Are you the publisher? Claim or contact us about this channel
Embed this content in your HTML

Search
Report adult content:
click to rate:
Account: (login)

More Channels


Channel Catalog


older | 1 | .... | 3 | 4 | 5 | (Page 6) | 7 | 8 | 9 | .... | 13 | newer

    0 0

    WEB+DB PRESS用語統一ルールとは、gihyo社のWEB+DB PRESSで使っているらしい用語の揺れを修正するための辞書ファイルのことです。

    gistで公開されています。(最新版とかGithubで管理したりしないのかな)

    この辞書ファイルはWZ EDITORの用語統一辞書となってます。

    フォーマット見てたら正規表現に変換できるんじゃないかなーという感じがしてきたので、Nodeでazu/wzeditor-word-rules-parserというパースして正規表現に変換するものを書いてみました。

    仕様が公開されてないので、色々試しながら変換したので正確なのかは若干怪しいですが、とりあえず変換出来た気がします。(一部正規表現的に解釈できないのがあったのダメな行があります)

    JavaScript Promiseの本を書いてて、これで、WZ Editor以外でも単語のLintができるんじゃないかなーと思って作りました。


    0 0

    この記事はSource Mapに対応した何かを作るためのライブラリとか仕様とかについて調べてメモった記事です。

    利用する場合の話はSource Maps 101 – Tuts+ Code Tutorial等 検索すれば色々出てくると思います。

    Source Mapとは

    まずはSource Map Revision 3 Proposalを見て置きましょう。
    ConventionsやNotesに参考となる情報が多いはずです。

    //@”から//# sourceURLという形式に変えた理由や、多段source mapについて書いてあります。

    何かを実現したい時、mozilla/source-mapを見てこのAPIで実現できないかを見てましょう。
    多くのライブラリは内部的にこのモジュールを使っていて、ちょっとしたラッパーであるケースも多いです。

    source mapオブジェクトは色々なモジュールの中で出てきます。

    {// version"version":3,// Source Map の対象ファイル (*.min.js など)"file":"out.js",// sources の基準となるルートパス"sourceRoot":"",// ソースファイルへの参照"sources":["foo.js","bar.js"],// ソースファイルを埋め込む場合に使う"sourcesContent":[null,null],// mappings でシンボルリスト"names":["src","maps","are","fun"],//  エンコードされたマッピングデータ(対応表)"mappings":"A,AAAB;;ABCDE;"}

    via #JSオジサンで Source Map について話してきました : document

    Utility

    • lydell/source-map-resolve
      • sourceMappingURL(コードに含まれているsource mapの定義ファイル/データURL)コメントから詳細な情報を取得するモジュール

    コード -> source map オブジェクトの詳細情報

    function(){...}();
/*# sourceMappingURL=foo.js.map */

    のようなコード(とファイルパス)を受け取って、source mapオブジェクト等を取得する。

    sourceMapResolve.resolveSourceMapはsource mapオブジェクトやそのmapファイルへの相対パスをsourcesRelativeToで取得出来る。

    sourceMapResolve.resolveは resolveSourceMapがパスだけなのに対して、ソースの中身(コード自体も)も一緒に取れる。

    • lydell/source-map-dummy
      • ダミーのsource mapオブジェクトを作成するモジュール
      • mappingsプロパティを生成する際に、jsとcssは自分自身をtokenに分解してマッピングを作る
    • lydell/source-map-url
      • sourceMappingURLコメントが入ったコードが対象
      • mapファイルのURLを取得
      • sourceMappingURLコメントの書き換え
      • sourceMappingURLコメントの削除
      • sourceMappingURLコメントの前にコードを挿入
      • sourceMappingURLコメントにマッチする正規表現の取得
    • thlorenz/convert-source-map
      • source map の相互変換モジュール
      • 入力 : source mapオブジェクト、JSON、Base64、sourceMappingURLコメント、mapファイル
      • 変換 : プロパティの追加/削除、
      • 出力 : source mapオブジェクト、JSON、base64、sourceMappingURLコメント
      • 削除 : sourceMappingURLコメントの削除

    結合

    • edc/mapcat
      • mapファイルを結合するツール/モジュール
      • mapファイルを渡す
    1. mapファイルから変換後ソースしてそれぞれ結合
    2. source mapのlineを結合するときに、ソースの行数分offsetを足していく
    3. 結合したソース + 結合したmapファイルを取得
    1. codeと mapを持ったオブジェクトの配列を作る
    2. concatに渡す
    3. => codeをまとめたjsファイルと、mapをまとめたmapファイルができる

    codeとmapが1対1、mapがないjsはlydell/source-map-dummyでダミーを使ってやればいいという方針。

    デバッグ

    ツール

    AST

    バリデーション

    その他

    人


    0 0

    JavaScript Promiseの本

    JavaScript Promiseの本という無料で読める電子書籍を書きました。

    タイトルそのままで、JavaScriptのPromiseについて書いた書籍です。

    書籍の目的

    この書籍を読むことで学べる事として、次の3つを目標にして書きました。

    • Promiseについて学び、パターンやテストを扱えるようになる事
    • Promiseの向き不向きについて学び、何でもPromiseで解決するべきではないと知る事
    • ECMAScript6 Promiseの基本をよく学び、発展した形を自分で形成できるようになる事

    Promiseは、次のECMAScriptの言語仕様として策定が進められていて既に多くのブラウザに実装されています。

    Promiseについて扱う書籍ですが、この機能はjQuery.Deferred()やAngularJSの$qやBluebird等の類似の機能が既にあるため扱ったことがあるかもしれません。

    ECMAScript6 Promiseの機能自体は新しいものではなく、既にあるものを標準化しただけです。
    そのためライブラリ等を使えば今すぐ使えますし、既に使っています。

    また、今後ブラウザに実装されるAPIとしてService WorkersやStreams API等、Promiseをベースしたものも出てきています。
    JavaScriptの非同期処理の一つのパラダイムであるため、この機会に学んでおくと他のAPIを学ぶときにも役立つかもしれません。

    書籍の閲覧方法

    この書籍は、スマートフォンも含めブラウザで見られるHTML版と PDF版を公開しています。

    HTML版には、表示されているサンプルコードをそのまま実行して試せる機能があるため、Promiseをサポートしてるブラウザで見るのをオススメします。
    ブラウザがPromiseをサポートしてなくてもPolyfillが使われるので大抵の環境で実行出来ます。

    JavaScript Promiseの本 2014 06 23 00 46 57 2014 06 23 00 47 03

    FirefoxとChrome、Operaの安定版は既にPromiseをサポートしてるので、その環境で見るのがオススメです(CORSやWeb Notificationを使うサンプルが出てくるのでデスクトップブラウザだと全てを試せます)

    この書籍のソースコードは全てGithubで公開されていて、ライセンスはCreative Commons Attribution-NonCommercialです。(コードはMIT)

    そのため、何か問題や意見などがあったらIssues · azu/promises-bookにIssueを立てたり、azu/promises-book – Gitterのチャットに書き込んだりしてくれると嬉しいです。

    書籍のハッシュタグは#Promise本となっています。

    こういう形態で書籍を公開したのは、常に書籍が更新出来るようにしたいからでもあります。
    そのため、今後の更新内容を受け取りたい場合は、Release notes from promises-bookをRSSリーダーで購読するといいかと思います。

    もっと細かく知りたい人はazu/promises-bookをWatchするといいでしょう。

    書籍の作り方

    書籍はAsciidoc形式で書いてAsciidoctorでビルドしています。

    また、Promiseには興味ないけど、こういう電子書籍の作りに興味があるという人は、JavaScript Promiseの本 付録というおまけを公開しています。

    おまけ.pdfには、この書籍を書き始めた理由や、どのように書いていったか、書籍自体の自動テストやワークフローについて書かれています。
    Github IssueやPull Requestの活用方法について自分なりに感じた事を長々書いてた気がします。

    Gumroadから無料 または 好きな値段でダウンロードすることが出来ます。(寄付したい人は寄付の代わりに使って下さい)

    ダウンロードする際に作者へのメッセージも書けるので、 メッセージを残すついでにダウンロードしていってね！

    最後に書籍の目次を貼っておきます。

    書籍の目次

    1. Chapter.1 - Promiseとは何か

    1.1. What Is Promise
    1.2. Promise Overview
    1.3. Promiseの書き方

2. Chapter.2 - Promiseの書き方

    2.1. Promise.resolve
    2.2. Promise.reject
    2.3. コラム: Promiseは常に非同期?
    2.4. Promise#then
    2.5. Promise#catch
    2.6. コラム: thenは常に新しいpromiseオブジェクトを返す
    2.7. Promiseと配列
    2.8. Promise.all
    2.9. Promise.race
    2.10. then or catch?

3. Chapter.3 - Promiseのテスト

    3.1. 基本的なテスト
    3.2. MochaのPromiseサポート
    3.3. 意図したテストを書くには

4. Chapter.4 - Advanced

    4.1. Promiseのライブラリ
    4.2. Promise.resolveとThenable
    4.3. throwしないで、rejectしよう
    4.4. DeferredとPromise
    4.5. Promise.raceとdelayによるXHRのキャンセル
    4.6. Promise.prototype.done とは何か?
    4.7. Promiseとメソッドチェーン
    4.8. Promiseによる逐次処理

5. Promises API Reference

    5.1. Promise#then
    5.2. Promise#catch
    5.3. Promise.resolve
    5.4. Promise.reject
    5.5. Promise.all
    5.6. Promise.race

6. 用語集

    書籍へのリンク

    おまけに書いてたような書籍を作るにあたってやったことはまた別の記事で書くと思います。


    0 0

    個人開発を支える技術Night

    個人開発を支える技術Night on Zusaarに参加したのでメモ。

    スライドは以下にまとめられているそうです。

    自分は Githubで書く電子書籍という内容で発表してきました。

    最近、 JavaScript Promiseの本という電子書籍を作って公開したので、どのような構成要素なのかについての話です。

    Githubで書く電子書籍の要約的には以下の要な感じです。

    • JavaScript Promiseの本 ではAsciidocを使った
      • Asciidoctorが良くできてた
    • 人間はやることスグ忘れるのでGithub Issueにメモろう
      • 公開情報になるので周りが口出しやすい
    • 自動化できるところは自動化してTravis CI等で回す
      • Pull Request駆動の効果が増すよ
    • 文章のリファクタリングは大変なので、周りが協力しやすい形にしよう

    個人開発と徳 – @otiai10

    • 徳が高い との話
    • お金と”徳”
      • ユーザーがお金を払う方法はあるので

    Animetick on さくら VPS – @KAZZONE

    • アニメをチケット管理
    • AWSは高い
    • 個人開発の味方 さくらVPS
      • 年間2万くらいのいサーバー代/ドメイン代
    • そろそろ2台にしたくなった
      • 分析基盤をつくろう
    • fluentdでログ転送
    • mongodbに格納
    • 自分で作った「Analytick」

    個人開発 in フィリピン 個人開発 in フィリピン – @deeeki #mydev

    • 最近つくったもの
    • ウェブサービス
      • 自分が使いたいもの
      • 収集系多め
    • ウェブサービスのためのライブラリ

    • Ceeker

      • Twitterの会話を集めるアプリ

    • 知見

      • Railsのありがたみ
      • 各gemにくわしくなる
      • Worker Dyno のありがたみ

    • Slidegate

      • 人気のスライド一覧してる
      • いいスライドはとっておきたい

    • 知見

      • デザインはtwitter Bootstrapでいい
      • exception_notification-rakeがあると便利

    • 知見いろいろ

      • うけそうなものよりもじぶんが使いたいもの
      • モチベーションの維持
        • コミュニケーション
        • チャットサービス
        • もくもくサービス

    • ソースコードの公開

      • メリット > デメリット
      • 外部ストレージとして

    • Webサービスで稼げるか

    • お金の稼ぎ方

      • しごとで稼ぎましょう

    ツイセーブを支える技術 – @9m

    リリース当初

    • MySQL
    • mroonga
      • 負荷が高いと壊れる

    リリースから結構経った後

    • 全文検索だけmongodbへ

    今年のはじめ頃

    • Solrに変更
      • Sunspotめっちゃ便利(Rails)
    • メモリが足りない

    個人開発のその先

    • あたった
    • サーバ代がやばい
    • 税金がヤバイ

    同棲生活による個人開発時の問題 – @soramugi

    • 現状の問題
      • 開発に使える時間が少なくなる
      • 集中できる時間が限られる
      • 個人開発がしにくくなる
    • 作ったサービス
    • TWordTag
    • FavMedia
    • 同棲と個人開発の問題
    • 開発に使える時間が少なくなる
      • 常に一緒にいる
      • 休日には遊びに行かなければならない
      • 何かを決めるには確認をとる必要性
    • 集中できる時間が限られる
      • 外部からの阻害要因が増える
      • 相手が何か失敗した時にリアクションが求められる
    • 分けるのは解決にならない
      • 開発が好きなのに作れる自由が妨害されている
      • 気になる事をやれないフラストレーションがたまる

    現状の解決策

    • 目的を明確に
      • タスクを立てる
      • 細かく集中、細かく解決する事で阻害される弊害を最小限へ
    • 長く続けられるようにする
      • 面倒な事をするようにする
      • 面倒なところはCIへ投げる

    話すことと作ること – @kyo_ago

    • 最初はとにかく喋った方がいい
    • 形になってきたら外で喋らないほうがいい
    • しゃべることでイメージが固まってしまう
      • しゃべることで満足してしまう
    • 作ってるものが正しいか不安になってくる
    • 話してるだけだと、未実装のアイデアが増えてくる
    • 自分が欲しいものを作るべきか?
      • 他人がほしいものはポートフィリオにしやすい。
      • 人に見せてもはずかしい

    DokkaaでドッカドッカDocker – @k2nr_

    Dokkaa Docker

    • Dockerのホスティングサービスを作ってる話
    • Dokkaa – https://github.com/k2nr/dokkaa-builder
    • イメージ名とかを指定してcreateする
    • イメージが走って指定したドメインでdockerが動く
    • Clojure
      • Om(React)ラッパー
    • dotcloud/hipache
      • リバースproxy

    骸骨駆動設計 – @mizchi

    • 時間がない
    • 資本がない
    • しがらみがない

    そもそも(僕の)個人開発の目的

    • 作るプロセスを楽しむ
    • プロトタイプ的な

    会社をハックする

    • 家でコンセプトを実装する
    • 会社で「こんなライブラリがある」といって会社の時間で開発する

    会社の成果を使いまわす

    • 次のプロジェクトのためにスケルトンを抜き出しておいてしまう

    ベンチャー

    • ベンチャーは買収されるリスク
    • OSSはそれに対するものでもある

    TypedCoffeeScript

    • 金がないとやってられない
    • gittip
    • BountySource
    • でも、金を集めるとサボれないので不便

    草を生やす技術 – @Linda_pp

    • Githubの草を生やす話
    • LLVMのフロントエンド Dachs

    GithubのCurrent streak

    • Current Streakをひたすら伸ばす
    • 19 – > 275 Contributions/monthに伸びた
    • GithubはSNS
    • 勉強会/もくもく書い
      • このアイデアのどこがイケなてないですか
    • やる気がでない時
      • とりあえずコミットすればいい
      • 問題点やTODOを考えたりまとめてissueを開く
      • Pull Requestのマージ
    • 1日最低1ドはリポジトリと向き合うことが大事

    Githubで書く電子書籍 – @azu_re

    Githubで書く電子書籍

    Github + Asciidoc + Travis CIで書く電子書籍

    Yeoman generator改造して気持よくなる話 – @h_demon

    • vus.jsリジェクト
    • gulpリジェクト
    • coffeescriptリジェクト
    • 命名がクソいと問い詰め

    • 個人開発の個人的な意義

      • 最新の技術を使って行きたい

    • Haxieさん

      • WHATWGのHTML仕様のエディタ

    • WAHTWG

      • W3Cとは別

    • 仕様と議論を追う手段

      • ML
      • Issues
      • IRC

    • ML

      • まずはメーリングリスト
      • 新仕様の議論もここからはじまる
      • どこからはじまったのか探すのが難しい

    • IRC

      • #whatwg #development が活発

    • WHATWG「とりあえず実装してみて」

      • 実装してみてからMLで議論するので難しい

    エタらないための技術力 – @kjirou

    • エター
      • エターナル – 開発中止的な意味
    • 開発 -> エターの繰り返す
    • エタるパターン
      • 既存部分の設計に不整合や不便な点がでる
      • バグに追われると開発が進まない
      • とりあえずリリースまでと言い訳をして変な設計を残る

    元々の開発体制

    • 外部モジュールを使わない
    • テストなし
    • 自前のSVNでソースコード管理
    • Windows

    個人開発のイメージ

    • Windows
    • FTP

    改善

    • 外部モジュールを利用
      • npm /bower/ 対応してないものをベタ置き
      • 40コぐらいいれた
      • 使わなくなったのは3つぐらい
    • テスト
      • 設計変更のリファクタリング のためのテスト
    • Github
      • コスパ的に使わない理由
      • 外部素材を含む場合は基本的にプライベース
      • => bitbuckets
    • Mac
      • 技術記事がMac前提のが多い
      • 経験上仕事も mac前提が多い
      • Macにしておくと楽
    • モジュール公開
      • モジュールとして分離出来そうなものを公開
    • 結果
      • 3ヶ月しか保てなかったやる気が継続するようになった
      • 1ヶ月ぐらいメンテしてないけど、普通に回収できた
      • 同時に仕事にも生かせる技術が手に入った
      • 痛い思いをして、それを技術でかいけつした経験が手に入った

    個人開発者へ送るカンファレンス運営のススメ – @OE_uia

    • Japan Scala Association という普及する団体

    方針

    • 仕事で作るもの
      • ユーザーが欲しているもの
      • 技術的に簡単なもの
      • KPI、数字
    • 趣味で作るもの
      • オキュラス

    個人開発者の醍醐味

    • 好きな言語を選べる
    • 好きな時間に働ける
    • 好きなように働ける
    • 失敗しても成功しても全て自分の責任

    カンファレンス運営

    • Scala Matsuri
    • 運営はやることが沢山
      • ウェブサイトのメンテ
      • スポンサー受付/営業
      • 広報
      • 会計、各種届け出(スポンサーが法人相手じゃないとやらないケースある)
      • ゲストとのやりとり
    • 個人開発を支える技術(開発以外) – フリーランス
      • 一人企業とカンファレンス運営の類似点
      • 届け出や営業とか似てる

    個人開発とマネタイズ – ninjinkun

    • 個人でスマホアプリ開発して儲けようとチェレンジした話
    • FeedBack ブログの評判可視化アプリを作った
    • アプリの売上は多分10万以下
      • 月2000円ぐらい入ってくる

    儲け

    • 賞に応募したら10万円入ってきた

    ブログのマネタイズに

    • アドセンスの代わりに、自分のアプリの広告を貼る
    • 開発者がアプリの広告を自分に出すのは自然

    自宅サーバする話

    • クラウドは容量が足りない
    • 自宅サーバなら大容量
    • コンテンツ
      • 音楽
      • 漫画

    自宅サーバ

    • 手間が凄い
      • USBでOSセットアップから始まる

    漫画

    • Subcomic
      • zipを分解してjpegで返す
      • prefetchする

    その他

    メモ : Markdown

    • Scalaがコンパイル遅いは定番の話題
      • いいマシンを使いましょう
    • LLVM IRの話をした
      • *-llvmはフロントエンド、ミドルエンド、バックエンド どこを示したプロジェクトなのか分かりにくい問題
      • pypy.js
      • LLVM JITとは何か?
    • 心理統計学の話をmizchiさんに聞いた
      • 検定の使い道とか

    0 0

    QuickStart

    QuickStartというのは、名前がややこしいですがSpotify社が出してるツールのことです。

    このツールはCommonJSで書いたJavaScriptのモジュールの依存関係を解決してビルドしたり、ローダとして使えるものです。

    前者のビルドする機能は簡単にいえばBrowserifyです。

    QuickStartもBrowserifyと同じく、nodeのcoreモジュール等をブラウザで使える様になってます。(CoreモジュールはBrowserifyが使ってるものと同じshimが使われてる)

    もう一つの**ローダ**として使えるのがこのQuickStartの面白い所なんじゃないかなと思います。

    この記事では、適当に試して見たQuickStartの使い方について見ていきます。

    サンプルプロジェクトは以下に置いてあります。

    ビルド

    ビルドする場合はBroserifyと同じようにentry point(始まりとなるjsファイル)を指定してビルドするだけです。

    Entry Pointにかかれているように、デフォルトでpackage.jsonのmainが自動的にentry pointとなります(オプションで指定も出来る)

    そのため、以下のように書けばビルド出来ます。

    quickstart > bundle.js
# ==
quickstart --main index.js > bundle.js

    azu/quickstart-exampleのサンプルプロジェクトだと、
    browserifyとquickstartそれぞれのビルドが以下のように出来るようにしてあります。

    npm run build-q # build with quickstart
npm run build-b # build with browserify

    ビルドオプション

    command line interfaceで幾つかビルドオプションが設定できます。(オプションファイルを用意して指定もできる)

    • --compressで minify
    • --source-mapでsourcemapの生成(browserifyの-d)
    • --astで JavaScript ASTを出力
    • --transforms ASTベースの変換プラグインを指定する(browserifyの-t)

    QuickStartのtransformsで指定して使うプラグインは SpiderMonkey AST based Plugin systemという事で、ASTを変換するようなモジュールを指定して使います。

    また、--astというオプションをつけてビルドすると、依存してるモジュールを含めたコードのJavaScript ASTを生成してくれます。

    この辺何か面白いことが出来そうだなーと思いました。

    JavaScript ASTについては以下を見ておいて下さい。

    ローダ

    これが、QuickStartのメイン機能だと思っているのですが、
    QuickStartは自身をローダとして使うことが出来ます。

    どういう事かというと、以下のURLにChromeでアクセスしてChrome Dev Toolsを開いて見るとrequireで読み込むモジュールを読み込んでいる様子が分かると思います。(このローダはローカルで使うことを想定してるはずなので、プロダクトはビルドしてものを使うと思います)

    http://azu.github.io/quickstart-example/

    ワザといらないものも大量に読み込んでるのでかなり遅いですが…

    gif

    ローダとして使う場合は--selfオプションを指定します。

    quickstart --self > bundle.js

    とやると、ローダとしてのスクリプトが出力されます。

    そして実際にアクセスした時に、package.jsonのmain等を解析して動的にrequireで使ってるモジュールを解決していきます。(AMDみたいに動的ロードじゃなくて最初のフェーズで全部やるはず)

    ローダとSource Map

    ローダとして使った場合、Source Mapの生成も動的に行います。(自動的に有効になるようです)

    そのため、ローダとして使った場合も元々のモジュールに対してブレークポイントを打ってデバッグしたり出来ます。

    これは Source Mapを扱う関連ライブラリのまとめ | Web scratchでも書いてましたが、動的にSource Mapを生成してsourceMappingURLにBase64エンコードしたものをいれるようです。

    サンプルプロジェクトでは、QuickStartとBroserifyで大体似たような事すると以下のようになるはず(ローダとして使えば、監視してビルドするの代わりになる)

    npm run quickstart
npm run watch # == broserify -d

    ローダとして使った時、コードを変更した場合でもビルドをしなくてもリロードするだけで良くなります。(これが名前の由来なのかな?)

    • ローダとして使う ≒ RequireJSを使った動的ロード
    • Browserifyのようにビルドして使う ≒ r.jsでのビルド

    というイメージが近い感じがします。

    まとめ

    CommonJSで書いたものをビルドしてブラウザで実行出来るようにビルドするツールはmichaelficarra/commonjs-everywhereやBrowserify等があります。

    QuickStartはビルド機能とローダとして使える機能があります。

    AMDのように初めてアクセスした時にロードする遅延ロードはCommonJSの仕様的に難しそうですが、ローダとして使うことでビルドする必要なく開発を続けられるようになっています。

    transforms系の機能に依存しなければ、BrowserifyとQuickStartどちらでもビルド出来るものを作るのはそこまで難しくない気がします。

    名前がわかりにくいので改名して欲しいです。

    ちょっと触った感想は以上です。


    0 0
  • 07/05/14--08:00: About

    • 連絡先はinfo@efcl.infoです。

    メールは苦手なので、Twitterでmentionしてくれたほうが返事は早いと思います。

    Twitterアカウントは @です。


    0 0

    移行

    http://efcl.info/はドメインとかはそのままで、 WordpressからJekyllベースのブログに移行しました。

    ユーザーへの影響

    efcl.info 自体は自動で記事のURLも同じで大体同じようなページがあり、 RSS Feedもそのまま継続して利用できると思います。

    何かRSS周りとか問題ありましたら、 コメントか efcl/efcl.github.ioにissueを立てて下さい。

    Jekyll

    Jekyll なのでいわゆる静的サイトです。 そのため、検索とか月別のアーカイブ等必要最小限になってます。

    また、このサイトはGitHub Pagesで動いています。

    記事の修正点などはそのままPull Requestしてくださると嬉しいです。

    記事の Edit on GitHubとか 修正リクエストをするから直接編集してPull Request出来ます。

    img

    仕組み

    基本的にはJekyllそのままでテーマとか色々書いたぐらいです。

    Githubのデフォルト機能として、masterに置いたJekyllを自動でGithub Pagesにビルドしてくれる機能を利用しています。 (gh-pagesブランチを作らなくてもいい)

    しかし、Github Pagesでは--safeが有効になってるのでプラグインは使えません。(そのかわり楽でビルドも早い)

    そのため、やや複雑な部分はメタ情報としてのJSONを作ってJavaScriptでUIを作っています。

    記事数でのソートカテゴリ

    →記事数でのソートカテゴリ

    関連記事の表示

    →記事数でのソートカテゴリ

    タグ一覧 | Web Scratch

    などがJavaScriptで動いてたりします。

    頑張ればJekyllのテンプレートでもできる気がしますが、ビルド時間が増えそうなのでJavaScriptでしておきました。

    既知の不具合

    • http://efcl.info/adiary/にあったadiaryベースの記事が現在404になってます。
      • adiaryにHTMLエクスポート的な方法があったら教えて欲しいです…

    追記

    最初は azu/azu.github.ioという、 いつも使ってるアカウントのGithub pagesとして作成していましたが、 これだと、 http://azu.github.io/promises-book/みたいな他のリポジトリにあるものも 全部 http://efcl.info/promises-book/に移行してしまいます。

    正直このケースはメリット無い気がするので、別途Organizationを使って、 Organization Pagesとして動くようにしました。

    リポジトリをTransferしてちょっと書き換えるだけで済むので比較的楽です。


    0 0

    前回、Jekyllベースのブログに移行しました。 | Web Scratchで WordpressからJekyllへと移行しました。

    その時に、benbalter/wordpress-to-jekyll-exporterを使い Wordpressの記事をJekyllのMarkdownファイルとしてエクスポートしたものを使いました。

    このエクスポートしたファイルは何故か日本語などはURLエンコードされたものになっていて、 動作的には問題ないですが、表示的に気持ち悪いのでURLデコードしてファイル名にそのまま日本語を使うように変更しました。

    以下のようなシェルスクリプトを書いて *.mdのファイルを対象にファイル名をURLデコードして戻しました。

    #!/bin/sh

find * -type f -name "*.md" -print0 |while read -r -d '' file;dodecorded=`echo"$file"| nkf --url-input`
   mv "$file"$decordeddone

    これで、記事ファイルを一覧した時にパッと見て分かりやすくなった気がします。

    screenshot

    Jekyllのブログエディタみたいのでいい感じのものはないのかなー(今はWebStormを使って書いてる)


    0 0

    天下一クライアントサイドJS MV*フレームワーク武道会 - connpassに参加してきたのでメモ。

    Chaplin - mizchi

    • > Chaplin.jsの話 #ten1club // Speaker Deck
    • 仕事で使ってる
    • Chaplin
      • paulmillr作のBackbone拡張系のMVC
      • Rail風の構成
    • Chaplinの設計
      • Rails風のルーター
      • インスタンスの管理するComposer
        • Controllerと強調してインスタンスを管理
        • 差分管理できるので早い
        • 逆にインスタンスを引き継ぐので意識しないと辛い
      • スキャフォールディング
    • Generator
      • MV*だとやたらファイルが増える
      • scaffolt はChaplinとは関係なく使える
    • Brunch
      • ウェブアプリに特化したビルドランナー
      • CommonJS風の展開
      • npmで拡張子に応じたプラグインを使う
      • Gulp/Gruntと競合するので乗っかれない
    • Chaplin.jsの悪い点
      • シングルトンのmediatorがテストしにくい
      • テストがない
    • Backbone.stickit
    • mocha-phantomjsでテスト
    • 学び
      • ディレクトリ構成が規約になる

    vue.jsの話 (@kazupon)

    • > Vue.js // Speaker Deck
    • Seedという名前で0.6でVue.jsにリネーム
    • Simple
      • mustacheテンプレートとデータバインディング
    • Fast
      • Batcherによる非同期的なバッチ処理
    • Composable
      • ViewModelをコンポーネントとして登録
      • モデルをモジュール化して再利用できる
    • Compact
      • 14KBぐらいで小さい
      • 外部ライブラリに依存してない
    • Powerful
      • テンプレート上で計算したりできる
    • プラグイン
      • Vue.jsを拡張したい人向けのプラグインするAPIがある
      • Vue.use
    • Vue.jsの今後
      • nextブランチで0.11の開発開始

    ripple.js(とcomponent関連)の話 (@tajima_ｊ)

    • reactiveなViewを提供するフレームワーク
    • ripplejs/ripple
    • 今年0.0.1を持ってる
    • Reactと似てる(サンプルコードも同じ)
    • Viewをpluginで拡張出来る
      • eventsプラグインを利用しないとonclickとかもできない
    • rippleはcomponent/componentが基盤
    • compoent
      • Githubを基本のリポジトリのクライアント向けのパッケージ管理
      • 基本的にripple.jsはcomponentと一緒に使う
      • rippleのプラグインとcomponentは相性がいい
    • 現状のripple.jsとこれから
      • 0.5の変更が多い
      • ドキュメントが少ない

    knockoutjsの話 (@tenntenn)

    • KnockoutJSとは
      • 双方向バインド
      • View <-> ViewModel どっちが変わっても変わる
      • いろいろなバインディングが用意されてる
      • computed
        • 2つのobsesrverに依存したものを処理するような感じ
    • プロジェクト規模
      • WebViewアプリ
      • コード量 : 数十万行
    • つかいどころ
      • カスタムバインド作って処理を簡潔に
    • KnockoutJSを選んだ理由
      • コールバックが少なくなる
      • 他のフレームワークと一緒に使える
        • 薄めのフレームワーク
      • 独自タグをつかっていない
        • 全部data-bind等の属性
    • KnockoutJSで辛かった点
      • バインディングする量が多いと重たい
      • data-bind属性が大きくなりすぎる
      • ifとifnotバインド等記述が冗長

    5分で分かるmarionette.jsの話 (@koba04)

    • > 5分でわかるMarionette.jsのいいところ // Speaker Deck
    • 最近2.0になった
    • 何で選んだか
      • SPAを最初Backbone.jsだけで実装
      • ネストしたView構造の管理を書いた
      • marionette.jsと大体似たことやってる
    • ネストViewをサポート
      • RegionとRegionMangerがある
      • 破棄とか自動でやってくれたり、renderも呼ぶ必要ない
    • 各Component毎にViewを作る
      • ロジックレステンプレート
      • Viewが多くなる
    • ソースがキレイ
    • まとめ
      • Backbone.jsからの移行コストは低い

    「marionetteからractiveへ、そしてXXXへ」 (@lxyuma)

    • > Marionetteからractiveへ - lxyuma BLOG
    • 使用してきたフレームワーク変遷
    • Backbone.js
    • Marionnet.js
      • 色々やることが多い
      • Backboneよりまし
      • だけど大変
    • Ractive.js
      • Viewだけ完全にractive.js使うようになった
      • Backbone.View等がいらなくなった
    • ハマる事が少ない
      • ractive.getはpureなオブジェクトがない
      • 学習ことは少ない
    • マイナー感
    • 今はRactive使ってない
      • バニラJSで書いてる

    にわかangulardart(@nyamadandan)

    • > にわかのAngularDart - Google スライドb
    • Dart
    • AngularDart
      • AngularJSをDartにポーティング
      • フルスクラッチ
      • WebComponentsを使ってる
    • カスタムタグ
    • KnockoutJSとの比較
      • KnockoutJSみたい関数を実行する必要がない
      • KnockoutJSほど気軽に使えない

    AngularJS x designer (@silver_s)

    • > angular X designer - デザイナからみたAngularJS #ten1club
    • デザイナにアプリを作ったもらったはなし
    • エンジニアとデザイナの分業フレームワークとして
    • JavaScript触ったこと無いひとにやってもらった
    • AngularJS
      • 設計や実装の自由度が低い
      • それが逆に規約的になる
    • 分厚い - フルスタック
    • HTMLだけでもいい感じに操作もかける
    • ngClick, ngTouch...などもHTML側にかける
      • こういう条件で表示みたいのもデザイナが書ける
    • 自覚directive
      • エンジニアが用意
    • 辛い点
      • 内部のロジック -> 暗黒
        • 死ぬのはエンジニア
    • まとめ
      • ViewとController自体はデザイナでもいけた
      • モデルとかはエンジニアが頑張る
      • ngAnimate, ngClassの虜
      • アニメーション増やしすぎる

    React + Fluxの話 (@dsuket)

    • > React.js + Flux
    • React
    • Just The UI
      • 単なるView
    • Virtual DOM
    • Data Flow

    • ReactiveProgramming

      • データフロー指向プログラミングのパラダイム
      • 値は動的に決定される

    • React + JSX

      • オブジェクトでもDOM作れる
      • JSX使ったほうがDOM構造が分かりやすい

    • Flux(アプリケーションアーキテクチャ)

      • MVC doesn't scale
      • Viewにreact
      • Dispatcherでイベントの順序を管理
      • フローを1方向にする

    Omの話 (@tfukushima)

    • > Om
    • swannodette/om
    • Reactと違う点
      • Undoが簡単に書ける
      • ウェブでもUndoが使う機会が増えてる
    • ClojureScript
      • 差分だけの情報が簡単にhookして取れる
      • Clijureが良い
      • ライブラリが良い
      • マクロ良い
      • LinkedList
        • Gitっぽいモデル
        • GET UNDO NOW

    パネルセッション

    SPA

    • 初期化に時間を取れるかどうかで選択できるか変わる
    • Kintone
      • 部分SPA
      • レガシー部分はページごとに別れてる
      • 最近出来た部分はSPA
    • ゲーム
      • 部分SPA
      • メモリリークがあると辛い
      • 適当なタイミングでメモリ解放したい
    • CodeGrid
      • SEOの問題
      • 最近Google自体がJavaScriptも解釈するようになってきた
      • Google以外にもはてブがタイトル取れないとかの問題もある

    Isomorphic

    • Meteorさんが悪い印象を作ってしまった?
    • サーバとクライントで同じロジックを使いたい
    • 夢がある
    • そもそもNode.js自体がビジネスロジックがだるい
    • ロジックは他で、Viewに近い所はNodeに持ってくるとか

    差分レンダリング

    • シングルと差分のレンダリングはやり方違う
    • その辺をIsomorphicなものが解決して欲しい

    使ってるフレームワークで最悪な所

    • Marionet
      • モジュールとrequireがぶつかる
    • Backbone.js
      • ルーターが微妙
      • ngRouterがよりつらい
    • Chaplin
      • reuseの判定がシビア
      • インスタンスの引き継ぎが大変
      • ジェネレーターをプロジェクトの進行と共に作っていく
    • Closure Library
      • モデルに対するバインディングが最近のMV*の要件
    • AngularJS
      • ngRouteが辛い
      • ServiceやFactoryとか自由すぎて、使い方が難しいngRoute
      • ngRouteのいやなとこ。
      • routeがやること多い。
      • ng-viewと紐付いてるので、まるっと書き換える困ることが出てくる。(スクロール一の記録とかしたいときに困る)

    WebComponents

    • http://www.polymer-project.org/tools/designer/みてどうなってるんだろこれ
    • Polymer - WebComponetsに載ってるライブラリ
    • 銀の弾丸話
      • JavaScriptの問題を解決するコンテキストではない
      • CSSの方についての銀の弾丸
      • CSSのスコープを取れる
      • 今は命名規則(BEMとか)で頑張ってる
      • Polymer ≠ WebComponents polyfill

    他のGUI環境と比べて足りない所

    • 永続ストレージが足りない
    • リソース管理が足りない
      • disposeとかその辺
    • window.gcが欲しい
    • 集団になるとルールがない

    モジュール

    • AMDはない
    • 現状だとCommonJSが分かりやすい
    • 将来的にはES6 moduleかな
    • Browserify
      • 遅延ロードは明示的に書く
      • ライブラリレベルとかの分離なら遅延ロード出来る
    • CSSとかも一緒にパックしたかどうかで使えるものが別れる
    • 遅延ロードを扱えるかどうか?
      • AMDはモジュールレベルの遅延ロードができる
      • Webpackの遅延ロードも結局は関数で呼ぶ定義を使う

    テンプレートエンジン

    まとめ

    • AMDはやめておけ
    • 規模とか人に違うよ

    その他

    懇談会


    0 0

    ブラウザエンジン先端観測会

    ブラウザエンジン先端観測会 : ATNDに参加してきたのでメモ。

    途中から参加なのでServoの話は途中からです。

    Twitterのログはこちら

    Servo (by Tetsuharu OHZEKI a.k.a @saneyuki_s)

    • ACID2は通った
    • Servoのレイアウトの計算
      • ボトムアップの場合
        • 子供のノードは並列に計算する
        • 全ての計算が終わった時に親に行く
      • トップダウン
        • もっとシンプルに親からやっていく
      • floatの話
        • floatの影響を受けるものはフラグを立てる
        • フラグが立ったものは遅延的に計算する
        • floatの計算終了後に再度計算する
        • = assign height
        • 遅延的にやるのは、同計算していいのか分からないため
      • overflow
        • Block format contextのこと
        • assign-widthの時に仮定を指定widthをやっていく
        • 大体でやっていく、Blockとしてやれると仮定
    • DOMのライフサイクル管理の一本化
      • 過去の事例 - DOM.js
        • DOM.jsというJavaScriptでDOMかいていいじゃね => メモリバカ食い遅い => 失敗
      • 現在 - SpiderMonkeyのGCに任せて管理
      • GPUでのセレクタマッチング
      • Intelの一時メモキャッシュ早いということがわかった
    • まとめ
      • ACID2は達成
      • 大体アーキテクチャできた
      • Samsungの人がどっかいった
        • 以前はTableレイアウトとか頑張ってた
      • NO PLAN
        • 何も考えずにつくってる

    アクセシビリティオブジェクトが作られない場合（by @Takenspc）

    • スライド: アクセシビリティオブジェクトについて

    • ブラウザのHTML5対応コンテキスト

    • アクセシビリティAPIについて

    • アクセシビリティオブジェクトとは何か

      • Access + Ability = アビリティ , A11Y

    • ウェブへのアクセス

      • 画面をみれなかったり
      • マウス、キーボードじゃなくてタッチスクリーンだったり
      • 音声入力だったり
      • ウェブへのアクセス方法も色々ある

    • 支援技術

      • Assistive Technology
      • 特定の技術を使いやすくする
      • そのままで行えないものを出来るようするための製品、ツール、デバイス

    • 支援技術のデモ

      • 「オープンオペラ」 in Mozillaオフィス
      • ブラウザが対応してるから音声入力で操作できる

    • アクセシビリティAPIの特徴

      • アクセシビリティAPiの語彙、セマンティックはHTMLとは違う
      • ブラウザ専用じゃないので
      • ブラウザがコンテンツをアクセシビリティオブジェクトに変換して利用する

    • ブラウザはコンテンツを支援技術に伝える

      • コンテンツをアクセシビリティオブジェクトに変換する

    • アクセシビリティオブジェクト

      • 役割 : 種類(role) ≒ HTMLの要素
      • 状態 : 動的な属性 - チェックされてるとか、ボタンが押されてるとか
      • プロパティ : 静的な属性
      • その他
        • 位置や大きさ、関連要素、文字の大きさ色

    • アクセシビリティオブジェクトを作るには

      • DOMツリー + レンダリングツリー => アクセシビリティツリー
      • アクセシビリティツリーをプラットフォーム別のアクセシビリティツリーに変換
      • 変換したアクセシビリティツリーを支援技術に伝える

    • (Gecko)DOMからアクセシビリティオブジェクトの作成

      • 非表示だったらオブジェクトは作らない
      • WAI-ARIAを見てやる
      • HTML要素だったら型や属性を見る
      • それでも出来ない場合はFrameの種類(レンダーオブジェクトから)からオブジェクトを作る

    • Webkit/Chromeのアクセシビリティオブジェクト

      • レンダーツリーをイテレート
      • レンダーツリーからやっていくのが基本的な流れ
      • CanvasはDOMをみる
      • WebCoreとBlinkは色々特殊
        • ノードのWAI-ARIAや種類を見る
        • ノードがWAI-ARIAのグリッドのケースの処理
        • roleの決定が複雑
      • Roleの決定
        • WAI-ARIAを見る
        • レンダーオブジェクトのboxの種類を見て判定するコードを並ぶ
        • レンダーツリーの隣接レンダーオブジェクトを見ていく

    • HTML5対応とは何か

    • アクセシビリティオブジェクトの調査

      • どうやってブラウザが対応してるのかをチェックするか
      • チェックツール
        • プラットフォームのアクセシビリティツリーをチェックするツール(プラットフォーム固有)
        • 内部的なアクセシビリティツリーをチェックするツール(ブラウザが持ってる)
          • DOM Inspector
      • 期待と違う結果
        • そもそも対応してないケース
        • レンダーツリーが影響してる場合
        • HTML5と一対一対応ではない => フラット化してる

    • フラット化

      • アクセシビリティオブジェクトはツリー構造
      • 重要と判断したノードに対してだけ見せる(=ユーザーに伝える)
      • 重要かどうかはブラウザが判断する
      • HTML要素と一対一対応だと意味ないネストが発生する(装飾目的)
      • そのためフラット化してシンプルにしていく

    • WebKitのバグ

      • 支援技術に見せるかどうかでの判定があまい
      • 見せるべきものを伝えない場合がある

    • まとめ

      • ブラウザにはHTMLに対応したアクセシビリティツリーを作る責務
      • HTML5対応にはアクセシビリティAPIの側面を含めて考える必要がある

    CSS JIT (by @Constellation)

    • スライド : CSS JIT: Optimizing CSS Selector Matching with Just-in-Time Compilation // Speaker Deck

    • 関連記事 : Surfin' Safari - Blog Archive » Little overview of WebKit’s CSS JIT Compiler

    • WebKitコミッター

    • モチベーション

      • CSSセレクタはものすごい回数が実行される
      • この要素にはこのスタイルを当てるというだけでも多い
      • QuerySelectorでも大量に行われる
      • .rabitt .house{ }というのだけでも全ての要素に対してやっていく必要がある

    • QuerySelectorの実装

      • rootから全ての要素を列挙する
      • 一個一個セレクタにマッチするかどうかを確認
        • 現実的に動いてるのはC++が早いだけなのでは
      • return マッチしたものを返す

    • CSS JITのゴール

      • セレクタマッチングを高速化するのは重要な意味を持つ
      • あるセレクタが与えられた要素にマッチするかを返すpredicateの高速化

    • 現在の高速化実装

      • C++実装
      • セレクタを div と ~ という感じに分ける
      • ~や+は関係性を示すもの(combinator)
      • div 単純な子孫、desendant(simple)
      • => 合わせてcompound selector

    • CSS Selectorの基礎

      • descendantから親を辿る列は常に一定になる (子 -> 親 -> 親)
      • CSSセレクタは右からマッチしていく

    • div> のケース

      • 子(div) -> 親を見て間違ってる時、そこで探査は終わる
      • > は子なので、親がdivじゃない時で探査はやめていい

    • バックトラッキング

      • セレクタのマッチを確認して行った時に間違ったマッチが起きた時にバックトラックをする
      • 間違っていた場合はdescendantに戻ってマッチを再開
      • マッチに失敗した時、次にマッチを再開するときにマッチの候補は少なくなるはず
      • そういう仮定をして、 section > div＊1 div＊2 spanという時
        • ＊1で間違ってた時に、＊2の方をずらしたりしない
        • 余計なバックトラックだとわかってるので、div＊2にマッチする要素を再度探索するところからはやらない
        • ＊1に関してを探索していく

    • CSS Selector JIT

      • セレクタのマッチングをJITをしていく

    • マッチングコードのコンパイル

      • バックトラッキングを開始する時
      • descendantに戻る
      • descendantはレジスタのどこにあるのか分かってる
      • そのため、レジスタにある一個前(descendant)へjumpすればいい
      • 関数コールとかが必要なくなる
      • これでバックトラッキングが高速に出来る
      • バックトラック用のレジスタが1つでいける = スタックに積んでいない
      • バックトラックで必要なのは最後に見たやつだけ
      • ステートマシンみたいなジャンプするコードが吐かれてる

    • アセンブラで見るCSS JIT

      • spanとかの文字列はatomic、ポインタで持ってくる
      • 直接cmpして比較、jnzでジャンプ
      • parentを見た時に、null pointer = rootまできちゃった
      • textノードじゃなくてelementかどうかを testでチェック

    • More intelligent バックトラッキング

      • ul > li > p span
      • ulが失敗した時、子供のelementとして pや spanを持ってる事を知ってる
      • そのため、spanのチェックを省けて再開する
      • つまり保存する1つのレジスタを削れる + 無駄なバックトラッキングを1つ減る
      • 親をlookupする処理は重い = ノードは適当に作られるのでメモリの分布がバラバラでキャッシュ効率が悪くて、ジャンプするコストがある
        • バックトラッキングがひとつ減る効果はある

    • ステータス

      • x64 / ARMv7s(nthでの計算命令) / ARM64 バックエンド 等に対応してる

    • まとめ

      • CSS Selectorのマッチングコストは大きいので高速化できる
      • 普通にやっていくとドンドンスタックを積んでいくので遅くなる
      • CSS JITでは最小限をレジスタに置く、関数コールを省いてジャンプコールだけでやれる
      • より賢いバックトラッキングをやっていく

    • Q&A

      • Q. 全てのセレクタが対象?
      • A. 7割ぐらいは対象、擬似要素、擬似クラスは対象外、今後やっていく
      • Q. :hoverとか :activeとかも効率的?
      • A. element自体にそういうフラグが入ってるので、CSS JITで高速化の対象になる
      • Q. 並列?
      • A. 今はシーケンシャルな性能についてを検証、実装
      • Q. JITコンパイルしたコードの容量の問題はないの?
      • A. JsCoreのインラインマクロでJIT生成するので、基本はそっちが破棄とか自動でやってくれるので気にしてない。
      • ある程度自動的に解放してくれたりをやってくれる
      • Q. CSSセレクタ自体の最適化やってる?
      • A. 常に失敗するというケースはスグにFAILさせるというのはある。
      • 静的に失敗するケースが分かるものはその時点で捨ててる
      • Q. atomizeするタイミング
      • A. JSでタグ作った時とかCSSパースした時とか出てきた時に何でもatomizeしていく
      • https://twitter.com/objectxplosive/status/488229099177930753
      • Q. descendantだけ?
      • A. 隣接とかも同じような仕組みでやってる
      • descendantとsibling等でグルーピングしてマッチングのバックトラッキングはやる
      • siblingが並ぶパターン自体が少ない
    • メモ
      • omnioutliner

    0 0

    非活性なGitHubアカウント

    Githubでpecoのアカウントを融通してもらった件 : D-7 <altijd in beweging>という記事を読んで、GitHubにメールすればInactiveなアカウントを削除してもらうことができるということを知り、同じことをやったという話です。

    JSer.infoというブログをTumblrでやっていて、 efcl.info(このサイト)と同じようにJekyll(+Github Pages)の方が適してるじゃないかと思って、移行を検討していました。

    GitHub Pagesに独自ドメインを当てる場合、GitHubのorganizationアカウントを取ってそこでやるのが楽だという事はわかっていたので、 JSer.infoむけに jserというGitHubアカウントを取ろうとしていましたが、既にアカウントは取られていた状態でした。

    元のjserアカウント

    元々あった jserというアカウントは、リポジトリが1つだけあってコミットがひとつもない、ただ取得しただけというInactiveなアカウントだったので、 最初に紹介した記事を思い出しました。

    補足: Organizationアカウントじゃなくても独自ドメインで運用できる事については @haya14busa さんが詳しく解説して下さいました。

    メールを送る

    Contact GitHubからフォームでも送れるのですが、 直接、supportあっとgithub.comの方にメールしました。 (メールのほうが返信が来やすいとかみたのと、実際フォームで送って返信こないケースを経験してたので試しに)

    以下のような感じで送りました。 大分、つらい英語になってるので添削した見本下さい。

    Hello, My name is azu.
My GitHub account is https://github.com/azu/.

I want to get "jser" for organizations account.
I'd like to use the account for https://github.com/azu/jser.info and http://jser.info/.
(I will move http://jser.info/ to github-pages from tumblr in the near future)

Currently, "jser" is already token, but the account is inactive.
Please remove dusty "jser" account.

Thanks.

    返信は以下のような感じで、Name Squatting Policy · GitHub Helpにしたがって jserのアカウントを解放したよときました。

    この時点ではアカウントを解放されただけなので、この後はまた早い者勝ちです。

    Hi Azu,

You are in luck — we have classified the jser account as inactive and released the username for you to claim, as per our Name Squatting Policy:

https://help.github.com/articles/name-squatting-policy

Be quick, as the username is now publicly available. Glad to help!

Cheers

    GitHubのName Squatting Policy

    上記の返信にもでてきましたが、GitHubにはName Squatting Policyがあり、 放置アカウントは連絡すれば解放してくれるクールなポリシーがあります。

    使いたいアカウントが放置アカウントだった場合は、一度問い合わせしてみるといいのかもしれません。

    Bitbucket

    競合サービスのBitbucketはどうなんだろと思って調べてみると以下に書いてありました。

    基本的にアカウントを解放することはないそうです。

    Bitbucketの場合は、無料でもプライベートリポジトリを無制限に作れて、一見Inactiveに見えてもそうじゃない場合が多いと思うので、 GitHubみたいにサクッとやるのは難しいので妥当な感じがします。 (問い合わせてきた人にはInactiveに見えるけど、プライベートで使われてて、Bitbucket側がそれはInactiveじゃないと伝えてしまうのは問題がありそう)

    おわりに

    JSer.info の方は下記に詳細を書きましたが、今後Jekyllに移行していく予定です。

    まだ全然作業進めてないので、 Jekyllのテーマとか、アイコン(GitHubのアカウント用)とか協力してくれると嬉しいです。


    0 0

    この記事では自分なりの勉強会でのメモの取り方についてメモしたものです。

    今までに参加してきたイベントでは、 大体メモを取っていて"〜アウトラインメモ"とかいうタイトルで公開してあります。

    書くツール

    メモを取るにはエディタとかツールが結構大事で、書くのに集中し過ぎると話をちゃんと聞けないし、 話に集中してるとメモを書かなくなったりします。

    なので、画面を見なくても入力できるような手に馴染む感じのツールを見つけて使うのがいいと思います。

    以下が使ってきたツールの変遷ですが、出力は常にMarkdownにしていたので、 基本的にはMarkdownエディタが中心となってます。

    アウトライン的に使う場合、MarkdownエディタだとMouが安定して使いやすい方だと思います。

    今だとMouの後継を目指して開発してるMacDownとか面白いと思います。

    基本的にリストで書いていくので、-が自動で入るとか、Tabを押した時にリストもインデントしてくれるかが、 入力のテンポの大きく関わってくるのでエディタは馴染むものを選ぶといいかと思います。

    - リスト
    - 書いていく
    - と思うので
- リストマークの自動入力が大事

    上に載せてないですが、Day Oneとかがこのリスト周りの動きの出来がいいと思います。 (iOS版もアウトラインに絞ると中々いい感じ)

    dayone

    後、最初の頃はQute for PC/Macというのを使っていて、 このアプリは幻のChromeless Browserを使ったHTML/CSS/JSのアプリです。

    普通のエディタとちょっと違って改行でそれぞれブロックが別れる感じになっていて、 カチッとハマると見た目もキレイで結構良かった記憶があります。(ものすごく癖があるので使いやすくはない)

    Qute

    この辺は慣れてる/好きなエディタを使えばいいと思います。(普通にAtomとかVimとかの方が何だかんだ自由度高い)

    最近になって、そもそもアウトライン的に書いてるんだからアウトライナーを使って書けばいいじゃんという事に気づいて、 OmniOutlinerを使い始めました。

    OmniOutliner

    omnioutliner

    OmniOutlinerはアウトライナーなので当たり前ですが、タブでインデントレベルの変更ができることや、 CONTENTSに表示する部分をフィルターしたり、入力は結構快適です。

    gif

    欠点

    OmniOutlinerは、 Markdownに対応してない以外は使いやすいですが、そもそもMarkdownのエクスポートに対応していません。

    fletcher/Markdown.ooxslというプラグインが一応あるのですが、ちゃんと動いてな気がします。

    HTMLやtxtやwordなどエクスポートできるのですが、機械に優しいフォーマットがOPMLしかないため、 OPMLとしてエクスポートしてそれをMarkdownに変換して使っています。 (一応OmniOutlinerのファイル自体がXMLなのでそれを見るという手段もある)

    OPMLをパースして(JSONにしてから)、Markdownに変換するNodeで書いたコマンドラインツールを使っています。

    opml-to-markdown -e file.opml --require lib/build-markdown.js # markdownに変換される

    これを使って作ったMarkdownファイルでCleaverのスライドを作ったりもします。

    生成したMarkdownを直接整えてブログとして公開するため、OmniOutlinerのファイル自体は使い捨てです。

    ツールの話はこの辺で終わりにして、まとめると好きなモノを使いましょうということです。

    なぜメモるか

    自分の場合は、大体スライドのページと喋ってるテーマに合わせてアウトラインでメモしています。

    - ページタイトル
    - ページについていってること
    - リンクとか
    - 喋ってることとか
    - 次のページに行ってもテーマが同じなら続ける
        - 更にネストすることもある
- 次の次のページのタイトル/テーマ
    - ほげほげ
- まとめ
    - ページ/テーマを塊としてアウトラインを作る
    - テーマで塊をつくるので、書く場所が前後することある
    - ネストの深さはあんまり気にしない!

    なので、発表聞きながらスライドを書いてるような気分になれます! (後述しますが、どれだけ手を抜くかが大切だと思います)

    そもそも何でメモしているかというと、自分の場合は3日経つと忘れるので、 忘れないためにメモるというのがあると思います。

    聞きながらメモって手を動かした方が感覚的に覚えていられる気がするし、後から見られるのが便利です。

    Twitterとメモ

    一言にメモといっても、上記のようにアウトラインで書くのが一応メインですが、 発表中にハッシュタグをつけてTwitterに投げるのもメモの一つだと思います。

    エディタで書くのと違ってTwitterに書いた場合は、時間と前後のTweetsからコンテキストが補完されるので、 普通にメモするよりも情報量的に優れてる場合もあります。

    また、エディタにメモを書きながら、必要ならそれをコピペしてTwitterにも投げると、 メモに時間軸の情報がつくので便利な事があります。

    どこに集中するか

    最初にも書いてましたが、書く事と聞く事のバランスを考えるのは結構大変ですが、 基本的に慣れというしか無い気がします。

    自分的な考えだと、"聞く"はしゃべる人のペースがあるので、こちら側で調整出来ませんが、 "書く"は自分でペースや量を変えられるので、"聞く"に合わせて書いていくのがいいと思います。

    例えば、多くの勉強会は後でスライド(大きめだとUstも)が公開されるので、 スライドに書かれている内容は別に細かくメモしなくてもいいですね。

    他にも色々書く手間は削る事ができると思います。

    • Twitterのハッシュタグを見て、誰かが分かりやすい事いってたらURLでメモする
    • イベントのスケジュールと発表内容は公開されてるので、事前にアウトラインに発表タイトルを並べておく
    • スライドが事前に公開されてるなら、そっからコピペする

    スライドに合わせてメモすると、スライドをめくるペースが早い人(mizchiさんとか)がメモ的に辛いので、 そういう時は気になる部分だけを書くとか諦めが肝心です。

    デモが中心だとあんまりメモる事がなくなりますが、 写真とか動画とかとっておくと便利なのかもしれないですね(あんまりしないですが、やっぱり後から見ると情報量が違う)。

    記憶からのメモ

    勉強会だとPCを開いているので普通にメモればいいですが、 飲み会とか懇談会的なものは皆PC閉じてる事が多いためメモしてないです。

    自分が 飲み会とか 食事とかに 参加すると なぜかLT大会が始まるため、 メモっておきたいことが良くあります。

    そういう時は、Twitterに適当に書いておくということをよくやります。 それを元に後からメモを構成し直すという事をやってました(大体帰りのうちにやっておかないと記憶が飛ぶのが難点)

    まあ、普通に疲れるので正直これはそういう意識でやらないと辛い。

    でも、先程も書いたようにTwitterになげるだけて情報量が付加されるのは便利で、 意外と飛び飛びでかいても後から記憶と合わせて補完できたりするので、記憶は不思議な感じです。

    勉強会の方も含めてTwitterに書くときに意識的にやってるのが、 話の区切りが変わったら書くということを良くしている気がします。

    勉強会なら、「発表テーマ - @アカウント」みたいな発表者区切りでTweetしたり、 飲み会的なものだと「〜のはなし」みたいな区切りのTweetを書いたりしてる事が多いです。

    こういう目印的な区切りがあると後から整理しやすいと思います。

    なぜ公開するのか

    基本的に非公開なイベントじゃなければ、公開しない理由は特にないので公開してる感じです。

    勢いでメモを書いて、大して整理しないで公開するので大量の誤字/脱字とか間違いもありますが、 公開して間違いの指摘がきたら直せばいいと思います。 (そこまで間違って深刻になる内容について勉強会だと話さないと思うので)

    typoについては正直諦めていて、アウトライン的なメモだとそこまでしっかり読む人もいないと思うので、 まあ気にしないほうがいいのではないかと考えています。

    またこのブログだと、GitHubから 修正リクエストを送れるので細かいことはやる気がある人が修正を送ってくれるかもしれません。

    後、メモを公開すると参加者や発表者がメモに対して補足等してくれることがあります。 そういうのが得られるのはメモを公開する利点といえると思います。

    レポートとかそういう写真がいっぱいでキレイな感じの内容は本職の人に任せればいいので、 雑なメモでも公開する意味はあるんじゃないかと思います。

    ブログ書くまでが勉強会なのでもっとメモを積極的に公開していくといいですね。

    以上でメモ終了です。

    • メモ
      • WebStorm

    0 0

    ニューヨークだより

    かなり前に、無料で読めて定期更新されているIT系の電子雑誌 | Web Scratchという記事でも紹介したのですが、IPAがやっているニューヨークだよりが面白いです。

    2013年度の途中で更新が止まっていましたが、2014年度が再開されています。

    例えば、7月号 米国におけるソフトウェア信頼性に関する取り組みの現状では、 色々なウェブサービスやソフトウェアに関する障害の事例について書かれています。

    医療保険制度改革の一環として開設された医療保険サイトである 「Healthcare.gov」の事例では、 オープン初日2013年10月1日には280万人以上がアクセスしたが、 数多くのバグのせいで実際に登録できたのがたった6人だけだった という単純に読んでいて面白い話も多いです。

    2012年度の1月号 オープンソースソフトウェアの動向では、 オープンソースとMSやIBM等の企業戦略についてなどについて書かれてたり、 ニューヨークだより2011年9月の コンシュマライゼーションについてでは、社員の私物端末の持ち込みとそれに対する課題について等興味深い内容が多いです。

    ニューヨークだより2011年11月 - ウェブ標準を巡る動向とか 見るとわかりますが、レポートに対して参照資料がかなり書かれていて、リソースがちゃんと載っています。

    普通に面白い内容が多い割にはあんまり読まれてない気がしたので紹介でした。


    0 0

    GitHub Releases

    GitHubには Releasesという機能があります。

    簡単に言えば、gitのtagに文章や添付ファイルを追加して公開出来るページです。 基本的にはgit tagと連携してるので、tagを付けてgit push --tagsをしていれば、自動的に追加されます。

    メリットとしては以下のような事が行えます。

    • git tagにパーマネントリンクがつく(重要!)
    • メッセージ(リリースノート等)が書ける
    • 添付ファイル(zip)をアップロード出来る(配布するバイナリとか)
    • RSS Feedsが自動的に生成される(TagとReleaseの2種類がある)
    • ライブラリ等にtagがついてると利用しやすい。

    git tagとGitHub Rleases

    git tagでつけたものが自動的にReleaseになるのは知ってる人が多いと思いますが、 この時にメッセージも自動的に入れることも出来ます。

    以下にサンプルのリポジトリを用意してあります。

    具体的にはgit tagを付けるときに-aと-mオプションでそれぞれタイトルとメッセージを指定出来ます。

    git tag -a "annotation title" -m "release message body"
    • -aリリースのタイトル
    • -mリリースのメッセージボディ

    demo

    GitHub Releasesのページは自動的にtagについてるメッセージを読み取って表示してくれます。

    NOTE

    微妙にバグっぽい挙動があって、この-mでつけたメッセージはMarkdownも指定は出来るのですが、 なぜかh1タグ等が無視されている気がします。 ただし、RSSなどにはちゃんと# titleなどがレンダリングされて表示されます。

    リリースとリリースノートの自動化

    汎用的なものはまだ無いですが、npm(node.js)向けには以下のようなツールを使うとgit tagとリリースノート(CHANGELOG)を自動的に生成出来ます。

    release-changelog <increment> [options]

    gif

    このツールはwebpro/release-itとajoslin/conventional-changelogをラップしたツールです。

    webpro/release-itはpackage.json等のversion更新とgit tagとnpm publish等を一括で行ってくれます。

    ajoslin/conventional-changelogはAngularJSの Git Commit Guidelinesにしたがってコミットを書くと自動的にCHANGELOG.mdファイルを生成出来ます。

    azu/release-changelogはこの2つをまとめたツールです

    • CHANGELOG.mdを自動生成
    • git tag -mにそのバージョンの変更内容を自動的に追加
    • release-itでtag付け+release

    release-changelogのオプションはrelease-itと全く同じです。

    これでReleaseした内容は以下で見られます。

    先ほど書いたように自動的にレンダリング部分があったりするのは若干微妙ですが、RSSなどはちゃんとレンダリングされた状態で出てくるので何もしないよりはいい感じです。

    npmのものしか対応してないので、もっといろんなものに柔軟に拡張して対応できるものが欲しい…

    その他

    CHANGELOGを自動生成するツールは他にも幾つかあります

    おわりに

    最近では多くのソフトウェアやライブラリがリリースしてもGitHubだけで完結しているものが増えました。 しかし、GitHubのReleaseをちゃんと使ってるものはそこまで多くはありません。(変更内容がコミットを見ないと分からない)

    個人的にはもっとGitHubがリリースしやすい機能(リリースノートを書きやすい機能)を入れてくれるのがいいですが、現状でもgit tag -a "annotation title" -m "release message body"を使うことで自動的にリリースメッセージを入れることができると思います。

    GitHub Releaseは自動的にパーマネントリンクが作成されるという意味でも言及しやすくなるので有用です。何でも自動化するのは現実的じゃない面がでてきますが、もっと活用する方法がでてくるといいなーと思います。

    結論: もっとリリースノート書いて下さい。


    0 0

    以下のGreasemonkeyスクリプトを修正した件についての話。

    Greasemonkey2.0

    Greasemonkey2.0ではFirefoxの変更に合わせて、セキュリティ周りの変更がありました。 それにより、色々なGreasemonkeyがそのままだと動かなくなっています。

    動かない原因は大きく分けて2つあります。

    • @grant noneがデフォルトになった
    • unsafeWindowの挙動が変わった(Firefox側の変更)

    @grant none

    に詳しい解説が書いてあります。

    簡単にいうと、今までそのまま使えていたGM_*関数は特権関数なので、Greasemonkeyで使う場合は、 事前にスクリプトのメタ情報で

    // @grant GM_getValue
// @grant GM_setValue
// @grant GM_getResourceText
// @grant GM_getResourceURL
// @grant GM_openInTab
// @grant GM_registerMenuCommand
// @grant GM_xmlhttpRequest

    のように列挙する必要があります。

    そのスクリプトで使っているAPIを列挙するのが面倒なので、 既存のスクリプトから、メタ情報のコメントを取得するコマンドラインツールを作りました。

    npm install -g greasemonkey_grant_cli
greasemonkey_grant file.user.js

    という感じでファイルを指定して実行すると

    // @grant GM_addStyle
// @grant GM_xmlhttpRequest

    のようなコメント形式で使ってるAPI一覧を得られます。

    @grant noneの挙動

    @grant noneはpage contextで実行されるためGM_*関数は使えません。 ブックマークレットと同じようなものなので、GM_関数が必要ない場合はこれをつかったほうが楽です。

    データの読み書き(localstorage)、GM_xmlhttpRequest(クロスドメインはそのままXHRと同じ)、GM_addStyleについてのshimライブラリが Greasemonkey "@grant none" compatibility shim.に用意されいます。

    そのためサイト間をまたいだりしないGreasemonkeyは、これをつかって @grant noneで動かせるケースが多いでしょう。 (APIを叩く場合は大抵クロスドメイン跨ぐので無理かも)

    実例

    livedoor Reader で NG word フィルター を実現する Greasemonkey - zaknakの日記で公開されていた LDRのNGフィルタをするGreasemonkeyはGM_*関数が必要なかったので、 @grant noneで動くように修正しました

    unsafeWindowの挙動

    もう一つの大きな変更が、unsafeWindow周りの挙動です

    unsafeWindow(特権context) -> window(page context) という一方通行なら、今までと同じ書き方で問題ありません。 (Greasemonkeyからpage contextの関数を呼び出すとかは unsafeWindow.hoge()みたいにできる)

    unsafeWindow(特権context) -> window(page context)にイベントハンドラを登録して、 window(page context)からそのイベントが発火してメソッドを呼ぶみたいなケースだと問題がおきます。

    例えば、LDRをj、kで前後の記事、nで新しいタブで開くGreasemonkeyでは、 以下のようににunsafeWindow経由で、イベントをpage contextに設定していました。

    つまり、Greasemonkey内で定義した関数をpage contextから呼ぶようになっていました。

    varopenAndGoNext=function(){varitem=w.get_active_item(true);if(!item){return;}// background openopenNewBackgroundTab(htmlEntityDecode(item.link));w.Control.go_next();};unsafeWindow.Keybind.add("k",openAndGoNext);

    これだと、page contextからopenAndGoNextを呼ぼうとすると Error: Permission denied to access property 'call'のようにパーミッションエラーという感じになって失敗します。

    そのため、openAndGoNextをpage contextから呼べるように定義する必要があります。

    このケースだとexportFunctionというGreasemonkeyの関数をwindow(page context)に登録するものがあるのでこれを利用すれば、 以下のように修正できます。

    functionexportGMFunc(fn,name){varfnName=name||fn.name;// page contextからfnNameを呼べるようにする特権作成関数exportFunction(fn,unsafeWindow,{defineAs:fnName});returnunsafeWindow[fnName];}
    unsafeWindow.Keybind.add("k",exportGMFunc(openAndGoNext));

    他にも変数やオブジェクトを登録する関数などがあり、以下に書いてあります。

    この辺はProxy APIでラップしたwindowとかを作れば自動的にいけるんじゃないかと思って、azu/Greasemonkey-unsafeWindow-Proxyというのを書いてたんですが、何かよくわからなくなって放置してます。

    実例

    ldr_keyhack_jkc+nとLDRFullFeedはこの exportFunctionを使って修正してあります。

    最近のGreasemonkey

    箇条書きで最近のGreasemonkey

    • scriptish/scriptishまだFirefox30対応してない
    • 作者のErik VoldさんはJPM Betaに忙しい様子
    • userscripts.org はほぼ完全に死んでる気がします
    • 代わりに Greasy Forkが動いています。
    • Greasy Forkは活発なのでこちらに移行するといいのでは
    • GitHubにスクリプトを置いて自動的に同期する仕組みなどもある。
    • Greasy Forkは外部スクリプトの読み込みに一部制限がある

    最後のやつは外部スクリプトを置ける場所が制限されています(条件から外れた場合はインストールボタンが押せなくなる)

    Greasy Fork policy on external scriptsに書いてある CDNやGreasy Forkにおいてあるスクリプトは@requireで読み込んで使うことが出来ます。

    簡単にいえば、動的にGreasemonkeyスクリプトの中身が変えられたりしないようにそういう制限を設けているという感じです。

    Greasemonkeyは下火ですが、まあまだ簡単に書く場合はAddon SDKより楽なので使う機会は多いです。

    JPM Betaが熟してきて、 Addon SDKでもnpmのエコシステムが回ったAddon作成ができるようになるといいですね。 (その場合でもGreasemonkeyは @grant none - 常時実行するブックマークレットみたいなプラットフォームとして残る気はする)

    今のJPM Betaはcfxコマンドの代替的な感じです。(PythonベースじゃなくNode.jsベースになった)

    Browserify

    Greasemonkeyの@requireでモジュール管理は正直現代的じゃないし難しい気がしてるので、 最近はBrowserifyでビルドしてGreasemonkeyスクリプトを書いています。

    ただし、この方法を使った場合はGreasy Forkのポリシーと反してる気がするので、 Greasy Forkでは公開できないかもしれません。

    以下で議論してたけど、どうすればいいのかよくわからないのでGitHubに直接置いてます。

    Browserifyでビルドする場合は、 git configでローカルのファイルパスを保存してビルドスクリプトを まわせば結構いい感じで開発出来ます。

    git config greasemonkey.file /path/to/自分の.user.js
npm run watch # 監視 + ビルド

    ファイルサイズが大きくなりやすいですが、管理しやすいし各スクリプトで共通モジュールが簡単にできたりするので、 自分用に書く場合は圧倒的に楽になると思います。

    まとめ

    • Greasemonkey 2.0(Firefox30)で色々破壊的な変更が起きた
    • userscripts.org は死んでいる
    • Greasy Forkがかわりに機能してる
      • safeを意識してるのでポリシーは若干厳し目
      • どちらにしてもGitHubにもコードを置いたほうがいいですね
    • Browserifyを使ってGreasemonkeyスクリプトを書く方法もある
    • Addon SDKのエコシステムが強化のためにJPM Betaがでてきた

    0 0

    Browserify 5.0.0では、 基盤となる変換処理の部分に色々変更がありました。(特にtransform周りが大きく変わって変換にhookする処理が色々できるようになった)

    ChangeLogの一番下にちょこっと書いてありますが、--standaloneを付けて単体のライブラリとして配布向けにビルドするときに、 derequireがされなくなりました。

    derequire has been taken out of core, which should speed up --standalone.

    そもそもderequireとは何かというと、 requireという関数を使うライブラリ等との衝突を避けるためにリネーム処理をするモジュールのことです。

    v4とv5のstandaloneオプションの違い

    例としてazu/get-html-titleを standaloneなライブラリとしてビルドしたいと思います。

    browserify v4以下の場合の場合は以下のようにgetHTMLTitleという関数を使える形にした ライブラリとしてビルドすると以下のようになります。

    # browserify v4以下の場合
browserify -s getHTMLTitle index.js

    !function(e){if("object"==typeofexports&&"undefined"!=typeofmodule)module.exports=e();elseif("function"==typeofdefine&&define.amd)define([],e);else{varf;"undefined"!=typeofwindow?f=window:"undefined"!=typeofglobal?f=global:"undefined"!=typeofself&&(f=self),f.getHTMLTitle=e()}}(function(){vardefine,module,exports;return(functione(t,n,r){functions(o,u){if(!n[o]){if(!t[o]){vara=typeofrequire=="function"&&require;if(!u&&a)returna(o,!0);if(i)returni(o,!0);thrownewError("Cannot find module '"+o+"'")}varf=n[o]={exports:{}};t[o][0].call(f.exports,function(e){varn=t[o][1][e];returns(n?n:e)},f,f.exports,e,t,n,r)}returnn[o].exports}vari=typeofrequire=="function"&&require;for(varo=0;o<r.length;o++)s(r[o]);returns})({1:[function(_dereq_,module,exports){"use strict";module.exports=_dereq_("./lib/get-title-html");},{"./lib/get-title-html":2}],2:[function(_dereq_,module,exports){"use strict";vartitleRegExp=/<title[^>]*>([^<]+)<\/title>/i;functiongetHTMLTitle(content){if(content==null){returnundefined;}varmatch=content.match(titleRegExp);returnmatch&&match[1];}module.exports=getHTMLTitle;},{}]},{},[1])(1)});

    以下の部分を見ると、requireではなくderequireされて無害な文字列に置換されていることが分かります。 (require.jsなどはrequireを単純に見るのでそのままだと衝突してしまうのを回避するため?)

    module.exports=_dereq_("./lib/get-title-html");

    これが、browserify v5からは以下のような出力になります。

    !function(e){if("object"==typeofexports&&"undefined"!=typeofmodule)module.exports=e();elseif("function"==typeofdefine&&define.amd)define([],e);else{varf;"undefined"!=typeofwindow?f=window:"undefined"!=typeofglobal?f=global:"undefined"!=typeofself&&(f=self),f.getHTMLTitle=e()}}(function(){vardefine,module,exports;return(functione(t,n,r){functions(o,u){if(!n[o]){if(!t[o]){vara=typeofrequire=="function"&&require;if(!u&&a)returna(o,!0);if(i)returni(o,!0);varf=newError("Cannot find module '"+o+"'");throwf.code="MODULE_NOT_FOUND",f}varl=n[o]={exports:{}};t[o][0].call(l.exports,function(e){varn=t[o][1][e];returns(n?n:e)},l,l.exports,e,t,n,r)}returnn[o].exports}vari=typeofrequire=="function"&&require;for(varo=0;o<r.length;o++)s(r[o]);returns})({1:[function(require,module,exports){"use strict";module.exports=require("./lib/get-title-html");},{"./lib/get-title-html":2}],2:[function(require,module,exports){"use strict";vartitleRegExp=/<title[^>]*>([^<]+)<\/title>/i;functiongetHTMLTitle(content){if(content==null){returnundefined;}varmatch=content.match(titleRegExp);returnmatch&&match[1];}module.exports=getHTMLTitle;},{}]},{},[1])(1)});

    requireがそのまま残っていることがわかると思います。

    なぜderequireしていたのか

    requireという関数を持つライブラリなどと衝突するのを回避するため(require.jsとか?)

    なぜderequireしなくなったか

    遅い。

    ビルドしたものをASTにパースして置換するので、-sつけるだけで10倍ぐらい遅くなってた。

    これからもderequireしたい

    に書いてあるように、別途derequireをいれて、 ビルドしたものに対してderequireをかける

    $ npm install -g derequire
$ browserify main.js --standalone Foo | derequire > bundle.js

    gulp等でやる場合は以下のようなpluginを使用すればいいと思います。


    0 0

    Voting Badge

    Vote++

    GitHub Issueで賛成などを :+1:と書いてコメントすることが良くあります。 投票ボタン的な機能としてそういうのが欲しかったので、Travis CIのバッジのように表示+投票できるボタンを作りました。

    上記にアクセスしてURL(実はキーなら何でもいい)を書くとバッジのURLを作ってくれます。

    img + link というよく見るバッジの仕組みと同じです。

    なぜ作ったか

    最近ブログをGitHub Pagesに移動したため、 これから書く予定の記事候補をGitHub Issueをつかって管理しはじめていました。

    しかし、記事候補に需要があるのか、 よくわからないので簡単な投票機能が欲しいなーと思ったのが始まりです(コメントは敷居高い)

    また、shields.ioはバッジを作ってくれるサービスですが、 これを見た時にURLと投票数の関係を管理するサーバだけを作って、画像の生成などはshields.ioにまかせてしまえば、 意外と簡単に+1バッジが作れるかもしれないと思ったのも要因です。

    GitHubの要望として既に同様のものがあります。

    しかし実装されなさそうな気がしてるので、とりあえず作ってみるかという感じで作りました。

    LevelDB

    http://shields.io/がNodeなので、合わせてNodeで書くとして、 保存する値は URL と 投票数 というだけというシンプルな感じで良かったので、KVSで適当なの使おうとしました。

    そこで何となく気になってたLevelDBが使いたくなったので、 rvagg/node-levelupを使いました。

    仕組み(初代)

    仕組みは凄くシンプルで、以下の2つのAPIを実装するだけでした。

    • /vote?url=xxxで+1投票
    • /img?url=xxxでバッジ画像をURLを返す

    imgでは、shields.ioのバッジ画像でリダイレクトを書けるというかなりずるい作りにしてました。

    "https://img.shields.io/badge/Vote:+1:-"+count+"-red.svg?style=flat"

    /imgにアクセスすると、そのurlに対するcountを使ったバッジURLを返すという感じですね。

    Heroku

    どこに置くのかも考えずに完成して、そういえばHerokuは Node.js対応してた事を思い出したのでHerokuにおくことにしました。

    LevelDBはファイルベースのDBなので、特に設定などは必要ありませんでした。

    後はProcfileを作ってpushするだけでローカルと同じように動きました。

    と思ったら、Heroku起動する度にファイルシステムはまっさらになるので、 永続化するには別途アドオンや外部に保存しないと行けないことに気付きました。

    そして、HerokuでLevelDBを単純に永続化する方法はなさそうだったので諦めました。

    Redis

    HerokuではRedisなどはアドオンが無料で使えて、こちらは永続化が簡単にできそうだったので、 Redis版の実装を書きました。

    せっかくなので、LevelDB,Redisの上にもう一層軽いラッパを作って 同じAPIで同じように扱えるようにして、LevelDB、Redisどちらでもうごかせるようにしてました。

    api-wrapper

    これでpushして永続化ができたので、完成！

    ではなく、キャッシュ時間が異様に長いというGitHub特有の問題に遭遇しました。

    キャッシュの問題

    GitHubのREADMEやIssue等に貼った画像は基本的にキャッシュされた画像に差し替えされて表示されます。

    shields.ioのカスタムバッジだと、普通にキャッシュされてしまって全然更新されないバッジが出来上がります。 (1日ぐらいキャッシュされる?)

    Cache-Control: no-cacheと Expires, Last-Modified or Etag あたりをちゃんと設定すれば、 キャッシュされなくなりますが、 shields.io の画像へリダイレクトしてるだけだったのでコントールすることが出来ませんでした。

    自前でレンダリング

    キャッシュコントールするためには、Herokuからバッジ(svg)を直接配布する必要がありました。

    shields.ioのリポジトリを見ていたら、バッジを作成するモジュールが公開されてる事に気付きました。

    node-canvas (cairo)のインストールが結構辛い感じでしたが、 Herokuで動かす設定も載っていたので、自分でバッジを作成するように切り替えました。

    これで自分のところのコンテンツを返すので、レスポンスヘッダでキャッシュコントールもできるようになりました。

    おわりに

    まだ、何か以下の心配点がありますが、一応 +1 バッジを作ることが出来ました。

    • Herokuの無料サーバで上手く動き続けるの分からない。
    • 何か微妙にGitHubにキャッシュされてる気がする…
    • DejaVu SansをHerokuにおいていいのかよく分からないため、適応してない
      • そのためレイアウトが怪しい感じ
      • 👍を表示したいけどsvgだと表示環境依存になって不便

    サンプルボタン => Vote++

    ソースコードはazu/voting-badgeに公開してあるので、修正等送ってくださると嬉しいです。


    0 0

    GitHubでのリリース

    前回、GitHubのRelease機能ついて書きましたが、これはリリースする側の自動化等についてでした。

    今度は、いわゆるライブラリユーザーだったりソフトウェアの利用者側から、 GitHubでリリースされるものをどう追っていくかについて書いていきたいと思います。

    自分は、JSer.infoというJavaScriptの情報を見ていくサイトをやっているので、 JavaScriptのライブラリ等のリリース情報をどう追っていくかが中心になりますが、基本的にGitHubでリリースされてるならやり方は大きな違いはありません。

    基本的には以下に色々書いていた内容のGitHubに関してをまとめた感じの記事となっています。

    自分用のツールが中心なので分かりやすさは二の次です。

    そのため、流れだけを見たい人はさいごのまとめを見るといいでしょう。

    リポジトリをWatchする

    GitHubではリポジトリをStar/Watchすることが出来ます。

    Starは単純なブックマークですが、Watchは登録したリポジトリに関係ある通知(イベントといわれる)がNotifications画面に表示されます。

    またデフォルトでは、登録したメールアドレスにWatchの通知メールが流れてきます。

    メールを購読するのはどうやってもスケールするイメージが出てこなかったので、 自分の場合はNotificationを見るためのビューアアプリを通して通知を見ています。 (代わりにメールの通知はフィルタして無効化しています)

    Watchしたリポジトリのイベントは大量に流れてくるので、基本的に殆ど中身までは見ていません。

    github-readerではGrowlで通知出来るようになってるので、 Growlにひたすら流して気になったものが見えたら見に行くという感じの使い方をしています。

    人をFollowする

    GitHubではTwitterのように人をフォローすることができるので、気になるリポジトリのOwnerをフォローするといいでしょう。

    ただしGitHubの場合はタイムラインに流れてくるのは、コミットやStar、Watchなどに関するイベントです。

    また、GitHubのタイムライン表示は量が増えるとまともに追うことが困難です。 そのため自分はgithub-readerを通して見ています。

    github-readerはWatchしたリポジトリのイベントと フォローした人のイベントを混ぜているので、基本的に一緒に眺めています。(主にGrowl通知なのは変わらない)

    人のStarをフォローする

    人のイベントは先ほども書いたようにコミット等の細かいものから、Starを付けたリポジトリなど多種多様です。

    新しいものを見つけるという点ではStarだけ見ていけば十分と言えるので、 Starに関してはstarseekerを利用すると、フォローしてる人のStarを一覧できるので便利だと思います。

    ここから先はGitHubのReleaseの追い方、つまりライブラリのリリースの追い方の話です。

    GitHub RelaseをRSSで見る

    先ほどGitHubのWatch機能でリポジトリのイベント通知が来ることを紹介しました。 このイベントにはReleaseEventも含まれていますが、大量のイベントの一つなので埋もれてしまいます。

    またtagをつけただけではReleaseEventはこなかったと思うので、リリースには気づきにくいと思います

    そのため、気になるライブラリ等のリリースを追いたい場合はRSSを使うのが確実だと思います。

    GitHub ReleaseのページにはtagとReleaseのRSSの2つが用意されています。

    例えば以下のようなReleaseページを見てみると、それぞれのRSSが用意されていることが分かります。

    tagが付けられるとReleaseが自動的に作られるので、基本的にどちらも同じです。 しかし、Releaseの方はリリースノートを本文に含めてくれるので、基本的にreleases.atomを購読するほうがいいでしょう。

    Releaseをワンクリックで購読

    GitHubのWatchとStarはワンクリックで出来るので、Greasemonkeyを使ってRSSもワンクリックで購読出来るようにしています。

    feedly-rss

    azu/github-releases-to-feedlyはFeedlyにReleaseのRSSを購読させるボタンを追加するGreasemonkeyです。

    手動でOAuthトークンを取得して使うので手順がややこしいですが、Usageを参照して下さい。

    1. Sign in | feedly cloudから好きなやつでログイン
    2. URL の ?code=XXX&state=から XXXをコピー
    3. リポジトリにあるツールでトークンを取得 console git clone https://github.com/azu/github-releases-to-feedly.git cd github-releases-to-feedly node get_token.js XXX | pbcopy
    4. github-releases-to-feedly.user.jsをインストール
    5. UserScript Command -> github-releases-to-feedly からpbcopyしておいたJSONをペースト

    というややこしい手順です…

    GitHub専用Feedly

    普段使ってるRSSリーダで購読していってもいいのですが、リリースノート書いてるリポジトリは少ないので、バージョン番号ばかりが流れてくるRSSが殆どです。

    そのため、自分は直接RSSを見るのではなく、FeedlyをRSSの貯める場所として使っています。 GitHub Releaseを購読する専用のFeedlyアカウントを作ってそこにRSSを追加していっています。

    そして、IFTTTを使って、TwitterやEmail Digest(1日や1週間でまとめたメールを送ってくれる)に流す感じで使っています。

    GitHub -> RSS -> Feedly -> IFTTT -> Twitter / Email / Slack

    という感じにしています。

    これなら適当な流量で流れてくるので、リポジトリのイベントだけをみてた時に比べるとかなり見落としは減った気がします。

    ReleaseからCHANGELOGを見る

    先ほども書いていたように、GitHub Releaseにリリースノートをちゃんと書いてくれるリポジトリはまだまだ少ないです。

    リリースノートは書かないで、CHANGELOG.mdといったファイルに更新内容を書いていくリポジトリもあります。

    Releaseには書いてないけど、CHANGELOGは書いてるようなタイプを見るために以下のようなGreasemonkeyを使っています。

    check_changelog_from_release

    CHANGELOGファイルがあるなら、Releaseページにリンクを表示するというシンプルなものです。

    Releaseから前回のバージョンとのDiffをみる

    リリースノートもない、CHANGELOGファイルもないというパターンは、どういうコミットがあったのかを見るぐらいしかありません(Issue等に書いてあることもありますが)

    そのようなときに、見ているバージョンと他のバージョンのcompare画面へのリンクを表示するGreasemonkeyを使っています。

    show-diff-from-release

    azu/show-diff-from-releaseではtag同士のcompare画面へのリンクをまとめて作ってくれます。

    GitHubにちゃんとしたリポジトリのtag一覧(日付が入った)を取得するAPIが見つからなかったため、タグ名が不規則だとcompareのリンクが上手くいかない場合があります。

    まとめ

    だらだら書いたので分かりにくいですが、まとめると以下のような感じです。

    この辺をうまくまとめたTwitterクライアントのようなGitHubクライアントがでてくるといいですね。


    0 0

    voting-badge

    以前作ったTravis CIライクな投票ボタンのサービスで、以下で詳しく説明しています。

    Vote++

    説明の中でも書いてありますがこのウェブアプリはHeroku(node.js)で動いています。

    Heroku Button

    Heroku ButtonとはHerokuで公開されているウェブアプリをGitHubのforkボタンのように一発でforkして使えるようにする機能のことです。

    Heroku Buttonへの対応

    Herokuですでに公開してて、GitHubにソースをおいてある場合はとても簡単にHeroku Buttonへ対応出来ます。

    1. app.jsonを配置する
    2. READMEにHeroku Buttonを置く

    たったこれだけで、Herokuのforkボタンがつけられます。

    azu/voting-badgeのケース

    azu/voting-badgeの場合は先ほど解説したように、 app.jsonを追加してHeroku Buttonを追加しただけです。

    1. add app.json
    2. アドオンなどを使ってる場合はapp.jsonに その情報を追加
    3. add deploy button

    最終的な app.jsonは以下のような感じで、アプリのメタ情報が入ったnpmのpackage.jsonみたいなものであることが分かります。

    {"name":"voting-badge","description":"Voting badge like Travis CI","website":"https://github.com/azu/voting-badge","repository":"https://github.com/azu/voting-badge","keywords":["node","badge","canvas","node-canvas","GitHub"],"env":{"BUILDPACK_URL":"https://github.com/mojodna/heroku-buildpack-multi.git#build-env"},"addons":["redistogo:nano"]}

    これで以下のようにボタンが追加できて、ボタンを押すとHerokuにforkすることが出来ます。

    img

    実際に動くボタンは以下のような感じです

    Deploy

    細かいはまりどころ

    BUILDPACK_URLやaddonなどを使ってる場合はapp.jsonにもその情報を書く必要があることに注意してください。 詳しくは以下で解説されています。(書かないとforkしたときにエラーがでる)

    また、app.jsonがjsonとして問題がある場合、 https://dashboard-next.heroku.com/newが何もいわなくなるという状態になったりしました。

    注意

    Heroku Buttonはリファラーをみて、どのアプリかを判断してるのでGitHubのREADMEに貼ったときのみ、 以下のようにパラメータがないボタンを貼ることで動作します。

    [![Deploy](https://www.herokucdn.com/deploy/button.png)](https://heroku.com/deploy)

    もちろん、パラメータをつけたボタンも作ることができるため、GitHub以外から動くボタンも作れます。

    以下のようにtemplateのパラメータを付け加えるだけで問題ありません。

    Deploy

    <ahref="https://heroku.com/deploy?template=https://github.com/azu/voting-badge"><imgsrc="https://www.herokucdn.com/deploy/button.png"alt="Deploy"></a>

    GitHubからでもリファラーを無効にしてるブラウザだと動かなくなるので、通常はパラメータを入れてたほうが安全そうな気がします。

    おわりに

    Herokuに追加されたHeroku Buttonについて解説しました。

    Herokuで公開してるアプリを簡単に試せるのでとても便利だと思います。


    0 0

    Shibuya.XSS テクニカルトーク #5 : ATND

    Shibuya.XSSに参加してきたのでメモです。

    体調がイマイチだったので朦朧としたメモです。 後、オフレコなものがあったので、その部分はオフレコとしてあります。

    公開していけない箇所があったらIssuesなど立ててください。

    私の見つけたXSS - yousukezan

    • JVNのXSS
      • FlashのXSS
    • PaypalのXSS($100ぐらい)
      • paypalの中国のサイト
      • paypal-wujinggou.com
      • All in ONE SEOプラグインのXSS (Wordpress)
      • s=\\x22\x3eみたいな感じでXSS
      • Wordpressのプラグイン
        • XSSが日々大量に見つかるので要チェック
    • Yahoo!のXSS
      • 去年バウンティプログラムが始まって大量の脆弱性が報告されている
      • Yahoo!mail の Self-XSS
        • "><script>をコピペするとできるXSS
      • FlickrのXSS
      • Yahoo!mailの電話帳のXSS
        • アドレス帳のWebURL欄にjavascript:alert(0)//
        • //がないとURLとして認識してくれなかった
        • クリックでXSS
      • Yahoo!7のXSS
        • 特定のメールタイトルがTOP画面にスクリプト実行される
        • ユーザー個人の新着メールのヘッドラインが変
      • Yahoo!台湾のXSS
      • Yahoo!動画検索のXSS
        • <"><svg onload=....>だとなぜか通る
        • サニタイズフィルターをスルーしてしまう
      • Yahoo!の広告表示のXSS($5000)
        • window.nameを使ってiframeのクロスドメインの広告を吐き出すHTMLにXSSがあった
        • 元のドメインが yahoo.com というURLに一致ならまだ通ってた
        • xssyahoo.com というドメインを取ってXSSが再度通った

    Blob URI Scheme - やぎはしゅ

    Blob URI Schemeの素敵なお話

    • CTF、カメラ、XSS
    • Blob URI について
    • blob:http://doma.in/xxxx
    • data:に似てるけどちょっと違うやつ
      • 一時的なデータにURLがつけるために使う
      • アップロードされたローカルコンテンツへの参照
    • Blob URLの作り方
      • BlobオブジェクトにFileオブジェクトを渡して、URL.createObjectURL()でblob URLを生成
      • ブラウザから直接参照した場合はtext/plainになる
      • 画像だとContent sniffing的な挙動
    • ユースケース
      • ユーザアップロードのコンテンツに対して一時的にクライアントサイドで参照を持ちたい
    • 前提
      • ユーザー指定のローカルコンテンツへの参照
        • input[type=file]で画像を選択して取る
      • 通常のユースケースではXSSになりにくい
    • むりやりXSSと結びつける
      • 本来の用途とはかけ離れているページ
      • 通常の用途ではなく、無理やりXSSが起きそうなページを作る
      • location.searchからBlob URLを作ってiframeのsrcに埋め込むサイト
      • location.search -> Blob URL -> iframe.src
        • 実行されるblobのoriginはiframeの参照元のコンテキストで動く
        • parent.document.cookieの参照が可能
    • まとめ
      • Blob URLをData URLとはやっぱり違う
      • Content-typeの扱いが面白い気がする

    Bug Bounty Program - nishimunea

    Welcome to the Black Hole of Bug Bounty Program Rebooted

    • Mozilla Security Bug Bounty Programについて
    • 重要なセキュリティバグ発見した人にMozillaが報償金
      • 1件3000$
    • どこを探したらバグの見つける戦略が必要
      • Web Workers弱そう
        • hasegawaさんが報告してた
      • 1件見つかった - CSPをバイパスするバグがあった
      • すでにkinugawaさんが発見、報告したバグだった
      • 既知のバグを見つけた場合 => 類似Bugへのアクセス権を付与してくれる
    • 諦めかけていたそんな時
      • DeviceStorage APIのディレクトリトラバーサルの脆弱性が報告されていた
    • Firefox OSは未開の地(フロンティア)
      • Browser API(WebView)を探索
      • CSPヘッダが完全に無視される
        • CSPの実装が古いだけ
        • CSPの実装がまだされてなかっただけ
        • 実装が間に合ってないだけだった
      • X-Frame-Optionsヘッダ無視される
        • フレームじゃなくてブラウザAPIなので仕様なんだ!
      • 未開の地ならではの苦労
        • 実装されてない機能がまだ多い
        • バグなのか仕様なのか手探り
    • Mozilla Foundation Security アドバイザリー
      • 過去の脆弱性を発表してるページ
      • 過去の脆弱性から弱そうな機能を抽出
      • それらを組み合わせて生まれる脆弱性があるかもしれない
      • CSP x appcache x WebSocket でバグ
        • CSPの違法レポートが機能しないバグ
        • だれも困らないバグ => セキュリティbugzillaだけど公開された
    • 機能が増えれば攻撃方法も増える(組み合わせが増える)

    ブラウザとWebサーバの話 - はるぷ

    ブラウザとWebサーバの話@Shibuya.xss

    • XSSの仕方いろいろ
      • スクリプトタグ
      • イベントハンドラ
      • href=javascript:<= 今日の主役
    • 302 Foundの画面
      • Locationヘッダの中身によって302画面が出るブラウザとでないブラウザがある
      • ChromeとFirefoxはabout:blankへは飛ぶ
      • javascript:と入れた場合
        • Operaは動く!
        • Apacheに報告したけど脆弱性じゃないといわれた
        • ISP 「このオブジェクトはここ」
        • Opera独自エンジン presto
        • Firefox5.0も同じように意外と動く
    • 正攻法でXSS
      • Chrome 普通にXSSいれても動かない
      • ヘッダでX-XSS-Protectionを無効にしてXSSを起こす
      • レスポンスヘッダを組み合わせると動くケースが出てくる
      • 今どきレスポンスヘッダインジェクションできないのでは?
    • JSP の面白いレスポンスヘッダインジェクション
      • CentOS6 Apache 2.2.x とかちょっと古い組み合わせで
      • ヘッダで改行ができてインジェクションできてしまう
    • Set-Cookie
      • 大量のクッキーを押し付けるとBad Requestになるケース
      • リロードしてもBad Requestが続く
      • クッキーをけすのも大変(位置が分からない)
      • 大量のクッキー押し付ける攻撃
    • まとめ
      • 古くからある変な挙動も面白い
      • 新しいものを作るときに意外と再熱する

    karupanerura

    • チート行為 - 2つの目的がある
      • 自分自身が有利になる
        • 偽の情報を送り付ける
      • ユーザーへ不利益を与えるもの
    • サーバに送信するデータを偽装する
    • 防ぎたいチート行為
      • ただでもできる
      • 簡単にできる
      • ほかのユーザーに影響を与えられる
    • ヤバいやつ
      • ブックマークレットで出来るチート行為
        • XHRでAPIにデータ送信
        • フロントに処理を置くケースが増えてきている
      • 位置情報を使ったゲームの偽装
        • デバイスデータの偽装は対応しにくい
    • 目指したいレベル
      • だれでもチートできる 状況を避ける
        • 少数なら手動でBANする
      • ブックマークレットなどでできないようにする
    • Same Origin Policy
    • オフレコーオフレコー
      • チート対策を完璧にやるのは難しいので、簡単には出来なくさせるにはどうするかという話

    直ってないGoogleの脆弱性 - ma.la

    • 複数バグ報告したけど、片方のみ修正されてない
    • オフレコーオフレコーデモーデモー
    • まとめられなかった

    うわさのあれをゆるくMITMしてみた- ockeghem

    うわさのアレはオフレコ???

    犯人を追いつめろ! - TAKESAKO

    • SECCON 2014年の夏予選
    • CTFオンライン予選
      • LINEの乗っ取りチャットっぽい問題
      • ソーシャルハックするCTF
      • 相手は人口無能
      • 画像をダウンロードさせる
      • UAとかIPとかからVPSにアクセスできるヒントをくれる
      • 細かいギミックがある人口無能

    文字列からHTMLを組み立てる話 - hasegawa

    shibuyaxss.pdf

    • DOM based XSS
    • 文字列のサニタイズ
      • IEであれば、toStaticHTMLが使える
      • JavaScriptなどを削除したものを返してくれる
      • IE以外はどうするのか
        • toStaticHTMLもどいきを作る?
        • 作るな!安全なものを探せ!
        • Google Caja
      • Google Caja
        • 文字列をパースして安全なHTML文字列を組み立て
        • 遅い
    • ブラウザ互換のパーサ
      • ブラウザ内蔵のパーサAPIを使う
        • DOMParser
        • createHTMLDocument
      • createHTMLDocumentによるパースとDOMノードの構築
      • 文字列をパースしてDOMノードを構築可能
      • DOMノートから必要な要素、属性だけをホワイトリストで取得する
      • DOMParserとcreateHTMLDocumentは現在表示してるdocumentに影響を与えない
    • 許可する要素、属性を列挙する?
      • JSONで許可リストを指定して処理するサニタイズのデモ
      • 許可したノードだけで構成されたノードを取得できる
    • パースしたものを文字列に変換してはいけない
      • 文字列 -> Element -> 文字列は 危険な可能性がある
      • HTMLElementから文字列の変換はmXSSを引き起こす可能性がある
      • <listing>&lt;img....というをDOMParserでパースして、それのinnerHTMLするとなぜか<imgになってしまう
      • toStaticHTMLと分岐して文字列を返すような関数を作ったりするとやりがち
      • 返すときはElementのまま返して使おう
      • fp170.pdf
      • mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
    • バグがあっても平気なようにする
      • HTML5 sandbox iframeを使う
      • sandbox属性によりJavaScriptを禁止する
      • seamless属性により親のCSSを継承
      • 見かけ上は普通のコンテンツだけど、実行されても安全な場所が作れる
    • まとめ
      • toStaticHTML便利(IE)
      • DOMParser、createHTMLDocumentでHTML文字列をパースしてElement
      • 文字列 -> Element -> 文字列は 危険 mXSSの可能性
      • sandbox iframeを使おう

    その他

    メモ: OmniOutliner


older | 1 | .... | 3 | 4 | 5 | (Page 6) | 7 | 8 | 9 | .... | 13 | newer