「Tech Deep Dive #2 in Osaka」に行ってきました

techdeepdive.connpass.com

に、行ってきました。

なんか怖そう

いやー、本当に参加するまでは本当にビビっていたわけですよ。前提とされる知識のハードルが高そうで。

その上で、以下の知識があると、説明の内容を十分に理解できることでしょう。

データベースサーバの表ロック・行ロックによる問題を説明できること

Java のスレッドの状態を知っていること

アプリケーションサーバのスレッドプールとコネクションプールのリソース枯渇による問題を説明できること

これらを説明せよと言われても、正直できないので。

ただ、私の場合、たまたま身近に #0 に参加した人がいたので聞いてみたところ大丈夫との回答を得たので特攻してきました。

Tech Deep Dive、たまたま #0 の参加者が身近にいたので「僕でも大丈夫ですかね？」って聞いてみたら「だいじょうぶー」って返事が帰ってきたので、置物覚悟で特攻します

— Toy (@mdstoy) February 23, 2018

怖くなかった

実際は、お二人のセッションは非常にわかりやすく丁寧でしたし、内容は今の私が知りたいかつ知るべきであろう事柄にとてもはまっていたのも幸いでした。 また、なにより難易度が事前に予想していたよりは高くなかったです。むしろ、ぶっちゃけ私にはちょうどいいけど物足りないとかもっと濃ゆい話がほしいと思う人もいっぱいいるんだろうなと思うくらいでした。

いろふさんがブログで

経験が浅い人にこそ聞いてほしい話なんじゃないでしょうか。この知識がx年前にあれば、あの時もっと楽できたのになぁ、なんて。

という感想を述べられていましたが、まさに私はそれに該当しているのかもしれないです。実際にセッション中にもこの話が近い将来生きてくるのかなぁなんて感じながら話を聞いていました。 主にインフラのスキル的な意味だったり、仕事における立ち位置的な意味で私はまだまだ途上で、それでもこれからはアプリを支えるインフラも含めた上でのサービスというものをいやがおうにも意識していかねばならない立場になりそうなので。

具体的には

• クラウドでは、アプリの性能が悪いと余計なコストがかかる
• 本番を想定したデータで性能テストをすることは重要
  • 例えば特定の商品に注文が集中するなどの特別なケースなどもちゃんと考える
• 安易なスケールアウトは問題の解決にならないばかりか危険
  • 解決のためには問題を正しく分析することが重要
• 負荷は、変わる（増える）
  • サービスの成長とともに負荷は増大する
    • しかも、それは比例とは限らない
  • 特殊な状況での負荷
    • EC サイトだったらセールとか
• コストを考えると、スケールアウトだけでなくスケールインについてもよく考えるべき
• データストアのロックをアプリ側のスケールアウトでは対処できない
• 非同期は要件次第
• キャッシュは条件が揃わないとさほど有効な手段とはならない
• リカバリの範囲（トランザクション単位なのか、テーブル単位なのか、データストア全体なのか）を意識する、影響を最小限に抑えられる適切な範囲で切り戻せるようにする

などなど、ためになるお話がたくさんありました。（独自解釈が入っているかもしれないのでご注意を）

怖くないよ

少なくとも今回の内容は、言われたことをコーディングするだけの人では、たとえそれなりのプログラムがかけたとしても辛いかと思いました。しかし、そのもう少しだけでも先の段階に行っている人なら十分受け止められるのではないかと思いました。 具体的には、自分でコードが書けてアプリケーションの一つや二つは作れます、インフラは正直よくわからんけど作ったアプリケーションを動かす環境を自分で構築するくらいはできます、というレベルの人なら多分大丈夫なのではないかと。ていうか、少なくとも自分はそうです。

なので、もし私のようにハードル高そうだ、うっかり侵入したら穴だらけにされてしまうのではないか、と思って敬遠した人がいたとしたらそんなことはない「かもしれません」よ、とお伝えしたいです。

でも（余談気味に）

とある構文解析ハンズオン に「Java SE 9(Java Platform (JDK) 9)をダウンロード・インストールしておいてください。また、javacにパスを通しておいてください。（中略）誤って、JREのみをダウンロードされる 方がこれまでも一定数見られましたので、注意してください。」と書いてあって、大木こだま師匠ばりに「JDK と JRE を間違うなんて、そんなエンジニアおらんやろー」と思って見ていました。 しかし、今回 TDD になぜ一見厳し目のハードルが設けてあるのかの理由を実際に伺ってみて、そういう（レベルと意識の）人が本当ににいるんだな、それは仕方ないな、と思いました・・・。

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

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 日目の記事です。

最近思ったこと

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

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

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

今考えていること

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

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

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