サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
saneyukis.hatenablog.com
たまたまoption-tを紹介してくれるブログ記事があったみたいで、その上でneverthrowの方がおすすめみたいな感じのtweetを見かけて、色々言いたいことがあったので久々に書いてみる。 https://t.co/GJGyxeyoZM fp-ts を入れるのを躊躇う環境で Result 型とコンビネータが欲しい場合の私のおすすめは neverthrow です— naoya (@naoya_ito) 2023年1月19日 ・ResultAsync という async に対応している ・fromPromise / fromThrowable を使えば Result の入れ子が嫌なときに async/await や例外を使った普通の手続きで書いて、fromPromise/Throwable で包むという回避手段が取れる— naoya (@naoya_ito) 2023年1月19日 ・Res
Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき?」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数(入力) context = グローバル変数(モジュールグローバルな変数) 実装の指針
今の職場で既に組まれたシステムが既にstyled-componentsにべったり依存していて、別に積極的に入れ替える理由もないので普通に使っているけれども、やっぱりこれ微妙だなと思った話。 そもそもとして、ビルドシステムへの介入が多くて不必要にロックインになったり、提示されてる手法がだいたいイマイチで普通にCSSとかSCSSを書く以上の意義が見出せないので、僕は基本的に「JS中にCSSを書いたり、ES Moduleのimportを使ってCSSを読み込むタイプのアプローチ(以下CSS-in-JS)」がそんなに好きではない・大人しくCSS書く方が好きではあるんだけど。色々あった理由はこちら: https://saneyukis.hatenablog.com/entry/2019/02/28/022750 https://saneyukis.hatenablog.com/entry/2019/0
「〜がChromiumベースに!」なことが起こるたびに「Chromium/BlinkはWebKitを源流とするエンジンでしかじか」みたいな話が出てきて、「実質WebKitだから同じだね」という反応が出てくるのが恒例行事っぽくなってるけど、結構モニョモニョする。 先祖が同じなら子孫も同じ、ってそんな単純な話じゃない。 fork前、BlinkがChromium WebKitというかWebKit Chromium portと呼ばれていた頃でさえ、Chromium portとApple portの2つが同じエンジンと呼べる箇所って、layoutとかdomとかstyleとかブラウザエンジンのコア部分だけで、他はV8とJSCとか、SkiaとCore Graphicsとか、そもそもプロセス分けてる方法も違うし、呉越同舟というか寄り合い所帯感だった。composition周りだってApple portはC
JSConf 2019で Your benchmark may not guide real application performance という話をしてきました。 寒い中お越しいただいた皆様。ありがとうございました。 話さなかったこと 「そうは言ってもベンチマークを組み込むのつらいよね」な話 自分の体験談、身の回りの同僚知人各位の体験談も合わせていくとそれだけの一本のコンテンツにできますが、今回は単純にスコープ外かつ30分に収まらないので諦めました。私の力量の問題もあります 後からベンチマーク足そうと思うと本当に大変。まあ最初からやっても大変だとは思うけども、ゼロからやる方が"ちょっとだけ"簡単だと思う。 詰まるところカルチャーの問題なので、うまくチームや会社を巻き込まないといけない。「ソフトウェアパフォーマンスは究極的には組織文化である(要約)」というJoe Duffyの主張はとても
BEMでいいじゃん話の続きその2にして, 具体的な解決編. 多分ここが気になる人が多いと思うのでなるべく箇条書きで済ませることにする. 背景 前回書いてた内容をまとめると以下のようになる. 無駄話が多いので前回は読まなくてもいいです. 追記: 前回読んでもらった方がいい気がしてきた. 時間が無い方はいったん飛ばしてくれて構わないのは変わらず. 状況 サービスの初期からwebpackのcss-loader(を用いたcss-modules)を使用していた これは(個人的には好きではないが)そこまでの問題ではなかった stylelintなどの各種のLint機構がそのまま使える上, CSSとUIコンポーネントのコードは分離できていた サービス開始時の鉄火場の中で, cascadingに基づく暗黙的なスタイルの継承を用いて, UI component treeにおいて祖先側が子孫側のスタイルを上書き
BEMでいいじゃん話の続きその1にして, とあるアプリケーションが困っていた話. 書き味は最良ではないけれど, 設計思想を持った上で長期メンテを考えると結構いい感じだと思っているアプローチに至った. しかしながら, 放っておくと誰も試行錯誤の過程を書かないままになってしまいそうだし, それを書きそうな同僚も(多忙のあまり)書きそうな雰囲気はなさそうだし, もしかすると永遠に出てこない気さえするので書いてみる. 多分完遂の暁にはどこかで話として総括が出てくると思うけど, 中間報告ということで. 経緯 とあるアプリケーションは, 元々はCSS Moduleをcssのビルドシステムに用いてAtomic Designとして作っていた. CSS Moduleを選定した理由は自分はよく知らないが, ものの試しで使ってみようと思ったんだと思う. ここまでは別に間違ってはいない. (自分は選ばないが)st
先週、Twitterでまるっきり別のクラスタの知人が全く別個の「Open Source Softwareのコードは綺麗。業務のコードは汚いが動くコード」みたいな誰かのtweetをRTしていてちょっとそれ違うよなーと思った次第。 Open Source Softwareのコードが綺麗かどうかというのは非常に大雑把かつ間違った先入観で、 仮にそう思っているのであれば、それはその人がロクでもないコードや大雑把な単位のコミットを普段から見すぎているか、 運よくめちゃくちゃコードの出来がいいプロジェクトのコードを読んでいるだけだと思った方がいい。 Open Source Softwareのコードが綺麗になるとするならば、 コードを公開する側にとっては綺麗なコードを公開したいという気持ちが生まれ、せめて見せかけだけでもと頑張っている(恥の概念) 綺麗なコードを書けるプログラマーが参加している・集まって
最近、社内のいろんなプロジェクトのリポジトリを眺めているとスタイルシートの記述にstyled-componentsとかwebpackのcss-loaderとかで頑張っているものを頻繁に目にする。 んで、Lintとかどうしてるの?みたいな話をすると「〜はこの『A(どこかのCSS-in-JS派閥の一つ)』は対応してないんだよねー」という返答が返ってくる。 そのたびに思う。「BEMで問題解決してたんだからBEMでいいじゃん」と。 このようなことを言うと「JVMのJITコンパイラの仕組みを聞いた後に『アセンブラを生で書けばいいじゃん』と言い出す痛いおじさん」感がするので自分でもあんまり好きじゃない。ただ、CSSに関してはBEMで問題が底に達してしまっていて、そこから先の標準化されてないwebdevツール群は問題を再発明しているだけに過ぎないなと思う。 書き味をどう頑張ろうが結局我々はCascadi
久々に色々書きたい気持ちになった + 矢倉さんの書かれたものを見て、彼とは微妙に考えることは違うかなあと思ったので書くだけ書いてみる。意見似てるなと思ってるところは書かないようにはした(標準化方面周りとか)。あと、Webブラウザ周りの現状に明るくない同僚や友人向けのテイストは含んでいる。 そもそもの大前提 まず、Webという文書・アプリケーションプラットフォームの価値は「標準仕様に基づく相互運用性」「インストールせずとも使える」の二点に集約されると自分は思っている。 最近はずいぶん聞かなくなった「Webは簡単に作りやすい」というメリットは、「Win32のデスクトップアプリに比べると」という但し書き付きで、90年代は事実だったと思うけど.NET Frameworkの進化とかモバイルOSアプリが出たりとか業界の成熟に伴って事実ではなくなって久しいと思う。 この「標準仕様に基づく相互運用性」とい
超速! Webページ速度改善ガイドを読んだ。 超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus) 作者: 佐藤歩,泉水翔吾出版社/メーカー: 技術評論社発売日: 2017/11/23メディア: 単行本(ソフトカバー)この商品を含むブログ (1件) を見る 普段あまりこういう本は買わないのだけれども、友人達が書いていたので購入してみた。特に献本などもないのでどうでもいいかと思ってたんだけど、あとで印税貢献分としてコーヒー一杯奢れと著者両人にたかるネタとして良さそうなので買いました。 内容はGoogleの出しているWeb Fundamentalsのうち、パフォーマンスに関連するセクションを捕捉・再構成したような感じ。 巷では玄人向けという評価もあるけれど、それは本のターゲットの説明として大雑把にすぎると思う。 一読者たる私の感じたタ
こんなの探せば10年とか20年前にも似た議論があって結論出てそうだし、ドメイン駆動設計系の人が実践論として言ってそうなものだけど。 アプリケーションフレームワークとかボイラープレートみたいなものをいくつか眺めていると、/Controller/SignIn/SignControllerみたいなディレクトリの組み方を薦めてるものが結構あるけれど、これは素直じゃないなと思った。 だいたいこんな階層になるやつ。 / Action/ Signin/ Report/ Editor/ View/ Signin/ Report/ Editor/ Repository/ Signin/ Report/ Editor/ UseCase/ Signin/ Report/ Editor/ 何が素直ではないと思ったかというと、 具体的な問題領域よりも先に教条主義的なコードの役割分担が優先されている 問題領域に応じて
Rustを書いていると、慣れるまではrustcに頻繁に怒られる。慣れても結構怒られる。とにかくrustcに怒られる。きっと貴方はこう思うだろう、「Rustはなんて煩い言語なんだ!俺の愛する****(好きな言語の名前を入れてください)ならばこんなことはないのに!」 このように「rustcが煩くて俺のコードが通らない」場合、とりあえず自分のコードが間違っていると疑って問題はない。え、「俺のコードは正しい」? 違う違う、コードのロジックの話じゃない。「そのコードがRust wayではない」という点で「間違っている」。microなスタイルからmacroな設計まで、ありとあらゆる点でRust的なコードであることを暗黙的ではあるが極めて強く要求する。それがRustというプログラミング言語だ。時たまrustcが間違っていることもあるんだけど、体感値として97%はrustcの方が正しいと言っていい。 なぜ
cargo:bindgenのupstreamがYamakaky/rust-bindgenからservo/rust-bindgenに変わった。変わった結果どうなったかというと、C++のヘッダのパース機能が大幅に改善したりする。 rust-bindgenを知らなかった人に簡単に解説しておくと、clangを使ってC/C++のヘッダをパースして、それを元にRustのC FFI binding用途のglue codeを生成するcrateのこと。 元々rust-bindgenはRust ProjectではなくJyun-Yan Youが始めたらしい。らしいというのは「git logを辿った限りだとそうなっている」以上のことを言えないから。その後、メンテナー間での移譲があったのかどうかはよくわからないが、2015年末の時点ではYamakaky/rust-bindgenがupstreamとなっていた記憶があ
前提 yarnpkgのv0.17系 依存パッケージのガーデニングという単語の意味についてはググれ How to yarn outdatedとかで更新が必要そうなものを眺める いきなり2へすっ飛んでもいい バージョンをstableとかdevとかnextで指定している場合は出てきたり出てこなかったりするけど yarn upgrade-interactiveする バージョンをstableとかdevとかnextで指定している場合は出てきたり出てこなかったりするけど 2を繰り返す yarn upgradeで, 表に出てこない依存関係含めてyarn.lockを更新する 今のところ, ./node_modules/を消して, yarn.lockを消して, yarn installしてyarn.lockを再生成した場合と同じ効果が得られる
東京Node学園#20で「Don't use try-catch」というタイトルで話してきました。 option-tの話 最初は手前味噌なoption-tの話を主題にするつもりではあったんですが、そんなライブラリの話とかしたって特にトリッキーな実装をしているわけでなし、全然面白くないし、別に特定のライブラリを使わなくても実現できる内容なので、もう少し広めの話題ということでtry-catchを安易に使うのをやめようという話にしました。 宣伝がてらoption-tの話も入れていますが、option-tのREADME.mdにも書いている通り、これのみが正解というわけでもないし、TypeScriptなどの静的型付けな支援が無いと使いにくいこともままあるし、依存関係を増やす元になるので、無理して使う必要も無いでしょう。インスタンスメソッドを組み合わせて使うとか、そういったことに魅力感じる場合に、選択
これは何? ECMA262 6th以降にはiteration protocols(と呼ぶべきもの)が導入されている、というのは皆さんもちろんご存知のとおりだと思います。これを使ってIterator<T>.next()が呼ばれるまでmap()などを実行しない(lazy evaluationする)Iteratorを作ってみようという話です。Rustのstd::iter::IteratorとかC#のLINQとかが似たような挙動をしますよね。 今後、巨大なオブジェクトやリストに対してのIteratorが提供・出現した場合、毎回のように即時評価でfor-ofしたりArray.from()するなどは現実的ではないでしょう。以下のように書くことも出来ますが、 /** * @template T, U * @param {Iterable<T>} src * @param {function(T):U}
8月末に書いたメモ書き どこに書いたか忘れそうなんで貼っておく
Rx.Scheduler RxにはSchedulerと呼ばれる主要概念がある. 値がpushで飛んでくるというRxのインパクトの後ろに隠れがちなSchedulerではあるが, これにより, 処理系のスレッドモデル(並行性)と時間軸にまつわるタイミングの制御を統一的に扱えるようにしている. 後続へのoperatorへの値の送出タイミングの制御, Observableの処理スレッドの指定, タイマーのモックへの差し替えなどがSchedulerによって実現されている. さてJavaScriptの場合, 原則的には単一スレッドの世界になる. Javaや.NETの場合とは違い, RxのSchdulerの役割は回り続けるイベントループ抽象となる. 永久に回り続けるイベントループの中で, どの時点で処理をdispatachするかがSchedulerの役目だ. JavaScriptの世界にはメモリ空間を共
This is the summary overview of karen-irc's client-side architecture. The history of my thought are wrote in the issue. I may talk about more details in somewhere. And I deployed the simplified design of this to my main work code. Perhaps I or my co-worker may write about it in someplace. CAUTION: karen-irc's code is refactoring still now, so there are some legacy part Basic Principle I wrote the
2015年を通して、Rxに関して色々調べてみた結果、(国内の)コミュニティごとに受容の温度感がだいぶ違ったので、ちょっとおもしろかった。 .NET(C#)界隈 2009年くらいからRxに付き合ってるだけあって、なんというか熱狂期を過ぎた感じ。冷静に受け止めて粛々と使う人は使うという印象。LINQがあり、LINQ to Eventsという売り文句でコミュニティに向けて発信されたのもあってか、リアクティブとかFRPとか、そういう単語で盛大に踊った痕跡もあんまり残ってない。Channel9とかinfoQとかにアップロードされてるBart de Smetの解説動画とかも、思想の源流としてリアクティブの話はしつつも、IEnumerableとのdualityを話す。 Android界隈 リアクティブという言葉のマジックを第一印象として大切にしつつも、Promise/Future相当の統合兵器として、粛
しばし見かけるReactive Extensions(ReactiveX, Rx)に関する説明の多くはファンクショナルだのリアクティブだのモナドといったキャッチーなフレーズを使っている。けれども、そういう方面に馴染みのない人を相手にして、そもそもの概念的に何を解決したかったものなのかという説明があんまりない気がした。ユースケースを伴った説明も局所解すぎて現実における使い道がわかりにくい、というか誰も彼もデータバインディングしか例に出さないのはどうなんだ。これはストリームの川?それは表現形態であって実態を表しているとは言い難いだろう。 放置していても誰も書かない気がするし、神秘的な霊験と共に語られても全く役に立たないし、自分の思考の整理と(幾らかは同僚への説明も兼ねて)書いてみることにする。 もしかすると.NET界隈あたりでは過去にやりつくしたネタの再生産かもしれないし、ラジオなどの非文章媒
http://www.slideshare.net/saneyuki/my-thoughy-about-beyond-flux (主にGUIの)アプリケーション設計的なものをぼんやりと考えていた時に、色々思いついたことを書いた。特にどこかで発表するという予定もないんだけど、作ったからには手元でタンスの肥やしにするのも勿体無いので貼っておく。「まあ、そうだよね」とかそういう感じでしかないし、何か真新しい内容があるわけではない。 結構散漫な話なので上には書かなかったんだけれども、ソフトウェア開発において人はよくベストプラクティスを求める傾向にあるけれども、現実には「悪くはない」程度の解を選んだり、バッドプラクティスやアンチパターンを避ける方が総じて上手くいくように感じている。理想形を探り求め続ける限りに天井は無いが、「良くも無いが、最悪に面倒臭いことは回避している」であれば下限が決まっているの
少し前にTypeScriptと素のECMAScriptとfb::JSXを混ぜてcompile -> linkする記事を勤務先のブログに書いたのだけれども、それ以後に色々思った小話を一席。 先述のエントリで示した構成を趣味プロジェクト含めて2~3度試した結果、現代のJavaScriptは書き捨て的なスクリプトから、(漸進的な)静的型付けまで、言語機能的なところではソフトウェアの規模に応じて、自由にスケールアップできるという実感を得るに至った、という確信を得た。インクリメンタルに移行できるので新旧コードの混在もできるし、素のJSじゃないとできないものは、それにやらせればいい。これはTypeScriptなりbabelといったcompilerやAST操作ツール群の成熟と、npmエコシステム、ES6というベースラインの更新が絡み合っている。 こうしてコードベースの規模に応じて自由にあれこれできるのは
生きているソフトウェアに付き物の破壊的変更(breaking change)であるが、一口に破壊的変更と言っても、実際は複数の意味を包含している。 なお、「生きているソフトウェア」では主語が大きすぎるので、ライブラリであったりランタイムについての話とする。 一般的に破壊的変更という場合、以下のどちらかとなるだろう。 セマンティクス・挙動の変更を伴う変更 セマンティクスの変更を伴わないが破壊的とみなされる変更 APIの名前が単純置換された 1は明らかに破壊的である。ソフトウェアに対して少なからぬ書き直しが発生するし、単純置換では済まないケースの方が多い。 そもそもの設計思想やアプローチに修正が加えられたので、前と後とでは違うものと言っても過言ではなく、十分に破壊的と呼ぶに足りえる。 しかし、2のケースは一概に破壊的と言えるかは怪しい。辞書的には破壊的だが、我々の思い浮かべる大規模な書き直しを
Rx.js, Immutable.js について - mizchi's blog ファイルサイズへの異論は無い。これを使わずとも解決できる問題があるというのも同意する。それでもイマイチ釈然としない。「使う必要のない」一般公理と「使いたくはない」私情の境界が曖昧に感じてしまう。仕方がないので反論を兼ねた個人の雑感を書いてみる。いわゆる、「ついカッとなってやった」に近い。 RxにせよImmutableJSにせよ、この手の標準データ構造を提供するライブラリは基盤性が強いので、全体的使うことでバイナリサイズに見合っただけの成果をもたらす系のライブラリに区分される。そのため、局所的に使いたい場合はあまり意味がない。この辺りはReactと類似してる面がある。 使うなら上から下まで、 あるいはオニオンアーキテクチャ的な例えで言うならある階層から外側のインターフェースを統一するようにしないと、さして美味し
The Evolution of Flux Frameworks — Mediumを読んだ。自分がここ3ヶ月~半年くらい考えてたことと殆ど一緒で、若干の安心感を得たり。実装論の話も概ね同意ではあるのだけれど、自分は必ずしも同意しかねる面がある。 今のメモリマネージド言語のトレンド、特にクライアントアプリケーションの存在を想定したアーキテクチャは、C#が筋道を立てた実践理論に追随してる面があるので、過程はどうあれ、彼らの先端スタイルに近づいていくことになると思うのよね。 Fluxパターンの話をすると、あれが偉かったのは「疎結合すると色々楽になるから、オブザーバーパターンにして、コマンドパターン使って、コマンドは単方向にすると破綻しにくい割に弄りやすいよ」ってのを、フレームワーク症候群に陥っていた凡百なWebクライアントサイドに、一発、投げつけた辺り(というのは半年くらい前に書いたな……)。
Reactive Extensions JS port(RxJS)をもくもくしていた結果、C#界隈がReactive Propertyを作り出した理由が(なんとなく)わかってきた。 Rxの流儀にのっとれば、ある値を使おうとする場合、その値を生成するObservableの結果を受けて、そのObservableも同様に……とObservableの依存関係を作っていく必要がある。 Rx.Observable.do()メソッド中に、関数外のグローバル変数などを副作用なmutateをさせてもいいが、これは基本的によろしくない。Rxで実行される各Observerが、一体どのタイミングが動作するかの順序保証が本来的には存在しないためだ。イベントループがひとつしかない & Workerは完全にメモリ空間が分割されたアクターライク & Rx.SchedulerもDOMのイベントループ原則に則るJavaScr
「gulpって何だよ、makeでいいじゃん(要約」論争について、私もちょっと一本講釈をぶってみることにする。あれやこれやといった実利的な話をするつもりはない。そういうものは既に書いた人がいるのでそちらを参照のこと。 Gruntの思い出 Gruntは、私の印象で言えば車輪の再発明の失敗作のようなもので、タスク間の依存関係が破滅への一途をたどり管理不能に至るなど、宣言型の負の側面が強く出てしまった。しかし、設定は本当にサンプルコードのコピペだけで組み立てられるので、JSが不得手なデザイナーなどには非常に受けが良かったという点は忘れてはならない。ちょうど、html5ブームが本格化して, Apache Antとかに慣れ親しんだJava(主にSIer)系の人が入ってきたタイミングにあった道具かつ、Yeomanファミリーにも組み込まれており、それでいて簡単な事をやらせるには悪くはない具合のシンプルさ、
次のページ
このページを最初にブックマークしてみませんか?
『saneyuki_s log』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く