読者です 読者をやめる 読者になる 読者になる

once upon a time,

Iris Tradをビール片手に聞くのが好きなエンジニアが、機械学習やRubyにまつわる話を書きます

Indigogo ではじめてバックして来た dot を使って3ヶ月がたった

最近のbackspace.fm でdotが「来る来る詐欺」でAir podsに完全に飲み込まれたという話が出ていたので、きちんとレビューしてなかったのを思い出したのでレビューします。

dotは一言で言うと、AirPodsみたいな小さいBluetoothイヤホンです。

https://www.indiegogo.com/projects/dot-world-s-smallest-bluetooth-headset#/

はじめての Indigogo

f:id:chezou:20170130213220p:plain

僕がバックしたのは、miyagawaさんがdotみたいなイヤホンをinstagramか何かで買ったというのを見て、これかな?と勘違いしたからだったんですが、2015年12月にindigogoでバックしてたみたいです。ステレオで$79+$29のシッピングコストです。最初の申込みから少し遅れていたのですが、当時は2016年4月に届く予定と言っていて、結局届いたのは2016年の10月でした。

はじめてのIndigogoで学んだのは、バックしたときが欲しい気持ちの最大値になっていて、届く頃には類似品が出てきて市場が開拓されていて切ない気持ちになること。こなれたものを手に入れたいなら待っていたほうがいいのかもなーと思いました。

dot レビュー

www.instagram.com

箱はこんな感じでおしゃれ。

www.instagram.com

中身もきちんとオシャレに梱包されています。

www.instagram.com

充電器兼ケースは、イヤホンがそれぞれマグネットでひっついて充電されます。 重さもたいしてないので、ポケットの中に充電ケースを常に入れておいて、オフィスや家についたら充電するような感じにしています。

ケースの充電はケースを2つに割って真ん中にある穴にmicro USBで刺すのですが、真ん中で別れるところもマグネットでひっつくため、バラバラでどっか行ってしまうということはありません。ただ、ケースを充電しながら給電できるのは、片方だけなので注意が必要です。 また、モノラル二個としても使えるので、片方充電してもう片方は聞き続けるという使い方も可能です。 公称値で3時間持つと言っている電池ですが、backspace.fmや最近のrebuildは通しで聞けるかどうかはわかりませんが、充電器を忘れて往復2時間弱の通勤で充電しないでも再生し続けられたので、なんとかなるかもしれません。

www.instagram.com

大きさは小さめの腕時計よりも更に小さい感じ。AnkerのIE20と比べて見ても小さいのがわかります。

Bluetoothのペアリングは、JabraよりはいいけどAnkerのIE20と同じくらいかなという印象です。めちゃくちゃ安定はしてなくて、街なかでちょこちょこ切れる感じだけど、我慢できる範囲です。最近のiOSのアップグレードで接続は安定してきましたが、一度ペアリングが切れかけると片方ずつ接続が復帰するので同期するまでに少し時間がかかります。*1

音については、個人的にはIE20の方がクリアで好きかなという印象です。個人的には、こもった感じがしてそんなにいい音だとは思いませんでした。遮音性に関してはIE20よりもよく、うっかりすると周りの音を聞き逃す感じです。

操作は、最初に同時に長押ししてペアリングをして、その後iPhoneなどとペアリングするという流れです。一度Dot同士をペアリングしてしまえば、後は気楽に使えます。 電源オンは両方のスイッチを3秒くらい長押しする感じです。タイミングずれててもいいですが、どっちが右か左かはまぁ音がでるのでそれを聞いて間違っていたら入れ替えています。 電源オフはどちらかのスイッチを3秒くらい長押しすると両方消せて、1秒長押しするとSiriが起動する感じなのは今時の感じですね。 マイクの拾いはそんなに良くないかな、と思うので、あまりメインで使うのには向いていないのかもしれません。

軽くて小型なので、カジュアルに持ち運びができてポケットにとりあえず突っ込んでおくという運用ができるので気に入っています。

今となってはAirPodsが安定していると評判なので、そちらのほうが良いかもしれませんが、$100で手に入ったということではいい買い物をしたな、と思っています。

*1:前のiOSのときはブチブチ切れていて本当に辛かったけど、最近は良い

また一つ年をとった

雑談

同い年のmirakuiさんがCTOになったりして、そろそろ組織に中で立ち回りが変わる年代なのかなと思ったりしてる。ちょうど一年前の今頃今の会社の面接を受け、初めての英語の契約書を1日2日で読んだりして、色々と慌ただしくしたところから首にならずに一年経った。backspacefm聞いてると、外資は当たり出し続けないと干されるよねみたいな話もあったので、価値を出し続けていきたい。コードを書く時間は減ったけど、いいペースで新しいプロダクトがでる変化の激しい会社なので、誰の役に立つものなのか考えて伝えていくのは楽しいと思ってる。幸いにして同年代がオフィスにもpyspaにも多いので、自分の役回りにあまり不安はないので、できることを少しずつ広げようとしている。

また、kawasaki.rbが三年半以上続いているのもありがたい限り。Rubyだけではない地域の技術の集まりとして、これからも細々と続けていきたいです。 https://kawasakirb.connpass.com/event/49105/

最近のトピック - 在宅勤務のしすぎで運動不足のため、夫婦で30日スクワットトレーニングを始める。楽しい - podcastの出演者を探すのがちょっと大変になってきた。相棒/出演者欲しい - 昔全然聞けなかったATPが普通に聞けるようになってた - Pythonばっかり書いてたら、Rも書くようになった。dplyr便利

最後に、例のリストです。 http://amzn.asia/17SpDXd

Gitlab CIを使ってSphinxのドキュメントを自動でPDFにビルドする

sphinx document gitlab

gitlab.comは自前でDocker image登録できたり、CI持っていたりと便利ですね。しかも、privateレポジトリもお金かからないという太っ腹。 技術書典2に向けたレポジトリはgitlab.comで管理しています。

今回は共著者にPython使いが多いためSphinxを使って書いているんですが、Sphinxはcommon markでも書けるのでmarkdownでも文章を書くことが出来ます。

前回の記事では、数式入りのmarkdownからPDFを生成するDocker imageを作りましたが、それを使うと簡単にGitlab-CIでPDFが生成できます。

chezou.hatenablog.com

やり方は簡単、あなたのSphinxのプロジェクトに、以下のような.gitlab-ci.ymlを書くだけ。もちろん、必要に応じてpathsは変更してください。

image: chezou/sphinx-recommonmark:latest
pdf:
  script:
    - make latexpdfja
  artifacts:
    paths:
    - build/latex/techbookfest02.pdf
  only:
    - master

こうすると、masterにpushしてCIが成功する度に、PDFが生成されてダウンロードできます。

f:id:chezou:20170123123725p:plain

めっちゃ簡単。お試しあれ。

数式入りのmarkdownをSphinxを使ってhtml/pdfにする

sphinx docker math

Sphinxmarkdown拡張を扱うためのrecommonmarkというライブラリがあります。 これを使うとreSTではなく、markdownを書いてhtmlやPDFが吐けるようになります。

詳細は以下のエントリにやり方がまとまっています。

tech.3rd-p-zombie.net

実は、このrecommonmarkはconfigに設定を書くだけで、数式をmarkdownの中に埋め込めるのでした。

conf.pyの上の方に以下をimportし、

import recommonmark
from recommonmark.parser import CommonMarkParser
from recommonmark.transform import AutoStructify

source_suffixの修正、source_parsersの追加

source_suffix = ['.rst', '.md']
#source_suffix = '.rst'
source_parsers = {
    '.md' : 'recommonmark.parser.CommonMarkParser'
}

最後尾に以下を追加します。

def setup(app):
    app.add_config_value('recommonmark_config', {
            'enable_math': True,
            'enable_inline_math': True,
            }, True)
    app.add_transform(AutoStructify)

すると、

 ```math
  (a + b)^2 = a^2 + 2ab + b^2

 ```

とかくと、以下の数式の部分のようになります。(document)

f:id:chezou:20170122160632p:plain

また、inlineの数式も以下のように書けます。 (document)

This formula `$ y=\sum_{i=1}^n g(x_i) $`

ただ、残念ながら式番号を出す方法はわかりませんでした。

[追記]

conf.pyにmath_number_all = Trueを足せば数式がでました。ですが、参照はできないと思うので参照が必要な場合はreSTで書く必要があると思います。

gyazo.com

[/追記]

$ make latexpdfja

とすれば、PDFが、

$ make html

とすればhtmlが生成されます。

さくっと書くときにはmarkdownで行けるのはありがたいですね。

Sphinxlatex環境を用意するのが面倒な人向けに、docker imageも作りましたので活用してみてください。

https://hub.docker.com/r/chezou/sphinx-recommonmark/

参考

macのJIS配列のキーボードをKarabiner使わずにUS配列にする

mac

macOS Sierraに上げる前に、Karabinerが動かない問題をなんとかしたいと思っていました。 El capitanでちゃんと検証してから上げないと、色んな人みたいに死ぬなと思ってKarabiner-Elementsに移行できるか検証しました。

今回の要件

  1. JIS配列の本体のキーボードをUS配列で使いたい
  2. 外付けのUS配列のキーボードで右cmd単体でかな(IME ON)、左cmd単体で英数(IME OFF)として使いたい

とくに、1.についての情報がみつからなかったので、実際に試してみた。

Karabiner-ElementsでUS配列にする

最近のKarabiner-ElementsはGUIがついているので、かなり楽ちんで、設定項目は2つ。

1つ目は"Virtual Keyboard"のKeyboard Type: ANSIを設定すること。これで大体USキーボードの配列になります。

f:id:chezou:20170119221149p:plain

2つ目の設定は、"Simple Modifications"でinternational3grave_accent_and_tildeに変えれば行けた。これでかつる!KarabinerのJIS->USと揃えるにはinternational1も同様に割り当てれば良さそう。

f:id:chezou:20170119221202p:plain

ちなみに、検証はAnkerのBTキーボードで試しました。安いUSキーボードとしてはそこそこ使えます。

cmd->英数,かな

これは、英かな使えば大丈夫。

しばらくこれで試してみようと思います。問題なければSierraにあげてみます。

非英語ネイティブにとってのOSSのメンテナンスコスト

community program

disclaimer: この記事を書いている人はClouderaというHadoop/Sparkのディストリビューターの会社にいます。

codelunch.fmの20回目を聞いていろいろ思うところがあったのでつらつら買いてみます。

codelunch.fm

この回のcodelunch.fmでは、前職の同僚である丸山さん(@h13i32maru)と@hokacchaさんが、お互いの家庭環境の変化を交えながら個人プロダクトの開発について話しているエピソードです。これ自体なかなかおもしろい回なので、趣味でプロダクト開発している人は聞いてみるといいんじゃないかなと思います。

丸山さんはJasperESDocを精力的に開発していますし、hokacchaさんはnodebrewadventarを作られています。彼らの話していた、個人で趣味プロダクトを開発するモチベーションは何かというところは、以下のようなことが話されていました。

  • 自分が欲しいと思ったものを作りたい
  • 他にも同じ問題で困っている人を自分のプロダクトで助けたい
  • 新しい技術を試したい
  • あわよくば、自分の作ったプロダクトで有名になりたい(承認欲求を満たしたい)

どれも同じエンジニアとしてはそうだよねという気持ちになります。

そんな丸山さんのESDoc関連の発言を見ていると、アクティブじゃないから他のにマージしろとかなかなか悩ましいなぁと見ていて思います。

本質的にはgithubのissueが辛いだけかもしれませんが(丸山さん自身もポジティブフィードバックを得にくいのが辛いと言っている)、スターが1000を超える程度の人気のプロダクトは色々な人のアテンションを引くため、言葉を選ばず言うと「乱暴な」issueが立ちやすいのかもしれません。*1ですが、自分もスター19くらいのtabula-pyというbindingも本家に拾われてからいろいろissueが来るようになりました。

OSSを出すパターンとしては、ざっと考えた限りでは以下のようなパターンがあるんじゃないかと考えます。カッコ内はその目的です。

  • 誰も作っていない欲しいものがないから作ってOSS化する(自分をユーザとして満足させる、承認欲求を満たす)
  • 会社で書いていたコードのうち、一部を汎用的に切り出してOSS化する(同じ問題を解いている他の人を楽にする、会社の認知を上げる、転職後もコードを使えるようにする)
  • 会社として、大きいコードを戦略的にOSS化する(他社との差別化、プロダクト自体の認知を広める)

下に行けば行くほど、メンテナンスする人数も増えていくと思います。ここで、OSSのメンテナンスコストという点について考えたいと思います。というのも、個人ですべてOSSとしてメンテしていくときにこういうのをどう処理すればいいのかな、と考えたのがきっかけでした。

前職のクックパッドに入る前は、OSSに対する考えとしては、ソースコードは公開されており、コントリビュートの機会が開かれている素晴らしいものだと素朴に思っていました。RubyやSolrにお世話になり、自分もC++のコードの小さいbindingを書いたりしていました。

クックパッドに入った後は、社内でも使っているし社外にも使えるものはOSSとして公開しようという流れでOSSを出しているのを見てきました。業務として使うコードを公開することでユーザが増え、コードのクオリティが上がり会社の認知も増えるという効果も得ることができていた様に感じます。 ある意味では、その企業が業務としてのOSS活動をサポートしているからできることだとも思います。プロダクトにもよりますが、1人ないしは数人で開発をしているという開発状況になると思います。

Clouderaに入って、HadoopやSparkといった巨大なOSSは一社ではとてもじゃないけれどすべてをこなすことが出来ないものであるという認識になりました。 良くも悪くも複数の企業やASFなどのファウンデーションでメンテすることで、そのコードを長く使えるようにしているものだということを学んだのです。 OSSコミュニティとして他社と共同開発をしながら、一方でビジネスでは競争をしているという形になります。当然、個人や一社で開発するより圧倒的にフルタイムの開発人数は多くなります。

では、継続的に個人の趣味コードをOSSとしてメンテナンスしていく上での、メンテナンスコストはなんでしょうか?

一つの要素としては、先程から書いているように開発リソースの問題です。

開発者の時間は有限ですし、ユーザーが増える速度はコントリビュータが増える速度より速いです。 ESDocに関してはorganizationに一人しかいないのもさばく負荷が高い理由になるでしょう。 コミットしてくれる人を集めたり、issueを消化してくれるメンテナを集めたりして優しい終身の独裁者として動くのもありかもしれませんが、個人として自由な裁量を持った開発をしたいという人もいるでしょう。 こうした中でどのように、増え続けるissueと戦うべきか、というのは難しい問題です。 なお、このあたりの話は、Sphinxメンテナのtk0miyaさんの記事とFreeBSDのPort maintainerのjj1bdxさんの記事が興味深かったです。

tk0miya.hatenablog.com

qiita.com

もう一つの要素としては、英語に困らない人にはノンネイティブの辛さが想像できない問題というのもあると思います。

自分のボスは、ネイティブと議論するときと英語が得意でないノンネイティブが混ざるときで、話すスピードもそうですが使う語彙を変えて話してくれます。 しかし、githubのissueなどpublicな場所ではこうした気を使ってくれる人は(自分の体感としては)珍しく、こちらが気合を入れて英語を読んだり書いたりする必要があります。 丸山さんとも昔話しましたが、issueの返信だと「この解釈で本当に良いんだろうか」とウンウンうなるときも少なくなく、スラングに苦しめられる時も多いです。*2 All Ears Englishでも、「アメリカ人はノンネイティブの英語に慣れていないから、崩れた英語から汲み取ることができない」という話もありましたし、ここは結局ノンネイティブが頑張るしかないのですが、ネイティブにもここらへん認識してもらう方法はないものか、とも思います。

例えるなら、対面で話しができるスムーズさとメールでのみやりとりしかできないときの負荷のギャップが、ネイティブ同士のやりとりとノンネイティブがネイティブとやりとりするギャップに相当するんじゃないかなと思います。

もちろん、PR貰ってコードでやり取りするのはやりやすいですが、GithubOSS活動をするということはそれだけでは済みません。 僕自身も英語で問い合わせメールが来てissueで辛いやり取りをして以来、最近はそういうコストをどうしたら抑えることができるかということを考えています。 ユーザーを拡大したければ英語でマーケティングをするのも大事になってきますし、英語圏の開発をしてくれるファンを増やせればもっと楽になるのかもしれませんが...。*3

とりとめもなくまとまりもないですが、他の人はどう考えて立ち向かっているのか教えてもらえるとうれしいです。

*1:もしかすると、彼のアピールの仕方が「他より良い」という点で攻めているので面倒なissueが立ちやすい可能性もあります

*2:urban dictionaryがないと死にそうになります

*3:Issue templateやFAQである程度は対処できるとは思いますが決定打にはかけるなとも思います

2016年を振り返って

雑談

ブルガリアンスクワットをして筋肉痛でプルプルしています。大晦日も元旦もほぼDMM英会話の予定しかありません。

2016年は、世界的にも激動の年でしたが、個人的にも色々な大きなことが起こり激動の時代でした。*1

昨年の振り返りはこちらです。

chezou.hatenablog.com

Cookpad TechConf、DS祭り、CWT2016で発表した

chezou.hatenablog.com

chezou.hatenablog.com

chezou.hatenablog.com

どれも自社イベントですが、今年は外で発表する機会を例年より多くいただきました。来年も、BigData Analytics Tokyoの発表から幕開けです。

転職した

chezou.hatenablog.com

CookpadからClouderaに転職しました。Sales Engineerというロール、初めての外資ということで慣れない事だらけですが、引き続き、機械学習やデータサイエンス周りでの強みを活かしてやらせていただいています。英語は入社してからDMM英会話をほぼ毎日やったら、最低限社内でやりとりをする力と飲みながら英語話す力は得ることが出来たので、意外となんとかなるかもな、と思っているところです。抵抗感が減ったのと、ちょっと気合を入れれば何かしらの英語はアウトプットできると思えるようになり、瞬発力が前よりはついたなと思えたのが良かったです。

instagram.com

良いなぁと思うのが、同僚で40歳を越えたエンジニアが日本にも何人かいて、その人達がエネルギッシュに働き続けているのと一緒に働けることです。40歳を越えたらマネージャーにならなければならないのかな、とかコード書けないのかなという不安が払拭され、さすが外資だなと思った瞬間です。もちろん、腕に覚えがある人だから生き残ってこれているというのはあるとは思いますが、うちのAPACのdirectorも飛行機で世界飛び回りながらいつも新しく書いたコードの話してくれるので、負けていられないと思う気持ちでいっぱいです。

instagram.com

また、転職の流れで同僚からひょんなことからpyspaに誘ってもらいました。温泉にはまだ言ったことがないですが、お世話になってます。

川崎Ruby会議01を主催した

chezou.hatenablog.com

kawasaki.rbが母体となって主催した地域Ruby会議です。コミッターの方々も参戦していただいたのに、良い意味でRuby色の薄いリージョナルだったと思います。

kawasaki.rbも細く長く続いており、参加してたら転職できた人や、参加してたら起業した人、参加してたら無職になったけど仕事が手に入った人(あるいは採用できた人)などコミュニティとして横のつながりができているなと思います。

(ブログエントリとpodcastが)rebuildデビューした

naoyaさんに紹介されて、データエンジニアリングとデータサイエンスの違いの話がrebuildデビューしました。自分で聞いてた時に突如現れた時にはお茶吹きそうになりました。rebuildはサポータープログラムに入ると文字起こしや一人語り回も聞けますし、本放送とライブ放送直後の配信と二回聞けてお得感満載です。

chezou.hatenablog.com

rubyist.club

本を執筆していた

お誘いいただいて一年くらい執筆活動をしていました。音楽性の違いにより解散してしまったのですが、24月の技術書典で供養したいと思います。

その時の切り出したものがこれらの記事ですが、はてなの教科書からも引用されて嬉しかったです。

chezou.hatenablog.com

chezou.hatenablog.com

また、記事を書くに当たっていくつかFactorization MachinePythonライブラリをPython3対応する人になっていました。

出張が多かった

昨年までとはうって変わって、今年だけでパロアルト、ラスベガス、シンガポールと年に三回出張で海外に行く機会がありました。研修でUSの様々なところから来たエンジニアや営業とはなしをしたり、APACのチームミーティングでシンガやインド、オーストラリアなど様々な国の人とロールプレイをしたりとハードでしたが、成長も実感できました。ただ、妻が一人で子供を二人面倒を見る期間が出来てしまうので、ワンオペ状態となっていたのは悩ましい限りです。

今年書いたコードなど

小物が多いです。あまりコード書けていないので、来年はもう少しコード書けるといいなと思います。tabula-pyももう少しなんとかしたい。

2017年に向けて

総じて今年は、やることを減らしてできることをやるぞ、というスタンスで来ました。自分のできる範囲内でこなせたんじゃないかと思っています。家族への負荷がもう少し下げられればなと思います。

社内で思ったより色々貢献できることがありそうだぞ、ということが分かってきたので、社内外ともに色々とアウトプットしていきたいと思います。

もう一つ、筋肉を付けて加齢に伴う色々な問題を解消していきたいと思います。

*1:のっけから余談ですが、UKに縁のあるボスが来日中にBrexitの結果を受けて落胆していた様子と、エグゼクティブたちが来日中にトランプの勝利を見てショックを受けているのを見て、波乱の年だったなと思います