複数のgitリポジトリを履歴を残したまま統合する
引き継いだプロジェクトが、foo_pc, foo_sp, foo_commonみたいなかんじでリポジトリが分かれていて、同じ機能の開発やっているのにそれぞれにPullReqだしたり、リリースノートを書いたりするのがしんどいので、統合した。以下に統合した時の手順をまとめておく。
まず、新しくリポジトリを用意して、以下のように統合したいリポジトリ毎にディレクトリを作成して(.gitkeepとか用意して)、コミットする。
foo ├── foo_common ├── foo_pc └── foo_sp
次のようなスクリプトを実行する。git 2.9 から無関係なヒストリもってるブランチ同士をマージするときは --allow-unrelated-histories つけないとエラーになるのがハマりどころ。
for repo in foo_pc foo_sp foo_common; do git remote add ${repo} ~/${repo} git merge -s ours --no-commit --allow-unrelated-histories ${repo}/master git read-tree --prefix=${repo} -u ${repo}/master git commit -am "Merge in ${repo}." done
webpagetest-api を使おうとしたときのメモ
個人用メモ。
ウェブサイトのパフォーマンス計測ができる WebPagetest - Website Performance and Optimization Test というサイトがあって、Speed Indexという独自の指標( アルゴリズムは webpagetest-doc-ja/index.md at master · t32k/webpagetest-doc-ja · GitHub が詳しい )や、その他各種計測値・統計値を出してくれる。
最近、関わっている案件のひとつで、継続的なウェブサイトのパフォーマンスの改善に取り組んでいて、WebPagetestが提供しているREST APIを定期的に叩きたくなった。webpagetest-apiというAPIラッパー・コマンドがnpmパッケージがあるので、手軽に始めるにはそれを使うとよさそう。
と、思っていたんだけど、数週間前にWebPagetestがhttpsに移行した影響でエラーになったり(既にPullReqは出ているがスルーされている。が、コマンドのオプションでFQDNを変更できる)、計測のAPIを呼び出すときにAPIキーが必須になっていたり(キーはここから取得できる WebPagetest - Get API Key)、ドキュメントが古くて、ちょいちょいハマった。
いまいま、コマンドで試す場合はこんなかんじになる。
webpagetest test --server='https://www.webpagetest.org' --key='YOUR_API_KEY' 'https://twitter.com/kitak'
ヴィンランド・サガ (18) を読んだ
読んだ。
- 作者: 幸村誠
- 出版社/メーカー: 講談社
- 発売日: 2016/08/23
- メディア: Kindle版
- この商品を含むブログを見る
トルフィンが「本当の戦士」に近づいていることをいたるところでアピールしている巻だった。 (「本当の戦士」ってよく分かっていないけど ) この漫画、戦闘の緊迫している状況の描き方が秀逸で、あっという間に一冊読み終わってしまう。
ES2015のarrow functionsはargumentsを束縛しない
題の通りで、何かのES2015の紹介記事に書いてあった気がするんだが、いざコードを書く時にすっかり忘れていた。
() => { console.log(typeof arguments) // undefined }
MDNの記事を読んだら( アロー関数 - JavaScript | MDN )、ES2015のrest parametersで代用できるよ、とのこと。
(...args) => { console.log(typeof args) // object console.log(Array.isArray(args)) // true }
arguments、ライブラリを作っていて可変長引数をやりたい場合に使うのだけど、これが「Arrayのような」オブジェクトで push や pop といったメソッドが使えない。これを解決するためのイディオムとして、以下のように arguments を配列に変換するのだけど、知らない人が見たら、何だこれは、という気持ちになる。
var args = Array.prototype.slice.call(arguments);
一方、rest parameters の方は普通の配列なので「Arrayのような」オブジェクトかどうか気にしなくてもよい。ES2015の仕様が当たり前に使える世界になったら(そうなりつつあるが)、可変長引数の用途では arguments を使わず、rest parameters でいいのかもしれない。
ES2015の配列のパラメータハンドリングが便利だった
ES2015の分割代入やパラメータハンドリング、便利そうではあるんだけど、他人がそれを使ったコードを読むと一見なにをやっているのか分からなくて(単純に慣れていないだけな気もする)、これまでの惰性もあって多用するのを避けていた。
で、今日、コードを書いていて、多値を配列として扱ってPromiseを解決した場合に、次のPromiseでそれを受け取る時に便利なことに気づいた。こんなかんじ。
someFn().then(([alpha, beta]) => { // ... });
以前までは、results みたいなイマイチな名前の変数で受け、適切な名前の変数に再代入することを行っていた。
someFn().then((results) => { const alpha = results[0]; const beta = results[1]; // ... });
Vuex のドキュメントを翻訳した
Vuex は、Redux インスパイアの Vue.js の周辺ライブラリ。各言語の翻訳があるんですが ( http://vuex.vuejs.org/ )、日本語のドキュメントが v0.8 から更新されていなかったので、v1.0.0-rc.2 を対象に @ktsn さんとドキュメントを翻訳し直しました。読みづらいところや誤りがあるかもしれませんが、見つけたら教えてください。
Vuex について、今回の翻訳とドキュメントを読みながらサンプルアプリケーションを書いた程度の印象ですが、Redux の影響を受けつつも、Vue.js 本体の状態の変更を追跡する仕組みを活かして(逆に依存しているともいえますが)、より単純で扱いやすくなっているように見受けられます。作者の設計の意図がドキュメントに丁寧、かつ明確に書かれており、興味深く翻訳させていただきました。仮に Vuex を使わないとしても、中規模~大規模のアプリケーションを自身で構築する場合の設計の一つの例として参考になるはずです。
次は、正式版のリリースが近づいている Vue.js 2.0 か、Vuex 2.0 のドキュメントの翻訳に関わることができればと思います。
knex.js: NodeのSQL Query Builder
最近、趣味と仕事両方で使うNodeで動くちょっとしたウェブアプリを書いている。
おそらくRailsの方が素早くできそう、あるいは普段書かないPythonとかGoみたいな言語で書いてみたかったんだけど、仕事で同じ部署の人に使ったり、手を入れてもらうことを考えると、JSを書いてNodeで動かすのがよかろうと判断した。
で、SQL Query Builderが欲しくなって、色々探したら、インターフェイスがPromiseなのと(Streamもある)、開発が活発というところで knex.js というのがよさそうだった。ドキュメント( Knex.js - A SQL Query Builder for Javascript )がしっかり書かれているので、細かい使い方とかは書きません。
あと、Query Builderに加えて、おそらくRailsインスパイアのMigrations機能があって、これも必要になったら使うと良さそう。 knex.jsと同じ作者の関連プロジェクトに bookshelf.js というORマッパーライブラリがあるが、今つくっているものに対してやりすぎな気がするのでスルー。