2018年振り返りと今年の抱負
2018年の反省
学んだこと
傾向
手を広げたがる
プログラミング言語に5個も手を出してたり、Vue.js、React、Angularのすべて動向をウォッチしているあたり、節操がないと言われても仕方ないと思います。
ここに書いていないものもとりあえずの気持ちで追っかけているので、実際にはもう少し多いですし。
パターンを見つけるのが好き
手を広げたがるのはパターンを読むのが好きだから、という感じです。
自分で新しいパターンを作るよりも、プロジェクトを探してその構造を解析する読むほうが好きなんだなと今年気付きました。
1から新しいプロジェクトを作るよりも、色んなパターンを組み合わせてバランスをとるような物の作り方をしていて、今年はその傾向が特に強かったような感じがします。
技術以外のパターンについて
人についても比較的パターンを見つけて、それを自分の糧にするような学習方法だった気がします。
例えば、
- あらゆることを計算式で表現できる形に直したい人
- コードのすべてのパスに対して、テストを書きたがる人
- あらゆる説明を図に書いて、紙で説明する人
- テストをするときはユーザーの気持ちに完全になり切る人
- すべての作業に対して新しいツールで楽できないか考える人
こういう人たちが周りにいて面白いなと思ったので、時々こういう思考を意図的にトレースして、使ったりしていました。
どちらかというと郷に入っては郷に従えで、その人と話しているときに合わせるケースが1番多い感じでしょうか。
課題
2018年を総括すると、色んなパターンを見つけてはその場に合ったものを選ぶ、というような能力を磨いてきた1年だったかなという風に思います。
なんですけど、今のやり方は例えるなら、職場のコードのパターンを見つけて、それに溶け込むようなコードを書くという使い方で、どうかなぁという気持ちがあります。
仕事ではVue.jsを書いていて、エディタはVSCodeなんですけど、職場で使っている人が多いからぐらいの理由しかないです。
Vim、Emacs、Lispあたりの勉強で身に着けたキーバインド、REPL駆動、その他諸々がつながっていないんじゃないかという感覚があります。
2019年の方向性
考えてみるとパターンを覚えて、それを活かすというやり方は中学生ぐらいから鍛えてきたものなので、今から戦う武器としてはまずこれを前提に置くべきなのかなという気持ちがあります。
そのなかで色んなパターンとか能力をどれだけ越境できるのかを考えてみたいなと思います。
パターンを認識してそれを使うというのはそこまで意識的にやっていなかったので、自分の中で言語化したり、課題を考えたりして、もう少し意図的に使ってみるというのが今年の課題ですかね。
技術的にはGraphQLとWeb Workerあたりには手を付けてみると思います。あとは、Rails、Rubyを業務で使えるまでは慣れたいです。
途中参加のプロジェクトに慣れるまで
近況
最近、これまでとは違うプロジェクトに途中参加することになって、大きな環境の変化に対応する日々を過ごしていました。
これまではフロントエンド・バックエンドの両方を触っていましたが、今はほぼフロントエンド専任です。
技術的にはNuxt.jsが中心で、Angularに似ているとはいえ、その違いを吸収するのに時間を使っていました。
事前にNuxtとVueの情報を拾っていたので「たぶん、行けるだろう」と思いきや、プロジェクトの理解に半日ぐらいかかって、自分の中で困惑することが多かったので、その知見を書いてみようと思います。
プロジェクトを理解するまで
実際の画面を触ってみる
参加するころには大体の画面はできていたので、とりあえず何も考えずに触ってみました。ある意味、ユーザー目線に近かったので、この時の気持ちを書いておけばよかったのでは、と今更ながら思ったりします。
何となく20分ぐらい触って大体の機能を拾っただろう、とこの時点では思っていたのですが、ここで開けなかったページがあったみたいです。
手探りだと体系的にはいかないですね。ちなみに仕様書はあったそうですが、「最初は書いていたけど、更新されている自信はない」といわれたので、あまり確認していません。
フォルダ階層をざっとみる
Nuxtは基本階層が決まっているので簡単かなと思ってみていました。
２階層目以降は、スマートフォンとPCでコンポーネントを分けているという話を事前に聞いていたので、まだつかめました。
3階層目はドメインごとに切られていましたが、ここがわからなかったです。実際の画面の言葉は日本語で、ファイル名は英語なのでそこが微妙にしっくりきませんでした。
それでもなんとなくは理解して、これで仕事できるかなと思いました。
直近のIssueを直してみる
Issueをつぶすのが当面の仕事だと言われていたので、直近3つぐらいのものを適当に取り出して、直せれば理解できたんじゃないかと勝手に考えて、やってみました。
ですが、全然できませんでした。
Issueは大体ドメインの言葉で書かれていて、それがどこに当たるのか全く分からないという感じです。Issueも砕けた表現が多く、暗黙的に大体知っているよねみたいなコンテキストで書かれている気がしました。
なので、まずIssueの内容が理解できなかったので、その対策を考えました。
用語表を作る
とりあえず、ドメインで使われている用語、変数名、意味の対応表をひたすら作っていきました。
コンポーネント志向なので、その階層も意識しながらひたすら書き込んでいきます。
そうすると明らかに同じ意味でありながら、違う変数名があったり、違う階層なのに名前が近いものなど不思議なものもいくつかありました。
そういう絶妙なものが理解を難しくしていたところもあり、それをはっきりと定義づけできるとやっとIssueの意味が理解できるようになりました。
コンポーネントを図にする
最後にIssueはデザインを修正するものだったのですが、意味が分かってもコンポーネントの配置関係がわからないと直せないなとなりました。
最初は開発者ツールでやっていましたが、同時の視認性が弱いなぁと思って、スケッチブックにページごとにコンポーネントの配置を書きました。
それで見ると、どこがデザインの要なのかがわかって、それでIssueの解法がわかりました。そこまでくると、他のIssueもやっつけられそうになったので、理解を終えました。
知見
Issue駆動でプロジェクトをとらえる
最初は漠然とプロジェクトを見ていましたが、「何を知りたいのか」「何を直したいのか」をはっきりと定義することで理解が加速した気がします。
それがIssueである必要はないと思うのですが、はっきりとした問いを立ててそこから理解するようにするとものの見方が定まるように思います。
用語を理解する
用語の問題がここまで大きいとはあまり考えていなかったです。バックエンドのロジックであれば、DDD的なものの見方が大事だと思っていたのですが、フロントエンドの部品もドメイン的な性質が大きいんだなと感じました。
名前と意味を正確に定義するということ、フォルダの切り方の大切さと、最初にそれを説明するのが結構大事なんだなと思いました。こういうのもREADMEにあってもいいのかもしれないですね。
手を動かす大事さ
見るとか、理解するという感覚は漠然としやすいです。なので、書くことが大事な気がします。
コンポーネント図を作っていると見やすいというのもありますし、能動的な頭の働きがあって、疑問とかも浮かびやすいです。なので、最近は複雑なことを始めるときは大抵紙から始めます。
Scrapboxとかに表を書くこともありますが、どちらにせよ見るではなく新しく作るのがいい気がします。
まとめ
今までライブラリとかを覗くことが多かったので、「今回も大丈夫だろう」という謎の自信があったのですが、実際業務レベルで理解するとなると戸惑うところが大きかったです。
これまではベストプラクティスの勉強が多かったのですが、そこにドメインが絡んできたり、デザイン回りの話が絡んだりで必要な見方が違ったんだろうなと思います。
その中で問題を整理しながら、理解のための手順を踏めたのはいい経験になりました。
あとから、Vue.jsのDevtoolsを使えば、もっと早かったのでは思いましたが、紙に書くのが少し楽になるぐらいの感じでしょうね。
新しくライブラリを見るときあたりに、こういう視点で見れたらまた知見がありそうなので、それもやってみたいです。
ポートフォリオ作りました
成果物
公開ページ（GitHub Pages） dexia2.github.io
ソース github.com
製作期間
構想：1週間
基本的な実装：5日
動機
エンジニアなのにも関わらずあまりOSS活動をしておらず、簡単な技術を証明する何かが必要だろうと思い立って作りました。
デザイン
デザイナーではなくプログラマーなので、なんとなく機械的というか2次元的な感触のデザインのほうがイメージに合うかなと思って、そうしました。
また、最初にレスポンシブ対応もすると決めました。ポートフォリオにたどり着く方の多くはPCでアクセスするような気もしましたが、技術力の一つとしてスマホ用のデザインが要求されることも多いので対応することにしました。
内容は業務経歴書などを参考にしました。
使った技術
- Angular6
- TypeScript
- Scss
- Angular Material
- Chart.js
- reset.css
大体、業務で使っている技術スタックそのままです。
デプロイ先
凝ったものではないので、GitHub Pagesを使わせてもらいました。
感想
AngularとAngular Materialが便利
静的Webサイトを作ったのは初めてなのですが、Angularから始めるととても楽でいいです。
TypeScript、Sassあたりのビルド設定、自動更新のサーバーを勝手に用意してくれますし、CSSもカプセル化されています。
それを自前でやることで技術力を見せるべきでは？と言われるとその通りなのですが、主題に早く入れるのはありがたかったです。
Angular Materialのパーツはレスポンシブデザインに対応していて、そのまま使えました。デザインは一部書き換えましたが、その方法もシンプルなのですごく楽させてもらいました。
技術的に遊べる
CSSはFlexbox、CSS Grid Layout 、アニメーションあたりを使って、すごく楽しんでいました。業務ではライブラリに投げている部分も多く、自前で組む楽しさがありました。
あとは色々な方のWebサイトを開発者ツールで覗きながら開発していたので、勉強になりました。
最近は常時、開発者ツールを開いて文書構造とCSSを当てるゲームをしていますが、結構楽しいです。
プログラマーの技量はあまり示せなかった
TypeScriptでガリガリ書く部分がそうそうなかったので、マークアップを頑張ったぐらいしか伝わらないなぁと感じました。
最近はCSSでできることが多くて、スクリプトで頑張らなくても大体のことはできました。
WebGLとかで表現を入れようかと思いましたが、自分のPCだとカクカクするので、あまり情報を見るためのサイトに使うのもどうかなという気持ちがあります。
今後
コンポーネント化の構想だったり、アクセシビリティだとかを含めてもう何回か見直すだろうと思います。
ただ、今回は無難に作りすぎたきらいがあるので、もっと遊んだものを作りたい気持ちがあります。最初は中国風のデザインを目指して、太極図や陰陽五行、八卦のアニメーションなどを作ったりしていましたが、レスポンシブ対応が辛くて諦めていました。
今回とりあえずの成果物を作れたので、趣味のほうも試せる環境にあります。なので、今後はちょっと遊びモードに入れたらなぁと思います。
まとめ
CSSやデザインの勉強がしたい人の題材として、ポートフォリオづくりはいいと思います。
早急にポートフォリオを作る必要がある人はAngularとAngular Materialを使うと、サクッとできて楽です。
最近取り組んできたこと（2018年4月～8月）
Web周り
表現方法の工夫
アニメーションへの興味がなぜか沸々とわいてきていたので、そこらへんを追求していました。
SVG
仮想DOMとSVGを組み合わせれば、独創的なUIがサクサク作れるとどこかで聞いたので、Angularであみだくじを作ってみました。
コンポーネント化したりとか、定数の外出しをしたほうがいいんでしょうけど、技術的な実験だったので1ファイル簡潔でさらさら書きました。
最初はdivと罫線で頑張っていたのですが、線に触れた時のイベントまわりが複雑になりそうだったので、SVGに転換しました。
line要素とか、直感的にマークアップを書けるのでよかったです。x軸、y軸の計算ロジックは増えたので、そこらへんは多少面倒でしたが。
CSSアニメーション
ローカルで色々と試していました。あんまり実例は残っていないですが、キーフレームあたりもちゃんと理解したので、ローディングとかは自前で書けそうなレベルです。
キーフレームとSVGを組み合わせてというのとか、あとはCSSの変数を使ってローディングの%表示をするというのが面白かった記憶があります。
3D
本を読んで勉強したり、APIのリファレンス、リポジトリを延々と眺めていました。
ただ、三角関数や頂点の計算などが合って、かなり数学的なにおいがして、手を出せていません。WebGLは直で触っても行けそうな感じはしましたが、three.jsとかのほうが情報量が多そうで悩み中です。
CSSでも簡単なものならできるらしいですね。
Chrome 拡張
Slackと連携したり、Amazonへのリンクを飛ばしたり簡単なものを実装しました。
地味に便利なことができそうと思いつつ、それ以降は触っていません。でも、簡単な割には可能性を感じました。
言語の勉強
Clojure
core系のAPIと実装を追うところまではやっていました。core.matchの実装が拡張ポイントを押さえていて気持ちいいなぁとか思っていました。
core.async、core.logicは使い方だけ抑えたところで終了。
APIとか実装を調査して記事を書こうと思ったのですが、思いのほか皆さん色々紹介してくれていたり、APIリファレンスが詳しかったりしたので、途中で挫折しました。
とりあえずClojureで書ける大まかな手法は理解できたんじゃないかと思って、ちょっと最近は別居中というかそんな感じです。
いろいろな言語に手を出す
なぜかいろいろな言語への興味がわいてきたので、手あたり次第に言語の勉強をしています。
どの言語も一度は勉強していたのですが、疎遠になっていました。Clojureを理解したあたりで、もう一度勉強し直してみるとなぜかすいすい頭に入ってしまって、はまってしまいました。
Pythonも以前見た時は普通じゃないか？と思っていたのですけど、今見ると色々そろっていてまぁ使いやすいよなぁと思ったり。
とはいえ、Clojureをまじめに触った時に本当に言語を学ぶときは集中して時間を書けるしかないと学んだので、どこかで絞るだろうと思います。
最近の流れだとPythonとGoですかね。言語的にはRustとScalaが好きですが、いかんせんそういう用途で書かないので。
ちなみに、自分は１冊の技術書を１日20ページ以上読めないので、分散しています。こういう読み方が単に好きなんですね。
勉強方法としては
あたりですかね。技術書を読んだ後、具体的なリポジトリを探してにらめっこが一番多いパターンな気がします。
今後
諸事情で趣味よりは技術的にやっていないところを補うことになると思います。
- GraphQL
- React/Redux
- WebSocket
- WebWorker
ここらへんと趣味のバランスが難しいですが、どこかでまとめてやらないとつらそうですね。
言語の勉強が楽しすぎて実用性より構文を眺めてしまうので、ちょっとそっちは休憩しないとかもです。
Clojureを歩いている
前書き
昨年9月ごろからLispを勉強しています。
最初はCommon Lisp、途中からEmacs Lispを経たりして、今はClojureを勉強している感じです。
以前は「リーダマクロがない？、引数はベクターで受け取る？ そんなの邪道だ」と思ってCommon Lispを中心に考えていましたが、今はClojureの設計はとてもきれいだと思って、その考えをとりあえずできる限り盗もうと思って頑張っています。
Clojureのimmutabilityあたりにちょっと詰まりましたが、それさえ乗り越えれば、Clojureはとてもシンプルで使いやすい言語だと思います。
逆に言うとClojureはなんとなく使いやすい言語で、なんとなく書けるのでその先に行くには意識的な努力がいるんじゃないかなというのが今の感想です。
だから、最初はとりあえずなんとなく書きたいものを書いて、読みたいものを読むというスタンスでしたが、計画的に努力するように心がけているところです。
勉強のメディア
本
プログラミングClojure
最初は本を読んで勉強していました。
「プログラミングClojure」は日本語の中では一番まとまっていてよかったです。改めてみるとつまみ食い感がすごい気もしますが、大事な情報がきちんと入っていて3回くらい読み直しました。
今ならちょっと古いのかもしれませんが、選択肢があまりないので導入なら問題ないかなと思います。
プログラミングClojure 第2版
posted with amazlet at 18.04.21
Clojureによる、初めての関数型プログラミング
基礎を固めた後としてはこれがよかったです。とてもシンプルな設計でどうやってアプリを作っていくかを学べてよかったです。
全体としてみてどうかといわれると難しいですが、細かいテクニックとかはこれで覚えた気がします。
Clojureによる、初めての関数型プログラミング
posted with amazlet at 18.04.21
gpsoft (2013-09-28)
売り上げランキング: 64,595
売り上げランキング: 64,595
Clojure Programming
ちょっと学んだらあとは英語で頑張れというのがClojureですが、洋書のなかで1番好きなのはこの本でしょうか。
一つ一つの概念について丁寧にページを割いて説明してくれていて、構文への愛があります。多少古いので最先端ではないのかもですが、Clojureを学ぶという意味ではとても好きです。
洋書であればWeb、機械学習に絞ったものなど色々ありますが、自分はきちんと基礎から学びたいタイプなのでそういう系はあんまり肌に合っていない感じはします。
関数型、リアクティブプログラミングの設計あたりは次あたりに読んでみようかなぁと思っています。
Clojure Programming
posted with amazlet at 18.04.21
Chas Emerick Brian Carper Christophe Grand
Oreilly & Associates Inc
売り上げランキング: 69,016
Oreilly & Associates Inc
売り上げランキング: 69,016
Web
Git Hub
最初はClojureのTrendのリポジトリを眺めていました。
Trending Clojure repositories on GitHub today · GitHub
でも、ClojureのTrendは毎日ほぼ変わらないですし、上がってくるのはほぼデータ系でこれだけに頼るのは厳しいですね。感覚的にはRubyとかJavaScriptあたりだと変動が大きくて面白かったんですけどね。
勉強が目的なら、Clojureの公式のリポジトリをめぐるほうが楽しいと思います。
その先の調べ方はあんまり考えていないので、今発掘中です。
Clojure Docs
Clojure Docsを眺めるのも勉強になってよかったです。APIにどんなものがあるか眺めるのも楽しいですし、サンプルを自分なりに作り直してREPLで叩くのも楽しいです。
Community-Powered Clojure Documentation and Examples | ClojureDocs
Clojureは細かい関数、マクロが多いので時々API一覧を見て不要な処理を本当に書いていないのかを確かめるのがいいと思っています。
その他
Qiitaとか、ブログとかはちょいちょいありますが、あまり更新されていないので主要な情報源にはならないかなぁという印象はあります。
Clojure界隈にはとても優しい方々がおられるので、そういう人たちと仲良くしながら情報がないかアンテナを張っておくほうが大事かなぁと思います。
おすすめされた情報源
一応自分なりの勉強方法はあったものの百戦錬磨のClojurianたちはどうやって勉強されているのか聞いてみました。
情報収集の場合、redditとMLくらい眺めておくと、とりあえず最新の情報は自動的に入ってくるかなーという感じです(どう取捨選択するかはさておき)。
— あやぴー (@_ayato_p) 2018年4月18日
あとはathosさん、t_yanoさん、カマイルカさんあたりのTwitterを把握しておけば、だいたい重要そうなものはちらほら流れてくる印象です。
reddit https://t.co/hlbqpmMZ4J
— あやぴー (@_ayato_p) 2018年4月18日
ML https://t.co/gXRKdqaJCP
MLはメーリングリストで通じると思ってました…そういえば、最近はマシンラーニングですよね…。
RSSリーダーを確認してみたら、私はClojure/Lisp関連ではこのあたりを購読してました。https://t.co/QhmDh0Vw8Xhttps://t.co/5XoZTllpPghttps://t.co/6y82NxT6sshttps://t.co/9a5ZltKZ7Ahttps://t.co/bY5Q64BHGp
— lagénorhynque🐬カマイルカ (@lagenorhynque) 2018年4月18日
Clojure の情報ということでもないのですが、 Clojurian の発表を文字に起こしている方がいます。こういうのも面白いかもしれません https://t.co/UAn085FANr
— Yoshito Komatsu (@ykomatsu0) 2018年4月18日
redditとMLは確かに毎日眺めるにはちょうどいい感じでした。
Podcastなどはいくつか聞いてみて、意外に英語でもプログラミング系ならわかりました。ただ、通勤しないので、聞くタイミングがなかなか作れないのでもう少し考えたいです。
transcriptsはかみ砕きながらみないと難しいですが、研究材料としてはこれ以上なく楽しそうでした。
勉強の方法
REPL it
やはり書くことが一番の勉強だと思っていて、本でもWebでも面白いものを見つけたらREPLに打ち込んで改変してテストするのが一番よかったです。
マクロあたりもずーっと読んでいるだけではわからなかったものの、色んなパターンをうちこんでもう最近は間違えないですね。
テーマをもってやる
前にも書いたのですが、Clojureは自分の思うように書きやすすぎるので特定の構文を使わなくても意外に何とかなります。自分だと、
- マクロ
- メタ情報
- 表明
- オブジェクト指向的なもの
とかは別に自分で書かなくても何とかなるというところがあって、やっぱり時間をとって研究しないといけないなという風に思っています。
そのためには何かアウトプットを書くといいのかなと思って、Qiitaとかにあげたりしています。正直、Clojurianの方々から見るとミスリーディングなどが多くて恐れ多い部分もありますが、それを自分だけで認識できないので開き直ってアップするという感じです。
今のところこんな感じです。
Clojure公式リポジトリの構文上の比較研究が多いですが、いずれはライブラリ、プロジェクトあたりの研究をして、それが終われば自分なりの形を作れればいいかなと考えています。
Clojurianへの道は遠いですが、自分は少しずつ進むほうが性に合ってそうなので、地道にやっていきます。
まとめ
ClojureはC#とかJavaScriptに比べて日本語の情報量が少ないので、より情報を得る手段が洗練されてきている気がします。
実務はLispではないので、きっちりこのやり方をそちらにもフィードバックしていけたらエンジニアとしてのランクがちょいと上がるかなぁとか考えます。
最近は実用物はあんまり考えていませんが、Lispの長い歴史を追いながらエンジニアはどういう風にしてきてこれからどうなっていくのだろうかというところにも興味があり、どうしようかは迷っています。
ただ、今とても楽しいのでもう少しだけ、研究という体で学んでいきたいです。やり方がガラッと変わったら、また何か書きます。
最近取り組んできたことの振り返り（2017年末～2018年3月）
動機
思い返すと、2017年末くらいから色々とコードを書くようになって、それなりに形にできたのでその振り返りをしたいなと思います
やってきたこと
配球ゲーム
バドミントンの配球を２次元に落とし込んで読み込んでみようという試みで書いたシミュレーションです。製作期間は２か月足らずくらいでしょうか。
細かいところは大体Qiitaに最近は書いているので、技術的なところはそこを見てもらえれば。
ClojureScriptで配球予測ゲームを書いてます - Qiita
感覚的なところで言うと、これが一番収穫だったかなぁという印象です。
Lisp系の言語を使ってそれなりに知見を貯められたとかそういうところもありますが、自分の思考とプログラムを近づけるということが一番自信を持ってできたというところで価値があります。
表現が伝わるか難しいですが、ライフハックそのものではなく思考を拡張することこそがシステムの価値じゃないかという思いがあって、 そこに踏み込めた第一作としてはとてもよかったです。
統計ごっこ
バドミントンのいいデータセットが見つからなかったので、とりあえず人力でJSONを書いてそれで分析していました。
１試合どころか１ゲームで６時間かかったので、途中でまじめにやるのは無理だとわかりました。
分析結果は一応他のブログに書きました。
簡単な分析であってもそれなりの知見が得られることはわかって、その点では満足でした。
ただ、複雑な分析をする手段をもっていないので、そこが足りないのかなと思いました。ストローク同士の関連を見たり、複雑な相関を見る道具がそろっていないのは実感しました。
Rとかを触ればいいのかなぁとか色々模索はしていますが、結論は出ていないです。
また、データセットをとるためには、たぶんYoutubeAPIとOpenCVを組み合わせたりして自分でやるしかない気がしていますが、そこまでの価値があるのかちょっとわからないので、保留中です。
指示出し器
何も考えずに買ったAmazon Echoを買いました。
練習の指示を出したら楽しいんじゃないかと思って、指示を出してくれるスキルを作りました。
でも、Alexaは対話型なので、一方的に話しかけてほしい自分の願いはかなわなさそうだったり、そもそも音声に反応する練習を積んでも意味がないのではと思い作って終わりです。
ついでに作ったメモ用のスキルのほうが役になっています。
GitHub - dexia2/MemoSkill: Slackにメモを保存するスキル
Alexaを使ってSlackにメモを保存する - Qiita
練習メニュー管理、量の記録あたりなら役に立つかもですが、ちょっと考え中です。練習テーマあたりを言ってくれたらうれしいかなぁ。
可能性は感じましたが、まだ積極的には生かせていないです。
書籍管理
Google Apps Scriptで書籍を管理する - Qiita
珍しく実用品を作りました。
とはいえ、似たようなサービスはもうあるらしいので、技術の実験的なところですね。Google App Scriptは便利で自分のような個人用作品を使うにはまぁそれなりに使えそうでした。
やる気がないところをやる気がないなりに成果を出すというところでは最高です。
振り返ってみて
やはり一番よかったのはProcessingで遊んだ配球ゲームですね。
機械学習や統計、画像処理をやることで他の人に貢献できるんじゃないかという気持ちはあるのですが、自分の感覚とどれくらい一致するか？というところを考えるとビジュアライゼーションの優先度が高いかなぁという気がしています。
あるいは練習管理が結構大事で、練習のテーマ管理、テスト管理、あとはモチベーション管理あたりが課題になっていて、そこらへんの心理的側面をどれだけシステムで行けるかなぁというのが今の気持ちです。
いろんな技術をまたげるようになってきた感じはしますが、まだ本質に近いものを量産できていないので、そこにまた近づけたらいいなと思います。
それはさておき、Git HubとQiitaはエンジニアのInstagramとは言いえて妙ですね。本当にそんな感じです。
Emacsを使い始めての感想
前書き
１か月ほど前から本格的にEmacsを使い始めました。
何か１つくらいエディターを極めたいなぁという願望はずっと持っていて、ちょいちょいVimを触ったりはしていました。
しかし、Pythonを入れないと解決しない問題に遭遇した際に、もともとVim scriptを好きになれなかったのもあって、手放してしまいました。特にバージョン絡みの問題だったので、さすがにそこまで環境を汚すのはあんまり。。という気持ちでした。
加えて、Lisp系の言語で遊びたいという従来の目的をするにしてもVImはあんまり有効でないこともあったので、それならEmacsのほうがいいだろうと考えて乗り換えました。
いざとなれば、Spacemacsに乗り換えればいいという保険もあったので、気軽な気持ちで使い始めました。
やったこと
VsCodeにEmacsのキーマップを入れる
業務ではTypeScript＋Angularを使っていたので、エディターは相性のいいVSCodeを使っていました。
いきなりEmacsに移るのは難しかったので、キーマップをEmacsにしてキーバインドを覚える練習をしました。
Emacs Friendly Keymap - Visual Studio Marketplace
最初はMキーとCキーの使い分けがまったくできず、移動にC-fとか二つのキーを使うのは逆に面倒じゃないかと思いながら、ひたすら耐えていました。
１週間くらいで基本操作ができるようになり、２、３週間でC-a、C-k、C-yという連続技が使えるようになり、やっと楽しいと思える瞬間がたまに来ました。
そのころにはEmacsの環境が大体できたので、Emacsに乗り換えました。
本を買って勉強
いろいろEmacsの本を買いあさって、どんな風にするのがよいのかという情報を集めていました。
特によかったものを選べといわれると、普通ではありますが、下の２冊でしょうか。
Emacsテクニックバイブル ～作業効率をカイゼンする200の技～
posted with amazlet at 18.02.10
入門 GNU Emacs 第3版
posted with amazlet at 18.02.10
ただ、どちらも悪くはないにせよ、Vimで言うところの「実践Vim」みたいな「これさえ読んでおけば大丈夫！」というものはない印象ですね。
結局、Webの断片の情報をかき集めながら進んでいくというスタイルをとらざるを得ず、入り口があるようでない感じがしました。
入門者にとってはあんまり優しい環境とは言えないかもしれないですね。
カスタマイズを始めた
いろいろやったので、あんまりまとめて書くのは難しいですが、
- デフォルトの変数をいじくった
- 行数表示とかハイライトとかテーマとか
- キーバインドの変更
- 特に削除系のキーバインドとバッファー操作系を変えました
- あとは C-c k とC-c C-kとかを間違えやすいやつを書き替えました
- プラグイン導入
- 大体el-getで入れました
- これはたいそう便利でした
- 大体el-getで入れました
- diredとかorg-modeとか既存機能で遊ぶ
カスタマイズの楽さにはびっくりしました。新しいコマンドの定義とか、キーバインドの変更、プライグイン導入どれもパパっとできたので、思いついたらいじくれるのは最高です。
評価
欠点
キーバインドが使いにくい
前にも書きましたが、キーバインドになれるのはなかなかつらいものがあります。
そういうものだと割り切ればいいのですが、Vimに慣れているとちょっと不合理じゃないかというキーバインドがデフォルトで多すぎます。
割り当てられている関数も微妙に使いづらいものが多い（特にカット関係）印象がありました。
Emacs Lispが絶妙に使いづらい
正規表現のエスケープとか、ダイナミックスコープがデフォルトであることとか、基本のAPIが地味に貧弱であるとか書いていて、時たまいらいらすることがありました。
Common LispとかClojureとかに慣れていると、感覚がずれてしまうこともあり、結構はまりやすいですね。Lisp一族といえど違いはそれなりに感じました。
静的言語だとIDEにできて、Emacsにできないことが多い
そんなに静的言語を触ったわけではないのですが、C#とTypeScriptに関していうとリファクタリング、ビルド、あるいは補完という面で他のエディタと同等に持っていくのはつらいかなという感じがしました。
それにここらへんはIDEを使う人が多いため、情報もそんなにないという点で苦労しています。
Clojureとかの動的な言語で書いているとそこまで気になるレベルではないですかね。
長所
カスタマイズが容易
気に入らなければ変えてしまえばいいという思想なので、短所で書いたキーバインド・Emacs Lispの問題は自力で解決できます。
それがいいか悪いかという話はありますが、気になった瞬間手を動かして試せるのは個人的には面白いと感じます。
情報量が多い
他のエディタよりも歴史があるので、自分が苦痛に感じることは大抵解決済みです。そういう意味、いろんな知識を使いやすく、やはりハックする余地がとても広いような印象を受けました。
総評
正直に言うとハックが好きな人でなければ、そこまでメリットは大きくないという印象を受けました。
ロードマップがあるわけでもないですし、最近のIntelliJ IDEAを超える機能性を提供できるかというと、かなり頑張らないと厳しいでしょう。
ただ、プログラム言語が好きな人やエディタ自体を愛する人にとっては遊び道具としてはとても優れていると思います。
気が向いたらscratchを開いてアイデアを試したり、他の人のEmacs Lispを読んで遊んだりできます。何より、気になれば直せばいい自由は何よりもありがたいと思います。
自分はもっと深く、深くエディタ自体に没入して遊びたいので、しばらくはEmacsで行こうかなと考えています。Spacemacsはもう少し素のEmacsで遊んでから試してみるかもしれないです。
