サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
www.izumisy.work
「Railsやってる人たちってドメイン層にvirtusとかinteractorとかサードパーティのライブラリが現れるのってどう思ってんの」という雑なツイートに対してROM.rbやdry-rbシリーズの作者であるPiotr Solnicaが優しくリプをくれた。 One rule of thumb is to rely on your own interfaces, even if it means having a small wrapper around a simple 3rd-party API. This is what gives you more control, and this is what makes it much easier to upgrade gems along the way once something stops working (for whateve
普段見ているものをなんとなく書き出してみた。 インターフェイス あえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。 言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。 バリデーションロジック すべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのか
一般的にElmでルーティングを行うSPAを作る場合にはBrowser.applicationを使って、組み込みのルーティングの機構を使うことになる*1。しかし、一方でルーティングの仕組みを持たないBrower.elementやBrowser.documentでも、ルーティングをJavaScriptサイドで自前実装する方法がある。 elementを使いつつルーティングを自作したいユースケースとして、ReactやVue.jsと統合してElmを使いたいケースが挙げられる。applicationやdocumentを使うと特定のDOMのみにElmアプリケーションをマウントすることができないため、他のフレームワークと共存させることができない。 なお、elm/browserのリポジトリにも「Browser.elementでルーティングをするにはどうすればよいか」を説明した詳しいドキュメントがある。 gi
Rubyで特にRailsを使う際に「特定のドメインの変化によって別の処理の実行をトリガする」みたいなケースでは大抵の場合コールバックが使われる。 しかし、ぶっちゃけた話コールバックはかなり結合度の高いコードになってしまいがちで、実装的にスケールさせるためにはドメイン・イベントを使うほうが健全であると言える。 martinfowler.com 以下の記事はActiveRecordのコールバックがどのようなときによろしくない感じになるかを説明しており、非常に参考になる。一言で言うと、コールバックを使うことモデル自体に副作用が埋め込まれてしまう。一方でドメイン・イベントを使うことで、副作用がなにをするものなのか(メールを送る、外部のmBaaSを更新する、モニタリングサーバへメトリクスを送信する、等)を意識しないでよくなり、疎結合になる。 techracho.bpsinc.jp さて、ドメイン・イ
テック系の学生というと、やはりいろんな会社のインターンに参加していろんなイケてるナウい技術を触って「圧倒的成長!」を求めますよね。 自分もそうでした。 自分はかなり極端な例で、大学を1年休学してまでインターンしてコロコロと会社変えながら10社くらいは行きました。 今思うと楽しかったしお金ももらえるし最高じゃんって感じだったんですが、ぶっちゃけじゃあインターンしまくってずっと成長してたかって言われると微妙です。 会社によってはただバグ潰したりするだけのインターンもあったりして、いわゆる限界効用逓減にぶち当たってただコードをかいてるだけの学生だった気がします。 あとはやっぱ学生でコードかけるとすごいチヤホヤしてくれるのでそれが嬉しい、みたいな。 いまでこそ社会人になって仕事でコードを書くようになったんで分かるんですが、別に起業家じゃなくともエンジニアだって自分のビジョンが必要だよなって感じます
このDiscourseスレッドがかなり面白かった。 OPは「幽霊型(Phantom Type)を使うと特定の順序でしか型安全に状態遷移できないように実装できると思うんだけど、どうしたらいいかな?」と質問している。 discourse.elm-lang.org 実装してみる 回答者からのアイデアによると、Phantom TypeとExtensible Recordを組み合わせて実装することで型安全な状態遷移が作れる。 たとえば、以下のようなゲーム上での状態遷移のパターンが仕様としてあるとしよう。 これを実際に今回のパターンで表現すると、このようになる。 type Transition a = Transition type Allowed = Allowed type Game = Loading (Transition { ready : Allowed }) -- ロード中 | Read
この記事はElm Advent Calendar 2019最終日の記事です。 去年末あたりから現職のチームでElmを書き始めたので、大体1年程度はプロダクションでElmのコードを書き続けたことになる。学生時代はRubyとJavaScriptばっかりだったので、関数型プログラミングとかそういうバックグラウンドは一切なかった。その観点から、改めて率直な感想を申し上げておく。 なお、弊社フロントエンドチームとElmに関するはなしは、私の書いたFringe81アドベントカレンダーの記事を参照のこと。 fringeneer.hatenablog.com Elmには中毒性がある Elmを触ったことのない方からすると「?」になるかもしれない(というか、昔の自分がそうだった)が、率直に言ってElmには中毒性がある。一度Elmを知ると、Elm以外の言語を触るたびに「これ、Elmだったら〇〇なのにな〜」と思う
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの?」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
https://www.quora.com/What-happens-to-older-over-30-programmers-Do-they-get-fired-as-they-get-older-and-less-innovative-Does-mid-career-pay-increase-much-for-software-engineers/answer/Bruce-Hoult ぼくは今年で55歳になる。81-84年ごろに大学を卒業して、働き始めたのが85年だ。同年代のプログラマーは多くなかったし、それに私達以前にはプログラマーはいなかった。もし君がITの領域で仕事をしようと思うのなら、競い合うことになるのはおそらくぼくらのような歳の人間ではなく、きみより5,6年ほど若い人間たちになるだろう。 で、どうしてるかって? まだコードを書いてるよ。 僕らが基本的に大学で扱っていたのはP
過去に「NoRedInk*1の筋肉の人」としておなじみリチャード・フェルドマンをフィーチャーする記事を書いたので、今度は自分をフィーチャーしようと思う。 www.izumisy.work おすすめはやはり一番最後の「jQueryからElmまで」だが、正直このスライドはElmに関する説明成分が少なかったと反省しているところがある。なので、個人的にはこの記事で並べている順番に見てもらうほうが、Elmに対するわかりが生じやすいと思う。 Elm, the functional frontend Elmの基本的な部分をざっくり説明するスライド。このスライドは関数型プログラミングカンファレンス2019で使った。Elm意外にもRustやElixirなどの関数型プログラミングのエッセンスを持つ言語の人たちとコラボレーションするタイプのイベントだったので、関数型的な部分に言及するのは少なめでElmの良さをア
元ネタはこれ scotthurff.com Webアプリケーションを作ったことがある人ならわかる話だが、アプリケーションは確実に予想外の状況に晒される。サーバーはレスポンスを返すのに時間がかかるし、ユーザーの環境がメモリ1G以下のこともあれば、完全に想定外の使いかたをするユーザーもいる。デザイナはそれらの現実に起こりうる可能性を全て考慮に入れてデザインをする必要がある。 2004年にBasecamp(当時は37signals)はThe Three State Solutionという提案をしていて、その内容は「全ての画面設計は3つのステート(Regular, Blank, Error)を考慮するべきだ」というものだった。その当時はまだAjax黎明期だったし、もちろんスマートフォンも存在していなかった。けれども、新しいテクノロジーが生まれるにつれて、インターネットを利用する環境は恐ろしく多様に
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
よく新しいフレームワークを学ぶにはTodoアプリを作ってみるのがよい、と言われる。実際、Todoアプリを様々なフレームワークで作ってみたサンプルをまとめたサイトもあったりする。 ところが、実際に業務で作るようなアプリケーションはTodoアプリの範疇を超えている。とくにSPAにもなると、画面遷移やWebAPI連携、大規模な状態管理などなどの条件が増えるので、Todoアプリを作っているときには考慮できていなかった大変さが出てくる。 そこで参考になるのが RealWorld example apps と呼ばれるプロジェクト 端的に言うと、TodoMVCの大規模版。 規定のスペックに沿って、様々なウェブフレームワークで作られたアプリケーションのリポジトリがリストアップされている。 スペックについて "Conduit" is a social blogging site (i.e. a Medium
このページを最初にブックマークしてみませんか?
『Runner in the High』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く