にわか TOEIC マニア - steps to phantasien
社内で開かれたワークショップ形式の研修に参加したのは一年前、ちょうど今頃のこと。 それはたぶんチームワークのような何かを学ぶ会だったはずだけど、 私の感想は本題と関係なく「いいかげん真面目に英語を勉強しないとあかん」だった。 話が通じないとチームワークどころじゃない。 米国資本勤めの会社員からすると、英語はグローバル云々以前に仕事用 DSL みたいなもの。 英語ができないまま騙し騙し働くのはたぶん、 SQL が書けなからと ORM の上だけでコードを書こうとするのに似ている。できなくはないけど、いろいろしんどい。 幸い私は Web 開発者じゃないから SQL はわからなくていい。でも英語はやらないとダメっぽい。 入社二年半、ようやく現実を直視した。 最初はしゃべる練習をしようかと思ったけれど、そもそもしゃべる以外の英語すらできるといえるのか。怪しい。 むしろまず典型的日本人として英語ができ
祝: 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 みたいなもの リアクティブプログラミングとは何だろう。どうもつかみどころがない。私は腑に落ちるまでけっこう時間がかかった。 このわかりにくさには大きく二つ理由があると思う。一つはプログラミングの概念をコードなしに説明する一般的な難しさ。オブジェ
趣味はキーノート鑑賞 - steps to phantasien
趣味は何かときかれたらインターネット企業ウォッチですと答えるかもしれない。そのへんの企業ゴシップに気を取られるよりコードでも書いてた方が百倍くらい有意義だとわかってはいる。でもついニュースを眺めて過ごしてしまう。職業上の便益を損ねるくらいだからこれは趣味と呼んで差し支えなかろう。中でも各種企業イベントのキーノート・スピーチ鑑賞はそんなおっかけ業のハイライトだ。 インサイダーからすると、キーノートは学芸会みたいなもの。隣のクラスの出来映えにやきもきすると同時に、自分のコードの晴れ舞台、たった一つの台詞を見守る。 インサイダーでないキーノート・・・つまり大半のキーノートは、言って見れば近所の高校の文化祭に行くようなものだろうか。あ、こういう学校なんだ、これが流行ってるんだ、なんてのが透けて見える気がして面白い。メディアが報じるキーノートは空気を伝えない。自分でビデオをみてこそ愛好家というものだ
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
炭坑の庭師 - 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 でやっているのと同じような
タダ飯よりも素敵なものは - steps to phantasien
GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。) 同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。 もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
