日々常々

ふつうのプログラマがあたりまえにしたいこと。

既存を正解とする減点ゲームへの違和感

オンラインミーティングとか、リモートワークとか、インターネットを介する話のメリットデメリットとかをみていると、「既存になるべく近づけよう」としているところに違和感を感じてる。

電子書籍もそうで、いかに紙をデジタルで表現するかに腐心しているように感じる。ページめくりのエフェクトなんて要らないのだけど、一時期ついてたりしたよね。紙っぽさにヒントはあるかもしれないけど、紙っぽくある必要はないはずなんだ。

差は減点対象となり、足切りとして機能している。減点ゲームをクリアしないと候補にもならない。そういう事実はある。けれど、足切りになりうる欠陥と、欠陥でないただの差異を混同している感じがする。

完全な代替なんてできないなんて認識は誰もがしているはずが、油断するとどこかに置いてきてしまいがち。ときに完全な代替ができることを宣言させられる圧力もあったりする。よくわからないけれど、そうでないと(それくらいでないと)進められないとかなんとか、言わせた側からはそんなよくわからない話も聞く。嘘をつかせる儀式に何の意味があるんだろう。

いくらデジタルにアナログっぽさを求めても、極限までアナログに近づけたデジタルはアナログの劣化コピーにしかならない。そんなことはわかると思うのだけど、それでも細かいところまでアナログっぽさを求めてる感じがする。

いくつかの理由づけはできなくはない。例えば「ただ変化を嫌っているだけ」とか。派生になるけれど「既存から変わるのを良しとしない人々を抵抗勢力と見立て、それを封殺するために既存を満たした上でメリットを強調したい」とか。後者は暴走品質を生み出す考え方の一つだと思う。

だからと言って妙案があるわけではない。 私は電子辞書と紙の辞書は両方使うけれど、使う場面は明らかに違う。仕事もリモートでいいものもあれば「これは対面だなぁ」と思って調整することも多々ある。漫画も紙、KindleiPhoneMacとまちまちで、今の所どれかに統一される気配はない。

きっと過渡期なんだろう。もしかしたら違うものが同じ名前で呼ばれているだけなのかもしれない。今「仕事」と言ってるものは、2種類(もしくはそれ以上)に分割され、仕事Aはリモートが当然で、仕事Bは対面が当然、みたいな感じになって、それらが「仕事」と一緒くたに呼ばれていたことなんて忘れられるのかもしれない。

とりあえずスクロールの漫画はとても良いと思う。あれは紙じゃ無理だ。できれば1話ごとに読み込みとかにせず、延々とスクロールさせてほしいもんだ。Kindleの合本も悪くないけれど、あれやるなら索引はちゃんとやってほしい。一昔前のゲームブックをデジタルで表現するなら読み進めながら文章が変化していく感じかなーと思ってたけど、よく考えたらそれってアドベンチャーゲームが済ませてるな。そこから少し捻ると、マニュアルとか技術書は利用者に応じて文章が変化していったりするといいよなーと思ったりする。読み飛ばすところもあるし、読む順番も人によって変わるのだから、その人の読みたい感じに構築されるようなのはどうかなーと。

ともかく、既存と比べて劣ってるところを何とかするのに注力するのはほどほどにしていいんじゃないかなー。コストに対して得られるものの上限は見えてるわけだし。対処するにしてもそのまま再現するんじゃなく、エッセンスを抽出して取り入れる方向で考えたいなと。

Tech Deep Dive #2 in Osakaに参加して思ったこと

techdeepdive.connpass.com

Tech Deep Dive #2 in Osakaに「ブログ書いてくれる人」の枠で参加したので、書きます。枠空いてたので一般参加枠でもよかったんだけど、なんとなく。

Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか reloaded

www.slideshare.net

再演ということでスライドは公開されています。reloadedということでいくらか更新/調整は入っていますが、大筋はこの通りでした。

話は「性能」と「可用性」をポイントとしていて、その背景に「クラウドにより技術がコストに直結する」という話は新鮮でした。性能が悪いと高価なインフラが必要になる。即時復旧やデータ整合性がコストに直結する。オンプレだと初期に固定されていたものが可変なパラメータとなったことで浮き彫りとなっている形ですね。

よくあるWebアプリケーションの構成をあげて、性能や可用性の面でどこが問題となり得るか。ある程度簡略化された構成だからこそ、それぞれの場所と結合部分に何かしらの問題がありえることは当然かと思います。これはスライドの図がわかりやすいですね。

https://image.slidesharecdn.com/techdeepdivewebapplication-171222125018/95/web-15-638.jpg?cb=1513947306

ああ、うんあるある。

タイトルの「高レイテンシ」を話は、ECサイトでどれだけの人数の同時購入を短時間に捌けるかと言ったシナリオ。パターンとして2種類、10,000商品に購入がそれなりに分散される場合と、1つの商品に購入が集中する場合。スケールアウト/スケールアップが効きやすい前者と、スケールアウト/アップが効きづらい後者というわかりやすい対比ですね。ここにキャッシュとインメモリデータグリッドのアプローチがどのような影響があるかの実測値で示され、確かにそうなるよねーと。

アーキテクチャや計測結果から読み取れることの説明を通して「この場合はこういうことが考えられる、こういう問題が起こり得る」と言った話が入り、実践する前に知識として持てているとだいぶ違います。

事象を聞いていると、2014年のJavaDayTokyoでせろさんが話された 実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡 の「DBがボトルネックなのに
 なんでAPサーバを
 スケールアウトするの?」とかを思い出しました。

https://image.slidesharecdn.com/anvg5ezbspmdzm9xoszp-signature-c1ca481fcc7191d99b160983ee307625e1b596fe1469c0d72735ca8985e1d83a-poli-141115014132-conversion-gate02/95/java-66-638.jpg?cb=1440743796

キーワード

  • 今の負荷は将来の負荷ではない
  • 障害の復旧時間を(事前に)測っていますか?
  • クラウドだと気軽にスケール頼りになっておかしくなる

もしもみなみんがアプリケーション開発者だったら

www.slideshare.net

前の話をうけて別の視点から、連続セッションだからこそできる話だと思いました。「構成を考えるのはできるけれど、実際作るのは難しい」とか、パフォーマンスの問題になったら「気軽に並列度をあげてたりすると、別のところに予期しない影響を与えるものだから徐々にしましょう」とか、「シャーディングは適切に分散されるように設計しないと効果がない」とか。

セッションはオペミスや性能などのよくある問題を挙げて、それに対する一般論の解決案が起こしうる問題の説明、理想的な解決や現実的な解決の提示という形で構成されていました。いくつかは踏んだこともあり、心当たりがありそうな参加者も多かったのが印象的でした。

インフラ側の言葉は初耳なものも多かった。

キーワード

  • 時間↓ = 処理量↓ / (速度 * 並列度)↑
  • まずは処理量をなんとかしましょう

感想

前提知識のハードルが高めに感じましたが、内容自体は一般的な知識の範囲で説明できるものだったと思います。それらを繋ぎ合わせてひとつなぎにしているところにこのイベントの価値があるのかなと思いました。ここで話された一通りを3時間程度で話せる気はしないので、素直にすごい。

一般的な知識の範囲とは言うものの、ギリギリいっぱいまで満たされていたと思います。ここから踏み込んだら現場の背景も全部入れないと的外れで「あー、うん、そうですよねー」な話にしかならない気がします。

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

以下、ポエム

仕事スイッチが入ってしまい、純粋に技術の話として楽しめなくなったポエム書きます。「Tech Deep Dive」に技術だけを求めた私の期待が外してただけなんでしょうけど、「おースゲー!なるほどー!」ってなりたかった。

事前にパフォーマンスを含めてアーキテクチャを検討する。もちろん重要なのですが、そんなの考えても仕方ないから今は考えないでおこうぜというバランスがあります。例えば「今はそれは考えない、何故なら・・・。このような条件が整ったら検討をはじめ・・・。それで間に合うように・・・・。」と言った判断を保留するアーキテクチャを採用する(かどうかすらも判断する必要があります)。このような「今は考えないでおこうぜ」という判断をするために、このイベントでの語られた知識は持っておく必要はありますが、その道具を常に振るうべきかというと否です。このバランスを取れない人にはミスリードになるのではないかと思ってしまいました。(そういうエンジニアは存在して、悪いとは言いづらいのだけど、そういう人が「エンジニアは話が通じない」と思われる原因になってるよなーというのもあって、もにょもにょ……)

例えば「10,000商品」と「1商品」と言ったシナリオがありましたが、これもECサイトならよくあるのかもしれませんが、そのプロダクトが扱う業務の性質としての取捨選択の上で成立するものです。少なくとも「1商品に注文が殺到し、それが同期処理でなければならず、待たせることがビジネスリスクだったり、本来得られるはずの利益を損ねる」ところまでが前提であり、そうでないものには無用の長物です。もちろんそんなことは当然の前提としているのだとは思うのですが、なんとなく「こういうのがあったらよくないですか?」みたいなところから銀の弾丸臭がすごく感じました。技術ってそういうものじゃない、と私は思ってます。

「インメモリデータグリッド最強」で話が終わるところにはなんとも言えません。この解決策が招く問題もあり、そちらを対処できなければ他のところに問題が移動するだけです。他と比べて重視しているものが違うという口頭でのやりとりもありましたが、それまで他のアーキテクチャでの懸念を挙げていたのにここだけ語られなかったところに疑問はありました。もちろん「でも、お高いんでしょう?」という話もありましたし、ハードウェアスペックがボトルネックにならないのも前提として提示されてはいますが、インメモリデータグリッドがパフォーマンスを発揮する前提条件がそもそも満たされないことも多くあります。認知度が低いのも確かに事実ではあるのですが、ミッションクリティカルシステム以外で使われない理由はそれだけではないわけで。

また気になったところとして、「アプリはインフラを意識したくない」というものの実現手段。疎結合は意識するところなのですが、「これで意識しなくていい」という方法がDAOの実装差し替えだとすると、これは多くの場合アプリケーションエンジニアの意識すべきレイヤーにあります。SQLを書かない世界(JPAでJPQLすら書かない場合などでしょうか)では妥当なのかもしれませんが、データベース設計などがアプリケーションエンジニアの守備範囲にある以上、意識せざるを得ない状況は変わりません。これを下手に「意識しなくていい」と言ってしまうと不適切に伝わる現場もあるのは悩ましいところですね。

金の弾丸は大抵の場合に有効です。適切なところに投資すれば、多くの場合にコストは抑えられるものです。一方、慎重になりすぎてか単にケチなのかはわかりませんが、このイベントで語られたようなものに一切手を出さず、独自技術症候群なのかなんなのかは知りませんが、力技で手当たり次第に場当たり対処して結果的に高くついているプロジェクトも多くあるのも悩ましいところです。

このイベントに限らず、アプリ/インフラと分けられた文脈で「意識しなくていい」「考えなくていい」という話はよくされます。でも「考えなくていい」というのはちょっと違うんじゃないかなと思いました。むしろ考えないためは知識を持つ必要があるはずです。知らずに領域を侵すことは頻繁にあり、それは知識が無いと止めるすべはありません。認知の外ってやつですね。知った上で、考えないでいいようにと言うよりも、邪魔しないように、適切に扱う必要があります。こういうものに「意識しなくていい」「考えなくていい」「勝手にやってくれる」となった瞬間に、なぜか「その領域の知識を持たなくていい」と解釈されるものなんだよね・・・違うよね。

とかなんとかだらだらと書きましたが、イベントも話もとても良かったとは思っています。長時間セッションで疲れたってのはありますが、続けて開催されるなら参加したいなぁ。

ベタープログラマ第二部の感想

第二部「練習することで完璧になる」を読みました。

読んだのは15,16,17,19,22章。15章は16,17章を読んでたら「我々のチームの三つの規則」として触れられてたので。

15章 規則に従って競技する

いろんな規則があるけれど「自分達で決めた規則が必要」とあります。規則は自分達のためにあるってやつですね。著者のチームでは以下の3つの規則が挙げられています。

  • 単純に保つ
  • 頭を使いなさい
  • 変わらないものはない

これらの規則についてはそれぞれ別の章で語られていて、15章は規則のありかたが書かれています。この章で重要なことは、要点の囲みにも挙げられているこれだと思います。

曖昧で記述されていないチームの「規則」に頼らないでください。暗黙の規則を明示して、コーディングの文化を統制してください。

たまに見るのが、暗黙の規則が勝手にあると思い込んで「こうしないといけないと思っていました」「こうするものじゃないんですか?」というの。自分の書いたコードを説明するのを阻む、思考停止の臭いがします。こういうのを私は「呪い」って呼んでて、その解呪の方法の一つかなと。そもそも自分達で自分達のための規則を作れるなら、そんな呪いにかからないと思うけど。

16章 単純に保つ

KISS(Keep It Simple, Stupid)のことかと思ったし、確かにKISSについて書かれてました。けど単純とは何かってところに踏み込んでます。昔似たようなこと書いたなーと思ったので引っ張り出してみる。

コードに凝れば凝るほど、コードはシンプルになり、言われるような "凝ったコード" から離れていくと思う。

さて、本では単純さを「誤った種類の単純さ」と「正しい種類の単純さ」の2種類に分けています。

「誤った種類の単純さ」は、物事を単純に捉えてしまうことで「極度に単純化されたコード」を生み出し、逆に物事を複雑にしてしまうことになると書かれています。これは心当たりがある方も多いでしょう。そして「正しい種類の単純さ」を保つためにどのようなアプローチをとるかが挙げられています。

コードのエントロピーも増大していくものです。ですが、増えるのを放置して手に負えなくなったらスクラップ&ビルドする以外にも、抑える方法はあるはずです。私の場合、例えば修正前後のコード量を見ます。コード量が想定以上に増えていないかってところですね。なんなら機能追加してもコード量が減っていなかったら、余計な複雑性を作り込んでいないかを確認します。数字はあくまで指標の一つでしかないので、使い所に注意は必要ですが。

17章 頭を使いなさい

この章は16章を前進させる規則ですね。曰く「Keep it simple, stupid. don't be stubid.」と。愚かになるのは典型的なギークの問題であr、コーディングの専門家でもやってしまうのだから、仕方ない。でもそれは愚かなままでいていいと言う意味ではありません。ちょっと時制に込められた意図が読み取りづらい章だなーとは思いましたが、勇気を出して失敗を認めて誤りを直そう、とかそんな感じです。愚かなコードや設計をしたからといって、「自分を失敗者と考えないでください」とあります。失敗はしていい。

「愚かなコードを書かないでください。」「不注意にコードを書かないでください。」などと書かれていますが、これはちょっと難しいかなー。書いたコードを落ち着いて見直して、直したい。私は。

さて、この章で抜粋したいのはこの文章。

あるコード部分に取り組むときには、その形と構造に関して意識的な決断を行なってください。コードを所有してください。そのコードに対する責任を持ってください。

「意識的な決断」や少し前に使われている「説明責任」などは普段使っている言葉に近くて共感を持てました。 コードをどまんなかに // Speaker Deck とかで言ってるつもりです。

19章 コードを再利用するケース

再利用のケース4種類が挙げられて、それぞれについて考察されています。一つ目の「コピー&ペースト」はすごく嫌ってますね。ウェブ上で見つけたコードをそのまま貼り付けるな、とかも書いてます。なんか微妙な感じのコードがコミットされてる時とか、それをググったらコメントまで一致するのが引っかかってくるとか、たまにありますね。ああ言うのをやめてほしいなーってのは同意。でもコードのコピペ自体は私はよくやるんだよなぁ。昨日もやったし……。

22章 凍結されたコードの数奇な人生

コード凍結に対する、どのようなものがコード凍結と呼ばれるものにあるかが整理されています。もちろんブランチ戦略による凍結のない世界についても語られ、凍結しない世界を目指してほしいとも書かれています。

この辺はいまだに過渡期だなーと思います。凍結せずにできているもの、凍結させずにできないかと試行錯誤しているもの、凍結ありきから変化しない動こうとしないものも多くあり、その中には凍結しないことがメリットにならないものもあります。とはいえもはや凍結ありきの世界観ではないので、対応できる術は持っておかなきゃでしょうね。

第二部の感想

普段言ってることに近いこともあってか、正直薄味でした。どの章も短めだったし。他の人に説明するときの語彙は増やせたかなーくらいで、この部に書かれてることから新たなことを見出すのは難しい感じでした。見落としてるだけかもしれないけれど。

一方、ここまで書いているようなことを「はいはい、あのことねー」とならない方は読めば知の高速道路に乗れるかもしれません。エッセイだけあってちょっと他の本には書かれてないものなので、お勧め。

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック