サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
mizchi.hatenablog.com
hooks が発表されてから趣味でも現場でもずっと hooks を使っています。おかげでだいぶこなれてきて、だいたいなんのライフサイクルでも表現できるようになってきました。 最初は単に useState が state を、 useEffect が componentDidMount/componentDidUpdate を置き換えるもの、と説明を済ますつもりでしたが、 useEffect についてはライフサイクルのモデルがぜんぜん違うので、別の説明をする必要があるように感じていました。 で、その結果 React Hooks を理解するには、関数のメモ化を理解するのが最も簡単だと思ったので、その説明をしつつ、イディオムを解説していこうと思います。 最初に: React Hooks は何であり、何ではないか 関数コンポーネントが状態を持てるようにするもので、関数のメモ化のテクニックを多用しま
gigazine.net 先日作ったこれです recording-studio.netlify.com いつもだったらこういうの紹介しないんですが、GIGAZINEさんがRecording Studio(仮。なんか適当に名前をつける必要があった)の紹介記事を書いてくださり、アプリ紹介のついでで、僕が面倒で書かなかったアプリの使い方のドキュメントまで詳しく書いてくださっています。リテラシー高い人しか使えない状態だったので、ありがたいです。 自分で読んでみると、たしかにマイクのパーミッションとか開始・終了とか暗黙的でしたね… いろいろ機能追加を考えてたんですが、これ自体は小さくまとまって完成してるので、ドキュメントを古くしないよう、新しくつくるにしても別ドメインにしようと思います。
Chrome でマイクからの音声を録音して、その音声認識で書き起こしも同時に行うツールを作った。 recording-studio.netlify.com で遊べる。 Chrome に搭載されてる Web Standard Proposal? の SpeechRecognition API を使っている。 developer.mozilla.org Chrome のみだが、 PC Chrome だけではなく Android Chrome でも動作確認済み。 ブラウザをオフラインにすると動作しないので、このAPI の 中身はたぶん Google Speech to Text API だと思われる。 出力 録音したものは webm ファイルとしてダウンロードできる。認識されたテキストも、タイムスタンプ付きのプレーンテキストなので、適当にもっていって、ぐらいの気持ち。 クラウドで音声認識してるこ
ペライチの markdown のコードブロックをビルドして iframe の中で実行できる https://markdown-code-runner.netlify.com で遊べる。 前々から作れるなと思っていたので作ってみた。3時間ぐらいかかった。 仕組み monaco-editor でコード編集 remark で codeblock の AST を収集 rollup と rollup-plugin-virtual でインメモリ上に依存を構築して bundle iframe でクロスドメイン制約を与えた状態で実行(ifram.sandbox="allow-scripts") 外部からの入力受け取れないし、そもそも自動実行できないのでコード実行とはいえセキュリティ要件はそこまで厳しくないはず TODO 実験的に React だけ特別扱いしてるが npm 対応したい monaco の補完用
漫画 ドロヘドロ(1) (IKKI COMIX) 作者: 林田球出版社/メーカー: 小学館発売日: 2018/11/12メディア: Kindle版この商品を含むブログを見る ずっとよみたかったが kindle 版が発売されたのと、また完結したということで アオアシ 1 (ビッグコミックス) 作者: 小林有吾,上野直彦出版社/メーカー: 小学館発売日: 2015/04/30メディア: コミックこの商品を含むブログ (3件) を見る サッカーユースの話 イサック(1) (アフタヌーンコミックス) 作者: 真刈信二,DOUBLEーS出版社/メーカー: 講談社発売日: 2017/07/21メディア: Kindle版この商品を含むブログ (2件) を見る 江戸時代、日本の傭兵がヨーロッパに渡って、30年戦争の中で仇(?)を追う話。 デッドデッドデーモンズデデデデデストラクション (1) (ビッグコミ
エンジニアの転職とかプログラミング教育周りで考えていたこと。 フランス革命と技術のコモディティ化 最近フランス革命やナポレオン戦争やナショナリズム、そしてクラウゼヴィッツの戦争論などを調べたりしていたんだけど、傭兵や専門技術の扱いについて、示唆的なものが多かった。 当時の傭兵は、扱いが難しかった大砲・銃火器を扱う専門集団で、技能職でもあった。それが 18 世紀になり火器の改良が進み、産業革命で効率的な生産が可能になり、そしてナポレオンによる国民軍の創設、そのヨーロッパにおける戦果によって、傭兵はその役割を終えた。 「傭兵はすぐ逃げる」というのが定説だが、彼らは金で動く専門職なので、負ける側に付く理由がないので、当然とも言える…特に戦争という、敗者の支払いが期待できない場では。そして彼らを雇う王侯貴族の経済力が、そのまま軍団の動員力に直結した。常備軍を持たない分、平時のコストも安くついた。
mdbuf, そこそこ使い物になりそうな品質になったので改めて紹介します。 https://markdown-buffer.netlify.com で遊べます。 コンセプト ブラウザで完結 編集とプレビューのみに注力 PWA 機能を最大限に活かす 特長: 高速な Markdown プレビュー 色々頑張ってみた結果、高速な入力が可能です。 試した限り、 100000 文字以上だと流石に重くなっていきます。将来的に領域を分割してレンダリングできないか実験中です。 Desktop PWA 対応 PWA アプリとして、オフラインで起動することが可能です。編集中のデータはブラウザ内に保存されます。 編集位置への自動スクロール Markdown を編集すると、プレビュー側の対応する行へ自動的にフォーカスします。 自分が知る限りこの機能を実現してるのは mdbuf だけです。 アウトライン機能 指定した
ヒストリ履歴からよく使ってるものをお焚き上げする。 注意点: npm 周り、グローバルコマンドは npm i -g で入れてて、ローカルで扱うものは yarn で使うという癖がある 追記: シェルじゃなくてCLIだろと言われるのが多かったので訂正した vscode $ code . -r 現在ディレクトリを VScode で開く。 -r が肝で、新しいウィンドウを生成せず、既存のウィンドウを開き直す。 yarn $ yarn install --prefer-offline yarn install 時にローカルキャッシュを優先する。テザリング環境下でリポジトリを作成するのに便利。 フリーランスになってから出先で作業することが多く、ギガ足りない問題が多々発生した。 git $ git clone <github-url> --depth 1 HEAD だけ clone する。テザリング環境
12月はなんとなく新しいことをやりたくなる。ということで、elm をやってみた。 大昔に触った気がするけど、文法が Haskell っぽいこと以外、何も覚えてなかった。というか当時触った signal とかがなくなってたので別物になってた。 作ったもの 勉強がてら作った、球拾いゲームみたいな何か コードはここ https://github.com/mizchi-sandbox/elm-playground elm-platform, svg の扱い, キー入力、乱数の副作用の分離などが学べた。乱数は面倒くさくなったので外部(JS)からSeed与える方式にして、気持ち純粋になった。 (自分の)環境構築 Parcel を使った brew install elm # OSに応じて mkdir elm-playground cd elm-playground yarn init -y yarn a
react-redux v6 で中身が新しい方の Context API になったと聞いたので、コード読んでみたらContext自体が外部に export されていた。じゃあ hooks の useContext と組み合わせて使えるじゃん、と思って実験してみた。 useContext で connect 相当の処理を置き換えてみる。 https://github.com/reduxjs/react-redux/blob/master/src/index.js import React, { useContext } from "react"; import ReactDOM from "react-dom"; import { createStore, Store } from "redux"; import { ReactReduxContext, Provider } from "r
初報を聞いたとき、描画系だけ blink に入れ替えて処理系は V8 使わず ChakraCore などに入れ替えるのかな、と思っていたが、どうも V8、というか chromium 一式を使うらしい。 正直に言って、Edge が死ぬことに、そこまで強く思うところはない。Edge は内部的に自身のベンダープレフィックスで webkit と名乗るぐらい (標準ではなく) webkit との互換性の意識が高いので、お前自分のことを webkit だと思ってるもんな、みたいな気持ちがあった。 webkit みたいなブラウザが消えて、webkit 後継のブラウザをベースに作り直される。開発者として追うべきは、個別の実装ではなく依然として標準仕様であって、それだけの話。 リリースサイクル 僕が思うに、 MS の抱えていた真の問題は、Windows に紐付けられたリリースサイクルとサポートにあって、Wi
なぜ初心者は webpackが解らないのか?- Why can’t you understand the webpack? - from 健人 井関 www.slideshare.net この記事バズってたけど、わからない人がよりわからなくなる、という点で問題だと思っていて、webpack の目的の本質的な部分から整理する必要があると思います。 (あと友人が webpack に挑戦していたので入門資料も兼ねてる) Webpack の本質的な部分は次の3つです。それ以外は全部おまけ機能だと思ってよいです。 ES Modules のエミュレート node_modules のリンカ 拡張子ごとの変形 Webpack が本当にやりたいこと こういうコードがあるとします。 // src/a.js export default () => console.log('hello'); // src/in
ReactNative 触った事ある人なら、ReactNative.View の iOS の UIView や Android View みたいな一貫性のある基底クラスが羨ましい人も多いと思う。 今の Webでは実質 div がそれを担っているわけだが、div になんでも押し付けるのはよくないという意見もわかるところがあり、それ専用の基底となる x-view 要素を作るとどうなるだろうか。 ほしいもの デフォルトが display: flex; デフォルトが box-sizing: border-box; flex は便利だが Web のプリミティブ要素として既定値でflex を持つものはないので、毎度手数が多くなって嫌だなぁぐらいの気持ちがあった。 実装 とりあえず ReactNativeWeb がどう実装してるか真似しつつ実装した const defaultViewStyle = do
なんでそんな手が速いのか聞かれたので、最近使ってるSPAボイラープレートを紹介しておきます。 github.com $ git clone git@github.com:mizchi-sandbox/minfront.git --depth 1 myspa $ cd myspa $ yarn install $ yarn dev # Start app server 終わり。 src/main.tsx か src/index.html を編集して、 yarn build && yarn deploy で netlify にアップロードできます。(要 netlify アカウント) こんな感じ https://gallant-yalow-997008.netlify.com プロダクションで使えるちゃ使えるかもしれないけど、議論の余地があるようなものを含まない最小構成。 含まれるもの yarn
mizchi/redux-workerized 作った。 yarn add redux-workerize で入る。 元々は react-hooks で redux へのアダプタを書いていただけのライブラリだったが… TypeScript フレンドリーなAPIにする ReactRedux.Provider の異なるAPI表現だけじゃ面白くない じゃあ Redux.Store を worker に置いて postMessage で更新しよう mapStateToProps や更新処理の抑制の処理もCPU使うから、worker に置こう JSON飛び交ってるだけだし、 React だけじゃつまらないから Vue Plugin も提供しよう 結果、ビジネスロジックが Worker に切り出された上で、 React と Vue が同じ Store を共有するようになった。 どうなってるかというと
大きく、末端コンポーネントと全体アーキテクチャの視点がある。 末端コンポーネントでの Hooks ここはあまり議論の余地なく、setState で local state を持っているものや、 componentDidMount していたものを置き換えることが出来ると思う。 FC を class にせずにちょっとリッチにするのが簡単になる。 class の setState 相当 function Counter() { const [count, setCount] = useState(0); const onClick = useCallback(() => setCount(s => s + 1), []); return <button onClick={onClick}>{count}</button> } componentDidMount / componentWillUn
主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され
この週末で機械学習を勉強した結果として、JavaScript エンジニア向けにまとめてみる。 自分が数式見て何もわからん…となったので、できるだけ動いてるコードで説明する。動いてるコードみてから数式見たら、多少気持ちがわかる感じになった。 最初に断っておくが、特にJSを使いたい理由がないなら python で keras 使ったほうがいいと思う。tensorflow.js が生きる部分もあるが、学習段階ではそこまで関係ないため。 追記: 最初 0 < a < 1.0 0 < b < 1.0 で三角関数 Math.sin をとっていて、これだと三角関数の一部の値しか使っておらず、線形に近似できそうな値を吐いていたので、次のように変更して、データも更新した。 // 修正前 const fn = (a, b) => { const n = Math.cos(a) * b + Math.sin(b
世界観をつかめるぐらいには機械学習やっておきたいと思い、とりあえず何かしらのお題がないと興味が続かなさそうなので、二次元の盤面上で何かしらの行動をする、ローグライクのモンスターのエージェントを作るのを目標にしようと思う。自分がゲーム作るとき、大抵エージェントのルール作る段階で飽きてくるので。 今回の記事は、迷路を解くところまで。 学習資料 [Python]強化学習(DQN)を実装しながらKerasに慣れる - Qiita DQNをKerasとTensorFlowとOpenAI Gymで実装する 全力で人工知能に対決を挑んでみた(理論編) - ニコニコ動画 雰囲気を掴むのに、ニコ動の解説動画わかりやすかった。 よく使われてる OpenAI Gym 、見た目は派手だが、環境変数が多すぎていまいち理解の助けにならない + 次元が多すぎて収束が遠いので、すごい単純なゲームルールを自分で作って、それ
React Hooks は Stateless Functional Component でも setState 的な状態操作や componentDidMount のような操作を可能にするための仕様提案です。 既に開発ブランチに入っていますが、 現時点で公式に採用されたものではないです。リリース時にはAPIが変わる可能性があります。 React のメイン開発者の一人である sebmarkbage の出してる RFC https://github.com/reactjs/rfcs/pull/68 試してみる react@16.7.0-alpha.0 に既に実装されており、公式のブログでも解説が出ています。 https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-reference.html 自分は以下
tensorflow.js で遊んでたら keras でモデルを作って import してみましょうみたいな章に差し掛かったので、python の環境構築した。 TensorFlow.js tutorials - import-keras 環境構築 keras ついでに pyre を試してみたいので、 pyre で keras が書ける、というところをゴールにした。 pipenv は ruby の bundler みたいな体験を目指して入れてみた。 ググってみると Mac で Anaconda は地雷みたいな意見が多かったので、とりあえず homebrew から pyenv と pipenv を入れて、pyenv から python を管理することにした。 brew install pyenv brew install pipenv .bash_profile などに環境変数の設定 exp
昨日作った mdbuf が 100000文字を超える場合、遅いときいたので、色々試してみた。 手元で18万のテキストを用意して編集してみた。それなりに重いが、それでもIMEを完全にブロックしてしまうほどでもない。とはいえイライラはする。 innerHTML で挿入にかかる時間を計測してみた結果、自分の手元では markdown 10000文字あたり、1.6ms の遅延。というわけで、体験を損ねない限界は 100000文字辺りが限界だと思う。とはいえ自分は最新モデルのMackbook Pro の中位ぐらいのモデルなので、平均的にはその半分の5万文字ぐらいだろうか。 ただ、画像がある場合には入力の度にリクエストが走ってるような気がするので、それのリサイズも合わさって、あまり良くない気がする。あとでアクセスがキャッシュに閉じてるか確認しておく。 細かい工夫として、IMEの変換中はプレビューの更新
もう人生で何個目かわからない markdown エディタ作った。が、今回のは結構気に入っている。 https://markdown-buffer.netlify.com/ で遊べる。 用途としては、GitHub か Qiita か はてなブログかわからないが、なにか書こうと思ったときに、どのサービスも中途半端に重いので、とりあえずのバッファが必要、という感じで作った。なので速度重視。 ブラウザのストレージで永続化してる。オフラインで動く。できるだけエディタとしてはスコープを大きくせず、単に編集バッファ(textarea)でしかない、というのを意識している。 結構頑張って作り込んでしまった https://nedi.app が色々肥大化してしまっていて入力時にラグを感じるので、編集体験を見つめ直す自戒もある。 機能 数式対応 コードハイライト対応 バックグラウンドで自動保存 改行を br に
おもしろライブラリを見つけて興奮しているので紹介します。 UIスレッド(メインスレッド)からユーザー操作をブロックしてしまうような重い処理を逃がす off-the-main-thread を実践しようとなると、実際に問題になるのは、ほとんどの処理は何らかの形で DOM を参照し、それに連なるものが処理時間の殆どを占めている、ということです。 off-the-main-thread の時代 - mizchi's blog DOM に触れない WebWorker でビジネスロジックを処理するのは、ある種の健全性(Universal/Isomorphic)を手に入れるための「縛りプレイ」として有用ですが、現状は実用上のメリットが殆どありません。 例えば react / redux の reducer で、ビジネスロジックを worker 側に移して処理できるぐらいアイソモーフィックに(DOMに触
ペルソナ5みたいな UI 作りたいみたいな話あって、メニュー画面の動きだけでも作れないか、と主要な動線だけ雑にReactでスケッチしてみたが、早々に限界が訪れた。 理由はいろいろあるが、(無限に気合でやれば終わるが) (そもそもどこにゴールに設定するかおいといて…) 細かいタメを作るのにフレーム単位の制御が必要。現代のHTML5には Flash Studio の代替がないという問題があり、本格的じゃなくていいからそれっぽいやつを作れないかと思って、試作してみた。 動画 ここで試せる https://5bbe44153813f06f1ff69d0c--timeline-editor.netlify.com クリックでアンカーを撃てる アンカーをカーソルキーで値とタイミングを調整できる width のみ easing も linear のみ GitHub のコード (きたない) github.
僕はエンジニアで、このブログで書くことは、そういうテーマを期待されていることを知っている。それ以外はノイズだから、あんまりやらないでほしい、とも。 でもこれは自分のアイデンティティの根幹に関わることで、そういう前提で、一部で話題になってたこの動画を見た。幸福の科学の大川総裁の息子の、幸福の科学との断絶宣言。 www.youtube.com happy-science.jp エンタメの文脈でそれはどうなんだと思うところはあれど、内容自体は非常に思うところがあった。 8歳ぐらいまで、家の宗教に疑問を持つことはなかった。幼稚園までは、人に隠れて食前の祈りを捧げていたと思う。それが褒められると知っていたから。 ティーンエージャーの頃、自分は怒りに支配されていた。自分の家の異常さを客観視できるようになり、その異常さを許せなくなった。自派以外を否定する排他的な教義、一時期採用された一夫多妻、そしてその
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty
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』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く