「あるエンジニアがプログラムを紡いでいく様を見てみる」に行ってきました

devlove-kansai.doorkeeper.jp

に行ってきました。

紡いでいく様への感想

素振り重要

お二人とも、自分の作業を改めて言語化することを、イベント後に Twitter で面白いと表現されていました。また、その言語化自体はコードを書くようにはスラスラと出てこなかったのが興味深かったです。

要するに、今日お二人がされたようなコーディングは、言語化せずとも無意識レベルで出来ているということなのかな、と。そして、それができるようになるには相当な回数の素振りが必要となることでしょう。

自分ももっと素振りせんといかんなぁと反省しました。ここ最近は、コードを書く動機で一番多いのが適切なコードレビューをするために自分でも書いてみる、だったりするので・・・。

テストに求めること

今回のイベントで一番印象的かつためになったのが、いろふさんのテストの対象範囲に対する考え方でした。それは、確認したい事柄を、確認できる最小限の範囲・労力でしかしないというもの。これは恥ずかしながら目からウロコでした。 コードとともにテストコードも合わせて成長していけば、確かにぶれないよなぁと思いました。 自分のイメージでは、テストコードは仕様に合わせてできる限り最大限に書くもの、という先入観があったもので。

その他感想

• お二人のレベルだと、並行して追いかけるのは無理
  • そりゃプロ棋士相手に二面指しするようなもんですわな・・・（してもらうほうじゃなくて）
• もうちょっとこじんまりしていたほうがよりライブ感が増したのかもしれない
• MOTEX 様の設備いつ見てもすごい
• Spring Shell は実際に仕事でも使える部分があるかもしれないと思ったので、明日以降ちょっと気にしてみようかと
  • そうでなくてもああいうインタラクティブシェルが作れるのは純粋に楽しそう

「モブプログラミングを実践してみよう!! 〜アジャイルモンスターのモブプロ入門〜」に行ってきました

devlove-kansai.doorkeeper.jp

に行ってきました。

やったこと

• 及部さんのモブプロに関するざっくりとした説明を聞く
• お題「自動販売機」で、三つのグループに分かれて一時間余りモブプロする
• 振り返り
• 一旦三チームの成果を確認する
• チームをシャッフルしてまた一時間余りモブプロする
• 振り返り
• 最後に三チームの成果を確認する
• 及部さんの締めの言葉をいただく

こんな感じ。

自分のチームの活動・成果

言語

まず言語を決めないといけないわけですが、自分の最初のチームのメンバーの得意言語は Ruby、PHP、Java、Scala、普段コード書いてない、と綺麗に分かれたので、あえて誰の専門でもない Python を選択。

設計・実装

チームの中で Python の経験者が @yoshiyoshifujii さんだけだったこともあり、自然と藤井さん中心にいかにも OOP 的な設計で堅実に進んでいったので、個人的にはとてもわかりやすかったし、興味深かったです。

後半戦は後半戦で、@haradakiro さんが参加されたことが大きく、引き続き堅実路線で進みました。 とくに、ランダム要素はテストが困難になるから避けよう（ランダム性が必要ならあとで注入できるようにしよう）という提案は非常にためになりました。

感想

チームについて

あとで他のチームの成果を見て思ったのですが、チームの方向性はメンバーによって容易に変わり得るのですよね。いい悪いの問題じゃなくて。 例えば、自分のチームのアウトプットは、Drink クラスのインスタンスをそのまま print したもの (Drink object at 0x7fe5659d8850 的なやつ)と、お釣りの数値の taple というシンプルなもので最後までいったのだけど、隣のチームは文字列として人の目に見える、わかる形で表現していたようでしたし、その隣はがっつりテストコードでした。

なので、いろんな可能性を（加えて上限も）考えて開発を進めようとすれば、チームのメンバーそれぞれが相応のスキルを身につけていないとすぐ行き詰まってしまう、ということを改めて目に見える形で認識することができました。 モブプロは、メンバーやチームの能力、成果をチームの上限まで引き上げるのにはとても役立ちそうですが、チームの上限自体をを引き上げるのにははたしてどれだけ役立つのだろうということが今これを書きながらちょっと気になりました。そりゃまあ一人でやるよりはるかに気づきは多いでしょうから効率は上がるのでしょうけど、個々が努力して自分の上限を引き上げる努力も並行して頑張ることも同時に必要にはなるのかなぁと。いや、そりゃ当たり前か。

モブプロについて

あと、モブプロは、他の手段だと別途用意しなければいけない工数が省ける分効率がいいというのが実感としてよくわかりました。レビューとか進捗管理とか。チームの振り返りの感想としても出てきたし、及部さんもそういうことを言われていました。 ただ、省けるというのは、それが雲散霧消してしまうわけではなくてモブプロの「中」に含まれることになるので、とても密度が濃くなるし疲れます。本当に疲れます。こんなの毎日一日中やるの無理だよ・・・って思ったくらい疲れます。

そんなわけで、適宜休憩をとったり参加自由出入り自由とかのルールを設けたりするのが思った以上に重要ということなのかも。今回のようなワークショップ形式だと、どうしても行けるところまで後先考えずに行こうとするわけなんですけど。

あとで改めて考えたこと

今回の及部さんの話の中で、エンジニアはドメインを理解して開発しないといいものは作りようがないという趣旨の発言を繰り返しされていたように思えました。 また、私は去年から DDD に対して改めて向きあおうと決心して今に至っています。その中で、もちろん開発する中でまずドメインを理解することがなにより大事、技術はエンジニアとしての前提条件（できて当たり前）であるべき、という考え方をするようになってきています。

しかし、残念ながら昔ながらの PG < SE < PM 的な考え方はあるところには根強く残っていて、（駆け出しの） PG は技術のみを要求するような風潮があります。もちろんそうでないところも増えてきているように感じますし、自分自身も幸いなことに今働いている現場はそうではないのですが。

ともあれ、これについての問題は二つあると思っていて、まずは上記の主張からいえばドメインを理解していない PG は役に立たないというシンプルな話になります。

もうひとつは PG 自身がキャリアパスの方向として、（ドメインの知識をないがしろにして）技術ばかりを突き詰めようとしてしまうという問題です。そういう人はいわゆる悪い意味で「意識高い」人になりがち、という。これは個人の感想に過ぎませんが。

本当に技術「のみ」で勝負できて、技術のみを相手にすることが仕事「そのもの」になる人ってよほど突き抜けたひと握りのエンジニアだけだと思っているし、それはともかくとして仕事として具体的なサービスや製品を作る立場であれば（そしてエンジニアの多くはそういう立場のはず）ポジションにかかわらずすべての人はそのドメインに向き合わけなればならないのではないかなぁ、と今の自分は思っています。

なので、私の中のあるべき姿を図にするとこういう感じ。

ドメインの知識はすべてのメンバーが持つのが大前提、その上で持っている技能によってエンジニアやプロデューサーやマネージャーが並んでいる、ようなイメージ。

あ、モブプロぜんぜん関係ない話になった？まあいいか・・・。

（xubuntu をインストールした）ThinkPad X220 のウルトラナビ（タッチパッド）を無効化する一つの方法

ThinkPad のタッチパッドが邪魔だとか無効化したいとか思う人はたくさんいるようです。私もその一人です。 そんなわけで、ググると xorg.conf などの設定ファイルをいじるだのデバイスの設定を調べてコマンドを打つだのいろんな方法が紹介されています。

だがしかし、コマンドを打つならまだしもシステムに関わる設定ファイルをいじるとか怖い。とても素人にはお勧めできない。

マウスとタッチパッドの設定から無効化することもできますが、これだとトラックポイントも一緒に使えなくなってしまう（ように見える）。（実は試してないからわからない）

しかし、実はとても簡単にタッチパッドだけを無効化する方法があります。

なんと！ BIOS に設定があるではありませんか！！ （ググってみた限り、型番によっては無いのかもしれませんが・・・）

というわけで、BIOS の設定画面にいって Touch Pad の項目を Disabled にするだけで済んだのでした。

ThinkPad X220 に xubuntu をインストールした時の記録

前置き

ThinkPad X220 ｷﾀﾜｧ pic.twitter.com/9veQWbUaDQ

— Toy (@mdstoy) February 8, 2018

ThinkPad X220 を入手したので、早速プリインストールの Windows から xubuntu に入れ替えました。せっかくなので手順や注意すべきことなどを記録に残しておきます。

10 年以上前に X21 に ubuntu を入れた時は PXE ブートでやったんですが、今回はおとなしく USB メモリをインストールメディアにしてやることにしました。

準備する（べきだった）こと

• USB メモリ 2 つ

リカバリーメディアのためにひとつと、インストール用のためにひとつ必要です。

まあ個人的には Windows に戻すことは九分九厘ないのでひとつでもよかったんですけど、まあこういうのを端折って何かあったときに困ることはまれによくあるというのと、極度の貧乏性なので作れるものは作っておこうということで。

容量は、X220 のリカバリーメディア用は 8GB が必要で、インストールメディア用は iso のサイズが 16.04 LTS で 1.2GB くらいなのでそれが入るサイズが必要です。とはいっても、わざわざ探さない限り 8GB くらいからしか売ってないですかね。

余談

昔なら使ってない USB メモリがそのへんに転がってたりしたものですが、このご時世ですから普段使う機会は全くといっていいほどなくなってしまって、ものが手元になく慌てて買いに行くはめになってしまいました。USB メモリ一つをポチって一日待つのもアホらしいですしね。

とはいいつつ、わざわざ街の電器屋さんに買いに行くのもだるいよなと思っていたのですが、カメラ屋でもメディアを扱っていることに気づきました。ちょっと盲点でした。というわけで、インストールメディアに使うためなら品質とか問わないので近所のカメラ屋さんに買いに行って事なきをえたのでした。

リカバリーメディアの作成

http://x220.e-sup.biz/thinkpad_x220_ssd/step1/x220.e-sup.biz

このブログを参考にさせていただきました。

(2019-12-19 追記) 参考にさせていただいたブログはリンク切れになっていました。残念。(2019-12-19 追記ここまで)

作成用のアプリケーションをするだけの簡単な作業です。いろいろググったところ、USB メモリはクリーンな状態にしておかないといけないようなのでそこだけ注意です。

インストールメディアの作成

私の普段使いの PC は xubuntu なので、そこで xubuntu のインストールメディアを作るのはとても簡単でした。

1. Download Xubuntu « Xubuntu からインストールしたいバージョンの iso をダウンロード
2. USB メモリをマウント
3. ターミナルで usb-creator-gtk を実行
   1. 特に変なことをしていなければ標準で入っているはずで、apt の実行とかは不要です
4. 起動したアプリケーションにダウンロードした iso と、マウントしたメディアが認識されているのを確認してブータブルUSBの作成をクリック

余談

ググると何種類かのアプリケーションを使用する記事が大量にヒットしますけど、標準で含まれているコマンド一つでできちゃうんですね。自分も今までは Unetbootin でやってました。

インストール

BIOS の boot の設定で USB メモリが優先されるように変更したのち、インストールメディアを差し込んで起動。インストーラーが起動するので、あとはそれに従ってインストールするだけです。

途中で「グラフィックス、Wi-Fi機器、Flash、MP3やその他のメディアに必要なサードパーティーソフトウェアをインストールする」という項目があるのでそれはちゃんとチェックしていたほうがいいかもしれないです。（チェックなしでのインストールを試してないので、その時どうなるかはわからないのですが）

余談

それにしても、インストールするたびにインストーラーがわかりやすく楽にできるようになっていていいですね。よく解説記事などで「わからないならデフォルトのままでOK」みたいに書かれている項目が以前はいくつかあったと思うのですが、そういうのはもうありません。わかるひとは後で自分でよろしくやればいいわけですから、とてもいいことなんじゃないかと思います。

インストール完了

思ったよりずっと早く終わりました。Wi-Fi や、トラックポイント、ウルトラナビなどもちゃんと認識されています。素晴らしい。今のところ唯一の問題は、ウルトラナビの感度がウルトラよすぎてウルトラいらいらするので、あとで無効にせねばなーということくらいですかね。

いやー、昔に比べて xubuntu のインストールは本当に楽になったなと感じます。あと、いつの間にやら日本語入力のデフォルトが Mozc になっているようで驚きました。

将棋ウォーズの棋譜 url から csa ファイルを作るワンライナー

(Lazy) One liner that create csa file from shogi w ...

とりあえずソフトで解析するための棋譜ファイルを作りたかっただけなので雑なワンライナーで済ませました。

ワンライナーで済ませずにちょっと気合を入れたら対局者名や消費時間なども入れられますが、そこまでする動機もないので・・・。

楽しく仕事をするということ

この記事は コミュニケーション Advent Calendar 24 日目の記事です。

最近思ったこと

仕事をする上で、何かのきっかけで一時的に雰囲気が良くなることが時々あります。たとえばレトロスペクティブのあととか、とてもチームの雰囲気が良くなることがあるんですよね、経験上。あ、いいなあこれ、みんな笑顔でいい雰囲気で仕事できてるなぁ、って。ただし、次の日にはだいたい元に戻っている。別に元より悪くなるわけではないのですけど。

結局、それはかりそめの笑顔だと思うのですよ。みんなの意識が本当に揃ったわけではなくて、あくまでも形式的な表面上のコミュニケーション。みんなで話し合って決めたからそうしようっていうだけで、本質的なところが何も解決していないから定着しないのではないかと。

もちろんやらないよりはやったほうがいいと思いますよ。私はいい雰囲気を作るのが苦手だからなおさら普段から意識していないといけない。（残念ながらまったくうまくできてませんけど）

今考えていること

じゃあ本質的なところを解決するにはどうしたらいいのかって話になるわけですが、それは結局、意識（知識・スキルも含めて）の共有ではないかとは思っています。それをどうやって実現するかの答えは私の中ではまだ全く見つかっていないので困っているのですが。そもそも実現不可能なんじゃないかとすら思っていたりして。仕事に対する意識も、持っている知識も経験もスキルも違う人たちが、同じものを共有するなんて。

いい悪いの問題ではなくて、見えているものが明らかに違うから伝えきれないよなぁと思うことがあって。見たいと思っているものがそもそも違うからどうしようもないよなぁと思うことがあって。でも、自分が見ているこの風景をぜひ見せてあげたいと願ってやまない自分がいる。

求め過ぎなのかもしれません。自分にも他人にも。みんな違うことを認識した上で、それでもできる手段を取ることに注力したほうが効率がいいのかもしれません。でもそれでは納得できないんだよなぁ。困ったことに。

「 関ジャバ 関西Javaエンジニアの会(関ジャバ) '17 10月度」に行ってきました

kanjava.connpass.com

に行ってきました。

というわけで、直接的な感想ではないんですけど、皆さんのセッションから得たこととか考えさせられたこととかを一旦まとめました。

DDD について

最近 DDD とかそれにまつわる技術とかを学んだり実践したりする上で思うのは、よくあるなんとかアーキテクチャーとか（MV なんとかなども含めて）一つの指針としてはとても有用だと思いますけど、なんとかアーキテクチャーありきで開発するのは違うよなーということです。 そういう型にはめて型ありきでやろうとすると、この層なんのためにあるのかよくわからないとか、特定の層がやたら膨れ上がったりとか、どうしても歪ができてしまうような気がして。

「ドメイン」は現場によって違う。言語やフレームワークも違う。作業者の質や量も違う。結局、そのときどきに合わせて悩んで苦しんで生み出していくしかないのではないかというのが今の時点での私の結論ですかね。

どうせ成果物を何ヶ月後か何年後かにあらためて見返したら、「当時の俺ってアレやったな」としか思わないんですから。いつまで経っても。

まあ一言で言うと「銀の弾丸はない」っていうお決まりのフレーズになっちゃうんですけどね。

ああ、もちろん、大きな枠組みではなく細かい技術やノウハウの積み上げは必要だし重要です。たとえば 増田さんの本 はそういうものが詰まっているんだなと今さらながら気づきました。

言語について

私は Java 大好きっ子で、一方今回のセッションは Scala が多めだったわけですが、それはそれでいろいろ学びになります。 で、少し前から意識はしていたんですけど、やっぱり Java 以外の言語も勉強しないといけないと改めて思いました。

それは、いろんな言語を学んで選択肢を広げるということももちろんあるのですが、メインである Java をもっと深く知るためにこそ、Java だけでなく他の言語や言語を支える技術をもっと勉強したほうがよいという意味で。

オブジェクト指向について

私のオブジェクト指向に対する認識は、いろいろさまよった結果

オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smalltalkのtは小文字です、“オブジェクト指向”の本質 - Smalltalkのtは小文字です

この辺でとどまっています。また、数年前には社内勉強会の講師としてオブジェクト指向について話そうとして大爆死した経験もあったりします。そんなわけで、自分でもよくわかってないし人にも説明できないし、そもそも人によって言うことはまちまちだし、なんかもう最近は「みんなの心の中に、それぞれのオブジェクト指向があるんだよ」ってことでいいじゃないかみたいな感覚でいました。（getter/setter がカプセル化とかいうのはもちろんだめですけどね）

しかし、少なくとも Java という文脈の上ではそれはもう「型」ってことでいいんじゃない？と増田さんのセッションを聞いていて自信（？）が持てました。（雑な表現、雑な理解ですけども）

まあとりあえず、存在はだけ知っていたけど英語なので敬遠していた WhatIs 論文くらいはいまさらながら読もうと思いました。今の自分なら時間は掛かれど、それなりに読めるはず・・・。