http://patchwork.serpentine.com/patch/12367/

Mercurial に patch を送ったんだけど、patchを投稿するにあたっての規約 がいろいろと面倒だった。なんとか順応できたけど、普段から GitHub に慣れきっているとこういうのはつらい。逆に言えば、Pull Request という共通のプロトコルを提供している GitHub の偉大さを体で思い知ったというところか。

やまねさんの物言いは、そういう意味でもっともだと思いました。まる。

OSSはライセンシングという共通プロトコルによってリーガルコストを下げた。GitHubはプロジェクト・プロダクトごとの決まりを共通化したプロトコルを導入することでコミュニケーションコストを下げた。OSSという観点ではコストを下げてアウトプットを最大化しているのだから正しい

— henrich (@henrich) December 28, 2015

2015年ももう少しで終わろうとしているので、今年がどんな一年だったかを振り返っておこうと思う。

なんといっても、所属が変わったことが一番大きい。それによって、それまで手掛けてきたものに対する要求も大きくなった。環境が全く異なり、期限もあり、頑張る人もいない中で、いろんなバランスをとりながらチームをリードすることが一番大変だった。そんな中でも成果をきちんと出せたのは自分の中で大きな財産になると思うし、技術的にも得たものは大きい。勿論、これはチームメンバの誰一人が欠けても、成し遂げられなかったことである。縁があって一緒にやってきた方々皆に感謝したい。

所属が変わったと書いた。これによって組織のカルチャーも大幅に変わった。ビジネスサイドを理解し、判断の根拠を他人任せにせず、自分なりのベストを（例え間違っていても）アウトプットすることが求められるようになった。これによって「情報を隠さず、誰が相手でも正直ベースでぶつかる」という自分のスタイルを全力で貫いても困らなくなった。それが、チームのリードに苦労した中でもうまくやってこられた大きな要因かもしれない。

技術的には、去年やっていたこと に加えて、プロダクトのスケールを妨げるあらゆる要因を潰すことを延々とやっていた。Redis Cluster の導入とか、プロダクトのコアのチューニングとか、バッチの速度を数十倍にしたりとか、それは本当にスケールするの？ とコードを書く人たちに問い続けるとか、そんな感じ。プロダクトに機能を付け加える人達の裏で、それの邪魔をしないようにするための基盤を作ることだけに徹した。

忙しさが大きくなると、周囲の動向に関する視野や問題意識が狭くなると思う。問題意識と視野あってこそのアウトプットなのだから、余裕を持って楽しもう。それが2015年の目標である。

去年こんなふうに書いたが、忙しさに紛れて、今年も余裕がなかったと言わざるを得ない。それは今年のエントリが少ないことを見ても明らかだろう。ただ、技術を楽しみながら、書いたコードを外部に還元することは忘れなかったつもりだ。 Redis のクライアント周辺については、必要に迫られながらも良い成果を出せたと思うけど、インプットもアウトプットもまだまだ足りないなあと思う。切磋琢磨する相手も増えたので、いろいろな人と協働しながらもっと楽しみたい。

来年はエンジニアとしての立ち位置が問われる一年になるはずだ。純粋に手を動かし、楽しむだけでなく、明確になりつつあるストロングポイントを踏まえて、どうしていくか。なんらかの答えを出さねばならない。

本当の意味での正念場といえよう。

2015年は Redis と戯れていた一年と言っても良い。Redis Cluster を Production 環境に導入し、redis-py-cluster に READONLY 対応の patch を送った りした。

Redis Cluster は Redis 3.0 で加わった新機能であり、もうじき 3.2 が出ようとしている。そんな状態の中で 2.8 でしかテストされていないのはどうなの？ と思い、以下の 2つの patch を送っておいた。

• redis-py のビルド環境を 3.0 対応にする
  • https://github.com/andymccurdy/redis-py/pull/697
• RESTORE コマンドに 3.0 で加わった REPLACE修飾子に対応
  • https://github.com/andymccurdy/redis-py/pull/698

特に前者は、2.8 によるテスト環境をごっそり 3.0 に入れ替えるものなので、割とドラスティックである。Redis 側で 2.8 をいつまでサポートするのか、というポリシーが明確ではないので、取り込むタイミングは流動的だと思われる。

ただ、3.x 特有の機能が増えていく中で、一石を投じる必要としては今がいいんじゃないかな、と思った次第である。

PEP8 のファイル更新を監視するのに、 Mercurial リポジトリ更新チェックツール というのを書いている。コミットメールや hg.python.org の RSS を見れたりすれば一番良いのだが、前者はPEPの編集者や開発者にしか開放されておらず、後者はファイル単位の更新を見せるようにはできていない(*1) 。このツールはファイル単位での更新があったらメールしてくれるというもので、自分のニーズを満たすための単純なものだ。

ところがこのツール、ちゃんと動いていなかった。更新がリモートリポジトリにあってもちゃんと検知できていなかったのだ。ダメぢゃん！
原因は git pull にあたるコマンド を hg update だと思い込んでいたというもので、単純に Mercurial の理解不足である。

なので、こういうお馬鹿な patch を書いてしまうんですね。ハイ(´ー｀; )
誰の役にも立たないんで、ますますお馬鹿度が増すという…

1
2
3
4
5
6
7
8
9
10
11
12
13

diff --git a/rev_update_checker.py b/rev_update_checker.py
index b6109fe..af39899 100644
--- a/rev_update_checker.py
+++ b/rev_update_checker.py
@@ -22,7 +22,7 @@ class TargetRepository(object):

     def update(self):
         os.chdir(self.repository_path)
-        subprocess.check_output(['hg', 'update'])
+        subprocess.check_output(['hg', 'pull', '-u'])


 class TargetFileRevision(object):

(*1) だったら hgweb に patch 投げればいいやん、と思って、投げておきました …

github page を Octopress で公開している人は、きっと master が HTML と CSS だけで出来たリポジトリを github に持っており、かつ source ブランチでそれを生成するための Rakefile や _config.yml、ブログエントリの markdown、テーマなどをバックアップしているはずだ。

では、何かの拍子にブログを書く環境を壊してしまい、source ブランチから復活させなければならなくなった場合はどうだろうか。今朝ちょうどそういう状況に陥ってしまい、復旧に少し手間取ったのでメモしておく。

要するに clone した後、 _deploy ディレクトリを生成し、そこで git リポジトリを再初期化し、github page へのリポジトリを remote に加えるだけだ。 要するに、 setup_github_pagesタスクの後半 を真似ただけである。

1
2
3
4
5
6

$ git clone git@github.com:mumumu/mumumu.github.io.git blog
$ cd blog
$ mkdir _deploy
$ cd _deploy
$ git init
$ git remote add origin git@github.com:mumumu/mumumu.github.io

あとは rake new_post["some title"] で記事を書き、rake generate や rake gen_deploy の操作でいつも通り記事が公開できるようになる。

こうしたリストアの操作と、 git push origin source というバックアップ操作が面倒くさかったので、以下のような patch を Rakefile に足しておいた。

まずは バックアップの操作が rake gen_deploy後に自動で行われるようにした。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@@ -252,16 +252,38 @@ multitask :push do
   Rake::Task[:copydot].invoke(public_dir, deploy_dir)
   puts "\n## copying #{public_dir} to #{deploy_dir}"
   cp_r "#{public_dir}/.", deploy_dir
+  message = "Site updated at #{Time.now.utc}"
   cd "#{deploy_dir}" do
     system "git add ."
     system "git add -u"
     puts "\n## Commiting: Site updated at #{Time.now.utc}"
-    message = "Site updated at #{Time.now.utc}"
     system "git commit -m \"#{message}\""
     puts "\n## Pushing generated #{deploy_dir} website"
     system "git push origin #{deploy_branch} --force"
+  end
+
+  cd "#{deploy_dir}/../source" do
+    system "git add *"
+    puts "\n## Commiting: Site updated at #{Time.now.utc}"
+    system "git commit -m \"#{message}\""
+    puts "\n## Pushing source branch as backup"
+    system "git push origin source"
     puts "\n## Github Pages deploy complete"
   end
+
+end

github page のソースを clone した後、_deploy ディレクトリを再生成し、master として remote を足すタスクも追加した。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

+
+desc "restore github pages directory"
+task :restore_github_pages_directory do
+  puts "\n## Re-creating deploy directory"
+  rm_rf deploy_dir
+  mkdir_p deploy_dir
+
+  cd "#{deploy_dir}" do
+    repo_url = "git@github.com:mumumu/mumumu.github.io"
+    system "git init"
+    system "git remote add origin #{repo_url}"
+  end
+ end

 desc "Update configurations to support publishing to root or sub directory"