Geek-Side

<< < 1 > >>

Web API The Good Partsを読んだ


昔はWebAPIを作る事が多かったんだけど、ここ数年はすっかりインフラ寄りになって、機能寄りの設計をやらなくなってました。
そんな中に読んだのが、Web API The Good Parts
技術書の中にはかつての自分の成果物に赤面してしまう本が多々ありますが、この本は赤面度上位に位置しますね。

内容


大きく分けるとエンドポイント、レスポンス、HTTPへの準拠という点に関して細かいところにまで突っ込んだ考察を繰り広げてくれます。
実例なんかもあげてくれるので、理想と現実という部分にも配慮されています。

特に面白かった所


プログラマーならプログラミングをする上で変数の名付けというのには意識を向けるものと思います。
そういった名付けにも通じる内容なのですが、エンドポイントやレスポンスに関して、WebAPIの世界で改めて説明されると新鮮なものがありました。
あとは、最近インフラ屋として関わる事が多いHTTPプロトコルをいかに利用するかという内容。
インフラもアプリケーションも両方経験してきた中で、自分の中の溝を埋めてくれるものでした。

考えたこと


普段何気なく使ってるAPIですが、こういった設計の指針を包括的に提示してくれる本は本当に貴重ですね。
そして何よりも、自分のアプリケーションの知識が時代遅れになっていることを痛感しました。
Rest Level3って知らなかったなー、Martin Fowlerさん、こんなところにも出てくるんですね。

そして、こういったアプリケーションの設計に関する本も読んでおかないと、
その基盤であるインフラに何を求められているのか、どう使われているのか、おざなりになってしまうと感じました。

まとめ


冒頭に書いてある通り、赤面する事この上なかったです。
今後自分の関わるWebAPIはできる限り恥ずかしくしたくないものです。
とりあえず、今のプロジェクトでこの本で学んだことを発表しておきました。

アプリケーションエンジニアとインフラエンジニアの溝を埋めてくれる良書 「プロのための Linuxシステム・10年効く技術」


これまでアプリケーションエンジニアとして、Linuxをインフラとするシステム開発に何度も携わりました。
ただ、ある程度のシステム規模になるとアプリケーションエンジニアとインフラエンジニアは分業になることが多かったです。
ミドルウェアの構築にしても最低限の構築はやって来ましたが、レイヤの低いところはインフラエンジニアの方に頼る部分が多かったです。
また、JVMのパフォーマンスチューニングでもOSレベルのチューニングになるとインフラエンジニアの方に頼ることが多かったです。

本書はそんなアプリケーションエンジニアとインフラエンジニアの溝を埋めてくれる良書でした。
章ごとに独立している構成ですが、最初から読み進めることをお勧めします。

Linuxの内部構造を押さえる

第1章はLinuxの内部構造についてです。
内部構造とは具体的に言うと、Linuxのディスク・プロセス・メモリについての説明になります。
恥ずかしながらこれまではforkとexecの違いをきちんと説明できませんでした。
この点も誰もが通るログインの流れの中でわかりやすく説明してくれます。

またプロセスの調査方法については、コマンドラインの便利な使い方が載っており、思わず膝を打ちます。
まさに先輩エンジニアの作業を見て盗んだり、先輩エンジニアからあっと驚く豆知識を披露してもらったりという感覚をこの本からもらうことができました。

スクリプトあれこれ

これまでの仕事で大規模なスクリプトを書くことは無いですが、小さなバッチプログラムや自動化のためのスクリプトを書くことは数多くありました。
第3章ではスクリプトの書き方のコツを伝授してもらえます。
変数の展開などあやふやな知識だったところを強化することが出来ました。
サンプルも実践的でためになります。

kernelソースの読み方

この本を買った理由の半分は、この章が読みたかったからでした。
第4章ではカーネルソースの読み方を実際にソースを追いながら見ていきます。
うるう秒に対応しているかをソースから読み解いていくところは、実際のコードリーディングでプロは何を考えるかまで書いてあり、圧巻です。
最低限のC言語の知識と、若干のLinuxの癖を理解すれば、ここまでkernelソースが読めるもんなのかと感心しました。
この癖を見極めるのが超えられない大きな壁の一つなのかもしれないですけど、この本があれば高速道路を利用してkernelに近づくことができます。

最後に

そもそも家で使っているメインOSはGentoo Linuxなわけで。
自分の道具をこんなに理解できていないのは今まで悔しい限りでした。
少し霧が晴れた気がします。

ベストプラクティスの生き証人「Unixという考え方」




気がつけば我が家はUnix系と言われるOSばかりになっていました。
デスクトップはUnix系OSであるLinux(Gentoo Linux)、iPadのiosやノートPC(MacBook Air)のMaxOsXはUnix系OSであるDarwin、スマートフォンはLinuxをベースにしたAndroidOSで動いています。
これもUnixの定理の一つである移植性のなせる技なんでしょう。

本書はUnixに貫かれる基本方針をひも解き、ソフトウェアを作る上での定理を示してくれます。
本書にかかれている定理は、ネットや本でよく言われる事柄です。

例えば、「できるだけ早く試作を作成する」という定理は、動くソフトウェアを重視するアジャイルの考え方で謳われています。
「一つのプログラムは一つの事をうまくやらせる」という定理は、なんでも出来るクラスではなく、責務を限定してクラスを作るクラス設計の基本でも良く言われることです。
「ソフトウェアの梃子を有効に活用する」考え方は、車輪の再発明をするなという言い方でよく聞かれることです。

いわゆるベストプラクティスが書かれているわけですが、Unixにどのような良い影響をもたらしたのか、一つ一つの定理について事細かに説明してくれます。
これまで、上記の言葉を聞いたことがある方も、現在のUnix系OSの席巻と本書の内容で説得力がますと思います。

本書で一番しびれた台詞は
「ソフトウェアに完成はない、あるのはリリースだけだ!」
ってとこでした。
ソフトウェアはリリースした後もずっと手がはいる、だから変更しやすいコードを書くようにするんですものね。

アーキテクトは組み立てるだけでなくて削れないとダメ


間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 を読了しました。
中身を見ずに題名だけ見て購入しました。
今のプロジェクトでアーキテクチャが原因でプロジェクトの足を引っ張っているところがあって、
さらに間違いを重ねないような参考情報はないかと思っていた頃に見つけたのがこの本でした。
アーキテクチャのアンチパターンが載っているのかなと思ってたのですが、副題の方が内容を表してますね。
アンチパターンが主題ではなく、非機能要件を中心にアーキテクトの仕事の流れを説明した入門本でした。

この本は非機能要件をどのように定義していくかが主題となっています。
非機能要件を定義していく時に何をどう定義していけば良いかが書かれているので、この本を道標とすればスムーズに要件定義を進めれると思います。
今回のプロジェクトでももちろん非機能要件は定義していきました。
程度の差こそはあれ、この本に書かれていることはそこそこやってきていました。
プロセスは大きく間違っていなかったのです。

じゃぁ何が失敗だったか。
それは削らなかったことに尽きます。
機能的な面で削れるところを削らなかったり、知見のない技術をシステム構成から削らなかった反省があります。

今回のプロジェクトでは未知の技術を使用することから、要件定義期間中からプロトタイプのスケジュールがきちんととられていました。
本書でも要件定義でプロトタイプをしつこくやる事の重要さが説かれています。
やはりプロセスは間違っていないのです。
しかし未知の技術の数が多かったため、当然プロトタイプで検証すべき事柄が多くなり、十分深く検証が出来ませんでした。

削ると言っても機能的な面を削るのは難しい所で、クールな機能を並べた方がお客様に受けが良いのは当然だと思います。
そうやって風呂敷を広げないと仕事がとれにくいのは想像がつきます。
けどいったん風呂敷をひろげちゃうと、それをたたむのはなかなか難しいのがジレンマです。

本書にも削ることの大切さを、有名な挌闘家の言葉を引用して説明しています。
 完璧とは何かを足せない状態になることではない。何も削るものがなくなった状態のことだ
大きな機能をゴッソリ削るのではなく、代替の熟れた技術を用いながら一部の機能を実現するなど、
うまく削っていくスキルがアーキテクトには必要なのでしょう。

WEBを支える技術読了

HTTP、GET、POST、URI、ステータスコード、ステートレス。
Webの仕事にに関わっていて、これらのキーワードと格闘した事のない人はいないでしょう。
ステータスコードをGoogleで検索したり、ブラウザのプラグインでHTTPヘッダーを見ながらRFCを読み解いてみたりした経験は多くの人があるでしょう。
その時々に分かった気になっても、これらの技術を体系的に学ぶ機会は少ないのではないでしょうか。

そんなWEBにまつわる技術を体系的に学べる本が、「WEBを支える技術」です。
WEBを支える技術の歴史から始まり、いかにHTTPがシンプルに設計され、それゆえに広まっているかをひも解いていきます。
その過程でHTTP周辺の技術を学んでいく事ができます。

かつてWicketに始めて触れて、ステートレス/ステートフルを意識したとき、これらの概念を理解し人に説明するのに苦労したものです。
その時にお世話になった解説も載っていました。ステートフル/ステートレス の説明をはじめ、わかりやすい解説がつまっています。

この本の主役はRESTでもあります。
HTTP周辺の技術を解説するとともに、RESTがHTTPにいかにマッチした技術であるかという話に続いていきます。
RESTとSOAPの話は、個人的にはApache AxisでSOAPと格闘した日々を思いだしたりもしました。

最後のRESTを用いた場合のWebAPIの設計手法、考え方は非常に参考になります。
基盤技術の設計意図を注意深く汲み取り、下位レイヤーの思想を壊さない形で上位レイヤーを設計していく過程は感動しました。

本書でWebにまつわる技術を体系的に学んだ後も、充実した索引やステータスコード、HTTPヘッダーの一覧がとても役に立ちます。
これからずっとそばに置いておきたい本です。



時間管理本を読みまくってわかった事

子供ができたりすると、とにかく自分の時間というものがなくなるもので。
ふと思い立って、時間管理に関するテーマ読みってやつをやってみた。
読んだ本は以下の通り。
レバレッジ時間術
TIME HACKS!
無理なく続けられる年収10倍アップ時間投資法
時間の教科書
脳を活かす!必勝の時間攻略法
デッドライン仕事術
「なぜか、仕事が速い人」の時間管理術
エンジニアのための時間管理術

時間は投資するものと言う考え方と、時間は節約すると言う考え方があると思うけど、最近のトレンドはもっぱら「投資」のようです。
私は「節約」のような考え方しかなかったので「投資」の考え方は新鮮でした。
時間をお金で買う事でさらに時間を得、恒常的な時間節約のために時間を使って仕組みを作る。
そして如何に「やらない」事をきめて「やるべき事」に集中するかがどの本でも説かれています。

いろんな著者がいろんな角度から説かれていますが、以下に尽きるんでしょう。
  • 選択と集中
  • 習慣化
結構言い古された結論だけどね。

まず時間管理を真剣に考えるようになってテレビはほとんど見なくなりました。見ても「お母さんといっしょ」ぐらい。
おかげで藤崎マーケットとかえどはるみとか知らなかった。
でも飲み会で不自由なく楽しくできてるんで、この年になったらテレビってのは見なくて大丈夫そう。
昔はテレビ見ないと話についていけない何て事があったけど。
長期的な投資的という意味では、いい物を食べるようになりました。結構高いんですよね、有機野菜とか。
これは嫁の協力なくしては出来ないけど。
その他細々とした事について自動化や仕組み作りを楽しんでます。

それでももっと時間欲しいなぁと思っちゃうんですが。

2007年も終わりな今日この頃、ウェブ進化論読了

2007年ももうすぐ終わり。
この一年を振り返ってい見ると、
プライベートでは関東から関西へ引越し、娘の出産と、なかなか濃い一年だった。

仕事関連では、この業界に転職して5年目にして,最高の技術者とも出会うことが出来た。
また、今までバッチやクライアントサーバーシステムの仕事が多かったけど、
この一年はWEBアプリばっかりの一年となった。
おかげでWEBシステムの少し深い部分への取っ掛かりが掴めたと思う。

来年はボチボチやってるWebフレームワーク Wicketのコードリーディングを進め、
スクリプト言語を1個マスターしとくってのが目標かな。

で、こんな年の瀬にウェブ進化論を読了した。
大分今頃感があるけど、図書館に娘の絵本を借りにいったらたまたま発見したので。

少し古い本ということもあり、Googleの社風とかはよく聞いた内容。
Web2.0とか、オープンソースの有り様とか、普段何となく言葉は聞いてるけど、
きちんと説明できない内容の整理がついて良かった。

情報をオープンにするかどうかで、
ネットの「あちら側」と「こちら側」と言う議論が展開されているけど、
自分の立ち位置としては、やはり日本の多くの典型的な会社がそうであるように
ネットの「こちら側」なんだろう。
この本がかかれたのが2006年始め、それから2年弱がたったけど、
インターネットの「あちら側」は、アンテナを張っていると確実に進化している用に見える。
転じて一日の大半を過ごす「こちら側」の世界はあまり変わってないように感じる。

プロジェクトでWikiを導入してみたけど、あまり発展しなかったり、
会社でBlogを導入しても活発なやりとりに発展しなかったりと、
些細な事かもしれないけど「こちら側」には情報リテラシーが足りないと感じる。
こういうのが発展するのは、工夫も必要なんだけども、
そもそも情報共有に対するモチベーションが低かったり、
自分が発信した情報が淘汰されるのを恐れているのか、
情報の自然淘汰以前に情報の流通が起きていない。

「こちら側」にいる者として、何が出来るか。
2008年が始まる前に読めたのはラッキーな一冊だった。

Slack ゆとりの法則 読了

トム・デマルコの本は前から気にはなってたんだけど、
今の現場の人が「Slack ゆとりの法則」を貸してくださると言うことで、読ませてもらった。
2001年に初版なようなので、だいぶ遅れをとった感があるけど。

テーラーによる製造業管理手法がそのまま適用できない、
いわゆるホワイトカラーな仕事の特徴とその管理に関する論点は、
ダニエル ピンクの「フリーエージェント社会の到来」や、
P・F. ドラッカーの著書にもよく書かれている内容。
そこに本書のタイトルである「ゆとり」による変化の醸成をプラスして、
効率化の罪悪を突いていくところは、効率化という言葉に悪いイメージが一切なかったため、
なかなか衝撃的だった。

もう一つ、品質管理という言葉にも悪いイメージはなかったのだが、減点法による品質管理に終始して、
創造性から来る高品質を殺してしまう様を説明してくれる。

効率化、品質管理という今までマイナスイメージのなかった言葉に変わって
本書では効果的という言葉が強調されてる。そして効果的を狙うとリスクが立ちはだかる。

この本で感銘を受けたのは、上記を踏まえて、
いかにリスクを取っていくかと言う点をわかりやすく示してくれた所。
リスクを取るメリットとリスクを取らないデメリットを示し、
本当のリスク管理とは何かを示してくれる。
自分はこの本は「ゆとり」というより「リスクの楽しさ」に関する本だと感じた。

自分の周りの企業や、自らの生き方を深く考えさせられる書でした。