UNIXという考え方読んだ

誕生日に id:aereal さんに頂いた本。ありがとうございます!

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

たいへん有名な本。原著は1994年に書かれていて、古典という感じ。

大きな一枚岩のソフトウェアよりも、cat、sort、uniq、sedやawkのような小さくて便利なツールを組み合わせることが好まれる。UNIXの世界には、こういった、UNIX開発者やユーザがが大事にしている哲学があり、そのおかげで、この本が書かれた1994年、そして現代においてもUNIXが広く使われることになった。この本では、そういったUNIXの考え方のエッセンスの部分を9つの定理にまとめてとして詳しく教えてくれる。

  • スモール・イズ・ビューティフル
  • 一つのプログラムには一つのことをうまくやらせる
  • できるだけ早く試作を作成する
  • 効率より移植性
  • 数値データはASCIIフラットファイルに保存する
  • ソフトウェアの挺子(てこ)を有効に活用する
  • シェルスクリプトを使うことで挺子(てこ)の効果と移植性を高める
  • 過度の対話的インタフェースを避ける
  • すべてのプログラムをフィルタにする

いくつか、おもしろかった部分をピックアップしてみよう。

第一のシステム、第二のシステム、第三のシステム

"できるだけ早く試作を作成する"について説明してくれる3章で説明されている第一、第二、第三のシステムの話が特におもしろい。曰く、人間にはこの三種類のシステムしか作れない。

第一のシステムは、一人もしくは少人数が、時間に追われる中で創造性を発揮し、勢い良く作ったシステムだ。時間追われたために、足りない機能もあるが無駄はなく効率的に動く。第一のシステムまったく新しい考え方を導入するので、はじめは世間には相手にされない。

しかし、第一のシステムが成功しはじめると、多くの人が集まってくる。そして、第一のシステムにより有用性が証明されたアイディアをもとにした新しいシステムが作られる。これが第二のシステムだ。第二のシステムは第一のシステムに目をつけた多くの参加者からなる委員会が機能を決定する。その結果として、多くの人の意見を取り込みすぎため、機能は多いが、無駄のある遅いシステムができあがる。多くの人に期待された第二のシステムは時には商業的にも成功するが、実はあまり役に立たない。

第二のシステムの失敗に反省した人々が、第三のシステムを構築する。第三のシステムだけが、第一のシステムが発見したアイディアと第二のシステムの中で見つかった必要な機能をバランスよく取り入れて、やっと役に立つシステムを構築することができる。

UNIXの考え方では、なるべくはやく第三のシステムを構築するために、すばやく試作することをおすすめしている。直接、第三のシステムをつくることはできないのだ。

必ずしもこうだと言い切れるものではないだろうが、実感としては同意できる。よくできたと思えるソフトウェアが一度にできることはない。イテレイティブな開発が現代のアジャイル開発手法では推奨されているけども、1994年の時点でもこのような話があるのはおもしろい。

ソフトウェアに完成はない

ソフトウェアには常に改善の余地はあるのはもちろんだし、時間的な制約などでそのソースコードは必ずしも最高の状態が保たれているわけではない。曰く、ほとんどのソフトウェアは妥協の産物だ。完成することはなく、ただリリースがあるだけだ。

ソフトウェアや計算機が常に進化していることを意識しなければならない。UNIXの考え方はソフトウェアの進化にも強い。ソフトウェアを小さくてシンプルな部品に分割すれば、将来の変更に容易に対応できるし、ソフトウェアを容易に移植可能にしておけば、来年には利用できるようになる、よりはやい計算機でも簡単に動かすことができる。

この話もまったく納得するはなしで、ソフトウェアを常に進化する流動的なものとして扱うというのは、現代でもホットな話題だが、普段利用しているUNIXにもその考え方が息づいているというのも面白い。

シンプルなソフトウェアのコンポーネント化手法

小さなソフトウェアを組み合わせる方法がシンプルであることもUNIXでは重要だ。UNIXではパイプを通じたプロセス同士の通信の仕組みがあって、多くのソフトウェアがこのシンプルなインタフェースに準拠してる。第8章ではMHを例に複雑なメールアプリケーションが、40近くのコマンドの連携によって構築できることを示している。

ソフトウェアコンポーネントのように、ソフトウェア特定の機能群を部品として使う方法を標準化して、それらを組み合わせるだけでアプリケーションを構築できるようにするというアプローチはいろいろある(CORBAとか)が、大成功している例はあまりみない。たぶん気楽に試すには難しすぎるのではないかと思う。

UNIXのプロセス同士をパイプでつなげて通信する方法は、ソフトウェアコンポーネントほど複雑なことはできないが、そのシンプルさ故にアプローチとしては成功している。これくらいシンプルだと、ちょっと自分でも試してみようと思うし、シンプルなわりに強力なことができてしまうので、人気がでてエコシステムも潤う。バランスの妙という感じで真似できるならしたい。

まとめ

この本は、UNIXをお手本にしたソフトウェア工学について書かれた本だとも言えると思う。古典だが現代に通じる考え方が多くて参考になる。UNIXに慣れ親しんでいるひとは、あらためて読む必要はないかもしれないが、よくまとまっているのでポイントを整理するのにも良い。うすいしすぐ読める。

ときどき時代背景がわかる記述があるのもおもしろい。CD-ROMが今後のソフトウェア業界を大きく変化させるであろう、だとか当時の時事ネタを楽しめるのもおすすめ。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

はじめてのClojure読んだ

はじめてのClojure (I・O BOOKS)

はじめてのClojure (I・O BOOKS)


nyampassの登尾さんの著書ということで読ませていただいた。URL短縮Webアプリケーションの実装を通じて、Clojureの基本や開発の方法を一気に学べる本。

全体としては、内容がすごく丁寧にかかれているので読みやすい。この本で特に良かったのは、Clojure界でのWebアプリケーション作成がすぐに開始できるようになっているところだ。例えば、Clojure界におけるWSGI/Rack的なものであるRingについてや、Leingenと連携した開発フローなどについて、簡潔に説明されていて、Clojure界のいまどきのWebアプリケーション開発手法に効率良く入門できる。

新しい言語を学ぶときは、文法や機能について知りたいのと同時に、その分野で流行っているライブラリや開発環境なども知りたいのでとても助かる。

一方、Clojureの言語自体のくわしい説明はあまり多くないので、言語自体に興味がある場合は別の本も読んでみたほうが良さそうだった。Clojureの本はあまりしらないけど、7つの言語 7つの世界にはloopの文法やSTMの解説がのっていた。

まず手を動かしてClojureでWeb開発をしてみたいという場合に読むととても良さそうな本だった。にゃんぱす〜

カラフルFizzBuzz

f:id:hakobe932:20140611222819p:plainなんかかわいいような気がする。Clojureの入門に書きました。

f:id:hakobe932:20140609223757p:plain

括弧の色の感じとか、縦に揃ってる感じとかそういうのです。

u (id:ujihisa)

1, 2など数字部分の出力もできるようになる修正を行うと聞いて

まじだ!! これははずかしい!

f:id:hakobe932:20140610003857p:plain

まとまりが悪くなった気がするのが残念。

f:id:hakobe932:20140610091728p:plain

うむ

空文字列ではなくnilでよいとのこと!

f:id:hakobe932:20140611222819p:plain

情熱プログラマー読んだ

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

誕生日に id:shiba_yu36 さんにもらった本。ありがとうございます!

ソフトウェア開発者が、たいくつしない幸福な人生を送るためのヒントを、コラム形式で解説してくれるという内容の本。コラムは53個くらいあって思ったよりボリュームを感じる。

本書では随所で、ソフトウェア開発のメタファが使われている。本の構成自体も、ソフトウェア開発者を1つの製品だとみなした時に、どのようにその製品を社会に対して売り込んでいけばよいかという観点によるものになっていて、大きくは以下の5つの章からなっている。

  • 第一章 市場を選ぶ
  • 第二章 製品に投資する
  • 第三章 実行に移す
  • 第四章 マーケティング... スーツ族だけのものじゃない
  • 第五章 研鑽を怠らない

この本が良いのは、各コラムの最後に必ず"今すぐ始めよう!"というコーナーがついていて、コラムで紹介されたアドバイスを元に具体的に何をすればよいかがのっているところだ。

例えば、"8 スペシャリストになろう" というコラムは、ちょろっとかじっただけではない、その道に深い知識を持つ真のスペシャリストになるべきだという内容だ。このコラムの"今すぐ始めよう!"コーナーでは、自分のつかっているプログラミング言語の実行環境(たとえばJavaならJVM)について詳しく学んでみることを提案してくれる。イイハナシダナーで終わらずに、具体的な行動に移しやすくて参考になる。

おもしろいコラムはいくつかあったけど、印象に残っているものの1つが "47 ロードマップを作る"というコラムだ。ソフトウェアのように自分という人間のロードマップを考えることで、軌道をはずれていないか、着実に前進しているかの目安が得られるだけでなく、自分自身の全体像を把握できるようになるらしい。そして、たくさんの機能をまとまりなく組み合わせたソフトウェアが役に立たないのと同じで、むやみにスキルを学ぶのは得策ではなく、ロードマップによって全体像を踏まえた上でその一部分について学んでいるという風になれば、より高い成長が得られる、とあった。

自分もわりと技術をつまみ食いしがちなので、全体的な方向性みたいなのがあると、効率よく勉強できるようには思う。新しいライブラリを勢い良く作りまくれるタイプだとか、開発プロセスにくわしいだとか、標準仕様に異常に明るいとか、周りにはいろんな方向性をもったエンジニアがいるけど、自分はどのタイプかと言われるとよくわからない。いいロールモデルみたいなのを見つけたい。

全体的に意識高めでちょっと読むのがたいへんだけど、とりあえずポジティブな内容なので、ソフトウェア開発者としてがんばるぞ!という気分になれるのは良い。説得力もあるので、"今すぐ始めよう!"のコーナーの内容を1つか2つ選んで実践してみたい。

君にはほかにいろいろな職業を選ぶ道もあっただろうが、この仕事は面白い。クリエイティブな仕事だ。<<中略>>

ソフトウェア開発は、やりがいがあって、しかも報われる仕事だ。芸術活動のようにクリエイティブでありながら、具体的で数値化できる価値を生み出せる。
ソフトウェア開発は楽しい!

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

大学で公演してきた

所属していた学部が10周年ということで、1期生の人たちは今どうなっているかというパネルディスカッションに出演させていただいた。

情報理工学部10周年イベント 「あいちゃれ×みらい塾 次世代グローバルIT人材を生み出す非常識と常識」 | Facebook

基調講演の高須賀さんのお話がたいへんおもしろくて、ハードルが高い状況でトークが開始されたものの、自分はともかくパネラー方々がみなめっちゃ個性的なこともあって、中々おもしろいセッションになった気もする。

聴衆の多くは現在学部に通っている学生さんが多かったので、話題が自然と学生さん達へのメッセージになったのだけど、みんな口をそろえて言ってたのは、何かしら好きなことを見つけてのめり込むと良いということであった。

こう書くと意識高いみたいな話になってつらいものの、自分がめっちゃおもしろいと思っていることをやり続けるのは、モチベーションを維持しながら修行して能力を高めるのに大変効率が良い。その結果として良い成果が出たり、お賃金をいただけたりして、どうにか幸せになれるのであれば、そんなにうれしいことはないという話。

パネラーの人たちはそれぞれ勢いのある成果があって、そういう人たちが一斉に好きを貫け!とか言っていたら、学生さんにとっても、まぁまぁ迫力があったような気もする。

振り返ると、自分も、プログラミングやインターネットおもしろいとか言っていろいろやっているうちに、今の仕事を楽しくやらせてもらっているのがある。わりと雑に選択肢を選んできたこともあるものの、なるべくおもしろさを損なわないようには選んできたつもりで、今のところモチベーションもなんとか運用できてる。なんとか運用しているという風では良くないので、もっと効率良くはしていきたい気はしてる。いい感じの成果を得てモチベーションを高めたいけど、それはがんばるしかない。いい感じの成果についてはひとでくんも何やら書いてた(■ - hitode909の日記)

ともあれ、イベントに呼んでいただいて、おもしろい話も伺えたし、同期ががんばってる様子もわかったし、わかものといろいろ交流することもできて良かったです。ありがとうございました。

わかもの向け情報: 何かしら好きなことを見るけるのに便利なインターンシップがあるのでどうぞ。

「はてなサマーインターン2014」を開催します - Hatena Developer Blog

さっき見た夢

風吹きすさぶ海岸にて:

  • かつての生徒: 「先生、僕のこのブランチ。 マージしてくださいませんか...?」
  • マスター先生: 「...」
  • 刑事: 「先生! もういいでしょう。今が大事なときなんです。どうかこのブランチをマージしてくださいよ。あなただってそうすれば良いことくらい、わかってるんでしょう!?」
  • マスター先生: 「...」
  • マスター先生: 「刑事さん、わしゃあいつでも言っているでしょう...」
  • マスター先生: 「わしのレビューにかなう、最高の品質のコードであれば、いつでもマージすると!!!」
  • (マスター先生の気迫に、たじろぐ、かつての生徒と刑事)
  • コーディング探偵: 「ふふっ、なるほど、そういうことでしたか。ならばそのブランチ、私が引き受けましょう!」

ピープルウェアを読んだ

この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。

ピープルウエア 第3版

ピープルウエア 第3版

  • 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
  • 出版社/メーカー: 日経BP社
  • 発売日: 2013/12/18
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (6件) を見る

この本は、作者のトム・デマルコさんとティモシー・リスターさんが10年に及んだ調査と、自身のソフトウェア開発の経験をもとに、ソフトウェア開発における人に関する問題をたくさんのコラムを通じて教えてくれる。冒頭には以下のようにある。

実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。

いろんなレイヤにおける人の問題についてそれぞれ章がわかれていて、個人からオフィスやチーム、さらには会社組織のはなしへと続く。結構マネージャー視点ぽいコラムが多い気がする。

以下、いくつか記憶にのこった部分をピックアップしてみた。

うまくいっているチーム、うまくいっていないチーム

21章 "全体は部分の和より大なり" によると、チームが結束し同じ目標を向くことできると、大きな力を出すことができるようになるという。チームが結束しはじめると、一体感がでてきて、よく一緒にご飯をたべにいったり、チームにしかわからない冗談を言い合ったりするし、他のチームとは違う選ばれたものだ、という雰囲気を醸し出したりするそうな。

バグを見つける喜びのもとに結束したすばらしいテストチームの例がおもしろかった。ありとあらゆる入力をプログラムに与えてはバグを見つけてはチームで大喜びして、プログラマを泣かしていたらしい。陰険なイメージを強調するためにチームメンバーは、みな黒い服を着てくるようになったそうで、そこからブラックチームと呼ばれていたそうな。彼らは独自の個性により結束した、社会的にうまくいっていたチームだった。最終的には、これまでに見つけられることのできなかった幾つものバグを発見することができたらしい。

自分も、確かにリリース時にクラッカーを鳴らすチームや、折にふれてお寿司の出前をとって慰労会を行うチームを見たことがある。たしかに、それらのチームは結束した良いチームであったように思うので、この話にはなんとなく納得感があっておもしろい。

また、結束したチームを作る簡単な方法はないが、台無しにする方法というのはあるらしく、23章 "チーム殺し、7つの秘訣"という章に書かれている。例えば、製品の品質削減を命じられる(例えば、雑でいいので急げと言われる)と、メンバーは自分たちの仕事に誇りをもてなくなり、結束は失われ、別のチームへの脱出を考え始めるとある。

人がやめないようにするという話

いくつかの章に、人が退職した場合におこる問題について言及されていた。客観的な視点で書かれていて良い。

19章 "ここにいるのが楽しい" では概算でも退職によってかかるコストは人件費の20%にあたるとあって明らかに無駄だと述べてる。また見えないコストとして、退職率の高い企業ではメンバーが長期的な視点を持てなくなるし、雰囲気が悪化して負のスパイラルに陥ってしまうことがあると書かれている。

逆に、退職率の低い企業では、メンバーは長期的な視点ができるようになる。長期的な視点のもとでは、組織をなるべく根本的に良くしようという力がはたらき、共通の方向性のもとで強く結束しやすく、より良い組織になることがあるらしい。

また、35章 "組織の学習能力" では、組織の経験をもとに、組織全体に技術を浸透させたり、組織を再編成したりといった、組織自体の学習能力について述べている。ここでも、"組織の学習能力は、どの程度人を引き止めておけるかで決まる"と書かれている。

さらに、退職率には目を背けがちだが、きちんと分析することで良い組織を目指せるというようなことも書いてあって、なるほどと言う感じ。

電話、電話、また電話

トム・デマルコさんはとりあえず電話がきらいで、電話が最悪だというだけの章(11章 "電話、電話、また電話")がある。電話が存在しないパラレルワールドに、とつぜんにグラハム・ベルがあらわれて電話のプレゼンをするんだけど、そんないつでも作業を中断してくる道具はいらないといって追い返してしまう。電話はたしかに異常で、人間同士が面と向かって会話していた時でも、ベルがなると電話のほうが優先されたりする。

フロー状態のエンジニアの作業を簡単に中断してしまってよくないので、電話をデスクにおかないか、電話をとらなくても良いという制度にすると良いとあった。

自分は、これまで電話のあるオフィスで働いたことがなくて、平和。

まとめ

ソフトウェア開発における人の問題について、漠然と感じていたことが言語化されて整理された良い本だった。具体的な例ものっていて納得感はあるし、読み物としてもおもしろいので、おすすめです。

ピープルウエア 第3版

ピープルウエア 第3版

  • 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
  • 出版社/メーカー: 日経BP社
  • 発売日: 2013/12/18
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (6件) を見る