2016-10-19 06:26:00 +0900
https://github.com/mumumu/repos_file_update_checker
以前 PEP 8 のファイル更新だけをチェックしたくて、 Mercurial 向けのファイルチェッカを書いた 。
今年になって Python のリポジトリが Github に移行した ため、それが役に立たなくなった。よって、以前書いたものを Git にも対応させ、プラグイン化してかっこ良くしたものが上記である。
みんな大好き Github ... といえども特定ファイルの git log 出力を RSS で吐いてくれたりはしないんですよね。。
2016-10-12 05:58:00 +0900
http://www.thanko.jp/shopdetail/000000002595/
自分の寝室にはベッドしかなく、ノートPCを膝に乗せて長時間弄るのは非常に苦痛だ。寝たままPCを弄りたい！という動機は誰でも考えるようで、以前はゴロ寝deスクアルミというやつを買っていた。
寝たままPCを弄れるという夢が叶うことに加え、デスクスタイル、ソファースタイル、ベッドスタイル等、利用シーンに合わせて形が変えられるというウリに飛びついたわけだが、以下の欠点があった。
使ってみてわかったのだが、寝たままでPCを打つ姿勢って意外に長く保てない。よって、場合によってはカジュアルに姿勢を動かしたいとか、移動したいとかいうニーズに上記の欠点が仇となり、あまり使わなくなっていた。やっぱ軽くて取り回しの効く奴が欲しいよねー、という思いがあったのは間違いない。
粗大ごみを始末していた時、この使わなくなったゴロ寝deスクに気づいた。ふっと軽くて取り回しの効く奴、という欲望を思い出し、調べてみると後継のシリーズが出ているではないか。我ながら懲りないなあと思いつつ、早速ポチってしまった。上の画像がそれである。
「腕が疲れそう」とか、「おんなじじゃね」とかいろんなことを言われたが、1kg を切る重さに加え、調整すべき場所も天板と脚の部分と意外に少ないので、個人的には扱いやすくて気に入っている。ただ、新しいものだからプラシーボにかかっている疑いも否定できないので、暫く使ってみるつもりだ。
とりあえずは、10ヶ月ぶりにエントリを書く気になった、というのがこれを買った一番の成果と言えるのではないだろうか(´ー｀; )
2015-12-29 23:34:00 +0900
https://patchwork.mercurial-scm.org/patch/12367/
Mercurial に patch を送ったんだけど、patchを投稿するにあたっての規約 がいろいろと面倒だった。なんとか順応できたけど、普段から GitHub に慣れきっているとこういうのはつらい。逆に言えば、Pull Request という共通のプロトコルを提供している GitHub の偉大さを体で思い知ったというところか。
やまねさんの物言いは、そういう意味でもっともだと思いました。まる。
OSSはライセンシングという共通プロトコルによってリーガルコストを下げた。GitHubはプロジェクト・プロダクトごとの決まりを共通化したプロトコルを導入することでコミュニケーションコストを下げた。OSSという観点ではコストを下げてアウトプットを最大化しているのだから正しい
— henrich (@henrich) December 28, 20152015-12-29 22:22:00 +0900
2015年ももう少しで終わろうとしているので、今年がどんな一年だったかを振り返っておこうと思う。
なんといっても、所属が変わったことが一番大きい。それによって、それまで手掛けてきたものに対する要求も大きくなった。環境が全く異なり、期限もあり、頑張る人もいない中で、いろんなバランスをとりながらチームをリードすることが一番大変だった。そんな中でも成果をきちんと出せたのは自分の中で大きな財産になると思うし、技術的にも得たものは大きい。勿論、これはチームメンバの誰一人が欠けても、成し遂げられなかったことである。縁があって一緒にやってきた方々皆に感謝したい。
所属が変わったと書いた。これによって組織のカルチャーも大幅に変わった。ビジネスサイドを理解し、判断の根拠を他人任せにせず、自分なりのベストを（例え間違っていても）アウトプットすることが求められるようになった。これによって「情報を隠さず、誰が相手でも正直ベースでぶつかる」という自分のスタイルを全力で貫いても困らなくなった。それが、チームのリードに苦労した中でもうまくやってこられた大きな要因かもしれない。
技術的には、去年やっていたこと に加えて、プロダクトのスケールを妨げるあらゆる要因を潰すことを延々とやっていた。Redis Cluster の導入とか、プロダクトのコアのチューニングとか、バッチの速度を数十倍にしたりとか、それは本当にスケールするの？ とコードを書く人たちに問い続けるとか、そんな感じ。プロダクトに機能を付け加える人達の裏で、それの邪魔をしないようにするための基盤を作ることだけに徹した。
忙しさが大きくなると、周囲の動向に関する視野や問題意識が狭くなると思う。問題意識と視野あってこそのアウトプットなのだから、余裕を持って楽しもう。それが2015年の目標である。
去年こんなふうに書いたが、忙しさに紛れて、今年も余裕がなかったと言わざるを得ない。それは今年のエントリが少ないことを見ても明らかだろう。ただ、技術を楽しみながら、書いたコードを外部に還元することは忘れなかったつもりだ。 Redis のクライアント周辺については、必要に迫られながらも良い成果を出せたと思うけど、インプットもアウトプットもまだまだ足りないなあと思う。切磋琢磨する相手も増えたので、いろいろな人と協働しながらもっと楽しみたい。
来年はエンジニアとしての立ち位置が問われる一年になるはずだ。純粋に手を動かし、楽しむだけでなく、明確になりつつあるストロングポイントを踏まえて、どうしていくか。なんらかの答えを出さねばならない。
本当の意味での正念場といえよう。
2015-12-29 21:56:00 +0900
2015年は Redis と戯れていた一年と言っても良い。Redis Cluster を Production 環境に導入し、redis-py-cluster に READONLY 対応の patch を送った りした。
Redis Cluster は Redis 3.0 で加わった新機能であり、もうじき 3.2 が出ようとしている。そんな状態の中で 2.8 でしかテストされていないのはどうなの？ と思い、以下の 2つの patch を送っておいた。
特に前者は、2.8 によるテスト環境をごっそり 3.0 に入れ替えるものなので、割とドラスティックである。Redis 側で 2.8 をいつまでサポートするのか、というポリシーが明確ではないので、取り込むタイミングは流動的だと思われる。
ただ、3.x 特有の機能が増えていく中で、一石を投じる必要としては今がいいんじゃないかな、と思った次第である。