読者のみなさまへ

Wazanova News の運営を行ってきた米国法人 Wazanova, Inc. を精算することにともない、当サイトの更新を終了いたします。1 年半にわたりご応援いただき、まことにありがとうございました。

特に、Gittip (Gratipay) を通じて継続的にご寄付いただいた方々に御礼申し上げます。2015年 3月上旬より寄付の受付を終了し、お預かりしたお金は全額 Gittip サイトの運営者に寄付するよう設定してあります。

既存コンテンツは当面の間、従来の URL でも閲覧できます。Jshiike からのごあいさつ にもある通り、一部を個人ブログサイトにも移行しており更新も予定されておりますので、こちらについてもご愛顧いただければ幸いです。

今後もメンバそれぞれ、IT / ソフトウェアエンジニアの世界に貢献していければと考えております。引き続きどうぞよろしくお願いします。

noto / Jshiike

原文を翻訳された方がいるようなので紹介します:

『毎日コードを書くこと - snowlongの日記』

noto 3年以上前 | ▲upvoteする | link | parent

この全文翻訳の記事が人気を集めているのを見て、この話題に関して親近感を覚えるエンジニアが多いのだと思いました。また、スポーツや楽器演奏もそうだと思うのですが、企業内の他の職種と違ってブランク期間が長くなると、予想以上に腕が落ちるのにもかかわらず、それが企業内でなかなか理解されていない、構造的にそれを防ぐ手段がないという背景もあると思います。

WazanovaNews 3年以上前 edited | ▲upvoteする | link | parent

定量的に調査したものを見たわけではないですが、より便利なテクノロジーへの変遷のペースが加速してきているのだとすると、かつては「エンジニアは新しいテクノロジーも勉強すべきだね。」だったのが、常に一定時間新しいものの習得に努めていないと、ものすごい勢いで自分の商品価値が下がっていくという時代になりますかね。人間のキャパって限られているので、学ぶ姿勢も大事ですが、「過去の自分を思い切って捨てるスキル」というのも重要になるのかな。

noto 3年以上前 edited | ▲upvoteする | link | parent | on: Angular 2.0

クライアントサイドの JavaScript フレームワークである AngularJS の公式ブログで Angular 2.0 の実装が始まったことがアナウンスされ、設計に関しての考え方、なぜ変更しようとしているか、詳細な変更点などについて述べてられています。Angular のもともと持っている特徴もおさえつつ説明されているので、Angular の復習にも良さそうです。

Angular 2 は mobile apps のためのフレームワーク (デスクトップにも利用できる)。data-binding、extensible (拡張可能な) HTML、テストのしやすさの重視については変わらない。

Angular 2 のすべての design docs は Google Drive で公開されている。このドキュメントでは、我々のアプローチの概要や設計方針が、個々の設計へのリンクとともに示されている。

注意: 我々はまだ Angular 2 の設計とプロトタイピングの段階にあり、これらのいくつかは異なった形で実現されたり、最終的なプロダクトにまったく含まれない可能性もある。

Designed for the future

Angular 2 の設計は、みなさんがこれを利用する頃、この世界がどのようになっているかを想定しながら行っており、特にモダンブラウザと ECMAScript 6 の利用をターゲットにしている。

  • モダンブラウザ: いつも自動的に最新バージョンにアップデートされるブラウザのこと。こういったブラウザを対象にすることで、Angular の利用・開発を難しくする hacks や workarounds を省略できる。今のところ、Chrome, FireFox,Opera, Safari と IE11 が含まれている。モバイルについては、Android のChrome, iOS 6+, Windows Phone 8+ と Firefox mobile がサポートされる予定。
  • ECMAScript 6+: Angular 2 のすべてのコードはすでに ES6 で書かれている。現在のところ ES6 はブラウザでは動作しないので、Traceur compiler を使って、動作する ES5 を生成している。開発者がもしアップグレードしたくなければES5 を利用し続けることも可能。

より速く (Faster)

  • より速い変更検知: Angular アプリケーションは DOM と JS オブジェクトの間の data-binding を利用して構築される。Angular アプリケーションのスピードは data-binding の基盤となる変更検知メカニズムに大きく依存する。Chrome M35 から利用できる Object.observe() を使うことでこれを改善する予定。
  • Instrumented (計測): 性能のもう半分はアプリケーション開発者の書くコードで決まる。アプリケーションで費やされる時間を高解像度 (high resolution) で計測するための仕組みを提供する予定。diary.js と呼ばれる新しい Angular-wide なロギングサービスを通して直接サポートされる。
  • Modular: Angular 1.0 をリリースした際は、この機能はオプショナルなパッケージだったが、モバイルデバイスでは大きく差が出る。$route をライブラリに分離した際おもしろいと思ったのは、革新的な代替モジュールがいくつか出てきたこと。性能とイノベーション実現のため、Angular のほとんどの部分を optional かつ代替可能 (replacable) で、他の Angular 以外のフレームワークでも利用できるものにすることをゴールにした。
  • 他の性能に関するトピック: デザインはまだないが、他の性能最適化も含める予定。事前に parse されたテンプレートを使った初期ロード改善から、なめらかでスムーズな 60 frames per second のアニメーションまで、完全に最適化されたユーザエクスペリエンスのために労力を注ぐ予定。

よりシンプルに (Simpler)

  • Dependency Injection (DI): DI は他のクライアントサイドフレームワークとの主要な差別化要素であり、アプリケーション内の連携 (wiring) コードの量を減らし、デフォルトでテストしやすくすることに貢献している。現状の実装より複雑性を減らしながら、できることを増やせると考えている。設定フェーズを減らし、命令的なスタイルのかわりに宣言的スタイルの ES6+ アノテーションを使ってシンタックスをシンプルにすることで、DI の複雑さを減らせる。DI を ES6 モジュールのロードと統合することで、より多くのことができるようになる。child injectors を通して我々の JS の一部を lazily-load できるようになる。
  • Templating and Directives: HTML に直接テンプレートを記述できることと、そのシンタックスを拡張できることは Angular のもっとも基本的な部分。バージョン 2 のテンプレートコンパイラーでは以下のような野心的なゴールを設定している。
    • directive API をシンプルにする
    • ウェブ標準を利用した他のコンポーネントとの統合
    • 性能改善
    • IDE のようなツールを利用して分析・バリデーションできるように

より多くの機能 (More capable)

  • Touch animations: 指を利用してリストをスクロールする、カルーセル (回転式の選択インタフェース) の利用、スワイプしてリスト要素を削除するなど、ユーザはタッチ前提の利用パターンに慣れている。しかし、現状下記のような問題があるため、first-class サポートを提供する予定。

    • カルーセル、無限スクロールの現在の実装は、コアを共有しておらず、冗長でさまざまなアプローチが存在している。
    • 古いブラウザや現行ブラウザの一部がサポートしていないということもあり、現在の実装の多くはネイティブスクロールイベントを利用する手段を提供していない。
  • Router: 最初の Angular router はごく限られたシンプルなケースを扱うように設計されており、Angular が成長するにつれて、徐々に機能が追加されてきた。しかし、基礎となる設計は大幅な拡張に適していない。多くのアプリケーションフレームワークについて router 実装を調べており、もっとも幅広く、さまざまなアプリケーションに対応可能なシンプルでかつ拡張可能な route を提供できると考えいている。特にサポートしたいと考えているものには以下が含まれる:

    • state-based routing
    • 認証・権限機能の統合
    • ビューの状態維持、特にモバイルで必要とされている
  • Persistence (永続化): 多くの開発者はサーバからのデータ、ブラウザのローカルで保持されるデータを扱うために、Angular の簡素な $http より抽象度の高い方法を求めている。モバイルアプリはサーバへの接続を試しつつ「常にオフライン」モードでも動く必要がある。RESTful サービスは $resource で提供されるより多くの機能を必要とする。途切れないストリームモデルが必要な場合もあれば、バッチでアップデートできるデータもある。新しい永続化レイヤでは、こういったケースのためのきれいな構造を提供し、現在共通的に必要とされるものを取り込んでいく。

Q&A

  • いつ完成するの? → 未定。design docs を投稿したばかりだが、すでに多くのモジュールのプロトタイピングを始めている。DI と Zone.js は利用できるようになってきている。すべての作業は GitHub 上で行われ、週次ミーティング議事録もとっているので、追跡可能。
  • Angular 1.x アプリケーションは Angular 2 に移植できそうか? → 開発中なので正直なところわからない。想像するに移植はかなりかんたんだと思うが、移植作業自体が不要とはならないのではないか。作業の多くは ES6 の恩恵を得る部分と関わると推測する。テンプレートはほとんどが同じで、残りの部分は機械的な置換でいけるだろう。コントローラもかんたんに移植できるはず。もっとも検討が必要なのはモジュールとディレクティブの利用部分。
  • Angular 2 は PhoneGap や Ionic Framework のようなモバイル技術を置き換えるものか? → No. Angular は従来通り単なるコアフレームワークである。モバイルに最適化された CSS/JS コンポーネントとして Ionic のようなライブラリや、app packaging とネイティブ API アクセスのための PhoneGap のようなツールが、今までどおり欲しいと思うことはあるだろう。
  • Angular 2 は AngularDart とどのように関係するのか? → AngularJS を Dart 言語に移植する際は、今まで学んだことをすべて利用して Angular の新しいバージョンをビルドしている。改善されたディレクティブの概念やシンタックス、クラス/アノテーションベースの DI のような、このドキュメントで議論されている改善点の多くは、そちらにもすでに含まれている。実装はバージョン 2 で到達するものにはまだなっていないが、これから提供されるもののすばらしいプレビューになっている。AngularJS 2 を構築するにともなって、AngularDart もアップグレードしていく予定なので、Dart 言語を好む人たちも JS の人たちと同様にその利点を楽しめる。我々のゴールは言語の選択によらずひとつのフレームワークを提供することだ。

MySQL の専門家として著名な松信さんのブログなのですでに読んだ方も多いかと思いますが、自分も読んでみたので日本語でサマリを紹介します。実は一番最後に SUMMARY というセクションがあってそこにまとまっているので、そこだけを紹介するかたちです。本文はサンプルコードを使った説明になっていてよりわかりやすいので、ぜひ本文を読んでみてください。

質問: なぜバッファを利用した write() が時々待たされるのか? 単にカーネルバッファに書き込んでいるだけで、disk にはアクセスしていないのでは。

答え:

  1. write() は、必要な時に disk read を行う。これを避けるにはファイルを上書きするのではなく追記 (append) するようにする、あるいは OS page サイズに合わせた write を利用する (本文中で、Facebook MySQL は InnoDB log について OS page サイズに合わせた write をしていて、production 環境で使っていると紹介あり)。

  2. write() は、"stable page writes" というもののために block されることがある。これを避けるには stable page writes をオフにできる新しい Linux カーネルを使う必要がある。

  3. 本当にレイテンシのことを気にするのであれば ext ファイルシステムを使うことはおすすめしない。かわりに xfs を使うこと。

これらの問題は raid コントローラ上のバッテリー/フラッシュメモリでバックアップされた write cache を使うことで緩和できるが、いつも可能ではないし、バッテリーもよく切れてしまう。

最後に、次の post では、なぜ sync_file_range(SYNC_FILE_RANGE_WRITE) が時々止まってしまうかを説明する予定と書かれています。

個人的に、原文読んでて興味深かったのは、以下の点です:

(背景としてスクラムはそこそこ知っていたけど、カンバンのことはツールとして以外にはほとんど理解していなかったというのがあります)

  • たくさんの開発チームの現状をワークショップで探ったところ、どこも同じ問題を抱えていて、それが task-switching, technical dept and plans and deadlines not being met であること

  • この問題は開発チーム以外に HR, communications and management teams でも見られ、IT 部門以外のすべての knowledge-based team に共通すること

  • 根本的な原因は進行中のタスク (work-in-process, WIP) が多すぎることで、この数を最小化することでほとんどの問題が解決すること

  • カンバンは、WIP を制限することで、フローコントロールに集中する手法なので、この問題解決としてぴったりであること

同時進行しているタスクが多すぎてかえって効率が落ちているという様子は、開発にかぎらず仕事の現場でよく見られることですし、そういう時は task-switchingに悩まされてたり、ひとつのことに集中できていなかったりします。

それ以外の WIP を減らす理由を調べていたら、同じ InfoQ の「かんばんとスクラム 両者の良さを最大限ひきだす」というミニブックの p.16 にありました:

一度 WIP の制限をかけると、私たちは一つのタスクが完了するまでの平均時間であるリードタイムの計測や予測を始めることができる。予測ができるリードタイムがあれば私たちは SLA(service-level agreements: サービス内容合意書)への合意や現実的なリリース計画を作成できる。

スクラムがイテレーション、スプリントという期間を区切って、その中でどれくらいのストーリーポイントを消化できるか見積もり・計測をするように、WIP を制限すると個々のタスクの所要時間を計測したり見積もりしたりしやすくなるようです。

このミニブックでは他にも

  • スクラムでは、スプリントの開始前に取り組むと決めたストーリーに集中して、その期間内の変更を減らそうとするが、カンバンは WIP にだけ集中しようという考え方

  • WIP の制限は、スループットを上げるためのものなので、スループットを最適化するため WIP 数を調整する必要がある

という話も紹介されていました。

スプリントごとに結合して動作するものを作るなどの場合はスクラムのほうが良さそうですが、開発チーム以外にも適用できるという点ではカンバンのほうが適用範囲が広そうです。エンジニアから見て、エンジニアリング部門以外でもカンバン (的なもの) を使えばいいのにと思う場面もあるような気がします。

上記のミニブックはスクラムと比較してカンバンを理解するのにとてもよい内容ですので、おすすめです。

余談ですが、マネージャは

  • ミーティングドリブンで (つまり時分割で) 仕事をすることが多い
  • いくつかのタスクを同時並行して進める (アサインして進めてもらう)

ことから、同時並行でものごとを進めるのが当然と思いがちで、それを何かに集中すべきメンバーに無意識のうちに強いてしまっているという面もあるんじゃないかなと思います。チームの仕事のスタイルはリーダーやマネージャが決めてしまう、という部分が大きいと思うので。カンバンはそれに関して意識的になるという意味でも有効かもしれません。

Gittip は 毎週少額の現金を贈るしくみ で、名前から推測できるとおり open source software 開発者の支援が主目的になっています。週ごとの取扱額が日本円換算で 100 万円を上回ってきているようなので、あらためて紹介したいと思います。

手数料は実費しかとっておらず良心的で、ファウンダーも Gittip という組織もかろうじて Gittip 経由で gift を受け取るだけで頑張っているようです。

2014 年 2 月 13 日の (1週間あたりの) 送金額は 11,683 ドルで、これは、20131 月 3 日の 1,425 ドルと比較して、8 倍 (= 2 の 3 乗倍) になった (グラフ)。

取扱高に比べるとアクティブユーザ数の成長 (グラフ) はゆっくりで、これは 1 年前より多くの企業が Gittip でお金を提供するようになったのと、個人以外に対しても支払えるようになったことが背景にある。

Gittip ファウンダーの Chad Whitacre は 2013 年 1 月からフルタイムで Gittip に携わり、チーム作りを開始し、 今年の 1 月には 20 名の参加者が一同に会した。その後、Venmo や bitcoin と連携して定常のもの以外に 1 回限りのギフトを送る機能の追加、コミュニティ機能の改善などを行ってきた。

平均して 4, 5 ヶ月で取扱額が倍になるので、もしこのペースで行くと 6 月か 7 月に週 22,800 ドルに到達し、2015 年の春には 100,000 ドルを超えるはずだ。

Wazanova もそろそろ運営資金を何とかする必要があるのですが、これを機に Gittip アカウントを作成してみました。support してくださる方いらっしゃいましたら、よろしくお願いします。

noto 3年以上前 | ▲upvoteする | link | parent

追記ですが、個人的には優れたオープンソース・ソフトウェア (OSS) の作者が、OSS を書くだけで生活ができるというのは理想的な状況だと思うので、Gittip のような仕組みは意義が大きいと思っています。それこそ、どこに住んでいてもできる仕事でしょうし。

objectx 3年以上前 | ▲upvoteする | link | parent

https://flattr.com/ とは違って、

幾ら送るのか明示 (基本は)定期的な送金

なのですね。

noto 3年以上前 | ▲upvoteする | link | parent

そうなんです。flattr の方が使い勝手良いでしょうか?

flattr は、支払う人が月額の予算 (総額) を決めて、あとは like 的なアクションをした対象に分割して支払われるという形のようですね。

objectx 3年以上前 | ▲upvoteする | link | parent

flattr ボタンが付いてても悪くは無い気もするんですが、そうなると upvote と微妙に被る様な気もします。

noto 3年以上前 | ▲upvoteする | link | parent

たしかにそうですねぇ。

各実装での ES6 対応状況は http://kangax.github.io/es5-compat-table/es6/ にまとまっていて、 V8 での開発状況は https://code.google.com/p/v8/issues/list?q=label:Harmony が参考になるようです。

ご指摘のとおり V8 / Node Harmony でもまだまだ未実装のものが多いようです。TJ Holowaychuk さんも「ES6 が使えるようになると」と言ってますが、そういう意味ではこの議論、今使えるものと近い将来使えるようになるものが若干ごっちゃになっていると思います。

あともう一つ補足で、ES6 で予定されている機能の説明は https://github.com/lukehoban/es6features がわかりやすくて、現在も頻繁にメンテされています。英語ですが、サンプルコードが多いので概要つかみやすいと思います。

JS でブロックスコープが使えるようになるといいなぁと思う人がけっこういるのではないかと推測しますが、それを実現する let はすでに Node Harmony / V8 で実装されているようです。

@naoya_ito さんの tweet を、ご本人の許可を得て掲載します: