clavierのブックマーク - はてなブックマーク

人の作ったWebアプリケーションのコードを見るときに注目しているところ - Runner in the High

普段見ているものをなんとなく書き出してみた。インターフェイスあえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。バリデーションロジックすべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのか

clavier 2020/03/26

リンク

ElmでBrowser.elementを使いつつルーティングを自前で作る - Runner in the High

一般的にElmでルーティングを行うSPAを作る場合にはBrowser.applicationを使って、組み込みのルーティングの機構を使うことになる*1。しかし、一方でルーティングの仕組みを持たないBrower.elementやBrowser.documentでも、ルーティングをJavaScriptサイドで自前実装する方法がある。 elementを使いつつルーティングを自作したいユースケースとして、ReactやVue.jsと統合してElmを使いたいケースが挙げられる。applicationやdocumentを使うと特定のDOMのみにElmアプリケーションをマウントすることができないため、他のフレームワークと共存させることができない。なお、elm/browserのリポジトリにも「Browser.elementでルーティングをするにはどうすればよいか」を説明した詳しいドキュメントがある。 gi

clavier 2020/03/24

elm

リンク

Elmをプロダクトで一年書き続けた感想 - Runner in the High

この記事はElm Advent Calendar 2019最終日の記事です。去年末あたりから現職のチームでElmを書き始めたので、大体1年程度はプロダクションでElmのコードを書き続けたことになる。学生時代はRubyとJavaScriptばっかりだったので、関数型プログラミングとかそういうバックグラウンドは一切なかった。その観点から、改めて率直な感想を申し上げておく。なお、弊社フロントエンドチームとElmに関するはなしは、私の書いたFringe81アドベントカレンダーの記事を参照のこと。 fringeneer.hatena blog.com Elmには中毒性がある Elmを触ったことのない方からすると「？」になるかもしれない（というか、昔の自分がそうだった）が、率直に言ってElmには中毒性がある。一度Elmを知ると、Elm以外の言語を触るたびに「これ、Elmだったら〇〇なのにな〜」と思う

clavier 2020/01/24

リンク

クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High

何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている