seri::diary

プログラミングのこととかポエムとか

余裕はあるけど今やらなくても良さそうだけどいつかやった方がいいタスク問題

こういうタスクは大体「溜まる」傾向にある。 github issueでいえば いつかやる とか NiceToHave なんていう、何とも第三者から見ると全くプライオリティが想像できないタグが付けられて、そして1か月もたつとissueの存在すら忘れる。*1

自分の場合、こういうのを貯めておくと気持ち悪いので、それほど余裕がなくてもスキを見てさっさと片付けてしまう傾向にある。今日も例外発生時の調査用のログフォーマットを調整するだけのPRを出した。*2

余裕ができると自分はリファクタリングのPRを週に10個近く出していることがある。流石にレビューを依頼される同僚からはドン引きされたのではなかろうかと思うが、プロジェクトの谷間とかで急ぎの仕事がなければそういうことをせざるを得ない時もあるのである。

そのため、自分がアサインされているissueは遅くても1か月にはcloseされている傾向にあるようだ。ようだ、というのは正確に計測した訳ではなく肌感覚だからなのだが、少なくとも3か月以上closeされていないissueに関して言えば自分は1つしか持ってない。これはやらないのではなく色々な事情でcloseできておらず目の下継続中のタスクなのだ。

さて、こういうタスクに関してだが、他のメンバーを見ると結構古いissueをずっと抱えているのをよく見かける。openなissue絶対closeするマンの自分は、時間ができると他の人のissueを見て回って「進捗どうですか?」的質問をして状況を確認し、わざわざその時のステータスをコメントに書いてみたり、アサインされていないものは適当にやれそうな人をアサインしておくことがある。あるいは自分で勝手に巻き取ってやってしまうこともある。自分がやれるタイミングなら自分がやるのが一番早いからだ。

自分の場合、積み残した仕事というのがそもそも自分として許せない存在であり、改めて検討した結果やる必要がないと判断できるならすぐcloseしてしまうし、イシューになっている(githubのissueではなく本来の意味のissue)時点でそれは自分のチームの責務なので、なるはやでcloseに向けて動くのが仕事だと思っている。

こういう積みタスクというのは、クライアントにも同僚にも喜ばれる華々しい機能追加ではなく、大抵はちょっとしたtypoを直すとか、社内用の画面のちょっとしたバグだとか、急いでいたので黙認したrubocopの警告を直すとか、ライブラリのバージョンを上げるとか、拡張性の悪いクラスを細かく分割してspecを書き直す、とか、めったに起きないエラーを調査して直すとか、使ってないクラスを既存コードに影響しないように取り外すとか、使ってないのになぜかDBに残ってるテーブルをdropするとか、not null制約がないとどう考えてもおかしいのに付いてないカラムに付けるとか、そういうやつである。

そのため、会社の売上にも貢献できず、その上誰からも感謝もされず、評価もされにくい貢献だと思われがちなせいか、多くの人は避けたがる。だがその思い込みは恐らく間違いだ。そうこうしているといつか大きな負債を生んで自らを苦しめる(もしくは苦しめられた)例を自分は沢山知っているし、逆に自分が時間がある時に仕込んだ詳細なログのおかげで命拾いしたことが何度もある。これはれっきとした技術的負債の返済であり、将来の自分たちを救うための重要なタスクなのだ、と思ってもらいたい(のだが、一度そういうマインドが染みついた人の思想を変えるのは実際難しい)。

こういうタスクは実際会社の売上には1円も影響しないかもしれないが、将来発生し得る100万円の損害を1万円に抑えられるかもしれない可能性を秘めている。いざ大障害が起きてから「ログが少なくて状況が分かりません」だとか「コードが汚くて修正するのに時間がかかります」などと言ってられるだろうか。そういう目にあってから初めて目を覚ますのでは遅すぎる。

こういう負債をまとめて返済すべく派手にリファクタリングするのはデグレのリスクが大きくなる。そのため、5行とか10行とかの小さなPRを普段から出し続けて地道に改善するしかないのである。GoogleUeyama Ruiさんのブログにも同じような話が書かれている。

blog.sigbus.info

自分はオープンソースに何度かPRを出してマージされたことがあるが、基本的に仕事でコードを書くのとオープンソースのコードをいじるのとは全く同じスタンスで考えている。つまり、変更の意図が分かりやすく、必要な量のコメントが書いてあって、自分以外の誰かが次にいじる時に困らないようにするということを常に守っている。実際、オープンソースにPRを出す練習のつもりで、これまでつらつら述べてきた「誰もやりたがらないタスク」を片付けている部分もある。そう考えればそこまで退屈なタスクでもないし、タイムアタックだといわんばかりに1日に何個片付けられるか挑戦してみたりすることで自分はそれなりに退屈しないでいられるのだが、もしかしたら自分が変わってるだけなのかもなぁという気持ちにもなっている昨今である。

*1:こういうタスクどうやって管理するのがいいのかいまだによく分からないがどうやっても発生してしまう。定期的に棚卸すればいいのだろうか。誰か教えてくれ。

*2:今の会社に入ってからBugsnag入れたりログを増やしたりログを検索できるようにしたり、エラーを可視化する仕事ばかりしている気すらする。この手の運用に強いコードにするためのリファクタリングのコンサル業だけで飯が食えそうな勢いである。

業務と勉強

少し前にtwitter界隈で話題になった話に軽く便乗してみる。

と言っても、プライベートの時間に勉強しなければいけないかどうかとかそういう話ではない。業務の余った時間を自分の勉強に宛ててよいか、どうかという話。*1

先に断っておくが、「自分の勉強」とは、仕事に関係あるものではなく、使うかどうか全く分からない技術のことを指す。

どこまで関係あってないかという線引きもかなり主観的なものなので難しいが、採用可能性が少しでもあるものは「仕事に関係がある勉強」。何をどう考えても仕事で採用可能性がないものは「仕事に関係がない勉強」と定義する。

自分の場合、前者は最新バージョンのrubyrailsのコードを読んで動向を知るとか、AWSの新しいサービスを試してみるとか、Rの新しいプラグインを試してみる、とかが該当する。後者は、数学だったり、Hadoop3の動向を追っかけるためにJIRAを読んでいたり、DockerでHDFSクラスタを作ってIrisデータをいじくっている、といったものが該当する。少なくとも今の会社でデータストアを自前でホスティングして使うことはしない。

で、自分は会社で「勉強」するのが物凄く苦手である。

もちろんタスクがある時は全力でやっている。しかし、大抵予定していたスケジュールより早く自分の仕事は終わってしまうため、プロジェクトとプロジェクトの間が1週間から2週間空くことがある。もちろん、その間何も仕事をしていない訳ではないが、単発的に1日に1時間かそこら集中してやれば終わってしまうタスクがたまに発生するだけの状態になってしまうことがある。

そういう時に何をするか。それが目の下の問題である。

まずは積んであるbugfixとかリファクタリングのissueを片付けまくる。だがそれもなくなってしまい、他のメンバーに仕事はないかと聞いて回っても見つからなくなるといよいよ困る。

そういう状態のときに、一応やるべきことはすべてこなしたし、好きなことをしていても(多分)文句はないはずだが、それが中々できない。

なぜかといえば、自分は手持ち無沙汰なのに、周りの社員はプロジェクトに従事して各自の仕事をしていて、そういう社員に対する後ろめたさみたいなものが影響しているのだと思われる。

忙しそうにしているからには手伝いたいのだが、なかなかうまく途中参加できないケースもあるし、そもそも職種が違う関係ですぐに手が出ないケースもある。*2同じサーバーサイドのタスクであればいくらでも引き受け放題なのだが、そういうケースばかりでないのが厳しい所である。

普通に考えれば仕事がないのは別に自分のせいでもないし、別にサボって仕事をしていない訳ではない。だから堂々とすればよいのだが、なぜだか他の社員に対し後ろめたさを感じてしまう。勤務中は会社のためになることをすべきである、という考えが強すぎるのかもしれないが、とにかくせっかくスキマ時間を生み出しても、上手く自分のために時間を使えていないように感じている。

こういった複雑な葛藤を一切持たずして勉強できるようになるのは退勤してからである。オフィスを一歩出たら仕事のことは一切考えず(とは言ってもやはり少しは考えてしまうのだが)やりたいことに集中するようにしている。逆に仕事をしている間は仕事のことしか考えない。

そうやってメリハリをつけて、少しでも仕事を早く終わらせて、やりたいことをやる時間を最大化するための努力をすることが今のところ勉強時間を確保するためにしていることである。

いつか自分が勉強したいことと仕事で必要なことが綺麗に一致して、業務時間中の勉強はすべて業務のためになる、というような状況を自分で作り出したいものである。

*1:プライベートの勉強はやりたきゃやればよいし、会社から露骨に強制されたら業務内でやらせてくれと主張すれば良いだけではないだろうか。

*2:自分の場合、フロントエンドやiosは普段触ってないだけにすぐに手伝える状態ではない

広告を非表示にする

やりたいことを最初にやる

去年は数ⅡB辺りを勉強したので今年は線形代数を勉強している。サラスの方法や余因子展開を使って行列式を求めたり、行列をあれこれ変形してrankを求めて一次方程式の解が求まるかどうかを日々検討しているのである。

しかし勉強を始めた動機は別の本を読んで出てきた「固有値」とか「固有ベクトル」の意味って本当はなんだっけ?という疑問であった。だから線形代数の本を買ってきて固有ベクトルの章だけ読めばよい。最初はそう思っていた。ところが固有ベクトルの章だけ読んでもそれ以前に知識(特に行列式の意味や正則な行列の性質)がなければ理解できない内容だった。なので諦めて最初から参考書籍を読み問題集を解いているのである。

ちなみに読んでる本はこれ。とても分かりやすい。

プログラミングのための線形代数

プログラミングのための線形代数

問題集はこれ。学部生向けの模様。

演習線形代数 (新版演習数学ライブラリ)

演習線形代数 (新版演習数学ライブラリ)

線形代数のように順番に勉強しないといけないということは結構ある。多分資格の勉強とかも大体そうだろうと思う。しかし、新しいITスキルを習得しようとする時はどうだろうか?なぜこんなことを突然言い出したのかと言えば、今日図書館で線形代数の勉強をしていた時にふと思いついたからである。

例えば、新しい言語を勉強する時に初心者用の入門書を買ってきて、頭から最後まで全部読んでからコードを書き始めるだろうか。実際、自分は一度だけやったことがある。php入門書を買ってきて(残念ながら書籍のタイトルは忘れてしまったのだが)頭から読んで写経し始めた。

ただ、今振り返れば、あれからphpを覚えてから7年ぐらい経つが未だに一度も使ったことがない関数やクラスのsampleコードを当時必死に写経していたのは大分無駄だったなと感じる。もちろん、「こういうのがあるのか」というのを知っておくことは重要である。問題なのは、肝心のウェブサービスを作る上では不必要な知識だったということである。

実際に自分がphpウェブサービスを作るために自分はどうしたか?入門書の最後の方に「応用課題」として掲載されていた掲示板だのSNSだののサンプルコードをコピペしまくったのである。そうしなければウェブサービスは作れなかった。その章に行き着くまでに多くのコードを書いたが、それだけでは足りなかったのである。echo "Hello, php!"; から始まり mysql_connect('localhost', 'root', 'pAssw0rd') or die('データベース接続エラー');みたいなことをやるscriptをいくら書いてもウェブサービスを作ることはできなかったのである。

何が足りなかったのか?いや、足りなかったというよりそもそも努力の仕方が間違っていた。ウェブサービスを作りたければまずコピペでもなんでもいいから完成させてみることが重要だった。そうすれば自ずと何が必要か分かってくる。実際、自分のプログラミングのスキルや技術の知見は掲示板っぽい何かの実装を通じて大きく広がった。最終的にさくらのVPSを借りてCentOSの使い方も調べてドメインまで取って、今見たらどうしようもなく意味の分からないみたいな掲示板もどきサービスを公開するところまで行った訳だが、プログラミングは覚えたので次はLinuxについてじっくり勉強してから。。などとやっていたらおそらく一生公開できなかったと思う。

それがなぜ公開にこぎつけられたかと言えば、まずやってみて、足りないと感じるものだけを補うように途中から方向転換したからだと思っている。それが結局は効率が良かった。勉強と言えばまず基礎をガッチリ固めて次に応用問題を。。という、高校までのスタイルにどっぷり浸かっていた自分は、当初プログラミングに対しても同じスタンスで挑んだが、プログラミングは学問ではない。道具なのだ。金槌を使えるようになるためにまず金槌の歴史の勉強から始める必要があるだろうか?全くないとは言い切れないが、大抵の人は金槌をまず握ってみるだろう。何なら叩いても良さそうなものを叩いてみるはずである。

プログラミングも多分同じだと思う。まず今必要なことをその言語でやってみる。次にそれで分かった足りないことを知るために書籍に立ち返って必要な部分を集中的に勉強する。結局、これが効率がよい勉強の仕方ではないかと自分では思っている。

自分がEffective Javaを読んだのはjavaを書くようになって1年近く経った後、Effective Rubyを読んだのもrubyを書くようになって2年以上経った後だったが、逆に初心者の頃だったら、何に役に立つのか分からずに多くの学びは得られなかったと思う。

今でも新しいことを勉強するときはこのアプローチでやっていることが多い。
今年に入ってからはデータ分析の業務でpythonを結構書くようになったが(去年もNNの実装で使ったが)、何も考えずにまず brew install pyenv して pyenv install anaconda3 してjupyter notebookをinstallしてpandasでBigQueryのデータをいじり始めた。ハマりまくったが結局やりたいことはできた。*1
たまたま別件で調べ物をしていて見つけた某大学のシステムプログラミングの講義資料が面白くなってしまい全部写経して、まだ作ったことがなかったwebサーバーを書いた。Cを集中的に書いていた時はCがどういう風にメモリを管理するかロクに知らなかったので構造体を使ったコードを書いたら至る所でSEGVの嵐で泣きたくなったが、お陰様で低レイヤーの技術とアセンブラに興味が沸いて今では社内輪読会でパタヘネを読んでいる。

このアプローチの応用で、自分がまだやれたことがないと思うのが「自分が一番難しいと思うこと」からやってみる、というものである。これまでは「多分実現可能っぽくて(周りがやってたりするので)一番やりたいこと」から手を付ける、という感じではあったのだが、それだとどうしても自分のスキル面での成長が止まってしまうと危惧しており、逆に「実現可能か全然分からないけど自分の中で一番難しいと思うこと」から手を付けてみたいと考えるようになった。

実際には時間的な制約でできなかったり、あまりに壮大過ぎて結構本気でどこから手をつけていいか分からないというものだったりするのだが*2、少しずつ課題を切り崩して、何とかとっかかりを見つけていきたいものである。

併せて読みたい(というかこれ読めば上記の文は読まなくてよい)

luccafort.hatenablog.com

*1:のちにpyenvとanacondaは自分には不要とわかり使わなくなった。とりあえずpython機械学習したーいという人には最初からpyton3をbrewで入れる方法を勧めている

*2:具体例を挙げると「HDFSより使いやすいインターフェースを備えた分散ファイルシステム」「でかすぎるjobは勝手にクラスタ内のnodeにバラまいて分散処理してくれるworker」「一度に大量のtopicを並列readできるQueue Store」「ぼくがかんがえた最強のBaaS」「Cコンパイラ」「sparkのRDDよりさらに抽象化された分散プログラミングモデル」

英語のリーディング勉強方法についての振り返り

洋書の技術書や英語の論文を読むようになって3か月ぐらいになる。

とは言え、母語が日本語なので日本語の方が圧倒的にinputは早いため、読んでる本の言語比率は日本語:英語 = 8:2といったぐらいである。全然である。「洋書を読んでいる」なんて決して人前で言える量ではない。*1

ちなみに英語で読んでいる技術書は下記。パラパラとわかるところだけ読んでいるものもあれば最初から読んでいるものもある。もともと本は5~6冊をパラレルで読んでいくタイプなので洋書もそんな感じで読んでいる。

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Distributed Computing: Principles, Algorithms, and Systems

Distributed Computing: Principles, Algorithms, and Systems

Big Data: Principles and Best Practices of Scalable Real-Time Data Systems

Big Data: Principles and Best Practices of Scalable Real-Time Data Systems

Java Concurrency In Practice

Java Concurrency In Practice

なぜ英語で読むのかと言えば、技術書に関しては翻訳がなかったり日本語版が絶版になっていたりするため。論文はそもそも基本的に英語しかない。

そのため今は英語のリーディング力を高めるために主に語彙を増やす勉強を中心にしている。

英語の教材としてTOEIC対策の単語帳を使っている。*2

TOEIC(R)TEST英単語スピードマスター NEW EDITION

TOEIC(R)TEST英単語スピードマスター NEW EDITION

手順としては以下のようにしている。大体これで40分ぐらいである。

  1. 1回の学習で50単語ぐらいを目標として覚える範囲を決める
  2. 例文を読んで、意味やニュアンス、類似語、例文を丸暗記するぐらい読み込む
  3. 解説が不十分だと思えば辞書を読んでニュアンスを覚える。
  4. 一通りやったところで赤シートを使って覚えているかどうかを確認する。覚えてなければその部分を集中してやる。
  5. 覚えた単語をざっくりノートに書きだして、それを眺めて意味やニュアンスがすぐに思いつくかどうかを再度確認。

こんな感じでやっているのだが、語彙力がなかなか伸びずに苦労している。 どのように苦労しているかと言えば大きく下記の2点である。

1. 覚えたかどうか分からない

それはともかく、この手の方法で単語を勉強してきたつもりだが、何というか本当に覚えたかどうか、つまり語彙力がついたのかどうか確認する手段があまりにも乏しい。確認できるのは英文を読んでいてその単語が出てきたときに「この単語見たことあるやつだ!」と思えた時か、commit logを書いていて「この場合はあの単語が使える!!!」というひらめきを感じた時ぐらいである。

それでいて2週間ぐらいだってから単語帳で同じ単語を眺めた時に「あれ、これなんだっけな…」となるケースも結構あり、覚えている率は肌感覚で1/4ぐらいであるのだが、果たして本当にそうなのかを定量的に計測する手段がない。これって単語テスト付きの単語帳でも使えばもっと正確に計測できるのだろうか?そういう単語帳買うべき??うーむ。。

2. しんどい

単語のみを覚える努力をしたことのある人ならわかってくれると思うが、使うか使わないか分からない単語を必死に覚えるのはなかなかにしんどい。

「なるほど!こういう言い回しがあるのか!」という発見はそれなりに楽しいにせよ、普段日本語で日常生活を送り日本語で仕事をしている人間にとってはやはり普段使いようがない知識である。どうしても仕事で疲れ切った頭にムチ打って図書館で必死に単語帳とにらめっこしていると純粋にしんどいと思うことも多い。どうして俺は生涯一回使うか使わないかってぐらいめったに見ない「embrace」みたいな単語の使い方を覚えているのか。他にやるべきことがあるのではないか、という気分にもなるが、とはいえ語彙力が貧弱であることは間違いないので頑張ってやるしかない。しかしどこか非効率だなという気分は拭えない。

こんなことを今年入ってからずっと続けてるので、かれこれ半年ぐらいはやってきた計算になる。しかし、いい加減この方法は間違っている気になってきた。

最近採用したやりかた

やり方を間違っている気になってきたので、単語帳作戦は一旦やめることにした。

代わりに、TOIEC Part5-7の問題集を解きまくって、分からない単語出てくる度に調べてメモって覚える方式に切り替えた。ネットで検索するとこっちの方が語彙力上げる手段としては効率が良いという意見もあるし、自分としてもまだ印象に残りやすいと感じている。しばらくはこの方法でやってみる。

また、技術書や論文に出てきた単語も覚えやすいということに気が付いた。 英文を読むとき、分からない単語を無視してとりあえず1センテンス読んで、それから分からない単語でどうしても類推できない単語だけ辞書を引くようにしたら「皆目分からない単語」だけをピンポイントだけで覚えられるようになってこれは効率が良いのではないかという気分になっている。「〇〇から遮断する」という動詞である「insulate」がアーキテクチャの解説でよく出てくるのだが*3、この単語は手持ちの単語帳の動詞コーナーには載ってなかった(索引がないので確定はできないが多分なかった)。そう考えるとやはり技術書に必要な英語は技術書を読みながら身に着けた方が早そうな気がする。

今のところリーディングさえできれば自分の用は事足りるので、もう何も考えずにいきなり英文を読み倒して分からない単語だけ辞書に当たる方が効率がよさそうである。

「英語学習にはまず単語帳が必要だ!」と思い込んでいたのは、大学受験時代の習慣というか思い込みみたいのが強かったからかなぁと思う。しかし、今や大学受験以上の語彙数力必要だとわかってる以上、異なるアプローチが必要なのは自明だよなぁと、自分の短絡さを反省する次第である。

*1:半々ぐらいになったら「趣味は洋書を読むことです」とか言っても差し支えないのではないだろうか。早く意識高い感じになりたい。

*2:ちなみにこの本、今amazonで調べたら結構辛辣なレビューがついていたのでTOIECの勉強にはあまり向いてないのかもしれない。。

*3:モジュール間の疎結合性を説明する文脈とかで

死ぬまでエンジニアでいたい

理想の死に方は、前夜にOSSリポジトリにPRを出して、翌朝には机で突っ伏して死んでて、最期に出したPRのコメント欄がr.i.p.コメントで溢れている。そんな状態。

なんて話を冗談めかして飲み会ですることがある。*1が、本人は割と本気で死ぬまでコードを書いていたいと思っている。

年金がもらえそうにないので生涯働かないといけないみたいな主張を最近各種メディア界隈でよく見る。しかし、それとは別に、体が元気なら死ぬまで働き続けていたいものである。定年で悠々自適におとなしくできる気がしないし、それに、エンジニアとしてならリモートでも働きやすいし、数十年後にはさらにそれに適した社会になっているとも思われるし。

死ぬまでエンジニアでいる。それはおそらく難しい。

40歳を超えた辺りで、現場を離れてマネージャーとかIT芸人とかCTOとか技術顧問とか、そにかく違う肩書で働くようになる人がたくさんいるを見てもわかるように、そもそもエンジニアという職業を長く続けることは難しいと思われる訳で、死ぬまでエンジニアでいるのは多分容易ではない。自分の周りでいえば、現場でコードを書いてる人で一番高齢の人でも40歳で、それ以上は見たことがない。大体それぐらいになるとマネジメントとか会社の広報活動をメインでするようになって、現場から離れてコードを書かなくなっている。

でも自分はマネジメント方面には今のところ興味がない。仕事でそういう振る舞いが必要になって、他の人を巻き込んでそれらしいことをすることはあっても、それを専門にして飯を食いたいとは思わない。

もし自分が現場を離れてプロジェクトマネージャーになったとしても、自分が担当してるプロジェクトでこっそりコードを書いてPRを出したり、開発環境を改善するツールやライブラリを作って配布したり、CI環境を整備してテストとデプロイを自動化したり、PRというPRに目を通してコメントしてまわってウザがられること間違いなし。そんなプロジェクトマネージャーがいたら自分だったらイヤなので、やはり自分はマネージャーになるべきでない。とにかく目についた気になる所は即座にissueを立てて時間ができた瞬間に片っ端から修正するPRを出していく、そんな人間はやはりマネジメントをするよりコード書き野郎として生きるしかない。

ではそれをどうやって実現するか。今のところ割りと真面目に考えている話として以下を考えていたりする。

コードを書き続ける

当たり前のことかもしれないが意外と難しいということに気づいた。なぜなら、仕事における課題は大体コードの外で起きている。コードの外で起きている問題に対処し始めるとあれよあれよとコードを書く時間は失われていく。だから、意識してコードを書き続け無いと1週間のスプリントで何もdeployできない、なんていうのが普通になる。それが習慣化したらエンジニアとしての自分は死ぬと思っている。*2

あと家にいても気になるコードは読む、cloneして手元で動かす、バグを見つけたらPRを出す。気になる技術はdoc読んでわかった気にならずに動くコードを写経して感覚を覚える。そういう習慣が大事。youtubeやニコ動ばかり観ててはいかんのだ(けもフレ12.1話最高でした)。

長らくdocker以外の新しい技術を学んでいなかったなと反省して、最近はelectron本の写経をするなどしている。electronの本というよりモダンなフロントエンド開発の要素をまるごと勉強できてお得な一冊。サンプルコードもES2015で書かれている。

それ以外だとsparkのコードリーディングなど。今年はpythonscalaを今年学ぶ言語として勉強している。

健康の維持

どんなに優秀でも健康でない奴に重要な仕事は振られなくなる。残念ながらこれが人間の心理。人は細かいところをよく見ているもので、毎週月曜日に休んでたりすると必ず誰かがマークしている。コワイ。いわんや、高齢で体が弱いとか、ますます仕事が無くなりそうではないか。それをひっくり返すだけのバリューを出せればよいが、そうだとしてもやはり体調が悪いのは精神的によくないし、長期的にはモチベーションに関係してくる気がする。生涯現役目指すマンにとっては大きな壁となるであろう。

まずは体力ということで、最近忙しかった関係で通ってないけど(だめじゃん)ジムで筋トレしたり走ったりしている。むしろ走る方がメインか。なんでもいいけど運動は大事。運動と瞑想の習慣の無い者の末路はなんとやら、というのは多分正解。

瞑想も『サーチ・インサイド・ユアセルフ』を読んでからやってるが、1日の振り返りになって大変よい。1日に起きた出来事が頭に浮かばなくなるまで瞑想し続けてから寝ると変な気持ちを翌日まで持ち越さなくて済む。

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

あと、生えている最後の親知らずを先日抜いてきた。まだ少し痛い。だが、親知らずも放置したまま高齢になるとますます抜くのが難しくなるし、傷口が塞がるのも遅くなるし感染症にもかかりやすくなる、ということで今のうちに抜いておこうと思って抜いた。幸いにして真っ直ぐ生えていたので歯医者に着いてから10分もかからずに診察は終了した。この歳になるとこういう細かい体のメンテが大事じゃないかと思っている。

それ以外にやっていることとして、月1で温泉に行くとか。もちろんY氏直伝でN氏も絶賛していた交代浴をするのだ。

travel.spot-app.jp

千葉県野田市にある七光台温泉が好きで、自宅からだと電車と徒歩で片道2時間弱かかるのだが、その分土日に行ってもそこまで混んでなくて大変居心地がよい。都内の銭湯はいつ行っても混んでいてあまり好きではない。

nanakoudai.3riku.co.jp

今できていないこと

最近勉強会で登壇することがなくなってしまい、すっかりプレゼンスが下がっている。これはなんとかしないといけない。だが、今のところ発表できるネタと勉強会のテーマが合わなかったりして二の足を踏んでいる。なので基本的にブログやQiitaでのoutputをメインにしようと思うが、できれば今年中に最低一回はどこかで話したい。

あといい加減○○の人として認識されたいが、せいぜい「エモブログの人」とか(これは実際に言われたことがある)、「職業railsマン」程度なので(多分)、もう少し技術的なところでプレゼンスを発揮していきたい所存である。

その一環として、最近読んでいるsparkのコードリーディングの成果を一部qiitaに書き始めた。ある程度まとまったら第二弾を書く予定。

qiita.com

*1:「そういう時に限ってcircle ciが障害起こしててビルドがコケて無念の中死ぬものである」というコメントを酒の席で頂いた

*2:今の会社に入ってから初めて1sprint内で何もデプロイできない経験をして結構ショックだった

自分がRubyMineでRails appを書く理由

基本、Rails appを書く時はIDE(RubyMine)を使っている(それ以外はatomvim)。

今の職場だとIDE使ってるの自分だけで、これまでもだいたい他の人はRails appを書く場合でもemacsvimatom、といった具合だった。Rails appはそういうエディタで書くのが普通らしい(自分の観測範囲においては)。

しかし、自分は仕事でrailsを書くようになってから3年ぐらいになるが、ずっとRubyMineを使っている。理由は下記。

  1. 自分で各種プラグインを入れなくても開発に必要な機能が最初から揃っているのでインストールするだけで開発がすぐ始められる。
  2. リファクタ機能が強力。メソッド名をファイルをまたいで一括で変更できるのが超絶便利。
  3. メソッド、クラスの定義元に一発でジャンプできる。使っているgemのソースを読みたくなったときも一発で手元のrails appからgemのソースへシームレスにジャンプできる。
  4. typoやsyntax erorrをエディタ上で教えてくれるので実行する前にミスに気が付ける。
  5. classやファイルをインクリメンタルサーチで検索してファイルを開くことができる。
  6. クラス構造のtreeを表示できる。1classが500行超えぐらいになるとこれがないとジャンプがつらい。

これらの機能はvimでもemacsでもプラグイン入れれば実現できるのかもしれないが、やり方を調べて設定ファイルを書いて、さらにトラブルが起きたときに自分で調査する手間を考えると、インストールすればすぐ使えて、万が一なんかあってもサポートが効く有料IDEの方がいいと思っているのでRubyMineをずっと使っている。

そこまでエディタにこだわりがないというか、正直なんでもいいと思っている。ただ、web appのメンテという仕事においては、できるだけ早く目的の箇所を探し出してコードを書く必要があるため、その効率だけを考えてエディタを選んでいる。その結果としてIDEに落ち着いている、という感じだろうか。プライベートだとC++Atomで書いてたりはするが、仕事だったらVS使ってると思う。

ちょっとだけOSSに貢献したらすごく新感覚だった話

普段は仕事でコードを書いていて、それでおちんぎんは貰えるし、こんな自分でも多少は社会の役に立っているのではないかなぁという実感がまぁ多少は持てる時もある訳で、それなりに満たされた生活をしている。サラリーマンなので、当然大人の事情でしんどい気持ちでコードを書いてる時も少なからずあるが、それでも仕事は仕事である。頑張って書くのである。そんな毎日。

そんな中、1円ももらえないし、役に立つかどうか良くわからんが、気になったのでやった、というような状況でコードを書いてみたら、不思議な事に仕事でコードを書くのとは全く異なる満足感が得られてめっちゃテンション上がったので、その辺の話をしたい。

ある日、BigQueryにアクセスしている部分で突然エラーがraiseされてトラブったので調べてみたところ、GCPruby clientであるgcloudというgemがGoogleaccess tokenを取得する時に Faraday::TimeoutError をraiseしていたことが原因だった(因みにこの時のgcloudのバージョンは0.12)。 Faradayのエラークラスをそのままraiseしてくることを想定していなかったので、自前で入れていたリトライ機構をすり抜けてしまっていた。

gcloudのnamespace配下で定義された専用のエラークラスがあるにも関わらず、Faradayのエラーを生でraiseしてきたという状況が単純に気になって調べてみたところ、errorをraiseしてきたのはgcloud本体ではなく、そのgemが使っているauth用のクライアントであるgoogleauthというgemの方だった。ソースを読んだところ、確かにrequestする部分でエラーを拾ってない事がわかった。で、gcloud側もこのエラーを拾ってwarpしてない、という状況だった。

正直このエラーをどちらかにwrapしてほしい。Faradayのエラーがそのままraiseされてくるのは流石に想定しづらいし、何よりgoogleauthもgcloudも、独自のエラークラスを定義し、主要なエラーについてはそれでwrapしてraiseするように実装してるのだから統一してほしいというモンである。

しかし、今回見つけた問題に関してはどちらが面倒を見るのが良いのだろうか?個人的意見としては、auth周りで起きている問題なのでgoogleauthに面倒見てほしい。が、googleauthを使ってるgcloud側で面倒見てもまぁそこまで筋は悪くはない。

というようなことを考えていたら、gcloudのrepositoryですでに似たような問題でお悩み相談しているissueが立っていた。なんでFaradayのエラーが飛んでくんねんという話とhttp requestのエラーくらいretryするべきではという話がごっちゃになってややこしいのだが、少なくとも議論の終盤の流れとしてgcloud側が何か対応をする気はないらしかった。

ならば、googleauth側でやるべきことが大体わかってる自分がやるのが良いだろうと思い、googleauthの方にPRを出し、先日approveされた。googleの中の人(多分)のレビューともなると色々細かいツッコミが入るかなと思ったが割とあっさりとapproveされた。まぁ大した修正じゃないしな。

まだマージされていないが、このPR自体はgcloudの方で立っていた件のissueの方で紹介されて、この件はgoogleauthの方に責任を持たせてgcloud側の上記のissue自体をcloseする提案が出ている。大した修正ではないにせよ、半年ぐらい停滞していた議論を少しでもすすめるきっかけを作れたという結果には満足しているし、自分自身も困っていた問題なので、ぜひマージされてほしい。たのむ。

今回の件は多分誰でも出来たことではあったし、ブログのネタにするにはあまりにしょうもない話だったかもしれない。しかし、自分が問題だと感じていることに対して解決策を提示して、それをほかの人が(しかもgoogleの人が)認めてくれた、という結果が、とても嬉しかった。OSSにcontributeしても1円にもならない訳だが、なんというか、多くの人がOSS活動をしている理由が少しだけわかった気がした。

なお、調子にのってopenid-rubyという2年ぐらいメンテされてなかったOpenID(Connectではない方)のクライアントにもbugfixのPRを送ってみた。もうcommiterも放置しててマージしてもらえないかなと思ってたらちゃんとマージしてもらえた。こちらはたまたま壊れてたの見つけたから直したよ、という程度だったが、自分にすぐできるのはこういうことなので身の丈に合った仕事と言えるのかも知れない。

今後も何か自分にできそうなことがあれば積極的にPRを送ってみようと思えた。多分その方が仕事でコードを書くよりも下手すると楽しい。

2017年3月29日追記