東京Node学園祭2015に参加したきたメモです。

また、技術文書をソフトウェア開発する話という内容でブログ以上技術書以下の文書を書く場合における開発方法について話してきました。

The State of JavaScript - @domenic

スライド: The State of JavaScript (2015)

  • 皆Babelを使い始めたらそれはスタンダードじゃない可能性があるので気をつけた方がいい
  • Custom Element
  • Service Worker
    • ブラウザの中でプロキシサーバ的なことができる
  • Custom Paint
    • registerPaint
    • 新しいCSSプロパティ
  • 言語
  • TC39/ecma262
    • に新しい仕様が置いてある
    • GitHubにある
    • Living Standard的な感じになってる
  • Spec番号
    • あんまり気にする必要はない
    • 言語ではバージョン番号は必要ない
    • 仕様書に入ったものだけがstable
    • そうじゃない場合は戻ってくる可能性があるunstable
  • ES7
    • async/await
    • SIMD.js
  • watch out for
    • value types
    • decorators
      • コードで静的に決まるの良いところ
    • cancelable promises
    • async iterator
    • module loader
      • import a from “./”;
      • import b from “../”
      • import url from “https://example.com/js”
      • が最小のケース?
    • web assembly

How did we get here

スライド: Node.js in the Enterprise // Speaker Deck

  • Nodeがどうやって今日の状態になったかについて

技術文書をソフトウェア開発する話

スライド: Introduction | 技術文書をソフトウェア開発する話

textlintとかを使って文書をテストしながら開発する話をしました。

  • 技術書を書く環境
    • 技術文書のコードと文書のテスト
    • textlintについて
    • 表記揺れのルールを設ける必要性
    • 技術文書の開発とCI
    • 何事も計測してから
    • 校正と推敲

このtextlintはjser.infoの文章をチェックするのに作ったのが始まりですが、今は日本語問わず文章なら何でもLintできるように設計されています(日本語向けのルールがあるとかそういう話)

azu/JavaScript-Plugin-Architectureはこのツールなどを作ってチェックしながら書いているという話をしました。

今はRedPenとか自然言語処理をちゃんとやっているツールもありますが、発表で話していたように自然言語の正しさは人によるところがあります。

そういった細かいルールをすぐ書いて使える環境としてtextlintを作っているので、Node.jsに慣れている人(ESLintのルールを書いたことがある人ならなおさら)は扱いやすいと思います。

発表では話していませんでしたが、対応してるMarkdown、txt、HTMLはProcessor Pluginとして実装されているので、対応する拡張子自体も拡張が可能です。

Markdownのパースではmdastをベースとしたものを使ったりしています。

話した内容のGitBookの構成はgitbook-starter-kitというリポジトリをcloneすればすぐに使えるようになっています。

何かあればtextlintにIssueを立てるといいかと思います。

“npm”: “>=3”

スライド: zkat/talks

  • npmの話
  • CLIはJavaScriptのために動くチーム
    • CLIチームは3名
  • npm日本語サポートの窓口
    • @watilde @yosuke_furukawa
  • npm
  • ProgressBar
    • 要望は昔からあったけどnpm 3でやっと実装
  • semver
    • バージョンを見た時に意味のあるものが入ったことがバージョン番号だけで分かる
  • npm3でのmajorな変更
    • Flat tree
    • npm dedupeがインストールされるたびに行われる
    • モジュールがグローバルに入ってる事には依存できなくなる
    • フロントエンドの事を考えてdudupeされてる
    • peerDependencies
      • 実際に入ってるかどうかは関係ない
      • 設定されてることが警告されるだけ
      • npm install hellになってしまった
  • npm shrinkwrap
    • どこで何回インストールされても必ず同じ結果になるのがshrinkwrapになる
  • npm v3の内部的な変更
    • フェーズに分けた
    • パッケージのダウンロード -> 次のフェーズ
    • preversionのlifecycle hookでnpm testするといい感じ
  • Roadmap · npm/npm Wiki
    • npmのロードマップ
    • frontend modulesのサポート
    • JavaScript以外のファイルの対応
    • browserDependencies
      • dependenciesが必ずFALT
      • ならない場合はFAIL
      • FALTになるように選択する
      • 結果として全てのモジュールがフラットで、モジュールの依存がはっきりする
  • Windowsサポート
    • npm installの42%はWindowsから
  • ES6 modules
    • ES6 modulesの仕様がどう進むのであれ、将来的にはnpmはES6 modulesとなるだろう
    • 仕様のfixすれば

Electroknit! - Pixel to sweater with Node.js - @kosamari

スライド: Electroknit！

  • Scripto
  • 編み物のカウントするスクリプトからJavaScriptを始めた
  • ウェブエンジニアでもハッカーになれる
  • 編み物はバイナリ
  • 編み機について
    • 自動編み機のバイナリデータをNode.jsで作る
  • Bitwise Operatorを初めて使った
  • aheckmann/gm
    • 画像からフルカラーは取れた
    • でもグレースケールにしないと
  • ニッティングマシンは200針 = 200px
  • カーネルコンボリューション=畳み込みしないとノイズデータが多い
    • 画像処理も必要になった
  • 作ったデータを編み機で編み(手動)
  • 画像もJavaScript(D3)で作った
  • コードがどうやって動くのかを編み機で理解
  • PEG.jsで編み物を書くだけの言語を作った

ESDoc - ES6時代のドキュメンテーションツール

スライド: ESDoc - ES6時代のドキュメンテーションツール - Node学園祭2015 // Speaker Deck

  • ES6時代の開発環境
  • ドキュメンテーションツール進化した?
  • JSDoc
    • まだES6には正式対応してない
  • JSDocのここを良くしたい
    • タグが多すぎる
    • 成果物が微妙
    • コードベースをES6
    • Rhino対応が複雑化の原因
  • ESDocというツールを作った
    • ES6 Class/モジュール対応
    • カバレッジ
    • テストコード統合
    • 静的解析
    • Lint
    • ホスティング
  • ESDocのゴール
    • 良いドキュメントを作れるツール
  • ドキュメントとは何か?
    • 要求
    • デザイン
    • algorithmとか技術的な擬似コード
    • エンドユーザー(マニュアル)
    • マーケティング
  • ESDocが対象するドキュメント = マニュアル
  • いいドキュメントとは?
    • 書き手: コードより簡単に書ける
    • 読み手: コードより簡単に理解できる
  • ドキュメントの要素
    • Instalation
    • Usage
    • API Reference
    • Example
    • ChangeLog
  • 継続性:カバレッジ
    • ドキュメントがどれだけ書かれているかをカバレッジ
    • モチベーション
    • 網羅性
  • 網羅性: 静的解析
    • 型を出す
    • プリミティブなものしか対応してない
  • 関連性: テストコードの統合
    • テストコードとドキュメントと関連付ける
    • @test
  • 検索性
    • 検索インデックスを作って検索する
  • その他のドキュメントについてはどうするのか
  • マニュアルの統合
    • APIリファレンス以外の内容もドキュメントに含められる
    • ESDocはmarkdownを読み込んで一緒に表示できる
  • ドキュメントのフレームを提供したい
    • 読み手にも書き手にも優しい
  • ESDocの今後
    • コードとドキュメントの日時チェック
    • テストコードのさらなる活用
    • クラスの関連図の作成

フロントエンドに秩序を取り戻す方法

スライド: フロントエンドに秩序を取り戻す方法 // Speaker Deck

  • 記事編集画面のリニューアル
  • はてなブログの設計思想
    • 4周年
  • 問題発生
    • 巨大なファイルがいる
    • テストが書けない
  • はてなブログのJS
    • 全体2万
    • 一部1ファイル5500行だったり
  • 編集画面のJSがでかい
  • 従来のJS分解
    • 名前空間ベース
    • concatしてた
    • グローバル名前空間
    • window.Hatena = {}
  • 依存関係の問題
    • 名前空間ベースは依存関係でつまる
    • concatでは難しい
  • Lintにやさしくない
    • 未定義の変数が名前空間にいると死ぬ
    • Hatena.Util.hoge Utilがちゃんといるかどうか
  • Browserify
    • concatしなくて良くなる
    • 少しずつCommmonJSに書き換えた
  • 名前空間 => モジュール
    • index.jsで名前空間にモジュールを突っ込む
    • 共通化を正しく行う必要がある
    • 循環参照
  • 設計のスタイルの問題
    • データとDOMが密結合
    • constructorでデータ初期化、DOMからデータ初期化色々なパターンが混在していた
  • コンポーネント間の連携の問題
    • 循環参照で呼び合ってた
    • Triggerで無理やり回避してたり
  • サーバとの連携
    • HTMLからJSでスクレイピングしてた感じ
    • サーバからHTMLを吐いて差し替えみたいな形
  • バニラJSで改善していく
    • データとDOMの分離
    • 初期化するときにDOMからデータを取ってくる
    • 途中ではDOMから取ってこないように
  • DOM操作は専用メソッド
    • JSでレンダリング
    • 要素をまるまるけして、まるっと入れ替える
  • 機能ごとにViewModelっぽいのを作る
    • データ、ビジネスロジックは親コンポーネント
    • EventEmitterになっていて、子コンポーネントはその通知を受け取ってDOMメソッドを呼ぶ
    • 親はデータを受け取り、変更、emitする
  • コンポーネント間のやりとり
  • renderを2015に自作?
    • Vue.js
    • React
    • 学習コスト、捨てやすい
  • Reactを採用
    • Vue -> Reactは難しい
    • React -> Vueはできる
  • デザイナーが触れない
    • JSXくらい触れるはず
    • CSSだけで
  • Babel
    • JSXのために導入(という口実)
    • Statge 2イカは禁止(変な機能を使われると困る)
  • 基本的な考え方
    • Fluxフレームワークは使いたくない
    • いつ消えるかわからない
    • EventEmitterで簡単にやる
    • 小規模: ViewModel
    • 中規模: Flux風
    • 大規模: Dispatcherを導入
  • スタイル導入の方針
    • 全ての標準ルールを入れる
    • 既存コードで警告がなくなるまでやっていく
  • テスト
    • 4月: Casper JSのE2Eのみ
    • 記事投稿とか特定の部分のみ
  • E2Eテストから?
    • シナリオが結構複雑
    • ユニットテストからしたい
  • ユニットテストから
    • テスタブルなコードじゃないとテストしにくい
    • View操作は必ず分離する
    • DOMを触るモジュールは
  • Karma
    • localStorageを使ってるものがいたので本物のブラウザ
  • リファクタリングしたらテストを追加するツール
    • Util系から
    • EventEmitterを導入したのでテストしやすくなった
  • E2E Test
    • ReactがあるためCasperJSが死ぬ
    • Nightmare
    • Protractor
      • Angularっぽい
    • Slenium.io
      • Selenium系なのでいざとう時に移行できる
    • ES6 generatorで同期的にテスト書ける
  • 今日話したこと
    • 良い設計を目指すための土台作り