祝: Atom の Web Components 導入、ついでに Atom Shell の話。 - steps to phantasien
GitHub 謹製 Atom エディタが Shadow DOM を使い始めたという。 めでたい。せっかくだから私も Atom を使ってみよう。 起動してテキスト書きもそこそこにインスペクタで DOM を眺める。 するとあら素敵。Shadow DOM のみならず Custom Elements もばりばり使われているじゃありませんか。 ためしにステータスバーをつついてみるとわかる。 Atom は UI を React に書き直したものと思いこんでいたけれど、 React になったのはテキスト編集領域だけの様子。周辺の UI は Custom Elements ベースになりつつあるらしい。 もともと space-pen という jQuery ベースの内製フレームワークで書いていたものを、 徐々に Custom Elements 化していくという。 Atom, 意外と Web Component
Reactive Porn - steps to phantasien
Rebuild.fm に出させてもらいました。ありがたいことです。 さっそく録音を聞き直す。自分の声を聞くのは辛い・・・のはさておき、 リアクティブプログラミングの話は我ながら主張がよくわからない。 反省のため何が言いたかったのかを考え直したい。 たぶん趣旨は二つあった: A. RxJava や RxAndroid はなかなかいいやつだ。 B. リアクティブプログラミングは一つのはっきりした概念ではない。 A については試してもらえばわかるはず。ReactiveX のサイトからぽつぽつ資料を読めば済む。ここでは B を補足してみる。 X 指向は Y みたいなもの リアクティブプログラミングとは何だろう。どうもつかみどころがない。私は腑に落ちるまでけっこう時間がかかった。 このわかりにくさには大きく二つ理由があると思う。一つはプログラミングの概念をコードなしに説明する一般的な難しさ。オブジェ
リアルな DOM はなぜ遅いのか - steps to phantasien
これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 「React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ」 もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ
Life of Touch - steps to phantasien
いいかげんあんどろでも勉強するかと 6 年遅れくらいで重い腰を上げかけている。気が重い。スマホとか知らないっすよ・・・。 あんどろ、というかスマホ固有の話題は色々あれど、その一つがタッチベースの UI なのは間違いない。そういえばタッチというのはどうやって実装されているんだろうか。それを一通り眺めれば、少しは気の重さが晴れるかもしれない。ということで今日はタッチイベントの実装を眺めてみたい。実装といっても静電容量だの電磁誘導だのではなくユーザー空間の話です。そして老人の勉強記録であり目新しい話はありません。間違ってたら教えてください。 参照するコードは何も考えず repo sync で降ってくる AOSP master。たぶんだいたい 4.4.x 相当(だよね？) View#onTouchEvent() あんどろプログラマからみたタッチイベントはふつう View#onTouchEvent(
にわか TOEIC マニア - steps to phantasien
社内で開かれたワークショップ形式の研修に参加したのは一年前、ちょうど今頃のこと。 それはたぶんチームワークのような何かを学ぶ会だったはずだけど、 私の感想は本題と関係なく「いいかげん真面目に英語を勉強しないとあかん」だった。 話が通じないとチームワークどころじゃない。 米国資本勤めの会社員からすると、英語はグローバル云々以前に仕事用 DSL みたいなもの。 英語ができないまま騙し騙し働くのはたぶん、 SQL が書けなからと ORM の上だけでコードを書こうとするのに似ている。できなくはないけど、いろいろしんどい。 幸い私は Web 開発者じゃないから SQL はわからなくていい。でも英語はやらないとダメっぽい。 入社二年半、ようやく現実を直視した。 最初はしゃべる練習をしようかと思ったけれど、そもそもしゃべる以外の英語すらできるといえるのか。怪しい。 むしろまず典型的日本人として英語ができ
Polymer と Web Components - steps to phantasien
先週はサンフランシスコで勤務先の年次博覧会が催され、中には自分と近いプロジェクトを紹介するセッションもあった。 いい機会なので便乗して宣伝してみたい。自主会社員活動につき勤務先の見解と違っても見逃してください。 さて件の年次博覧会、ウェブ開発者向けの講演の一つで Polymer という新しい JavaScript UI フレームワークが公開された。 Closure, GWT, Angular ときて また別のフレームワークかよ…とぼやく人の気持ちもわかる。でもそれほど被るものでもないから見逃してほしい。 なるべく多くのブラウザで動かそうとする既存のフレームワークと違い、 Polymer は新しいブラウザの機能を使い倒すことで強力なフレームワークを作ろうとしている。 別に特定ブラウザでしか動かないわけじゃない。ただ将来そうした新しい機能が各種ブラウザに備わる日を見越し、 そのときベストに動く
Gisted: Ideas Worth Pasting - steps to phantasien
TED の動画はまあまあ面白いのでときどき暇つぶしに見るのだけれど, 動画ではなく音だけ (mp3) で聴きたいことがある. 動画ばかりは疲れる. あとあんどろ機器や iPod に入れて持ち出すのも音声がいい. 動画だとサイズが大きい上にバッテリーの減りも速いからね. 幸い TED は多くの動画にダウンロード用の mp3 を用意してくれている. あとは transcript (原稿) があればいうことない. 実際, TED のサイトには transcript もある. ただサイトのつくりが持ち出し派につらい. 持ち出しビューがないし, サイトから手元に切り出そうもコピペがやりにくい. それに切り出したテキストを Instapaper なんかのテキスト表示機に取り込むのは, いずれにせよ面倒がある. 私は移動中に原稿つきでスピーチ聴きたいだけなんよ. 音声だけで足りるほど英語できない… とい
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
Hackability - For Whom? - steps to phantasien
WEB+DB Press が出てます(だいぶ前に). 前回はあまりに内容がおっさんすぎたと反省し, 今回は若者ぶって JavaScript のビューレイヤの話を書いてみました. MVC 用語の定義を気にするのもいいけどもうちょっと細かい所に目を向けても面白いですよ, という話のつもりです. しかし最近は JS もおっさん言語であるという指摘をうけ二週遅れな自分を痛感… おっさん的な話であるところの連載第一回 Hackability vs. Hackiness はオンラインで読めるようになっていました. お暇のある方はご覧ください. 以下あんまし関係ない話: Hackability 紛争 先の連載記事にも書いたとおり, WebKit はプロジェクト目標の一つとして hackability を挙げている. 私が hackability の有無を気にし始めたのもこれを見て以来のことだ. Hack
炭坑の庭師 - steps to phantasien
Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro
WebKit2 と愉快な仲間たち - steps to phantasien
ある ニュース記事を同僚に教わった。 この記事によるとタッチデバイスの会社は WebKit2 に対応しているのに検索の会社は旧バージョンにとどまっており、HTML5 に課題は多いのだそうな。 そりゃ課題は常に山積みだよね…と思っていたら記事は誤解だと別の同僚が説明を書いている。 リンク先の記事はさておき、世間の関心をいまいち集められていない気がする WebKit2 についてざっと説明をしてみたいとおもう。 この記事を読み終われば WebKit2 と Chromium WebKit, Webkit1 の違いを知ったかぶれるようになる予定。 WebKit2 は 2010 年の 4 月にアナウンスされた WebKit の新しい API レイヤで、Mac 版 Safari などが使っている。 大きな特徴はレンダリングエンジンを別プロセスで動かせること。 Chromium でやっているのと同じような
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
