転職しました

生存報告的に。今日が初出社日でした。

FROM: 2019/09 株式会社TOLOT TO: 2019/10 株式会社ピクシーダストテクノロジーズ

よろしくお願いします。

Mercurial 3.6 Sprint 参戦メモ

ちょっとFacebook Londonまで行ってオフラインミーティングに参加してきました。

Mercurial Sprint

分散バージョン管理システム Mercuiralの半年に一度ペースで実施されるオフラインミーティングです。 公式Wikiのミーティング一覧を見ると、もう10回以上開催されている由緒ある会です。

今回はイギリス Facebook LondonがSprint会場*1で、期間は10/23から10/25までの三日間。全世界*2からMercurialのコミッターやコントリビュータが集まって新機能のディスカッションなどを行います。

参加の経緯

藤原さん*3に

都合が良ければ飯野さんも一緒に参加しませんか？

とメールで誘われたのがきっかけです。これが9/17の朝。開催まで一ヶ月。この時点で僕はパスポートを持っていませんでした。

Sprint期間中

初日だけ自己紹介して、以降は事前に公式Wikiに乗せてあるProposal*4や温めておいた提案をベースにいろいろディスカッションしていました。ミーティングスペースがたくさんあるので、込み入った話題の場合は実装に詳しい関係者を集めて別室で、という感じ。あとは各自もくもくと作業です。ディスカッションの内容はtitanpad.comで共有*5していました。

載せられるやつだとこんなのとか、こんなのがあります。

そのほかはこんな話題が上がっていました。

  • pypy support
  • in memory merge
  • revsetの相対リビジョン記法の提案

当たり前だけど英語でやりとりしているので、難しい話題も相まって僕の英語力では全然理解できませんでした。。。

僕はKallitheaにパッチを送ったり久しぶりにi18nファイルのメンテナンスをしたりMads*6と話したりしました。最近パッチ送ってなかったみたいだけどなんで？って聞かれて焦るなどしてました。。

Sprint期間中のおかし

メインの会場にあらかじめイギリスのおかしが用意してありました。それ以外もFacebook Londonのオフィス内にある休憩スペースから勝手にお菓子や飲み物*7をとっていったり、100万円くらいするらしい全く音のしない静音エスプレッソマシンでエスプレッソを作って遊んでたりしてました。

日本からは羽田空港で買った宇治抹茶味とわさび味のキットカットを持っていきました。抹茶味の方は味が、わさび味は変な味だけどチャレンジャー向きってのが受けたのか結構好評でした。

Sprint期間中の飯

初日は平日だったので昼、夜はFacebook Londonの社員と混じって社食でご飯*8。 二日目、三日目は近くのレストランに移動してワイワイ宴会をしていました。

特に最終日は謎日本料理バーはメニューがgindara no saikyo yakiみたいなローマ字表記*9とかなのでビビりました。しかも流れで日本人の僕らが料理の注文を取り仕切ることに。めっちゃ緊張&反省*10しました。

以下旅行のメモ

初めての海外旅行。一人で旅券とって、ホテル予約してチェックインして、電車やバスで移動するのはいい経験でした。

事前に藤原さん、西原さんと日程や宿の情報、海外旅行必需品の情報を共有したり、ロンドンに長期滞在経験のある上司や同僚に現地情報や海外旅行tipをもらったので非常に助かりました。

タスク管理

trelloをつかってタスク管理しました。

f:id:troter:20151103211952p:plain

用意したもの

  • パスポート。 今は申請から7営業日くらいで取得できるみたいです。都内に住民票がある人が都内で申請する場合は戸籍謄本だけでOKで住民票は不要でした。
  • 旅券。 いろいろ調べたのですがDeNAトラベルで取りました。旅行保険も一緒に。British Airwaysの直通便で行きました。
  • 宿。 Booking.comで予約してチェックイン時にカード決済しました。ホテルの受付で、「これです」ってスマフォ画面を見せたらOKで簡単でした。
  • オイスターカード。 ロンドンのSuicaです。地下鉄、バスに乗れます。現地でも地下鉄にある端末で買えるのですが事前にビジター用のカラフルな柄ものを確保しました。 旅行中に無くして現地向けの地味なやつを買いなおしました。。
  • 海外旅行用クレジットカード。 スキミングとか怖いのでメインで使ってるクレジットカードとは別に用意しました。藤原さんの考察を聞いた結果マネパカードを用意しました。
  • 現地マネー。 日本の空港で少し用意して、残りは現地でおろして用意しました。クレジット決済できるのですが、現地のお金で買い物したかったので多めに*11おろしました。
  • 電話。 iphoneが海外でも利用できるので特に現地用のものは用意しませんでした。SIMフリーの端末があるなら現地でSIMを買うと良いと思います。
  • wifi。 ホテルやSprint会場ではWifiがありますが、観光中は使えないのでwifi借りました。なんとなくtownwifiのやつを借りました。
  • 変圧器、アダプター。 なんとなく用意したけど、MBAの電源は優秀なのでプラグの変換アダプターだけあればOKでした。USBでの充電はMBA経由でできるし。
  • 地球の歩き方ロンドン編。 気分を高めるために&観光地調べのために。

旅のタイムスケジュール

こんな感じ。一ヶ月前にパスポートなくても海外旅行できました。

  • 9/17 誘いを受ける。先輩社員に相談
  • 9/18 戸籍謄本確保（親に頼んだ）
  • 9/24 パスポート(a)申請、地球の歩き方ロンドン編購入
  • 10/03 (a)取得
  • 10/06 有給調整。旅券購入、宿予約
  • 10/07 オイスターカード(b)申し込み
  • 10/10 海外旅行用クレジットカード(c)申請
  • 10/12 (b)確保
  • 10/17 (c)確保
  • 10/20 猫をくれた家に預ける
  • 10/22 日本時間朝出発
  • 10/23-10/25 Sprint
  • 10/26-10/27 観光
  • 10/28 現地時間朝出発
  • 10/29 日本時間朝着。そのまま出社

*1:ちなみに前々回はドイツ Google Munich、前回はアメリカで PyCon 2015 Montrealに併設で開催されました。

*2:っていっても北米、ヨーロッパがメインっぽいです

*3:Mercurialのコントリビュータ。トランザクション周りやvirtual file system（ファイルシステムの抽象化層）などが得意

*4:WIkiにあるHogeHogePlanというページがそれです。

*5:URLを紹介しようと思ったのですが、誰でも編集できる共有ノートになっているようなのでやめておきます

*6:Kallitheaのメインのメンテなー

*7:水、各種コーラ、ジンジャエール、Redbull、その他イギリスの謎ジュースなどなど

*8:イギリスの飯だけどFacebookの飯はおいしかった

*9:別の料理の名前でこれが分からないんだけどって聞いたら、「それは英語だよ」って帰ってきて「あー、そうですよね」って気持ちになりました。

*10:注文内容にベジタリアンな人たちの配慮が足りなかった。

*11:というか端末の設定からか200GBPからしかおろせなかった、、

ISUCON5の予選に参加して惨敗してきました #isucon

ISUCON5の予選に参加して惨敗してきました。チーム名は「T・D・U！T・D・U！」。大学で同じ研究室だった友達を誘った&&「googleの大学名の検索結果がおかしくなった事件」の画像の作成者がチームメイトだったので、この名前にしてみました。

事前準備

僕以外の二人は初参加です。

事前に一回集まって前回のISUCON予選の課題を解いたり、bitbucketに今回用のリポジトリを作ってwikiに秘伝のタレをまとめたりしてました。

あと、食料の買い出しなども。

当日

Skypeのボイスチャットでやりとりをしながらリモートで作業しました。

コミットログから当日のタイムラインを作ってみるとこんな感じです。（みんなの成果です。）

  • 〜12:00 秘伝のタレをアプリに適用、コードをgit化して提出用インスタンスを作成
    • nginxで静的ファイル返すとかunix domain socketとかmemcachedのsessionとか
  • 〜14:00 ログインのhtmlをキャッシュしてみたり、インデックスを貼ってみたり、アプリのSQLを修正してみたり
  • 〜16:00 '/'のN+1をやっつけたり、friend_mapを最初に取得してfriend_mapをつかってis_friendの代わりにしてみたり
    • この辺りでスコアは2000くらい
  • 〜18:00 いろいろ力尽きてインフラ周りのチューニング

言語はrubyで、最後に取ったスコアは5000点くらいでした。

良かった点

秘伝のタレで用意したタレはテンパった状態でもサクッと適用できた。事前準備大事。

反省点

いろいろあるのですが。

リモート辛い

skypeのボイスチャットとslackではいろいろ情報のやりとりが大変なので対面でやったほうがいいです。 ちょっと画面みてよ、とかできないので。情報共有の難しさがあったなーと。

当日時間を気にしてテンパる

テンパりました。

  • プロファイルするためのgemを入れる。
  • アプリを把握して、更新のあるテーブル、ないテーブルを確認する。
  • dbのschemaとプロファイル結果を見比べてindexを貼る

みたいな必ずやるべきことがうまくできなかったです。ちゃんとプロファイルしてその内容から修正しよう。。

作業分担しておくべきだった

得意不得意あるので、事前に作業分担をしておくべきでした。 久しぶりに集まったので作業分担で遠慮しちゃう部分があったり二人で同じことやったりとか、効率悪かった部分が。

最後に

今年もTop20に載ることなく終わりました*1。来年は一瞬でも載って盛り上がれるよう精進したいです。

運営、出題のみなさん、すばらしい問題をありがとうございました！

*1:去年も参加しましたがブログを書いていません。すみません。。

generaldeltaを有効にしてmercurialのリポジトリサイズを減らす

mercurial

Mercurialのリポジトリの履歴のフォーマットは通常のフォーマット以外にgeneraldeltaというものが有ります。

と偉そうに言ってみましたが、NetBSDリポジトリに関するMLのツイートをtwitterで見て初めて知りました。

通常のフォーマットと比べるとリポジトリサイズが小さくなるらしい*1ので、pypyのリポジトリで試してみました。

有効にする

.hgrcに次の設定をしてください。

[format]
generaldelta = true

クローンしてみる

  • generaldeltaを無効にした場合（通常）
% time (hg clone -U --config format.generaldelta=0 --pull pypy pypy-non-generaldelta)
requesting all changes
adding changesets
adding manifests
adding file changes
added 70529 changesets with 223487 changes to 44701 files (+124 heads)
( hg clone -U --config format.generaldelta=0 --pull pypy pypy-non-generaldelt)  152.55s user 19.13s system 61% cpu 4:38.12 total
% du -sh pypy-non-generaldelta
617M    pypy-non-generaldelta
% hg debugrevlog -m -R pypy-non-generaldelta
format : 1
flags  : (none)

revisions     :     70061
    merges    :      4767 ( 6.80%)
    normal    :     65294 (93.20%)
revisions     :     70061
    full      :       394 ( 0.56%)
    deltas    :     69667 (99.44%)
revision size : 288714045
    full      :  55492796 (19.22%)
    deltas    : 233221249 (80.78%)

avg chain length  : 505
compression ratio :  88

uncompressed data size (min/max/avg) : 0 / 916642 / 364444
full revision size (min/max/avg)     : 0 / 222686 / 140844
delta size (min/max/avg)             : 0 / 217544 / 3347

deltas against prev  : 69667 (100.00%)
    where prev = p1  : 58075     (83.36%)
    where prev = p2  :  1057     ( 1.52%)
    other            : 10535     (15.12%)
  • generaldeltaを有効にした場合
% time (hg clone -U --config format.generaldelta=1 --pull pypy pypy-generaldelta)
requesting all changes
adding changesets
adding manifests
adding file changes
added 70529 changesets with 223487 changes to 44701 files (+124 heads)
( hg clone -U --config format.generaldelta=1 --pull pypy pypy-generaldelta; )  297.99s user 30.27s system 69% cpu 7:53.03 total
% du -sh pypy-generaldelta
398M    pypy-generaldelta
% hg debugrevlog -m -R pypy-generaldelta
format : 1
flags  : generaldelta

revisions     :    70061
    merges    :     4767 ( 6.80%)
    normal    :    65294 (93.20%)
revisions     :    70061
    full      :      124 ( 0.18%)
    deltas    :    69937 (99.82%)
revision size : 65592031
    full      : 10731965 (16.36%)
    deltas    : 54860066 (83.64%)

avg chain length  : 491
compression ratio : 389

uncompressed data size (min/max/avg) : 0 / 916642 / 364444
full revision size (min/max/avg)     : 0 / 214457 / 86548
delta size (min/max/avg)             : 0 / 217544 / 784

deltas against prev  : 58927 (84.26%)
    where prev = p1  : 58076     (98.56%)
    where prev = p2  :    90     ( 0.15%)
    other            :   761     ( 1.29%)
deltas against p1    : 10881 (15.56%)
deltas against p2    :   129 ( 0.18%)
deltas against other :     0 ( 0.00%)

ちなみに、リポジトリがgeneraldeltaで保存されているかどうかは.hg/requiresでわかります。

% diff -u pypy-non-generaldelta/.hg/requires pypy-generaldelta/.hg/requires
--- pypy-non-generaldelta/.hg/requires  2014-04-10 11:06:25.000000000 +0900
+++ pypy-generaldelta/.hg/requires      2014-04-10 10:56:47.000000000 +0900
@@ -1,4 +1,5 @@
 dotencode
 fncache
+generaldelta
 revlogv1
 store

結果

generaldelta enable disable
リポジトリサイズ 398M 617M
通常リポジトリからのcloneにかかる時間 7:53.03 4:38.12

今回の例ではリポジトリサイズは40%削減、通常リポジトリからのcloneにかかる時間は70%増加しました。

これくらいなら、サイズが大きくて困っている場合に奥の手として利用できそうです。

*1:NetBSDの場合は15GBから2.1GBに削減されたらしい

#kyon_kao_wedding と #real_dvcs に参加してきました。

mercurial git

きょんさん、かおりさん、ご結婚おめでとうございます！

という事で、参加してきました。

#kyon_kao_wedding

ガチ発表と様々なのろけの温度差にやられました。ご結婚おめでとうございます。ライフ尽きました。

#real_dvcs

アンチパータンがいっぱい紹介されていて興味深かったです。同じ轍は踏まないぞ！的な。 基本的に"仮想"の話が多かったのですが、"not 仮想"の話も有って闇が深かったです。

僕の発表はあまり闇は無いやつでRhodeCodeの細かい使い方の話をしました。

git/hgのリポジトリサーバー、外部のリポジトリのミラーサーバーが簡単に作れるし、WebAPIでミラーとの同期をリクエストできるので、社内用のミラーサーバーとして最適です。

もちろんぷるりを使った開発もできます。Side-by-Side Diffやインラインコメントも有るよ。

「Webアプリエンジニア養成読本」をいただきました。

刊行記念イベントの予約方法の難易度が高いことで話題の「Webアプリエンジニア養成読本[しくみ,開発,環境構築・運用…全体像を最新知識で最初から!]」を技術評論社様からいただきました。ありがとうございます。

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

全編書き下ろしです！

「Webアプリエンジニア養成読本」の名前に違わず、HTTPやHTMLなどの話から始まり、開発ツールの選び方、Webアプリ開発、サーバ構築、サービス運用のためのロギングや監視と、Webアプリ開発に必要となる基礎知識が上から下まで網羅的に解説されています。

ページ数に対して取り扱う内容が多岐にわたるため、各章の内容がとても濃くなっています。僕が原稿のレビューを行った「Webアプリケーション実践入門 Ruby編」の章を例にあげると、

  • Rubyの文法
  • Bundlerを使ったgemの管理
  • 構造化されたSinatraアプリケーションの作成
  • ActiveRecordでDBにアクセス
  • テンプレートの分割
  • セキュリティ
  • バッチ処理
  • rspecによるテスト
  • カバレッジ計測

と身につけて欲しい知識が詰め込まれています。*1 内容もサンプルプログラムもすばらしいので、ぜひ写経してみてください。

どんな人におすすめか

これからWeb開発するエンジニアの方は、このムック本を読んでおけば間違いないです。全体像が把握できます。各章の終わりにおすすめWebサイト、おすすめ書籍の紹介があるので、いけてない情報をつかまされる心配がありません。

すでにWeb開発しているエンジニアの方は、自分の分野がDevOpsのDev側であれば、後半のインフラの部分*2を、Ops側であれば前半のアプリ開発の部分を読むと幅が広がると思います。

*1:同じ筆者の「パーフェクトRuby」から特にWeb開発に必要な部分を引っぱり出して、最新のバージョンとツールに対応&凝縮させた感じでしょうか。

*2:僕はDev側の人間なので、後半のインフラの章や"裏表紙の裏"にある「ITインフラ構築チェックシート」はとても参考になりました。

gitworkflowについての雑感

git mercurial

振られたので。詳しい内容はリンク先をどぞー。

git reset

特徴的というか、僕が「やっぱgitらしいなー」と思ったのは、git reset <branch>を積極的に利用している点です。 gitworkflowでは4種類の統合ブランチを用意していますが、そのうち2種類が使い捨てのブランチというのが面白いです。

  • maint - メンテナンスリリースはここから。時折masterへマージする。
  • master - 機能リリースはここから。
  • next - 使い捨て。機能リリース(masterからのリリース)後にgit reset --hard masterされる。
  • pu - 使い捨て。機能リリース(masterからのリリース)後にgit reset --hard masterされる。

git-flowやgithub-flowはトピックブランチのresetやrebaseはあっても統合ブランチをreset、rebaseすることはありません。

マージ

マージの回数が多く、同じ変更をいろいろな統合ブランチにマージします。

  • バグ修正(基本的にmaintからトピックブランチを作成する)

    • nextにマージ
    • maintにマージ

  • 新機能(基本的にmasterからトピックブランチを作成する)

    • puにマージ
    • nextにマージ
    • masterにマージ

トピックブランチのマージはたくさん発生しますが、統合ブランチ間のマージはmaintとmasterのマージのみ行われます。

  • maintの変更
    • masterにマージ

実験で汚れたpuやnextはgit reset --hard masterできれいに掃除するのでマージは発生しません。

パッチ

うすうす感づいてると思いますが、gitworkflowはプルリクエストを利用するワークフローではありません。

githubのgitのミラーリポジトリの説明には「This is a publish-only repository and all pull requests are ignored」と注意書きがあります。変更を送りたい場合はSubmittingPatchesにある通り、メーリングリスト([email protected])にパッチを投げることになっています。

gitといい、mercurialといい、みんなメールが好きですね。mercurialの方でよく聞かれる主張としては、誰も他人のプルリクエストを見ないし、検索しないので、知識の蓄積ができないというのがありました。gitの方はどんな理由なんでしょうね。(だれか詳しい人おねがいします。)

gitworkflowを使うべきか

前職の仕事でgitworkflowのブランチ運用を採用しようという提案があり、みんなで検討したのことがあるのですが、手間が多すぎるので安定trunkパターン(masterとマイルストーンブランチ)にすることになりました（してもらいました）。

このときは、だいたい次のようなことを考えていました。

  • puにあがった変更の動作を確認する場所がない。
    • テスト環境にはnext相当のものがあがる。puはのせない。
      • 環境を用意するお金の問題も、、
  • リファクタリング、コードの整理はさっさとリリースしたい。何度もマージしたくない。
  • 変更点をnextにマージ後masterに個別にマージするうまみが少ない。
    • マージ漏れはgit logで発見できるが、ちまちまマージするのが面倒。
    • ほとんどの場合、全部マージする(or必要なものだけrevertする)方が簡単。
      • 要望や優先順位は会議で決まる。（あ、開発者も出席してるやつね）
      • 優先順位、マイルストーンで作業しているからやっぱリリースしない！があまり発生しなかった。
        • やっぱリリースしないものはだいたい出来てない機能なので、マージもされてない。
      • 先のやつはトピックブランチのままでもあまり困らない。
  • nextを検証環境で確認しても意味がない。
    • masterとnextの差が発生する場合はテスト環境にのせる意味がない
      • 同じものが本番にリリースされない不安がある
    • masterと差が発生しないならnextいらない(マイルストーンブランチをmasterにマージすればよいじゃん)

まとめると、nextとpuの使い方が請負の仕事には合わなかったという話です。

なので、nextやpuをうまく活用できるのであれば採用できますが、それ以外はさけた方がよいというのが僕の考えです。