ソフトウェア開発における、資産とはなんだろう？単純に考えると、「ソースコード」というソフトウェア設計図そのものを中心に、それを開発するためのドキュメント、テスト、ユーザマニュアルなどを考えがちだ。人は、これらのまわりで、これらを作り出し、メンテナンスしている。 しかし、実際は「人、一人ひとりの頭の中」も、資産だと考えないといけない。すなわち、ソースコードになっていない思考過程、ノウハウなど。。。ソフトウェア開発は、壮大な伝言ゲームであり、脳の中で情報を加工し、その情報を別の脳に伝え合って開発している。 例えば、ドキュメントがしっかり整っていれば人は交換可能だ、と考える人もいるが、ぼくはこれはナンセンスだと思う。暗黙知も含めて、頭の中にある「スティッキー」な情報はすべてをドキュメントに書き出すことはできない。聞かれれば答えられる情報すべてを、聞かれる前に紙には書けないし、「こういう場いいどう
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
ソフトウェアエンジニアの仕事はいいソフトウェアを書くことなので、別に英語のミスなんか二次的な問題なのだが、Twitterやメーリングリストで、日本人（と思われる）ソフトウェアエンジニアがよくするミスについて、メモしておこうと思う。何かの役に立ったら幸いだ。反響があれば、あとからここに足していくかもしれない。 software/middleware/hardwareは常に単数:softwares/middlewares/hardwaresとはまず言わない。どうしても数えたい時は"a piece/pieces of software"とするのが妥当。 codeも基本的に数えられない:"I wrote codes"とか"I can't deploy codes"とかいう表現を散見するが、これも間違い。ただcodeに関しては、暗号という意味もあり、こちらは数えられます。"Secret codes"
ピタゴラ装置ができるまで 最近Gitを多少理解した。 Gitを理解することは、ソフトウェアの設計について深く考えさせられる体験である。おそらく、SCMになんの関心もない人にとっても、Gitを理解することは有益だ。理解した結果ではなく、理解する過程が有益となる。 Gitを理解した結果は、Gitを理解する過程に比べると、些細なものだ。tarballとパッチによるワークフローの、賢く素早いが面倒な自動化――「そうそう、コンピュータってこういうものなんだよ」と改めて思い出させてくれる。賢く素早いが、面倒。 インターネットが普及し始めてから20年以上が過ぎた。コンピュータによる自動化が容易な分野は、掘り尽くされつつある。今後新しく登場する種類のソフトウェアの多くは、Gitと似た問題を抱えるだろう。 Gitを理解するうえでの困難について書き留めておく。 ・用語の混乱と不統一 まず、名詞のcommitと
最近、日本経済新聞電子版に掲載された中村邦夫パナソニック前会長の言葉に、私はある衝撃を受けました。そして思い出したことは、日本の電機メーカーでの伝統的なソフトウエアの軽視、というより「ソフト嫌い」の伝統です。 この言葉が出てくる記事は、2012年7月2日掲載の「『さらばパナソニック』知られざるカリスマの胸中」です。経営の第一線を退く中村邦夫前会長へのインタビューに基づく記事で、その中にこんな言葉が出てきます。 僕はね、電機業界にはITという隕石（いんせき）みたいなんが落ちてきたんやと、今でもそう思うとるんですわ。 この言葉は、三洋電機の買収（2008年〜2009年）の是非に関する文脈の中で出てくる言葉です。そして、次のように続きます。 ライフスタイルも何もすべてを変えてしまったからね。デジタル化の波が急激にやってきて、われわれのようなメーカーは、さてどうするかと考えねばならなくなった。 こ
かねてより自分がインターネットにおいて完全にパブリックに公開している各コンテンツのライセンスについて明示してきた。すなわちソースコードについては GNU GPLv3 、それ以外の文章等については CC BY-ND 3.0 というライセンスである。これについて、今年に入ってからひっそりとソースコードのライセンスを GPL から GPLv3/LGPLv3 のデュアルライセンスに変更した。それって単なる LGPLv3 と一緒じゃないのと思う人もいるだろう。だが、あくまでデュアルライセンスの形態を採用しているのには理由がある。私がハッカーとしてこの世で最も敬愛しているリチャード・ストールマンの思想によると LGPL の採用はフリーソフトウェアとしての後退を意味する。一方で、私自身が利益を追求する企業に所属している以上やむを得ない事情もある。しかしながら単純な LGPL 採用を善しとしない思想上の理
Geckoベースのユーザーインターフェース (HTML Canvas + XUL)。柔軟でカスタマイズが容易です。 マルチプラットフォーム。現在サポートされるのは、Mac / FreeBSD / Linux(というかUbuntu) / Windows(XP/Vista/7) + Cygwin環境 (POSIX版Pythonが必要) プラグインアーキテクチャ。プラグアンドプレイでのインストール・アンインストールが可能。 ブラウザを再起動したり閉じたりしている間、ターミナルセッションを保持します。 サスペンドしたセッションに後から再接続できます。 デバッガ内臓。ステップ実行やトレースができます。 ターミナルとアプリケーションがやり取りするI/Oシーケンスをリアルタイムで観察できます。 スクロールバック、代替スクリーン、ビジュアルベル、オーディオベルなど基本的な機能はサポートしています。 IME
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
