Toy と帽子と ADP BE

主にプログラミングに関わる話をゆるくエモくやっていきます

スマホのない生活 3日目

突然の別れ

スマホが突然お亡くなりになりまして、今日で三日経ちました。

で?

何か困ることがあるのかというと特に困りません。

私がスマホですることといえば、基本ネット見るか、ゲームするかだけなので。電話は年に数回しかする機会ないし。チャットアプリは、たまに仕事の連絡にで必要になることはあっても、それ以外では奥さんとしかやり取りしないから特に差し迫った問題でもない。カメラも特別なイベントでもない限り使わないですねそういえば。

ただし

知らぬ間に自分が書いた記事のコメント欄が(また)炎上しているのにすぐ気づけなかったりするのでちょっと困りました。

本当に、地味に、辛いこと

私は普段スマホをおしりのポケットに入れているんですが、持ち歩いていない今でもつい手がそこに伸びるわけですよ。で、そのたびに

(あ、スマホなかった)

と、なったあと

(ていうか、ケツでかっ)

って思わざるを得ないのが地味に嫌です・・・。

実は今年、9kg 痩せたしウェストも 5cm 減ったんですけど、おしりはなかなか痩せないんですよね・・・。

サービスと階層の話

【大阪】9/16 現場で役立つシステム設計の原則 読書会【第5回 in 豊中】 - connpass に行ってきました。その中で、私にめちゃくちゃ刺さったことについて書き残しておこうと思います。

なお、『現場で役立つシステム設計の原則』では、第5章の話に相当します。それプラス、読書会で出た話や、私個人の感想が含まれます。

要約

  • サービスは単機能で作る
  • 複数のサービスをひとつのまとまりとして扱いたいときは、単機能のサービスを複数まとめた新しいサービスを作る
  • 階層は必要になった時に作ればいい
    • 階層ありきで設計すると、無駄なクラスをつくるハメになる

感想

ずっと悩んでいたわけですよ。どの階層に何を置けばいいのか、どのように階層を作ればいいのか、ということに。

古くはいわゆる MVC やその亜種に悩まされてきましたし、やれ DDD だやれ Clean Architecture だと言っている今でも、サービスって何さ?ユースケースって何さ?モデルって何さ?ってよくわからなくて試行錯誤して階層を分けたり分けなかったりしているのです。しかし、どうしてもどこかにただデータを横流ししているだけのようなクラスを含む階層ができたり、逆に色んな要素がつめ込まれてしまうクラスができたりしまいます。どうしてもどこかに歪が出てしまう。

でも、無理に階層を分けないで、小さい単位で組み立てていって、ある程度まとまった固まりに対して必要となった時に初めて階層を用意するとしたら? それは確かに、より自然であるように思えます。

最初から○○層!って気合を入れる必要なんてなかったのです。階層ありきで作るから、○○層って何書けばいいの?とか、書いては見たけれど本当に必要なのかどうかわからないようなクラスができてしまっていたのです。

そんなわけで、これからは必要なものを必要な分だけ書いていこう、と思ったのでした。

余談

PHP の有力なフレームワークである Laravel ですら「モデル」に対しては完全に振りきっていて

多くの別々の人達にとって、その意味合いは様々なため、"models"という言葉の定義は曖昧であることに私達は気づきました。ある開発者たちはすべてのビジネスロジックを総称してアプリケーションの「モデル」と呼び、一方で別の人達はリレーショナルデータベースに関連するクラスを「モデル」として参照しています。 ディレクトリ構造 5.5 Laravel

とかいいだす始末です。(まあ実際そのとおりなんですが)

余談その二

『現場で役立つシステム設計の原則』の第3章を初めて読んだ時、なぜか今回の話に出てくる(古き悪しき)MVC を想起*1してしまって「えええええ?」となってしまったのでした。もう一度読むと全然そんなことは言っていないことがわかったのですが・・・。あの感覚はなんだったのだろうか?

*1:フラッシュバックと表現したほうが適切かも

『現場で役立つシステム設計の原則』という本に対して思うこと

前置き

「現場で役立つシステム設計の原則 読書会」に行ってきました。

kansaiddd.connpass.com

で、所感とか書こうかと思ったんですけど、勉強会の内容そのものよりまず『現場で役立つシステム設計の原則』という本に対して思うことが膨らんできたので、一旦そこだけにフォーカスした内容で一エントリ書くことにします。

この読書会自体は恐らくあと十回くらい続くので(十回で済むんかな?)、そこで得たものはおいおい現場やブログでフィードバックできたらいいかなと思っております。

『現場で役立つシステム設計の原則』という本に対して思うこと

基礎知識

第一章を読んだ時点の感想が「うわこれオブジェクト指向の基礎知識は必須だよな」、第二章を読んだ時点では「うわこれ少なくとも Effective Java に挑戦できるレベルは最低限必要じゃないか」。 そこで、次に十章を流し読みしてみました。章のタイトルが「オブジェクト指向の学び方と教え方」だったので、もしかして前述の OOP に対する前提知識がそこで身につけられるようになっているのかなぁと思って。でもそこに答えはない、ように見えます。「こうすればオブジェクト指向になります」ってことは書いてあるっぽいんだけど、「何故そうすることでオブジェクト指向になるのか」については書かれていない、ように見えます。

じゃあやっぱり、オブジェクト知識の何たるかは前提として持っているかなんとかして自力で身につけないといけないっぽい。

行間

今回の読書会自体に対する感想として、「みなさんめちゃくちゃ行間を読み込んでるなー」というのがありまして。また、Twitter やブログでも、異口同音に「考えさせられる」という感想が目立っているように見受けられます。また、読書会の中で「この本は徹頭徹尾各論しか書かれていない」って話題が出てきました。

つまり、この本は行間を読めないと全く読めたことにならないのではないかと。

なまじ読みやすい本なだけに、考えずに読んでいたら「あーそうそう、そうだよねー」で終わってしまう危険性があって怖いです。

もうちょっと考えてみた

そんなことも踏まえつつ、読書会から帰ってからいろいろ考えていたんですが、結局この本に書かれているのは著者が直面してきた「ドメイン」に対しての解の一つ、でしかないのではないかなぁ、と。もちろん普遍的に通じるところもいっぱいあるというか、普遍的に通じる部分を、書籍として普遍的に通じるように表現されているとは思うのですが。

なので、自分自身に生かそうと思えば、考えないといけない。めちゃくちゃ考えないといけない。 それはもちろん何においても当たり前といえば当たり前のことではあるのですが、この本は相対的にも絶対的にもかなり高いレベルでそれを要求してくるのではないか、というのが現時点での私の印象です。

現時点での結論

OOP がわかってないといけない。Effective Java 挑戦レベルは最低限必要。字面だけを真に受けてはいけなくて行間が読めなくてはいけない。自分自身に適用しようと思えば、その答えは自分で導き出さなくてなならない。取っ掛かりにはなるかもしれないけれど、うっかりしていたらそこに取っ掛かりがあることすら気付けない。

取っ掛かりが見つかったようにみえても、表面的なものだけ受け取ったら大変なことになりかねない。具体例で言えば(勉強会でも話題になりましたが)共通する処理はメソッドに閉じればいいよって話ひとつとっても、意味的なものを考えない人がそれをやったら、処理がほとんど同じなら共通化してしまって なんとかUtil に放り込んで、ほとんど同じだけどちょっと異なる部分はフラグを付けて対応して、結果的にメンテナンスがむしろ大変になって、結局なんのために共通化したんだって話にしかねない(なりかねない)。 そんな危険性がある本だなー、というのが現時点での偽らざる感想です。

いろいろ考えられるとても面白い本であることは間違いないし、買ってみて、読んでみて、よかったということは間違いないです。 でも、読みやすいから初心者でも読んでいいんじゃないかという意見には個人的には賛同しかねるなー、という感じ、ですかね。

「関西Javaエンジニアの会 - クラウド・ネィティブ」に行ってきました

日本の二代目 Java Champion こと、てらだよしおさんのマイクロサービスにまつわるおはなしをがっつり聞いてきました。

私自身が、インフラ力がないというか、そもそもインフラに興味がない(おい)、ので、そういう話はこの記事にはあまり出てきません。あしからず。

寺田さんの今年のテーマ

寺田さんいわく、去年はマイクロサービスやら DevOps の話やらを色んな所でしてきたが、その感想として、現場の実情とあまりにも乖離していてどうしていいかわからないとか浮世離れしているなどと言った感想を多くもらったそうです。(あー、すいません私もその中の一人です・・・。) なので、今はどこから始めればマイクロサービスに近づいていけるかということを念頭に置いて話されているのだそうです。

マイクロサービスは

銀の弾丸ではない

まあ、この業界、何事に置いても銀の弾丸など存在しなくて、もちろんマイクロサービスも例外ではないということです。ただ、マイクロサービスに関わる技術を身につけておくことはもちろん重要であると。そして、その技術の使いみちを正しく見極められることが重要とのこと。

正しく管理できないとすぐ破綻する

それはまあインフラに詳しいわけではない私でもわかります。

それにすればハッピーになるのではない

自分たちのサービスに合ったものを、自分たちで組み合わせないといけない。デザインパターンはあるにはあるけれども、それをただ適用しても何も上手くいかない、と。 それは何においてもそうですね。寺田さんはアジャイルを別の例としてあげられていました。言われてみれば、椎葉さん (@bufferings) の結果的にスクラムになってる!なのがいいと思う! もそういう、(スクラムという)型にこだわるのではなくチームが必要とするものをまずやっていこう、というお話でした。

何に向いているか

スケーラビリティの向上やサービスの独立性を高めることは、マイクロサービスでなくとも可能。変更に強いシステム作りや耐障害性を高めるなどがより向いている、とのこと。

今までの技術の延長線上

これが今回一番私に刺さった話。また、話の前半と終盤で同じことを繰り返されていたので、寺田さんも大いに伝えたいことだったのではないかと推測。 マイクロサービスは、あくまでも今までの技術の延長線上にあるのであって、突然変異で出てきた救世主などではないということ。これが何を意味するかというと、今までの技術でちゃんとできていないことが、マイクロサービスに変えただけでちゃんとできるようになることはない、と。ましてや、マイクロサービスにすると考慮することが増えて、正しく管理できないとすぐ破綻するわけですから。

マイクロサービスにするには

ここから先は、より具体的で実践的なお話が続いたのですが(もう眠いので)特に気になった部分を箇条書きで。

  • 共有ライブラリは呪縛
    • まったく同じライブラリでも全てのサービスが一つの場所を見るのではなく、サービス毎に別々に管理するように。今ならバージョン管理するためのツールは揃ってるからできるよね、というお話。
  • 外部リソースの設定は環境変数を使おう
    • あれ?System#getEnv とか昔は Deprecated だったよね?ってちょっと思った。(って、いつの時代の人だよ)
  • 障害は起きる(必ず起きる)
    • そこで、起きないように努力するのではなく、起きても大丈夫なシステムを作ることを考えたほうがよい。

KANJAVA PARTY 2017 !!! に行ってきました

各セッションの感想

Spring Security にできること・できないこと

opengl_8080 さん。セッション資料

Spring Security にできること・できないことが理由付きできれいにまとめられていました。 例えば

  • Spring Security は ServletFilter を利用しているから、そこで対応できない脆弱性はそもそも対処しない(できない)
    • SQL インジェクションとか
  • セッションID自体の管理は Servlet の仕事なので、Spring Security は責任を持たない

などなど、とにかくとても明快でした。

あと、個人的に印象的だったのは、CSRF のチェックは(デフォルトでは)メソッドが GET, HEAD, TRACE, OPTIONS 以外 でしか行われないということ。

つまり Spring Sequrity 自身は、ちゃんと Web のお作法を守っているし、お作法を守っているアプリケーションのセキュリティは守るけど、守ってないアプリケーションは知らないよ、ってことですよね。そういうポリシーが見えて面白かった反面、見方を変えればお作法を守っていないとハマるってことだし不勉強だととても危ないってことなんですよね。

(2017-06-27 追記)

opengl_8080 さんから直々に Twitter でご指摘をいただきまして、対象のメソッドは設定によって変更が可能ということと、とはいえメソッドを正しく実装することが推奨される旨がドキュメントに記載されているとのことです。 (2017-06-27 追記ここまで)

メソッドを適切に使い分けるというのは、今でこそ REST API とかの文脈があるから当たり前になりつつあるのではないかと思ってはいるのですが、昔はこんなこと平気でやったりしましたやん?

// コードは簡略化してます
void doPost(req, resp) {
    doGet(req, resp);
}

え、してない?

あと、会場が会場ということもあって言葉を濁されていましたが、(控えめに言って)edge は脆弱性の検証に使い勝手がよいということはわかりましたw

普段使いのDDD

haljikさん。セッション資料

DDD は全く勉強したことがなくて、まあ悪く言えば食わず嫌いの状態でした。別の勉強会で、DDD と同じく食わず嫌いだった TDD にリアルに触れられる機会があって、そこでいろんな気付きを得ることができたので、今なら素直に食わず嫌いせずに DDD も受け入れられるんじゃないかと思って今回このセッションを選びました。

そこで、個人的に今回一番衝撃的だった言葉に出会います。

『利用者が「ここ」を「こう」したいという要望に対して、「ここ」を「こう」するだけで変更できるようになっていれば良さそう』

『利用者のいう「ここ」をこうしたいの「ここ」がコード上のどこを指すのか?』

この話を聞いた時、本当に比喩でも誇張でもなく、ちょっとだけ涙腺が緩んだ。私にとってはそれくらい衝撃的でした。衝撃的すぎたので、恥ずかしながら何度もツイートしてしまった・・・。

現実に立ち返ると、よくない DB 設計の上によくないソースコードが載っかっていて、一つ直したら別のところがバグるなんてよくある話で、ソースコードのどこを触ればいいかなんて直感的にはわからなくて、それをどうにかこうにか繋いでいて(でもそもそも繋げられないどころか平気でぶち壊すような人もこの業界には腐るほどいて)みたいな絶望感があって・・・。

でも、たとえば DDD はそれを解決するためのヒントを持つもののうちのひとつであるのかも、という、光が見えたというか希望をもらったというか、そんな感情が私の涙腺を緩ませたのではないかって気がします。

でも、前提が「利用する言語は息をするように書けないとしんどい」って、もちろんそれで飯食ってるんだから当たり前といえば当たり前なんですけど、私自身ももちろんのこと、チームメンバー全体のレベルとか、この業界全体のレベルとかも含めて考えたらやっぱりきついよなー・・・。

Introduction to JShell: Official REPL Tool for Java Platform

吉田真也(@shinyafox)さん。セッション資料

OpenJDK のコミッタである吉田さん直々の JShell の解説。

IDE 上で main メソッド込みのテストクラス作ってテストコード書かなくてもよくなる!前方参照してくれるから、呼び出すクラス、メソッド、フィールドをあとから定義しても怒られない!これは便利。はやく Java9 でてくれー。しかし

Java9 は(うまくいけば)9月リリース

あと、API の仕組みはなんか面白いことできそうかもと思った。具体的になにをどうできそうかは全く見えてないけど。

それから

プラグインを「僕が作りました」

これ最強。

Kafkaを使ってイベントを中心にしたアプリケーションを作ってみる。Spring Cloudにのせて。

椎葉 光行(@bufferings)さん。セッション資料

本人が「ゆるーく話します。関ジャバなので。」って言ってたので、ゆるーく聞いてました。(うそ) いや、正直なところは、私のスキルも興味の範疇も逸脱してるのでゆるーく聞くしかなかったんですが。(結局ゆるーく聞いている)

実装くらいは後でゆるーく読んでおきますです。

DevLOVE関西からギルドワークスへの越境

中村 洋(@yohhatu)さん。セッション資料

中村さんがDevLOVE関西の前説でいつも話されている話がとても深く広く掘り下げられていたという印象でした。

DevLOVE関西は素振りの場です、現場に持ち帰って実践しないと意味ないです、とか、そういう話に、今回の話によるDevLOVE関西の結成の経緯や継続の意味が乗ることによってより強く理解できたというか。

ただ参加するだけで満足していてはいけないし勉強会で得たものは具体的に生かしていかなければならないという思いを新たにすることができました。

具体的な内容としては、視座は高く持つ、でも高く持ち続けていると実装レベルにリーチ出来なくなるから降りていくことも大事、という話が一番印象的でしたね。 わたしなんかは、油断すると実装レベルに閉じこもろうとするから、それ以前の問題なんですけど・・・。

オフショア開発にも応用可能!? リモートチームの道具箱

粕谷大輔(@daiksy)さん。セッション資料

結局、リモートは情報量が落ちてしまうリスクを、いろんな工夫や道具を使ったとしてもどうしても落ちてしまうから難しいということなんですかね・・・。 あと、結局はコミュニケーションを取ろうとする人自身の努力が当然ながら必要ということ。

感嘆符とかの大げさな感情表現の話なんかは、私も余裕があるときは心掛けているつもりですけど、感情が高ぶったり怒ったりしてしまったときほど表現に気を使う余裕がなくなっていて、残念ながら緩和が本当に必要になるべきときほど結局は冷たい表現になってしまいがちだったりします・・・。

全体の感想

とにかく勉強になったし、楽しかったし、快適に過ごせました。 改めて、スタッフの皆様、登壇者の皆様、参加者の皆様お疲れ様でした。ありがとうございました。

余談

私もそろそろ、登壇することを念頭に入れていくべきかなぁと思ったり思わなかったり。(登壇するとは言ってない)

色んな意味で、帰ってきました

ブログを書くのはたぶん初めてです。

昔、公開していたウェブサイトに自作の cgi スクリプトを使って日記を公開していたことはあります。このブログのタイトルはそのウェブサイトから持ってきました。タイトル考えるの面倒くさかったから。

実は、mdstoy 的なものではない別の名義で、はてなダイアリーというところで日記を書いていたこともあります。はてなスター事件以降はてなは絶許だったんですが、そろそろ許してあげようかなと思って まあいろいろ考えたすえ、ここに帰ってきました。

まあ、主に技術的なことをゆるゆると書いていこうと思っています。よろしくお願いいたします。