実践的なREADME駆動について

README Driven Development

実践的なREADME駆動の話をしてるスライド。

以下のイベントでのスライドらしい

Write The Docs EU – A two day conference for technical writers, documentarians, and all those who write the docs.

ユーザーがそのツールを選ぶのにドキュメントは大事な指標であり、README駆動開発とは何かについて紹介してる。
README駆動のメリットしてはコードを書く前にバグを直す、コードのスケッチングできる点を上げてる
実際にREADMEをPRしてレビューやmdlintでチェックすることで、一つのREADMEというエントリーポイントが存在することになる。

Who, what, when, where, why and how.

そのREADMEを通してビジョンを共有し、明示的な意図(6W)を書くことで、チームの対話がより簡単になり、結果的にコードを書く時間や質が良くなるという話だった。
単純にREADMEをかけという話じゃなくて、それを行う事でどういう事が起きるのかについて踏み込んでいてよかった。
mdlintとか紹介してたけど、READMEとコードって少しまだ距離があるから、それを開発スタイルで補完できるのかもしれないと感じた。

ChrisWren/mdlint
vesln/jsmd

広告

ECMA, TC39 Meeting 2014-11のメモ

TC39 MTG 11月が行われた

rwaldron/tc39-notes にそのミーティングノートが上がる予定

上がってからミーティングノート見ながらTC39 MTG MTGをする予定。

幾つか今までの変更が上げられているので、TC39 MTG MTGの前にメモ書き。

[GitHub英語] コードはMIT、ドキュメントはCCライセンスでと書く時

.NET open source projects typically use either the MIT or Apache 2 licenses for code. Someprojects license documentation and other forms of content underCreative Commons Attribution 4.0.See specific projects to understand the license used.

引用元: Microsoft/dotnet.

.NETのリポジトリにコードはMIT or Apache2で、ドキュメントやその他のものはCCライセンスでという表現の例があった。

azu/promises-book でそういう表現使ってたけど、実際に正しいのかよくわかってなかったので参考になりそう。

GitHubである機能がライブラリなどに実装された時期を探す手順(npm run編)

$ npm run [ENTER]とすると、package.json の scripts の内容がダンプされるのって、いつから実装されたんだろ…

引用元: コラーゲンたっぷりさん on Twitter: "$ npm run [ENTER] とすると、package.json の scripts の内容がダンプされるのって、いつから実装されたんだろ…".

探し方

  1. npm/npmを見る
  2. npm run の実装を探す
  3. npm/run-script.js at master · npm/npmにあった
  4. if (!args.length) return list(cb) それっぽい関数を見つける
  5. git blame
  6. コミットを発見

img

コミット見ると大体関連issueが分かる。

list runnable scripts · 9122541 · npm/npm

list runnable scripts by evanlucas · Pull Request #5184 · npm/npm で実装された時期がわかる。

Angularが好き嫌い(Ver 1.x)

Angular V1の頃のメモ

Ver2発表後

ちなみにAngularJS ver2はangular/angularで開発中

rebuild.fm後

Rebuild: Aftershow 67: Sacrifice Your Code (Naoya Ito)

Reactive MVC and the Virtual DOMのメモ

Reactive MVC and the Virtual DOM — Futurice のメモ。

Model-View-Intent and the Virtual DOM の記事版という感じ

  • React/Fluxは最近話題になってる
  • React/FluxはリアクティブプログラミングであるがAPIが少し違う
    • Reactはリアクティブとインタラクティブなパターンを混ぜた感じ
  • ゼルダのように昼と夜で同じマップだけど違う世界のように2重となるようなケースを考える
  • The dual of Interactive is Reactive
  • 普通のインラクティブの場合は、Xをに影響を与えるものを探す場合、他のモジュールでX.update()を探す必要がある
  • しかし、リアクティブパターンの場合はXの中を探せば良くなる

どうやってリアクティブパターンを実装するか?

  • event emittersの導入
  • Xからあるイベントをsubscribeするだけ
  • FluxもReactiveも別にRxJSやBacon.js等の必要はなく、EventEmitterだけでも事足りる
  • EventEmitter : RxJS == roller blades : cars.
  • RxJSではObservablesがEventEmitter的なもの

Reactive MVC?

  • まずはControllerを取り除くことから
  • Controllerはインタラクティブなコンポーネントだから
  • ModelはデータイベントのObservablesをexportする
  • ViewはModelのObservableに対してSubScribeする
  • MV*と言われるやつはControllerでユーザイベントを監視して、Modelのupdateを呼び出すスタイルを取る
  • Reactiveの場合はModelが”Reactive Controller”を監視する
  • この”Reactive Controller”を”Intent”といったりする

Model-View-Intent

  • Intentはユーザーイベントをモデルが監視しやすいEventに翻訳する(Intent Event)
  • ModelがこのIntent Eventをsubscribeし、モデルのデータを変更する
  • Intent -> Model -> View の一方通行の流れができる

    Model
    Input: user interaction events from the Intent.
    Output: data events.

    View
    Input: data events from the Model.
    Output: a Virtual DOM rendering of the model, and raw user input events (such as clicks, keyboard typing, accelerometer events, etc).

    Intent
    Input: raw user input events from the View.
    Output: model-friendly user intention events.

Virtual DOM to DOM

  • Model-View-Intent ではViewが実際のレンダリングをしないでもいい
  • ViewがVirtual DOMを使うRendererに処理を移譲してあげる

サンプル

How is this different to React/Flux?

  • Pureなリアクティブである
    • React/Fluxはリアクティブとインタラクティブをmixした感じ
  • MVIは中心となるものを持たない
    • FluxはDispatcherなど中心となるやつを推奨してる(シングルトン)
    • Model(Store)間の依存はそれぞれのモデル内で定義出来る
    • MVIはModels observe other Models.
  • RxJSパワー
  • RendererをViewと切り離せる
  • Rendererが副作用がある所なのでそれを分けることでテストしやすくなる
  • No internal state – SteteはViewにはなく、Modelのみに存在する
  • No reusable UI components
    • Reactは再利用可能なComponentsであることを主張してる
    • MVIの場合はそのような再利用可能なComponentsはWeb Componentsのレイヤーで持っておいて
    • それをVirtual DOMで使うとかそういう方向をイメージしてる

A State of Change — On the future of Object.observeのメモ

A State of Change — On the future of Object.observe

Object.observeについてのスライド。
Object.observeはオブジェクトの変更を監視できるが、imuutabilityとは逆の事になってしまう。
Immutableなしくみを提供するmori、同様にDOMでもStatelessなDOMを提供するReactやVirtual DOMがある。
ただ、全体としてのUI状態を管理するImmutableオブジェクトは必要。

Immutableなオブジェクトでやるいいところは、Undoの実装が簡単になる。

  • 現在のシンプルなバインディングはMutableデータをStateful DOMへ結びつける
  • 未来のレンダリングはImmutableデータをStateless DOMにする

[GitHub英語] コミットメッセージを次のように変更してくれないか?

Can you please format your commit message as “…”

引用元: Fix Markdown link by azu · Pull Request #1389 · eslint/eslint.

git commit --amend
# コミットメッセージの変更
git push origin fix_markdown_link -f

とすることでコミットメッセージを変更して、Pull Requestに反映するという手順も書かれてると、Gitに詳しく無くてもできるので良い。

Bleeding Edge Pressの技術書の執筆プロセス「booksprint」

Bleeding Edge Pressは最近いろんな技術書を早いペースで出してて、 Learning Swift とかもここの出版社。

後、共著で出してるケースが多い。

サイトの方を見たらどういうプロセスで書籍書いてるかの紹介があった。

Our Unique Process

引用元: About Us » Bleeding Edge Press.

に簡単に書かれてる。

明確にコラボレーションによって執筆が加速することに書かれてて、コラボレーションを上手くやるためにbooksprintを使うと書かれてる。
booksprintは週末とかにGoogle Hangout で書いてる人が集まって意見交換とかをやったりすることで、公開がスムーズに進むと書かれてる。

Videos » Bleeding Edge PressのページにDeveloping a Backbone.js Edgeでのディスカッション内容が公開されてる。