下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
最近のおっさんたち - steps to phantasien
Gisted のドッグフードをかねて InfoQ のインタビューやプレゼンを見るようになった。 いくつか面白かったのを紹介したい・・・とおもってるうちにバックログを溜めすぎた。一度に紹介するのは諦めて何度かにわけよう。 今日はおっさん、具体的には ThoughtWorks 周辺の面々を追いかけてみます。InfoQ 中心だけどそれ以外も若干あり。 When Geek Leaks “プロダクティブ・プログラマ ” の著者 Neal Ford が あるキーノートにつけたタイトルは ”When Geek Leaks“。 ここでの Leak は前向きだ。Geek の情熱がその主たる関心の外にも影響を与えていくといいですね、という話。 ファインマンが物理学という専門以外で発揮した数々のいたずら心、 ”Now Every Company Is A Software Company” という Forbes
リアルな DOM はなぜ遅いのか - steps to phantasien
これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 「React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ」 もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ
祝: 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
WebKit2 と愉快な仲間たち - steps to phantasien
ある ニュース記事を同僚に教わった。 この記事によるとタッチデバイスの会社は WebKit2 に対応しているのに検索の会社は旧バージョンにとどまっており、HTML5 に課題は多いのだそうな。 そりゃ課題は常に山積みだよね…と思っていたら記事は誤解だと別の同僚が説明を書いている。 リンク先の記事はさておき、世間の関心をいまいち集められていない気がする WebKit2 についてざっと説明をしてみたいとおもう。 この記事を読み終われば WebKit2 と Chromium WebKit, Webkit1 の違いを知ったかぶれるようになる予定。 WebKit2 は 2010 年の 4 月にアナウンスされた WebKit の新しい API レイヤで、Mac 版 Safari などが使っている。 大きな特徴はレンダリングエンジンを別プロセスで動かせること。 Chromium でやっているのと同じような
現場のフォーム - steps to phantasien
このごろ仕事の進みが悪く、しかもまったくの自業自得で肩を落としている。 今日はそれをふりかえり明日への糧としたい。反省文。 仕事の進みは「遅い」だけ。動いてはいる。一歩一歩は正しい。 でも一歩を踏み出すまでが遅い。正しい一歩を踏み出せる、正しい姿勢をとるのが遅い。 背中を丸め足を引きずる。たとえばこんなふうに… Bisection ある昼下がりにバグ修正を頼まれた。リグレッション。ここ三ヶ月くらいで壊れたらしい。 リグレッションを直す「正しい」一歩目は、二分探索で原因のリビジョンを探す bisection 作業だ。 でもこのバグ、bisection が面倒そう。なんとなく原因の想像はつくからあたりをつけて直してしまおう・・・ ・・・半日たち、結局あたりはつかない。日が暮れてしょんぼり帰宅。 翌朝気を取り直し bisection をしたら 2 時間でリビジョンの特定がおわる。あらら。 しかも
タダ飯よりも素敵なものは - steps to phantasien
GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。) 同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。 もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもな
Polymer と Web Components - steps to phantasien
先週はサンフランシスコで勤務先の年次博覧会が催され、中には自分と近いプロジェクトを紹介するセッションもあった。 いい機会なので便乗して宣伝してみたい。自主会社員活動につき勤務先の見解と違っても見逃してください。 さて件の年次博覧会、ウェブ開発者向けの講演の一つで Polymer という新しい JavaScript UI フレームワークが公開された。 Closure, GWT, Angular ときて また別のフレームワークかよ…とぼやく人の気持ちもわかる。でもそれほど被るものでもないから見逃してほしい。 なるべく多くのブラウザで動かそうとする既存のフレームワークと違い、 Polymer は新しいブラウザの機能を使い倒すことで強力なフレームワークを作ろうとしている。 別に特定ブラウザでしか動かないわけじゃない。ただ将来そうした新しい機能が各種ブラウザに備わる日を見越し、 そのときベストに動く
炭坑の庭師 - steps to phantasien
Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
