YAMAGUCHI::weblog

噛み付き地蔵に憧れて、この神の世界にやってきました。マドンナみたいな男の子、コッペです。

ドイツに行ってきた

misc

はじめに

こんにちは、OpenTelemetry推進委員会です。先々週Velociy Berlin 2019でOpenTelemetryを使って分散トレースを取ってみるという3時間のワークショップの講師をしてきたのですが、初めてドイツに行ったので面白いと思ったところを雑多に記録しておこうと思います。他の旅行記／出張記は以下のとおり。

旅程

都市 日程
ベルリン 11/2-7
フランクフルト 11/7-9

気づき

細かなことはいろいろあるし生活しているとまた違った感想になるのかもしれないけれど、初見で感じたことを残しておきます。

全般的なこと

英語の表示が驚くほど少ない

ドイツに着いてから知ったのですがドイツ語は公用語になっている国は少ないものの、母語とする話者はかなり多いらしく、それもあってか国内の看板、特に駅での表記には英語併記のものがかなり少なかったような印象を受けました。

f:id:ymotongpoo:20191117100152p:plain
フランクフルト中央駅にて
f:id:ymotongpoo:20191117100502p:plain
ベルリン東駅にて

シェア電動キックボードやシェアサイクルが多い

自分は電動キックボードは今年の7月にGopherCon 2019が行われた際にサンディエゴで初めて経験して、いまもKubeConでサンディエゴに来ているのですが、街中で見かけるのはLimeとBIRDとLyftのキックボードでした。

しかし、ドイツ（ベルリンとフランクフルト）では非常に多くのシェア電動キックボードのサービスが展開されていることを知りました。確認しただけでも5社が展開していました。

またシェアサイクルも多く、次の様なサービスが展開しています。

このブログなんかでも紹介されています。

johnnyafrica.com

電車の行き先の表記が省略形のものが多く行き先が分かりづらい

これはある種の初見殺しとも言えるもの。ベルリンやフランクフルトで感じたのは、とにかく駅名が長い！というのも、駅名にたいていその地域（BerlinやFrankfurtなど）の名前が最初についていて、その後に様々な名前が書かれているので長くなります。

f:id:ymotongpoo:20191119074815p:plain
フランクフルト空港最寄りの Frankfurt am Main Flughafen Fernbahnhof 駅

Googleマップなどで行き先を検索するとその途中の一語（たいてい地域名は省略される）が、しかもたまに省略形で書かれていたりするので、ぱっと見てどこに向かっているかわからなくて困りました。

電車やバスが割と時間に正確

これは電車の時間が割と正確な日本*1に住んでいると意識しないけれども、他国の鉄道が主な移動手段ではない都市では平気で予告もなく遅れるし、どれくらい遅れているかすらわからなかったりするので、そういう意味ではベルリンやフランクフルトは「あと何分で駅に来る」というのが常に電光掲示板に表示してあるので安心感があります。そのあたりは日本に近い感覚です。

f:id:ymotongpoo:20191121042924p:plain

ICEは早くて快適

ICE (Intercity Express) はドイツの新幹線です。自分は公共交通機関が好きなので、外国に行ったら危険がなければなるべく現地の公共交通機関に乗ってみるようにしています。ベルリンには日本からの直行便がないため、今回はフランクフルトの直行便に乗り、そこからICEでベルリンまで行きました。（帰りも同様）

f:id:ymotongpoo:20191121042403p:plain

写真を見てわかるように290km/hとなかなかの速度が出ていますが、車両がガタつくこともなく、車内では食事も頼むことができたりとかなり快適な旅でした。車両構成によっては椅子がリクライニングできないのでその部分はちょっと不満でしたが、それ以外は満足でした。（イタリア国内でItaloに乗ったときと同じような車両だったので、納入は同じ会社かもしれないですね）

リサイクルがすごい

ドイツはリサイクル大国として知られますが、ペットボトルや瓶の飲み物にはすべて容器の料金が乗っています。実際にスーパーに行ってリサイクル用の回収機に入れるとそのスーパーで使えるクーポンをもらえます。なのでちゃんとリサイクルすれば10%くらいは割引になります。


ドイツの空き容器回収機

ビールが安い

500mlのビールで€0.80（100円弱）くらいで、しかもリサイクルすると瓶は€0.10くらい戻ってくるので、実質90円くらいになります。やすいので飲み過ぎに注意。

f:id:ymotongpoo:20191121042832p:plain

自転車専用道路が整っている

これはアムステルダムでも感じたことだけれども、自転車専用道路が整備されているところが多く、また歩道でも自転車走行地帯と歩行者通行地帯が分けられている箇所も多かったです。自転車専用信号は日本にもありますが、その数は明らかに差がありました。

f:id:ymotongpoo:20191121043105p:plain

結構喫煙者が多い

北米は喫煙禁止のエリアが非常に多く、日本も最近では路上喫煙に関して非常に厳しい制限がかけられつつありますが、ロンドンでもそうだったように、ドイツでは割と駅前でタバコを吸っている人が多く見かけられました。駅構内ではだめだからと駅の入口のすぐとなりで吸っている人なども多く見かけました。

信号の変わり方が面白い

自分が訪れた国では緑→黃→赤→緑という風に変わるものばかりでしたが、ドイツでは緑→黃→赤→赤と黄→緑で循環しています。


ドイツの信号の切り替わり方 / How German traffic lights changes

クレジットカードの非接触支払いが結構あった

VISAのpayWave、MastercardのPayPassが結構多くの場所で使えることに驚きました。特に驚いたのは駅の切符の自動販売機が対応していて、暗証番号などを入れなくても切符を簡単に買えました。

f:id:ymotongpoo:20191121050015p:plain

ベルリン

カレーブルストはうまい

ベルリンではCurrywurstという庶民の味とも言えるソーセージにケチャップとカレー粉をかけたものをよく食べていました。小さな店の前で雑に立って飲み食いするスタイルで、こういう店は現金しか受け付けていなかったりします。そのあたりもローカルっぽさがあってよかったです。

f:id:ymotongpoo:20191121050747p:plain
軒先で立って飲み食いするスタイル

f:id:ymotongpoo:20191121050836p:plain
トマトケチャップは店によって味が違い、ソーセージを引き立てている

U-bahnは思ったより車両が狭い

市内を走る近距離線は地上を走るS-bahnと地下鉄のU-bahnがありますが、U-bahnは体が大きなドイツ人が乗るには小さいのでは？と思うくらいのサイズ感の車両でした。

f:id:ymotongpoo:20191121051200p:plain

歩行者信号はたまにアンペルマンじゃない

ベルリンの歩行者信号といえばアンペルマンが有名で、現地で初めて生のアンペルマンを見たときは「おお！」と謎の感動があったわけですが、歩いているとたまにアンペルマンではない普通の人形をした歩行者信号もあり、何が基準でそうなっているのか疑問でした。で、Wikipediaで調べたところそもそも旧東ドイツにしかなかったものが、ベルリンの壁解放後に徐々に拡大していったということで、はじめからこうではなかったということを初めて知りました。

f:id:ymotongpoo:20191121051412p:plain
普通の人形になっちゃってた信号機

f:id:ymotongpoo:20191121051622p:plain
アンペルマンの信号機

フランクフルトでの免税手続きに関して

ドイツの有名な工業製品といえばRIMOWAのスーツケースですが、今回の出張で前から買おうと思っていた機内持ち込み用のスーツケースを買いました。その際、当然免税手続きをするわけですが、自分はフランクフルト空港から日本に帰ったので、そこで免税手続きを行いました。

いくつかのウェブサイトで免税手続きの方法を調べて、自分が利用していたJALのウェブサイトでも確認しましたが、機内持ち込みのスーツケースの免税に関して状況が変わっていると思ったことを記録します。（JALのためターミナル2での話）

  • RIMOWAの機内持ち込みのスーツケースの免税に関しては、スーツケースを新品のまま持っていかなくても良い
    • RIMOWAのスーツケースには製造番号が記載してあるため、レシートを持っていれば購入品であると確認できるため、中身を普通に入れて空港に行っても大丈夫
  • 税関は出国審査の直後にあり、グローバルブルーの窓口と横並びになっている。クレジットカードへの返還にすれば数日で返ってくる

f:id:ymotongpoo:20191121052721p:plain
税関窓口とグローバルブルーの窓口が横並びにある

グローバルブルーの書類を郵送で送ってVATの返還をしてもらう話しか見なかったので、実際に窓口に行ったときはあまりの処理の速さに驚きました。RIMOWAでもらったレシートと免税書類を税関窓口に渡し、中身の入ったスーツケースを窓口に出して「これがそのスーツケースです」と伝えたら中身を確認することもなくスタンプをくれます。そのすぐ隣りにあるグローバルブルーの窓口にその書類をそのままそっくり渡したらすぐに受理され、VATを返還してもらうクレジットカード（自分の場合はデビットカード）を渡したら、スワイプしてくれてその場で完了です。帰国後数日でVATが返金されました。「数ヶ月も待つので返金されるのか心配になる」というような話ばかり見ていたので嬉しい誤算でした。

*1:都会の朝夕のラッシュの時間とかは例外として

海外で為替レートや手数料をお得に過ごしたい

misc

はじめに

こんにちは、Stackdriver担当者です。よく本社であったり海外に出張に行くことが多いので、今回ドイツに出張行く前に一度自分の手持ちのクレジットカードやデビットカードでどれが一番海外でお得に利用できるか整理したくなった。

TL;DR

1枚で全部こなすなら、ソニー銀行に必要なだけ円を入れておいて外貨普通預金口座だけ開設しておけば主要10通貨でショッピングとATM両方でお得っぽい。（自分調査なので正確性は保証しません。）

ショッピング

JALカード

自分はJALカードを使っているのでJALカードの例を出すけれどもこのあたりは手持ちのクレジットカードのウェブサイトのFAQなどに必ず載っていると思う。自分の場合はDC発行のVISAなので、外国為替に関して VISAのレートとは別に 2.0% の手数料が乗っかってくる。

金額の計算はこちらの計算機で確認できる。

usa.visa.com

ただJALカードの場合通常で200円で1マイル、最大で100円で1マイルたまるので、USDの場合、1USDでだいたい1マイル貯まることを考えると、実質1.0-1.5%前後の手数料と言えなくもない。

ソニー銀行

moneykit.net

ソニー銀行の為替レートではUSDのスプレッド15銭で、しかもショッピングの場合は手数料が無料になっている。またクレジットカードの場合と同様に不正利用に関しても保証があるので、普通にクレジットカードを利用するのと同じ感覚で使える。また使ってトランザクションが発生してすぐにメールでどこでいくら使ったかが通知が来るので、不正利用自体にも気づきやすい。万が一それに気づかなかったとしても銀行の預金口座以上に使われることがないのは助かる。

しかも外貨預金普通口座の残高が足りない場合でも円普通口座から自動でその時のソニー銀行でのTTSで両替してそれ以外の手数料がかからないので、スプレッドの15銭だけしかからない。割合に換算すると手数料 0.1% ということになる。安い。 あと「優遇プログラム Club S」というのがあって、口座残高に応じてスプレッドが4銭にまで下がるらしいけど、そんなに入れてしまうと自分のデビットを使う目的の一つである「口座の額以上に使われることがないから安心」という保険的な利用方法に当てはまらなくなってしまうので、今回はその部分は検討しない。

JAL Global WALLET

為替レートが載っているが、2019年11月13日現在での為替レートで見ると片道1.3円取られている。

ご利用方法｜両替｜JAL Global WALLET

f:id:ymotongpoo:20191113095135p:plain
2019年11月13日現在の為替レート。この時のTTMは109.18円

為替レートで変動すると思うが、割合で換算すると 1.3% が手数料。

SBI銀行VISAデビット付きキャッシュカード

こちらはUSDで見ると為替レートではソニー銀行よりも安いスプレッド4銭。海外事務手数料は2.5%だけれども、30回までは「ポイント」でキャッシュバック。これをどう捉えるかで変わってきそう。自分は正直SBI銀行のポイント（スマプロポイント）で返ってきても嬉しくないので、その点は無視する。

キャッシング（海外ATM利用）

JALカード

自分のもってるJALカードの発行会社がDCカードなのでそれの引用だけれども、基本的にキャッシングは海外だろうが国内だろうが金利は変わらない。繰り上げ返済すれば金利は安くなるけれど、忘れてしまった場合の金利は高くなる。また為替レートはVISAのレート（上述）と同じなので、両替所よりは安いかもしれないがあまり割のいいものではない。明記されていないがATMの手数料も別途取られる。

ソニー銀行

ショッピングの場合と同様、外貨口座を開設しておけばUSDのスプレッド15銭だけで、手数料が現地のATM手数料＋1.79%の事務手数料となる。たとえば2019年11月13日現在、100USDを下ろす場合、1.79USDが事務手数料なので、日本円だと200円弱取られることになる。

JAL Global WALLET

ATM手数料に関しては200円相当額と固定なのは素晴らしい。しかし、レートがいまいちなので、下ろす金額にもよるけれど、そこまでソニー銀行と変わらない気がする。

SBI銀行VISAデビット付きキャッシュカード

海外ショッピングの場合と同様。手数料2.5%がスマプロポイントで返ってくるけれど、自分は特にほしくないので無視。ATM利用料は別途徴収される。（ソニー銀行と同じ）

参照

GitHubのPull Requestからpatchを取得して試す

GitHub

はじめに

こんにちは、OpenTelemetry推進委員会です。OpenTelemetryのワークショップをしにベルリンに来ているんですが、そこで事前準備をしていたところ、ワークショップのコードがupstreamの直近の変更で動かなくなり、あわててcohostがPull Requestを投げました。これを承認前に自分で手元で試すためにPull Requestだけのパッチが必要になったけれども、そういえばやったことがないなと思って調べたところ、非常に簡単だったのでメモしておきます。

パッチファイルを持ってくる場合

$ cd /path/to/repo
$ wget https://github.com/username/reponame/pull/:pull_number.patch
$ git am -3 number.path

もしくは hub コマンドを使って

$ cd /path/to/repo
$ hub am -3 https://https://github.com/username/reponame/pull/:pull_number.patch

.patch のURLについて

「ドキュメントに書いていない裏技！」みたいな感じで書いてあるブログ記事がたくさん、あって「本当にそうなのか？」って思って調べてみたところ、たしかに丁寧には書いてなかったが一応公式ドキュメントのAPIレスポンスの中にそのURLが含まれていることは確認した。

developer.github.com

同じようにしてdiff形式のファイルも取得できる。

git am の -3 オプション

git am で 3way merge をする際のオプション。そこまでややこしいパッチを試したことがなかったので使ってなかったけど、とりあえずここではメモのためにつけておく。

ブランチを取ってくる場合

てっきり次のようにしてフォークされたブランチを取ってくるのかと思っていました。

$ git fetch git@github.com:username/forked-repo branchname

しかしGitHubはremote refのエイリアスを用意してくれていたんですね。

help.github.com

$ git fetch upstream pull/ID/head:branchname

ヘルプを見るとレポジトリの書き込み権限がないとできなさそうな雰囲気で書いてるけれど、普通に全然関係ない人でも取れました。

両方あるけどどっちがいいの

git fetch 一回で取ってこれるのでブランチを取ってくるほうが楽そうですね。

じゃあpatchやdiffの方はいらないかというと、patchとかdiffの場合はprivate repoでも一時的にURLを生成して外から取ってこれるので、クリーンな環境でパッチを当てなければいけないときに便利です。

Jaeger のall-in-oneコンテナを最速で公開する

Jaeger Google Compute Engine

はじめに

分散トレースのバックエンドのOSSとしては Zipkin とならんで Jaeger が有名です。Jaegerは複数のコンポーネントから成立していますが、それらをきちんとプロダクション環境用にセットアップしようとするとストレージをきちんと用意したり Docker Compose などを使う必要があります。しかし、自分の用途だとデモ用などに使う all-in-one のコンテナ（ jaegertracing/all-in-one ）をさっと上げて公開したいことがあり、どうするのが一番手数が少ないか考えた結果次のようになりました。

やってみた

$ gcloud compute firewall-rules create jaeger-rules \
    --allow udp:5775,udp:6831,udp:6832,tcp:5778,tcp:16686,tcp:14268,tcp:9411 \
    --direction ingress \
    --priority 1000 \
    --target-tags jaeger

Creating firewall...⠏Created [https://www.googleapis.com/compute/v1/projects/playground-219502/global/firewalls/jaeger-rules].
Creating firewall...done.
NAME          NETWORK  DIRECTION  PRIORITY  ALLOW                                                             DENY  DISABLED
jaeger-rules  default  INGRESS    1000      udp:5775,udp:6831,udp:6832,tcp:5778,tcp:16686,tcp:14268,tcp:9411        False


$ gcloud compute instances create-with-container jaeger-vm \
    --preemptible \
    --container-image jaegertracing/all-in-one:1.14 \
    --boot-disk-size 30GB \
    --tags jaeger

WARNING: You have selected a disk size of under [200GB]. This may result in poor I/O performance. For more information, see: https://developers.google.com/compute/docs/disks#performance.
Created [https://www.googleapis.com/compute/v1/projects/playground-219502/zones/asia-southeast1-b/instances/jaeger-vm].
WARNING: Some requests generated warnings:
 - Disk size: '30 GB' is larger than image size: '10 GB'. You might need to resize the root repartition manually if the operating system does not support automatic resizing. See https://cloud.google.com/compute/docs/disks/add-persistent-disk#resize_pd for details.

NAME       ZONE               MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
jaeger-vm  asia-southeast1-b  n1-standard-1  true         10.148.0.3   XX.XXX.XXX.XXX  RUNNING

立ち上がったので適当に curl でJaeger UIの疎通確認をしてみます。

$ curl -I http://XX.XXX.XXX.XXX:16686/
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Tue, 08 Oct 2019 05:56:03 GMT

できた。だいたい１分かからないくらいで公開できました。

決してプロダクション環境用ではないので使ったらすぐに落とすこと。

クレジットカードの差替えをしたが意外に手間は少なかった

misc

はじめに

いまや多くの会社が「キャッシュレスだ、ペイメントだ」とペイメント事業に乗り出し、経済産業省もキャッシュレス・消費者還元事業などの施策を打ち出して、日本全体でキャッシュレスが一大ブームになっている昨今ですが、セブンペイの不正アクセスなどもあり、セキュリティに関する懸念も広く一般的に認知されました。

図解とQ&Aですっきりわかる! 絶対得するキャッシュレス決済超入門

図解とQ&Aですっきりわかる! 絶対得するキャッシュレス決済超入門

そんな不正アクセスに関して、キャッシュレス界隈において長らく取り組んでいる業界と言えばクレジットカード業界です。不正利用に関してはかなり高度なシステムによって検知しています。しかしながら、現状の仕組みとしていわゆるクレジットカード番号（プライマリアカウント番号、PAN）、セキュリティコード（CVV2、CVC2など）、有効期限、そして所有者の氏名という、すべてカードの表面に記録されている情報で決済ができてしまうため*1、一度それらの情報が漏洩してしまうと不正利用の対象となる危険性が格段に上がります。

クレジットカードのイシュアーはこうした危険を事前に察知して情報漏洩があった場合、あるいは不正利用が多発した加盟店などがあった場合、利用したカードを差替える措置などを取っています。今回はそういう連絡が来て、実際にカードの差替えを行ったあとにどれくらいの手続きが必要になったかの記録をしました。

三菱UFJニコスからの連絡

ある日三菱UFJニコスから一通の封書が届きました。開けてみると「クレジットカード差替えに関するお願い」と書いてあります。

www.cr.mufg.jp

中を読んでみると、次のような文言がありました。

お客様が以前ご利用になった一部の店舗が犯罪集団によるカード情報の不正詐欺に遭った疑いがあり、カード情報が流出した可能性が極めて高いことが判明いたしました。

ただ事ではありません。普段から利用明細には目を通しているものの、こういった連絡が来るとあらためて不安になります。その後次のような連絡が太字で書かれていました。

お手持ちのカードを新しい番号のカードへ差替えさせていただきたく、同封のカード差替え承諾書のご返送をお願い申し上げます。

そうせざるを得ないのは分かるのだけれども、その後困ったことに次の事柄が判明しました。

  1. 承諾書が三菱UFJニコスに到着次第、使用中のカードは無効になる。
  2. 新しいカードが到着するまでに1週間〜10日かかる。
  3. 光熱費関係以外はクレジットカード経由での引き落としは更新する必要がある。

まず2番めがかなり不便で、その10日間メインカードが利用できないということになるわけです。また3番めも非常に不便です。ネット回線等、ネット上で引き落とし先のカード情報を更新できないサービスにすべて手続きの申し込みをしなければなりません。

2番めに関しては、1週間メインカード無しで過ごす実験でしたが、モバイルSuicaや他のカード、ペイメントサービスの残金などでキャッシュレス決済はまかなえてしまいました。案外何とかなるものですね。

カード情報を更新しなければならなかったサービス

3番めの各種サービスの引き落とし先クレジットカード情報の変更ですが、当初は書面による手続きが結構あると思って、めんどうで嫌だなと思っていたけれど、よくよく調べてみると光熱費以外の手続きはすべてオンラインで完結しました。また今回の差替えでは光熱費（東京ガス、東京電力、東京水道局）に関してはカード会社側で変更してくれたので、すべてオンラインで完結。思っていたよりは世の中進んでました。

ブラウザやAndroidのカード情報補完がすごく便利だった

Google Chromeをはじめ、最近のブラウザにはカード情報をフォームに自動補完する機能があります。

support.google.com

今回の更新でも、パソコンで作業していた時は結構自動補完で入力できたので楽でした。またモバイル系の更新はAndroidでやっていたけれど、AndroidがGoogle Payの情報に基づいて同様に補完してくれました。

*1:3Dセキュアなどもありますが、それですら少数派

ぎっくり腰になってすぐに海外出張にいくことになった

misc

はじめに

人間は年を取るといろいろなところに支障がでてくる。自分はこれまで大きな病気やケガもなく、一番大きな病気で記憶にあるのはノロウイルスに感染して脱水症状をおこしかけたくらいで、ほかは入院の経験もない。ケガも中学の頃に左手首にヒビが入ったくらいで、多少は捻挫等のケガはあったものの、松葉杖、車椅子での生活、あるいは入院といったこともなかった。

そういった経緯もあり、今回ぎっくり腰になって酷くうろたえた。特に痛みのピークでは病院にたらい回しにされたストレスもあり、ひどく落ち込んでいた。さらに翌週には海外出張も控え、非常に不安であった。そうした体験はあまり得られないため、記録のためにここに記そうと思う。

なお過去に似たようなモチベーションで記録を残したものには次のようなものがある。

ymotongpoo.hatenablog.com

ymotongpoo.hatenablog.com

TL;DR

ぎっくり腰後に海外出張に行くことになったらサーモス系のスープジャーなどに氷で冷蔵しながらボルタレン坐薬を持ち運ぶと安心感がある。

サーモス 真空断熱スープジャー 300ml グリーン JBU-300 G

サーモス 真空断熱スープジャー 300ml グリーン JBU-300 G

ぎっくり腰時系列

  • 8/19 16:30頃: 重いものを持ち上げた拍子に腰（仙骨あたり）でなにかずれた感覚があって直感で「あ、やっちゃった」と感じる。幸いまだ動けたので歩いて帰宅。痛いながらも一日過ごす。
  • 8/20 8:00頃: ベッドから起きると通常の生活に著しく支障をきたすレベルの痛みがあり、椅子になんとか座るも姿勢を変えることができない。近所の病院に電話しまくり外来できるところに行くことに。
  • 8/20 10:00頃: 病院に着いて生まれて初めて車椅子を体験する。便利。その後診察とレントゲンを撮り、問診・触診等の結果と併せて、椎間板ヘルニアではなさそうということで鎮痛剤を処方してもらって帰宅。帰りは歩いて帰れた。
  • 8/21-23 終日: 相変わらず朝は痛いものの、8/20の朝ほどではない。鎮痛剤のおかげもあって、朝数時間すると普通に生活はできる程度になる。
  • 8/24 9:00頃: ぎっくり腰は早ければ3日で痛みが収まると言われているが、相変わらず朝はかなり痛いので、月曜日から海外出張で不安もあるため、念の為近くの個人医院（整形外科）に診察してもらう。やはり最初の診断と同様、椎間板ヘルニアではなく、仙骨周りの靭帯の損傷でしょうとのこと。鎮痛剤（坐薬）が切れたので追加で処方してもらう。
  • 8/25: 朝の腰の様子はかなり改善された。しかしながら全快ではなく、重いものを持ち上げる動きには依然として不安が残る。
  • 8/26 6:00頃: 出張の出発当日。やはりベッドから起きたときの痛みは弱くなってはいるが、10時間を超えるフライトを待つ身としては不安がある状態。飲み薬と坐薬を服用。
  • 8/27: 起床すると多少の傷みはあるものの普通に生活できる感じではあるが1日イベントなので念の為飲み薬と坐薬を服用。
  • 8/28: 起床したときの腰の痛みはないが、多少動くと響くような感じがあるため、飲み薬のみ服用。
  • 8/29: 起床したときの腰の痛みはなく、違和感もあまり感じない。飲み薬の服用もせず、10日ぶりにジムに行く。少し負荷をかけるとちょっと違和感があるので無理はせず、懸垂を数種目とゴブレットスクワットを軽く。
  • 8/30-31: 一日外出して歩いていると腰が妙にだるくなる。調べてみるとどうもぎっくり腰回復期特有のだるさのようだ。坐薬は使用せず飲み薬のみ服用。
  • 9/1-2: 帰国の日。12時間超のフライトで、フライト中に6時間程寝ると腰が硬く痛みを感じる。飲み薬を服用し、体を少し動かすと痛みがなくなった。

ぎっくり腰発症直後の病院の対応

巷には「整骨院／鍼灸院に行ったらすぐ良くなった！」という話もあり、実際効果がある場合もあるのだろうけど、いわゆるぎっくり腰というのは俗称であり、実際には椎間板ヘルニアを含むさまざまな症状があるため切り分けが必要である。特にぎっくり腰が起きる腰椎は下半身の運動を司る神経が通っているため、迂闊に民間療法などを試みて後遺症が大きくなると目も当てられない。

自分も症状が起きた直後に痛い体をなんとか動かし、すぐに自宅周辺の整形外科の電話番号を調べた。しかしながらどこに電話しても予約でいっぱいで外来で行くしかない。今となっては笑える話ではあるが、電話越しに定形文で「外来で来ていただくほかありません。来ていただいた場合2-3時間お待ちいただくことになります。」と言われるたびに、仕方ないとは言え「激しい痛みに耐えながらも必死に電話してきた人間に対して返す言葉ではないだろう」とやり場のない怒りを覚え、それが3軒めともなるといよいよ社会保険制度まで含めた怒りに発展しかけた。

最後に電話した病院も同様の定型文を返されたものの、あまりの痛さに悶絶していたところ途中で整形外科の看護婦が電話で対応してくれ、さまざまにトリアージであろう質問をしてくれた上で、家にイブプロフェンがあることを伝えると、少しでも鎮痛作用があるのであれば服用してから外来に来ることを勧めてくれた。また来院したら窓口に言えば車椅子に乗れることも教えてくれたのも大変ありがたかった。やり取りとしては1分程度だったが、こうしたやり取りがあるだけで病院に対する信頼度はまったく変わるものである。自分の仕事においても大変参考になる対応だった。

ボルタレン坐薬関連

ボルタレン坐薬が効くまでに掛かる時間

坐薬を入れるとトイレに行きたくなる。浣腸もそうだけれども、腸を刺激する行為を多少なりともするわけだから仕方がないといえば仕方がない。しかし、きちんと鎮痛剤の効果が発揮されるまで待たないと意味がない。したがってトイレを我慢することもあるわけだけれども、無意味に我慢をしたくないので調べてみた。

www.fpa.or.jp

こんな直球な質問あるかと思ったけど、検索する側としては助かった。40分待てば一応大丈夫そうだ。

健常男子による実験では、挿入後40分程度でほぼ吸収は終了するので、その時間の排便を我慢すれば効果が得られると推察される。挿入後早期（20～30分）で排便した場合、Ｃmaxは挿入後40分後に排出と同等であったが、ＡＵＣの低下やＴ1/2の短縮がみられたので、作用持続時間が短縮することが予想される。

ボルタレン坐薬の海外への持ち運び

最初の病院で処方された鎮痛剤は飲み薬と坐薬の2種類、2回めの病院では坐薬のみの処方だった。この両者で処方されたボルタレン坐薬（ボルタレンサポ）は非常に強力な鎮痛剤であると同時に、これがあるおかげで起床後の痛みから解放され、人間的な行動ができるようになる。痛みは抑えられているとはいえ無理な活動をすることは勧められることではないが、海外出張ということであれば仕方がない。しかし現地で痛みで活動ができないのは残念というほかないため、この坐薬を携行して備えたくなるのが人情である。特にボルタレンサポ50mgはてきめんの鎮痛効果を見せるため、某界隈では「人権」と呼ばれている。

ところでここで問題がある。坐薬は体温で溶けて吸収されるようになっており、場合によっては外気温で溶けてしまうため、冷蔵保存を求められる。しかし海外出張にこれを持っていくとなると、飛行機でも運べる冷蔵の手段を考えなければならない。たとえば日本の航空会社2社では次のように冷蔵に関しては搭乗者自身で手段を講じることと記載している。

機内にはお薬を冷蔵できる設備はございません。ご自身で保冷容器をご準備ください。

機内では薬剤のお預かりや冷蔵はできません。ご自身で保冷容器等のご用意をお願いします。

したがって保冷容器を確保する必要がある。*1家にはピクニックなどで使う簡単な保冷バッグしかないので、もっと保冷機能が強いものが必要だ。そこで次のサーモスのスープジャーを購入した。

サーモス 真空断熱スープジャー 300ml グリーン JBU-300 G

サーモス 真空断熱スープジャー 300ml グリーン JBU-300 G

スープジャーの中に坐薬を入れ、さらに周りを凍らせた保冷剤で囲んでなるべく低温で運ぶ作戦である。持ち込みの手荷物で運ぶことを想定しているため、保冷剤は100ml以下のもので小分けされているものを使う必要がある。（国際線の規則で100mlを超えるジェル・液体の持ち込みは禁止されている）スープジャーの中に保冷剤を入れていくため、保安所で保冷剤を破棄するよう指摘される可能性があるが、その場合に備え一応保安所を通過するためだけに保冷剤だけ取り出せるようジップロックを持っていく。（液体はジップロックで見えるようにすることが求められる可能性がある。）また最悪保安所で保冷剤の破棄をすることになっても、出国さえしてしまえばラウンジや機内で氷は手に入るため、再冷蔵は可能であろう。*2

実際にこの方法で朝6:30に家を出て、日本時間24:00にホテルの冷蔵庫に坐薬を移すまでおよそ17時間半手荷物のバックパックに入れて運んだ。懸念していた保安所での検査は成田では事前に「ここに要冷蔵の薬を保冷剤と一緒に入れています」と申告したら、普通のX線検査をしただけで特に中を開けて確認をされるようなことはなかった。

写真はホテルに着いた直後のものだけど、容器内下側に見えるものは家で冷凍したジェルの保冷剤で、上半分は機内で溶けた保冷剤と置き換えたもらった氷。見ての通り、氷は形をしっかりと維持している。確認した限り、機内でもらったときとほぼ大きさは変わっていない。

帰りが厄介で、ホテルの冷蔵庫には冷凍庫がないため、行きに使った保冷剤を再度凍らせることができず、とりあえず空港まではホテルの氷ベンダーで氷を詰めてから行った。保安所前で氷を捨ててから保安検査を通って出国、その後適当に氷をもらって詰め直すという感じで乗り切った。帰りの機内でも溶けた水を切って氷を1度足して、あとは普通に帰宅。ホテルを出てから20時間程度は経過していたが、保冷剤でない普通の氷でも持ち運べることがわかった。以下は帰宅直後に冷蔵庫に入れる直前の写真。

鎮痛剤の現地（アメリカ）での入手に関して

確認した場所がシカゴの特定のWalgreensとCVS Pharmacyだけだったので、あくまで一例としての参考程度にしてもらいたいが、鎮痛剤の棚を確認してもほとんどがアセトアミノフェン、イブプロフェン、ナプロキセン、アスピリンのどれか。*3 同じ非ステロイド系消炎鎮痛剤とはいえ、ボルタレンが該当するジクロフェナク系の鎮痛剤は置いていなかった。

インターネット上で確認しても、アメリカでも入手には処方箋が必要なようだ。

www.drugs.com

Both diclofenac and ibuprofen are available in various strengths. In the USA only the lower strength tablet ibuprofen 200mg is available OTC, the 400mg and 600mg tablets are prescription medicines. Diclofenac is only available by prescription in the USA but in some countries a lower dose 25mg tablet is available OTC.

感想

ぎっくり腰は最悪だ。しかし椎間板ヘルニアではない、いわゆる一般的な「ぎっくり腰」であれば、おおよそ4日-1週間程度で日常生活はできる程度に回復するという情報は実際に体感できた。

f:id:ymotongpoo:20190902214621p:plain
回復までの経過図
（図はこちらのサイトより https://www.shimon-c.jp/indication/lbp-acute/）

先達が口を揃えて「クセになるぞ」と脅してくるので、非常にストレスがたまる。しかし一度経験するとどのような経過をたどるのか、おおよそ想像できるようになるので、次回なってもストレスは今回よりは少ないだろう。もっとも二度とならないのが一番良いのだが。

参照

*1:ネット上で調べてみると外気温でも溶けなかったし大丈夫だ、というような体験談も見かけたが、万が一ダメだった場合は業務に致命的な影響を及ぼすため、安全のために極力冷蔵する方向で検討した。

*2:購入後にスープジャー内に氷だけ詰め32℃の屋外に放置し5時間後に取り出してみたところ、ほぼすべて氷が溶けずに残っていた。

*3:アスピリンは前者3つに比べると少ない

特定のコミットメッセージを持つコミットの詳細なコミットログを一覧で見る

git

はじめに

こんにちは、Stackdriver担当者です。いまGoのコミットを調査していて必要になったので調べていました。

ユースケース

Go本体にコントリビュートする場合、コミットメッセージの形式が次のように定められています。

math: improve Sin, Cos and Tan precision for very large arguments

The existing implementation has poor numerical properties for
large arguments, so use the McGillicutty algorithm to improve
accuracy above 1e10.

The algorithm is described at https://wikipedia.org/wiki/McGillicutty_Algorithm

Fixes #159

最初の行では変更を加えたパッケージ名をまず書いた後に、コロンを挟んで1行でコミット内容を説明します。空行を挟んで、2パラグラフめ以降に詳細なコミットメッセージを書いていくわけです。

今回、cmd/compile パッケージに加えられたコミットのコミットメッセージをすべてみたいという要求があり、結果次のようにして一覧しました。

% git log --oneline --grep "cmd/compile" | cut -f 1 -d ' ' | xargs git show --abbrev-commit --quiet

この様に表示されます。

% git log --oneline --grep "cmd/compile" | cut -f 1 -d ' ' | xargs git show --abbrev-commit --quiet
commit fbde753a58
Author: Keith Randall <keithr@alum.mit.edu>
Date:   Tue Jun 25 22:24:34 2019 -0400

    cmd/compile: make duplicate anonymous interface output deterministic
    
    Taking over CL 162240, the original CL hasn't been making progress.
    I just took the parts that fix the immediate issue. I left the
    signatslice changes out, I don't think they are necessary.
    
    Fixes #30202
    
    Change-Id: I5b347605f0841dd925d5a73150b8bf269fa82464
    Reviewed-on: https://go-review.googlesource.com/c/go/+/183852
    Run-TryBot: Keith Randall <khr@golang.org>
    Reviewed-by: David Chase <drchase@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>

commit 4ea7aa7cf3
Author: Cherry Zhang <cherryyz@google.com>
Date:   Tue Jun 25 14:48:04 2019 -0400

    cmd/compile, runtime: use R20, R21 in ARM64's Duff's devices
    
    Currently we use R16 and R17 for ARM64's Duff's devices.
    According to ARM64 ABI, R16 and R17 can be used by the (external)
    linker as scratch registers in trampolines. So don't use these
    registers to pass information across functions.
    
    It seems unlikely that calling Duff's devices would need a
    trampoline in normal cases. But it could happen if the call
    target is out of the 128 MB direct jump limit.
...

他にもっといい方法があったら教えてください。

追記 (2019.07.08 19:00)

いくつか助言をいただいたので、その後諸々検討してみました

% git log --oneline src/cmd/compile | wc -l
3951

% git log --oneline --grep "cmd/compile" src/cmd/compile | wc -l
3673

% git log --oneline src/cmd/compile | grep "cmd/compile" | wc -l
3654

% git log --oneline --grep "^cmd/compile" src/cmd/compile | wc -l
3080

この中でどれが自分の本当に求めているログに絞れているのかと考えてみると、おそらく3番目のもので、理由は

  1. Goのコミットメッセージの規約は守られていると仮定して、--grep="cmd/compile" としてしまうと、2パラグラフめ以降にだけ cmd/compile が入っているものが含まれてしまう。
  2. "^cmd/compile" としてしまうと、1行目の対象パッケージの部分で、 runtime, cmd/compile: となっているようなコミットが漏れてしまう。

が挙げられる。したがって今回自分がみたいログを見ようと思ったら

% git log --oneline src/cmd/compile | grep "cmd/compile" | xargs git show --abbrev-commit --quiet

が正解になると思う。

GoogleのDeveloper Relationsチームは何をしているのか

misc

はじめに

こんにちは、Stackdriver担当者です。

これまで「Developer Relationsは何をする組織なのですか」「Developer Advocateってどんな仕事をしているのですか」といった質問をしばしば受けてきました。都度考えながら答えていたのですが、今後のためにこの記事にまとめておこうと思います。

The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success

The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success

Amazon

Developer Relations とは何か

XXX Relationsとは何か

自分は Developer Relations を語る前に、まず世の企業内で見られるような他の「XXX Relations」というタイトルの組織について考えていくと整理しやすいのではないかと考えています。

  • PR (Public Relations; 広報): 一般大衆に向けて企業の情報を伝達し、同時に一般大衆から意見や情報を受け入れるための組織
  • IR (Investers Relations): 投資家に向けて企業の経営状況や財務状況を伝達し、同時に株主を主とした投資家からの意見や情報を受け入れるための組織
  • GR (Government Relations): 企業が政府や行政と関係を結び、企業が実現しようとしている目標に関係する法令や規制に関してのスムーズな意見交換を実現する組織

とこのように「XXX Relations」と呼ばれる組織は名前の通り 対象の人間や組織と関係を作り、そこで必要とされる情報を伝達し、同時に意見や情報を受け入れる 組織であるとわかります。

Developer Relations の定義

先の話を前提として、自分はDeveloper Relationsを次のように定義しています。

開発者や企業に向けて自社関連技術を伝達し、同時にそれらに対する意見や情報を受け入れるための組織

これを分解して考えていきます。まず前半の「開発者や企業に向けて自社関連技術を伝達し」の部分。これに関しては注意をしないといけないと考えています。

このツイートでも書いていますが、よくDeveloper Relationsでは開発者イベントを開催したり、登壇したりするだけが仕事だと思われているようですが*1、それは一部でしかありません。

開発者に自社関連技術を伝える仕事としてはイベント関連を含めて多岐に渡ります。たとえば自分の職種であるDeveloper Advocateでは次のような仕事に関係しています。

  • 開発者イベントの企画、開催
  • 開発者イベントでの登壇
  • 開発者コミュニティとの連携
  • 技術資料の作成（公式ドキュメント、ブログ、動画など）
  • サンプルコード、参照実装、デモの提供
  • クライアントライブラリ、SDK、APIの提供
  • OSSの開発
  • PRやGR、ビジネス開発などに対する技術面での後方支援

また後半の「自社関連技術に対する意見や情報を受け入れる」に関しても活動も多く

  • 各種標準団体や重要なOSSに参加・連携
  • 主要ユーザー（企業等）との定期的なディスカッション、ヒアリング
  • 新規技術や機能を導入する企業への技術支援

上記で集めた意見や情報を自社製品や関連技術の改善につなげるために

  • 社内の他の技術職（ソフトウェアエンジニア、プリ・ポストセールス系の各種エンジニア、サポート系エンジニアなど）との技術・情報の共有
  • プロダクトマネージャーやソフトウェアエンジニアと製品や機能に関してディスカッション、PRDやDesign Doc*2へのフィードバック
  • GDEへの情報提供含めたディスカッション

といった仕事も多く行っています。（むしろ日常業務はこれらがすごく多い）*3

これらを見ると他の組織と重複する仕事も多いですが、GoogleのDeveloper Relationsチームでは「最終的に開発者のメリットになるのか」という点が最重視されていて、営業的な数値目標で意思決定がされるわけではありません*4。個人的にはこの点において営業組織との棲み分けが強く働いていると思います。社内にいながら、ときには開発者視点でみて、外部開発者に導入を積極的には勧めない、あるいは様子を見るように伝えることもあります。また外部開発者の視点で開発チームに修正を求めるフィードバックも多々行います。

Google の Developer Relations に所属する役職

Google Careers のサイトに Developer Relations に属する役職などの説明動画があります。（動画自体は少し古いですが、内容は変わっていません）

https://www.google.com/intl/km/about/careers/teams/client-facing/dev-rel/www.google.com

Developer Relationsチームに所属する職種は細かくみるとこれよりも多いのですが、主要な職種は次のとおりです。

  • Developer Advocate
  • Developer Programs Engineer
  • Developer Program Manager
  • Technical Writer

これらの役職はおおよそ次のように分かれています。

  • Developer Advocate (DA): 対外的な仕事が多く、担当領域に関してイベントでの登壇や外部の開発者への技術支援、担当製品のフィードバック収集などをよく行う。
  • Developer Programs Engineer (DPE): SDKやサンプルコードの開発などがメインだが、対外的な登壇もあったりする。
  • Developer Program Manager (PgM): コミュニティ（例: GDG、GCPUG）との連携やオフライン／オンラインイベントの開催などを重点的に行う。
  • Technical Writer (TW): 公式ドキュメント（Google DevelopersやGoogle Cloudの各種ドキュメント）の執筆

（追記 2022.09.01 いまはDAとDPEの職のオーバーラップが多かったため、Developer Relations Engineerというタイトルになり、両者の垣根はなくなりました。外部的には過去の役職名のままの人もいますし、変えている人も居ます。）

これらがすべてきっちりと分かれているわけではなくて、たとえば自分はクラウドチームのDAですが、GoやOpenCensusといったOSSのコミュニティとの連携を業務の中でも重視していますし、サンプルコードやPoCコードを書くことが多々あります。

WebチームのDAのえーじさんはいまはWebAuthNの普及に務めつつ*5、長年一貫してWeb関連のコミュニティ支援を行っています。

DPEである@yuichi_araki（通称: 課長）は、メイン業務ではRoomの開発をしつつ、コミュニティでの登壇やハンズオン講師なども必要に応じて行っています。

Program Managerであるたくおさんも、コミュニティ支援やイベント企画だけでなく、デザイン系のイベントでの登壇などもよく行っています。

他にもチームメイトが各々に異なる技術領域をカバーしています。このように各職種に大きな枠はありつつも、最終的に「ユーザーである外部開発者と社内の開発チームをつなぐ橋」として成立すれば、自分が実行したほうが良いと思ったことを裁量を持ってなんでもできるというのがGoogleのDeveloper Relationsです。

追記: 2025.10.03

今年2月に開催されたイベントでDeveloper Advocateという職種について私が仕事として行ってきたこと/行っていることを話したので、その資料もリンクしておきます。

speakerdeck.com

おわりに

そもそもこれを書こうと思った理由は先日開催されたイベントの名前を見て面白さを感じたからです。

ここでは「SA (Solution Architect)」の人たちが集まっていたようですが、各社でSolution Architectの職務の定義は違っているはずです。X社ではプリセールスという認識で、Y社ではポストセールスとして扱われていたりするでしょう。そうした人たちが同じ職種であるということで集まって活動内容をシェアするというのは、その職種に共通する性質を知る近道なのかもしれません。

最近は日本でもDeveloper Relationsという組織を持つ企業が増えてきました。先に挙げたPR、IR、GRが会社の特性に合わせて異なった活動をしているのと同様に、各社のDevRelの活動は大まかには近しいとしても、企業によって変わってきます。しかし、その「大まかに近しい」活動の内容が「重要である」と認識されれば、個人的には自分のキャリアパスも広がるので嬉しい限りです。

日本でもDevRelConが開催されていますが、こうした活動が広がってDeveloper Relationsの重要性が認識されることを願っています。

参照

*1:実際にイベントでそのように聞かれたことが多々あります

*2:Product Design Doc; プロダクト要求仕様書、Design Doc; 設計仕様書

*3:他にも上記以外にやってそうだけど自分がパッと思いついたのはこれくらい

*4:目標設定に関しては営業的な数値目標を持つことを禁止しているわけではなく、優先度が違うという意味です。

*5:リンク先のWebAuthNの記事もえーじさんが書いたものですね

Go Conference 2019 SpringのPaperCallを初めて使ってみた感想＋α

misc

はじめに

こんにちは、Stackdriver担当者です。先日、Go Conference 2019 Springのセッションの応募にはじめてPaperCallというCfP as a Serviceを使ってみました。

www.papercall.io

使ってみての感想がいくつかあったので忘れないうちにメモしておこうと思います。

運営として

これまでGoConでのCfPはGoogle Formで作ったテキストエリアにただAbstractとDescriptionの中間くらいの分量のものを書いてもらって、その内容だけで判断していたのですが、今後のイベントとしての方向性を考えてPaperCallを使ってみました。

運営としてPaperCallがいいなと思った点は

  • コミッティーがセッションに求める内容をCfP Descriptionをきちんと書ける
  • 世界のコミュニティーに直接リーチできる

の2点です。

CfP Descriptionが書ける

今回のCfPでは、セッションとしてどういう内容を期待しているか、を書いていました。（そして応募されたProposalのうちの かなりの割合 がそれを無視していましたがw）

Selection Criteria Proposals will be reviewed based on the selection criteria below.

Relevance: The talk is relevant to the Go community. GoCon is not a general software conference, our audience wants to hear about topics that relate to the Go programming language.

Clarity: You’ve clearly explained what you are going to talk about.

Correctness: You’ve demonstrated knowledge of your topic. You don’t have to be an expert, but you are expected to be speaking from experience.

Achievability: You’ve thought about how to present your material in the time available. Impact. The goal of the talk. What new idea, technique, tool, or information will the audience leave your presentation with? Note: This clear selection criterion is based on GopherCon’s one. Thank you.

今回は8人のレビュワーが全Proposalを5段階評価をしたあとに、その平均点と標準偏差を取り、各トークフォーマットごとに平均点を降順にならべて、高得点のものから採用としていきました。（標準偏差はばらつきが大きいものだけ各人の評価を確認するためだけに使用）

やはり採択された中でも得点が高かったもの（4点以上）は、上記の条件すべてに当てはまっているものが多かったです。やはりGo Conferenceなので、上にあるように

  • そのセッションがどうGoに関係しているのか
  • そのセッションはどのような問題を解決してくれるのか
  • そのセッションで登壇者が伝えたいことの独自性はなにか

こうしたものが伝わってくるようなProposalは、それを読むだけでワクワクしましたし、ぜひ発表を聞きたいと感じ自ずと点が高くなりました。

世界のコミュニティーに直接リーチできる

PaperCallを利用したもう一つの理由は、多くの海外のカンファレンスでもそれがCfP用プラットフォームとして利用されていて、海外のエンジニアがPaperCallに公開されているイベントには、まず勢いで登録しているからです。

今回CfP Descriptionなどをほとんど英語で書いたのも、そうした海外のエンジニアに向けて情報を伝えられるように配慮した結果でした。

で、今回のGo Conferenceでの結果はどうだったのかというと、数は少なかったものの、きちんと応募がありました！そしてその少ない応募のうち2名は海外から参加されます！これは本当に嬉しいことで、すでに登壇者の方とはメッセージでやり取りをしています。

一人は「スピーカーに渡航費等の補助はあるのか」と質問してきたのですが、残念ながらいまのGoConではそれは賄えないと伝えると、それでも来てくれると言ってくれました。本当に嬉しい限りです。もう一名の方もビザの準備等がありまだ参加が確定しているわけではないのですが、それでも楽しみにしていると言ってくれました。

こうした方々の参加が今後ますます増えてくるようなイベントにしたいですね。スピーカーの渡航費補助などもできる仕組みを整えたいなと考えています。（イベント自体の有償化も視野に入れて）

応募者側として

逆に応募者側として何がいいかなと思ったときに次の内容が挙げられるなと思いました。（自分も1セッション応募した）

  • 応募者側としてタイトル、概要（Abstract）、セッション詳細（Description）、追加情報（Note）をきちんと分けて書ける
  • 同じProposalを複数のイベントに登録できる

各セクションが別れている

Proposalの書き方は、学会のポスターセッションなどに近い感覚でした。そうしたものに慣れていない人にも、タイトル→概要→セッション詳細→追加情報という形でフォームが広くなっているので、セッション自体を考えるプロセスにも使えるのが良かったです。

その中でもやはり概要とセッション詳細が肝だなと思いました。概要に書く内容は、セッションスライドで言えば、最初あるいは最後のスライドにくるような「何を伝えるセッションなのか」ということ。ここを先のCfP Descriptionに一致させたあとに、実際セッション詳細で、細かな内容を記述できるわけです。

今回の応募者の中にはトークフォーマットに合わせて、各内容をどれくらいの時間をかけて話す、ということまで説明してくれていた人もいました。そういった内容があればProposalのレビューをする際にも、セッションの様子をより具体的にイメージすることができるので助かるなと実感しました。

同じProposalを複数のイベントに登録できる

今回、Go Conference 2019 Spring と Go Conference 2019 Summer in Fukuoka のCfPの期間がかぶっていました。 どうなるかわからなかったので、GoConとGoCon Fukuokaには両方同じTalkを登録しました。Submissionごとにあとで編集できるので、出してから変更すればいいのですが、自分の得意なテーマがある場合にはそれを様々なイベントに対してチャレンジできるのは便利だと思いました。

早速 GoCon 2019 Spring の Reject Conf もあり、そこでもPaperCallを使うようなので、残念ながら通らなかった人も、PaperCallの機能を使ってそちらに登録してみてもらいたいです。

コミッティーとしての感想

Proposalをたくさんいただいた中で、やはりもうちょっと改善してもらいたいなと思うProposalはあって、何段階かあったのですがつぎのようなものが多かったです。

  1. セッション詳細がない or 雑
  2. 応募者が登壇しなければならない理由がわからない

まず1つめの「セッション詳細がない or 雑」に関して言うと、前者は自明として、後者はどういうものかといえば、ブログか何かのURLが貼ってあってそれでおしまい、というようなもの。レビュワーもかなりの数（今回のレビューで言えば合計で5万字くらい読んでます）のProposalに目を通すので、その中でそういう応募があれば、熱意を感じられず加点をする気持ちが起きません。ブログのURLだけが貼ってあるものを見たときには私は中身も確認せずに「このブログ記事をシェアすればいいだけなのだから、イベントで登壇枠を作る必要はない」と判断しました。

2つめの「応募者が登壇しなければならない理由がわからない」に関しては、ライブラリやツールなどの基本的な使い方の説明、などです。ドキュメントに書いてあるような内容しかセッション詳細で読み取れないときには、やはりこれもドキュメントをシェアすれば済んでしまう話になります。

今回コミッティーとして分量があるProposalを多く読み、あらためてProposalに込められた熱意というのは大事だなと実感しました。今後PaperCallやそれに類似したサービス使うイベントは増えてくると思いますが、このサービスのおかげで様々なイベントでのセッションの質もあがるのではないかという期待が湧いてきました。

今回は初めてのPaperCallでしたが、次回は2回めで運営側も参加者側も慣れていると思うので、今回よりももっと充実した投稿が増えることでしょう。早くも秋のイベントが楽しみです。

追記 2019.04.25 09:57AM

普通にウェブサイトにはProposalのタイトルと概要だけ載せたのですが（そうしないと発表内容全部公開になってしまうので面白くない）、何がウェブサイトに記載されるか書いていなかったため、何人かの方から「詳細も載せてほしい」「概要を変更させてほしい」というリクエストが来ました。 これらに関しては運営側がCfP Descriptionにその旨を書いていなかったのが悪いので反省しています。しかし詳細を載せてしまうとセッション内容が全部わかってしまい、個人的には興ざめになってしまうので、そのリクエストはお断りしました。また概要を変更するのも、人手が圧倒的に足りないので都度修正する手間などを考えてお断りしています。

右綴じ書籍のスキャン済みPDFをKindleで読む

misc Linux

はじめに

こんにちは、Stackdriver担当者です。海外旅行に向けて準備をしているのですが、Kindleに読みたい書籍をLinuxの端末のみを使って入れるのに苦戦したのでメモを書いておきます。

Kindle Paperwhite、電子書籍リーダー、防水機能搭載、Wi-Fi 、8GB(Newモデル)

Kindle Paperwhite、電子書籍リーダー、防水機能搭載、Wi-Fi 、8GB(Newモデル)

TL;DR

  • 右綴じ書籍対応のためにPDFを全部逆順にした（pdftk 使用）
  • PDFのサイズ圧縮にGhostscriptを使った
  • これでなんとか Send to Kindle が使えた

PDFのページを逆順にする

Kindleアプリは使ってないのでわかりませんが、ハードウェアのKindle*1では、典型的な日本語の書籍（縦書き右綴じ）の書籍を開くのに対応していません。

そこで仕方なく、PDFページを全部逆順にしたあとに末尾ページ（＝元ファイルの先頭ページ）から戻していくことで右開きを実現しました。

$ pdftk input.pdf cat N-1 output output.pdf

ここで入力値は以下の通り

  • input.pdf: 元のPDFファイル名
  • N: PDFのページ数
  • output.pdf: 出力する逆順にしたPDFファイル名

PDFサイズを圧縮する

さて、これで Send to Kindle by Email でさくっと送るぞと思ったら、Gmailの添付するファイルサイズの上限を超えていて「Google Driveのリンクをシェアしますか？」とか聞かれたので困った。見てみたらファイルサイズが50MBを超えている。

ちょっと調べてみたらGhostscriptを使ってPDFを簡単に圧縮できるようだったので試してみた。

$ gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dPDFSETTINGS=/ebook -sOutputFile=output.pdf input.pdf

ここで入力値は以下の通り

  • input.pdf: 先程逆順にしたPDFファイル名
  • output.pdf: 圧縮済みのPDFファイル名

また各種オプションはmanや公式ドキュメントを見てもらったほうが良いですが、メモとして残しておくと

  • -dBATCH と -dNOPAUSE: PDFファイルの各ページごとに停止して確認しながらループするのではなく、全ページ一気に処理するときに指定
  • -sDEVICE: 出力先デバイスの指定なんだけど、PDFファイルに書き込む場合はここで pdfwrite を指定
  • -dCompatibilityLevel: 圧縮する際のAdobe Distiller 5互換のパラメータ（ここの表参照）
  • -dPDFSETTINGS: Adobe Distillerに対するプリセットの設定群を適用できるラベル。電子書籍用であれば /ebook を指定するのが良いと思う。（/screen だと粗すぎると感じた）

処理結果

% ls -lh *.pdf
-rw-r--r-- 1 ymotongpoo users 20M  4月 14 19:23 reversed-compressed.pdf
-rw-r--r-- 1 ymotongpoo users 53M  4月 14 18:50 reversed.pdf
-rw-r--r-- 1 ymotongpoo users 53M  4月 14 18:47 original.pdf

53MBが20MBに圧縮されました！

参照

*1:自分が持っているのはKindle Paperwhite