そういえば何度か会社に入ったり出たりしました

ジョブホッパーな僕だけど、今何の仕事してるよって言ってた記事は

shishi.hatenablog.jp

が最後だった。およそ3年も前の記事である。当然仕事も変わる。

前回記事から現在まで

• フリーランスとしての職は別にずっと継続

  • まあこれはやめたっていうまでいつまでも名乗れるので継続とかどうとか言う問題ではないかも知れない

• 前々職

  • タケユーウェブ
• 前職
  • Kabuk Style
• 現職
  • ???

タケユーウェブ

いわゆる小規模SIer。以前からの友人であった竹内さんが立派な志を持って始められた会社。社員4,5人ながら色々と細やかに気を使っていただき短い期間ではあったが楽しい経験だった。以前からフルリモートワークで働いてはいたが、そういえばここが初めての「会社として全体をフルリモートワークとする」を選択していた会社だった。

ここを辞めることになった理由はちょっといろいろありすぎてインターネット上では書けない。たぶんこんなふうに仕事をやめるのはジョブホッパーの自分でもこれ一回きりだと思う。

KabuK Style

HafH というサービスを提供している会社。友人の紹介でつなげていただいたベンチャー。

既にエンジニアは数人いたものの、ドメインやメールサーバーの管理がどうなっているかなどを誰も把握しておらず、ドメインが失効するところだったのを食い止めて整理したり、10年ぶりは固いレンサバ触ってGCPに持っていったり、ほっとくだけで爆発することが見えていたDB構造の再設計、それに伴うアプリケーション全体の再設計、AWSからGCPへの移行など、思い出すだけでめまぐるしい日々を過ごした。死ぬほど働いたが、別にそれが辞めることになった理由ではない。自分が納得したハードワークはどんとこいである。

現職

まだ試用期間中なので秘密。ブログに転職したと書くのにあえて一定期間秘密にするのを友人たちがやっているのを見て僕もやってみたかった。またこの記事と同じ様にいつか思い出した頃に書くと思う。

今言えることは、変わらずフルリモートワークであるが、普通にみんな同じ日の、同じような時間に働く普通のことを期待されるのが何年ぶりなんだっていうぐらい久しぶりなので、そういう働き方に普通に頭と体がついてこない。いつのまにか一般社会に適応できてない体になった…

「それが僕には楽しかったから」を読んだ

それがぼくには楽しかったから 全世界を巻き込んだリナックス革命の真実 (小プロ・ブックス)

何がきっかけかは忘れてしまったけど、そういえば読んだことない本なので読みました。古い本なので電子書籍化はされておらず、久しぶりに紙の本を買うことになりました。寝る前に横になって本を読むのが習慣化しているのですが紙の本だと照明がないと読めないという当然の事実の前になかなか読書が進まなかったので旅先で籠もって一気読みしました。

自分の知る限りは最初のそして唯一のLinuxを生み出したLinus Torvaldsの自伝です。

内容として語られていることはこの本が古いこともあり、既にLinusの人となりとして知っていたエピソードが多いので、あまり特別に新しい発見ということは少なかったのですが、やはりプログラミングが楽しいという点でつながるLinusと自分というだけで、こんなに同じ感性があるのだと思うと楽しいものがありました。金をもらうのは嬉しいが、もっと優先したいものはあるし、ただ面倒だとかそういう理由で世の中ではすごく大事そうなことを避けることもあるみたいな… 原題は "Just for fun" ですが、原題も、邦題も良いと思います。ただ楽しいからやってただけなんだということは何度もLinusの振り返りとして書かれています。与えた社会的インパクトには大きな違いがありますが、自分にもその気持ちは理解できます。

プログラマーというか、プログラミングが好きな人には不思議とこういう感性が共通する人が多いように思います。そしてそのような感性はいわゆるプログラマーではない人たちからすると理解しにくいものであることが多いようです。なので、世界一有名なプログラマーといっても過言ではないLinusからプログラマーとはこんな特性があることが多いということをわかってもらうために、プログラマーでない人に読んでもらうと面白いかもしれないと思いました。

VS CodeのRemote Development: Containerを実用したい

VS CodeのRemote Development拡張が登場して騒がれて少し経ちました。

code.visualstudio.com

僕は開発用にUbuntu Desktopを使っていますが、PCゲーマーであるのでWindowsを手放すことは出来ません。さらにゲームを実行するという関係上Windowsを仮想化して使うことも考えにくいです。なので2台(もしくはLinuxを仮想化)で開発することが当たり前になっていました。ちなみにMacも長く使ってましたが最近の開発者の方を見てないなという姿勢を見てMacは完全に卒業しました。ゲームというWindowsのような維持理由があるわけでもなく、開発用として持っているのにネイティブDockerが使えないことも大きい。なんにしろいくつも環境を維持するのは面倒です。なのでできればWindowsだけで開発できれば楽です。

現在のモダンな開発環境の中心にはDocker、もしくはコンテナがあります。ただ、エディタやIDEがローカルインタプリタやコンパイラを必要とする例も多くあり、結局ローカルにもコンテナ内部と同じような開発環境を作っている方は多いと思います。Appサーバーに相当する部分だけdocker-composeから外したりとかする人も多いですよね。 Windowsでこのように一部をローカルで賄おうとするとWindowsだということがだいぶつらくなります。貧弱なCUI環境とか、Unix系ツールがないこととか、パスの表し方とか、そもそもWindowsで動くことを想定しないライブラリの多さとか…だからLinuxを開発に使うわけです。

じゃあってことで開発環境はコンテナ内部に全て置き、XでコンテナからGUI飛ばしてみたりとかするとかするわけですが、実際にやってみるとこれがまた使いにくてたまらない。

コンテナ内部に閉じ込めて快適に開発できる環境が作れればWindows使ってようがMac使ってようがLinux使ってようが関係ないポータブルかつ独立した開発環境を作れるのになあと思っていたところに現れたのがVS CodeのRemote Developmentです。先のXでなんとかしようとしたときと発想は近いですが圧倒的に使いやすいですね。往時のCEOがLinuxはガンとまで言ったMicrosoftがCEOも変わり積極的にOSSを取り込もうとする姿勢になっているはとても良いです。

登場からしばらく経ちましたが「使ってみた」の記事はたくさんあれど、実用している人の記事は全然ありません。そこで複数のプロジェクトで実践してみた設定例を公開してみようかと思いました。

github.com

Windows側からはリポジトリに含められないファイルを最初にコピーするだけで、ソースコードもファイルシステム上の都合からパーミッションやらシンボリックリンクやら問題があるのでWindowsからマウントしません。volumeも使わないのはdocker buildの段階でできる限り構築してしまいたかったためです。

この設定で立ち上げたコンテナに直接アタッチして開発するイメージです。ほとんどのDockerhubにあるようなDocker Imageでは直接コンテナ内でデイリーユースするための想定はしていないのでシェルや周辺ツールを整えて使います。日頃からそのへん自動化している皆さんならセットアップは苦にならないでしょう。最初からコンテナ内部にいるのでdocker-compose exec とか必要ありません。楽です。

他の人がどんな快適な使い方をしているのか気になります。

プログラマー35歳定年説の当事者になりました

1月27日に35歳となりました。定年です。

プログラマー35歳定年説

僕がプログラマーになった頃にはまだわりと一般的であるかのように言われることが多かったように思いますが、最近は35歳を過ぎて活躍するプログラマーが増えてきたことであまり聞かなくなったように思います。

自分が35歳になってみて、言われてみれば確かに今までと全く同じようにバリバリプログラミングだけしているということはなくなりました。技術顧問やってみたり、チームビルディング手伝ってみたりと、一歩引いた仕事が増えているのは事実です。このような仕事には一定の現場で培う経験がないと理解できないことが多々ありますので、違う技術とはいえ最初からこのような仕事を専門にすることは難しく、現場から一定程度はそのような仕事をする人がでないといけないのは理解できます。とはいえ、同年代の現役プログラマーは増える一方です。これからもそれが続くのでしょうし、35歳定年説は今聞かなくなってきているように、いずれ消えていく言葉なのだと思います。現在最も広く使われる古い言語の一つ、C言語が生まれてからまだ約50年。まだまだ若いこの業界なので、キャリアのモデルケースもまだまだ安定していないということですね。

ただ僕はプログラミングやものづくりが好きなので、この仕事の現場から全く離れたところにいくことはない、というのは昔からずっと変わっていません。これからも経営で数字を追うような人ではなく、ものづくりの現場でものをつくれる立場でいたいなあと思います。

正直なところ集中できる時間の減少、学習効率の悪化、病気になりやすくなったなんかは実感しているのですが、まだまだそんじょそこらのやつらに負けてたまるかという気概でプログラミングしております。

人間の能力というスペックが加齢で衰えてくるのは仕方がないことなので、筋トレや自分に快適な環境を揃えるなどして衰えに抵抗しつつ、アーリーリタイヤ目指して日々頑張っていこうと思います。

あと寒いのが年々ますます嫌いになってきてるので国内では沖縄、海外ではタイあたりに移住することを割と真剣に考えています。そのへんの経験者いればアドバイス募集！

今年買って一番良かったもの 2018

今年もあと半月で終了です。

個人的な今年は滑り出しこそ旅行ずくめでよかったものの春頃には石灰付着で左腕が1ヶ月ほど動かなくなり、別の病気で手術したあと3ヶ月ぐらい寝っぱなしの生活になったり、他にも人に言えないことのあれやこれやですさまじい厄年でした。間違いなく人生で一番つらい1年でした。

買い物方面ではクルーズ&アトラス、Erdodoxなど生活を変えるものもあり、悪くなかったと思うのですが、一番良かったと思っているのは別のものです。

shishi.hatenablog.jp

shishi.hatenablog.jp

それがこれとこれ。

TROND Bluetooth ヘッドホン V4.2 ワイヤレス ヘッドフォン 密閉型 オーバーイヤー ヘッドセット aptX Low Latency対応 高音質 重低音モデル 最大30時間再生 コーデックインジケーター付 マイク内蔵 ケース付

Inateck 2?in 1?Bluetooth送信機と受信機、デジタル光学式Toslinkと3.5?MM Auxオーディオアダプタforテレビ、APTX low latency

Bluetoothの送信機とヘッドホンです。ヘッドホンは今や無線で当たり前の世界ですが、PCでの利用、特にゲームや映像によく触れる人間にはずっと遅延が気になるものでした。

ゲーマー向けヘッドホンなんてものもあるんですが全て独自規格な上、圧倒的に連続稼働時間が短いのが問題でした。だいたい1日つけっぱなしなんてこともある我々には稼働時間は申告な問題です。

そこで別方面からの解決を探るわけですが、Bluetoothでヘッドホンを接続するコーデックのひとつに aptX Low Latencyというものがあり、これは遅延が40ms以下であることを保証します。どれぐらいのものか使ってみないと分からんなと思っていましたが、全く遅延は感じません。特に遅延に敏感な人間ってわけではないと思うんですが音ゲーやっても分からないぐらいなんで少なくとも僕に感じることは出来ません。有線にもDA変換やら信号が伝わる速さやらで遅延はもちろん存在するんですが、実際それを感じてないだけですしね。最近は無線のほうが有線よりはやいものもあるので有線である意味がどんどん減ってきていますね。

音質という意味でもCD音質を許容する帯域を持っているので、多くの場合問題ありません。気合を入れて聞きたいときはもともと持ってる別のいいものかスピーカーを使います。ほとんどそんなに気合い入れることはありませんが。実際みなさんのほとんどが毎日聞いている圧縮音源は間違いなくCD以下です。

ヘッドホン自体の傾向はドンシャリで別に褒めるところはありません。これはもう値段という意味でも仕方がない。逆にお金を出してもまだaptX Low Latency対応ヘッドホンの選択肢がほとんどないので現段階ではこれぐらいで様子見しておくのが良いんじゃないかと思っています。

これのおかげでゲームをするから仕方がないと有線ヘッドホンを使い続けてきた家の環境でも、ふとしたときに煩わしいケーブルから解放されました。なんともニッチな問題の解決かとは思いますが同じ問題を持っている人には超オススメです。

Ergodox配列不定期報告

現在の配列はこんな感じ。

レイヤ1

親指Enterにはすっかり慣れたけど内側親指キーはやっぱり微妙に遠く、親指位置にあるDelやBackspaceは全く活用できない。

外側にCmd/Winを配置してみたが意外に便利。KeyHacと組み合わせてCmd/Win+JにIME切り替えを当ててみたが押しやすい。IME単独にキーを当てるのはなんだかもったいなかったのでちょうど良い。Cmd/WinキーはOS側からグローバルショートカットが多くあたっていることも有り、発想としても良かったのではないかと思う。

最下段のキーたちは一番親指側にあるAlt以外はほとんど使っていない。一番端のMehはかぶり防止の為にグローバルなホットキーを当てたいアプリケーションに当てていたりするのでその時のみ使う。内側から2番めにはAlt+Shiftを当ててある。この配列だとAlt+Shiftはすごく押しにくいので稀に便利。それ以外は設定以来たぶん押下したことがない。

レイヤ2

ちゃんと記号入力に活用するようになった。といっても右手ホームポジションにあるカッコ3種ぐらいが実用範囲。他は入力機会がそこまで多くないので思い出している間にレイヤ1で入力できる。ブラケットはレイヤ1での配置都合上どうしても良い場所がなかったこともあり、レイヤ2に配置してなれたことでとても入力しやすくなった。

また、メディアキーをレイヤ3からレイヤ2の空いた位置に配置した。そこまで使うものではないけどたまに便利。

レイヤ3

完全に移動用のレイヤになったので気持ち的にスッキリ。VimやEmacsのカーソル移動法から離れつつ快適にカーソル移動するのにだいぶ役立つ。一応配置してみた戻る/進むボタンは設定以来押したことなし。

その他

ずっとファームウェアコンパイルには ErgoDox EZ Configurator を使ってきたけどその他の設定値をいじりたくなり、ローカルでコンパイルするようになった。とはいえ配列を変えるのにはこちらのツールのほうが便利なので、こちらで配列変更後、配列ソースコードをダウンロードしてローカルで整形して自分の設定に合わせてコンパイルしている。とても便利。

make 方法が割と頻繁に変わっているようで、現在は

make ergodox_ez:shishi:teensy

のように

make キーボード:ディレクトリ名:コントローラー

のように書きます。

最後のコントローラを省略すると転送せずにコンパイルだけすることになります。

エンジニアリング組織論への招待を読んだ

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

僕は本書を読んで、題名とは違う印象を受けた。「エンジニアリング組織論への招待」というより、「エンジニアリング的思考から見る組織論への招待」という感じ。

同じ会社で共通の会社の発展という目標を持っているのになぜ人とのいさかいが起こるのかというようなテーマの話が前半に続く。

その後に経験主義や仮説思考の話が出てくるが、僕はこの思考ができる人とそうでない人に大きな仕事能力の差を感じてきた。まさにこの辺の思考が僕の仕事への取り組み方なので言語化されてみると新鮮だった。

アジャイル開発の歴史が簡単にまとまっていたりするのも面白いが、この本の一番力が入っていたところは技術的負債に関する章であると思う。

いかに技術的負債という言葉が生まれ、どのように今日のように受け入れられ、どのようにまずい点があるのか。技術的負債に関する章については、今まで考えたことがない視点の話が多くあり、僕にとっての本書の価値の多くもこの章にあったと思う。

全体的に、「エンジニアリング」とタイトルにあるだけあり、多くの人が言語化せずに理解していることを言語化して書いてくれていると思う。読んでいて確かに言語にするとこの通りになるだろうなあと思いながら読むところが何度もあった。多くの人に気づきを与える名著であると思う。

エンジニアとして小さな単位から大きな単位まで率いるリーダーはもちろん、エンジニアでない立場でもエンジニアを率いる立場の人は読んで損はない。