第106回カーネル読書会のお知らせ〜〜LinuxCon Japan開催記念〜〜 - 未来のいつか/hyoshiokの日記
Tweet 毎度お馴染み流浪のカーネル読書会のお知らせです〜 昨年のLinux Kernel Summit記念カーネル読書会と同じ感じで カーネルハッカーを招いてビアバッシュを開催します。 今年は誰が参加してくれるか楽しみです〜 日時：9月28日(火)18:00開場、18:30時ころ開始 お題：あれやこれやご歓談 発表者：みなさん 内容：いきなりビアバッシュ 会費：1000円（予定、学生は無料、コメント欄に学生と記してください） 18:00頃 開場、LTないし自己紹介など 19:00頃 ビアバッシュ 21:00頃 中締め 場所はGREE（六本木ヒルズ）http://gree.co.jp/corporate/location/ 会場の都合上、18:00より以前には開場しませんので、ご注意ください。 参加登録に際しては、受付のためお名前の明記をお願い致します。 またなるべく遅刻のないようにお願
2010-03-07
KCS(Keio Computer Society - 慶應義塾電子計算機研究会)という大学時代のサークルの50周年記念パーティに行ってきた。 同好会が50年も続くというのもすごいが、設立当初の先輩（60代半ば？）から現役の学生まで40数歳の年齢差のある人々が一同に会するというのもすごい。設立当時のお話も興味深いし、60年代のコンピュータのお話もめちゃくちゃおもしろかった。 日本IBM最高顧問の北城さんも先輩の一人なのであるが、学生時代GPSSの処理系を作られたというエピソードを語られていた。経済界の重鎮もプログラマの時代があったのである。 われわれ同期（1977年入学組）はしょっちゅう会っているのは、同期の浅井がゴルフコンペを定期的に開催しているからである。わたしはゴルフはしないが、定期的な連絡網の整備が、飲み会の情報の共有などとあいまって参加率の高さにつながっている。浅井さんには感謝し
ソースコードリーディングワークショップ2010に行ってきた。 - 未来のいつか/hyoshiokの日記
ソースコード理解と勉強会というタイトルでお話をした。ソースコードを読むことの意義などを話した後、わたしのしょぼいテクニックを恥ずかしながら披露した。 Sourcecode Reading Workshop2010View more presentations from Hiro Yoshioka. ワークショップは下記にあるようなプログラムになっている。 http://se.naist.jp/events/srw2010.html Javaアプレットのコードがあって、それぞれのパッチをあててよいかというのを判定するというのを実際のコードを読みながら行う。当初、コードを読むというハンズオンには参加するつもりもなかったのだが、2時間ほどぼーとしているのもヒマだし急遽参加することにした。ソースコードをPCにダウンロードしておけばよかったのであるが、ダウンロードしていなかったので紙でソースコードを
わたしがprintf()デバッグをしない理由 2009-03-22 - 未来のいつか/hyoshiokの日記
プログラマという職業について、もう25年くらいになるのであるが、その間にコンピュータのコストパフォーマンスは、それこそムーアの法則に従って、10万倍〜100万倍くらい向上した。にもかかわらづ、デバッグの方法というものの劇的な変化はほとんどみられない。 プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。 たまたま手元にあった、C実践プログラミング(ISBN4-900900-64-8)という10年くらい前に買った参考書では、450ページのうちデバッガの利用については、4行ほど記述がある。たった4行である。診断用のprintf()を挿入するということは3ページにわたって記述されているのにだ。 流石に21世紀になってprintf()デ
デバッグ方法論 - 未来のいつか/hyoshiokの日記
「わたしがprintf()デバッグをしない理由」http://d.hatena.ne.jp/hyoshiok/20090322#p1 は思いのほか注目をあびた。せっかくなので、その続編とも言うべきことを書き記してみる。 ところで、皆さんは、誰にデバッグ方法を教えてもらったのだろうか？テストの方法を誰に教えてもらったのだろうか。あるいは、ソフトウェア開発方法論を誰に教えてもらったのだろうか。学校でならったのは、プログラミング言語の文法であり、アルゴリズムであり、コンピュータアーキテクチャであった。デバッグ方法は誰も教えてくれなかったので、見よう見まねで行っていたのが学生時代だったような気がする。 バイト先のちっちゃいソフトハウスでは、トラブルシューティングは二分検索でやるということを教えてもらったが、デバッグ方法についての、コーチはなかった。別のバイト先では、厳密なテスト方法について学んだが
自分の人生は自分で決める。 2008-09-23 - 未来のいつか/hyoshiokの日記
先日のエンジニアの未来サミットで、「自分の人生は自分で決めよう」ということを言ったら、よしおかさん、自己責任論言いすぎと揶揄された。自分は、一言も「自己責任」という言葉を使っていないつもりだったのだけど、世間ではそうとらえるのねと非常に勉強になった。 自己責任って何だ？ わたしが繰り替えし主張していたのは、あくまで「自分の人生は自分で決めよう」ということである。その主張がマッチョだと言われると、もう何も言えないのだが、まあ、そーゆーことである。 別に努力しろとか頑張れとか言っているのではない。自分の人生は自分で決めようということである。 子供のころ、日が暮れるまで野球をやっていた少年が、いつの日かどうがんばっても自分はプロ野球の選手になれないのだなということを知り、すこしづつ大人になっていく。小さい決断を積み重ね、それが今の自分になる。 家庭の環境や、育った地域、自分ではどうしようもない、
未来のいつか/hyoshiokの日記 - 人月の神話
人月の神話を久し振りに読んだ。(フレデリック・Ｐ・ブルックス Ｊｒ．「人月の神話」新装版、狼人間を撃つ銀の弾はない。滝沢徹他訳) 人月の神話／ユメのチカラ OSSにかかわる多くの人は、プログラミングに楽しさを見いだしている。一方でプログラミングの苦しさを上手に回避している。一人で膨大な単純作業をやるのは苦しいが、コミュニティで開発すれば、それも苦ではないという事かもしれない。喜びは参加者の分だけ倍増し、苦しみは参加者の分だけ割引かれる。 http://blog.miraclelinux.com/yume/2007/07/post_1529.html ソフトウェア開発というのは人がおこなうものだから、その本質というのは変らない。ソフトウェア産業は日進月歩の技術によってささえられているので目まぐるしい新しい技術を追う事ばかりに気をとられていると、本質が見えなくなる危険性がある。ところが、カーネ
未来のいつか/hyoshiokの日記 若者の情報産業離れとオープンソース
日本OSS推進フォーラムのサーバ部会の性能評価のプロジェクトも佳境を迎えつつある。各種ベンチマークデータもそろいプロジェクトメンバーと毎週毎週がしがし議論を重ねている。先日はUN社の16CPUマシンでのスケーラビリティ検証データのレビューなどをプロジェクトメンバとやったが非常に楽しかった。 UN社はメインフレームの老舗U社の子会社ではあるがビジネスはSIとかサービスなので必ずしもOSとかRDBMSそのものに専門性があるというわけではない。PostgreSQLと言えば、各社にもそこそこPostgreSQLのコードを読んだことがある人はいるけど、業界的にはSRAの石井さんが重鎮になっている。石井さんを交えoprofileデータを分析した。 わたしなんかはPostgreSQLに関してはド素人、だけど昔は某社製RDBMSを開発していたから、そこそこ土地鑑はある。 RDBMSの性能があがらないのは、
未来のいつか/hyoshiokの日記 - 当事者になるということ
時々思う。本当に日本と言う地域は評論家だらけだと。冗談じゃない。あんたはそれをやったことがあるのか？汗をかいたことがあるのか？それだけ言うのなら自分でやってみろ。 なんてことを言うのは大人気ない。大人はそういうことを言わない。ぐっとこらえてミステリアスな笑みを浮かべると言うのが正しい日本人の姿だ。 時々日本に対する違和感を持つことがある。そりゃ違うだろうと思うことがある。それに対してどのような態度をとるのか？どのような態度をとることによってその人なりの生き方が見えてくる。 多分わたしは自分が自覚するかしないかにかかわらづ日本人が暗黙のうちに持っている掟をどこかで踏み外しているというような感じがする。それがいいことか悪いことかは別としてそのような感じを持つ。 90年代日本のIT産業の出口がなくなったとき多くの人は何もしなかったし、そもそもそこに問題があるとは思っていなかった。大丈夫か日本なん
無駄なドキュメントは書くな - 未来のいつか/hyoshiokの日記
ひたすら実装に関するドキュメントをしこしこ書いている人がいるが、好きで書いているわけではなく、書かされているのかもしれないけれど、そーゆー無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。断言する。実装に関するドキュメントと最新の実装は常に食い違っている。いまだかつて同期したことがない。無駄なドキュメントを書く時間があるならコードを洗練しろ。無駄なドキュメントを書く時間があるならコードをドキュメントにしろ。 ソフトウェア工学の教科書にドキュメントの重要性が書いてあるからといって信用してはいけない。ウオーターフォールモデルが商用ソフトウェア開発の現場で役にたたないように、実装に関する詳細ドキュメントは百害あって一利なしである。 コードがドキュメントだ。 http://capsctrl.que.jp/kdmsnr/wi
正しいものを作ることと正しくものを作ること - 未来のいつか/hyoshiokの日記
プログラムを作ることはそれほど難しいことではない。それを製品にしてビジネスとすることは非常に難しい。「正しくものを作ること」より「正しいものを作ること」のほうがはるかに難しいのである。 いわゆるウォーターフォールモデルでは開発プロセスの初期に仕様を固定してそれを「正しく作る」事に注力する。１千行あたりのバグ数とか月当たりの生産コード行数などが、いかに「正しくものを作ったか」の生産性の指標になる。ソフトウェアファクトリとか日本のソフトウェア産業の得意とするところである。開発プロセスの初期段階で仕様を固定するので、状況の変化とか、顧客の要求の変化とかには取り合えず目をつぶるので、作られたものが顧客に必要とされているものかは、ものができてみないかぎりよく分からない。まあ、原子炉の制御システムみたいに信頼性が絶対条件だとか、システム要件が何年経ってもほとんど変化しないものには、そーゆー開発プロセス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
