かつてオープンソースが当たり前じゃないころがあった - 未来のいつか/hyoshiokの日記
先日文明塾の修了生のみなさまとお話したときのこと(コミュニティとしての大学 - 未来のいつか/hyoshiokの日記参照)。ハッカー文化とかオープンソースのことをあれやこれやお話したのだけど、その中で現役の学生さんから「ゼミでIT係を担ってからよくソースコードを何気なく閲覧してしいました。しかし、自由にソースコードが見れる環境が衝撃的で素晴らしいことであることに吉岡さんのお話を聞いて学ばせていただきました。」という感想をいただいた。 そうだ。すっかり忘れていた。オープンソースが当たり前じゃない時代があった。とてつもない衝撃を受けた自分がいたことをすっかり忘れていた。 1998年1月。Netscapeが自社のブラウザのソースコードを公開するということを発表した。当時のシリコンバレー日記にそのことを書いている。http://web.archive.org/web/19990423102903/
昔DECという会社があった。エンジニアとして必要な事はDECで学んだ。 - 未来のいつか/hyoshiokの日記
大学を1984年に出て、新卒で入社した会社がDECという会社だった。その当時日本デジタルイクイップメント研究開発センター株式会社というのが日本にあってそこに新卒バリバリで入社した。その会社は米国のDigital Equipment Corporation (以下DECと称す）の日本子会社であった。当時はDECの販売子会社日本ディジタルイクイップメント株式会社と別会社で、後に合併して日本ディジタルイクイップメントになる。 エンジニアリング部門の子会社なので、トップはPhD（博士号）を持っているし、米国本社からの出向者もいて、技術系の外資という感じだった。一方で、新卒入社ということもあり、同期も少ないながら（6名）いて、日本DECの同期と合わせれば、200名近くいて、日本企業的な感じもあった。 DECをコンピュータ産業史的な観点から眺めると、当時コンピュータ産業を支配していたメインフレーム、す
ブルックスの法則とはなにか - 未来のいつか/hyoshiokの日記
ソフトウェア開発におけるブルックスの法則とは何か。 http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87 遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる ブルックスはIBM System/360用オペレーティングシステムOS/360の開発総責任者だった人で、その経験をもとに人月の神話【新装版】というエッセーを執筆した。 人月の神話は、ソフトウェア開発を志す人なら必ず一度は読まなければいけない良書だ。読んでいない人は、悪いことは言わないから、ともかく読むことをおすすめする。 初版が出版されたのが1975年（日本語訳は1977年）で、20周年記念版が1995年に出た。ブルックスの発見した法則があきらかになって約40
パターンによるソフトウェア構成管理 - 未来のいつか/hyoshiokの日記
パターンによるソフトウェア構成管理を大学の図書館で見つけて読んでみたところ意外に良書だったので紹介する。 16個のパターンを紹介している。 Pattern Name Summary Mainline マージを最小化する。メインラインで開発することによってアクティブなコードラインの数を管理可能な集合にする。 Active Development Line Active Development Lineを作ることによって急激に成長するコードラインを安定化する Private Workspace Private Workspaceによって、統合の問題で集中できない状況から守る、また自分の変更が他の人に影響を及ぼさないようにする Repository 必要なものを全て持っているRepositoryを設定する Private System Build Repositoryにコミットする前にPriva
ビアバッシュの段取り - 未来のいつか/hyoshiokの日記
某ML社の中で最もビアバッシュに精通したダンドリストと言えばわたしだ。あ、ちなみにビアバッシュつーのは、シリコンバレーあたりで、金曜日の夕方に、(別に金曜日じゃなくてもいいんだけど)、会社でピザなどの軽食をとりつつビールとかワインとか飲みながらわいわい歓談する、まあ言ってみれば、飲み会みたいなものですな。 カーネル読書会をミラクル・リナックスで開催するときは通常ピザパーティと称してこのビアバッシュをとりおこなう。つまみはピザ、飲み物はビールとアイテムが固定しているので幹事としてはこれほど簡単なものはない。 ピザの発注 発注先：わたしはよく、ドミノピザ http://www.dominos.jp/ を利用するのだが、インターネットで注文すると5%オフになったりするので、各自確認しておこう。ピザーラ、ピザハットなどチェーンの出前などもチェックするとよい。 発注量：カーネル読書会の場合、L一枚3
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
楽天で角谷さんのお話を聞いた - 未来のいつか/hyoshiokの日記
解読アジャイルソフトウェア開発というタイトルでお話をしていただいた。*1 アジャイル開発の本質を角谷節で1時間あまり独演会してもらった。 Demystifying Agile Software DevelopmentView more presentations from Eiwa System Management, Inc. . ともかく映像を観てほしい。約1時間ちょっと、そしてその後に続く質疑応答も一緒に。 ソフトウェア開発における受託開発という立場ではない、もう一つのソフトウェア開発の現場が、自分のサービスを自分で作るという立場だ。 受託開発の場合はユーザー企業（発注する側）と開発する企業（受託する側）とがあって、時として敵対関係に陥る。一方の利益が他方の損というゼロサムゲームである。 自社開発の場合は、社内にユーザ部門と開発部門があったとしても、最終的にはユーザ部門の利益と開発部
2010-03-27
20数年前に新卒で入社したわたしを育ててくれたのは配属先の上司であり、社内エンジニアリングコミュニティだ。 最初のプロジェクトは日本語COBOLのプリプロセッサを作るというものだった。大学でソフトウェアを学んだが、職業としてプログラムを組むという経験はなかった。プログラムを作ることのいろはをその会社で学んだ。 新卒の初心者プログラマの日常はこんな感じだ。 よ「プログラム書きました〜」、先輩「あれ〜、どこにファイル置いたの？チェックインした？」、よ「まだでした」、ぱたぱたぱた、よ「チェックインしました〜」、先輩「あれー、ビルドできないなあ、コンパイルエラーが出るよ」、よ「コンパイルしていませんでした〜。今直します〜」、あれやこれや、よ「出来ました。ばっちりビルドも出来ます〜」、先輩「あれー、テストが通らないなあ、ちゃんとテストしたの？」、よ「テストはしていません（きっぱり）」、先輩「おいおい
2010-03-20
なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
Emacsとわたし - 未来のいつか/hyoshiokの日記
Emacsというエディタがある。ハッカーが長年育ててきたエディタだ。わたしも日常的に使いはじめて10数年になる。 多機能、拡張可能なので、いろいろな便利なモードがあるが、正直全然使いこなせていない。機能の1%も使いこなせている感じがしない。 会社の机の上にあるGNU Emacsマニュアル(竹内、天海監訳)の初版発行は1988年2月である。20年前のマニュアル。 会社のブログに「勉強しなおす／ユメのチカラ」というのを書いた。 http://blog.miraclelinux.com/yume/2008/05/post-81b9.html いくつになっても勉強だ。昔とった杵柄。錆びたナイフを研ぐ。 思いたったら吉日。もう一度Emacsを勉強しなおしてみようと思った。 DECにいたころはプロプライエタリな世界にどっぷりで当然エディタは自社製のJTPU (Japanese Text Process
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
