亀岡的プログラマ日記

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

Macのウィンドウ切り替えアプリ Contexts がすごくよい。あと、Microsoft MVP 更新しました。

Macのアプリ紹介とMS MVPの更新を同時にやるとか一体何やってるんですかね僕。

さて、とはいえ、Contextsです。

Contexts

Macは割とウィンドウ切り替えがうざい

Mac使っていて、意外と不便に感じるのが、「Alt + Tab」がないことです。 いや、まぁ本当のProgrammerなら (Emacs | Vim) の外から出ないで開発するんでしょうけれど、私はIDE大好き人間でして、、、必然ウィンドウ切り替えが頻発するのです。

あとは、やっぱりフルスクリーン派なので。 するとMacでWindowの切り替えをどうするかというと、

  1. 4本指横スワイプで切り替え
  2. 4本指上スワイプでWindow一覧出して切り替え
  3. Comamnd + Tab で切り替え

の3択なのですが、それぞれ問題があります。

  • 1 は遠くのウィンドウに移る時に、どこいったんだっけ!?と迷います
  • 2 は一覧開くのがまどろっこしい上に、なんだか超絶重いことが多いです
  • 3 は切り替えは早いのですが、なんと切り替えがアプリ単位で、ウィンドウ指定できないのです

Contextは求めていたもの

Contextの何がいいって、まず 3 をウィンドウ単位にしてくれる、というのが基本機能としてあります。 まずはこれ、これで十分。

だけれど、なんと他にも機能があります。

トラックパッドの上端をなぞると、、、

f:id:posaunehm:20161008111823p:plain

同じく一覧を出してくれます。この操作感が思いの外気持ちよく、割と使ってしまいます。

基本的にはテキストですけれど、スライド作っているときとかはトラックパッドにも手は伸びてますからね。

そんなこんなでContextsオススメです。

それからそれから

Microsoft MVP for Visual Studio and Development Technology 、再受賞させていただきました。 今年もシアトルにはいけないのですが、来年にはなんとか行きたい。そんな気分です。

2016年、今年もよろしくおねがいしまーす!

さて、あけおめです。

しばらくBlog書いていないので、なんか、感覚がつかめていませんが。。。

とりあえず、今年の目標でも書いておこうかなぁ。 その前に、去年を振り返るか。

2015年を振り返って

いやぁ、転職してしまいましたねぇ。。。自分でもこうなるなんてびっくりです。就活の時は、「一生勤められる会社を!」みたいな思考だったんですけどね。 やっぱり、外の勉強会に言って、もっと楽しい現場の話を聞いていると、ウズウズしちゃうんですねぇ。

転職して8ヶ月、なんだかんだで楽しくやってます。これまでやったこと無いことばかりで、やっぱ大変ですけどね!

2016年に向けて

やっぱり、僕フロント中心の設計が好きみたいです。というわけで、Fluxというか、モダンなWeb開発は何とかマスターしていきたいなーと思っています。

あとは、そろそろ、ぜんぜん違う言語を身に着けたいですね。Goとか、Rustとか、Elixirとか。

それから、ちょっと読書の年にはしたい。 かなり、危機感はあったりします。知識をもっと貯めねば。貯金がまだあるうちに。

おし、がんばろ。

今年もよろしくお願いします。

大きすぎるDiff、縮まったDiff、縮まないDiff

これは、 DevLOVE Advent Calendar 6日目の記事です。 id:itow_ponde さんから、受け取ります。

f:id:posaunehm:20151206235021j:plain (町で見つけた本当のAdvent)

さて、今回のテーマは「Diff」です。違いじゃなくて、「Diff」というのが、なんともDevLOVEらしいですねw

大きすぎるDiff

さて、思い返せば、もう恐らく5~6年前になりますか。僕が勉強会に出始めたのは。

その当時は、登壇している人々って、とんでもなく遠くに感じたものです。 言ってしまえば、「アイドルとそのファン」みたいな感じです。

自分が、登壇するとか、主催するとか、そっち側に行くとは思っても見ませんでした。 このまま、普通のエンジニアとして過ごしていくんだろーなー、と。

縮まったDiff

転機は最初の勉強会参加から1年後くらいに、突然やって来ました。 @toshiotm と(京都人同士なのに)岡山で出会い、勉強会を主催する意気投合をしたのです。

それは、「アジャイルサムライ京都道場」となり、「京都アジャイル勉強会」となって、今に至っています。 勉強会をしていく中で、 XP祭り関西やら、Agile Tour Osakaやら、システムテスト自動化カンファレンスやら、様々なイベントで登壇やスタッフなど前面に立つようになりました。

大きな舞台の前にも、何度か立ってきましたが、そこには支えてくれる仲間たちが、必ずいました。 周りのみんなに助けられて、時にはおだてられ、ノセられて、ちょっとずつ住む世界が変わってきました。

縮まらないDiff

そして、前に立つようになって分かったこと。それは、より具体的な差となって横たわる、すごい人々僕との間のDiffでした。

そこに足りないのは、技術的なスキルもあれば、人間的な大きさもあれば、実践してきた経験もある、というように見えています。 この差を、今度は埋めていかねばなりません。

大変です、大変ですけれど。

どうやって埋めればいいのか、のが見えていいないわけではありません。

バイナリレベルのDiffから、行単位のDiffが見えるくらいまで、見え方は変わってきてるんじゃないかと思ってます。

この見え方の違いそのものも、過去と今のDiffですね。 来年このDiffがどうなっているのか、楽しみです。

僕にとって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