禅プログラミング
きっかけ
最近の仕事は難しい仕事が増えてきました。
例えば、あまり触ったことのないプログラミング言語のコードを読んだり、新しい機能のレビューを任されたり、新しいプロジェクトの開発環境の整備を１から作るなどです。
全く知識がないというわけでないので、頭をひねったり、多少調べれば解くことができるのですが、QCDが安定しないのでさてどうしたものかなと考えていました。
前の仕事では1つ1つのステップを設定し対策案を実施し、うまくいったら次に行くを繰り返す方法を習いました。
仮定を立ててそれを実証することを繰り返していればいいよというのは科学的で正しいとは思うのですが、時間がかかりすぎるので、このやり方には限界がありそうでした。
そういう問題意識を抱えていたところ、たまたま禅の本を読んでいて「自分を観察（＝瞑想）すると仕事が捗るよ」という内容を見つけました。
面白そうだなと思って何気なしにやってみると意外とうまくいって、問題に冷静に当たれるようになってきたのでそれについて紹介します。
実務でよくあること
横道に逸れる問題
何か技術的な調査をしているときに、このツールをNPMで入れたらいいんじゃないか、という話を見つけます。
思考停止でそれをいれると、エラーで動きません。原因を調べると、さらに他のパッケージがないとエラーが出て動かないとか、バージョンが上がったら不具合があるよという様々な原因が見つかります。
そういう指摘を検証してやっと動いた！と思ったら、当初の問題を解決するものではなかったりします。そもそもうまく動けばいいほうです。
こんな風に技術調査をしていると別の問題がどんどん起きて、最初の課題ではないところに時間をとられて、時間が溶けていたりします。
また、業務で使っているSlackでレビュー依頼や別のIssueが挙がっていて、そっちを見ていると思考が流されたり、割り込みが入ったりで、気づいたら何をしているかわからなくなります。
検索がやめられない問題
こちらも技術調査でとにかく不具合があって直さないといけないということがあります。原因はとりあえずライブラリにありそうというケースを考えます。
最近だとStack Overflowに出てくるような問題の解法はあまりなく、どちらかというとGitHubのIssueにあることが多いです。
しかし新しいバグを踏むと、Issueで議論中で結論が出ているような出ていないような状態で放置されていたり、人によって違うことを書いていたりします。
こういう時に検索すれば答えがでるかもと思って調べていると、永遠に答えが見つからず辞め時を失うことがあります。
コードを見ればわかるといえばわかりますが、どれぐらいそこにコストがかかるのかを考えるといい塩梅というものがあるはずです。
禅
禅の正式な定義は知らないので何となくで言葉を使っています。マインドフルネス、瞑想、ヨーガとの違いはこの際、聞かないでください。この記事についてはすべて同じ意味で置き換えてもいいと思います。
シンプルに「自分の考えていること、自分のやっていること、自分の体の状態をすべて正確に観察するように努める」という意味でとらえてください。
具体的に言うと、自分がいまどういう感情なのか、自分が何に集中しているのか、その時体に変化はあるのかということに意識を置きます。
もう少し細かいことについてはこれから書いていきます。
やっていること
『いかにして問題をとくか』を考える
はるか昔に買ったはいいのですが、こんなの当たり前じゃないかと思って眠っていた本です。
本の詳細は書きませんが、問題を解くためのフレームワークのようなものが書かれています。例えば、
- 未知なものは何か？
- 与件（データ）は何か？
- 条件は何か？
などです。
今、技術調査をするときはこうしたことを先に大きく目につくところに書くようにします。「この関数が偽を返すことが証明できれば、不具合は必ずこのスタックトレース内にある」とか、そういう具合です。
レビューの時も反復作業系なら「抜け漏れがないことを証明する」、新機能なら「既存の機能に影響がないことを証明する」という観点をぶらさないようにしています（もちろん、意図は複数ありますが）。
この何を解いているのかということを基準に思考を観察していると、いつ思考が横道にそれたか、今どこまで調査が完了しているかが把握できるので、思考が散漫になることが減りました。
また、レビューでも自信を持って、問題がないということを言えるようになった風に思います。
他の優秀な方たちはどうしているのかはわかりませんが（脳内で整理できているのかな）、自分は紙に頼ることが今でも多いです。
感情を観察する
問題が解けずに2，3時間たつと、イライラし始めます。レビューで指摘されて感情的になることはありませんが、同時に修正が大量に来ると頭がかっとなることがあります。
できる限り客観的に対応しますし、外にも出しませんが、かといって仕事中に感情を消すことは少なくとも自分にはできそうにないです。
ただ、感情を観察するようになって、いつそれが出てくるのかがわかるようになってきました。
そうやってメタ的に見ていると、「あ、今頭に血が上ったな」「胸から上に重心が上がった気がする」という兆候がわかるようになってきます。
さらにそれを深めて「普段の状態はどんな状態だろう」「どこから血が上がったのかな」「この状態で思考するとどういう思考になるのか」という観察を進めていると、気が付いたら冷静になっています。
また、今自分は問題についてではなくて、相手によく思われることに注意を向けていたなということがわかると、自然に問題のほうに思考を戻せます。
つまり言い方を変えると感情を観察することで、問題と感情を整理つけてとらえることができるようになったと思います。
これはノートに書くよりも、適当にSlackで自分にDMを打つようにしています。そうやって外に書いていると何となく傾向が見えてきます。
Vimを使う
今はVSCodeのVimバインドですが、Vimは禅にとっていいエディタです。というのも、自分が今何をしているのか、何をしたいのかを正しく認識しないと、操作できないからです。
Emacsでもなんでもいいですが、Vimが顕著な気はします。
選択肢はどれだけあるか、今使うべきキーは何か、設定を変えることで最短を更新できないかなどを考えて作業することで、より禅の世界に近づけるという風に思います。
この分野は自分が語るほど強くなくて、周囲の人は、キーボード、画面分割、エディタの改造、シェルの改造、ブラウザの拡張などをかなりやりこんでいます。
いいエンジニアはそもそも自分のやっていることを把握しているものなのかもしれません。
やってみた感想
何かを考えるとき必ず他の人はどうしているか、ベストプラクティスは何かを探る癖がついています。
それも前職の思考のトレースに近いものですが、そうではなくて自分の軸を作ってそれに従う場面も必要なはずです。そこの優先順位が低いなぁと自分の思考をたどりながら、思ったりします。
そして感情が表に出ているときはパフォーマンスが悪いです。
悲しいはそもそもあまり思わない質ですが、怒りであったり、恐れ、焦り、あるいは愉快さであっても、明瞭に問題を解くときには役に立っていません。
「仕事は 楽しいかね」と最近色々な人に聞かれるのですが、うまく働けているときは問題のこと以外に注意が向いていないのでよくわかりませんという答えになります。
そのための環境は提供できていますかという意図の設問だと思うのですが、そこに入る過程は自分の注意力の向け方が正しいかどうかなので、自分自身の問題だよなぁと感じてやはり回答が難しいです。
自分は満員電車でもあまり苦に思わず、電車の揺れ、人の動き、体にかかる力などを味わうのが最近は気に入っているので、やはり心の持ち方次第ですとしか言えないです。客観的にみて、満員電車の環境がいいとは思いませんし。
今後
いかにも悟りましたという感じで書いていますが、実際は相変わらずSlackに注意をとられたりしますし、自席で仕事をしていれば紙やメモで頭を整理できますが、会話や会議になるとちょっと難しいところがあってまだまだです。
そういう問題に対しても深く観察して整理することで挑める部分もあると思うので、もう少し禅プログラミングを頑張ってみたいなと思っています。
RailsDM2019の振り返り（２日目）
前書き
前日に続いて参加したので書きます。
聞いたもの
操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践
論理削除や削除テーブルなど、操作履歴をどう残すかという議論でした。
最近はフロントエンドが中心でこういう議論を全然していないなと思いつつ、以前はここらへんのやつを大体試せる環境にあったので懐かしく聞いていました。
要求によりますねという当たり前のことしか言えませんが、バージョニングと更新サインで管理しているとテーブルの結合とかがとにかくしんどかった記憶があります。
プログラミングスクールを作ってみた
前に教育担当をしていたので、技術的なところに関しては詰め込めば詰め込めるというのはわかっていました。
なので、カリキュラム内容は充実しているなぁと思いつつ、同時に納得感がありました。
そこから先のビジネス的に利益になりづらいみたいなところは聞いたことがなかったので参考になりました。
ユーザー層も主婦や引きこもりの方が多いということで、知りませんでした。
How framework and buildtool handle webpack?
WebPackerやcreate-react-appなどがどうやってWebpackを扱っていて、どうやって拡張しているかみたいな話でした。
業務で出てくる技術ではありますが、比較して考えたことがなかったので勉強になりました。
ある程度ブラックボックスにしておいたほうが確かにアップデートの時に楽だなぁとは思いつつ、１度ejectしてあとは自己責任という態度はまさしくReactらしくいいなぁと。
Evolution of Enumerator
RubyのEnumeratorを使ったことがなかったです。Enumerableあたりでなんとかできることが多くて、そこまで使い込んでなかったので。
なので聞いた後でもEnumeratorはすごい便利！とは思いませんでしたが、Rubyのループ処理能力の高さとその実装方法が興味深かったです。
Rubyがブロックの中でループを打ち切る能力があるところとか意識してなかったです。よく考えると結構頑張っているのに、推されたことがないので意識してなかったです。
この発表を聞いたことでシンプルに書けることがありそうなので良かったです。
巨大なモノリシック Rails アプリケーションのマイクロサービス化戦略
話としてはシンプルで環境をDockerにしたり、マイクロサービスにしたよぐらいで見返すと難しい話は少なかったです。
ただコードベースがここまで巨大になった時にどうなるかというのは想像できない領域で聞いていて参考になりました。
スライドを見ていてもわかりませんが、実際に聞いていると基本的には技術的に解決できそう、という自信にみなぎっていてすごかったです。
まとめ
２日目は多様なテーマを聞きすぎていて、あまりこれだというまとめが思いつかないです。。
しいて言うと、１日目に比べると１度は経験したことがあるか考えたことがあるテーマが多かったです。
仕事でこういう解決方法をしてうまくいったなぁと思ってはいましたが、自分で納得して終わっていました。
知識の整理をしてみると、誰かにとって役に立つ何かがでてくるかもしれないなと思いました。
あとは、意外に普段話している会話の内容が意外に偏っている？感じがしたので、色んなテーマについて触れることを意識してもいいかもというところでしょうか。
RailsDM2019の振り返り（１日目）
前書き
業務の一環としてRailsDM2019に参加しました。その際にレポートの提出が必須ということで、忘れる前にメモしておきます。
基本的には自分の知らない分野に参加しました。
聞いたもの
"Ask Me Anything" by DHH
名前は知っていましたが、あまり本人が語っているのを聞いたことがなかったです。
「JavaScriptは塩のようなもの」「マイクロサービスは複雑さをもたらす」という持論を延々と展開していて痛快でした。
現在の仕事がフロントエンドな自分としてはあまり大きい声では言えませんが、SPAが過剰な分野はあると思っていて共感できる部分が大きかったです。
発言ではBasecamp社では……という前置きが多かったです。Basecamp社といえば、先日「NO HARD WORK!」を読んでいたので思い出せました。
あの内容も大体「最低限必要なことをやればいい。過剰にするな」という趣旨だったので、まさにBasecamp社の哲学そのものなんだよなぁと。
Railsへの見方が変わる講演でよかったです。
PR
こういうPRも軽い口調のところが多いのは意外でした。
採用目的が多かったですが、楽しさを強調するのがエンジニアにとっての福利厚生というとらえ方が多いのでしょうか。
行き過ぎ感と愉快さが半々ぐらいです。
OpalでつくるBrowserアプリケーション
OpalはRubyライクな記法で書けて、JavaScriptに変換できる言語らしいです。
詳しいことをあまり話していませんでしたが、Virtual DOM、Isomorphic、Web Socketあたりができるという話でした。
ここらへんに関しては、ClojureScript、Elmあたりも見てきているので、Virtual DOMやっぱりあるんだ、そっかぁぐらいの感覚になってきました。
IsomorphicやSSRについては確かに考えたことがなかったです。前に挙げた言語もできるのかどうか記憶にないので、そこまで調べてなかったですね。
見ていて何度もリロードしていて開発体験がよくなさそだったので、自分としては採用しない気配があります。勉強にはなりました。
Active Record Oracle enhanced adapterのこれまでとこれから
Active Recordの詳しいところは知らないし、聞いてみようかなぐらいのモチベーションでした。
中身はRails、OracleのDBに追従するためにどのような戦略をとっているか、というOSSのバージョニングの話が多かったです。
ライブラリを使う側としては早くパッチを……という気持ちだけがあって、作る側の意見を聞いてみると本当に大変だなぁというところで思うところがありました。
作る側からするとずっとRCの時からずっとリリース計画を見つつ、変更に追従しないといけないと考えるとすぐに出せるほうがすごいだけというのがよくわかりました。
破壊的な変更も仕方ないから入れるというところもあり、OSSの辛さとか作っている人の気持ちがよく伝わってくる発表で内容的にはエモくないはずなのに、とてもエモく感じました。
Power-Nap（ランチセッション）
聞き取りづらかったのと、動画の目的がよくわからず、不完全燃焼でした。
個人的には技術的な発表のほうが好きです。ご飯は健康的でおいしかったです。
What's new in RubyGems 3.0
www.slideshare.net
Gemが更新されているということ自体あまり意識したことがなかったです。なので、バージョンごとに破壊的な変更が入ることがあるということも知りませんでした。
細かいインターフェースの変更もしているということで、わかる人にはどんどん使いやすくなっているということらしいです。
ここもOSS開発の分業の仕方（フルコミッターがいるとか、セキュリティ担当者がいるとか）が印象に残っています。
SQLQL は GraphQL にとってなんなのか
www.slideshare.net
GraphQL を勉強中だったので、今ならよくわかるかもと思って聞きに行ったのですが、GraphQL の話していませんでした。
とはいえ、GraphQL の勉強をした際に、「なぜわざわざクエリ言語の再発明が必要なんだ。。」という気持ちはあり、同じ問題意識はありました。
中身はSQLを代わりのクエリ言語として使うというもので、結構DBの仕組みや扱い方を深く扱っていて面白かったです。
OSSというとがんがんロジックを書くというイメージがありましたが、結構他のライブラリやミドルウェアの仕様と戦うところが多く、見方が少し変わりました。
To make Ruby ready-to-use in the data science field. And the impact that it has on Rails applications.
データ分析領域でRubyを使うためにライブラリを書いているという話でした。
Apatch Arrowsというライブラリがあって、C++で書かれているそうで、それをCに変換してRubyから呼び出すみたいな話があった記憶があります。
実際にそのデータ構造を使うと、Railsが早くなったとか。
去年Ruby Kaigiに行ったときにひたすらCのコードが出てきていたので、そういう系統の話には慣れつつありますが、改めてRubyOSSのコミッターの強さを感じました。
万葉のRails新人研修のコードレビューコメントを分析してみました
最近、レビューに時間をかけているので何かヒントを、と思い見に行きました。
分析の手法や見方は好きだったのですが、分類や答えが何となく科学的というよりは、自分たちにとって都合のいい方法でやっている気がしてあまりうまく共感できなかったです。
それ自体が悪いというよりは、そのまま自分たちに流用できない気配だったので、自分たちの組織でやり直してみるのがよさそうという気持ちです。
"雑" / Almost Microservices
必要な設定は全部DBのテーブルに入れてしまえというのは前の仕事では当たり前だったので、すらすら入ってきました。
逆に今の仕事でこれもこれも、オンコードでいいんだと思うところが多くて、戸惑う気持ちがあります。RubyやJSはそんな文化を特に感じます。
テストの仕方や、ユーザーを絞ってリリースするという発想は面白かったです。難しさはありますが、覚えておきたいところです。
作って学ぶ RDBMS
理解できた気もするし、全く理解できていない気もします。
オープンソースとしてのDBは見たいなぁと思い領域でありつつ、C系統だしなぁとか、数学的なアルゴリズムが全開だとどちらにせよわからないし。。と思いながら放置していました。
聞いているとそういう心配はなく、読めるだけの下知識はもらえました。
小さく真似して書いてみるというアプローチも含め、OSSから学ぶ学習法を聞けて良かったです。
Thrifty Rails - How to run a production app on a budget
メモリやパフォーマンスを計測して、自力で直すとお金で殴るよりはいいよねみたいな話でした。
今日は難しい話ばかり聞いていたのでシンプルで聞きやすかったです。
パフォーマンス計測、メモリ監視、全部Gemで行けるよみたいなところで、驚いたところはあります。
特にN + 1問題について、Gemでチェックできるよと聞いてそこまでできるんだという感想でした。そもそもできると思っていないので、検索することもなかったです。
毎日の開発に役立つRailsプラグインづくりの秘訣
人が多くてびっくりしました。今日は人が少ないところばかりにいたので、このテーマでこんなに人が集まるんだというのが発見でした。
中身はRailsのコンソールでの操作が難しければ、WebをGUIにすればいいじゃないみたいなところでこれは盲点でした。
コンソールのWrapperを書くとしてもRailsは選びませんし、そもそもCUIで頑張るほうを選ぶのでその発想がでてこなかったです。
そういうわがままさと技術的な詰め方というところが何となく自分にない感覚が多かったです。
感想
OSSの開発者が普段なにを考えて、なぜ物を作って、どうやって技術を選定しているのかというところを知れたのがよかったです。
自分で作ってみたいという気持ちもありますし、使う側としても背景を知ることで理解や共感ができるようになったように思います。
周りにOSSを書いている人は少なく、本格的なものになるともっと少ないので、今日でだいぶ身近なものになりました。
今回はフロントエンド関係の話をあまり聞いていませんが、発想は活かせそうなので参加してよかったです（と書いたら同僚は納得してくれないだろうか）。
明日もおそらく参加しますが、がちがちのOSS系統は少なそう？なので、別の視野を広げられそうで楽しみです。
2つの文化、2つの世界
背景
これまで自分はシステム開発において、大きく分けて2つの世界で開発に携わってきました。どちらも要件定義～テスト、保守までかかわったことがあります。
前者はユーザー企業の業務系で主に業務改善に関わるところで、よく揶揄されるCOBOL、Excel、VBといういずれの文化を持っていて、古いIT企業のイメージを当てはめると大体当たっているような気がします。
ただし、新しいプロジェクトではC#（ASP.NET Core）、Angular、TypeScriptあたりを触っていたので、すべてが古いというわけではなく歴史的な問題も大きいです。保守対象が明らかに広いので、古い資産が残るのはどうしようもないです。
ユーザー数は最大で数千人ですが、基本的には事業部単位でシステムを組んでいたので、普段は100人未満ぐらいだったと記憶しています。
後者はWeb系で厳密なところは置いておいて、toCの会社です。持っているサービスはいくつかありますが、現状ではほぼ1つのサービスで収益を上げています。
こちらも一般的なWeb系のイメージで考えてもらえればよくて、フレックス、リモートが可能で、Rails、Nuxt.jsでゴリゴリ新機能を追加していくという感じです。
ユーザー数はアクティブかどうかは置いておいて、数10万という単位なので、少なくとも前者とは桁が違います。
前者にいた経験が長くてWeb系への憧れがとても強かったのですが、今少し時間が経ってきて前者の戦略に理解ができてきたので、その世界を中心に考察してみたいと思います。
ちなみに、会社（システム部門）の人数はどちらも100人足らずぐらいで同じです。
ユーザー系の世界
他のユーザー系の事情もそれなりに聞いているので、ユーザー系という主語が大きいのは承知の上ですが、いい名づけが思いつかなかったので、許してください。
開発技術の選定
選定ポイントはいくつかあって、まずは開発している組織が大きいかどうか、サポートを受けられるかどうかに大きな比重が置かれていたように思います。
データベースはOracleが最も多く、開発環境はVisual Studio、言語はC#、OSはWindowsです。Micorsoftとべたべたです。
実際メールで問い合わせをして確認したり、営業の方と話をする機会は多かったです。
ここにはグループウェアがOffice365で、新しい不具合を毎回踏まされるという事情もあるにはありました。ついでにWindows Updateによる影響も切実でした。
ライブラリ選定も基本的には大多数に合わせろ、です。なぜかというと、マイナーなOSSを使って将来的に更新されなくなった時に直す技術力がないからです。
個人的にはVisual Studioの機能の豊富さがすごくて、ほとんどの作業がGUIでできる経験がつめたのは大きい経験でした。
あのエディタのおかげで会社の技術力が底上げされていた感があります。Vimとか、VSCodeでは環境すら作れなかったと思います。
Microsoft縛りで辛かったのは認証回りと、IEがサポートから絶対に外せないことぐらいですかね。（あとはiPhone対応が辛かった）
もう1つあったのは、組織で技術を統一しようという文化がありました。プログラミング言語、ライブラリ、エディタ等々を全部統一して、勉強範囲と開発範囲を最小限にしようという考えです。
当時は反発がありましたが、戦略として今ではわからなくもないです。
社内ライブラリ
実は結構作っていました。プログラミング言語が統一されているのでスケールしやすかったのもあるでしょう。
あとは、技術力が高い人が数人いて、その人たちで他の人の分の作業をすべてするにはどうするかみたいな話があったように思います。
その結論としてできる限り、超高性能なライブラリを作って、それ以外の人は詳細をほとんど知らなくても済むようにしようというそういうプロジェクトがありました。
例えば、新しい管理画面を作るときは、テーブル定義をGUIで設定すると、自動でスキャフォールディングが走って画面の大体ができるみたいな仕組みがありました。
コンポーネント集もあって、それでほとんど賄えるようにしていました。
作っているのは数人で、使っているユーザー数はその10倍くらいいたんですかね。
ただ、中身をみると結構地道なコードで書かれていて、新しい技術は使わないという方針がありました。
なので、OSSをforkして作ったとかそういうことはしてないです。
コーディングの作法
ルールを作って縛る、これが大原則です。
Linterはもちろん、変数名のルールが決まっていましたし、画面ごとのメソッドのインターフェースも決まっていました。細かいことを言うと、テーブル名、カラム名も誰がつけても同じになるようなシステムがありました。
使える技術的な範囲（新しい構文は使わない）も制限されていて、これも優秀な人がレビューして、全部そろえるという原則がありました。
忙しい時は週末に出勤して1日中リファクタリングしている時もあった気がします。
ルールが世間一般と同じかというとそうでもなく、独自インターフェースみたいなものがあったように思います。
それはWeb、デスクトップの両方で統一された世界観でした。ここでも技術的な統一が果たされていました。
機能面
業務系はとにかくビューを作る仕事が多かったです。
作った画面の8割ぐらいは検索系でこんな見方をしたい、こんな出力をしたいという要望（最初はCSVですが、必ずExcelになる）でした。
ここも自動化が進んでいた理由になる気はします。
更新系の画面もありましたが、これは入力項目がひたすら多く、デザイン以前に並べるのがしんどかったです。
ユーザー系の会社だと入力項目をいかに増やすかという要望が大半だったかもしれないですね。
非機能要件については、パフォーマンス要件がかなり厳しくて、レスポンスが何ミリ秒以下みたいな基準がありました。
しかし、社内ネットワークから出さないことも多いので、セキュリティなどはそこまで厳しくなく、サーバーも1台あればさばくのに問題はなかったです。
要件定義、設計
人材の半分以上をここに突っ込んでいて、年長者は軒並みここに配置されているので力の入れ方が違います。
要件定義で数年というケースもあるほどで、どれぐらい正確にやるかというものでした。
こういう分け方をするということはアジャイルではなく、ウォーターフォールということですが、現実にアジャイルでは無理だと思います。
文化として納期の正確さ、機能の欠落が許されないところがあり、調査をかなり綿密にやらないとうまくいかなかったです。作りながらではやはりもれました。
業務を分析して、どこを直すと業務を直すかというのをフローを書いたり、というので専門性があったように思います。
技術と同様にその事業について詳しくないととてもではないが、口にだせる領域ではなかったです。
人材育成
基本的には新卒から育成でした。文系、理系も特に問わなかったので、対人能力と論理的に話せることあたりが採用方針だったと思います。
勉強熱心さはそこまで求められていなかったです。
ただ優秀な数人の半分ぐらいは外部でしたので、優秀な技術力を持つ人を育てることは最終的にできていなかったかもしれないです。
そもそも採用のための広報もほとんどしていなかったので、通年で応募が数十件もなかったです。
仕事の振り方
自分でどんどん見つけたことをやるというよりは、基本的な方針が上から振ってくるのでそれに従います。
もちろん新しい提案はしてもいいのですが、承認プロセスが結構上まで行かないとだめなことも多かったです。
Web系の世界
皆さん知っていそうなので、あまり詳しくは書きません（力尽きている）。
基本的には技術力志向が強いように思います。
レビューもありますが、それを踏まえても最低限のコーディングルールしか注意されず、機能面でのレビューが多い気がします。
開発環境はOSこそMa統一ですが、エディタなどは自由でVSCode派が多いですが、Vim、Emacsなど色々いるみたいです。
言語やライブラリはマイナーすぎるものは選びませんが、サポートなどはあまり気にしていない様子です。
特にフロントエンドについてはいざとなれば自分たちで置き換えたり、直したりできる技量があるので、よければ採用ぐらいの方針です。
社内共通ライブラリは今のところないです。改善する可能性は高いですが、前ほど大規模にやることはないように思います。
画面はコピーで作れるものも少ないのでスクラッチでコツコツ書くという形です。要件定義は誰でも参加できるので、自由に意見を言えます。
業界のルールや知識はありますが、ユーザー系ほど専門領域ではないです。
採用も今の段階では自分たちと同レベルの人をとるというのが基本方針です。
仕事も上からほとんど降ってこないので、自分たちで見つけてすぐに手を出すというやりかたです。
振り返って感じること
ユーザー系の企業のやりかたはシンプルで「技術は優秀な個人に任せて、他は専門領域で勝負しよう」です。
一方Web系の企業は「優秀な個人の数を増やして、全員が多くの領域に参加しよう」でした。
Web系で仕事をする前はとてもうらやましいという気持ちがありましたが、優秀な人のレベルは大きく変わりませんでした。
なので、もし前者で優秀な技術者が多ければ、下のような戦略を取っていた可能性はある気がしています。
Web系の企業は特殊な技術を採用すると人が集まりづらいのはあると思っています。個人の技術力の向上の機会を会社が提供することが一種の福利厚生になっているからです。
特殊な技術ができても、中途で他のところに移るのが難しいですからね。
どんな技術にも好きな人はいるので、そういう会社には行けると思いますが、幅となると辛いのかなという思いはあります。
そういうところで一般的な技術を使いこなしているのすごいなぁ、技術力が高いなぁと思って見ていたのですが、ユーザー系のやり方は一般的ではないやり方をしているだけで知恵がありました。
今のIT界隈は基本的には有名な技術を知っていることを技術力が高いと評価していますが、その評価は正当なのかなと思いを馳せます。
前の会社には技術力を上げたいと言って抜けさせてもらった手前、申し訳ないなという思いがあります。今はとても勉強になっていますが、ユーザー系の会社にとってはやりかたが違うので参考になる部分は少ないでしょう。
だから、自分がWeb系に入って優秀になったということはなく、ただ今のやり方の中から学べることを真摯に学んで、折衷点みたいなところを探したいなと思っています。
Perlに夢中
きっかけ
最近、Perlに目覚めてしまいました。
きっかけはMacbookで開発するようになり、ちょっとしたスクリプトを書かないといけない機会がぼちぼちでてきたことです。
これまでWindowsマシンで仕事してきていたので、何となく調べながらやっているとシェルスクリプトの話になって、そこから芋づる式にPerlに当たったように思います。
前に一度文法書を読んだ時はしっくりこなかったので継続していませんでしたが、今勉強し直すときれいに線でつながるようになり、とても楽しく学べています。
あと、「Let Over Lambda」でダグ・ホイト氏が学ぶべき言語に挙げていたのもあります（他はCとHaskellもあったような）。
やったこと
文法書を何冊か読んで、リポジトリをちらちら覗いています。入門書ではないですが、「Perl Hacks」がメタプログラミングとか、テスト駆動的なトピックも多くて面白かったです。
あとは、「初めてのPerl 」が入門としてはよかったです。
Perlについて思ったこと
機能が意外に多い
Perl6は機能がモダンになっていると聞いていたのですが、Perl5についてはあまり期待しておらずVB6ぐらいの印象を持っていました。Perlで関数型、Perlでオブジェクト指向という文章を見たことがなかったので、シェルスクリプトより少し書きやすい言語なのかなと。
調べていくと関数を値として渡すことも、オブジェクト指向的に扱うこともできました。
分配束縛みたいなこともできますし、タプル、ストリームに近いこともできますし、自分の中でモダンに近いと思えることは大体できました。
細かい差はあるのでコールではないのですが、どうしてこうなっているかという仕組みがわかりやすい分Perlのやりかたは気に入っています。
他の言語との共通点が見つかる
これがPerlを見ていて一番楽しいところです。
PHPは個人的に好印象ではなかったのですが、Perlの文法を見てからとらえ直すと「だから、こういうやり方になったのか」とハッとすることが多いです。変数の宣言もそうですし、スカラーという概念などもここから来ているのかというのを感じる瞬間がとても楽しいです。
Rubyは最初期ほどPerlの影響を受けていないと聞いていますが、それでも正規表現リテラルとか文字列の生成あたりにPerlっぽいシンタックスあったりして、そういうのを見つけた時、にやりとします。
Lispとの共通点で言うとダイナミック変数を使うところとかでしょうか。一時的に設定を上書きするというやりかたをPerlではそこそこ使うので、前に勉強したぞとなりました。
まだ、本格的に勉強していないですが、ソースフィルターをつかえばマクロ的なこともできそうな気はします。Lispほど直感的にはならない気はしますが、ハックとしては楽しそうです。
Perlの後付けオブジェクト指向も、Lispの後付け文法（マクロ）に近い感じがしますね。そういうことを考えるのが楽しい言語です。
読みやすい、書きやすい
Perlというと好きなように書けるので読みづらい、暗黙的なコンテキストに依存するから保守しにくいと聞いていました。個人的にはそういうハックは普通に好きなので、なんだそれ最高だなと。
とはいえ学んでみた感じだと、規則性もしっかりしているので慣れたらそこまで黒魔術ではないんじゃないかという気持ちです。何が起きているのかわからないということはないです。
RubyやJavaScriptでも黒魔術めいたコードをこっそり書く人もいますし、程度の問題ですかね。
Perlは言語学者が設計していて、読みやすく書きやすいようにしているという話があって、慣れてくると自然に読めるという意味でも完成度は高いと感じます。
基本的には大いなる責任が伴ってもいいので、自由に使える言語が好きです。
シェルスクリプトと同時に学べる
シェルスクリプトの延長に近い言語なので、今学ぶと相互的に理解できていいです。
今まで学んだ言語は抽象化されていてあたかも言語の機能みたいになっているところが、Perlでは隠されていなかったりするので、それが見えるのは面白い体験です。
今後とまとめ
文法やこんなモジュールがあるよ！というのを見ているだけで楽しいんですけど、もう少し深堀りしたいなぁという思いがあります。
リポジトリを何個かあたりをつけて研究しつつ、何か作るとすればコンソール系のスクリプトをさらさらと書けるところまで練習するつもりです。
まだまだ未知なことも多いので、一つずつ先人が切り開いた世界を見てみたいです。
あと、昔Perlを書いていたプログラマの人は今Goを書いているという現象を何度か観測しているので、そっちもどこかで手を出すかもなぁと思っています。
仕事とステートマシン
何となく思いついたので、小ネタです。
仕事のとらえ方
仕事をしている状態をどういう認識でとらえるべきか？というのが最近の興味です。
この前の分析ではプログラミングという仕事はパターンの発見、繰り返し、組み合わせあたりで行っているのではないかなという仮説を立てました。
それと似たような見方として、ステートマシン（状態遷移）でも説明できるのではないかと考え中です。
簡単な状態遷移
例えば、単純な疲労度で言うと、
- 元気
- 普通
- 疲れている
- 限界
あたりの状態があって、１日の中でそれが変化しているという可能性はまぁまぁ高いです。その中で、状態ごとにできる振舞いがあって、遷移条件があると考えられます。
そこらへんを明確に定式化してとらえられると便利な使い方ができるの可能性があると思います。
応用例
思考に関しても、
- 深く集中する
- 広く注意を向ける
- 機械的に判断する
- 誰かの思考になりきる
あたりの状態があって、それを適当に切り替えているのではないかと思います。
それを意図的にどういう状態があるのか、どういう時にそれを使うべきか、どうすれば切り替えれるかを認識できれば、もう少し深いものの見方ができる気がします。
やりたいこと
要するに自分が仕事をしているときにどういう状態にあるのか、何ができるのかを知りたいなと思っています。
暗黙的な思考や状態をどこまで自分の管理下におけるのかというところで、言葉や概念にして説明できればいいなと。
ステートマシンの概念はその切り口として役に立ちそうなので、もう少し考えてみたいところです。
2018年振り返りと今年の抱負
2018年の反省
学んだこと
傾向
手を広げたがる
プログラミング言語に5個も手を出してたり、Vue.js、React、Angularのすべて動向をウォッチしているあたり、節操がないと言われても仕方ないと思います。
ここに書いていないものもとりあえずの気持ちで追っかけているので、実際にはもう少し多いですし。
パターンを見つけるのが好き
手を広げたがるのはパターンを読むのが好きだから、という感じです。
自分で新しいパターンを作るよりも、プロジェクトを探してその構造を解析する読むほうが好きなんだなと今年気付きました。
1から新しいプロジェクトを作るよりも、色んなパターンを組み合わせてバランスをとるような物の作り方をしていて、今年はその傾向が特に強かったような感じがします。
技術以外のパターンについて
人についても比較的パターンを見つけて、それを自分の糧にするような学習方法だった気がします。
例えば、
- あらゆることを計算式で表現できる形に直したい人
- コードのすべてのパスに対して、テストを書きたがる人
- あらゆる説明を図に書いて、紙で説明する人
- テストをするときはユーザーの気持ちに完全になり切る人
- すべての作業に対して新しいツールで楽できないか考える人
こういう人たちが周りにいて面白いなと思ったので、時々こういう思考を意図的にトレースして、使ったりしていました。
どちらかというと郷に入っては郷に従えで、その人と話しているときに合わせるケースが1番多い感じでしょうか。
課題
2018年を総括すると、色んなパターンを見つけてはその場に合ったものを選ぶ、というような能力を磨いてきた1年だったかなという風に思います。
なんですけど、今のやり方は例えるなら、職場のコードのパターンを見つけて、それに溶け込むようなコードを書くという使い方で、どうかなぁという気持ちがあります。
仕事ではVue.jsを書いていて、エディタはVSCodeなんですけど、職場で使っている人が多いからぐらいの理由しかないです。
Vim、Emacs、Lispあたりの勉強で身に着けたキーバインド、REPL駆動、その他諸々がつながっていないんじゃないかという感覚があります。
2019年の方向性
考えてみるとパターンを覚えて、それを活かすというやり方は中学生ぐらいから鍛えてきたものなので、今から戦う武器としてはまずこれを前提に置くべきなのかなという気持ちがあります。
そのなかで色んなパターンとか能力をどれだけ越境できるのかを考えてみたいなと思います。
パターンを認識してそれを使うというのはそこまで意識的にやっていなかったので、自分の中で言語化したり、課題を考えたりして、もう少し意図的に使ってみるというのが今年の課題ですかね。
技術的にはGraphQLとWeb Workerあたりには手を付けてみると思います。あとは、Rails、Rubyを業務で使えるまでは慣れたいです。
