継続的インテグレーション(CI - Continuous Integration)と継続的デリバリー(CD - Continuous Delivery)について知りたかったら、闘うプログラマー［新装版］を読もう。 これはWindows NTの開発物語だ。大規模基盤ソフトウェアの現場の葛藤を生々しく描いていて、ソフトウェア開発に従事しているものには必読書といっても過言ではない。 デスマーチ、ドッグフードを食う、ビルド、業界人なら誰でも聞いたことがあるジャーゴン（業界用語）がちりばめられている。本書によって、それらの用語を覚えた人も少なくないと思う。 「カトラー（開発の総責任者、伝説のプログラマー）は、オペレーティング・システムを開発するときは、機能を増やすより、スケジュールを短縮するべきだと考えている。最初のバージョンは、機能を減らしても、早くリリースしたほうがいい。最初は機能を最小限にして

PBL(Project Based Learning)の授業を持っていて、その教員が集まってあーだこーだという会に参加している。PBLという手法は必ずしも教員にとっても経験豊富なものではないので学生の指導方法とかに悩みが多いので、いろいろな立場の人が集まって、あーだこーだ試行錯誤や悩みについて披露し合う。 産業技術大学院大学でのPBLはウェブアプリケーションの作り方を学ぶというもので、モダンなソフトウェア開発手法やクラウドを前提としたツールなどを利用してチームで実際にものを作る。 *1 キーワードとして、Continuous Delivery (CD), Test Automation, Continuous Integration (CI), Version Control System, Test Driven Development (TDD), Platform as a serv

エンタープライズ系ってなんだろう。ウェブ系ってなんだろう。勝手に脳内イメージを言語化してみた。読者諸氏のコメントを待つ。(想像でものを言っています) エンタープライズ系 ウェブ系 開発手法 ウォーターフォール アジャイル 開発 外注 内製 会議 多い、長い 少ない、短い 資料 人数分カラー印刷 印刷なし 進捗管理 エクセル バーンダウンチャート ソースコード管理 ファイル名日付 Git 服装 スーツ Tシャツ 新技術の取得 ベンダーのセミナー 勉強会 テスト 人海戦術 自動化している 休日の過ごし方 休日出勤 趣味のプログラミング 休日の過ごし方、その２ ゴルフ 趣味のプログラミング、子供と遊ぶ ダイバーシティー 最近結婚してやめた人がいる 最近外国籍の人が増えている 上司 年上 年下もいる 飲み会 おじさんばっか おたくとコスプレ 転職 したことがない 同業他社から転職して来た 趣味、尊

先日文明塾の修了生のみなさまとお話したときのこと(コミュニティとしての大学 - 未来のいつか/hyoshiokの日記参照)。ハッカー文化とかオープンソースのことをあれやこれやお話したのだけど、その中で現役の学生さんから「ゼミでIT係を担ってからよくソースコードを何気なく閲覧してしいました。しかし、自由にソースコードが見れる環境が衝撃的で素晴らしいことであることに吉岡さんのお話を聞いて学ばせていただきました。」という感想をいただいた。 そうだ。すっかり忘れていた。オープンソースが当たり前じゃない時代があった。とてつもない衝撃を受けた自分がいたことをすっかり忘れていた。 1998年1月。Netscapeが自社のブラウザのソースコードを公開するということを発表した。当時のシリコンバレー日記にそのことを書いている。http://web.archive.org/web/19990423102903/

ともちゃんがGitHubを勉強したいにゃん、ということなので、勉強会に行ってきた。みんな猫耳つけて発表するというわけのわからない勉強会であった。 http://atnd.org/events/48075 Introduction to Git and GitHub #git_nyan from Hiro Yoshioka のれんがかかっていた。 これらはすべて手作り 沢田さんの説明 LTもあった GitHub実践入門とステッカー わたしのお話は、GitがLinusの自分の問題を解決することから始まったというような歴史の話からあれやこれや。Linuxのソースコードを管理するためには分散型、高速、高信頼性などが必要。 Linusは自分のPCのバックアップをとっていなくてもコミットしたものをインターネットにおいておけば誰かがコピーして、そのコピーは改竄することが非常に難しいので安全に複数のバック

日本において、就職したあと、大学で学び直すというのは、それほど一般的ではないような気がする。諸外国はどうなんだろうか？ 下記の資料などをみてみると、OECD教育データベース(２００５年)の調査では、25歳以上の大学生の比率は、日本は2％で最低、OECD平均は20.6%、最高はアイスランド40.1%となっている。 http://www.mext.go.jp/b_menu/shingi/chukyo/chukyo4/028/siryo/__icsFiles/afieldfile/2010/03/05/1287479_01.pdf また、社会人学生の比率も、通信制（放送大学を含む）を含めても平成13年に18,340人をピークに現象減少している。入学者に占める社会人割合は2%を切る。 日本はまれにみる社会人が勉強しない社会なのか？ enPiTなどのプログラムを作っても、顧客となる社会人に刺さらなけ

わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、

昨日の日記には山のようにブックマークがついた。( 世界でもっとも強力な9のアルゴリズムを読んだ。 http://d.hatena.ne.jp/hyoshiok/20140209/p1 ) データベースはアルゴリズムじゃないだろうというツッコミもあるけど、偉大なアイデアということだろう。それは多分誰も異論はないと思う。そこで紹介されている３つのアイデアは ログ先行書き込み(WAL) 2段階コミット リレーショナルデータベース トランザクションと言う概念が70年代以降発展してきて、その実装にはログ先行書き込みが多大な貢献をした。 2段階コミットによって分散型データベースが信頼性をもって実装できるようになった。 リレーショナルデータベース（というよりもリレーショナルデータモデル）は全ての基盤になっている。 これらの発展は70年代のSystem Rの先駆的な研究開発から始まったといっても過言ではな

1990年代のインターネットというのは利用者も少なく閉じた世界観があって、自由というもののある種の見えない掟みたいなものがあった。あったのかもしれない。当時ネットニュースという掲示板みたいなものがあって、今で言うところの中二病をこじらせたいい歳をした大人たちが日夜あーでもないこーでもないと言い合っていた。 fjというネットニュースがあって、日々いろいろな話題が議論されていた。あなたの会社のエラい人も若い頃、そのネットニュースに書き込んでいたかもしれない。若き日の（15年前）まつもとゆきひろさんとかがいるよ。 たまたま、そのころのニュースを発見して、あまりの懐かしさにここに再掲することにする。若き日の、あの人やこの人の中二病時代の書き込みである。 編集解説はわたし。それ以外は、当時の誰か。 https://groups.google.com/forum/?hl=ja#!topic/fj.co

日経BP社、ITPro副編集長、高橋信頼さんが2013年12月26日に逝去された。 彼は日経BP社の記者としてOSS（オープンソースソフトウェア）、地域コミュニティ、ITによる東北復興支援などを精力的に取材し記事にしてきた。プライベートでは、よき父として、よき夫として過ごされた。 http://itpro.nikkeibp.co.jp/search/index.html?q=%E9%AB%98%E6%A9%8B%E4%BF%A1%E9%A0%BC 早くからオープンソースやLinuxに注目し、取材を続けられていた。日経ITProのサイトには4100件を超える記事がアップされている。2000年頃から記事があるので、年間300本近くの記事を投稿されていることになる。驚異的な量だ。 第100回カーネル読書会 http://itpro.nikkeibp.co.jp/article/NEWS/2009

オープンソースやウィキペディアの成功によって実証されたインターネットを利用したオープンイノベーションが科学の分野にも起こるかということを解説している。 科学の発展は、科学者が発見したものを論文として公開することによってもたらされて来た。 ニュートンやガリレオの時代は科学者が発見を広く公開することはなかった。世界最初の科学雑誌が発行されたのは1665年で、ガリレオが一連の偉大な発見をしたのが1610年のことだ。 閉鎖的で秘密主義的な発見の文化から、科学者が新しい成果をできるだけ迅速に出版しようとする現代の科学文化への移行は、いったい何によって引き起こされたのだろうか。（272頁） 17世紀における科学の大きな進歩には裕福なパトロンの存在がある。パトロン達が科学者達を支援した主な動機は、科学的な発見によってもたらされる公的な利益と、偉大な発見への援助者として与えられる名声にある。 科学的な発見

良いコードを書くためにはどのようにしたらよいのだろうか。 そのヒントが載っている。200頁ちょっとの本だからすぐに読める。読めて知識として得たとしても、それですぐに良いコードを書けるようになるとは限らない。日々コードを書く時にこのヒントを実践しなければいけない。それはもちろん簡単なことではない。 知っていることと出来ることには大きな差がある。 職業としてのプログラマならば、知っているだけではだめで出来るようにならないといけない。 それは必ずしも容易なことではない。日々の鍛錬が必要なのは言うまでもない。 本書を職場の同僚と読んで、ここで書かれていることを話し合ってみよう。同意できる部分、よく分からない部分、実践することが簡単な部分、難しい部分などがいろいろ見つかると思う。 読書会のいいところは、読んだメンバーに共通の理解ができることだ。例えば「名前に情報を詰め込む」ということはどういうことか

大学を1984年に出て、新卒で入社した会社がDECという会社だった。その当時日本デジタルイクイップメント研究開発センター株式会社というのが日本にあってそこに新卒バリバリで入社した。その会社は米国のDigital Equipment Corporation (以下DECと称す）の日本子会社であった。当時はDECの販売子会社日本ディジタルイクイップメント株式会社と別会社で、後に合併して日本ディジタルイクイップメントになる。 エンジニアリング部門の子会社なので、トップはPhD（博士号）を持っているし、米国本社からの出向者もいて、技術系の外資という感じだった。一方で、新卒入社ということもあり、同期も少ないながら（6名）いて、日本DECの同期と合わせれば、200名近くいて、日本企業的な感じもあった。 DECをコンピュータ産業史的な観点から眺めると、当時コンピュータ産業を支配していたメインフレーム、す

20数年前に新卒で入社したわたしを育ててくれたのは配属先の上司であり、社内エンジニアリングコミュニティだ。 最初のプロジェクトは日本語COBOLのプリプロセッサを作るというものだった。大学でソフトウェアを学んだが、職業としてプログラムを組むという経験はなかった。プログラムを作ることのいろはをその会社で学んだ。 新卒の初心者プログラマの日常はこんな感じだ。 よ「プログラム書きました〜」、先輩「あれ〜、どこにファイル置いたの？チェックインした？」、よ「まだでした」、ぱたぱたぱた、よ「チェックインしました〜」、先輩「あれー、ビルドできないなあ、コンパイルエラーが出るよ」、よ「コンパイルしていませんでした〜。今直します〜」、あれやこれや、よ「出来ました。ばっちりビルドも出来ます〜」、先輩「あれー、テストが通らないなあ、ちゃんとテストしたの？」、よ「テストはしていません（きっぱり）」、先輩「おいおい

数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース（OSS）を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1

OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。通常は元となるソースに対しての差分をパッチという形で提供することになる。あなたがプログラマなら diff とか patch というコマンドはおなじみであろう。そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。メンテナはそのパッチをみてよければ採用しよくなければ採用しない。良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。ある人のパッチは受け入れられてある人のパッチは受け入れられない。ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。少なくともわたしにはその経験則を記述する程の経験はないのでそれは出来ないが、インターネットのどこかにはそのような経験則を記述した文書があるはづである。(多分Eric Raymondあたりが記述しているはづだ) 商

KCS(Keio Computer Society - 慶應義塾電子計算機研究会)という大学時代のサークルの50周年記念パーティに行ってきた。 同好会が50年も続くというのもすごいが、設立当初の先輩（60代半ば？）から現役の学生まで40数歳の年齢差のある人々が一同に会するというのもすごい。設立当時のお話も興味深いし、60年代のコンピュータのお話もめちゃくちゃおもしろかった。 日本IBM最高顧問の北城さんも先輩の一人なのであるが、学生時代GPSSの処理系を作られたというエピソードを語られていた。経済界の重鎮もプログラマの時代があったのである。 われわれ同期（1977年入学組）はしょっちゅう会っているのは、同期の浅井がゴルフコンペを定期的に開催しているからである。わたしはゴルフはしないが、定期的な連絡網の整備が、飲み会の情報の共有などとあいまって参加率の高さにつながっている。浅井さんには感謝し

例えば、次の言葉の意味を知りたい、聞いたことがあるけどよく分かっていないプログラマにとって、お勧めの書籍だ。Unicode/UTF-8/UTF-16/USC-2/JIS X0208/JIS X0212/JIS X0213/SJIS/EUC-JP/CP932/ISO-2022-JP/ASCII/Latin-1/ISO 10646/ISO 8859-1/サロゲートペア/文字化け/機種依存文字/半角カナ/絵文字… JIS X0208やJIS X0213の解説などは圧巻である。書籍にはWebにない利点がある。Webには即時性があるが、文字コードの解説においては、即時性はそれほど求められない。字体ないし字形の差異についてWebではその字体ないし字形がなければ表現しようがないが、書籍であれば細部までこだわって表現できる。 例えば、包摂された「辻」という字の一点しんにょうと二点しんにょうの字体の差はWe

文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる

「わたしがprintf()デバッグをしない理由」http://d.hatena.ne.jp/hyoshiok/20090322#p1 は思いのほか注目をあびた。せっかくなので、その続編とも言うべきことを書き記してみる。 ところで、皆さんは、誰にデバッグ方法を教えてもらったのだろうか？テストの方法を誰に教えてもらったのだろうか。あるいは、ソフトウェア開発方法論を誰に教えてもらったのだろうか。学校でならったのは、プログラミング言語の文法であり、アルゴリズムであり、コンピュータアーキテクチャであった。デバッグ方法は誰も教えてくれなかったので、見よう見まねで行っていたのが学生時代だったような気がする。 バイト先のちっちゃいソフトハウスでは、トラブルシューティングは二分検索でやるということを教えてもらったが、デバッグ方法についての、コーチはなかった。別のバイト先では、厳密なテスト方法について学んだが