テスト駆動開発、Kent Beck著、和田卓人訳、濫読日記風、その28 - 未来のいつか/hyoshiokの日記
テスト駆動開発の発売記念という建てつけの技術書の歩き方勉強会「テスト駆動開発」編 - connpassというイベントに参加した。 テスト駆動開発は2003年に翻訳出版されたのだが、絶版になっていて、先日、和田さんが訳し直して出版された。その経緯は新訳版『テスト駆動開発』が出ます - t-wadaのブログが詳しい。 ソフトウェア技術書の古典的名著を翻訳しなおし、復刊するという商業ベースにはなかなか乗りにくいことを敢行した和田さんとオーム社に拍手を送りたい。 再翻訳に当たって、１）サンプルのソフトウェアのバージョンを最新にした、２）判型を小さくした（持ち運びやすい）、３）サンプルコードの省略をやめ、コードの変更点を目立たせ、各章ごとにその時点の全コードを記載する、というような工夫を施した。 それによって、現時点でも非常に読みやすい構成になっている。 そして本書の最大の特長は、付録Cにある、和田
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか - 未来のいつか/hyoshiokの日記
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース（OSS）を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記
誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事でLinuxを使う機会は全然なかったのだけど、自宅のPCにSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleがLinux版を出し
伽藍とバザールの「伽藍」ってなんだろう。 - 未来のいつか/hyoshiokの日記
Linuxの開発モデルを初めて紹介した歴史的エッセイとして有名なThe Cathedral and the Bazaarは、山形浩生氏が「伽藍とバザール」として翻訳している。The Cathedral and the Bazaar: Japanese オープンソースの開発モデルを従来型のカテドラル（大聖堂）モデルと対比して解説した。 Linuxの開発モデルでは、正式な文書もなければ、開発ロードマップも、技術的な設計書もない。皆無である。そして、そのような開発方法がうまく行く筈がないという風に広く信じられていた。特に、オペレーティングシステムのような精緻で組み立てる必要があると考えられているものが、そのようないい加減な方法で出来る訳がないと考えられていた。中央集中的に作る以外ありえないと当時は考えられていた。 Linuxの開発モデルは、素人の大学生が作った、ちょっとした遊びのプログラムを、イ
まつもとゆきひろのコピーは作れるのか。 - 未来のいつか/hyoshiokの日記
「Rubyにみるグローバルソフトウェア開発」というタイトルでの講演だった。 http://aiit.doorkeeper.jp/events/8871 まつもとゆきひろのコピーは作れるのか？ コミュニティの運営とかは言語化できそうだけど、情熱をコピーすることはできない。心に灯をともすにはどうすればいいのだろう。それを１０年間続けるにはどうすればいいのだろう。 OSSを作ることはそれほど難しいことではない。多分、気の利いたプログラマなら誰でも作ることはできる。 githubのようなサービスが開発を支援してくれるし、コミュニティ作りのコストを圧倒的に下げた。twtitterやFacebookやブログなどで開発を告知することも出来る。 にも関わらず、Rubyのように世界中で使われるプロダクトを作った人はまつもとさん以外にほとんど現れていない。OSSを作った人はいっぱいいるが、まつもとさんのような
プログラマが知るべき97のこと - 未来のいつか/hyoshiokの日記
和田さん監修、夏目大さん翻訳。下記のような日本人プログラマに書き下ろしもついている。 命を吹き込む魔法 森田 創 ロールプレイングゲーム 関 将俊 ルーチンワークをフローのきっかけに 宮川 達彦 プログラマが持つべき3つのスキル 吉岡 弘隆 快適な環境を追求する 舘野 祐一 見知らぬ人ともうまくやるには 小飼 弾 不具合にテストを書いて立ち向かう 和田 卓人 育ちのよいコード 森田 創 Noといえることの大事さ 宮川 達彦 名前重要 まつもと ゆきひろ 誰かに向かって、「〜するべき」というのは、いささかおこがましい感じもしないではないが、「プログラマが持つべき3つのスキル」というエッセイを寄稿した。日頃言っている、ソースコードを読むスキル、テストするスキル、デバッグするスキルなどについてあれやこれや申し上げた。 書き下ろしの中で、まつもとさんの「名前重要」や森田さんの「命を吹き込む魔法」は
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
東京Ruby会議03に行ってきた〜 [tokyorubykaigi03] - 未来のいつか/hyoshiokの日記
東京Ruby会議03に行ってきた。 http://regional.rubykaigi.org/tokyo03 場所は、日本オラクル。いつもお世話になっています〜。無線LANも安定しているし、電源も豊富にあるし、100名程度のカンファレンスをやるにはベストの会場だ。 午前中のYuguiさんの講演はUST中継で観ていて、午後のワークショップというかハンズオンから参加した。 わたしが参加したセッションは和田さんのRSpecの入門。http://d.hatena.ne.jp/t-wada/20100228/p1 はてなのブログにアップされたテキストを写経しながらRSpecを体験するというハンズオンだ。わたしはubuntu 8.10という、ちょっと古めのプラットフォームで、rspecをdebianパッケージで入れたのがどうもよくなかったみたいで、パッケージのバージョンが古くてspec の subj
![東京Ruby会議03に行ってきた〜 [tokyorubykaigi03] - 未来のいつか/hyoshiokの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/c046edf062c8dfd2440f8bf1bc1bbd66279c4282/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729892968%2F10257846132704606358%2F1547419305)
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
セキュリティー＆プログラミングキャンプキャラバン金沢 2009-01-31 - 未来のいつか/hyoshiokの日記
Genesis Lightning Talksでお話した映像が公開された。5分ちょっとなので、お気楽にご覧ください。 http://wiki.somethingnew2.com/lt/index.php?Events%2F2009%2F01 わたしのわくわくが伝わればいいなあ。 LT(Lightning Talks)で触れている日経サイエンスの記事って、http://www.nikkei-science.com/page/back/ronbun-kensaku/75-79.html を見るとマイクロコンピュータ（1975年7月号）みたいだ。1977年11月号にもマイクロコンピュータの特集がある。TOSBAC-3400はhttp://museum.ipsj.or.jp/computer/main/0004.html にあった。TRS-80とかARPANETとか若い人はコンピュータ産業の歴史だ
ピザ発注の必殺ノウハウ - 未来のいつか/hyoshiokの日記
最近では日本各地でなんちゃら読書会、なんちゃら勉強会、なんちゃらユーザー会などの会合が開催されていて、御同慶の至りである。めでたいめでたい。 各人、勉強会の会場探しやら会場設定、必要経費の計算、精算、会費の集金、懇親会の設定（場所決め、予約）、当日の運営などなどそれぞれにご苦労があるかと思う。この手のノウハウはほとんど一緒なのでベストプラクティスとして誰かがまとめておいてくれると今後の参考になってよろしいと思う。全日本オープンソースユーザー会連合会とか。 なので、わたしから、ピザ発注の必殺ノウハウを伝授しよう。 ピザはLサイズで出前を取る。だいたい3.5人に一枚という分量でいいだろう。Lサイズの相場は2800円〜3500円位なのでお財布に相談しながら発注する。 ビールは一人あたり1.5本程度にしておこう。わたしみたいにあればあるほど飲んでしまう奴が絶対いるのでそこはそこで分量を調整しよう。
無駄なドキュメントは書くな - 未来のいつか/hyoshiokの日記
ひたすら実装に関するドキュメントをしこしこ書いている人がいるが、好きで書いているわけではなく、書かされているのかもしれないけれど、そーゆー無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。断言する。実装に関するドキュメントと最新の実装は常に食い違っている。いまだかつて同期したことがない。無駄なドキュメントを書く時間があるならコードを洗練しろ。無駄なドキュメントを書く時間があるならコードをドキュメントにしろ。 ソフトウェア工学の教科書にドキュメントの重要性が書いてあるからといって信用してはいけない。ウオーターフォールモデルが商用ソフトウェア開発の現場で役にたたないように、実装に関する詳細ドキュメントは百害あって一利なしである。 コードがドキュメントだ。 http://capsctrl.que.jp/kdmsnr/wi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
