年内に間に合わなかった… 2021年に主にお世話になった言語・ライブラリ TypeScript React chakra-ui dnd-kit Node Vite esbuild Docker(=> lima) とりあえず挙げてみたが、なにか特定のライブラリを使う、という感じではなく、レイヤーが一つ下にいった感じがあり、実際にはなんかもうちょっと下のミドルウェアみたいなものを作っていることが多かった気がする。ASTをいじるコンパイラ周辺ツールを作っていることが多かった。 サクッとなにか作る場合、 React + TypeScript + Vite(esbuild) が鉄板という感じで、 esbuild が異次元に速すぎて、typescript の変換もバンドルも、もはやこれ一本でいい気がしてる。 microsoft/typescript はもはや言語仕様の定義と型検査がメインであって、コン

2 年ほど走ってみました。 Qiita の Increments を退職します - mizchi's blog からの 転職活動 https://gist.github.com/mizchi/4e097923bb92399d03ced9da44f15cfa の結果 この記事は、自分の体験を書くことで、どういう人がフリーランスに向いてるか、というのをわかるように書いたつもりです。自分に近い属性ということで、ある程度プログラマとして経験を積んだ人向けです。 フリーランス辞める理由 フリーランスが嫌になったわけではないです。機会があればまたやりたいとも思っています。今回はフリーランスを続けるより良い選択肢があった、というだけの話です。 個人事業主を 2 年やって、消費税の徴収方式が変わるタイミングがあり、法人化してフリーランスの働き方を続けるか、個人事業主をやめるか、という 2 つの選択肢があり

主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され

今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる

このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(

という予感がしたので書く。正確に言うと機械学習の成果としての訓練モデルを。 まず事前に前置きしておくと、僕は機械学習をほとんど抑えていない。トレンドだけ追ってる。 大学生の時にニューラルネットワークを実装してみてフ～ンって言ってた程度に知識しかなくて、ディープラーニングが流行る前だから、「バックプロパゲーションってややこしかったけど、今は自動でモデルの最適化いい感じにやってくれるんでしょ？」ぐらいの雑な理解しかない。(この時点で怪しい) で、今はフロントエンドやってて、ここは機械学習は縁遠いように思えるかもしれないだろうけど、最近のGoogleはなんとブラウザで tensorflow を動かすのに情熱を注いでいる。 で、こんなのが Hacker News で流れてきた。 medium.com とりあえず試した。デモをそのままデプロイした。 PoseNet - Camera Feed Dem

ライセンス表記みるぐらいで深掘りはしてない シャニマスのコード読むか— human eslint --fix (@mizchi) 2018年4月24日 シャニマス、pixijs ですね— human eslint --fix (@mizchi) 2018年4月24日 pixi-ae.min.js たぶん after affect のコンバータなんだろうけどググっても引っかかんないな、内製かな— human eslint --fix (@mizchi) 2018年4月24日 s/after-affect/after-effect After effects to pixi.js | CodeSeek なら見つかったが、該当のライブラリ名で探してるが見つからず パーティクルはこれ https://t.co/NtIqPBBq7n— human eslint --fix (@mizchi) 201

某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない

これは怪文書です ここから10年はWASMがDOMのGCインテグレーションを果たしてJSを置き換えるか、JSがWASMに追いつかれる前にまともな言語として進化しきれるかのチキンレースになる ES Modules のブラウザ実装が枯れた頃に先鋭化したフロントエンドツールセット群は一旦そこで破棄され、シンプル化への揺り戻しが起こる 仮想DOMはブラウザエンジンの何らかの処理で更新が隠蔽されるか専用のDOM更新APIができ、Reactのような実装の手を離れる WASMで git, vim, bashなどが porting されるにつれ、再びWebOSのようなものが試みられる TC39でJSの型アノテーションの構文だけだけ決めよう => V8 が型アノテーションを元にランタイムを最適化したぜ！ => 気づいたら標準化みたいな流れがある IE11のサポートは延長されず、MSがなんらかの強攻策に出る

React.js界隈の人に聞きたい 前提 Reactより前に僕がやりたかったこととして、冪等性の担保の為に毎フレーム document.body.innerHTML を書き換えたかったがパフォーマンス的にそれが許されなかったが、Reactは擬似的にそれを達成させてくれたという圧倒的感謝🙏がある— ダイナモポグラマ (@mizchi) 2016年5月23日 SPA 世の中にSPAの需要があるのか？という点考えていたけど、需要がないからSPA技術がいらない、というのはたぶん間違ってて、SPA技術を持たない人が多いからその発想もなく、SPAで達成できることがイメージ出来ないのがアプリケーション設計の縛りになっている、という感じな気がする— ダイナモポグラマ (@mizchi) 2016年5月23日 GmailやTrelloやPivotalやグラブルは異常な技術の集大成ではなく、個別に分解可能な

prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5

昔からずっとqwertyの非効率さは感じていて、前々からやろうと思っていたのだけど、仕事中にやるとおそらく仕事がまったくすすまなくなり、ストレスでヤバくなるということはわかっていたので、この連休中に覚えてしまおうと思った。 今は二日目 なぜ Dvorak か 英文入力において、QWERTY配列と比べて上段と下段の使用頻度が低くなるように設計されている。 そのためQWERTY配列に比べて、英文入力における指の移動距離を短くすることができる。この特徴から、腱鞘炎などの予防に効果があるとされる。 母音は左手に集中しており、英文の入力において母音に連接しやすく高頻度で使う子音ほど、右手に集中している。 このために右、左、右、左とリズミカルに打鍵できる確率が高まり、QWERTY配列に比べて高速かつ効率的な入力が可能であるとされる。キーボードをタイプする速さの世界記録は、この配列を利用する者によって樹

ぼくのフロントエンドの情報収集ソース | Yuhiisk みたけど多すぎて逆に機能不全になると思う。 自分が主に見てるのは次の2つ。 efclのはてなブックマーク JSer infoのazuさんのはてブ。 Echo JS - JavaScript News Hacker News のJS版みたいなもの これを読み流すんじゃなくて、LDRで一件一件丁寧にみてる。日本語圏で再生産され続ける情報に意味があるもの少ないので、上流とまとめだけみればよい。

「最近のReactへの言及についての違和感」というエントリ書いたら燃えますかね— イカid:mizchi0x (@mizchi) 2015, 6月 7 僕がみた資料の中でFluxの設計について正しい理解をしていると思えるのはげたさんのこの資料だけです https://t.co/XaKHhhuP2A— イカid:mizchi0x (@mizchi) 2015, 6月 7 みんなsetStateに騙されてる— イカid:mizchi0x (@mizchi) 2015, 6月 7 一部で「React使うとコード量が増える」という意見、サーバサイドで書いたテンプレートのレタッチをするjQueryと比べたらそりゃそうなんだけど、SPAでそもそもJS側がテンプレート握るような環境では handlebars とかで書いてたところが JSXになるだけでそれ移行コスト— イカid:mizchi0x (@mi

最近の不満、日本人はライブラリ使って満足してる人が多くて、他人が作ったライブラリがすごいし便利最強みたいな人が勉強会コミュニティのボスになってたりするんだけど、海外だったらそのボスがプロダクトオーナーだったりするわけで、明らかに情報格差になってる— 損益分岐点 (@mizchi) 2015, 3月 14 技術文書は翻訳コストが高いのでそのコスト払った人に敬意が払われるのはいいとして、降ってきた変更に対してフィードバックもせずに文句いう人が(俺含めて)多いのでどうにかしたいなという気持ちがある— 損益分岐点 (@mizchi) 2015, 3月 14 言語が障害になってて報告経路がわからんってのが理由の一つだったけど、最近はGithub Issueで一本化されつつある。とはいえ要望出すフェーズ超えてディスカッションになると日本人の平均的な英語の能力だと明らかに不足で何も言わなくなる人が多い気

hueはiPhoneやAPIから操作可能な電球で、前々から話は聞いてたんだけど最近自分のFacebookで @NStyles や @Hageatama が異様に盛り上がってたので、つい買ってしまった。 今の家、ワンルームの照明が物理スイッチしかなくて不満に思っていたので、いやリモコンつきとか買う選択肢はあったんだけど、せっかくなのでHueにしてみたワケ。 Philips hue(ヒュー) スターターセット 929000259901 エコパッケージ [フラストレーションフリーパッケージ(FFP)] 出版社/メーカー: Philips(フィリップス)発売日: 2014/01/26メディア: Personal Computersこの商品を含むブログを見る 設置自体は簡単だった。マニュアル通りなんで特に問題なし。 天井に吊るすためにライティングバーを買った。 ELPA ライティングバー コンセント

僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。

僕は本当にAngularが嫌いで、もはや許せないレベルに達していて、今ではもう本当に使いたくない。 イカ理由。 APIがほんっっっっっとうに糞 趣味の問題といえばそうでもあるが僕は糞だと思う 実装が黒魔術 良識あるJSエンジニアなら Function.prototype.toString() しない 実際に一部のクロージャが破壊されてて挙動が直感に反する DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない Googleだから許される、みたいなコミュニティの驕りが本当に嫌 Angularの都合だけでChromeでObject.observeを前倒しするのやめろ Angularの内部モジュール同士が密結合 DI, module, factory, それぞれ大きなテーマなのに密結合 使いはじめるとAngularをやめることが困難 パフォーマン