亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。

はい、ポエムです。自分が正しかろうとは欠片も考えていません。異論や示唆は歓迎ですが、そう考えろと言っているわけではないので、そこはご容赦を。

前置き終わり。

さて、Nullは50億ドルの過ちだそうですね。

そして、それを回避するため、Maybe / Nullable / Optional などの言語機能が生まれ、各言語に埋め込まれています。 それは、大変喜ばしいこと、だと思います。

なんですが、どうもどうも、僕はどうしてもしっくりこないのです。これら全てに対して。Nullと同じように。

Nullは何がダメなんだっけ?

Nullがダメな理由、ってなんなんでしょう。よく言われる批判として、以下があるのかなぁと思っています。

①Nullは型ではない

Nullと言っていますが、こいつはNullポインタ、でございます。 からの「何か」を指すポインタ。つまり、型がない。

CalssHoge のnullも、 ClassFuga のnullも、同じもので、それをに特別な役割を与えることができないのです。

②あるメソッドがNullになるかどうかの判断ができない

Nullを普通に返していると、「そのメソッドがNullを返すかどうか」が判断できなくなります。 結果として、あらゆるメソッドに対して、Nullチェックを行うことになってしまい、コードが if (x == null){ return; } だらけになります。

だいたい、これくらいでしょうか。

Optionalが解決するのは②だけ

こう考えると、Optionalなどのパターンが解決するのは②だけです。

確かに、 Optional の明示によって、解決は可能になります。Optionalを返すものは、ハンドリングをしないといけない(ハンドリングしないと元の型に代入できませんからね)。 うん、素晴らしい。

①の「どの方のNullか分からない」という問題も解決はしますが、本当に解決したいのは「Nullに型独自の処理をさせたい」なので、残ったままです。 でもまぁ、②が解決できれば、いいんじゃないの?

なぜ②を解決しただけでは気持ち悪いのか

そこが僕の違和感です。何が気持ち悪いのか、大きく2つあります。

結局 if 分相当の処理を書いてしまってる

Optional にせよ、 Either にせよ、対照Objectが無かった場合の処理を、Optional を返していれば書く必要があります。 記法が洗練されただけで、 Optionalif乱発を本質的には解決していないのです。

いや、むしろ、 記法が簡潔になった分、逆にあらゆるメソッドに気軽に Optional がついてしまい、コードがより汚くなってしまっている傾向がある とさえ感じています( swift が特に顕著だと思う)。

とっても手続き的に見える

当たり前のように呼び出し側で Optional をチェックしていますが、本当にその責務は呼び出し元が負うべきなのでしょうか?

呼び出し元が、問い合わせで帰ってきた値に対して空チェックをし、空の場合は何らかの処理をする、というのは非常に手続き型プログラミング的です。*1

オブジェクト指向プログラミングの観点からいうと、 空の時にどう振る舞うべき かは、可能な限りそのオブジェクトが持つべきだと思います。 「求めるな、命じよ(Don't Ask, Order)」のオブジェクト指向の原則的観点から言うと、空だろうがなんだろうが、提供されているインタフェースに関して、命じられた命令を返すのが、正しい姿ではないか、と思ってしまうのです。

つまり、NullObject をちゃんと使いたい

なので、NullObjectをちゃんと使いたいのです。

NullObjectは、ただ単に equals で問い合わせれば Null かどうかが分かるだけの静的な値では無いと思っています。 Nullである時、つまりデータ取得を失敗した時や、初期化時や、その他諸々、まだ値が空の時にも、責任持ってそのオブジェクトとしての責務を果たすだけの機能を持つ。

それがNullObjectなんじゃないかと。 もしその責務を果たすために親が何かを与えてやることが必要なのであれば、それはオブジェクトの設計そのものが間違っていたり、歪んでいたりすると思うのです。

勿論、その時に逃げ道は必要ですが、それを糖衣構文化することは、言語としては避けたほうが良いんじゃないのかなぁと、そんなふうに思うのです。

以上、ポエムでした。

*1:そういう意味ではHaskellOCamlなどの関数型系のOptionalは納得行くものではあります。

恐れ多くもDDDの話をしてきたのでした #DevKan

というわけで、喋ってきました。シルバーウィーク一日目なのにご足労いただいた皆さん有り難うございました!

www.slideshare.net

ここ半年の中で、技術者としての一番のブレイクスルーは、「ドメイン駆動設計ってドメインに駆動されて開発することなんだ」と気づけたことかなぁ、なんて思っています。

なんで設計って言ってるのに開発なんだろ?とは思ってしまいますが、、、

f:id:posaunehm:20150920213521p:plain

このあたりのエヴァンスの問題意識からすると、 DesignImplementation の境界はなく、作ることまで含めて Design と読んでいるんでしょうね。

実際に、Google Slide をみんなでいじりながら毎週モデリングセッションやりつつ、日々実装進めていく、ってのは結構楽しい行為ですよ。 リモートでもチーム感出る、という副次的効果もあったりします。

グダグダ言わずに、設計して、コーディングして、実装できねええええええ!ってサイクルを、ぐるぐる回していけばいいじゃない! *1

*1:それってぐるぐるDDDっぽいな

最近の @Posaune

二ヶ月間書いてない…!

てなわけで、最近のわたくしです。

本業

ギルドワークスBlogには時々書いてます。

まぁ、忙しくて体調崩しつつも、軒並み元気にやっております。

発表

ポストJenkinsの今、どうCIするのか、のお話。

www.slideshare.net

これは思いの外PV伸びました。皆さん色々思うところはあるんでしょうね。

重ねていっておくと、これは「Jankins is Dead, Long Life CI!」ではありません。ただ、CI = Jenkinsという時代ではなくなったんだよね、という感じです。 それでも、Workflowプラグインを検討するなど、Jenkinsのプラグインヘルにならないような工夫が必要ですね。

なれる!IL!

www.slideshare.net

ILをひたすらデモとして読み書きしてましたので、資料はうっすいです。 ひたすら書いたと言っても、、、

ILでfor文相当の処理を書いてみただけです。アセンブラ読めれば書ける書ける。

ツイート

最近技術の記事ツイート増えていると思いますが、これははてぶの「あとで読む」したものが流れています。

読んだ後には、わりとサマリした文章で再投稿しているので、そういうものだと思ってもらえれば。

ユーザーストーリーと"INVEST"とDONEの定義

会社Blogの方に、こんなのかきました。

blog.guildworks.jp

ここ最近、ストーリーで開発していてうまくいくパターンと駄目なパターンがだいたい分かってきたので、共有ついでに書いてみた、という感じですね。

なんとなくですが、アジャイルを最初にとりかかる人は"INV"をすごい強く意識しすぎて、開発でずっこける、みたいなパターンが多いかと思います。

どっかで"ES"にふらないとねーという。そのなかで、"Testable"であること = 受け入れ条件がしっかりしていること、はやっぱ重要じゃね?と思いますね。

ちなみに、"受け入れ条件"と"DONEの定義"は結構違うので、そこはそこでご注意を。

"DONEの定義"ってのは、ストーリー個別ではなく、全てのストーリー共通として意識すべきことです。コードレビューが終わってる、とかC0カバレッジが100%だ、とか、そんなの。

カンバンでいうところの「各レーンを超えてよいかどうか」の統一基準ですね。

受け入れ条件にDONEの定義含めていちいち全部書いてもいいですが(慣れてない現場ではまずはそうした方がいい)、ゆくゆくは分離しないと大変かな、と。

そんなことを最近考えています。

User Story Mapping

User Story Mapping

終了直前!雑食系プログラマがKindle 50%オフセール で買ったものまとめ。

さて、後3時間ですね。ギリギリすぎるとは思いますが、「こんなのもあったのね」と目に止まったものを中心にいくつか買いました。

既に持っている定番書は買っていなかったりするので、ニーズにマッチするものではないとおもいますが、ご参考までに。

そろそろちゃんと勉強しておきたいJava8。

諸事情でPython勉強したくなったため。

パーフェクトPython

パーフェクトPython

持ってなかったのでこの機会に。

新版暗号技術入門 秘密の国のアリス

新版暗号技術入門 秘密の国のアリス

半額なら買ってもいいかなー、系。

カンバン: ソフトウェア開発の変革

カンバン: ソフトウェア開発の変革

某なごや方面でおすすめされていた気がする。

定評あるScala関数型本。

赤帽さんの解説書ということで。Linux詳しくないのでね。

そろそろ「ノンデザイナーズ・デザインブック」以外のデザイン本もちゃんと読まなきゃなので。

ソフトウェアテストがいい本だったので、こっちも。

USP研究所のシェル本。

シェルプログラミング実用テクニック

シェルプログラミング実用テクニック

どっかで強力なおすすめ書評を見たので。

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

たべたい。

食べる!SSL! ―HTTPS環境構築から始めるSSL入門

食べる!SSL! ―HTTPS環境構築から始めるSSL入門

ElasticSerach自体をわかってないので、ひとまず読んでみる。

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

Redisも。ちゃんと基礎を押さえるため。

Redis入門 インメモリKVSによる高速データ管理 (アスキー書籍)

Redis入門 インメモリKVSによる高速データ管理 (アスキー書籍)

低レイヤーよりもひとつくらいは。

30日でできる! OS自作入門

30日でできる! OS自作入門

うん。

買いすぎたね!

Githubで特定のディレクトリだけをチェックアウトする方法

Github、ようやく開発の本物のレポジトリとして扱えるようになってます。いやぁ、ほんと、楽。 色々とはかどります。

とはいえ、最初にレポジトリの構成を間違ってしまうと、開発終盤になって、「このブランチのこのディレクトリだけちょっと見れるようにしておきたいなぁ・・・」と思うことは有ります。うっかりデザインデータを特定レポジトリのディレクトリに突っ込んじゃった、とか。

そんな時、「このディレクトリ以下をチェックアウト」ってできればなぁ、と思うんですが、残念。svnならまだしも、gitはできないんですよねぇ。。。

「"Git"hubといったな?あれは嘘だ。」

んで。まぁ有名な話として、これがありますよね。

f:id:posaunehm:20150516115131p:plain

そう、Githubsvnチェックアウトできるんです。ということは・・・、特定のディレクトリ以下を引っ張ってくることだって、もちろん可能です。

えー、でも今更svnつかうのー?

我々には、git-svnがあるじゃあないですか。

というわけで、"Githubの任意ディレクトリをsvnとして、git-svnを通じてgitチェックアウトする。"をやってみましょう。

例えば、対象はこちらのブランチ。

自動化パタン・ランゲージの、公開用のgh-pagesブランチの、gitbookディレクトリ、ですね。

git svn clone https://github.com/KenColle/AutomationPatternLanguage/branches/gh-pages/gitbook

これで、一応gitレポジトリとしてチェックアウトできました。pushは当然git svn dcommitで。

参考

というか、これをまるっと翻訳したにすぎないんですけどね。あたまいい!と思いました。まる。

stackoverflow.com

そもそも、勉強会ってそんなに大変なものだったっけ?

ちょっと気になったので。

mollifier.hatenablog.com

d.hatena.ne.jp

お二人の意見に、特に異論はないです。ただ、なんか「勉強会」ってのがあんまりにも巨大になりすぎてるんじゃないかと、ちょいと危惧しておるのです。

大きな勉強会は大変

大きな勉強会運営は大変です。私もDevLOVE関西というそこそこでかい勉強会コミュニティの運営お手伝いしてますし、無断欠席等々で困ることは多々有ります。

そりゃあ大変ですよ。

でもね、「うわこわ。じゃあ勉強会やめとこ」とも思わないで欲しいんです。

昔話

むかしむかーし、京都アジャイル勉強会という勉強会が有りました*1

立ち上げの時、なんか偉い気負って、半日くらいでみっちり勉強しようぜ!みたいな謎の義務感にかられ、風呂敷ばっかり大きくして勉強会を企画し始めました。その結果、立ち上げは遅れに遅れ(その間に主催者2人はやたらと飲みに行きえらい仲良くなりましたが)、立ち上げたイベントも全然人を集められず、何だったんだこの準備期間は、みたいな状態に陥ってました。

んで、何をやったかというと、アジャイルサムライの読書会をさらっと立ち上げて、夜とか土曜日の午前中とか、気楽な時間に気楽なメンバーで始めたんですよね。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

それ以降、京アジャの運営で困ったことは、ネタ不足以外はありません。15人位入る会議室を借りて、夜にちょろっと集まって勉強して、部屋代だけワリカンで、、、みたいなね。

参加者も主催者も、気楽にね

あれから幾星霜、結構最近はコミュニティの数も勉強会の参加者も増えちゃって、冒頭のような問題が起こってますよね。

外に出て勉強する人が増えるのは本当にいいこと。でも、それが結果として勉強しようとしている人を躊躇させるような、変なプレッシャーになるのは、なんだかなーと思うのです。

気楽に行きましょう。10人位の規模で、勉強したいものを、勉強したい人で、気軽にやればいいのです。それくらいの会場なら、一人300円も出せばワリカンできる会場は、そこそこの都市圏ならたくさんあるはず。

そういう気軽で小さな勉強会が増えれば、大規模な勉強会の必要頻度も減ると思いますし、そこで磨り減る人も減ると思うのですよ。

気楽に行きましょ、気楽に。

最後に宣伝

とか言っておきながら、そこそこ大きな勉強会、やります。

kokucheese.com

運営のプロがたくさんいるので、僕は気楽なもんですが、なんか喋ると思いますので、ぜひぜひ。

*1:まだ有りますよ!念のため!!