みなさんこんにちわ、カカオ豆です。 皆さんは家でコーヒーを飲みますか？僕は一日4杯くらい飲みます。 コスパ良く美味しいコーヒーが飲みたすぎて自家焙煎までしはじめて、職場の同僚にもその良さを布教しまくるようなウザムーブをかまして、気がつけば2年が経ちました。 さて、自宅コーヒーは、ちょっと気をつけて投資するだけでその辺のカフェくらいなら余裕で追い越せるくらい美味しいのが淹れられるようになります。 え？「プロをなめんな？」 いえいえ、もちろん超こだわったお店で超こだわる客に出す超高い一杯を超えるのは相当難しいです。 しかし普通のカフェが出す普通のお客さんに出す普通の一杯は極限までコストを削減しなければならないのです。 それはそれでプロの仕事ですが、我々自家消費のしろうとはコスト感覚を無視して高級豆を使えるのです。よく「ドリップ技術」なんて言われますが、コーヒーのドリップは豆の品質がほとんどです

全くブログを書いていなかったのでリハビリに……去年買って良かったものを羅列して振り返ってみる。 くるま 車なんていらんやろw そんなふうに考えていた時期が俺にもありました…… まあ実際札幌の中央区に住んでるなら車なくても不便しないです。 でもあるとレジャーの幅は広がるし、急用でタクシーを呼ぶ手間がなかったり、色々とはかどります。 全くもって必需品ではないんだけど、もう手放せない。買って良かった。 マタドールの超コンパクトになるレジャーシート マタドールポケット毛布 レッド、レギュラー（2～4人用） MatadorAmazon 今年はよくピクニックやデイキャン、BBQをした。 レジャーシートって意外とかさばるし、風でとんでストレス。 これは超コンパクトに畳める上に、四隅に簡易的なペグがついているから少しくらいの風で飛んだりめくれたりすることはない。地味だけどQoLに貢献してくれたアイテム。

そんな皆さまの疑問にお答えします。 スタートアップのアーキテクチャがブッ壊れてるのってなんでェ？ 先にざっくりまとめましょう。 巷でよく言及されるのはカネ、つまりは雇用するエンジニアの能力問題を元凶とする方が多いようです。 スタートアップの内情を知っていれば金と雇用の問題がどれだけ切実であるかについて異論を唱える人はいないとおもいます。しかし僕の考えによればこれはスタートアップのソフトウェア開発が抱える問題のうちのひとつ側面にすぎません。 つまりどんなに優秀な人間をかき集めようがスタートアップのソフトウェア設計は近い将来壊れる宿命にあるということです。 スタートアップの存在意義は未来の不確実性そのもの 普通のやつらの上を行け、ではありませんが。 スタートアップ企業はうまくいくかわからない事業をやることそのものに価値があります。 「誰からみてもうまくいくに決まってる」事業で金も人材も潤沢にあ

注意：本稿にはあまり一般的ではない（かもしれない）筆者の独自思想がふんだんに盛り込まれています。これを受けてどう考え、行動するのかは自己責任でよろしくおねがいします。 ソフトウェア開発に銀の弾丸なし、という言葉は広く市民権を得ています。多少なりとも開発の経験がある方ならばこれに異を唱える人はいないでしょう。 しかしそんな我々もアーキテクチャ（多くの現場でこれはフレームワークの選定と同義語である）の話になると無意識のうちに「最強の何か」を想定して思考してしまいがちです。そうだよね？ なので未来の自分へのメッセージもかねて、いまここではっきりと宣言しましょう。 この世界に最強のアーキテクチャは存在しません。各プロダクトに合わせた最適が存在するだけです。 にんにくの存在 とはいえ先の僕の宣言を完全に鵜呑みにして、要件に合わせてプロダクトに必要なものを一から自作していくのがベスト！という結論に飛び

はじめに まずインターネットのお気持ち記事で「型がある」とか「型がない」とか言い始めたら、書き手がどういった意図でそのような言葉を選んだのか警戒しなければならない。 全部を語るとそれだけで5記事分くらいの分量になりそう*1なので割愛するが、世間的には「静的な型検査を行える」ことを指して「型がある」と呼称しており、その強弱とかランタイムの挙動については基本的に無視するという姿勢をとっているようだ。きちんと研究している層にとってはなんとも歯痒い定義なのかもしれないけれど、雑に語るにはとても便利な切り分けなので本記事も基本的にこれを採用する。 余談だけど、世間一般が語る「強|弱い型付け」の定義って恣意的すぎて意味不明だわとおもってたんだけど、いまWikiで確認してもやっぱりどういう基準で決めてるのか意味不明。たぶん時代遅れの概念なんだとおもう。 はじめに 変数の型が静的なのは我々にとってごく自然

なんか話題になってて、なんかおみこしwasshoiする流れになってたのでお気持ちを書き残したくなった。 先に結論 こういうのを作って公開するのは誉れある組織 ですが 内容的にはfor TypeScriptというよりはfor ES nextといった感じで、特に型周りに関する言及が少なめ eslintのルールが用意されていないので使いたいなら人力運用になる ゆえにGoogle社員以外がわざわざプロジェクトに導入するのはどうなんでしょうか。手間に見合う価値があるんでしょうか。 だからこれをデファクトにしよう！みんなこれ使えよな！みたいな勇み足はちょっと…… これが言いたかっただけです。 スタイルガイド自体に関するオレのKimochi 伝えたい… 率直にいってしまえばスタイルガイドは存在しているという事実そのもの、そしてそれが常にチェックされている機構に価値があって、中身はどうでもいいと極論しても

ZOZOの人の発言、ぶっちゃけアイティーでパソコンの先生やってる人の大半の人が大筋では同意するんだろうけどみんなへそ曲がりだから年末年始みたいなイベントと絡めたり散りばめられた意識高い属性にイラッときてるみたいなところがあるとおもう— はっちん (@hatchinee) 2021年1月4日 「年末年始にコード書かないやつは……」云々のツイートについてのお気持ちはだいたい↑の通りなんだけど、どうも世間の感想（ツイートへのぶら下がりとはてなブックマークのコメントという枠です）をみる限り僕の想定とはズレた感じで批判的な人*1が沢山いるようなので、プライベートのコーディングとプログラマとしての能力がどういう相関関係にあるのか僕の考えを書こうとおもいます。 プライベートで（趣味）コーディングしてる人が有能である（可能性が高い）理由について コーディングの前に （趣味） とついていますね？ まず趣味コ

hachibeechan.hateblo.jp 前回の続き そういえば、前回の記事のブコメで Behavior = TransactionScript? 実践CQRS という感じの元ネタばらし鋭い指摘をしてくれた方がいました。 90%方その通りなのですが、実装の平易さ、許容できるパターンの広さを優先するために元の定義からかなり離れてしまっており、混乱を招くかもしれないと感じたので別の用語で説明している次第です。 読み返すと文字の密度が高くて読むの大変な記事ですね。 今回は具体的な話になるのでサンプルコードとか載せられるといいなとおもいます。 スケーラブルなデータ設計の基本アイディア Storeの構成要素 アンチパターン 1. Modelという名前がついたクラス 2. "DBに対するCRUD操作" のような抽象度でStoreを設計してしまう 3. 同一の対象を表すデータが複数存在している（N

あわせて読みたい FlutterでBLoCだChangeNotifierと振り回されて消耗するまえに - タオルケット体操 筆者のFlutterに対する印象は半年前にこのエントリーを書いたときから驚くほどに何も変わっていないので、逆にFlutterは非常に明快でわかりやすいライブラリなのかもしれないですね。 hachibeechan.hateblo.jp 筆者の主張の事前まとめ Reactの学習は実質Flutterの予習 クライアントアプリを設計するにあたってはActiveRecordパターンの再発明をしてはいけない 結局MVX RXSteamとはなんだったのか DDDの勉強をすると多くの示唆を得られる Remi wareを信じろ ちなみにここ以下で述べるActiveRecordパターンはPoEEAとRoRのものの混合があるかもしれませんが、利用すべきじゃないという点において同一なので特に

貴方がある日突然、チンパンジーにドミニオンと将棋と囲碁を混ぜたようなゲームを教えてもらうことになったらどうしますか？ それも…… その猿はとびっきり凶暴で とびっきりの指示厨で（内容は間違ってる） とびっきりの陰キャ しかも、そのうえ……その猿共はみんなみんな初心者狩りが大好きなんです！ LoLのつらいところ 初心者に厳しいと言われる格闘ゲームをさらに凌ぐ辛さだとおもう。 とにかく覚えることが多く、民度が最悪。梅澤春人先生が描く野球部くらい民度が低い。チンパンジーしかいないとおもっていたR6Sの民度が実はオランウータンくらいには高かったことに気がついたレベルで酷い。 覚えなければならないことの量が異常 使えるキャラクター（チャンピオンと呼ばれる）の数が異常 148体。初代ポケモンかよ。 それぞれ特徴的なコンボやスキルがあるので、自分が操作するキャラはもちろんのこと、知らない対面と当たるとわ

追記 providerとかfreezedの作者が作ってる state_notifier が当エントリとほぼほぼ同じことをやっているので依存が増えることを気にしない人はそっち使ってもいいんじゃないかとおもいます。 みんなの心はひとつでした。 まえがき 先のエントリ BLoCにおけるリモートデータの状態遷移のパターンをくくりだす方法 - タオルケット体操 の書き方からもわかるように、そもそも僕はBLoCが嫌いです。 というか10年前にC#がRXをはじめたときからわかっていたはずですが、ObservableStreamは超かっこいいけど使い道の少ない技術です。フレームワークの裏側で使う分には便利ですが、表に出てくるべきではないでしょう。普通のGUIアプリケーションであれば99%のユースケースはただのコールバックで満たせます。 しかもBLoCはViewModelのパターン*1です。ViewMode

今回のエントリは特定の言語に向けて書いているわけではありませんが、関数をサポートしていない言語では必然的にクラスをベースに実装していくことになるのである程度は対象となる言語は絞られます*1。 また特に説明がなければサンプルはTypeScriptで書きます。 さて、あくまで傾向としてではありますが関数を作れる言語の経験が短い人（例えばJavaやRubyですと、関数ではなくクラスに対するメソッドという形で実装することになります）は、単機能の振る舞いを実装するためだけであっても以下のようなコードを実装しがちです class DoSomethinger { constructor(private something: Domething) {} public doSomething() { return dooo(something); // do something } } これは const

Dart否定して終わりだとあもりにあわれ。 おれにこれしかなんだ！ だから、これがいちばんいいんだ！というわけで現実と戦う方法を模索。 元ネタ： https://elmprogramming.com/remote-data.html ちなみにBLoCはすでにオワコン化しつつあるようなので新規でコード書く場合はよっぽどのモチベーションがない限りは避けるべきでしょう。ちょろっとコンセプト読んだだけで微妙なのわかってしかるべきなのに今さら「やっぱダメで〜すww」とかほんともうね、そういうのはフロントエンドだけにしておいてくれ モチベーション ざっくり99%くらいのFlutterアプリはなんらかのリモートデータを取得して画面に表示する処理を持っているはずです。 その場合、データには 初期状態 問い合わせ中 成功 失敗 というフローが存在しており、Viewはそれぞれに応じてクルクルさせたりエラーを出

本当に効率が悪いReduxの学び方 いまある"フレームワーク"の中でReduxほど覚えるのが簡単なものはありません。 しかし(僕を含め)多くの人が学習の最初に躓きと強い苦痛を覚えるようです。何故でしょうか。 私見ではありますが、これにはReduxがどういう性格をもったツールであるかということ、それによって現在マジョリティを占めるフレームワークとは異なる学習スタイルを求められることが影響していると考えております。 理由は追々述べていきますが、一番効率の悪いReduxの学習方法は「覚えよう」とすることです。 (異論はあるかもしれませんが)Railsなどのフルスタック系フレームワークを習得するときには実装例を写経するなどして暗記から学習していくスタイルはかなり有効だとおもいます。しかしReduxを同じように学習していくのは遠回りどころか、最悪で何一つ得られるものはなくただ壊れたアプリケーションが

TypeScriptにはType infer in ConditionalTypeという便利機能があり、それを利用すると既存の型定義から柔軟に特定の方を取り出すことができます。 そして利用頻度が高そうなものについては組み込みの型定義がいくつか存在します。 関数の型定義から引数を取り出すのは Parameters<T> で、この型引数に関数の定義を与えることでその関数の引数がTupleとして返ってきます。 ちなみに返り値は ReturnType<T> で取り出すことが出来ます。 function testFunc(a: string, b: number, c: boolean): {a: string, b: number, c: boolean} { return {a, b, c}; } type TestFuncArgs = Parameters<typeof testFunc>;

ペアリングモードへの移行 Fn + を一秒以上長押しすると が点滅するのでお好きなデバイスでペアリング ペアリングスイッチのやり方 Fn + 1/2/3 で切り替えられる。古いステマブロガーの記事だとFn + Q/W/E ということになっているが、おそらくテストファームの仕様か、使わずに書いた適当なコピペ記事のどちらかだとおもわれる。 なんでこんなの書いたかって？説明書を捨てたからだよ！ Taptek自体の簡単なレビュー ゲーム用としてならOK、作業用の普段使いとしてはクソ まずもって「コンパクトかつ本格的なメカニカルなので自宅でも出先でもオーケー！」というコンセプトが、アルミボディ由来の重量と青軸のうるささのせいで台無しになっている。 カフェでこれパチパチやってる馬鹿、俺がマスターなら出禁にするわボケが。 反面レイテンシー低めでNキーロールオーバーをサポートしてるので、ゲーミングキーボー

YAGNIの原則 YAGNIの法則はご存知ですか。 You Ain’t Gonna Need It. の略で、アジャイルとかでよく言われる「いらんもん作るな」の原則ですね。 「これいるやろー」で前もって作りこまれた機能は10%しか使われないし時間の無駄だよね（10%の根拠はあるんかな）、っていうあれです。 「まだ必要じゃない」って意訳する人もいますがこれは悪い意訳です。 YAGONIの原則 ではYAGONIの原則はご存知ですか？ これは「ここは明らかにあとで必要になるやつだから工数よこせ」の法則です。 ご存じないとおもいます。今僕が作ったからです。 ある程度の経験を積んだプログラマーならわかるとおもうんですが、「これは予め作りこんでおいたほうがいいな」っていう半ば直観めいた洞察、あるとおもいます。そういうことです。 スタータップ、それもWeb系だとプロトタイピングだからという名目のもとカウ

React Hooksでましたね。 これでクラスを使う必要がなくなってみんなハッピーです（公式で再三書かれてますが、既存のコードをHooksで書き直す必要性はないです）。 それはそうとして、useReducer という新しい仲間が増えました。 ちょっと前に追加されたContextと合わせることでReduxを置き換えることができます（置き換える必要があるかどうかは考えてはいけない）。 しかし最近気がついたのですが、そもそもReduxがどういうものなのか、雰囲気で使っている人が多いようにおもいます。 ぶっちゃけ「ドキュメントやソースコードを読めばいいやんけ」、で終了する話なのです。 とはいえReduxは特定のViewライブラリへの依存を防ぐように作られていたり、なるべく縛りを作らずに薄い実装にしてプラグインで解決していくような思想になっていたり、フレームワークというよりはフレームワークのための

最近の波には乗り遅れたけど、これは定期的に議論が発生するトピックスな割にあまり整理して話してるものが見当たらないので僕なりの観点からまとめる。 なおこの記事では 学校教育 未経験者を雇う企業の新人研修 社員の平均レベルをあげたいイケイケ企業 などの領域を包括的に扱いたいので抽象的な段階に終始しようとおもう。 0. そもそも人には向き不向きがある問題 いきなりこれ書いちゃう？ 「教育」という概念には、「人間の能力はそれぞれみんな同等で教えればできるようになりますよ」という思想（タテマエ）が根底に存在している。 でも悲しいかな、そんなことないんだなぁ悲しいなぁ。 そして教育にかけられるコストには限りがあり、仕上げる納期がある。つまり「マンツーマンで個人の理解度に合わせた進行」、「理解するまで徹底的に教える」というやり方には限度がある。 なので大まかなグループ分けをして一緒くたに教えることになる