Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
俺の webpack.config.js-20200503 - mizchi's blog
基本思想 とにかく薄く。必要なものだけ。基本は ts-loader を transpileOnly: true で使うだけ。最悪これだけでいい。型チェックはIDEか yarn tsc -p . --noEmit でやる。 CRA や parcel は使わない。暗黙な振る舞いが多すぎるので。一切勉強したくない人はいれていいと思うが、その場合 eject しない、dist ディレクトリをそのまま使うこと前提。 style-loader/css-loader は外部CSSを読むときに設定する worker-plugin はなくてもいいけど、 worker もビルドしたいことが多いので、入れていることが多い html-webpack-plugin と webpack-dev-server 組み合わせると、他と組み合わせずに完結して動く。このHTMLを本番で使わずとも、デバッグで使ってることが多いの
報告: 結婚しました - mizchi's blog
なんか今日は2がいっぱいあるので @syakejs と入籍しました。 以下例のリンクですhttps://t.co/dnzQMbvxdu pic.twitter.com/FrEcrOGUAz— ヌー (@mizchi) 2020年2月21日 私事ですが(と個人ブログでいうのもなんですが)、syakejs:(blog) と結婚しました。彼女は Webエンジニアだったり、大学でセキュリティの研究をしてたりしています。競プロやCTFもやってるらしいです。 話を聞いてみると、昔から僕のブログやTwitterをみていたファン？だったらしいのですが、最近なんやかんやあってコンバージョンしました。 入籍いつしよっかーという話になって、西暦2020年(令和2年)2月22日というゴロがよかったので、この日に決めました。 なにかしたからと言って別段何かが変わるというわけではなく、これからも普段どおりやっていくの
2020 年、 React 軸で学ぶべき技術 - mizchi's blog
なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
当初の懸念どおりブラウザのプッシュ通知は邪悪に使われはじめている。実装側はクリックまで購読確認を待つべき。 - mizchi's blog
追記: 2019/11/12 2年経ったけど体験が悪化し続けた結果、 Firefox がこの記事の通りになりましたね… www.fxsitecompat.dev プッシュ通知、ネイティブアプリの機能郡をWebに持ち込むPWA技術の売りの一つだが、当初から懸念されていたとおり、非常にノイジーなものとなってしまっている。自分も気づけばあらゆるサイトの購読確認を、無意識で拒否を押すようになってしまった。 hagex.hatenadiary.jp 少し前の記事。最近はどこかで wordpress のプラグインになったのか、目にする機会が非常に多くなり、非常にストレスフル。最初は技術的な目新しさからか、ある程度容認していたが、さすがにこの状況が悪化する一方で、本気でやばいんじゃないかと思っている。とくに初見のブログの記事を読む前に、購読確認が出るのが最悪の体験となっている。 そもそもプッシュ配信とは
フロントエンドへの複雑化について、一つの視点 - mizchi's blog
これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記
最近のフロントエンドの変化とビルドツールについて - mizchi's blog
界隈の雑な会話です。注意点として、フロントエンドガチ勢寄りの方面なので、一般的な感覚とは乖離してる可能性があります。 基本的には http://www.s-arcana.co.jp/blog/2016/12/12/3438 や kikuchi1201.hateblo.jp を念頭に。 動き早いって言われるフロントエンド界隈、この1年何も進んでないからな— 現場の声 (@mizchi) 2016年12月14日 今年のフロントエンドの統括、es2016でしょぼかったので皆es2015+ みたいなノリが抜けなかったのと、redux以外のfluxが脱落したのと、angular2+今年も出なかったねというのと、たぶん eslint の採用が増えてそう(肌感)のと、flowの採用が増えたぐらい— 現場の声 (@mizchi) 2016年12月14日 実際browserify/webpackは先行実装だ
Re: React.js界隈の人に聞きたい - mizchi's blog
React.js界隈の人に聞きたい 前提 Reactより前に僕がやりたかったこととして、冪等性の担保の為に毎フレーム document.body.innerHTML を書き換えたかったがパフォーマンス的にそれが許されなかったが、Reactは擬似的にそれを達成させてくれたという圧倒的感謝🙏がある— ダイナモポグラマ (@mizchi) 2016年5月23日 SPA 世の中にSPAの需要があるのか？という点考えていたけど、需要がないからSPA技術がいらない、というのはたぶん間違ってて、SPA技術を持たない人が多いからその発想もなく、SPAで達成できることがイメージ出来ないのがアプリケーション設計の縛りになっている、という感じな気がする— ダイナモポグラマ (@mizchi) 2016年5月23日 GmailやTrelloやPivotalやグラブルは異常な技術の集大成ではなく、個別に分解可能な
さよなら CoffeeScript - mizchi's blog
prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5
睡眠障害で辛い - mizchi's blog
一緒に働いたことがある人は知ってると思うけど、自分は尋常じゃなく朝に弱い。 で、自分でもさすがに酷いと思っており、様々な努力をしたが改善せず、結局睡眠科をうけて睡眠障害だと診断された。 自分がそうだと疑った理由は 睡眠障害らしきものとわたしの20年間振り返りメモ - 青いの のおかげ。inoaoさんとは違うけど、自分は 睡眠相後退症候群 DSPSに罹患して9時5時生活を送ることは、毎日6時間の時差ぼけを体験しているようなものである。患者は週日には数時間しか眠ることができないので、週末には午後まで眠って睡眠時間を補うことがよくある。週末によく眠ったり、普段昼寝をしたりすることで、DSPS患者は昼間の眠気から解放されるが、遅い睡眠相はそのまま続く。 DSPS患者は、極端な夜型の傾向がある。彼らは、夜が最も頭が冴えていて、物事がうまくでき、創造力にも溢れていると感じる。彼らは単純に早く眠ることが
Rx.js, Immutable.js について - mizchi's blog
自分はImmutable.jsとRxをなぜ採用しなかったか、自分の考えを整理するために書き出してみる。 僕の理解が及んでいない無知のゆえのアレもあると思うので間違っていたら罵倒ブコメお願いします。 Immutalbe(.js) 扱う対象をイミュータブルにするのはたぶん間違いなく正しい。正しいが、現時点のエコシステムにおいてその必要性を示せてない。具体的に言うと、Immutable.jsの110kbのオーバーヘッドの配信負荷、読み込み負荷、開発者の学習コストを支払ったとき、それに見合う価値を提示できているのか？にまだ疑問が残る。 PureなJSでも、ただ単に目的のデータを作るだけなら、ほとんどのケースで組み込みのarray.mapとObject.assign(またはそのポリフィル)で代用できる。(勿論生成したオブジェクトに副作用を加えないことが前提になるが) あと型がない環境でImmutab
JavaScriptの情報の仕入れ方 - mizchi's blog
ぼくのフロントエンドの情報収集ソース | Yuhiisk みたけど多すぎて逆に機能不全になると思う。 自分が主に見てるのは次の2つ。 efclのはてなブックマーク JSer infoのazuさんのはてブ。 Echo JS - JavaScript News Hacker News のJS版みたいなもの これを読み流すんじゃなくて、LDRで一件一件丁寧にみてる。日本語圏で再生産され続ける情報に意味があるもの少ないので、上流とまとめだけみればよい。
Angularが嫌い - mizchi's blog
僕は本当にAngularが嫌いで、もはや許せないレベルに達していて、今ではもう本当に使いたくない。 イカ理由。 APIがほんっっっっっとうに糞 趣味の問題といえばそうでもあるが僕は糞だと思う 実装が黒魔術 良識あるJSエンジニアなら Function.prototype.toString() しない 実際に一部のクロージャが破壊されてて挙動が直感に反する DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない Googleだから許される、みたいなコミュニティの驕りが本当に嫌 Angularの都合だけでChromeでObject.observeを前倒しするのやめろ Angularの内部モジュール同士が密結合 DI, module, factory, それぞれ大きなテーマなのに密結合 使いはじめるとAngularをやめることが困難 パフォーマン
ゲーマーのエンジニアが転職先としてソーシャルゲーム業界を選ばない理由 - mizchi's blog
今回の転職にあたって、各方面から「なんでゲーム業界にいかないの？」と何度も訊かれたので、書いておく。 僕のキャリアはソーシャルゲーム業界から始まって、教育の会社にいって、次はxxxだ。転職先に関しては後日。 僕はそもそもスーパーファミコン時代にスクエニ黄金期の洗礼を受けた古い気質のゲーマーで、ソーシャルゲームを一切楽しめない人間で、ソーシャルゲームに開発として関わった人間でもある。バイアスが掛かっているのは認める。 古巣がどうこうって問題ではなくて、業界全体の問題なので、そこらへんは誤解しないように。 ソーシャルゲーム業界 今のソーシャルゲーム業界の開発現場は、開発の現場が「面白いゲームを作ろう」というモチベーションにはなりにくい。 感覚として、ソーシャルゲームってのは「課金させる場」を作ることであって、面白いゲームを作ることはあまりフォーカスされない。 それを言えばコンシューマだって売り
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
はてブオフのコンテキストがブっ壊されたこと - mizchi's blog
今日は風邪で寝込んでたんだけど気分悪いついでにあの件胸糞悪いなと考えていたら頭がグルグルしだして、グワーと書き連ねてしまった。 最初に、僕はツイキャスを途中まで見ていた勢で、現場にはいなかった。某プロポーズのシーンは見ていないが、LTは見ている。 オフ会そのものの感想 最初に感じたのは、自分が大昔にTwitterをはじめたときの、あのグチャグチャな感じがあの場で再現されていて、やっぱり行けばよかったと思う程度には楽しそうだった。ネット越しに見知らぬ人が仲良くしているのをみたときに感じる、「けまらしさ」という感情を久しぶりに思い出した。 僕はああいう場が好きだ。別種の人間がぶつかる場所。異なる価値観同士が、お互いの価値観を手探りに伺う場所。全く知らない人間が集まる場所が提供されるのは、東京に出てきて本当に良かったと思えるものの一つ。まあ僕がいったとしても、運営が1/3ほど知り合いだったからそ
Swift ファーストインプレッション - mizchi's blog
とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV
ボーイフレンドを直す方法 あるいは賢いjQuery.Deferredの使い方 - mizchi's blog
問題 モバイルは回線が不安定なので、ロードの失敗が頻繁に起こります。 開発時は高速なwifi環境で開発しているので、リリース間近になって帯域を圧迫していることに気づいたりします。 解決方法 画像を先読みします var preload = function(src){ var d = $.Deferred(); var img = new Image; img.src= src; img.onload = d.resolve img.onerror = d.reject return d.promise(); }; 何をやっているかというと、空のimgタグをつくってそこに画像を読み込みます。その過程でブラウザキャッシュに画像が保存されます。正確に言うとこの時点ではどこにも紐付いていないのでGC対象ですが、その後すぐDOMに画像をはるなら問題ありません。 並列で先読みする(速い・不安定) va
twitterのid:mizchiがはちま禁止でBAN対象になった件に対し、作者kozoh氏に対して質問です - mizchi's blog
@kozoh氏に直接リプライを送ったのですがブロックされており、タイトルに @kozoh を含むタイトル爆撃も考えたのですが、さすがに攻撃的すぎるアプローチであり、おそらく僕の1favしかないツイートを理由にBANしたであろう@kozoh氏なら、観測範囲に引っかかると信じています。 経緯 今朝方、自分のtwitter @mizchi がはちま禁止によってNGされていることを知りました。 今からfirefoxのアドオン「はちま禁止」に登録されているアカウントを見つけた限り列挙します。アカウントの性質によって区別とかはしませんし、晒してどうこうという意図もありません。ただ、こういうものは公開されるべきだという私の判断です— メガフライゴンくろいK (@JoKuroi) 2013, 11月 26 追記: リスト、公開を希望しないアカウントが意図せずログが残ってしまう恐れがあるで削除しました。 自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
