2020年やったこと、考えたこと、触った技術のまとめ - mizchi's blog
今年の本業は、 3rd party script で、そこから呼ぶウィジェットを最適化するコンパイラを書く、その仕様を考えて、実装するという感じだった。要は Google Analytics と、最適化コンパイラ付き GTM みたいなものを作っていた。その内容は以下に書いた。 サードパーティスクリプトの極限環境向け Svelte パフォーマンス改善に Core WebVitals という大義名分を得た 今年は、 パフォーマンスのエンジニアをやっていた、と思う。サードパーティスクリプトの配信を生業にする会社のエンジニアとしては、来年の Core WebVitals というパフォーマンス関連の大きな変化で、波にのってやりたいことがやれたと思う。 Core WebVitals の導入で実際にどれぐらいの影響がでるか不明だが、パフォーマンスが SEO に影響する、というのは、 若干やりすぎと思いつ
2020 年、 React 軸で学ぶべき技術 - mizchi's blog
なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介
人類は(いつ？/そもそも？)ビジュアルプログラミングに至るのか。またはプログラミング的思考とはなんなのか - mizchi's blog
西村賢さんのこの記事について coralcap.co 68件のコメント https://t.co/jGBUcpTCoK “プレーンテキスト Markdown 時代の終焉 - portal shit!” https://t.co/1Q831CDuXY— 限界シェアハウスみたいなTL (@mizchi) 2019年11月18日 ↑ の記事や、あとは最近の slack の wysiwyg 化について色々思うところあった。 wysiwyg は人類の技術の進歩なのかコンピュータへの適応の失敗なのかは議論の余地がある— 限界シェアハウスみたいなTL (@mizchi) 2019年11月19日 編集してるものと、出力されるものが違う、という発想、エンジニアの発想であるのは間違いなく、markdown を使うのはプログラミング的な思考や訓練が前提にあるのはそうで、人間を訓練するか、内部状態が汚れるのを許容
リモートワークの設計と運用 / または Discord + VSCode LiveShare がいいぞという話 - mizchi's blog
この記事読んで自分のリモートワーク経験からどうやるのが今一番良いだろうか、という話をずっと考えていたので、書き出してみました。 リモートワークをする人必読。組織パフォーマンスを左右する「デジタル心理的安全」とは？ | 未来を変えるプロジェクト by iX（アイエックス） 自分自身はフルタイムリモートとフリーランスでのリモートの2つの経験があります。 次の会社が申請すればリモート可というスタイルなのですが、自分がリモートワークする場合、働く環境に期待しているのはこういうことだ、というのを事前に宣言しておく目的もあります。 フルリモートではなく、部分的なリモートを想定しています。 リモートワークに期待すること リモートワークは、基本的には「うまく運用すれば効率が下がらない」というものです。リモートワークで効率が上がることもありますが、基本的にはある種の福利厚生、雇用競争力のためと割り切ったほう
フリーランス完走した感想 - mizchi's blog
2 年ほど走ってみました。 Qiita の Increments を退職します - mizchi's blog からの 転職活動 https://gist.github.com/mizchi/4e097923bb92399d03ced9da44f15cfa の結果 この記事は、自分の体験を書くことで、どういう人がフリーランスに向いてるか、というのをわかるように書いたつもりです。自分に近い属性ということで、ある程度プログラマとして経験を積んだ人向けです。 フリーランス辞める理由 フリーランスが嫌になったわけではないです。機会があればまたやりたいとも思っています。今回はフリーランスを続けるより良い選択肢があった、というだけの話です。 個人事業主を 2 年やって、消費税の徴収方式が変わるタイミングがあり、法人化してフリーランスの働き方を続けるか、個人事業主をやめるか、という 2 つの選択肢があり
dota auto chess が張り切った麻雀みたいで面白い - mizchi's blog
dota auto chess は dota2 の MOD 。Steam で無料の Dota2 をダウンロードして、その MOD として遊ぶ。なので無料で遊べる。Dota2 のシステムを部分的に流用しているが、基本的には独立したゲームであるため Dota2 を知っている必要はない。 Steam：Dota 2 元々 autochess は中国産のMODだが 3 月に日本語にもローカライズされ、日本人にもとっつきやすくなった。 このゲームを簡単に説明するならば、麻雀のようにユニットの役を揃えて、ユニットをチェス盤に配置して、戦闘は自動で行われるのを観戦する、といったもの。 ルール 8 人同時プレイ。毎ラウンド自分以外の誰かとランダムに勝負し、生き残ったユニットの戦力差で最大 HP が減る。HP がゼロになれば終了。負けたらさっさと部屋から抜けて、次の勝負にいってもいい。 ラウンドごとに収入があ
フロントエンドの開発環境に Docker は不要(少なくともMacでは) - mizchi's blog
追記: 前提部分 開発環境を docker-compose で抽象することが最近のベストプラクティスだとされているが、フロントエンドをコンテナに突っ込むと無視できないIOボトルネックが発生する。 とくにwebpackのファイル監視からのビルドで発生する高頻度のIO処理を捌くために、フロントエンドだけはホスト環境に移したほうがいい、という主張。 これについて speakerdeck.com 自分の意見 Web開発者の主要な開発環境である Docker for Mac は I/O がとにかく遅い (3x~5x) data volume の driver やら cache を工夫しても遅い npm install/webpack は 基本的に I/O ヘヴィー とくに大規模開発時の watch => build がクリティカル webpack.conifg の entry で自分が関与する部分以
Chrome 73 で Desktop PWA Support & mdbuf アップデート - mizchi's blog
developers.google.com Signed HTTP Exchange もですが、個人的に待望だった Desktop PWA が正式リリース。 PWAアプリをウェブアプリのように振る舞わせることができます。 例えば mdbuf を開いて、「mdbuf をインストール」を選択すると… モーダルが出て Win/Mac のアプリのように立ち上がります mdbuf について https://mdbuf.netlify.com サンプルで紹介しましたが、これは僕が作ってる markdown のプレビューツール です。 amachang さんや結城浩先生へのインタビュー、その他このブログの記事、各種書籍への原稿も全部これで書いています。 mdbuf v1.0.0: 最高の Mardkown Preview を目指して - mizchi's blog この時点からさらに自分で使い込みながら
SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
off-the-main-thread の時代 - mizchi's blog
off-the-main-thread は今フロントエンドで熱いテーマの一つです。日本語圏では今ひとつ話題になってないので紹介しておきます。 off-the-main-thread の概念の大まかな概要については、Chrome 開発者の nhiroki さんの日本語の記事があるので、こちらを参照してください。 nhiroki.jp speakerdeck.com ここまでのあらすじ 従来のウェブブラウザーでは、一つの画面につき一つ割り当てられる、UI スレッドと呼ばれる名前空間で様々な処理を行ってきました。DOMセマンティクスの評価, CSS による rendering / painting、JSのScripting…。もちろん裏側ではブラウザが様々なバックグラウンドサービスに処理を委譲し、スレッドで実行され、その非同期な結果を受け取っているわけですが、少なくともUIスレッドで走るJSから
「この〜を導入すると、なんとこうなりました！どうです？わかりやすいと思えませんか？」 - mizchi's blog
主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され
二世の呪い - mizchi's blog
僕はエンジニアで、このブログで書くことは、そういうテーマを期待されていることを知っている。それ以外はノイズだから、あんまりやらないでほしい、とも。 でもこれは自分のアイデンティティの根幹に関わることで、そういう前提で、一部で話題になってたこの動画を見た。幸福の科学の大川総裁の息子の、幸福の科学との断絶宣言。 www.youtube.com happy-science.jp エンタメの文脈でそれはどうなんだと思うところはあれど、内容自体は非常に思うところがあった。 8歳ぐらいまで、家の宗教に疑問を持つことはなかった。幼稚園までは、人に隠れて食前の祈りを捧げていたと思う。それが褒められると知っていたから。 ティーンエージャーの頃、自分は怒りに支配されていた。自分の家の異常さを客観視できるようになり、その異常さを許せなくなった。自派以外を否定する排他的な教義、一時期採用された一夫多妻、そしてその
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
Chrome に PWA for Desktop が来ていたので next-editor で試した - mizchi's blog
追記: Canary じゃなくてもいいらしいのでタイトル修正した。が…実装具合はよくわからない 今年中に来るとは聞いていたやつ。要はウェブアプリを デスクトップアプリ化する。Electron と違って Chrome の Sandbox と同じ権限で動いている Twitter Lite をデスクトップ PWA にして使ってるんだけど、最 & 高です。 Mac だと Chrome Canary で enable-desktop-pwas のフラグを立てると使えます。 pic.twitter.com/0TPhe8gyQL— Eiji Kitamura / えーじ (@agektmr) 2018年7月12日 ちなみに Chrome Canary + フラグは上級者向けなので、自身のない方はいましばらくお待ち下さい。そのうち安定版で普通に使えるようになります。— Eiji Kitamura / えー
手足がもがれる感覚 - mizchi's blog
最近乗り換えたもの Twitter: 夜フクロウ => Tweetdeck ブラウザ: Firefox(Vimperator) => Vivaldi RSSリーダー: Livedoor Reader => Inoreader ただ、これらにかなり不満がある。 情報には上流がある。情報の上流は、一次情報が乱雑に転がってる未整備の荒野みたいなもので、下流はその二次情報やまとめみたいなもの。キャズム理論でいうと、一次情報に接する人がイノベーター、イノベーターを観測する人がアーリーアダプター、イノベーターまたはアーリーアダプターによる編集物を閲覧する人がマジョリティという分類になると思う。 自分が思う近年のインターネットの問題は、一次情報を整理していたイノベーターやアーリーアダプターに対するサービスが本格的に終わってきたこと。 最初に挙げた3つのサービスは、どれもサービス終了やサポート終了などの必
ServiceWorker as a Service, または Universal ServiceWorker という発想 - mizchi's blog
ServiceWorker とは本質的に リクエスト＆レスポンスモデルであるので、それをサーバーサイドで実装で一種のサーバーロジックとして動かしてしまって良いはずだ ー という発想に目から鱗だったので、ちょっと考えてみたいと思う。 www.publickey1.jp ここで試せる。 https://cloudflareworkers.com/#a9bc9ef6b4248289c71518581df30bc7:https://tutorial.cloudflareworkers.com Cloudflare はCDN業者なので、 それに特化して Service Worker as a Service みたいな表現はしていないが、実態としてはサーバーサイド ServiceWorker だ。Fastly では varnish のミドルウェアなどでキャッシュ破棄設定のロジックやリダイレクトを書いて
いつ ReactNative を使っても大丈夫か - mizchi's blog
AirBnb がReactNativeをやめることが話題になってますね。 medium.com RNの未熟さ、社のRNのForkのメンテナンスコスト、JavaScriptのスケールのしなさ、JavaScriptCoreの実装の違い、クラッシュレポートが信頼できない、開発者は主に片方のプラットフォームしか知らないのでOSSのライブラリはバグってる、結局ブリッジを描く人間が必要、人が雇えない、山ほど出てくる…— Hello (@rejasupotaro) 2018年6月19日 以下私見です。 RN採用可否のフローチャート 自分がRN使いたいといって相談された際にはこういう感じで返してます。基本的にはExpo 採用可能か否かで判断してます。 Expo ではじめる ReactNative 開発環境 - Qiita プラットフォームごとにUXを突き詰める必要がある => RN やめとけ Q: 社内に
最近のフロントエンドのエディタ事情 - mizchi's blog
これは、個人でどんなエディタを使うべきか、ではなく、「チームとして」新しいものを採用するとき、あるツールがエディタ横断で便利かどうかを考える必要がある。 自分個人としては、基本はAtomを使って、TypeScriptを書くときだけVS Code を使っている。ターミナルでは Vim。 環境でエディタを選ぶ 最近の新規プロジェクトでは、とくにブロッカーがなければ TypeScript を使っていいと思う。TypeScript を使うなら当然 VS Code を使うことになる。Atom や Vim でもいいが、TypeScriptのエディタとしては、流石に完成度が頭一つ抜けてる。JavaならJetBrains 的なノリで、TSならVSCode、そういうものと思ったほうが楽。 TS以外なら、エディタはなんでもいいが、ある程度流行ってるものでないとエコシステムに追いついてくれない。 prettie
Flutterのコミットログを読んで、これは一体何由来なのか調べた - mizchi's blog
本当に凄い雑にコミットメッセージと気になったdiff だけ読んだ感じなので正確性は保証しません。 Flutterの実態、Chrome と同じく描画エンジンの Skia を直接叩いている点、Dart であるという点、仮想DOM相当のモジュールが後付である点などから、これはおそらく Dartium から既存のウェブブラウザの後方互換を切り捨てたところからスタートしてると想像できる— human eslint --fix (@mizchi) 2018年5月22日 結果としてこれは間違ってました とりあえず dart engine の initial commit 見つけたが昔の名前は Sky だった模様 https://t.co/HwFKCpKtYv— human eslint --fix (@mizchi) 2018年5月22日 The approach we're exploring is
クライアントサイドのモデルとは何か 後編 ~ 単方向データフローと参照透過性 - mizchi's blog
この記事は クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog の後編。 前提として、今回の出す例で、「Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる」という意見があると思う。これに関して、そもそも「SPA というものが、いかに実現可能になったか」という視点の話であり、また、自分の経験上「フロントエンドなんて雑でシンプルでいいでしょ」というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。 適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。 Flux 以前 先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
