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

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

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

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

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

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

補足：2021年6月 結構昔に書いた記事ですが、今でもたまにアクセスがある（ありがとうございます）ようなので使命感に駆られて追記。 本編の冒頭にもあるように、これは2018年の記事です。なので色々と書いてますが、2021年の人間の立場からTypeScriptの導入について申すのであれば一言です。 使いましょう。 もはや「TypeScriptを使う理由」とか言ってる時代はとっくの昔に終わっています（Elmとかそういう、他の型付きAltを使いたいなら別ですが）。 もちろんstrict mode一択ですからね。 当時は採用云々とか書いてましたが、逆にいまTypeScript書けるかどうかってのはフロントエンドエンジニア採用の足切りラインとしてちょうどいいくらい（書けるってのが程度かにもよりますけど）だとおもいます。 好き嫌いはともかく、TypeScriptを使えないエンジニアを雇ってもフロントエ

理由 流行り（一部）に乗ってErgoDox EZを買いました。 何故か？ それは私が漢だから。そして超オスの存在…憧れ… つまり、あまりに肩こりがひどすぎるのでいい加減HHKを脱却しようとおもいたったというワケ。 というわけで開封。 くっさい。めっちゃシンナーくさい*1。しかしツヤ消しのブラックといい、見た目はなかなか綺麗です。角度をかえられるチルトもしっかりしていてグッド！ どこをみても作りはしっかりしてます。これから買う方はチルトとアームレストつきをおすすめします。 理由 世間で流行っている様子 感想 デフォルトのキーバインドがイケてねぇ ErgoDoxのキーコンフィグの書き換え方 Vimとの相性が不安 プログラマー以外にはおすすめできない 使いやすさは最高 まとめ 軸ですが、僕はよくわかんないので赤軸を選びました。HHKの静電式と較べてはいけないんですが、まぁそれほど悪くないです。音

わかりやすく文系でくくりましたけど、正確には非情報系出身と言った方が適当かもしれませぬ。 私めは完全なる門外漢、未経験からこの業界に入った男です。思えば恥の多い生涯を送って来ました。 インターネットを徘徊してると色々なノイズが目につきます。そんな中でも、就職してからずっと僕の良心をチクチクと刺し続ける主張があります。「情報系以外の人間がプログラマーになるなよ死ね」ってやつです。以下みたいなエントリが生まれるたびに延々と繰り返されるアレです。 プログラマーは文系の仕事か、理系の仕事か - 愛と勇気と缶ビール 「プログラマーは文系の仕事か、理系の仕事か」 - カレーなる辛口Javaな転職日記 こう見えてかなり真面目な人間なんで、こういうことを言われると「そうか僕は職に目が眩んだまがい物のゴミ人間として、きっと何者にもなれず一生を終えるんだ……」と中央線を止めたい気持ちになったりするんですよね。

＊ ネタ元 Rubyのブロックつらい問題を解決する暗黙のブロックパラメータ - Qiita RubyPythonのブロックラムダつらい問題 Pythonでショートコードをしようとおもうと、時々こういうことが起きます。 map(lambda it: it.upper(), ['foo', 'bar', 'baz']) それぞれの要素に対してupcaseを適用する、ただそれだけのためにitを2回も記述しなければなりません。っていうかそもそもlambda:って読みにくいです。 Pythonはラムダをあまり使わない言語なのでこの様なコードを書く機会は少ないですが、それでもちょくちょく出番があり、やがてあなたは辟易するはずです。 <中略> 参考になる例として、ClojureやScalaでは暗黙のパラメータ（プレースホルダ）を導入することでこの問題を上手く解決しています。 <例は省略> やりましょう