Netscapeがすごい会社だった頃の話（1996年前後）。 - 未来のいつか/hyoshiokの日記
夏休みなので、たまたま読んでいたCoders at Work プログラミングの技をめぐる探求という本の中にJamie Zawinskiのインタビューが載っていた。この本は著名なプロラグマを集めたインタビュー集で、Unixを創ったKen ThompsonやらDonald Knuthやらすごい人たちが登場している。 その中でJamie Zawinskiはそれほど著名でもなければ誰もが使っているすごいシステムを開発したというわけでもない。私が彼の名前を知ったのはNetscapeのソースコード公開時にMozilla.orgを仕切っていた頃なので、20年近く前である。 彼はxemacsの開発者としても著名で、当時GNU Emacsではなくてxemacsを日常的に使っていたので馴染みにある名前だった。xemacsとGNU Emacsはのちにマージされるのだけど前者が今で言う所のバザール型開発で、後者が
Done is better than perfect 完璧よりもやることだ - 未来のいつか/hyoshiokの日記
FacebookのHacker Wayという行動原理のなかに、Done is better than perfect（完璧よりもやることだ）というのがある。IPOのときの目論見書にそれが書いてある。 Registration Statement on Form S-1 The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it ― often in the face of people who say it’s impossible o
SQLを作った人たち - 未来のいつか/hyoshiokの日記
リレーショナルデータベース管理システム(RDBMS)は言うまでもないことだけど、データベース管理の基礎中の基礎だ。NoSQLというRDBMSではないデータベース管理システムが出て来ているがそれもSQLがあってこそのNoSQLだ。 リレーショナルモデルはIBM E.F. Codd博士が提唱した。Edgar F. Codd - Wikipedia Codd博士は後にチューリング賞を受賞している。 http://en.wikipedia.org/wiki/File:Edgar_F_Codd.jpg そのデーターモデルを利用したデータベース管理システムのプロトタイプがSystem Rだ。IBM System R - Wikipedia 1974年ごろ発表された。 その成果の一つがSQLだ。誰でも使っているSQLはSystem Rの論文が発祥の地である。そしてその論文を読んでRDBMSを作った男がL
第110回カーネル読書会を開催した - 未来のいつか/hyoshiokの日記
かれこれ15年にもわたってこんなことをやっている。震災のあった2011年から先日まで活動をほぼ休止していたが、先日再開した。 Kernel Code Reading Party, #ylug_110 2014/05/02 from Hiro Yoshioka YLUG (横浜Linux Users Group)の年表をみてみると第1回カーネル読書会は1999年4月28日に溝口で開催した。 http://www.ylug.jp/modules/pukiwiki/?history 駅そばの公民館みたいなところでミーティングをして、その後、居酒屋で宴会。 そもそものきっかけはYLUGのメーリングリストでLinuxのシステムコールはどうやって実装しているのかを質問したところだれかが、それはソフトウェア割り込みで実装しているというのを教えてくれて、おお、それはすごい、じゃあ、そのコードを読んでみたい
ブルックスの法則とはなにか - 未来のいつか/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の日記
プレゼン資料で画像を使いたい場合がある。 インターネットで検索して適当にコピペするというのは、その画像の著作権を持っている人の権利を侵害する可能性が高いので、よろしくない。 そこで、再利用可能な画像の検索方法が必要になってくる。 1) Image検索で、Search Toolsをクリック 2) Usage rightsをクリック。そのなかで権利関係で選ぶ。ライセンスでフィルターしない。再利用、変更可能。再利用可能。非商用、再利用、変更可能。非商用、再利用可能。のなかから選ぶ。 再利用可能な画像はいっぱいあるので、そこから選んで利用しよう。くれぐれも、自分が著作権を持たない、画像をぺたぺたはるのはやめよう。よく、マンガのキャラクタなどを分別なしに使っている人がいるが、おすすめできない。多くの場合は引用の範囲を超えているので、やめたほうがいい。 下記のサーチエンジンのリストも便利だ。 http
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
世界でもっとも強力な９つのアルゴリズム、読了。 - 未来のいつか/hyoshiokの日記
世界でもっとも強力な9のアルゴリズムを読んだ。 コンピュータサイエンスの優れたアイデアを紹介している。それらは私たちの生活を変えた。世界を変えたにもかかわらず広くは知られていない。 偉大なアルゴリズムというものは何なのか？本書はその偉大なアルゴリズムを次の基準で選定した。１）普通のコンピュータユーザが毎日使っているもの。２）現実世界の具体的な問題を解決するもの。３）コンピュータサイエンスの理論に関係のあるもの。 そのような基準から著者が選んだのが下記のアルゴリズムだ。 検索エンジンのインデキシング ページランク 公開鍵暗号 誤り訂正符号 パターン認識 データ圧縮 データベース デジタル署名 決定不能性 最初の二つのアルゴリズムのおかげでわたしたちは日々検索エンジンで有用な情報を入手できる。公開鍵暗号やデジタル署名のおかげで安全にインターネット上でクレジットカード情報などを交換できる。誤り訂
人月の神話を再読した。2013-02-03 - 未来のいつか/hyoshiokの日記
何度読んでもその度に発見がある。 大阪出張のおり、行きの新幹線（帰りは大抵へべれけで寝ているので本は読めない）でぱらぱらめくってみた。 再読するきっかけは、大槻さんからご著書を頂いたからである。「ソフトウェア開発はなぜ難しいか」では、「人月の神話」を題材に、普遍的な問題を改めて平易に解説する。多くの注と参考文献の説明がついていて、初心者にとって便利な読書ガイドにもなっている。 「人月の神話」の歴史的背景を言えば1960年代はメインフレームの時代だ。コンピュータ業界はIBMに支配されていた。支配という言葉はちょっときつすぎるように若い人は思うかもしれないが、圧倒的な存在感をIBMは持っていた。 大規模ソフトウェア開発の本質的な困難さというのが、OS/360の開発によって認識されはじめた。まだソフトウェア工学と言う概念も確立していなかった。 OSという極めて複雑で大規模なソフトウェアをどのよう
Continuous Deliveryを読む。2011-11-06 - 未来のいつか/hyoshiokの日記
同僚とContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))の読書会をやっている。 英語の本なので、一人で読むにはちょっと敷居が高くても何人かで読めばどうにかこうにか読了できるような気がする。きっかけとして読書会というのはいいメソッドである。 読書会のメリットは、わたしのようなものぐさでもある種のプレッシャーがかかるので、どうにかこうにか続けられるというのがあるが、それ以外でもいろいろある。 何といっても読書会のメンバー間では、言葉の定義というか概念について共通の理解が深まる。 前回レガシーコード改善ガイドを読んだとき、レガシーコードというのは、テストのないコードのことを言
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
達人プログラマーの思考法と学習法 - 未来のいつか/hyoshiokの日記
無理してベストセラーを読む必要はない。自分にあった本を自分にあったペースで読んでいけばいい。GW中に昔（1年くらい前）献本された「リファクタリング・ウェットウェア」を読んだ。 達人プログラマでお馴染みのAndy Huntの著書である。正直言って、この本のタイトルにぐっとこなかったので、本書を1年近く寝かせておいたのであるが（献本いただいた宮川さんすいません）、ふと思いたち、読んだ。面白かった。副題の「達人プログラマーの思考法と学習法」が本書の内容を的確に表現している。 情熱プログラマーを読みながらも感じたことなんだけど、プログラマーとして、どのように学ぶかという問題にはもちろん正解はない。だけど、人間は弱いものなので、そのような正解を求めて本を読む。様々な自己啓発書が本屋にあふれているのがその証拠だ。私自身、そのような自己啓発書の類の書籍にはあまり興味がないので、買うことも読むこともほとん
自分にとっての情熱プログラマー - 未来のいつか/hyoshiokの日記
先日、情熱プログラマー読書会が楽天であったので、参加した。LT(Lightning Talks)で発表もした。発表スライド 情熱プログラマー 自分にとっての情熱プログラマーってなんだろうと考えた。 この「情熱プログラマー」という書籍は、ソフトウェア開発者の幸せな生き方という副題がついているのだが、純粋な技術書というよりもプログラマーにとっての自己啓発書みたいな位置づけの書籍だ。 ソフトウェア開発におけるプログラマという役割を取り替え可能な部品のような立場から見れば、プログラマはコストであり、どのようにしてそのコストを削減するかということになる。コストを安くするという考えで行けば年功序列的な賃金体系の中ではベテランより若いひとを使った方が安く上がる。数字でソフトウェア開発を見ていけば人月工数がすべてであり、開発コストは工数＊人月単価になる。 そのような立場で言えば人件費の高い日本で開発するの
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか - 未来のいつか/hyoshiokの日記
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース（OSS）を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
2010-03-07
KCS(Keio Computer Society - 慶應義塾電子計算機研究会)という大学時代のサークルの50周年記念パーティに行ってきた。 同好会が50年も続くというのもすごいが、設立当初の先輩（60代半ば？）から現役の学生まで40数歳の年齢差のある人々が一同に会するというのもすごい。設立当時のお話も興味深いし、60年代のコンピュータのお話もめちゃくちゃおもしろかった。 日本IBM最高顧問の北城さんも先輩の一人なのであるが、学生時代GPSSの処理系を作られたというエピソードを語られていた。経済界の重鎮もプログラマの時代があったのである。 われわれ同期（1977年入学組）はしょっちゅう会っているのは、同期の浅井がゴルフコンペを定期的に開催しているからである。わたしはゴルフはしないが、定期的な連絡網の整備が、飲み会の情報の共有などとあいまって参加率の高さにつながっている。浅井さんには感謝し
東京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)
2010-02-14 - 未来のいつか/hyoshiokの日記
例えば、次の言葉の意味を知りたい、聞いたことがあるけどよく分かっていないプログラマにとって、お勧めの書籍だ。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
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
2009-08-22
セキュリティ＆プログラミングキャンプ2009のわたしの講義で、「オープンソースにすると企業は損をするんじゃないですか」という本質をとらえた質問がでて、講師陣が、いきなりいろいろ議論を始めた。 企業の行動原理は、利益の追求だから、利益を生まないアクティビティは原則として行わない。オープンソースも例外ではない。 利益＝売上-経費 なので売上が増えるか、経費が減るかという観点から投資判断をする。当たり前ですな。 例えばマイクロソフトが自社の製品をオープンソースにすると、売上が伸びるか、あるいは経費が減るかというと、どちらもそうとは言えないので、マイクロソフトが自社製品をオープンソース化することは考えられない。先日マイクロソフトがHyper-V向けのLinuxドライバをGPLで公開したことが話題になったが、Linuxドライバを公開する事が自社のHyper-Vの魅力を増し、売上向上を期待して公開した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
