「プログラミングElixir」を読んだ

プログラミングElixir第2版を翻訳者笹田さんから頂けました。ありがとうございます。

プログラミング Elixir(第2版)

プログラミング Elixir(第2版)

  • 作者:Thomas,Dave
  • 発売日: 2020/12/01
  • メディア: 単行本

ElixirについてはErlangVMを利用した言語であり、なんだかRubyインスパイアな部分があるらしい関数型言語であると何年も前に知ったものの特に学習はしていないという状態でした。

また、本書の原著者Dave ThomasはRubyの普及に大きな影響があったと語られるピッケル本の作者であるのみならず、まさに世界のレジェンドプログラマーRubyをメイン言語として愛用する自分としてはRubyの良さを広めた彼が次にお気に入りの言語としてElixirを挙げているのは結構気になっていました。 さらにタイムリーなことに弊社でもElixirの機運が上がっており、まさに渡りに船というタイミングでいただけることになったのでした。

まず、本書はElixir習得のための総合的な入門書です。某所ではよくこういう書籍に関して「プログラマ初心者にとっての本ではない」というレビューがつくことがありますが、本書もプログラミング初心者のための本ではありません。プログラミング的な知見をある程度備えたElixir初心者、もしくは学習済みの人が知識を総ざらいするための本です。

序盤はまずElixirのもつ型や構造体の説明ののち、関数型言語の特徴的な扱いというか、考え方について解説が割かれます。パターンマッチに始まり、例えば、本書で whileloop といった代表的な繰り返し制御構造を見ることはありません。その代わり何度も再帰を使う場面に出会います。Rubyやその他いわゆるオブジェクト指向言語では再帰を使えてもあまり積極的に使う場面は少ないと思うのですが、Elixirではこういう風にするとクールだというふうに聞こえるぐらい再帰を使います。パターンマッチと再帰になじんでくると、なんだか関数型言語っぽい書き方ができるようになってきたなという感じになります。リストの扱いもオブジェクト指向言語たちでは見かけないやり方なので、Emacs LispCommon Lispになじんでなければリストの扱いにはもう少し苦労したかもしれません。

中盤になると、組み込みの依存管理ツール兼プロジェクト管理ツールである mixGithubと連携する使ったちょっとしたCLIツールを作ってみる章に入ります。近時のプログラミング言語にはこのようなツールの扱いは必須で、とても実用的と思いました。テストの書き方にもちゃんと振られており、実際に全部写経しましたが手にElixirをなじませるに良い教材となってくれたと感じます。新規プロジェクト作成、テストも何も言わずに最初からセットアップされており、依存性管理もビルトイン。このスムーズさはやはり新しい言語ならではという感じがありました。

その後、より本格的と言うか、ElixirとErlangのパワーを知れる内容に移っていきます。最近の言語が備えていなければならない安全に並行プログラミングを実行する機能、OTPサーバー、スーパーバイザ、タスク機能といった具合です。どれも入門書にある内容と思えないほどしっかりと解説がされており、コード量もしっかりしているので全部写経することは時間的な都合でできませんでしたが、辿れる考え方はもちろん規模や方法の違いはあれど、実世界の問題にも十分に適用できそうです。スーパーバイザとクロージャでもっていた値を新しくデプロイしたアプリケーションに引き継がせる例はこれがこのコンテナ時代より前にもっと知られていれば…と思わせる大変おもしろい体験でした。

終盤は高度な機能としてマクロやビヘイビア、プロトコルについて説明されます。マクロはともかくとして、プロトコルは実世界上のプログラミングでよくお世話になる予感があります。Javaでいうところのインターフェイスに近いものと理解しました。

要所に要所に演習問題がありますが、本を通してみると結構な量があります。すぐ解けるようなものばかりではなく、結構考え込んだりもします。ちなみに答えは用意されていないので、どうしてもわからない場合はGithubで探すことになります…僕は探しました。 演習問題と合わせて写経しながら本書はそのコード量と合わせて相当なボリュームとなります。

本書の最初に 「赤いカプセルをとれ」"Take the red pill" という映画マトリクスの名言が出てきますが、今だこういう世界観に対するあこがれのある自分としては最初に本書に引き込まれるきっかけとなってくれました。大変ずるくて効果的ですね。あと本書は全編に渡りカラーでした。紙の本を久しぶりに読んだこともあり、新鮮で驚きました。

本書を読了した今、さらにElixirのウェブフレームワークであるPhoenixに入門してウェブ開発への知見を深めていくか最近噂のIoT用フレームワークNervesを学んでいくか、うずうずしているところです。

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

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

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

それがこれとこれ。

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

のように書きます。

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