『しょぼちむにおごって僕が金欠になるかどうか』をプログラミングしてみた！
この記事は しょぼちむ Advent Calendar 2014 5 日目の記事です。
しょぼちむ Advent Calendar 2014 - Adventar
昨日は なかけん さんの しょぼちむを使ったお手軽WebGL体験｜猫まっしぐら でした！
しょぼちむとは確か2回ほど会ったことがあります！可憐でかわいい女の子でしたよ＾＾しょぼちむとは年末の忘年会でも会う予定だから、今から楽しみだ！
普段から「かわいい女の子には奢っちゃうぞ///」宣言しているから、この状況でおねだりされるとおじさん、金欠がデッドラインになっちゃうな～ｗｗ。
・・・
あいつ本物か？
というのも、実はネカマのおっさんで僕が会ったのはバイトの女子大生という噂も絶えません。ツイッターを見てても、可憐な女子の発言とはとうてい思えない！
お、おっさんには絶対に奢らないからな！！
やばい、結局金欠になるのか、ならんのか分からなくなってきた。
ということで、『しょぼちむにおごって僕が金欠になるかどうか』をプログラミングして求めたいと思います。
まずは可能性をあらわすクラスを用意します。世の中は選択肢で溢れています。 選択肢の型はジェネリック型にして、様々な選択型を扱えるようにします。また、選択には確率がありますので、確率を小数点*1で現します。
しょぼちむ Advent Calendar 2014 のソース(可能性)
次にしょぼちむの正体とその可能性を考えます。
僕が会っていたしょぼちむはバイトの女子大生の可能性が高いです。ということは、今度の忘年会にもその子が来る可能性が高いでしょう。ってことで、確率を60%として0.6で現します。もしかすると忘年会ということで、ネカマのおっさんがくるかもしれません！ようおっさん！はたまた、実は本当は普通の二年目女子SEかもしれません。全く知らん人かも、、おまえ誰だ？
まじレッドキングだったらどうしよう。。
しょぼちむの正体の可能性をStreamで現すことにします。Streamとは遅延評価可能な値の集まり、つまりリストです。そしてリストとは非決定性を持った値の集合、つまり可能性ある値の集合なのです。
しょぼちむ Advent Calendar 2014 のソース(しょぼちむ)
次に支払いの可能性を考えます。支払いは「おごり」と「ごち」と「割り勘」が考えられます。バイトの子がきたらおじさん奢っちゃうかも///。おっさんがきたら、謝罪と賠償を求めます。レッドキングだったら、まじどうしよう。。
それぞれの確率にしょぼちむの正体の確率をかけることで、入力の確率に対しての割合を加味して返します。
しょぼちむ Advent Calendar 2014 のソース(支払い)
最後に、支払いの結果、おこづかいのダメージ具合を考えます。奢ったからといって、即金欠になるかどうかは分からないからな！ （その逆もしかり）
しょぼちむ Advent Calendar 2014 のソース(おこづかい)
可能性の条件は揃いました！
flatMapで処理を連結してcollectで確率を求めます。flatMapを用いることで、「ある値に対して考えうる可能性を返す関数」を連結出来るんです！*2
しょぼちむ Advent Calendar 2014 のソース(Main)
そして実行結果
{金欠だ～ヽ(；▽；)ノ=70.0, 金ならあるんだ！！(((o(*ﾟ▽ﾟ*)o)))=29.0}
やばい、70%の確率で金欠やで～～。。
人生は選択の連続であり、選択の結果が人生です。若いというのは可能性の宝庫です。これから様々な選択をしていくことになると思います。慎重にかつアグレッシブな選択をしていき、自分が楽しいと思える人生を選択していってくださいね＾＾
若いっていいな～ *･゜ﾟ･*:.｡..｡.:*･'(*ﾟ▽ﾟ*)'･*:.｡. .｡.:*･゜ﾟ･*
ではこの辺で！バイナリ〜( ´ ▽ ` )ﾉ
明日は mike_neck さんの syobochim/gistにプルリクを送った結果ｗｗｗｗｗｗｗｗｗｗｗｗｗ です！
*1:金額の計算をBigDecimalで！[http://togetter.com/li/738592]
関西Kotlin勉強会に参加したよ
関西Kotlin勉強会に参加してきました！！
様子はここら辺をみれば分かります！
関西Kotlin勉強会で発表してきたよ〜 - 算譜王におれはなる!!!!
KotlinでJAX-RS + おまけ
http://backpaper0.github.io/ghosts/kotlin-jaxrs.html#/
うらがみさんの発表はKotlinでJAX-RSをやるってお話でした。
テーマを決めてその技術を検証するってのは、本当にその言語の「出来る／出来ない」がはっきりしてきていいな〜と思いました。あとうらがみさん、Kotlin詳しすぎで凄い！！
一日前にKotlin初めて触って、資料作る所だけ学んだ僕とは姿勢から違いました。。
見習いたいと思います！
JAX-RSの話が一通り終わると、Kotlinが出力するバイトコードの検証からモナドをKotlinで実装する話と、一気に参加者を置いてきぼりモードに。。うらがみさん、怖い。
別件ですが、JAX-RSのブログの更改してくれるみたいです。期待しています！！（俺得なので）
Nullなのはいけないと思います！
僕の発表です。この勉強会の前にScalaMatsuriでたろうさんと初めてお会いして、そこでLTやる宣言したので作りました。Kotlin知らないのにw
Kotlinに関しては、Nullを安全に扱える仕組みがある言語ってのは知っていて、そこが言語機能としてすごく好きだったので、そこに絞って資料作りました。
ただ、もう少しきちんと整理してお話出来るようになりたいですね。
勉強がNullなのはいけないと思います！
たろうさんの発表
たろうさんの発表。今までの資料からKotlinの面白い所の話をたくさんしてくれました！
僕は既存オブジェクトを拡張できる拡張メソッドが好きでしたね＾＾
また、AndroidをKotlinで実装するライブコーディングも見させて貰えましたし、大満足です。Kotlinはモダンな言語機能を備えてて、とてもいい言語だと思いました。
あと、自分のコードみて悩んでいるたろうさん、かわいかったです、本当。
懇親会
神戸で飲んで、大阪で飲んでとかなりの時間飲んでましたww
本当に楽しい時間でした！ありがとうございました！！
Scala Matsuri 2014に参加しました！
Scala Matsuri 2014に参加しました！
Enjoy.scala ! 日本最大級の Scala のカンファレンス - ScalaMatsuri
ちょっと忙しくてブログ書くのが遅れました。楽しかったです＾＾
今回の参加は勉強目的ではなく、Scala界隈のトップレベルの人達が集まるイベントに参加したかった、その空気を感じたかったという完全に個人的な趣向です。去年、参加出来なかったのが悔やまれたので、今年は参加出来て本当によかったです。
Scala Matsuriの内容はニコ生で中継されていましたし、資料も公開されています。ScalaMatsuri で検索すれば、色々な記事が出てくると思うので、僕は感想だけ。この記事読んでも得るものありませんよ！！
1日目
S-1 、S-2、B-1、B-2、A-3、B-4、B-5、B-6、B-7、B-8あたりに顔を出しました。
個人的には、B-1のGitBucketとA-3のPlay vs Node.js の話が一番印象に残っています。
普段、ツイッターで絡んでいる東京勢の方とお会い出来て嬉しかったです。
GitBucketはちょっと使いたいな〜と思っていたので、ローカル環境で立ち上げてちょこちょこ触っているから余計に印象に残ったのでしょうね。また、竹添さんの話し方がとても面白かったのと、GitBucketで使っている技術とかが興味深くてよかったです。
Play vs Node.jsについては、LinkedInの中の人が色々なフレームワークを検討しているって話が面白かったです。その中でもPlayはいいフレームワークってことなのでしょう。
懇親会ではOdersky先生にサイン貰えて、写真までご一緒させて頂きました！！
とても嬉しいです。
嬉しい〜！！！
(((o(*ﾟ▽ﾟ*)o))) pic.twitter.com/eURUqHOkI5
— こざけ (@s_kozake) 2014, 9月 6また、梅澤さんにPlayステッカー貰えたのが嬉しかったです！
ScalaMatsuriでは色んなステッカー貰えましたが、当分はこのステッカーのみでいこうかと思います＾＾
綺麗に貼れた(((o(*ﾟ▽ﾟ*)o))) pic.twitter.com/G6YYEJa45M
— こざけ (@s_kozake) 2014, 9月 62日目
アンカンファレンスではぶらぶらしていました。
こざけさん。。。朝から。。。 #KozakeMatsuri pic.twitter.com/Ap3eOewZaX
— だいくし@9/20Scala関西ビギナー (@daiksy) 2014, 9月 7Skinny Frameworkのハンズオンでは、そもそも「skinny new」 が失敗して動かないw
結局は、nodeのバージョン0.11が入っていたことが悪さをしていたみたい。0.10にしたら動きました。う〜ん、なんでこんなん入ってたんだろう。
あとは、Playの翻訳作業を眺めたり、GitBucket 会議にでたり。
まとめ
ま〜、ひどい内容のブログですが、本当に今回はお祭り気分の参加でした。勉強に燃えてって訳でもなく、そもそもScala力もそんなにありませんからね。本当に勉強したいなら、家でコップ本と逆引きを読んでいたでしょうし。
雰囲気を感じたかったのですが、色々と言語化できない刺激を受けました。
とりあえず来年があるなら、もっと有意義な参加になるようScalaの勉強と英語頑張ろうと思いましたw
今回のイベントは値段を考えても信じられないくらい豪勢なイベントでした！
スタッフの皆さんは本当に大変だったと思います！
ありがとうございました！！
関西WildFly 8(旧JBoss AS)勉強会に参加してきました。
関西WildFly 8(旧JBoss AS)勉強会に参加してきました。
nekop さんの発表
詳細はこちら
関西WildFly 8(旧JBoss AS)勉強会でしゃべってきた - nekop's blog
nekopさんとは初めてお会いしたが、噂通りの背の高いイケメンな方。しゃべりも上手で天は二物を与えてずるいのである。ちょっと仕事の関係でOSSまわりのWeb Application Serverを選定中だったのだが、スライドの中でJBossの市場シェアの話などが出てきてとても参考になった。Tomcat、Jetty、WildFly、GlassFishあたりが選定対象にあがると思うが、最近のJava界隈のOSS事情を考えると、ある程度企業サポートのあるOSS製品が今後も生き残ると考えている。組織として選択結果は技術投資になるので、投資が無駄にならない製品を選びたい。ちょっとGlassFishの立ち位置がいまいちなので、そうなるとWildFlyかな〜と考えていた。当日にWildFlyを使ったデモも拝見させて頂いたが、未だ重量級なイメージのあるJavaEEサーバーとは思えないほど軽くて良さげ。また、Web Application Serverはクラスローダーまわりで毎回ハマるのだが、WildFlyではモジュールクラスローディングを採用しているので心配ないとのこと。ちょっとモジュールクラスローディングについては推移的依存関係のバージョン違いのバッティングの解決方法など、そこら辺が詳しく分からなかったが、面白そうである。文献をあさって調べていきたい。
backpaper0 さんの発表
詳細はこちら
関西WildFly勉強会をやった #wildflykansai — 裏紙
Arquilian を使ったテストの話。僕も仕事まわりでJAX-RSを検討しているので参考になった。テストに関してはどうしても後回しになってしまうが、保守・運用フェーズになるとテストがないと困ることが非常に多い。今回の開発ではそこらへんの反省を踏まえて、テスト設計もしっかりしていきたいと思う。Arquilian は使えるかもしれない。
おだ さんの発表
詳細はこちら
関西WildFly 8(旧JBoss AS)勉強会 でお話しさせてもらいました - お だ のスペース
GlassFishからWildFly8に乗り換えたお話。大変参考になる。また、実際に使ってみてほとんど問題がないというのも心強い話である。ところで、帰りに@haljik さんとも話したのだが、おださんはどういうシステムを開発しているのだろうか？WASを変更したり、バージョンUPを気軽にするとか、なかなかSI案件では難しいのだが。。謎である。
その後
勉強会に参加出来て本当によかった。みなさん、ありがとうございます！当日は家庭の事情で懇親会に参加出来なかったのが本当に残念だった。
WildFlyについては、その後も色々といじっている。WebLogicで動いている社内プロダクトをWildFlyで動かしてみたり、Jenkinsのせてみたり。特に問題は発生していない。GradleのCargo Pluginを使ってビルド＆起動してうま〜ってのも出来たいので、どっかで公開したい。本当、今のところ全く問題なく使えているので、このまま問題なければWildFlyで行きたいと思う。
進め、現場のチーム開発 〜チーム開発実践入門〜 (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
