No Purpose

If I must say, it's for me.

ペルセウス座流星群など、7月〜8月に撮った写真

7月

超望遠レンズを買った

こんな話をした末に、SIGMA 100-400mm DG DNが生えてきた。

これまで所持していたズームレンズは、常用しがちなTamron 28-75mm/f2.8と、もっぱら星撮り用のSIGMA 14-24mm/f2.8で、次はSIGMA 70-200mm/f2.8で大三元ツモか...なんて思ってたのだけど、なかなか出る気配がなく、「そもそも自分が撮りたい写真は200mmの先にあるのでは？」なんて謎のことを考え出していた矢先、70-200mm/f2.8をすっ飛ばして100-400mmが給付金価格で出てきたので飛びついてしまった。

ちなみに「200mmの先にある撮りたい写真」は、圧縮効果の効いた風景写真や、近くの公園にときどき現れるカワセミ...あたりを考えていた。

ご近所スナップ

今年の7月は梅雨がなかなか開けず、コロナ禍での生活様式と相まって、晴れ間を狙って近所でスナップを撮るにとどまった。

SEL50F18Fでの2枚。

dev_02163

dev_02175

今回購入したSIGMA 100-400mm DG DNでの2枚。

dev_01631

dev_01656

購入した望遠レンズは、おもしろいながらも使いこなすには至らなくて「望遠でf値が暗いレンズを使って絞り優先/ISOオートで撮ってると、こんなに簡単にISO上がっちゃうのか...」という点には今もまだ四苦八苦している。

7月はそんな感じで天気にも恵まれなかったのだが、それを理由にネオワイズ彗星の撮影をあきらめてしまったのが今でも心残りで、毎日の天気をチェックしながら晴れた場所を狙って多少遠出すればよかったと思っている。

8月

基本的には7月と同様で、近隣での写真撮影をしていた。 これはベランダから。

あとから、レイヤーの優先度が逆だったと気がついた。

ペルセウス座流星群

近隣で撮影をするも、ネオワイズ彗星を諦めた心残りからか別の天文ショーをなんとか見に行きたい気持ちが高まり、8/12の極大に合わせてペルセウス座流星群を撮りに行った。 SCWで直前まで天気を確認していたところ、関東圏では房総半島の南端までいけば極大の頃に晴天となる可能性が見込めそうと考え、カーシェアの車で野島埼灯台まで行った。

「極大の時間は、最大で1時間に30個ほど流星が見られる」といった前情報も目にしていたが、生憎、日没からの6時間ほで肉眼で確認できた流星が十数個程度だったと思う。 また、流星が見えても、レンズを向けた先とは別の方向で「ぐぬぬ、あっち向けておけば...」なんてやきもきすることも多かった。

ようやく今のは画角に入ったのでは？という流星があったとしても、撮影できた写真をディスプレイで確認しても写っておらず、首をひねりながら撮影を続け、0時頃に撤収した。 流星群を狙って撮影したことは何度かあったものの、これまで流星の撮影に成功したことはなく、とはいえ、装備や知識の面で今回が一番充実していたのでそれなりに残念ではあったが、まぁ天の川は撮れたからいいとしよう...そんな考えで帰路についた。

天の川。

dev_02621

現地には流星群を見に来た人や同好の士たちが最終的には数十名ほど人がいたように思うのだが、感染リスクを下げるために適度に距離を取って岩場や通路に散っているのが、2020年の流星群らしい思い出と言えそうだ。 なお、感染リスクを可能な限り下げようとすると、ろくに旅先にお金を落とせないんだなと感じた。(食事もコンビニで買って車で済ませた...)

ところが、帰って撮影データをPCで確認してみると「流星撮れてるじゃん！！！」という嬉しい驚きがあった。 今回、少しでも画角に流星を入れるべく14mmという超広角で撮影していたのだが、それだけ広い画角だと、現地でカメラのディスプレイでパッと見てもわからない程度の細い軌跡になっていたようだ。

これは日没直後に撮れたので、いわゆるブルーモーメントに流れる流星となった。

dev_02599

こちらはガスが出始めて、諦めて帰る間際に撮影できた。

dev_03025-2

写真は全てSIGMA 14-24mm DG DN Artで撮影した。 撮影準備/構図や画角/現像等々の面において、まだ工夫する余地はあると感じるが、ひとまず初めて流星のその軌跡を写真に収めることができて、すごく嬉しい。

カワセミ

昨日の夕方、とうとう近所の公園でカワセミを撮影できた。

A7_03337

ただ、運動不足解消のための散歩の傍ら、ダメ元でカワセミがいないかと望遠レンズをリュックに忍ばせたものの、夕暮れどき日陰での野鳥の撮影はかなり厳しいものがあった。 この写真はISO12800だ...。

撮った写真を振り返りながら、そのときの状況や心境を言語化するのはなかなか楽しいことがわかった。

世の中が落ち着いて、写欲が満たされるシーンともっとたくさん出会いたい。

自分にとって苦手だけどもっと訓練すべきと最近思ったこと: 「早く失敗する」

薄々気がついていたけれど、自分は、大小を問わず"失敗"することを嫌う気質があると、最近ハッキリと自覚できた。 そして、これがWeb開発という領域において、致命的と思えるほどに悪癖になりうると気づきつつあって、向き合うためにここに書いてみようと思う。

きっかけは、TerraformによるAWS Fargateの構築でうまくいかなかったことがあり、人に相談してみたところ「とりあえずタスクを手動で実行してみたらどうですか？」と言われ、「え、そんなことしていいんだっけ？」と臆してしまったことにある。 彼から「いま失敗すると何か困ることあるんでしたっけ？」と言われて、確かに、まだそのプロダクトは本番環境で稼働しているわけではないので実害なんて出るわけないことに気がついた。

こんなことわざわざ言語化するまでもないのだが、現代のWeb開発において、失敗することによって得られるエラーはフィードバックの宝庫だ。 実際この件についても、細かく手動での実行を行い、そのエラーメッセージを見てのトライアンドエラーを繰り返すことで、なんとか不慣れな構築を行うことができた。 解決のための技術的なアドバイスに加えて、「フィードバックを得るために"早く失敗すること"を心がけるべき」と助言をしてくれた彼には感謝してもしきれない。

これ以降、くだらないことでも失敗を極度に嫌う自身の思考を省みることが増えた。

  • 料理やってて、レシピの工程を1つ飛ばしたことにあとから気がついただけで、必要以上に落ち込んだり。(別に味の違いはなかった)
  • 最近やってたゼノブレイド(RPG)、全滅によるデメリットがほぼない(最寄りのランドマークに戻されつつ、得られたアイテム/マネー/経験値は減らない)のに、ちょっとリスクある敵との戦闘はすごく消極的になってしまったり。

そして、こういう自分に気がついては「これくらいの失敗を恐れるべきでない」なんて理性的に考えたりする。 「失敗を恐れるべきでない」なんて手垢がついた言葉、こんなに自分が実践できていないだなんて思っていなかった。

また、ただ失敗するだけじゃなくて「早く失敗する」というのがより大事で、それを実現するには技術が必要だというのも感じている。 安全に早く失敗することには、リカバリが効くように影響を局所化しつつ、有効なフィードバックを得る方法を考える必要がある。 たとえば、アプリケーションの設計は実際に運用してみないと良し悪しがわからないことが多いので、早く失敗するには

  • どの機能なら影響が小さいか
  • どうすれば速やかに元の状態に戻せるか
  • 何の指標でフィードバックを得られるか
  • どういった手段でフィードバックを得るか

といったことに向き合うことになる。 これらを考えることは、長期的にメンテナンス可能なアプリケーションを設計するのと同じくらい重要なことと感じる。

こういった思考のクセみたいなものは一朝一夕では直せないとわかりつつ、こうやって言語化して向き合うことでもうちょっとマシになったらいいな。

「クリーンアーキテクチャ」をこう読んだ

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

読み終えた。良い本だったと思う。

この本を読んだモチベーション

  • Goで書かれた簡素なレイヤードアーキテクチャによるマイクロサービスを会社で触る機会があったり、新たなサービスの切り出しを検討していたりして、Rails以外のサーバサイド設計についてもっと知見を深めたかった。
  • そんな中で、上司との1on1で「マイクロサービスパターン」を紹介してもらい、その本を読む前段の読み物としてよさそうと感じた。
  • 「Design It!」を社内の読書会で読んでいて、アーキテクチャ関連の本をほかにも読みたかった。

僕はこう読んだ

  • 例の"同心円状(玉ねぎ)のアーキテクチャ"(= "クリーンアーキテクチャ")の話以上に、その前提になっている「設計の原則」が重要に思えた。
    • SOLID(単一責任の原則 / オープンクローズドの原則 / リスコフの置換原則 / インターフェイス分離の原則 / 依存関係逆転の原則) を、通しで学べるのがよかった。
    • そのSOLIDの考え方を、コンポーネントレベルの議論に押し広げることで、より大きな粒度での設計を考える示唆が得られた
    • これらの考え方自体は"クリーンアーキテクチャ"を採用していなくても重要と感じる(たとえば、Railsでちょっと込み入ったことするときとか)
  • 同心円状の"クリーンアーキテクチャ"は、SOLIDを遵守するための1つのテクニック、という位置づけで捉えるのが自分にとってはちょうど良さそうに思えた。

「設計の原則」での学び: たとえば"DIP"における気付き

自分は"DIP"と"DI"を混同していたことに気がついた。

  • 「DIP: Dependency Inversion Principle」(依存関係逆転の原則)
  • 「DI: Dependency Injection」(依存性注入)

DIはたとえば、以下のようなコードを

class Foo
  def foo
    bar = Bar.new(params)
    bar.call
  end
end

このようにするようなテクニックと理解している。

class Foo
  def foo(something_like_bar)
    something_like_bar.call
  end
end

これによって、Fooクラスは、自分が依存しているBarクラスの存在や、その生成の方法を知らずに済む。 FooにBarという依存を注入した結果として、FooにBarFoo内でBarをnewするような"従来型の依存関係"に対する逆転をもたらす...つまり、"DI"は"DIP"のための手段だと理解できた。

その上で、この考え方をクラス間の依存ではなく、マイクロサービス間の依存に適用できないかと考えて、社のチャットにあれこれ書いていたら同僚の @qsona から有益なツッコミをもらった。 つまり、"DIP'が指す「従来型の依存関係の逆転」とは「"実体への依存"から"IFへの依存"への転換」という指摘だ。

上の例のように「Barクラスという実体」ではなく「 call メソッドを呼べるIF」への依存への転換が、依存性の逆転を実現する。 とすれば、マイクロサービスにおいても「サービス間で定めたIFを守っていさえすれば、対向サービスの実体を問わない」という考え方ができそうだ...。

と、気がついたところで、それってわりと普通のマイクロサービス間の関係だな、あぁこれがサービスを疎結合にするマイクロサービスのメリットなのかぁ、って当たり前のことに思い至ったりした。

同心円状の"クリーンアーキテクチャ"について

f:id:highwide:20200816004615j:plain
https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg

正直に言うと、これは本で語られるほど、いついかなるときも採用できるアーキテクチャではないのかなという印象を受けた。

この本では、繰り返し、DBやWebフレームワークといった"詳細"についての決定を遅延した経験やそこで得られるメリットが語られる。(ちなみに、"詳細"は"detail"の訳語で、"detail"には"些細"というニュアンスが含まれる旨が書かれていた)

ただそれは、現代のWeb開発においては必ずしも美談にならないのでは...という感想を抱いた。

たとえば、yasaichiさんの以下のスライドでは、Hanami(クリーンアーキテクチャを採用したRubyのWebフレームワーク)とRailsを比較しながら、密結合の功罪について明晰に語っている。

speakerdeck.com

あるいは、フロントエンドにおいても以下のエントリをきっかけにFirebaseを隠蔽すべきかという議論が盛り上がったことが記憶に新しい。

blog.ojisan.io

これらの議論は、現代のWeb開発においては"クリーンアーキテクチャ"が否定するような特定フレームワークやデータストアとの密結合を利用したいシーンがそれなりにあることを示唆している。 スタートアップにおいて素早くトライアンドエラーを行いたいときなど、意図して密結合を選んだうえで初速を得る選択肢も持つ必要があると思えた。

...何より、著者のアンクルボブ自身が以下のように語っている。

「アーキテクチャ？御冗談を。これはスタートアップだぜ。アーキテクチャに時間をかけてる余裕はなかった。とにかくコードを書くんだ！コードがすべてだ！」

-- Robert C. Martin, 角征典, 高木正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計(第VII部「付録」-「明確なコミュニケーション」)

とはいえ言うまでもなく、"クリーンアーキテクチャ"を全否定したいわけではない。

特に、業務ドメインのシステム化が主眼となるエンタープライズの現場においては、ステークスホルダーの意思決定やが遅延したり、各種の政治的判断に振り回されがちな中で、"些細/詳細"な意思決定を遅延できるアーキテクチャというのは大いに価値がありそうに思える。

もちろん、Web事業開発においても、

  • トライアンドエラーのフェーズを経て、ユースケースやオペレーションが安定している
  • システム化したいドメインがある程度はっきり見えていて、かつ、それなりの規模になりそう。
  • 数年以上のスパンでの運用がもう見えている

といった状況にはフィットしやすいだろうなと思う。

この本との向き合い方

本著のまとめにあたる「第34章 書き残したこと」は、(なぜか)主著者のアンクルボブではなく、Simon Brown氏が筆を執っているのだが、アンクルボブがこれまで書いてきたことを大筋認めながら、ややバランスを取るような発言も目立つ。

使える選択肢は可能な限り残しておきたいが、理想に走りすぎてもいけない。チームの規模やメンバーのスキルやソリューションの複雑さ、そして時間と予算の制約などを考慮しよう。

-- Robert C. Martin, 角征典, 高木正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計(第VI部「詳細」- 第34章「書き残したこと」-「まとめ：言い残したこと」)

また、「訳者あとがき」でもこんな言葉があったりする。

ビジネスドメインに関係のないことは「詳細」と割り切り、デリバリーの仕組みやフレームワークなどをすべて後回しにしようとする。おそらく異論のある方もいらっしゃるだろう。私もすっきりしていない。

-- Robert C. Martin, 角征典, 高木正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計(「訳者あとがき」)

何度もアンクルボブが言い方と持ち出すエピソードを変えながら力強く主張してきたことに対して、同じ本の中で別の人がこんな発言をする懐の広さに驚いた。 そんな旨をツイートしていたら、t_wadaさんがレスをくれて、自分の感じていたこの本との向き合い方について見事に言い表してくれた。

...というわけで繰り返しにはなるが、僕はこの本をこう読んだ。

  • 結局、"クリーンアーキテクチャ" も適材適所で利用すべき
  • その採用とトレードオフになるものを頭に置きながら「"クリーンアーキテクチャ"の採用」自体も適切に遅延したい
  • 一方で、下敷きになっている原則には、クラス/コンポーネント/サービスという相似形において、適用しやすい有効なテクニックが多い

Rubocopを導入しない世界ですべき振る舞い

このエントリで書いてないこと

  • Rubocopというgem名について

このエントリを読んでその点について議論したくなるかもしれないけど、筆者が書きたいわけではないこと

  • プロジェクトにRubocopを導入するかどうか

このエントリで書くこと

このツイートに至った経緯と、その上での自分の考えを書く。

現職での前提

基本的にRubocopを採用しないプロジェクトが多い。 理由はいくつかあるんだろうけれど、基本的にはこういう話なのかなって思っている。

あるいは「Rubocopが指摘するような事柄の中には画一的に決められるものだけでなく、都度どのような選択をとるべきか考えることに心血を注ぐべきだから」といった考え方があったという話も耳に挟んだ。

これらのスタンスに対する自分の意見としては、

  • これらの考え方は、基本的には自転車置き場の議論になりやすいCop、特にStyleやLayoutに対するものが多いと思っている
  • それらのCopを全てdisableにしたとしても、Rubocopで得られるものはそれなりにあるのではないか(SecurityやLintのCopなど)
  • ただし「じゃあどのCopをdisableにして、どのCopをenableにするのか」のメンテや、メンバーの考え方のすり合わせにコストがかかるのは理解できるので、一律で導入しない選択も全否定しない
    • 特にOwnershipがあいまいになりがちな共通ライブラリであれば、関わる人数の多さからそのコストが大きくなってしまうことは想像に易い

前職では厳し目のconfigによるRubocopに馴らされていたこともあり、導入したくないメンバーが多い現職に戸惑っていたのも正直な本音としてあるのだが、それでも導入するコスト/リターンと、導入しないそれとを勘案したときに、現状の結論に至っていることについての一定の理解はあったつもりだ。 少なくとも、現状の採用していないプロジェクトに後から導入するコストは大きいだろうなと思っていた。(rubocop_todo.ymlみたいなテクニカルな解決ができる話というよりは、メンバーの心理的な話が大きい)

というか、前職ではRubocopの推奨するStyleに異論唱えがちだったのは僕だったんだよな。

本題: 今日あったこと

Railsで書かれたコードのちょっとした修正をするのに Time.current という書き方をした。 ActiveSupport::TimeWithZone を利用した現在時刻の取得だが、この書き方についてはほぼ手癖だったと言っていい。

このPRにおいて、同僚から Time.zone.now に変更するCommit Suggestionをもらった。

自分の理解ではこれらのメソッドは等価だと思っていたので、単なるStyleの違いをどちらかに揃えるよう指摘されたのか聞き返した。

...いや、もっと正直に言います。 「Rubocopを導入しない」ということは「Styleの違いを許容する」だと思っていたので「そういうことの指摘はしないでほしい」っていう態度を示しました。ごめんなさい。

それに対する同僚からのレスとして、自分が入社する前に書かれた「時間に関する緩やかな指針」という社内ドキュメントを提示してもらった。曰く、

  • Time.current は使わないようにした方がいい
  • Time.currentは内部で「 Time.zone がなければ Time.now を使う」という挙動をとる
  • Railsアプリケーションを書いている限り間違いは怒らないが、時間ほど重要なものであれば、念を入れるに越したことはない

といったことが書いてあった。

参考: https://github.com/rails/rails/blob/6a033a06855f0b7a407ff8edbfc9f9aa45527edc/activesupport/lib/active_support/core_ext/time/calculations.rb#L38-L40

このことについて僕は知らなかったので、できる限り Time.zone.now を使うべきという指針は一理あるように思えた。(とはいえ、明らかにRailsってわかってるならどっちでもよいんじゃないかなって気持ちも、正直ちょっとはある)

ただ、New Joinerが目につきにくい場所に"指針"があるのは望ましくないように思えるし、今後は自分も含めて Time.current って使われてるの見たら都度コメントしなきゃいけないのかな？みたいなことが頭をよぎって、当初は素直に受け入れにくかった。

あるいは「だったらRubocop導入すればいいんじゃないかな」って気持ちになったのも事実なんだけど、冒頭書いたように、このエントリで「Rubocopを導入すべきか」を議論したいわけではない。

今思えば、これは「Rubocop導入しないことで発生したコスト」なので、「このコストを払うくらいなら、Rubocop導入するコストを払ったほうがいい！」「なんなら、俺が頑張ってそのコストを引き受けるから導入しよう！」って言うんだったら誠実だよなーと思っている。

はい、そのとおりですよね...↓

で、このツイートに至る

たとえば、僕はなんとなく今回の件は「きっとCopでなんとかなるだろうな」っていう感覚があったから、それならRubocop使えばいいのではって考え方に走るのだが、指摘をしてくれた同僚は知らなかった。

参考までに、rubocop-railsのこのCopで対応できる。

https://docs.rubocop.org/rubocop-rails/cops_rails.html#railstimezone

もちろん「知ってるべき」という考えはあんまりなくて、どっちかというと Time.current の内部挙動について知ってた方がうれしい気がする。

...というわけで結局、ここで長々と書いているのは

「Rubocopを導入しない」ということは「Styleの違いを許容する」だと思っていたので「そういうことは指摘しないでほしい」っていう態度を示しました。

についての反省文なのかもしれない。

じゃあRubocopを導入しない世界ですべき振る舞いとは？

自戒をこめて言語化してみる。

  • 前提として、実利のない(と各々が信じる)議論は避ける
  • その上で、レビュアーやレビューイに「Rubocopがどんなことを指摘できるか」の知識を求めない
  • 結果として、自分がレビューされるときはRubocopのような指摘をもらうこともあるし、自分がレビューするときはRubocopがしてくれるような指摘をすることもある
  • 同じような指摘が何度か続いて、それらのコストとリターンが釣り合わないと思ったら、Rubocop導入を提言する
  • 別途コードガイドラインにしておきたい事項があるなら見えやすいところに置いておく

というわけで、チームにそれなりの習熟度を必要とするんだけど、そこまで無理な世界だとは思わない。

あと、このあたりについて他の人の考えを知れたらうれしいという気持ちもある。

ちなみに

社内の他の言語のプロジェクトではLinter(Formatter)が使われることが多い。 js/tsのプロジェクトではESLint+Prettier、Goのプロジェクトではもちろんgofmt、Elixrプロジェクトではmix formatというものが使われているらしい。SwiftとKotlinはどうしてるんだろう。

あと、Rubocopとは別のアプローチとして、Dangerってツールがあることを知った。(これは社内で使われている)

danger.systems

「Engineer x Coffee Meetup! Vol.1｜ by WORC」でLTをした #worccoffeemeetup

2019/11/27に縁あってこちらのイベントでLTしてきたので、諸々のメモ。

worc-meetup-20191127.peatix.com

経緯

以前、何回かTokyoWebCoffeeという、Web界隈のコーヒー好きが集まるMeetupに参加したことがあって、そこの中心的人物だった @tetsuyaさんから発表の話を持ちかけてもらい、LT発表することにした。結局、今回の発表者はそのtetsuyaさんとTokyoWebCoffee主催者の @kozo002 さんと僕だったので、発表者3人は顔見知りって感じでやりやすかった。

tokyoweb-coffee.connpass.com

発表資料

※ 今回の発表はかなりDEMOやスライド外の説明で補足しながらだったので、改めてこのブログで諸々書きたい

今回の発表テーマについて

f:id:highwide:20160120144447j:plain
SCAA Coffee Taster's Flavor Wheel

↑こういうものがあって「コーヒーの味を表現するときに便利」くらいの雑な認識を僕は持っている。ちなみに、このFlavor Wheelについても、教えてもらったのはTokyoWebCoffeeのMeetupだったなと今思い出した。すごいコミュニティだ。 ちなみにワインでも同様のものがあって、ワイン通らが言う「木の皮のような」とか「白い花のような」みたいなのも押さえられているらしい。

で、このSCAA Coffee Taster's Flavor Wheelについては、前職のときに誰かがコーヒーを淹れたあと、「別に味覚にそれほど自信があるわけではないけれど私はこう感じました」みたいな話をワチャワチャとするときにおもしろかった記憶があり、このコミュニケーションをSlack上で楽にやれたらおもしろいかもしれないと考えた。

作ったもの

このgifのように、Slack上で、どんな味を感じたかFlavor Wheelの内側から順番に選択していくようなSlash Commandを作った。

f:id:highwide:20191128005016g:plain

発表資料にもあるように、TypeScriptで作ったExpressをGlitch上でtscして動かすようにしている。

f:id:highwide:20191128005609j:plain
構成

ポイントは、最初のSlash Commandに対応するmessageを送ったあと、SelectBoxの中身やユーザーの選択内容がInteractiveに書き換えられているところで、これは動いているのを見ると得も言われぬ自己満足感を覚えることができる。

Slash Commandについては、Slack公式が日本語で書いてくれていたチュートリアルが大変わかりやすかった。

api.slack.com

Interactive Messageについては、ドキュメントを見ながら手探りで実装をしていったが、当初は慣れないGlitchでのデバッグが難しかった。(というか、結局printデバッグばかりしていた)

また、自身のTypeScriptの習熟になるように、ExpressをTypeScriptで書くようにやっていたのだが、迫りくる発表当日...という時間との戦いに心折れ、随分とAnyでごまかすようなコードになってしまった。とはいえ、それでも型検査によってバグの予防ができた感はあったので、体験としておもしろかった。

今回の失敗

複数人が投票できない仕組みになってしまった

現職ではSlackの /vote コマンドや /polly コマンドがよく使われていて*1、正直言うとそれにインスパイアされたのだが、いつの間にか、複数人による「投票」のようなことができない仕組みにしてしまっていた。(誰か一人しか入力ができないのだ)

ひとつのメッセージに対して、複数人が選択することで「highwideさんはシトラスっぽさを感じたよ」「うちやまさんはハチミツっぽさを感じたよ」「たかひろさんはスモーキーっぽさを感じたよ」って出てくると、コミュニケーションとしてはおもしろいと思ったのだが...。

ひとりでSlackのコマンドを開発してると、第三者からどう見えるかどう操作できるかって、わかりにくいんだなって思った次第だ。

SCAA Coffee Taster's Flavor Wheelのライセンスについての考慮不足

www.scaa.org

上のページにあるように、このFlavor WheelはCreative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0)となっている。

Creative Commonsについて調べると「あなたがこの資料を リミックスし、改変し、あるいはこの資料をベースに新しい作品を作った場合、あなたは改変された資料を頒布してはなりません」とあり、今回実装したように「Flavor Wheelをプログラム上で取り扱えるようにする」というのが「改変」にあたるのではないかと(実装後に)気がつき、リポジトリをPublicにすることを見送っている。

creativecommons.org

失敗したとはいえ...

普段あまり触ることのないExpressやGlitchなどを触ったり、SlackのAPIについてわかることが少し増えたり、そもそも久しぶりのLT発表ができたりと、楽しい機会になった。

イベントについて

みんなコーヒーについてのレベルが高い...。発表も懇親会めちゃくちゃおもしろかった。

@katsumata_ryoさんが素敵な写真付きでレポートを書いているのでみてほしい。

medium.com

特に、プロなのだからレベルが違うのは当たり前のだが、LIGHT UP COFFEEの川野さんの論理と数値によってコーヒーを解き明かそうとするようなアプローチがとても印象に残っている。資料も後ほど公開されるようで、プロのノウハウがシェアされるのはありがたいなぁって思っている。

*1: 突如チャット上に現れたVoteには「犯人はujihisa」というReactionがよくつけられている

有給消化エントリ

Summary

  • 2015年4月に入社し、だいたい4年半くらい勤務したリブセンスを退職します。
  • 2019年9月6日に最終出社日を迎え、今は有給消化期間中です。
  • 次は10月15日からQuipperにて、RailsとReactを書くソフトウェアエンジニアになる予定です。

転職理由はマネージャーからプレイヤーに戻りたいっていうよくあるやつで、でもリブセンスは総じていい会社だったなぁって思っています。

このエントリは「自身の退職やそれにあたっての胸中を、今誰かに伝えたい」というよりも、キャリアのチェックポイントでまとまった文章をとりあえずダンプしておこうという性質のものです。

リブセンスで何をやったか/なぜ辞めるか

2015/4/1に入社して、当初は企業の口コミ情報を提供する「転職会議」の開発に携わりました。
それまでは、文系学部を卒業して新卒入社した「一次請けしかやらないSIer」でSEをやっていて、業務でほぼプログラミングをしたことがなかった自分にとって、初めて「プログラミングでお金を稼ぐ」経験になりました。
よちよち.rbの活動などを通して少しはRuby/Railsの学習はしていたものの、やはり自身のスキルが業務レベルにないことを感じましたし、受託開発から事業会社へのマインドシフトという面でも当初は難しく思いました。

いくつかの機能改善やグロースハック施策の企画/実装などをやった後、ビジネスモデルの刷新に向けた、新規サブシステムの開発に携わりました。
そこでRailsにおけるElasticsearchを利用した検索機能/indexing機能を実装したのが、自身のリブセンスの経験の中でも、特に腰を据えて技術に向き合えたいい経験だったなぁと思います。

その後、2017年1月にアルバイト事業部に異動しました。
開発しているアルバイト求人サービスは、異動当時は「ジョブセンス」という名前でしたが、リブランディングのために「マッハバイト」にリニューアルを行うこととなり、プロジェクトマネジメントと実装の面で携わりました。
その際、必要なデータを揃えて事業部長と折衝した結果、ガラケーサイトの閉鎖を決められたのが、数少ない「エンジニアに手放しで喜んでもらえる功績」かもしれません。

そんなかたちで、徐々にマネジメント/ファシリテーション/コミュニケーションといった面で、評価してもらうことが増え、徐々にマネージャー寄りのキャリアにシフトしていきました。
最終的には「事業部付のエンジニアリングマネージャー」という立場で、制度の策定や組織運営、採用や1on1などを慣れない身ながらやるようになりました。
これは自身も納得の上でのキャリアシフトで、たくさん失敗をして迷惑をかける一方でそれなりに楽しさややりがいも感じつつ、まだ自身のプレイヤーとしての伸びしろを信じられるうちにプレイヤーに戻りたいと徐々に考えるようになりました。

単純にマネージャーからプレイヤーに戻るだけならば、リブセンスの中でそういうポジションを見つけることもできたと思いますし、上司やVPoEからそういった提案をいただくこともあったのですが、改めてプレイヤーとしての地力を高めるのであれば、4年半いた会社から環境を変えて新しい刺激に身を置きたいと考えて転職に至りました。
自分が怠惰であることを自覚しているので「より新しい何かを求められる場所」に身を置く緊張感が自身の成長につながるという思いもありました。
結果的に、後任となるEMの方の採用が決まり、最低限の引き継ぎ(ができた、とか言うのもおこがましいので「気軽にランチとか今後も行きましょう」って言ってきた...)のうえで最終出社に至ります。

リブセンスについて

4年半いれば、いいところだけでなく改善すべきところも見えはしつつ、自分にとってはいい会社だったなぁと心から思います。
職種を問わず「頭がよく・勤勉で・話しやすい」と三拍子揃った人が多かったのは、Webエンジニアとしてのファーストキャリアとして、すごくありがたかったなぁと振り返っています。 (そして自身の成長は、優秀な同僚たちに多大なる迷惑や無礼や不出来さを押し付けながら得たものだったなぁと思い返しながら)
というか、単純に、"友達"みたいに思える人たちが多かったのも、振り返ってみて楽しかったなぁと思うことです。
勉強会、写真撮影、ボドゲなどなど、この楽しい縁が続けばいいなぁって思います。

また「改善すべきところも見えはしつつ」なんて偉そうな書き方をしましたが、そんな「改善すべきところ」を見つけた上で実際にボトムアップで改善行動を起こそうという人たちが多くいるのも好きなところでした。
何か課題が見えているときに「不平不満をこぼす」「指摘する」「レビューする」で終わるのではなく「自身は、改善に着手することが許されたポジションである」という心持ちで振る舞うことを「与党であれ」という表現をした取締役がいて、僕もわりとその考え方が好きでした。
※ すごくポリティカルな表現に聞こえてしまうことや、会社経営においてまごうことなく"与党"である取締役が言ったことで、あんまりうまく"いい言葉"感を伝えられていない自覚はある...。

f:id:highwide:20190830205505j:plain
社内では「うなぎさん」って呼ばれていた

これは最後にやったテーマ縛りLT大会「0x64物語」で、 @dkatsura_bot がお疲れメッセージをQuineにしてくれた様子。
「うなぎさん」と「お疲れ様!」をループする。

転職活動について

転職活動は、LAPRAS経由でのスカウトと、リファラルに頼りました。
あまり転職を意識していなかった1月頃にいただいたスカウトに、カジュアルに会うだけの対応をさせてもらいつつ、5月頃から選考に進みました。
最終的に決めた転職先だけでなく、合否を問わず、今の自分のスキルやフェーズが違えば選びたかったと思う会社も多く、最後まで悩みながらの活動でした。

LAPRASは、Scoutyというサービス名だった頃に登録したのだけれども、登録したこと自体すっかり忘れていて、それでもGitHubやCONPASS等の活動履歴がスコアリングされた結果スカウトに繋がっているのだと気がついて驚きました。
(久しぶりに自分のページを見に行ったら、諸々のインターネット上のログがアグリゲーションされててヒッとなったのも正直な感想)
ただ、HR事業や採用に多少なりとも関わっていた身からすると、転職者にも人事にも過度な負荷をかけないようにしながらマッチングを行うための仕組みとして考えられているのだなぁという思いもあります。
何にせよ、転職活動が自身が行う採用活動について示唆をもたらすことも多々ありました。

次の会社について

リクルートマーケティングパートナーズ傘下のQuipperにてスタディサプリの開発に携わる予定です。
Software Engineerの肩書きのもと、RailsとReactを書くポジションに就くことができました。
Railsももっと知識を深めたいのですが、それ以上にReactやモダンフロントエンドに関しては業務未経験なので、有給消化期間中にAWS Loftに"出勤"してキャッチアップするなどしています。

Quipperは入社前からTwitterでフォローさせてもらっていたような優秀な人たちが多かったので、これ以上ない「新しい刺激」になりそうです。
また、海外オフィスの方たちと同じコードベースを触るにあたって、英語でのドキュメンテーション等が求められるので英語学習の必要もありそうです。 とりあえず、瞬間英作文とduolingoを始めました...。

残念なこととして、前オフィスから徒歩1分程度の距離なので、これからも目黒でランチ食べるのかぁという思いはあります。
(おいしいところはあるんだけど、流石に飽きた感はある)

というわけで

ありがとうございました！！
よろしくおねがいします！！

自作キーボード入門した

状況です

f:id:highwide:20190728013750j:plain
Mint60作ったぞ

かわいい...。しかもまだキートップの面で伸びしろがあるんだぜ...。

ここまでのあらすじ

Apple純正からHHKBへ

現職に2015年に入社して初めてUS配列のMacを手に入れた。 しばらくは内蔵キーボード/Apple純正キーボードを使っていたのだけど、そのうちHHKBが気になるようになった。 で、そのタイミングで友人が安くHHKBを譲ってくださると言うので思わず手を上げた。 ツイート探したら2016年12月だった。

HHKBは今でも大好きなキーボードで、オフィスではこのとき譲ってもらったもの使っていて、家ではBluetoothのHHKBを買い足して使っていた。

分離型キーボードへの憧れ

現職入社のタイミングで「その方がかっこいいから」という理由でUS配列を選ぶあたりでお察しなんだけど、基本的にミーハーであることを自覚している...。

というわけで、数年前から左右分離型キーボードが流行り始めたタイミングでは、HHKBに不満はないながらも、ちょっと気になる存在になっていた。 ただそのときは、同僚にErgoDoxなど使わせてもらったものの、格子配列のキー配置になじめず導入は見送っていた。

そんな中、mistelのBaroccoシリーズを知る。 格子配列でない(このときは「row-staggered」なんて言葉を知らなかった)HHKBライクなデザインで、分離型。かっこいい。 特にMD650Lの渋いデザインがすごく気になっていた。

Mistel BAROCCO MD650L 分離式 メカニカルキーボード 英語配列 Cherry ML Switch ML1A 採用 アイボリー/グレー MD650L-LUSMGAB1

Mistel BAROCCO MD650L 分離式 メカニカルキーボード 英語配列 Cherry ML Switch ML1A 採用 アイボリー/グレー MD650L-LUSMGAB1

ただ、欲しい物の優先順位考えて、しばらく見送られる存在ではあった。

見送りつつ、気になってる存在。当然、友人が使っていると気になってしまう。

そして沼へ

で、上のツイートのやり取りの中で「軸」の話になるんだけど、僕の「どの軸がどういうキータッチか...という感覚がない」ことに対してこんな指摘が入ったのだった。

ただ、このときはまだ「遊舎工房」の名前は聞いたことがあったものの「キーボードを自作したい」とまでは思えていなかった。 あんまり言語化された理由はなかったように思うんだけど、社内の自作キーボード部の人たちがだいたい格子配列のキーボードを作っていて「自作キーボード = 格子配列」っていう図式がいつのまにか脳内にあったからかもしれない。

というわけで、勢い余ってこんなツイートをしてしまった。

そこで教えてもらったのがMint60だった。(しかもお二人に教えてもらった)

これは...完全に好みだぞ...。もう引き返せない...。(という自分に対しての納得感形成)

ただ、自分は学校の「技術」の科目などでもはんだごてを使った経験もなかったので、とりあえず遊舎工房でmeishiキットを買ってみて、「自分が自作キーボードという行為を楽しめるか」という確認を兼ねる練習をしてみることにしたのだった。

meishi

Q: 自分が自作キーボードという行為を楽しめるか

A: めちゃくちゃ楽しめた

作成にあたっては、職場の自作キーボード部に感謝するところも大きくて、はんだごて/コテ台/はんだ線/マスキングテープ/ニッパー/作業マット等々、めちゃくちゃ器具が揃ってたので、キット買いたての一番テンション高い状態から特に追加投資の手間などもなく、スルッと沼に入っていくことができた。

キーは左から「画面ロック・前の曲・再生/停止・次の曲」に割り当てた。 これは「オフィスで、トイレに行こうと立ち上がったあとに、画面ロックして曲停止する」みたいなユースケースにおいて普通にめちゃくちゃ便利だった。

meishiのキー配列↓

https://github.com/highwide/qmk_firmware/blob/highwide-settings/keyboards/meishi/keymaps/default/keymap.c#L20

あとは、初めてやったはんだ付けも普通に楽しくて、下手なんだけどまたもっとやりたいなーっていう思いを抱くようになった。

Mint60

というわけで、meishiを作り終えて早々に、当初の目的だったMint60に手を出してしまったのだった。

キースイッチはGateronの静音赤軸を修飾キーに、静音茶軸を文字キーに使うことにした。 キーキャップは遊舎工房の人には「Tai-Haoを想定して作られてる」と教えてもらったのだが、「せっかくなら自分なりのこだわりを見せたい」という初心者のくせに厄介なこじらせを見せて、一番文字の印字がかっこよく見えた「MDA Big Bang」を選んだ。

※ あとから、自作キーボード界隈の人が集うDiscordで「Big BangはErgodox系統向けのセットなので、ANSIよりのMint60だとそういうやつ向けのBig Boneのほうがよかったかもしれません」といったことも教えてもらった(善意で教えてくださったものの、「内訳は見ていない」とのことで要確認だとは思う)

で、昨夜作り終えて、冒頭の状況に至る。

失敗したところ

めちゃくちゃ気に入ってるんだけど、やっぱり自作初心者ということもあって、失敗した点はいくつもある。

  • キーキャップの配置。左手小指は当然Capslockなんて使わないのにちょうどいいキーがなくて代用してたり、キーキャップの規格がわかってなくて遊舎で買い足したパステルカラーのキーは高さが違ったり、右側の最下段の親指キーに至っては長さが足りなかったり。
    • とはいえ、これは買い足せばなんとでもなるかな。(と言って、また沼にズブズブと...)
  • ProMicroの"モゲ"防止にエポキシ接着剤を使ったんだけど、液の混合比率をミスって、イマイチ固まらないままはんだ付けしてしまった...。
  • ネジ止めしてから、はんだ付けし忘れてるキースイッチにいくつも気づいた。会社のキーボード部にはテスターもあったから、ちゃんと使い方覚えて、早い段階で確認していけばよかったな。
  • 作り方の説明にも注意が書いてあったけど、LEDに基板側の端子が接触してショートしてた。(しかもケースに入れないと再現しなくて苦戦した)
    • てか、LEDの保護テープ外すと接着面がでてきたけど、あれは保護テープ外さなくてよかったんだろうな。

とはいえ、学びを得つつ、最終的にはきちんと実用に耐えそうなものができた(気がする)ので、初めてのフルキーボード制作としては個人的には大満足している。

こだわり

静音

キースイッチを静音のものにしただけでなく、遊舎の店員さんに教えてもらったOリングというものを導入した。

Qisan メカニカルキーボードに対応 耐用シリコン 防水性を付き　静音化リング（白色）

Qisan メカニカルキーボードに対応 耐用シリコン 防水性を付き　静音化リング（白色）

これをキーキャップにはめこんでからキースイッチに挿すことで、打鍵におけるキーがよりマイルドになる。 あれこれキースイッチを試してるうちに、自分は青軸のカチャカチャみたいな感じがそんなに好きじゃないことがわかってきたので、いっそのこと静音に振り切ることにした。

キーマップ

これは正直うまくいくかわかんないんだけど、いま時点のこだわりとして。

自分は前職にいたときの「ソフトウェアエンジニア仕草なんもわからん」みたいな時分に教えてもらった「シェルでは矢印やEnterやTabキーを使うな。Ctrl + 文字キーでなんでもできるぞ！」という考えに影響を受けてしまっていて、C-f/n/b/pやC-a/eでカーソル移動して、C-[でesc、C-iでtab、C-h/u/k/wで文字削除して...みたいなキー入力をしている。

で、MacOS使ってる限り、だいたいのソフトウェアで問題ないんだけど、たまにユーザーの「Ctrl + キー」を自らのプロダクト専用のショートカットキーとして奪っている不埒なサービスがあって(会社で使ってるServer版のJIRAとか)、そういうわけでKarabiner-elementsの「Emacs key bindings」をインストールしていた。

で、自作キーボードならもっとハードウェア寄りのところでキーマップ設定ができるんだしと思い、普段Ctrlを打っている左手小指の修飾キーを「限りなくCtrlに近いレイヤ切り替えキー」として設定し、そのレイヤでは「Ctrl + f」の感覚で「→」が入力される...といったキーマップを書いてみた。(これならC-fとして入力されるのではなく「→」として入力されてるので、諸々のソフトウェアは奪えないはず、という判断)

https://github.com/highwide/qmk_firmware/blob/highwide-settings/keyboards/mint60/keymaps/highwide/keymap.c

まぁ、正直あれこれ試しながらブラッシュアップすることになると思うので、これはひとまずいま時点の考えを残しておくくらいの意味しかないかもしれない。

いずれにせよ、早く慣れるほど使いこなしたい。

というわけで

Mint60は主に会社で使っていきたいと思っている。

会社と家でキーボードが変わることによるコンテキストスイッチが今から心配。(そして、それを言い訳にしてもう1基買っちゃうんじゃないかというのも心配)

これ読んでくれた人も自キー沼にハマっていこう。