WeBlowg Side

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

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

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

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

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

本書にも削ることの大切さを、有名な挌闘家の言葉を引用して説明しています。

 完璧とは何かを足せない状態になることではない。何も削るものがなくなった状態のことだ

大きな機能をゴッソリ削るのではなく、代替の熟れた技術を用いながら一部の機能を実現するなど、
うまく削っていくスキルがアーキテクトには必要なのでしょう。

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ヘッダーの一覧がとても役に立ちます。
これからずっとそばに置いておきたい本です。

約7年間お世話になった会社を辞めて、転職する事になりました。
同時に東京へ引越しすることになります。

私はシステム開発未経験でこの会社に転職してきました。
大学も情報系ではないのでプログラミングも未経験でした。
どんな事でも最初のハードルを越えることは本当に大変だと思います。

最初に参加したプロジェクトは、ウォーターフォール型の開発だったのですが、各フェーズを丁寧に行うプロジェクトでした。
(そしてきっちり利益もあげていました！)
今思えば、システム開発での最初のハードルを越える上で、一番良いプロジェクトに参加させてもらったと思います。
おかげで色々教えてもらいながら、システム開発がどういうものかを学ぶことが出来ました。
そして転職に際しても、本当に暖かく送り出してもらい感謝しています。

さて、今月からは有休消化を経て新天地になります。
これまでは業務システムを手がけてきましたが、今度からはコンシューマ向けのWebサイト開発です。
Webと言う点はこれまでも出掛けてきたのですが、コンシューマ向けと言う点は未経験です。
これからも勉強することがいっぱいです。

しかも職場は3年前に転勤して以来の東京です。
3年前と比べて、勉強会も随分ブームになってますし積極的に参加して行きたいと思います。

前職ではモーターのチューニングをやってました。
(「チューニングなんていやだぁ！モノ作らせろー」と転職したのですが)

そのチューニングってのが結構泥臭い事をやってて、モータを機械に取り付けて発振する限界まで応答性を高める設定値をトライ & エラーで割り出し、そこから安全率をかけた値を設定値にするようにしてたんです。
モータを取り付ける対象は何億円って機械なんで、その機械がエラい音をだして振動するのを見るのは、最初の頃は恐怖でしたね。
そして、その機械に何トンもの重りをのっけたり、下ろしたりといろいろ手間が多かったので、金額的にも手間的にも、大変なトライ & エラーでした。

そんな高価なトライ & エラーをやってきた経験があるんで、プログラミングでのトライ & エラーって行為は凄くお手軽なんですよね。
今のソフトウェア開発って何度でもお手軽に試すことができるけど、このお手軽さが考えることをなくさせている気がします。
これって自分だけなのかもしれないけど、もうちょっと考えてから手を動かすべきだと自省しています。
「手を動かす前にもう一度考えろ」を座右の銘にしているインフラ管理者がいたけど、この辺ってインフラ管理者に見習うべき所があるのかもしれないと思ってます。

テストファーストなんかは、ともすればトライ & エラーの連続になってしまうのかもしれないけども、
プログラミングをやる前にできるだけ完成形をイメージして、プログラミングに入るかってのが自分の場合重要な気がします。
全体を見渡せる目と、細部を見てきっちりテストしていく目をもてるかがポイントなんでしょうね。

5月に受けた第138回のTOEICスコアが発表になりました。

Toeicを受けることにしてから 2ヶ月ちょい。
やったことと言えば iknow の TOEICチャンネルをぼちぼちやって単語を覚えたのと、模擬問題を解いたぐらい。
当初は500点越えたらなぁとか思ってたけど、さすがに出題の方式は掴んでおこうとやってみた模擬問題が680点くらいいったので、 「目標700点」と調子に乗ってました。
そして結果は。。。。

645点(リスニング：315 リーディング：330)

途中、「目標700点」とかちょっと調子に乗っちゃったけど、まぁ私のこの程度の勉強量なら、こんなもんでしょう。
わかってはいたけどリスニングが苦手。
「そんなもん、ネイティブにどんどん話しかけなよ」と言われそうだけど(実際言われたけど)、やっぱりシャイなもんで。

点数もやっぱりきになるけど、今回TOEICの勉強をしながら覚えた単語が、英語の資料を読んだりしているときにでてくる事が結構あった。
こんな感じで試験勉強と自分の英語を学ぶ目的がかみ合ったので点数はともかく、プロセスは非常に満足している。
自分はなかなか覚えようとしないと身につかないもんなんで。

これからもどっしりとTOEICに取り組むことはないと思うけど、ゆるーい感じでちょくちょく受けたいと思う。

実はアンチUMLだったのですが、最近その必要性を感じます。
なぜアンチUMLなのかと言うと仕様と実装の間にワンクッション置くと言うのに違和感を感じたからなんです。

今まで頭で考えるときも、コミュニケーションをとるときも「なんちゃってクラス図」とか「なんちゃってアクティビティ図」でなんとかなってました。
お客さんに納品するならちゃんとしないといけないけど、技術者同士でコミュニケーションするのが目的なら、通じるなら「なんちゃって」でもいいかなと思ってました。
ただ、最近実装方針をいろいろ話し合う事が多くなってきたので、いよいよちゃんと書けるようになった方がいいのかなぁと。

モデリングと言えばER図なんかはよく見たけど、UMLって流行ってるのんでしょうか?
コミュニケーションである以上、UMLを使える人口が多くないとメリットが少ないし。

技術者同士のコミュニケーションと言えば、デザインパターンは勉強しといた方がいいと思う。
Facade, Composite Factory Strategy Proxy Singletonぐらい覚えといたら今のところ十分に感じます。
たまにFlyweightみたいに「それってパターンだったの？」ってやつもあるけど、そこまで覚える必要はないでしょう。

他の言語、特に関数型言語とかではモデリングやパターンってあるんかな？

昨日書いた内容なんですが、

わがままといえば 「10年は泥のように働け」って話を企業の方がされているそうで。
年功序列の終演を説く本をよんだりしてると、すごく対局にある感覚ですね。
わがままなんて許されない感じ。

見事に釣られてたようです。

パネラーの方の「10年は泥のように働け」の由来。
「泥のように働く」の元々の話がIPA討論会での意味合いと全然違っている
まず入社して十年間は泥のように働いてもらう 丹羽宇一郎さん 人間学を学ぶブログ 「こころは超臨界」
終身雇用にとらわれているって言う点は多少あるかもしれないけど、「10年は泥のように働け」の意味が大分ずれて伝わってしまってますね。
いわゆる「使い捨て」ではなくじっくり育てる熱意のある経営者は好感がもてます。この言葉の印象ががらっとかわりました。

他にも実際行ってきた方の感想。
IPAX 2008を見に行ってきた

後、IT Proも記事を出してたようでそれと比較しても大分印象が違います。
大手メディアによるIT業界ネガティブキャンペーン

情報の怖い側面が身に染みましたね。

「プログラマは入力を信じちゃいけない」って言葉は、私がこの業界に入りたてぐらいの頃に、
フリーランスをやってらした方がくれた言葉。
それから4年たった今でも、プログラムを組むときにはこの言葉を良く思い出します。

ここ数日、このブログが不安定でした。
RSSの出力もめちゃくちゃだったので、RSSリーダーで購読してくださっている方、
ご迷惑をお掛けしまいた。すいません。

どうして不安定だったかというと、日付解析の処理部分でロケールが正しく考慮できていなかったためでした。
開発機のロケールと、本番機のロケールが合っていなかったので、なかなか手こずりました。
入力チェックを丁寧にやっておけば、
ログの出力をもうちょっと丁寧に作り込んでおけばよかったと反省しています。

自戒の意味もこめて、私が考えるプロのプログラマとは。

• 入力を信じちゃいけない(入力チェック)
• 障害発生時の事を考える(ログとか例外処理)
• 想像力はたくましく

これらの事をきちんと考えるのが、プロのプログラマだと私は考えてます。

反省、反省。

del.icio.us Firefox extension v1.5が激しく便利な件 につられて試してみた。
ダウンロードはこちらから del.icio.us bookmarks 1.5

実は、一番最初に試したソーシャルブックマークは del.icio.us でした。
その後、 Google Bookmark へ浮気した経緯があります。
Googleツールバーから各Bookmarkへのアクセスが非常に洗練されてたっのが理由です。
del.icio.usがいちいちWebページにBookmarkを表示させてアクセスしないといけなかったのが、
なんともまどろっこしかったんです。

ショートカットキーも充実してます。
この操作性はキーボードショートカット大好きっ子にはたまりません。

• Ctrl + b でサイドバーに Bookmarkを表示
• Ctrl + d で見ているページをBookmark

さらに Auto Hide の機能を有効にすれば、使い勝手はさらに上がると思います。
Auto Hide は、Bookmarkをクリック後は、サイドバーを自動的に隠してくれる機能です。
Auto Hideの 有効/無効は、サイドバーの右上にある青いボタンでできます。

今回感心したのが、Google Bookmark も del.icio.us も、データの　import/export　が自在に行える点。
ユーザーとしては、いい機能があるサービスに気軽に乗り換えれます。
このまま囲い込みなんかせずに、切磋琢磨してくれれば、ユーザとしてはホクホクです。

5月のTOEICを受けることにした。
資格試験は一昨年にSun Java2の試験を受けて以来なので、かなり久々に資格試験を受けることになります。

思い起こすとIT業界ってやつに入る前、まったく異業種にいた頃に、
「基本情報に受かったら転職しよう！」と自分にハードルを設けて受けたのが、初の資格試験。
なんとか受かって、転職を果たしたけども、
基本情報を持っていた所でIT業界ではたいして役にたたなかった事に愕然として思い出があります。

そんなこんなで資格にいいイメージがなかったので、会社が受けろと言うから受けるって感じの、
非常に消極的な姿勢でOracleとかJavaとかを受けたりもしました。

今回、資格試験に消極的な自分がどうしてTOEICを受けたくなったかというと、
やはり自分の英語力を測りたかったから。
たまに英語のメーリングリストに投稿してみたりしてるけど、
一応それなりのリアクションがあるので、通じているみたいだし、
Gentooの翻訳で、全くのダメ出しってのも今のところなさそう。
というわけで、英語力を測ってみたくなった。

もちろん、技術系の英語とは違う部分があるんだろうし、
そもそも点数をとるには、英語力だけではなくて、
テストそのもののテクニックという部分も大きいんだろうけど。

iknowでちょこちょこ単語は勉強してたけど、
やっぱり受験というイベントがあると、英語の勉強にも身が入って単語も覚えられそう。

ちなみに7,8年位前に受けたときのTOEICのスコアは450点。
このスコアは越えたいな。