Railsdm 2018 Day4 Nouvelle Vague section B [15:50-16:10 ] Rails アプリケーションの成長に伴い、単一の ActiveRecord モデルにロジックを記述するのに不都合が出てきます。今回、それらの問題を『緩やかに』解消するための ApplicationModel 層の導入・活用方法と、既存のアプローチとの簡単な比較をご紹介出来ればと思います。
![ApplicationModel のある風景 / Rails with ApplicationModel - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/9b9740a75a9f98011d15293832eddbcfd1953ac9/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fb5579c5fa5fa4e479ec81fda3b231eb2%2Fslide_0.jpg%3F11393122)
TypeScript Advent Calendar 2019 - Qiita 14日目の記事です。 type-festというTypeScriptの便利な型を集めたnpmパッケージがあります。 今回はtype-festの中から特に複雑なUtilitiesの型の紹介とそれらの型パズルのような型定義について解説したいと思います。 この記事がMapped TypesやConditional Typesを使った複雑な型パズルの理解への一助になれば幸いです。 github.com 長いので前後半に分けました。後半はまた後日公開します。 前提知識 Utility Types Mapped Typesを利用したUtility Types Conditional Typesを利用したUtility Types type-fest Except Mutable Merge MergeExclusive Re
はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数
こんにちは、フリッツ です。プロダクトマネージャー(以下 PM)になってから相当の年月が経ち、特に、現職の US メルカリにおいては「 UIUX 強化型 PM 」として認知されるようになりました(ありがたい)。 ただ、最近は自分があまりにもいま持っているスキル・経験に立脚しすぎているなぁ、と感じており、強みの分野を広げようとお勉強中。 ということで、旅の序盤として、本記事では「プロダクトの成功」を導くために必要とされる、問題定義・優先順位決定・実行 という 3 つのステージを PM 視点から 20 項目にわけてみました。できるかぎり、(自分の今までの)現場の動き方に沿うようにまとめました。割と基本的な内容ではありつつも、特に実行のパートにおいては、現場で役立つような個人的知見を多少含められたはず…。 プロダクトに関わる方、および・駆け出し~数年目の PM の方のお役に立てる記事になっていれ
本について Amazon: https://www.amazon.co.jp/dp/4822284654 題材として選択したのは、「オブジェクト指向でなぜつくるのか-第2版-」という本です。13章で構成されており、今回は第5章について、まとめました。 ゴール オブジェクト指向プログラミングのメモリの使い方について説明できる 一般的なメモリの使い方 オブジェクト指向プログラミングの動作環境の特徴は、メモリの使い方にあります。ただ、従来のプログラミングの動作環境と共通する点も多いので、まずは一般的なメモリの使い方について説明がされています。 プログラムのメモリ領域は基本的に、 静的領域、 ヒープ領域、 スタック領域 の3つに分けられます。 静的領域 プログラム開始時に確保され、以降プログラムが終了するまで配置が固定される領域を指します。 ここには、静的な変数であるグローバル変数と、プログラムを
課題 redux を引っ張り出すと大仰になる。Context 下に共有ステートを持ってそこに setState できるだけでよい。 なので、次の 2 つを用意する 現在の state を参照する const appState = useAppState() 現在の state を更新する関数を返す const setAppState = useSetAppState() React.useState() と違って分割している理由は、主にパフォーマンス上の理由 大域な参照なので、可能な限りステートを参照したくない setState() の API は (prevState: State) => State も取れるので、状態更新用途に限ってはそもそも useAppState() せずに済むことが多い でも毎回書いてるけどボイラープレート感強い上に忘れるのでここにメモする 毎回書いてるボイラー
最近のツイッターランドはとても殺伐としていますね。 先日に某テレビ番組で出演していた女性がSNSからの誹謗中傷によって傷付き自殺してしまったという件もありました。 SNSは表現の自由が最大限に発揮できます。 しかし、SNSではどうも画面の向こう側にいるのが生身の人間だということを理解せず好き勝手に言ってしまう人がいるようです。 非常に嘆かわしい話です。 さて、もし仮に誹謗中傷されたときはどのように対応するのがベストなんでしょう。 泣き寝入り?逆に相手に執拗に嫌がらせをしてみる? ぼくがとった行動はというと、法律事務所に相談です。 そして、結果的に20万円の示談金をもって加害者の方と示談するに至りました。 先日の誹謗中傷の件で、あれから本人に直接DMで謝罪いただき、損害賠償請求は取りやめて示談金を20万円として示談で解決することにしました! みんなインターネットで誹謗中傷しちゃダメだよ! —
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く