早春とフィルム写真 カラーネガフィルムとはなんとも不思議なメディアで、その季節の陽光だとか湿度が写真に乗ってくるような気がする。 冬の写真は暗くかさついているし春の写真は霞がかって見える。夏の写真は湿度100%に近い空間を貫いてくる強い太陽光がフィルムの乳剤面に記録されてい…
はてなブログ | 無料ブログを作成しよう
早春とフィルム写真 カラーネガフィルムとはなんとも不思議なメディアで、その季節の陽光だとか湿度が写真に乗ってくるような気がする。 冬の写真は暗くかさついているし春の写真は霞がかって見える。夏の写真は湿度100%に近い空間を貫いてくる強い太陽光がフィルムの乳剤面に記録されてい…
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
静的オブジェクト指向は設計者が苦労を背負込むシステム
2009-09-26 北陸Scala第1回開催 2009-04-04 第十四回java-ja勉強会 - 第1回チキチキ 地方巡業withひがやすを飲み会in富山開催 2009-03-20 わんくま大阪勉強会#28 「ジェネリクスを使おう！」 2008-11-08 わんくま富山勉強会#1 開催 2008-08-09 わんくま東京勉強会#23 「C#登場前夜」 2008-04-01 *で始まるタイトルはエイプリルフールネタです 2008-01-26 わんくま東京勉強会#16 「ライブプログラミング」 2007-12-08 わんくま名古屋勉強会#1 「わんくま初めてのJava」 2007-07-28 開店 みねこあさんのところで挙がっていた、 静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。 Javaは経済的事情をうまく捉えて普及した プログラミングの効率と経済で書いていると
修正可能なシステム 番外編１ 出来る開発と出来ない開発の違い - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ここで 「その体系から見ると、できる開発と出来ない開発がみえてくる」というのは、修正可能なシステムでかきます と書いたので、「修正可能なシステム」の番外編として、その「出来る開発と出来ない開発の違い」を書きたいと思います（なお、番外編１の１は、べつに、２、３と予定しているわけでなく、もし今後出てきたら、１、２と続けようと思っているだけです） ■情報処理の体系 まず、「その体系から見ると」の「その体系」から説明します。 それについては、情報処理試験ぐらいのお勉強のポイントの体系化の「理論の階層と細分化」に書いた、 これは、情報処理という概念の２つの側面をあらわす。 情報処理とは、情報（データ）を、処理（プロセスを動かす、プロセッシング）することといえる。 ってことに関連する。 つま
オンスケジュール＝崖っぷち - 極北データモデリング
転職して分かった、進捗管理という面白くない作業を楽しくやる方法について。 タイトなスケジュールを組んで、そこからの遅れをチェックするから、楽しくないし、遅れが隠蔽される。 ダルダルにゆるいスケジュールを組んで、1週間以上前倒しにできているかどうかをチェックすれば、みんな遅れていることを隠さないので早めに手が打てる。 タイトなスケジュール＆遅れチェックだと「2日遅れです」と言わなくてはならないところを、だるいスケジュール＆1週間前倒しチェックなら「3日前倒しです」と言えるので気分がいい。 情報量はどっちの言い方でも同じだから、気分のいい言葉を使えばよい。 だいたいオンスケジュールというのは崖っぷちに居るということで、カゼ引いたり障害発生したりしたら即遅れてしまうのだから、「オンスケです」という報告がよいニュースのわけがない。「前倒し」という名前を付けたバッファの減少傾向を見張って、オンスケジ
BeInteractive! [「これコミットして大丈夫なのかな...」と考える前にコミットして欲しい]
最近、「こんなのコミットしちゃっていいのかな...」とか「本当に勝手に修正しちゃって大丈夫なのかな...」とか悩んでいる人を見かけるのですが、そんな風に悩む前にコミットして欲しいと思います。良いとか悪いとか、使うとか使わないとか、それは周りの人やユーザーが決めれば良いと思います。コミットせずにしまい込んでしまったら、何かが起きる可能性はゼロです。 そうは言っても、あまりこういうのに慣れていない人にとっては、色々と不安もあるようなので、それを解消する為にちょっとまとめてみました。 コミットを恐れないで欲しい どうも、コミットを「かなり重大な儀式」のように感じている人が多い気がするのですが、もっと気軽に、言うなれば「Twitterで発言する」ぐらいの感じで捉えてもらいたいと思います。別にどんな小さなコミットでも良いし、何連続でコミットしようが、誰も咎めたりしません。 実際、僕も最近はA
修正可能なシステム その２ 背景－修正のジレンマ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） シリーズ化してしまった？修正可能なシステム。 前回は、概要として、何をやるかについて書きました。 本来なら、その説明をするべきですが、その前に、どこが問題で、このような手順になっているのか？という背景の話をします。 ■データに関する修正をかける場合 問題は、データ構造に対して、削除、あるいは意味が変わったり、型が変わったりする修正で起こります。 （価格を、整数から実数へ、文字２バイトを１バイト、有効期間項目をなくすなど・・） この場合、修正後のプログラムを作るには、まず、データの構造を修正しないといけません。 とくに、データ構造に追加がある場合、追加しないと、プログラムが作れないので、追加します。そうすると、同時に項目を変えないといけない場合（つじつまが合わなくなるので）、削除や
人月計算とExcelとスーツの世界より・アフター
http://anond.hatelabo.jp/20080323175904 半年前に「人月計算とExcelとスーツの世界より」を書いた増田だけど、この増田が他人に思えなかったので、半年ぶりに自分の話をしたいと思う。 半年前のエントリの内容、読んでない・読むのたるいって人のために簡単にまとめておく。 俺はCOBOLっていう昔々の言語を使って巨大な金融システムのお守りをしていた。それは誇らしい仕事（「これ読んで「転職考えろ」とか言ってるやつってアホだろ」的な意味で。これももっともな話だよね）ではあるんだろうけど、俺はやっぱりキャッチーな新技術がやりたくてたまらない。 そんなふうに増田に愚痴ったところ、なんか400以上のブクマがついた。以上がこれまでのあらすじ。 話の続きを始める。 あれほどのブクマを集めたことなど初めてだった。戸惑いながらも、日々増えていく皆のコメントを噛み締めた。 転職を
エンジニア発想が小さくまとまってしまう理由
…あくまで「僕の場合」という前置きをつけておきます。 普段、プロデューサーという肩書で、サービスでうまくお金をいただけるように考えて実行する仕事が僕の会社での役割ですが（多分、はてなで言うサービスディレクターかな）、その流れで、たまに新しい何かを実現するためにシステム設計をしたりします。 ずっと開発担当者と並行してソースコードはずっといじっていたのですが、開発とプロデューサーは似て非なる仕事だということに気がついたので、開発は努めて移譲するようにしました。 でも、たまにプロデューサー的思想（「おもてなし」的なのや、もっとビジネスライクなのもある。）を実装に落とすにあたって、さまざまな理由で思いついたことを伝えるのが難しいなーと思う場合は、自分で詳細仕様を書いて、プロトタイプを作ってみたりします。 こういう時につくづく思うのが、昨日まで覚えていたことをシステム設計するとすっぽり忘れてしまうこ
機能から関係へ (arclamp.jp アークランプ)
建築には機能主義という言葉があります。 機能主義はモダニズム建築を代表する概念の1つで、アドルフ・ロース、オーギュスト・ペレ、バウハウスと言った名前が知られています。その次の世代としてはル・コルビュジエ、ミース・ファン・デル・ローエといった名前が有名でしょう。 時代背景から考えてみます。ロースが1870年生まれでミースが1887年生まれなので、19世紀末から20世紀初頭にかけて盛り上がった言葉だと言うことが分かります。19世紀末といえば産業革命が落ち着き、自動車など市民生活に機械が入り始める時期です。フォードが、かの有名なフォード・T型を市販したのが1908年10月のこと。フォードがT型の開発でもっと注意したのがフォード・システムに見られるような大量生産に適応させた車である点です。つまり、19世紀末から20世紀初頭というのは「機械による機械の大量生産」時代の幕開けともいえる時期だったのです
ユーザ目線のシステムの是非
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45665 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
inasphere blog | はてな伊藤直也さんのセミナーに行ってきた
Web Designing誌主催のWD Live! 株式会社はてなと考えるにっぽんのWeb 2.0。そのサービスとサイト運営 伊藤直也氏 × 須賀正明氏に行ってきました。来場者は160人だそうで会場はほぼ満杯。以下は自分が印象的だった部分のメモです。 はてなについて PV：6億/月 ユーザ：54万ユーザ サーバ：400台 売上：秘密だけど黒字 資金調達：0円 Alexaで16位（国内） 従業員：23名＋しなもん（注：ここは笑うところ） はてなサービスの作り方 開発者が自分で企画して自分で作る。 一つのサービスを開発するのは基本的に一人だけ。開発に関わる人数が多くなると、どうしてもサービスの方針がブレてしまうため。「新しいことの正しさは、あなたにしかわからない」 開発者自身が信じる哲学をサービスに投影する。 外注はしない。自分達でトライアンドエラーを繰り返し、技術とノウハウを蓄積する。 経験
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
バグ予防のDB設計
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45674 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
はてな伊藤直也氏MIJS講演「プログラマでいること」 : 小野和俊のブログ
昨日MIJSのコンソーシアム内での技術発表会があり、理事会の方から「参加ベンダーの技術者が集まるイベントなので、技術者に元気を与えられるような人に講演をお願いしたい」という話があったので、はてな伊藤さんに講演をお願いした。 伊藤さんにお願いしようと思ったのは、伊藤さんなら、エンタープライズの世界にウェブの世界の元気な風を吹き込んでくれるのではないかと思ったからだ。 以下、私なりに講演の内容をまとめてみた。 ■「建物の建て方」 つくる対象がどのようなものかで、作り方は当然変わってくる。これは建物もソフトウェアも同じ。1階建ての格好良い小さなロッジを建てるのと、60階建ての安全で高品質な巨大ビルを建てるのとは方法も道具も異なる。ロッジを建てる時にはノコギリを使うが、巨大ビルを建てるにはクレーンを使う。 よくブログの世界でソフトウェアの開発について、ぜんぜん違うことをやっている人が同じ土俵で議論
「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
「メインフレームにこだわると，技術が伝承されなくなる」——JTBの野々垣氏が警鐘：ITpro
「もし情報システムのオープン化に躊躇している現場があるならこう言いたい。メインフレームにこだわるな。一刻も早くオープン化に取り組めと」――。 JTB情報システムの野々垣典男氏（執行役員 グループIT推進室長，写真）は29日，都内で開かれたセミナーでこのように述べ，メインフレームに固執する企業に対して警鐘を鳴らした。日経SYSTEMS主催の創刊1周年記念セミナー「変化に強いシステム基盤の条件～ITインフラの最適設計を目指して」の基調講演で語ったもの。“脱メインフレーム”の最大の理由を野々垣氏は「システムを再構築するプロジェクトを敢行しなければ，ベテランのノウハウが伝承されない」ことだと強調する。 もちろん再構築の狙いは「技術伝承」だけではない。JTBでは1970年代に構築した旅行予約販売システムの再構築を，2002年から5年計画で進めている。その主な目的は，インターネット販売への対応や，各店
＠IT：ソフトウェア開発をちゃんと考える（1）
本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームリーダー日記 : コード量＝借入金の額
developer0000.jp