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

それがこれとこれ。

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

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

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

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

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

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

Ergodox配列不定期報告

f:id:shishi4htn:20180804155138p:plain

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

レイヤ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 キーボード:ディレクトリ名:コントローラー

のように書きます。

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

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

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

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

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

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

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

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

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

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

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

通信制の情報系大学院に入りたい

プログラマーはいわゆる理系に分類される職業ではあるが、文系の人も割りとたくさんいると思う。僕もその一人である。たまに文系出身者同士で話をすると、理系の専門教育を受けてないことによるコンプレックスをかかえている人たちがちらほらいる。僕もその一人である。

必要に応じて知識を得てきたし、何か大きく劣っているとは思わない。むしろ勉強してきて得た知識に自信もあるにはあるが、どこかコンプレックスがある。そのことを払拭したいがため、以前から情報系の大学院で学んでみたいと思っている。

検索してみれば同じような考えの人も見つかる。Serverspec等で有名な宮下さんも過去にそのように考えられたようだ。

mizzy.org

社会人向けに入れるところを探してみると大学では結構あるものの、大学院は少ない印象を受けた。社会人向けの大学院もあるにはあるが関東圏で夜間や土日を基本としているようで、通信制は見当たらない。

最近できたという東京通信大学というのも見たが大学のみのようで、大学院はなさそうだ。

良さそうな通信制大学院はないものか…

クルーズ&アトラスを買ってみた

プログラマーは座り仕事であるが、事務作業の方のように前傾姿勢での作業はあまりないと思う。座っている間は考え事をしている時間のほうが長いと言われていて、そのようなときには後傾姿勢のほうが向いているらしい。

たぶんプログラマーの人たちはこんな座り方をしていないだろうか。

エンジニア座り - Google 検索

上記のような理由からすればこのような姿勢になるのは自然なことのように思える。

僕もそのような姿勢で快適に作業したいとずっと思っていたが、スタンダードな既成品ではそのような姿勢での作業は快適に行えない設計になっている。かつそのような姿勢をサポートしない製品で後傾姿勢をとるとヘルニアの危険性もあるらしい。そこでこのような姿勢をとることを前提とした製品を探す必要がある。

椅子だけでいえばワーキングチェアには後傾姿勢もよくサポートしてくれているものはあるが、机はまずそのような姿勢をサポートしてくれない。

そこでこちらの製品である。

Cruise & Atlas (クルーズ&アトラス)|デスク・テーブル|株式会社オカムラ

昔ミクシィが大々的に導入して話題になってことで覚えている人もいるかも知れない。オカムラはみんなご存知バロンなどで有名な日本のオフィス家具メーカーである。

後傾姿勢をちゃんとサポートしてくれそうな製品はこのクルーズ&アトラスとエンベロップデスクに適当な椅子を組み合わせるぐらいしかないと思う。どちらもめっちゃ高い。

僕はクルーズ&アトラスのセットと付属品で23万円前後かかった。ここまでかかるともう10年は使ってやらないと気がすまない。保証は3年しかないが、そこはオカムラを信用しつつ修理しながらになるだろうなあと思う。

この机と椅子の詳しい特徴はググってもらえれば分かるとして、簡単に言うと机が上下し、角度が変わる。実際にセッティングするとこんな感じになる。

最初は机部分の端に前から持っていたエルゴトロンMXをつけていたんだけど、重さで机が安定しなくなるのと、当たり前だけどディスプレイが近すぎた。なので、おとなしく専用マウント用金具を使ってエルゴトロンLXを買って取り付けた。快適になった。専用アームでなくてもつけられることはこれから購入を検討する人には知っておいてもらえればと思う。

これで椅子を思いっきりリクライニングして、机の下に滑り込むようにすると、腕を机で支えつつ斜めになった机がフィットする。ディスプレイを高めにセッティングして下向きに傾けることで大きく後傾姿勢をとっていても快適に閲覧できるようになる。

この姿勢を取ると首、腰を椅子に預けたままなので負担が減る。また、腕を机に預けられるので長時間キーボードに手をおいたままにできる。さらに、この椅子と机はとても低く設定されているので足をベッタリと床につけることができ、体重分散にも役立つ。ほとんどの椅子や机は日本人の体型には高すぎるそうですよ。

この快適さを表せる客観的な何かがあるわけではないけども、控えめに言って快適です。Ergodox、MX Ergo等と合わせて、あれだけいつも起こっていた腱鞘炎、腕の痛みがなくなり、腰や首のコリ、痛みも控えめになってきた。もっと長い時間使っていけば、そんな体の不調もあったと忘れられる日が来るかもしれない。