RailsのControllerにApplicationService相当のロジックを書くのはありなしや？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。 Railsにおいては、ApplicationService相当のロジックをコントローラーに書いても良いものとする— 猫でもわかるしんぺい入門 (@shinpei0213) June 4, 2019 これについてです。 結論から先にいうと、ぼくは「正しい」と思っています（ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています）。 なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplication
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
#builderscon 2017で「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてベストスピーカー賞第三位を頂いてきた - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先週開催されたbuildersconで表題の通りの内容をしゃべってきました。発表内容については、スライドもアップしてますが、いつもどおり実況中継シリーズを会社ブログのほうに書きます。ただ、あれ書くのすごい大変なのでもうしばらく時間かかりますすみません。書きました。 自分のトークについて 弊社はまだまだメンバーが少なく、わたしもJavaScriptが専門、あるいは専任というわけではないという状況の中で、「なるべくJavaScriptに独特の概念などはプロダクトに持ち込まず、他のプラットフォームにも通用するような考え方ややり方で保守性の高いコードを書く」ということを考えて設計/実装をしています。 その試行錯誤の結果得てきた知見を対外的に発表することで、みなさんに「JavaScriptに限らず有用なトークだった」と言っていただけたのは本当に嬉しいです。 ただ、逆に考えると「JavaScript全
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / write stack - usecase - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回の記事では、Scala.jsで書かれたモデル層がどのようなクラス/オブジェクトをJSで書かれたUI層に公開し、UI層はそれらをどのようにして扱うのかというのを見てきました。今回からはScala.jsで書かれたモデル層のうち、コマンドから始まる一連の状態更新系（write stackと呼んでいます）について見ていきたいと思います。 write stackを構成するpackageとクラスたち write stackを構成するクラスは以下の通りです usecase パッケージ Commandクラス Serviceクラス domain パッケージ Domain Modelを表すクラスたち infrastructure パッケージ Repositoryクラス Synchronizerクラス このうち、今回はusecaseパッケージに注目してみましょう。 usecaseパッケージは、いわゆる「アプ
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / Vue.jsによるUI層とScala.jsによるモデル層のコミュニケーション - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回の記事では、Scala.jsをどのように利用したかについて概観を見てきました。 前回、UI層は素直にVue.jsの単一ファイルコンポーネントで書いて、モデル層はScala.jsで書く、というスタイルを取る、と述べましたが、今回はモデル層がどのようなインターフェイスをUI層に公開して、UI層がどのようにそれらを利用する設計としたのかについて見ていきます。 モデル層の公開するみっつの種類のクラス/オブジェクト モデル層は、UI層に対して、「コマンド」「クエリ」「イベント」のみっつの種類のクラス/オブジェクトを公開します。まずは「コマンド」から見ていきましょう。 コマンドの責務 コマンドは、アプリケーションの状態を更新するような操作（たとえばTodoを追加する、Todoをdone状態にする、など）の窓口を提供します。 なにかを更新するような操作を行う場合、UI層は、 コマンドをインスタンス化
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / Scala.jsについて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに オフラインファーストへの要求 近年、オフラインファーストというか、「オフラインのときにも普通につかえて、オンラインになったら同期する」みたいなことに対する要求が高まっているように感じます。 その場合は、ローカルにもきちんと永続データを持っておき、オンラインのときにバックエンドと通信をしながらバックエンドのデータと同期していく、というスタイルを考えるのが自然だと思います。 また、普通のJSアプリケーションであっても、「サーバーに投げる際に失敗したデータはローカルでメモリ上にもっておいてリトライしたい」などの要求もあるでしょう。 さらに、ここでモバイルアプリも視野に入っているとなると、どうしても「オッRealm Mobile Platformか！？」という感じが出てきますが、Realm Mobile Platformにロックインされるのと引き換えに開発の速を選ぶのか、それとも、という
Vue.jsとvuex、Fluxについて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
最近立て続けにそのあたりの話をする機会があったので。わたしの意見です。 vuexというかFluxに手を出すタイミング Vue.jsを利用していて、相互に関連のある二つ以上の状態を扱う必要が出てきたら、それはもうすでに「十分に複雑な状態管理」である たとえば、APIとの通信中はインジケータを出したいので「通信中かどうか」を管理し、通信が終わったらその結果を表示するために「通信結果」も管理したい、など。 十分に複雑な状態管理に立ち向かうためには、自分でピュアなDomain側をきちんと作ってそこで状態管理するか、vuex利用するべきだと思う 自分で設計からやるにしても、まっとうにMVVMをやれば単方向データフローは守れるので、Fluxの考え方とMVVMは矛盾しない see http://techblog.reraku.co.jp/entry/2016/12/13/080000 vuexを触ってみ
リソース指向と操作指向のURLに関する最近の思い - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
弊社のwebAPIはRESTを捨てて操作指向のURLにすることが多いんだけれど、ここのところwebAPIだと結構そういう判断するところが増えてるように感じる（個人の感想です）。 SoEとSoRという話があったけれど、webブラウザ上でもスマートフォン上でもリッチなユーザ体験がモノを言うようになり、SoEなサービスが増えてきていることと操作指向のURLが増えていることは実は無関係ではないのではないか。 というのも、SoRの場合その性質上リソースに対する意識が高まるのに対して、SoEの場合はどちらかと言うとユーザ体験みたいなところに意識が高まる。で、ユーザがサービスを捉えるときのメンタルモデルって、「リソースの操作」とあまり一致しなかったりすると思うんですよ。そうすると、どうしてもリソース指向のURLでやっていくのに無理が出てきて、「じゃあいっそユースケース指向というか操作指向のURLでAPI
双剣問題について - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
双剣問題についてはyatteiki.fmを参照してください。 双剣問題に関しては言いたいことがふたつあって、ひとつは小菅さんも言ってたけど、「別に結婚とかしたからといって楽になったり落ち着いたりするわけじゃない、むしろその分剣を振り続けなきゃならない」ってことで、ひとりだったらサボっちゃうところも、だれかと一緒に生活をする、その生活をやっていき続けるためにはサボることができなくなり、むしろ双剣を握り続けるモチベーションになるということがひとつ。 もうひとつが、双剣を振り続けてると「それが当たり前の環境」になっていって、双剣を握り続けるということが特別なことではなくなるということ。というか、特別なことじゃなくならないと双剣は握り続けられない、ということ。 たとえば、カンファレンスで発表をするということ。じつは、初めてカンファレンスで発表する日、わたしは緊張とストレスでトイレで吐いていた。そん
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
プログラマとコミュニティ あるいは SD8月号に記事を書かせてもらいました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
表題にあるとおり、Software Design8月号の特集記事を書かせていただきました。GitHub入門的な記事です。 今書店で売ってる号は7月号ですので、今売ってるやつには載ってません（でももちろん買ってくださってもいいんですよ？）。発売日は7/18ですので、その後書店で購入したり、Amazonなどでお求めください。 www.amazon.co.jp 今年に入ってから、web+DB Pressの91,92号、SD8月号と、技術評論社さんの雑誌に記事を書かせていただく機会を立て続けにいただけて、ほんとうにありがたい限りです。 ところで、web+DB vol. 91の記事はYAPC::Asiaでの発表がきっかけでチャンスをいただいたのでした。92はPerlコミュニティつながりで頂いたお話でした。今回の記事に関しては、「Gitをはじめからていねいに」というドキュメントをGitHub上で公開し
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
YAPC::Asia 2015で喋ることになりました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
8/20,21,22に開催される、プログラマのフジロック（あるいはプログラマの夏コミ）とも言えるYAPC::Asia 2015ですが、無事トークが採択され、発表させていただく運びとなりました。詳細は下記より。 http://yapcasia.org/2015/talk/show/9f7059dc-003c-11e5-a00c-89c77d574c3a 自分が「これ聴きたいなー」と思うようなトークも不採択になったりしており、これでマズい発表をしたら各方面に対して顔向けできない感じで、プレッシャーも大いに感じていますが、まずは素直に嬉しいし、聞きに来てくれたひとになにか良いものを残せるようなトークをしたいと強く思っています。 ところで、スピーカー枠をゲットした都合により、個人スポンサーチケットが一枚あまっております。「しまったヤプシーのチケット買い忘れた！！」というかたは、 必ず参加すること
「地方」のIT勉強会は参加者がもっと外に向かってアピールしてほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
わたしの立ち位置 今は東京都でプログラマをやっているが、3,4年くらい新潟県でプログラマをやっていて、当時は地元のコミュニティによく顔を出していた、という人間です 以下本文 少なくともわたしが知っている限りの話です。新潟県には優秀なプログラマが一定数います。そして、最近はコミュニティがそういうプログラマにリーチしつつあって、交流は活発になっていると感じます。でも、参加者がレポートとかを対外的に書いたりはあまりしてないように思えます。これはとてももったいないことです。優秀なプログラマを喉から手が出るくらいほしがってる「都会」の企業が、「なんかあの地域めっちゃプログラマたちの活動活発だな、開発拠点作る意味あるかも」って思ってくれるくらいまで、「俺たちプログラマとして楽しいことやってるぜ！」ってのをアピールしていったらいいのにな、と思うんですよ。 これは多分新潟に限らないのではないかと思うんでけ
Perlの黒魔術を解説するよ〜〜〜〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
まずはこちらをごらんください。 shinh.hatenablog.com すごすぎる……。恐ろしいですね。 なぜこんなことになるのか、解説していきましょう。まずはPerlの気持ちになりましょう。 Perlの気持ち編 ポイントその1 barewordを数値コンテキストで評価するとどうなるのかということ 件のプログラムは、base64 っぽい文字列が書かれていますが、これを前からPerlコードとして読んでいくと、大きく2つのパートに分かれることに気づきます。というのも、前から一文字ずつ読んでいくと、「+」という演算子にぶつかるわけですね。 それに気づくと、このコードは前半部分 dXNlIE1JTUU6OkJhc2U2NDtwcmludCBlbmNvZGVfYmFzZTY0IGpvaW4nJyw8PjsKX19FTkRfXwo と、 s//v62/e+s//v60/e+s//v44/e+s//v
Functor における map の引数の順序を考えてたらいっこストンと腑に落ちた話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
別に知見は書いてないですが、なるほどなーと思ったという感想を書いたエントリです。 ScalazとHaskellのFunctorの提供するmap(fmap)は、引数の順番が異なります。 Scalaz の Functor def map[A, B](r: F[A])(f: A => B): F[B] F[A] なFunctor値が最初の引数で、A => B な関数が次の引数で、F[B]なファンクター値が返り値 Haskell の Functor fmap :: f => (a -> b) -> f a -> f b (a -> b) な関数が最初の引数で、f a なファンクター値が次の引数で、f b なファンクター値が返り値。 つまり第一引数と第二引数が逆。 ふつうに考えると Scalaz のやつが直感的に思えます。C言語とかでも、ある構造体を操作するための関数って大体第一引数にその構造体を渡
肉をやりました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
個人の日記です。 id:moznion がはるばる新潟まできて肉をやってくれるというので好意に甘えて肉をやりました。 肉をはじめたところです。すでに仕込み済の肉をmoznionが持ってきてくれたので、焼くフェーズから開始している様子です。 焼いてくれています このような見た目で最高な感じでした うまい（確信） こちらはアンティクーチョというペルー料理だそうです。ハツをスパイスとかビネガーとかに漬け込んで焼いたものだそうです。これ本当においしかったのでうちでもやろうと思った。 牡蠣も食べたかったので生牡蠣をレモンと塩でいただきました。 今回の功労者が青色のなにかを口元に押し当てている様子です。 感想 肉はとにかくうまかったのでとてもよかったです。 昔から家にひとを呼ぶのは好きだったんですけど、息子が生まれてからはなかなかこういう機会を作ることができませんでした。でもやっぱり家にひとを呼びたく
テンプレートをDRYにするのは慎重にやったほうがいいですよねというお話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
社内でレビューおじさん業してて書いた内容ですけど守秘する必要ない情報なんでちょっと内容書き換えてオープンアンドシェアーします。 本文 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品（些細な変更されることが多い部品）なので、「同じような部品だから共通化しちゃおう」ってやると失敗することが多いです。 特に気をつけるべきなのは、たとえばコンテンツをランキング形式でテーブルで表示する画面と、新着から順にテーブルで表示する画面があって、このふたつのテーブル部分は一緒だからパーシャルにしちゃおう、みたいなやつです。 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品、というのがここで効いてきて、「新着とランキングは基本的に同じ表示なんですけど、ランキングのほうではランクがアップしたかダウンしたかのアイコンを表示してほしいんですよね〜」とか言われたり、「今見てるページ
タイ風角煮考 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ここ最近角煮が話題かどうか知りませんが角煮です。 角煮ですが、うまいし簡単に作れるのですが時間がかかります。とはいえ、タイ風角煮なら雑に作ってもうまいという知見があるのでシェアします。 まず、角煮が硬くなるのは調味料で煮る、そのタイミングです。このタイ風角煮はその工程をまるっと無視して、タイ風のたれをかけて食べるものなので、雑に作ってもほろほろの角煮が出来上がります。ただし圧力鍋は必須です。圧力鍋は角煮に限らず煮込み料理がはかどりまくるのでないひとはこの機会に買いましょう。 材料は以下のとおりです。 豚バラブロックたくさん トムヤムクンのもと レモン汁 ナンプラー しょうが 好きなだけ ネギの青い部分 キャベツ パクチー（おこのみで） 下ごしらえ 豚バラブロックは適当なサイズに切っておきます。しょうがは皮をむいて（皮は捨てない）、すりおろしておきます。みじん切りでもいいです。 豚バラを雑に
TRADITIONAL MUSIC THEORY FOR CONTEMPORARY MUSICIANS を読んだ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
一般に流通してない本なんだけど、下のリンクから買える。 【販売ページ】Traditional Music Theory For Contemporary Musicians | Music Theory Workshop Japan 公開されてる分は全部読んだ。 著者が自分でも言ってるんだけど、「猿でもわかる！！音楽理論」みたいなタイプのやつだと演奏や作曲に活かすことができないくらいレベルが低くて役に立たないし、かといって芸大和声みたいなやつだとそれを役立たせるまでの道のりが遠すぎる & ポピュラーミュージックに応用するまでの道のりが遠すぎるというのがあって、なかなか「演奏や作曲の役に立ちやすい音楽理論の本」ってのは今までなかった印象がある。この本はそのちょうど間を埋めるような立ち位置の本で、バンドマンやDTMerにとってはかなり参考になるのではないかと思った。 ただ、結構ストイックに進ん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
