暇にかまけて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
暇。いい響きだと思う。声に出してみる。ヒマ。とても良い。「ヒ」の音でちょっと勢いづいた感じがするも、マ行の発音をするためには一度唇を閉じなければいけないこの感じが、いかにも暇という言葉の甘美な後ろめたさを表しているように思う。 これがもしも「ヒマ」ではなくて「ヒカ」とかだったら、あまりに印象がシャープにすぎる。暇にかまけてよしなし事をそこはかとなく書きつくるようなことは許されないような、そんな感じがする。逆に「ニマ」くらいまでいってしまうと、今度はほげほげとしすぎていて、なんとなく忙しい世間から取り残されるような後ろめたさが感じとれないではないか。 この、シャープなわけでもなければ、ほげほげとし過ぎているわけではない、そんな捉えどころのない「暇」というものについて、少し考えてみたい。 ぼくが「暇」について考えるときにいつも頭に浮かぶのは、スチャダラパーの「暇の過ごし方」という曲だ。これは
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
FluxのStoreがViewModelかって話からのMVWとかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
StoreがViewModel相当かどうかってことそれ自体はたぶんあんま本質じゃないんだけど。 blog.nkzn.info これについてです。 わかる。StoreがViewModelってのはちょっとだけ違和感あって、ぼくは ViewModelが読むためのクエリ用モデルくらいに思ってるけど、どちらにせよクリーンアーキテクチャ的な考えで言う「外側」のものだよねという点ではたぶん認識一致してると思う https://t.co/IMQADHGwUb— 猫型🐱蓄音機 (@shinpei0213) 2018年5月15日 べつにStoreが ViewModel相当なのかクエリモデル相当なのかってのはじつはどうでもよくて、あのクリーンアーキテクチャの同心円の外側に位置するものだってことがたぶんこの記事の本質。で、クリーンアーキテクチャは同心円の層の数を定義してなくて、— 猫型🐱蓄音機 (@shinp
Repositoryの後ろにネットワーク越しのシステムがあることの是非からRedux的世界へ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
twitterで言ってたことを少し修正してまとめ。MVVM + Layered Architectureの文脈です。 最近、Repositoyとして抽象化しておけばそのデータがメモリ上にあるかそれともDB上にあるかネットワーク越しにあるか意識しなくていい、というのは嘘だと思ってる。パフォーマンスの観点除いても。 というのは、リポジトリが「非同期クエリ」を受け付け始めると、ReadStackの複雑性が跳ね上がるというのがあるからなんだけど、そもそもRepositoryへのクエリは必ず非同期であるというインターフェースにすればこれは問題にならないのかな リポジトリを基本非同期に設計してもいいんだけど、そうすると同期的な表示を求めてくるUIプラットフォームと相性悪くなるんだよな たとえばMVVMで考えると、モデルのイベントを購読して、イベント来たらクエリ投げてモデル以下にある状態を読み出してきて
#builderscon 2017で「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてベストスピーカー賞第三位を頂いてきた - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先週開催されたbuildersconで表題の通りの内容をしゃべってきました。発表内容については、スライドもアップしてますが、いつもどおり実況中継シリーズを会社ブログのほうに書きます。ただ、あれ書くのすごい大変なのでもうしばらく時間かかりますすみません。書きました。 自分のトークについて 弊社はまだまだメンバーが少なく、わたしもJavaScriptが専門、あるいは専任というわけではないという状況の中で、「なるべくJavaScriptに独特の概念などはプロダクトに持ち込まず、他のプラットフォームにも通用するような考え方ややり方で保守性の高いコードを書く」ということを考えて設計/実装をしています。 その試行錯誤の結果得てきた知見を対外的に発表することで、みなさんに「JavaScriptに限らず有用なトークだった」と言っていただけたのは本当に嬉しいです。 ただ、逆に考えると「JavaScript全
NDS（長岡開発者勉強会）の52回で「怖くないし役に立つ設計原則の話」というタイトルで喋ります - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
新潟県長岡市では定期的に「NDS」という勉強会が開催されています。わたしも新潟に住んでいるときには非常にお世話になった勉強会で、とても良い勉強会です。 その第52回（52回ですよ！？すごくないですか！？）が6/17に開催されるとのことなので、「怖くないし役に立つ設計原則の話」というタイトルで発表させていただくことにしました。 nagaoka.techtalk.jp まだ内容固まっていないのですが、このトークでは、 デザインパターンとか知識としては知ってるんだけどなぜそれが有効なのかよくわからん 「結局設計パターンとかって役に立たないし勘でやるものでしょ」 MVCとかMVVMとかMVPとか「わざわざ難しくしてる」としか思えない！！！ DRY原則なら知ってる といった感じのひと（2010年くらいの俺だ……）を想定して、 われわれは（主語が大きい）なぜ設計パターンを役立たせることができないのか
GUIアプリケーションアーキテクチャ総合！みたいなやつ書いてる - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
最近はずっとJSでGUIを書くっていうお仕事をやっていて、その中で様々な知見が溜まってきてます。 そのときにひしひしと感じたんだけど、世の中にはさまざまなアプリケーション・アーキテクチャの話が溢れかえっていて、結構混乱を産んでいるように思います。 MVVMだけ見ても、「MVVMで実装しています」って主張しているものがMVVMパターンと違うパターンで実装されていたり、「軽量MVVM」なんて言葉が生まれていたりという状況があって、これはだいぶ混乱が極まっているぞ、と感じる状況です。 また「最近はClean Architectureが熱いらしい！MVVMを捨ててやってみよう！」とか言う発言を目にしたりして、「Clean ArchitectureとMVVMは矛盾しないからMVVMを捨てる必要はないんだよ！」って思ったりもするわけです。 そういう混乱の中にあるひと（それは知見を貯めるまえの自分のこと
遠く離れたところで昔の夢が叶ってしまった話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
なんだか久しぶりの投稿です。前の記事を投稿してからしばらくかなり忙しい日々が続いており、仕事の進捗は出ているのですがブログの進捗がお亡くなりになっていました。逆よりいいと思うことにします。 ところで、「かなり忙しい日々」の中に実は「雑誌への記事の執筆」というものが入っておりました。先に結論をいうと、WEB+DB PRESS Vol.91に「［すぐに使えてずっと役立つ！］データ構造の基礎知識 ── 配列、リスト、ハッシュテーブル、木構造」という特集記事を書かせていただきました。なんと！特集記事です。まじかよ。 www.amazon.co.jp 記事の内容について WEB+DB PRESSは、プログラマとして働き始めてからほとんど毎号購入して読んでいる雑誌で、そのような雑誌の特集を執筆させていただけたことは本当にありがたいことだと感じていますし、とても嬉しく思っています。内容としてはデータ構造
Scala の implicit parameter は型クラスの一種とはどういうことなのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
なんか型クラスとか言うと型の怖いひとたちが怖い話をワイワイしてるイメージがありますよね。わたしはあります。「で、それって何がうれしいのよ」とか、そういう話はあまりされていないような印象がありますね（あくまで印象です）。その上 "Scala の implicit parameter は型クラスの一種" とか言われると「暗黙的な引数がなんで型クラスの一種なんや！！！意味がわからん！！！！」となります。わたしはなりました。 というわけでそのへんについて勉強したので書きます。 そもそも型クラスってなんや Haskellとかにあるやつですね。アドホック多相を実現するもの、らしいです。すごい、いきなり意味がわからない。 というわけで、まずは「アドホック多相ってなんなの」という話からして行きます。 さて、まずは「多相」から行きましょう。この文脈で言う多相とは、簡単に言えば「引数にいろんな型を取れる」とい
やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから（あるいは Marionette.js を使ったらから）といって自動的にお前のアプリケーションが MVC になるわけ
ウォーターセル株式会社に join します - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
とはいえ、パートタイムです。今までの仕事も今まで通り行ってるので、実情としては仕事を増やしたという感じです。子供できてお金必要だし。みなさんの大好きな転職エントリではありません。具体的な仕事はまだ始まってない（今週金曜日が初仕事です）し、まだ join することが決まっただけなんだけど、なんかいくらでもやらないといけないことあるっぽいし、まあ価値を提供〜〜〜！！できるようになるべく頑張りたいな、と思ってます。 というわけでスピリッチャルなエントリ書きます。 ウォーターセルってなに？ 「アグリノート」という、農業支援のためのアプリケーション作ってる会社です。決して怪しいお水を高値で売ってるみたいなやつじゃないです。そもそも sell じゃなくて cell だしな join の理由 まず第一にお金が必要で仕事を増やす必要があったからです。ここは譲れない。だってお金必要だもん。そもそもなんで私が
意識を低く保つための tips - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ハイ意識でそれを実践してるひとたちのことをわたしはすごいかっこいいなーすごいなーって思って見てるんだけど、世の中には「意識高い()」みたいなアレがあって、わたし自身もある程度それを内面化してしまっていて、たまに「ウッ意識高いひとだ……」ってなることがある(facebookに生息してることが多い気がする)。「ウッ意識高いひとたちだ」ってなるの、結局意識に行動が追いついていないから痛々しく感じるわけで、意識だけが上空 100km を浮遊してるみたいなのはもう完全に事故ってる感じがある。(意識も行動も上空 100km なひとたちのことは本当に尊敬してる)。で、意識だけが舞い上がっちゃうみたいなのを嫌うあまり、意識はなるべく低く運用していきたいなーって思うんだけど、意識が低いままだと優秀な学生たちが卒業した瞬間に私の仕事はなくなり、その日食べるお米さえなくなってしまい破滅する。 あと、わたしがプロ
適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
middleman 良かった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く