BEMで底に達した問題を探す問題のために生まれる問題 - saneyuki_s log
最近、社内のいろんなプロジェクトのリポジトリを眺めているとスタイルシートの記述にstyled-componentsとかwebpackのcss-loaderとかで頑張っているものを頻繁に目にする。 んで、Lintとかどうしてるの？みたいな話をすると「〜はこの『A（どこかのCSS-in-JS派閥の一つ）』は対応してないんだよねー」という返答が返ってくる。 そのたびに思う。「BEMで問題解決してたんだからBEMでいいじゃん」と。 このようなことを言うと「JVMのJITコンパイラの仕組みを聞いた後に『アセンブラを生で書けばいいじゃん』と言い出す痛いおじさん」感がするので自分でもあんまり好きじゃない。ただ、CSSに関してはBEMで問題が底に達してしまっていて、そこから先の標準化されてないwebdevツール群は問題を再発明しているだけに過ぎないなと思う。 書き味をどう頑張ろうが結局我々はCascadi
銀の弾丸は川から流れて来ない - saneyuki_s log
The Evolution of Flux Frameworks — Mediumを読んだ。自分がここ3ヶ月～半年くらい考えてたことと殆ど一緒で、若干の安心感を得たり。実装論の話も概ね同意ではあるのだけれど、自分は必ずしも同意しかねる面がある。 今のメモリマネージド言語のトレンド、特にクライアントアプリケーションの存在を想定したアーキテクチャは、C#が筋道を立てた実践理論に追随してる面があるので、過程はどうあれ、彼らの先端スタイルに近づいていくことになると思うのよね。 Fluxパターンの話をすると、あれが偉かったのは「疎結合すると色々楽になるから、オブザーバーパターンにして、コマンドパターン使って、コマンドは単方向にすると破綻しにくい割に弄りやすいよ」ってのを、フレームワーク症候群に陥っていた凡百なWebクライアントサイドに、一発、投げつけた辺り（というのは半年くらい前に書いたな……）。
makeのくびき - saneyuki_s log
「gulpって何だよ、makeでいいじゃん（要約」論争について、私もちょっと一本講釈をぶってみることにする。あれやこれやといった実利的な話をするつもりはない。そういうものは既に書いた人がいるのでそちらを参照のこと。 Gruntの思い出 Gruntは、私の印象で言えば車輪の再発明の失敗作のようなもので、タスク間の依存関係が破滅への一途をたどり管理不能に至るなど、宣言型の負の側面が強く出てしまった。しかし、設定は本当にサンプルコードのコピペだけで組み立てられるので、JSが不得手なデザイナーなどには非常に受けが良かったという点は忘れてはならない。ちょうど、html5ブームが本格化して, Apache Antとかに慣れ親しんだJava（主にSIer）系の人が入ってきたタイミングにあった道具かつ、Yeomanファミリーにも組み込まれており、それでいて簡単な事をやらせるには悪くはない具合のシンプルさ、
EdgeHTMLを悼む - saneyuki_s log
久々に色々書きたい気持ちになった + 矢倉さんの書かれたものを見て、彼とは微妙に考えることは違うかなあと思ったので書くだけ書いてみる。意見似てるなと思ってるところは書かないようにはした（標準化方面周りとか）。あと、Webブラウザ周りの現状に明るくない同僚や友人向けのテイストは含んでいる。 そもそもの大前提 まず、Webという文書・アプリケーションプラットフォームの価値は「標準仕様に基づく相互運用性」「インストールせずとも使える」の二点に集約されると自分は思っている。 最近はずいぶん聞かなくなった「Webは簡単に作りやすい」というメリットは、「Win32のデスクトップアプリに比べると」という但し書き付きで、90年代は事実だったと思うけど.NET Frameworkの進化とかモバイルOSアプリが出たりとか業界の成熟に伴って事実ではなくなって久しいと思う。 この「標準仕様に基づく相互運用性」とい
Fluxとはなんだったのか + misc at 2014 - saneyuki_s log
はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン
見つけた便利MV**ライブラリを紹介するときにjQueryをスケープゴートにするのをいい加減に止めろ - saneyuki_s log
オレオレMV**フレームワークを紹介する際にjQueryを引合いに出して語る事案が多く、そこで語られるjQuery批判が的外れもいいところなのが散見されるので書きました。 Abstract MV**便利フレームワーク・ライブラリを紹介するときに、jQueryの一番イケてない書き方を引き合いに出して比較して「こんなにすごいんです」と紹介するのは不毛極まりないのでいい加減に止めろ jQueryで書いたコードがひどいのは、クライアントサイドWeb（あえてこう書く）が過去10年近くにわたって設計を軽視してきた結果であり、その根本が変わらない限り、問題は変わらない jQueryエンジニアをdisりながら、Angularエンジニアを産み出すとかギャグじゃないの？ 私個人のjQueryに対する見解 だいたい同意する意見： jQueryについての私見 - mizchi's blog mizchi / いか
システムプログラミング言語 - saneyuki_s log
第7回くらいのServo Readingで話したことをざっくりまとめた。誰がどれを話したかはmangleしてあるので御容赦を。 個人的にざっくりとTwitterなどなどをクロールして得た感想だけど、GoはCompiled Pythonともいうべき立ち位置な気がする。PythonとかPerlとかRubyとかシェルスクリプトとか以上C未満な箇所を、JavaやScalaよりももっとスマートに置き換える、そういう意味での「システム」開発言語。 対する？Rustは、カーネルとかブラウザエンジンとかゲームエンジンとか、ハードウェアに近いエリアの計算機資源をがしがしと叩きまくるための言語。C/C++の面倒くさい因習やエクストリームな部分をうまく隠蔽しつつ、時々必要になったらunsafeブロックで例外的に許容する。その安全性の担保として、コンパイラを使った静的チェックをCPUとメモリにものを言わせてブイブ
JS界隈にIDLもしくはd.tsを併記・同梱する文化が根付いてほしい - saneyuki_s log
前置き 最近、ウェッブフロントエンドエンジニアらしく各種JavaScriptのライブラリを眺めて、調査・選定しているのだけれども、その過程を通じたこととして、多くのライブラリが、ドキュメントのAPIの説明が貧弱すぎる。 jQueryのドキュメントが腐っているというのは既に広く知られた事実であると思うし、そうでないならば積極的に既知の事実として腐っている事を広めて行くべきであると強く思うが、jQueryに限らずとも、ドキュメントが満足な形で整理されていないのをひしひしと感じる。 この手のものでよくドキュメント化されている部類だと感じるBackbone.jsですら、仮引数の名称と定義のみしか書かれておらず、肝心の引数が備えるべきメンバや、引数の型情報が明示的に記述されていない。そのため、APIを俯瞰し、自分の欲しい情報がどこに詰まっているのか・どのように取得できるのか・DOM標準もしくはECM
ES6の前にES5のベストプラクティスを改めて考えたい - saneyuki_s log
歴史認識 だいたい以下のような流れだと認識している。 IE8以前を含むECMAScript 3暗黒時代があった この時代をベースにベストプラクティスが構築 + HTML5ブームが発生した 暗黒時代なんで結構つらいし、IE9じゃないとECMAScript 5使えないし、結局辛い CoffeeScriptを筆頭としたaltJS一派に救いを求めた（結局Coffeeは一過性のカフェインだったわけだけど） 気がついたらECMAScript 6が来そうになっていた ES6でのsyntaxの拡張・標準ライブラリの増強はカッコいい 気がついたらES5当たり前、ES6も使えそうな世界が来そうになっていた（希望的観測が多分に含まれているのは暗黙の了解と化している） ES6、altJSの次のナウい世界として注目を集める だいたいこんな感じで、ECMAScript 5を用いたベストプラクティス的な物が存在しない、
Promiseはコールバックに対する聖杯ではない - saneyuki_s log
ES6ならびにDOM4にPromiseが投入されることとなり、すっかりJavaScriptでよく陥るコールバック地獄に対する至高の解決策のように扱われているPromiseだが、万能の解・聖杯ではない。 たぶん誰かが既に似たようなこと書いてると思うけど、とりあえず自分の思考の整理に書く。 Promiseといえば以下のようにコールバックによるコードの無限ネストを解決するものとして扱われることが多い。 var p = new Promise(); p.then(function () { ... }).then(function () { ... }) だが、これはコールバックをPromiseというラッパーを用いてネストしない形に変換しただけに他ならず、Promiseの利点ではない。適当なラッパー関数を作って解決しているのと大差はない。 本質的にはPromiseとは将来的などこかの時点になれば値
プライベートブラウジング時に「最近閉じたタブを復元する」機能が無いのはダメ - saneyuki_s log
昨日のNightly 29でプライベートウィンドウで"Undo close tab"が使えなくなってるなーと思ったら、bug 956826 が原因っぽい。というわけでコメントしたんだけど、備忘録代わりに日本語でも書こうかなと。Twitterだとかなり文章長くなるし。 この挙動の変更について、「そうは言ってもChromiumはやってないしなあ」とあるけど、ここについてはChromiumが明らかに間違っている（というよりも、オプション画面やタブの挙動など、1.0未満のベータ時代に骨子が決まったと思われるChromiumの挙動は全体的にコンセプトワークであって、ほかのソフトウェアが安易に従うには筋が悪い、参考にするには警戒すべき）。 人間が間違えてタブを閉じてしまった場合に復元する手段が無いのは、undoの無いテキストエディタのようなもので、基本的にはコンピュータのソフトウェアとしてゴミだ。まし
Rustの並列タスクモデルのメモ - saneyuki_s log
「メモリ安全性と並列実行性に注目した言語」と語られる割に、メモリ安全性はともかく、どのようにRustの並列実行モデルが成り立っているのかについて語られる事が殆どない気がしたので、Rust Tasks and Communication Tutorial を大雑把ながら読み解いていくことで、Rust 0.7での並列モデルを探っていきたいと思います。 尚、サンプルコードはチュートリアルのものを元に一部改変を加えて使用してます Rustにおける並列実行モデル 実行されるRustプログラムは、それぞれがスタックと独自に所有権を持つヒープが割り振られた、タスクツリーによって構成される Rustにおける並列実行モデルは、軽量かつメモリ独立したタスクと、それらの相互のメッセージ通信によって成り立っている。 Rustにおけるタスクはスレッドではない。細かく分割されたタスクを、Rustの内部スケジューラによ
Web ブラウザは Web に対する GUI シェルである - saneyuki_s log
2年くらい前から個人的に色んな場で話しているんだけど、現状のWebブラウザには「HTML5 で導入された API 群に対して、ブラウザ側が適切なUIを提供できていない」という問題点がある。 これについて分かりやすい例を挙げると、cookieの管理ビューはあるのにDOM storage の管理ビューが無いこととか（この2年間でChromium先生は実装したけど）。 よくよく考えてみれば、だいたいのブラウザには現在保存している cookie をユーザーが閲覧するための機能があるのに、DOM storage や IndexedDB に何が保存されているのか、そもそもどこのドメインによって保存されているのかすらわからないというのは奇妙な話なんだ。何故なら、どれもユーザーのプライバシーに関連する情報の保存用途に使われるからだ。最近はトラッキングに関連する話題としてトラッキング cookie がやり玉
Mozilla 勉強会＠東京 8thで話しました - saneyuki_s log
そこの君、 バグ報告から始める Mozillaへのcontributeのやり方 教えてあげるからちょっと来なさい from saneyuki snyk さる12月1日に、Mozilla 勉強会＠東京 8thでお話しさせて頂きました。発表の内容でお聞き苦しい点がありましたら申し訳ありませんでした。 今回は「Mozillaへのバグ報告とバグの修正ステップを通じて、contributeへの間口を広げる」というテーマを設定しました。単にcontributeへの間口を広げるだけであれば、バグ報告のパートは要らないのですが、あえて追加した理由としては、この機会を通じて、バグ・不具合報告のやり方のたたき台のようなものを作成しておきたかったからです。 ユーザーとしてアドオンを使ったりFirefox自体を使ったりする上で、不具合報告をする機会はそれなりにありますが、「具体的にどのように不具合報告をすれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluxアーキテクチャの覚え書きを書いた - saneyuki_s log