進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) に参加してきました
進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) - DevLOVE関西 | Doorkeeper
に参加してきました。
当日はKYな台風到来で、予定していたスケジュールを短縮しての開催となりましたが、色々と気づきや学びのある勉強会でした。参加出来てとてもよかったと思います。
「チーム開発をスムーズにするために何ができるか、してきたか」
チーム開発実践入門の著者である池田尚史(@ikeike443)さんの発表でした。池田さんは勉強会に参加することはあまりないそうですが（懇親会の席で伺いました。ちょっと意外）、わざわざ遠方からお越し下さいました。僕は縁あって、以前にもPlay Framework勉強会*1*2で一度お会いしたことがあり、久しぶりの再会でした。あの時はPlayのすごい人のイメージだったのですが、今ではチーム開発実践の大先生です。*3
発表内容はチーム開発でよくある課題とそれにどう対処するかという話から始まり、チーム開発実践入門２章のケーススタディーのような、実経験に基づいたチーム改善の事例紹介でした。とても実践に富んだ内容でした。
発表内容の一部を紹介すると、
チーム開発にベストプラクティスはない。ケースバイケース。その時々の状況にあわせることが重要。
チーム開発の課題としては、
- プロジェクトの目標があいまい
- プロジェクトの成功や価値が不明確
- リスク管理が出来ていない
- チームがうまく機能していない（パフォーマンスが発揮されていない）
という状況が多く、これに対処していく。
言い換えると、
- ゴールはどこか？
- 決めるのは誰か？
- 利益は出るのか？
- リスクは見えているのか？
- チーム開発はうまくいっているのか？
といったことを念頭におき、
- 方法論はどんなものを使うか？
- コミュニケーションプランをどうするか？
- 成果をどう測るか？
- チームビルディングはどうするか？
- 開発ツールはどう使うか？
をチーム開発を始めるにあたって考えるとのこと。 特に「チームビルディングはどうするか？」で話されていた、
「キャラも大事。全員モヒカンばかりではチームがうまく回らない。プロジェクトのマネージャーも必要だし、やさしい人も厳しい人も必要。また人どおしの相性も重要」
という話は僕も同感です。技術ばかり優秀なメンバを集めてもチーム開発はうまく行きません。様々な能力を持つメンバーが自分の得意を活かして、一人では成し遂げれないことをするのがチームであり、組織に所属する利点だと思います。
また、「ツールを組み合わせればチーム開発の課題が解決するのか？実際上手くいくのは、実践し続けている人のみ」という話がありました。その後の事例紹介の中でも、ツールは導入されていたが上手く使いこなせていないという話があり、あくまでツールは人をサポートするものであり、大事なのは個々人のスキルとコミュニケーションなんだと実感しました。
事例紹介ではチーム開発実践入門には述べられていない、「某ソシャゲー会社」の事例紹介があって面白かったですww。どこまで話していいのかが分からないのでここでは触れませんが、色々と考えさせられました。
まとめの中であった、
- 管理しない。「管理する」の発想だと管理者のレベルを超えたものは産まれない。シナジーを重視する。
- 「やれ」と言われたことをやるよりも、自ら「やろう」と考えたことのほうがパフォーマンスが高い。
という言葉は、心に響きました。
最後に、チーム改善をダイエットに例えて、
- ダイエットが続かない理由はダイエットを始めるから！
- 「課題があるから解決しよう」ではなく「課題がなくなるような習慣をつくろう」というアプローチが成功の鍵なのでは？
という問いかけは面白かったです。チーム改善は良い習慣が大事で、それを続けるのが難しい（ダイエットと同じですね！）ということがすんなりと理解できました。上手いメタファですね！
チーム開発よろず相談部屋
その後、チーム開発よろず相談部屋にて、「情報共有」について話し合いました。話し合いで得た内容としては、
- 情報は蓄積より検索が重要でそれをうまくやるのが難しい
- タバコ部屋のような気軽な情報交換できる場を用意する
- 不特定多数への情報発信ができる場を用意する
- 定期的にミーティングを開く
という話を得ました。また、情報共有に使うツールとしては、JIRAやBacklog、Github、IRCというキーワードが挙っていました。
顧客との情報共有に関しては、顧客側から情報共有してほしいという要望があり、Backlogの導入がすんなり実現したという話も聞けました。社内からこのような働きかけをするのは難しいですが、外部圧力なら簡単に話が進むな〜と関心しました。
また、席を移動して「人材育成」について周りに伺いましたが、どこの現場も育成に関しては苦労しているみたいでした。
- コードレビュー
- 社内勉強会
- ペアプロ
というキーワードが挙げられていましたが、それぞれの育成効果は異なるので、ここら辺を組み合わせることが重要だと感じました。あと、経理やサポート、営業の人たちに初歩的な技術の勉強会を開くという話があり、それは面白い！と感じました。
懇親会
勉強会の楽しみのひとつは懇親会ですw。もちろん酒が飲めるいうのがありますが、懇親会では勉強会で聞けない裏話が聞けたり、突っ込んだ技術討論が出来たりと、実は勉強会よりも得るものが多かったりします。ちょっと禁酒していたので、飲み過ぎてしまいましたww。皆さん、お付き合い頂きありがとうございました！！
おまけ
実は今回はLTをする予定だったのですが、台風でお流れになりましたw。ってことで、幻の資料をここに上げておきます＾＾
この資料の内容は、実践出来ていることもあれば、出来ていないことも多いです。今自分が問題だと思ってて、今後このような改善が現場で必要だという内容を書きました。
ここで得た内容を少しでも実践出来ればいいな〜と思います。
皆さんありがとうございました！！！
チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)
- 作者: 池田尚史,藤倉和明,井上史彰
- 出版社/メーカー: 技術評論社
- 発売日: 2014/04/16
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (6件) を見る
*1:play framework 勉強会 in 関西の悲劇 その後。。｜システムアーキテクトのごった煮
*2:第一回 Playframework 勉強会 in 関西に行ってきたよ！ - ikeike443のブログ
*3:当日はチーム開発実践入門の本を持ってくるのを忘れてサイン貰いそびれました。無念。。
アジャイルAPI設計時代の到来！？APIデザインの極意を読みました。
「プログラミング言語Java」「Effective Java」などの翻訳で有名な、柴田芳樹さんの新たな訳書である「APIデザインの極意」を読みました。
APIデザインの極意 Java/NetBeansアーキテクト探究ノート
- 作者: Jaroslav Tulach,柴田芳樹
- 出版社/メーカー: インプレスジャパン
- 発売日: 2014/05/23
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
「APIデザインの極意」は、NetBeansの生みの親で、初期のアーキテクトであるJaroslav Tulach（ヤロスラフ・ツゥラッハ）が著者で、NetBeansの開発で得た経験や教訓を纏めたノートが元になって書かれた書籍です。
従来のデザインパターンでは解決できない、後方互換性を維持しながらライブラリを発展させる設計手法について書かれています。
読んだ感想としては、GoFのデザインパターン本のような体系だった内容というよりは、後方互換性を意識した設計手法が必要となる背景や理由、API設計者としての思想や態度に重点がおかれているように感じました。
本書の難易度はかなり高めだと思います。読み解くにはJavaをある程度習得している必要があります。「Effective Java」の内容を理解でき、デザインパターンの知識が身に付いた中級者が次に読む本だと思います。
なお、1章は哲学的な話が続くので、読みにくく感じるかも知れませんが、2章以降はシステムよりの話になるので技術者にとっては読みにくさはなくなるかと思います。
なぜ新たなデザイン本が必要なのか
序章でも述べられていますが、様々なデザイン本が出ている中、なぜ新たなデザイン本が必要なのでしょうか？
その答えは、本書の中にある、
今日のシステムは、巨大なビルディングブロックで構成されています。
にあると思います。
僕は最近のシステム開発はまるで、「レゴブロックの組み立て、もしくはパズルのピース合わせのようだ」と感じています。様々なフレームワークやライブラリが提供する一部のAPIを組み合わせ、または拡張し、それらをブラックボックスとして使用します。
以前、ソートのアルゴリズム名を知らないプログラマに驚いたことがありますが、幾多のライブラリを導入し、ブラックボックスとして使用する僕とそのプログラマの違いは何だろうと疑問を感じたことがあります。そして、このような開発手法にも若干の違和感を抱いておりました。
本書ではこの状況を以下のように述べています。
21世紀の最初の10年間に構築される平均的なシステムは、その裏側にはなんの優雅さがない、あってもわずかしかない巨大なゴミの山のようなものです。そのようなシステムを構築する主な動機は、常に最小限の努力で成し遂げることです。そのために、エンジニアリングチームは、既存のソフトウェアフレームワークが必要以上であっても再利用しようとします。
自分の知識や経験を踏まえて今後のシステム開発のあり方を考えた場合、このような開発手法は今後もますます拡がっていくと想定しています。
僕らは「何をしたいか」に注力し、大きなビルディングブロック上で自分がしたい”わずかな”拡張を実装することでそれを実現することになるでしょう。これを実現する為には、ユーザーがソートを実現したい時にそれを実現する方法を簡単に発見出来て、（具体的なアルゴリズムを知らなくても）それを呼び出すだけで最適なアルゴリズムによりソートした結果が得られるAPIが必要となります（本書では、そうした状況を選択的無知と呼称しています）。そして、APIを提供する設計者は、ユーザーの投資を無駄にせずに発展できるような設計、つまり後方互換を維持できるAPI設計が重要となります。
今までのデザイン本ではこのような手法については述べられていませんでした。
それが著者が本書を書いた動機であり、今後の開発者が本書から学ぶべき内容だと思います。
本書は400パージ程度の一般的なボリュームの技術本ですが、1ページあたりの内容が濃く、全てを端的に纏めることは不可能です（むしろ、著者が纏めた結果が本書のページ数です）。ですので、ここでは本書の概要と、中でも僕が感銘を受けたいくつかの内容について紹介したいと思います。
本書の概要
序章で述べられていますが、
が本書のテーマです。
- 純粋に芸術的な設計よりは多少エンジニアリング的設計を好むすべてのAPIアーキテクト
が本書の想定読者層となっています。
第1部では、本書で述べる語彙が定義されています。
第2部では、具体的なAPIの設計手法
第3部では、API設計者としてうまくやっていくための助言が述べられています。
本書は精読が必要な部類の本であり、第1部から順に理解しながら読んでいくことをお勧めします。
本書の内容の抜粋と感想
1章、2章では、この本の重要なテーマである「選択的無知」について説明されています。
「無知」という言葉は一般的に侮蔑や軽蔑を含むイメージがありますが、本書ではこのような「攻撃的な意味」では使われていません。
車や携帯電話については仕組みを全く気にしないで使っています。
車を運転するために車の設計を理解したいと思わないでしょう。歯を綺麗にするために科学を理解する必要はありません。
何を深く知り、何を深く知る必要がないかを積極的に選択することを意味しています。
目標は、開発者がすべてを知らなくてもよいコーディング方法を見つけることです。すなわち、開発者が必要な知識を選択することです。私は、それを選択的無知と呼びます。
と本中で述べられているように、優れたAPIは無知であることを選択できます。
また、
無知モデルは、世界中のソフトウェアプロジェクトから集められた大きなビルディングブロッグを使用することに基づいています。
と本中で述べられていますが、今日のシステムはより大きく、そしてより複雑になっています。昔のように、限定された単一環境上で画面入力をファイルに読み書きするだけのシステム開発はほとんどなく、複数の異なるベンダーが提供するOS、データベース、アプリケーションサーバーを利用し、様々なフレームワークやライブラリを組み合わせ、各所に分散されたシステムと協調して機能を実現するのが今日の一般的なシステムの姿です。そして、そのようなシステムでは、様々なAPIが他のAPIに依存し、ツタのように絡み合い、複数のAPIが異なるバージョンの同一APIを使用するというややこしい状況が普遍的に発生します。
このような状況下において、これらのAPIを組み合わせて効率よくシステムを設計・開発し、更にはエンハンスしながら健全に保つには、
- 無知な状態を選択出来ること
- 無知な状態で居られること
に気を使うことが、今後ますます重要になると思います。
それを実現するには、無知な状態でAPIを導入・使用でき、そしてAPIが後方互換性を保ちながら健全に発展出来る設計手法を学ぶことが重要になってきます。
3章、４章では、APIに焦点をあてた内容が説明されています。
について述べられています。
「API」は、それ以上に広範囲な意味を持つ用語であり、他の多くの種類のインタフェースを含んでいます。
と本中にあるように、一般的なプログラマが想像する以上のものがAPIに含まれます。
それは一般的に想像する「メソッドとフィールドのシグネチャ」のみではなく、環境変数や標準出力やログ、振る舞いといった広範囲なものがAPIに含まれます。標準出力までもがAPIとして扱われることには驚きましたが、Unixのコマンドの使い方を考えると、すごく納得できました。*1
ある変更がユーザーを「びっくりさせる」のであれば、それはAPIとして含まれるということになります。
APIの品質検査方法については、API設計者はもちろん、APIユーザの視点でも学んでおくことが重要だと思います。
ビルディングブロックの上で効率よくシステムを開発する為には、APIを設計する以上に、より良いAPIを探し出し、評価し、使用することが重要なスキルになります*2。
API導入の善し悪しがシステム開発から保守・エンハンスまで、システムのライフサイクル全体の品質に影響します。APIを一度導入すると、そのAPIはアプリケーションの一部となり、今後の保守対象となります。導入するAPIの習得コスト、発展性を評価し、「投資の保全」が保てるよう、APIの品質検査方法を押さえておく必要があります。
余談 ①
以前、とある勉強会で「Jenkinsがすごい後方互換の維持を頑張っている。その為に、Javaのバイトコードにパッチをあてるなど、黒魔法的なことをしている。」という話を聞きました。NetBeans開発でも同様の手法がとられていたことが本書でも記載されており、なんというかSunの後方互換に対する遺伝子のようなものを感じました。またJenkinsはユーザーの「投資」に真摯に向き合っているのだな〜と感動しました。
- ソース互換性
- バイナリ互換性
- 機能互換性
が挙げられています。
特に、機能互換性については考慮が漏れがちです。
のような理由で機能互換性を失う改修をすることがありますが、そのような改修はAPIの提供範囲によっては大きな影響をもたらします。
APIの提供範囲により、「どこまで」後方互換を保つかのレベルは変わると思いますが、後方互換のレベルを知り、それを保つ為の設計手法であったり、保ったまま発展させる方法を知識として押さえておくことは重要だと思います。
余談②
すこしうる覚えですが、以前、とあるORMapperの設計者がTwitterで「nullをパラメータに渡されたときに、"is null"を指定されたように設計変更しようかどうか」を悩んでいたのを見かけたことがあります。結局、その設計変更は他のフォロアーの「そのような変更はオプション指定で行えるようにしてほしい」という意見で見送られたみたいですが、大変興味深い内容でした。この会話内容には、本書の後方互換性の改修に対する最適解が含まれています。
第2部では、具体的なAPIの設計手法が述べられています。
- 御託はいいから具体的な設計手法を知りたい
- とりあえずコードを読みたい
といった開発者にとっては、第2部からが楽しい内容になると思います。
5章、6章では、APIが後方互換性を維持しながら健全に発展できる為の具体的な手法がJava言語に特化して述べられています。特に僕が感銘を受けた内容*3は、
の2点です。
「不変型を指定するためにJavaインタフェースを使用する」については、Java8でインタフェースにデフォルトメソッドが導入される経緯となった理由を理解する上でも面白い内容だと思います（更に言えば、Java8以降についてはこのデザインパターンもデフォルトメソッドの出現で再考が必要となります）。
「メソッドを安全に追加できる型としてfinalクラスを使用する」については、オブジェクト指向の代名詞と言われる継承に対する否定でもあり、とても面白い内容です。継承は「無知」をサポートするには難しい言語機能であり、ユーザの拡張方法が多岐に渡るので、後方互換の維持も難しくします。また、容易にソースをスパゲティ化することも出来ます。JavaではCompositeパターンが言語レベルでサポートされておらず、それを実現するには「もっさり」したコードを記述する必要がありますが、それでも本書を読んで、APIとして継承のサポートは出来るだけしないほうがいいように感じました。
8章ではJavaのWriterを例として、Decoratorパターンの発展問題と、それに対処する方法が述べられています。Decoratorパターンは僕が好むデザインパターンの1つであり、美しさを感じていたのですが、APIの発展性を考えた場合には大きな問題点があることに驚きました。APIは使用者向けと提供者（サービスプロバイダー）向けに分けて提供することの重要性、そして、コアな部分とサポートの部分に分けて提供することの重要性が理解出来ました。
9章では、テストについて述べられています。テストについては本書の中で心に響く文章があったので紹介しておきます。
テストは病みつきになるという私の主張にみなさんが同意しないかもしれない唯一の理由は、みなさんが試してみたことがないということです。
仕様書は時代遅れで、少なくともそのように思えます。...実際、テストは非公式な仕様書の一部となり、公式な仕様書がないことに対する埋め合わせとしての役割を果たします。
また、テストをサポートするテストAPIを提供することの重要性や、テスト互換性キット(TCKを提供することの重要性が述べられています。
10章では他のAPIとの協調においての注意事項が述べられています。他のライブラリのAPIをほとんどそのままのシグネチャーで公開する、再エクスポート(re-export)を行った場合の発展性への影響などが述べられています。
11章では、API実行時の側面について、スレッドを意識した話が多く挙げられています。特にスレッド周りのテストではいつも苦労するのですが、本書ではログを使用したクールなテスト手法が紹介されており、とても興味深い内容でした。
12章では、宣言型プログラミングについて述べられています。特に、「オブジェクトを不変にする」の節で述べられている、
宣言型プログラミングの力は、高いレベルの概念を定義し、低いレベルで何が起きるかの詳細を正確に指定させるのではなく、高いレベルで指定させることができるのです。
関数型言語の時代が来たら、コーディングは突然、さらに美しくなり、はるかに優雅になり、常に安定していて真実は永久に変わらない幾何学のようでしょう。それまでは、私たちのAPIの一部を少なくとも不変にすることで、来るべきその時代を感じることができます。
については、選択的無知や後方互換性の観点からも、今後APIはより関数型プログラミングに向いて進化することを彷彿させました。
第3部では、API設計者としてうまくやっていくための助言が述べられています。
特に、13章の有害で極端な助言については、API設計者は一度目を通しておいたほうがいいでしょう。
僕の場合で言えば、「APIは、正しくなければならない」の節で述べられている、
Javaでディスクからファイルを読み込む方法が異常に「面倒」と思っているのが、私だけではないと確信しています。
の一文がAPIを正しく設計するだけでは良い設計といえないということを実感をもって理解できて面白かったです。
余談③
Java7ではFileを簡易的な扱うjava.nio.file.Filesが提供されておりますが、本来はFileの追加メソッドとして提供されたほうがより利便性が良かったと思います。
そうならなかったのは、広く使われているだろうFileクラスがfinalでなかったことが原因だったのではないかと推測しています。
個人的には、3部では17章のAPI設計フェストが一番面白かったです。
本書を読む方は17章で設計フェストに挑戦し、本書の内容が身に付いているかを実感して欲しいと思います！*4
まとめ
先に述べたとおり、本書は内容が濃く、全てを端的に纏めることは不可能なほど示唆に富んだ内容が豊富に述べられています。
ライブラリを開発して世に広めようとしている意識の高い技術者、ライブラリを導入して"上手く"システムを開発しようとする技術者のいずれにとっても本書の内容は有効なものになるでしょう。
世の中のライブラリが「選択的無知」を活用し、"下手な"APIがより多くの死者を生み出さない為にも、是非本書をより多くの優秀な技術者の方が読み解き、そしてその設計手法を広めていって欲しいと思います。
APIデザインの極意 Java/NetBeansアーキテクト探究ノート
- 作者: Jaroslav Tulach,柴田芳樹
- 出版社/メーカー: インプレスジャパン
- 発売日: 2014/05/23
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
- 作者: ケンアーノルド,デビッドホームズ,ジェームズゴスリン,Ken Arnold,David Holmes,James Gosling,柴田芳樹
- 出版社/メーカー: 東京電機大学出版局
- 発売日: 2014/05/10
- メディア: 単行本
- この商品を含むブログ (3件) を見る
EFFECTIVE JAVA 第2版 (The Java Series)
- 作者: Joshua Bloch,柴田芳樹
- 出版社/メーカー: 丸善出版
- 発売日: 2014/03/11
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
DevOps時代の必読本？「チーム開発実践入門」を読んだよ！
「チーム開発実践入門」を読了しました。
チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)
- 作者: 池田尚史,藤倉和明,井上史彰
- 出版社/メーカー: 技術評論社
- 発売日: 2014/04/16
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
4/16の発売日に購入して役一ヶ月、相変わらず本読むスピードが遅いので嫌になります。読了後の感想としては購入当初の想定どおり、今の自分に必要な本だったと感じました。チームメンバ、そしてソフトウェア開発に携わる全ての人達に読んでほしいなと思います。
早く行きたいなら一人で
「早く行きたいなら一人で、遠くへ行きたいならみんなで行け
（If You Want To Go Fast, Go Alone. If You Want To Go Far, Go Together）」
アフリカのことわざです。個人プレーが好きな僕でもグッとくる言葉です。
どんな天才であれ時間は有限であり平等です。
「人間50年、下天のうちをくらぶれば夢幻の如くなり」
という一説は信長で有名ですが、SIer風に表すと
「人間600人月 大規模開発期間にくらぶれば夢幻の如くなり」
とでも表すのでしょうか。
現代ビジネスのスピード感で価値あるシステムを素早く市場に提供するには、チームで協力して開発するしかありません。好き嫌いに関係なく、ITで仕事をするということは、チームに所属するということです。
本書ではチーム開発を進める上でのベストプラクティスのヒントが多数記述されています。
まずは2章を
この本の価値を知りたければ、まずは2章を読んでみることをおすすめします。本日も至る所で繰り返されているだろう、開発現場の悲惨な現状を垣間みることが出来ます。
おそらく、2章を読んで
「こんな現場あるはずないだろう〜w」
というあなた！
自分の幸せを噛み締めてください。そして、周りの先輩への感謝も忘れずに！
だいたいの人は
- 苦笑する
- トラウマを感じて震える
- なぜ俺の現場を知っているのだ？
という感想を抱くでしょう。
2章を読んで心震えた方は、3章以降を読んで現場を改善しましょう！
3章から具体的な実践方法
3章以降は
- バージョン管理
- チケット管理
- CI
- デプロイの自動化
- リグレッションテスト
と続きます。後になるほどよりチーム力は強化されますが、導入難易度もあがるのでこの順番で導入を検討していくのがいいでしょう。実践の言葉どおり、それぞれの考え方のみならず具体的なツールの使い方が記述されています。
人間は道具を使うことで進化してきました。開発においても、いかに良いツールを使いこなすかが重要だと思います。*1
この本のいいところは、各ツールの特性と他のツールとの比較や連携方法などを説明しており、自分のチームにあったツールの選択の助けになるところだと思います。逆に、ツールのインストール方法や詳細な説明は他の書籍を参考にする必要があります。
チーム開発はSIerこその課題
僕は過去に大手SIerで常駐、今では自社で請負の開発に従事しています。その経験からも、ツールを活用したチーム開発はSIerの大きな課題と考えています。
SIerは大きな資本金を背景に、大規模システムを一人では到底仕上げれない期間で開発するお仕事です。そのため、開発チームは急造かつ大人数という特性があります。
その中で、
- 要求/要件/課題/品質の管理
- スケジュール/タスク/納期管理
- 品質管理
- 質問管理
- コスト管理
- 変更/バージョン管理
- 構成管理
といった様々な管理をチームリーダーは行う必要があります。*2
今までの開発では、Excelなどの表計算ソフトにより手作業によりこれらの管理作業をカバーしてきました。大規模チームで人のリソースは豊富にあるので、開発時はマンパワーでどうにか賄うことも可能です。
しかし、このような属人性に依存した管理方法は時間経過と共に必ず崩壊します。*3
「チーム実践開発入門」にはそういった崩壊を防ぐヒントが多数記述されています。
人らしいお仕事を
現時点でも人はコンピュータより優れたリソースであり、貴重なリソースです。
機械に出来ることは機械にやらせ、人間にしか出来ないことに注力したほうが幸せだと思います。この本はその為への道しるべにもなると思います。
あ、みんなの役立つかもしれないからハンドサインを貼っとくね！(((o(*ﾟ▽ﾟ*)o)))*4
January 2014 in Action
気づくと今年も12分の1を過ぎて2月。時間が経つのが日ごとに早くなってるように感じます。今年の目標は未だにふわっとしてますが、出来れば今月中にはきちんと考えてブログ化したいと思います。
とりあえず、今年からは月毎の活動をブログに残すことにしました。今年の抱負で決めた「流」の一環です。活動をブログ化することでアウトプットを意識した行動が出来るのを期待してと、自分自身の振り返りにも役立つかな〜と考えてです。
今年の抱負の「変」のとおり、少しずつ色々変えました。
まずは生活の時間配分を変えました。今年に入ってからは朝5:30起きて、スタバで朝モクを開始しています。朝は頭も冴えているし、のんびりと自分の時間を持てるのでこの習慣は気に入っています。また、6:31に最寄り駅始発が電車があることに気づき、朝の電車に座れていい感じです。朝早く起きると自然と夜も早く寝るので、一般的にゴールデンタイムといわれる22:00〜02:00の間の睡眠も多く取れて、睡眠時間が減った割には体調はかなりいいです。ま〜、ちょっと最近体調崩しましたが、これはあきらかに飲み過ぎですな。ノンアルコール生活を続けたら、大分回復しました。
また、最近MBAを買いました。このブログも早速MBAで書いていますが、なかなかキーボード操作もろもろ慣れないです^^;
早く使いこなしたいですね。
では、1月の活動です。
勉強会で「KnockoutJS勉強会」に参加しました。
http://connpass.com/event/4548/
JavaScriptは個人的にはあまり好きな言語ではないのですが、Webというフロントエンドの地位を確立し、周辺に様々な面白いプロダクトが出てきています。今年の目標としてJavaScriptの勉強は視野に入っています、というか、積読になっていた「パーフェクトJavaScript」で勉強を始めています。
朝モクで「Play Framework徹底入門」を読了して書評を書きました。
http://kozake.hatenablog.com/entry/2014/01/31/224029
書評って難しいですね。でも、書評ってアウトプットを意識していたので、いつも以上に集中して読書できた気がします。
今後は読んだ本は書評を書いていってもいいな〜とか考えています。
その他、通勤電車の中で「Team Geek」を読みました。HRTはいいですね。僕も過去の失敗をみるとこの精神が欠けていたように思います。
この本も近々書評書きたいです。
今年の抱負の「楽」ですが、ちょっと楽しい成分が不足していますね。「つらみ」が多いです。やっぱりもっと楽しいことしたいな〜。ここら辺はもう少し反省して、楽しい成分を取り入れていきたいですね。
ま〜、ドラクエモンスターズは始めたけど、あまり楽しくないww
ってことで、ざっくばらんですが１月の活動はこんなもので。
２月は楽しかったと思えるように頑張りたいです！
【献本駆動】「Play Framework2 徹底入門」を読んだよ！
@kara_d さんから「Play Framework2 徹底入門」を献本頂きました！とても嬉しかったです！
Play Framework 2徹底入門 JavaではじめるアジャイルWeb開発
- 作者: 掌田津耶乃,原一浩
- 出版社/メーカー: 翔泳社
- 発売日: 2013/12/17
- メディア: 大型本
- この商品を含むブログ (3件) を見る
その時の喜びよう
Play Framework2徹底入門の献本頂いた(((o(*ﾟ▽ﾟ*)o)))
ありがとうございます！ pic.twitter.com/AOq0pzi4Nk
— 小酒信一 (@s_kozake) 2013, 12月 21
早速読んで書評を書こうと思いましたが、読むスピードが人より遅いのと、かなりのボリューム量だったこともあり、読了まで時間がかかりました。読んだ感想は、すごい面白かった＆楽しかったです。
Play Framework2（以下、Play）は今流行のRailsライクなJavaとScalaのフルスタックフレームワークです。
Playに関しては、以下の理由で今年の注目技術だと思っています。
・今年の流行？
今年に入って日経系雑誌でやたらScala押しの記事を見かけます。そのScalaの本命フレームワークとして、Playが紹介されています。
ちなみに、「Play Framework2 徹底入門」はJava版です（9章にはScala版の簡単な説明もあります）。「なんだ、Java版か」と思った方もいると思いますが、後述の理由から本書は十分読む価値があると思います。
・SIerはフルスタックフレームワークの導入が必須
なにかと世間をにぎわすSIerですが、SIer界隈ではシステムアーキテクト、上級プログラマという人材が不足しています。ええ、それはもう圧倒的に（みんなWebとかソーシャルに流れちゃうからね）。
そのような状況下でSIerに残る身としては、フルスタックフレームワークの存在は大変ありがたいです。藁にもすがる想いです。フルスタックフレームワークを導入することで、アーキテクトの仕事はかなり軽減します。
フルスタックフレームワークの代表といえばRuby on Railsを思いつくでしょうが、Ruby技術者はこの界隈にはあまりいません。
「そんなことないよ」という皆さん、それはあなたのTLだけの話です。
Scalaについては、「Scala is 何？」です（最近は大分マシにはなったかも知れませんが）。
・SIerにはJavaのフルスタックフレームワークが必要
SIerはそのビジネスモデルのため、チーム体制が流動的です。大規模プロジェクトの終了はチーム縮小を意味し、次のプロジェクトが受注できると短期間で体制を整えなければいけません。その点でJava技術者は揃えやすいです。
よって、Java言語による開発が行われやすく、Javaをサポートしたフルスタックフレームワークは魅力的です。 更に言うと、そもそもRFPで「開発言語はJavaで」と指定されていることもあります。
若干悲観的な意見が多いですが、それだけではありません。Javaも進化しています。
今年はJava界隈で注目のJava8がリリースされる予定です。ラムダをサポートするなど、Javaも遅ればせながらも最新の言語技術を取り込んで来ています。Java8やGuava、Lombokなどのライブラリと組み合わせることで、まだまだJavaでも十分生産性の高い開発が行えると考えています。
「Java脱却やで！RubyやScalaのほうが生産性が高いんやってな！10倍やで！」という上層部の皆さん、皆さんが脱却しないといけないのはCOBOLとCOBOL文化です。本気で生産性を考えるなら、現場にCIサーバーをそっと渡してあげてください。喜ばれますよ！
その他にも色々理由がありますが、まとめて列挙すると、
- Playは日本のコミュニティの努力もあり、日本語情報が豊富*1で、習得が比較的容易です。有志のコミュニティ*2もあります。急造チームのメンバのスキル習得コストを考えると、技術習得が容易なことは必要条件です。
- モデル層はEbeanをサポートしているが、他のORMに容易に切替が可能。レガシーDBとの戦いはSIerには日常茶飯事です。モデル層を簡単な変更できることは魅力的です。
- SIerに忍び寄るクラウドの波。Playはクラウドと相性のいいF/Wです。
- SIerにとってセキュリティ対策は必須。Playはセキュリティまわりもしっかりサポートしてますよ。
という理由で、SIer各位にも本書をお勧めしたいと思います。PlayはWebやソーシャル界隈の「あちらの技術」ではなく、SIerにとっても魅力的な技術ですよ！
では、長々と本筋から離れてしまいましたが、本書の書評です。
・「Play Framework2 徹底入門」の書評
徹底入門という名前のとおり、入門から実践的な内容まで幅広いです。
「ヒープメモリが不足した場合の対処」や「コンソール文字が文字化けした場合の対処」、「Herokuへのデプロイ時の注意」など、実際に使っていく上で当たるだろう問題についてもColumnで言及されています。
1~3章はPlayの基本が丁寧に説明されています。実際に動かしながら学べるので、Playをはじめて導入するチームの教育資料として良いのではないかと思います。
4章からは実践編です。僕は4章が一番読んでて面白かったです。
「4章 アプリケーションの企画と設計」では実際にPlayでアプリケーションを企画、設計する上での進め方や注意点が述べられています。
企画時の注意点として、サーバーの規模やCookie、セッションの扱いなど、Play独自の注意点が述べられております。また、Play向きの企画、不向きな企画、開発環境や運用環境についてなどの注意点も記載されておりますので、実際にPlayをプロジェクトに導入検討する際は、必ず読んでおいたほうがいいでしょう。
設計では、一線で活躍する@kara_d さんの思想を垣間見ることが出来て、すごい参考になります。
要件はViewから、設計はモデルからという開発の進め方は、僕たちのチームも同じ方法を採っています。このほうが要件のずれが防げるし、設計がしっかりするんですよね。
「5章 MVCの実装」からは実際に小さな診断アプリを作っていくことで、開発を擬似体験できます。本章にも書かれていますが、サンプルソースを見ながら本書を読み進めたほうがいいと思います。僕はSublime Textでソースを見ながら本書を読みました。
WebJarsを使ったフロントエンドのライブラリ管理やBootstrap3を使ったデザイン、Twitterシェアボタンなどなど、Playと併用する技術を用いたモダンなWeb開発を経験できます。
ただサンプルソースの内容を説明するだけでなく、その設計にした理由が論理や経験に基づいて説明されており、開発を通して著者と会話している気分になります。
「え、ロジックはモデルでしょ？」という疑問の答えが次のページに記載されていたり、「どんだけOption好きなんだよｗ」と一人で突っ込みながら読んでいました。
「6章 共通処理とAPIの実装」では、実際に業務で必要になる、ログ、バッチ、エラーハンドリングなどの地味な技術についても記述されています。また、単体テストや社内環境、本番環境など、複数環境での環境設定ファイルの運用方法などについても記述されております。
世の中には運用面をまるで考慮していないシステムがあふれており、SIerの保守・運用で大量の技術者の阿鼻叫喚を聞いてきた（時には僕も叫んできた）僕としては、このように運用面についてきちんと記述されているのはうれしいです。
最近のWebアプリでは必須といえるAPIの実装についてもしっかり記述されています。
「7章 テスト・デプロイ・管理」では、テストやデプロイ方法について記述されています。個人的に嬉しかったのは、CRUDの説明です。著者作成のCRUDツールの説明がされています。実際のシステム運用では、データパッチを当てるシーンは少なくありません。すみやかにCRUDが作れる仕組みはうれしいです。
「8章 Play Tips」では、セキュリティについてしっかりとした記述があります。個人的にはSSLの導入も欲しかったなとは思います。また、認証まわりの仕組みがしっかり書かれているのはうれしいです。実際のシステムで認証がないシステムはほとんどないですからね。
ActorとWebSocketまわりは上級編のイメージを受けました。Actorまわりの説明が不足しているので、ここら辺は別の書籍でしっかり学ぶ必要があるかと思います。
最後に、エンタープライズシステムでは重要なトランザクション制御やSQLの直発行などについても記述があります。これは重要ですからね！
「9章 Scalaによる開発」では、JavaプログラマのためのScala入門とScalaによるPlayアプリケーションの作成が記述されています。
この章だけでJavaプログラマがScalaに移るのは難しいと僕は感じました。Scalaはコップ本で勉強しましょう！ただ、本章はScalaをやったことないJavaプログラマに、「こういう世界もあるよ」といういい入り口になると思います。
・注意点
長々と書きましたが、如何でしょうか？僕は1系メインでやってきましたが、そろそろ2系の導入に踏み切ってもいいような感じています。
ただ、Playには中毒性があるので皆さん気をつけましょう！
（過度の依存性から抜け出すためには、4章を読み直しましょう！）
・まとめ
- SturutsをラップしたオレオレF/Wを今でも使って現場を苦しめてるアーキテクトのみなさん！自重して最新のF/Wを使いましょう！Playは楽しいフレームワークですよ！
- 昔とった杵柄のJavaプログラマさん、最新のJava環境に触れてみましょう！昔プログラマで活躍したからといって、今のプログラマの気持ちが分かるとは限らないですよ！
- アーキテクト不足に悩んでいるSIerのマネージャー各位！息のいい若手にこの本を渡しましょう！会社経費で渡すと喜ばれますよ！
ということで
「いつやるの！？」「(ry」
Play Framework 2徹底入門 JavaではじめるアジャイルWeb開発
- 作者: 掌田津耶乃,原一浩
- 出版社/メーカー: 翔泳社
- 発売日: 2013/12/17
- メディア: 大型本
- この商品を含むブログ (3件) を見る
*1:Play Framework日本語サイト: http://www.playframework-ja.org/
*2:日本Playframeworkユーザー会: https://groups.google.com/forum/#!forum/play_ja
2014 in Plan
あけましておめでとう！
という時期もあっという間に過ぎもう既に1月が半分終わろうとしています。
ここら辺で今年の抱負を書いておかないとずるずるといきそうなので、2014年の抱負を書いておこうと思います。
今年のテーマは３つ。
「流」「変」「楽」
流
今年は流れを意識して、考え、行動していきたいと思います。清流が綺麗なのは流れがあるからです。流れのないものは濁り、よどんできます。「吐いて吸う」。これが生きる基本です。去年はインプットに偏りすぎていて、アウトプットが足りていなかったように感じます。また、人生にもよどみを感じてきていますので、流れを意識した行動を心掛けたいと思います。
特にアウトプット。アウトプット駆動で頑張りたいと思います。
目標としては、自分なりのコンテンツを作成していきたいなと思います。
変
新しいことをしていきたいと思います。技術であり、生活習慣であり。ようするに今までの行動を見直し、変えていく。新しい行動をしていきたいと思います。
「今までと同じ考えや行動を繰り返して、異なる結果を期待するのは狂気である ～アルベルト・アインシュタイン～」
「人間が変わる方法は３つしかない。１番目は時間配分を変える。２番目は住む場所を変える。３番目はつきあう人を変える。この３つの要素でしか人間は変わらない。最も無意味なのは『決意を新たにする』ことだ。 ～大前研一～」
とあるように住む場所を変えることはなかなか難しいですが、時間配分や新しい人との付き合いなどが出来ればいいな～と思います。
とりあえず、ブログをAmebaからはてなに切り替えました！
今後、技術ブログはこちらで書いていこうと思います。
楽
「楽すれば、楽が邪魔して楽ならず、楽せぬ楽がはるか楽々」
という富山の薬売りの言葉があります。
楽しようとすれば楽しようという想いが邪魔して楽になりませんよ。楽せず楽しんですることが楽ですし楽しいですよ、という意味です。
「楽したい」という想いが文明を発達させてきたと考えている僕としては、「楽しない」という考えはあまり賛同できないのですが、楽しいことをして、結果楽しようようという考え方はいいなと思います。
僕ももう人生半ばまで来ています。楽しいこと、やりたいことが何かを考えて、出来ることからやっていきたいなと思います。
まずは、前々から行きたいと思っていた離島やしまなみ海道への一人旅や、プロダクト作成とか。お金や時間に限りがあるので、出来ることからやっていきたいと思います。
あ、あとドラクエ10も2.0が出たことだし、それもクリアしなければｗ
今年のテーマは以上です。
これを元に、去年の反省も加えて今年の目標を練りたいと思います。
