カラクリスタ

「輝かしい青春」なんて失かった人のブログ

最近の僕の技術スタック

なんかヒマなので書く。


まあ、 技術スタック 、と言うワリには、大したコトも無い話しなんだけど、最近、僕はこういう言語を使って個人的な開発してますよって話です。

1. 主な開発言語: [Golang , ES2015 ]

最近……というよりかは、大分前からそうなんだけど、ここの所、僕がメインで使っている言語は、

という感じ。

まあぶっちゃけコレ以外には、 HTML5 とか CSS も書くときは書くんだけども、それ以外の言語はほぼ触ってない。つまり、延々と Golang と ES2015 (Babel) しか書いてない。

で、何かモノを作る言語選択として、

で、不自由するコトは何も無いんだけど、いかんせんこればっかり書いてるので、いい加減、ちょっと飽きが来ている感じが有る。そのため、メインの作りたいモノを完成させるモチベーションというか、モノを完成させるための熱意がちょっと不足気味。

まーこの辺り、僕が今うつ病を患っている関係も有るのか無いのかは判らないんだけど、完全に最近家にから外に出てないので、その辺りも関係していそう。あと、冬場なんで、調子が今一つ、というのも有りそうだけど。

ちなみに。

Golang から ES2015 (Babel + React) を Server side rendering する際の Javascript 実行エンジンには、

Duktape

を使っていて、実際使っている Binding Library としては、

olebedev/go-duktape

を使ってます。

ただ、 Duktape って結構独特というか、Binding API が思っ切り スタックマシン で、生の API を触るのは結構つらぽよ……という感じなので、ほぼ自分用っぽい便利ライブラリである、

https://github.com/nyarla/librenderernyarla/librenderer

の中で、簡単なラッピングして使ってます。

あと、実際の Server side rendering するための Javascript source code を吐くためには、

辺りを使っていて、 gulp とか grunt を使わずに、

npm-run-all

package.jsonscripts セクションを駆使して npm run build 一発でコンパイル出来るようにした上で、さらにそれを Makefile を使って make のタスクとして呼び出せるようにして有ったりもします。

それで、僕が gulp とか Grunt を使わないのは、特に深い理由とか有るわけでもなく、単にその辺りのツールが僕の性分に合わない、っていうだけなんですが、Server side rendering で使う Javascript source code を browserify とかで生成しているのには理由が一応有り、それはまあ実行エンジンに Duktape を使っている関係で、という感じです。

というのも、今時の Javascript library って大体は node.js とブラウザをメインの実行環境として見据えているモノが多く、単純なスクリプトとかならまだ良いんですが、いかんせん node.js のモジュールに依存したコードとかは Duktape 処理系では動かない (というか該当モジュールが Duktape 実行環境では実装されてない) とか、すごく良く有るんで、そういう理由で Browserify + Babelify + Envify という、 node.js を前提としていたらそんな苦労はしなくとも良いのに…… という感じの組合せを駆使して実行用 Javascript を吐いてたりしますね。

この辺り、もうちょっとスマートというかスッキリとした解法が有るのかもしれませんが、いかんせん僕は Javascript Ecosystem にそんなに熟知しているワケではないので、今の所はこういう感じでやってます。はい。

というコトで次。

2. 主な開発環境: iTerm2 + tmux, MacVim

なんかここまで辿り付くのに 2000 字越えてるのがちょっと意味不明ですが、まあサクサクっと次に行きます。

で、僕は今現在 (2015 年 11 月現在) 、基本的にコード書く際には、

という環境で書いてます。というか、気がついたら、何時の間にやら、コンソールの黒い画面に籠っていたという。アレ?

で、 MacVim とか tmux の設定は一応ごにょごにょとはしているんですが、まあその辺り、結構適当というか、設定してあっても使ってない or 使いこなせてない設定とかそれなりに有るし、また MacVim を使っている、とは言っても、基本的なキーバインドぐらいしか使ってません。というか、ぶっちゃけ全機能を使いこなせるほど、 vim は極めてないっていう。

ただ、それでも言語サポート系の Vim Plugin は使っているし、また、それ以外の UI 系の Vimプラグインでは、

scrooloose/nerdtree

を良く使ってます。

ただ、 NERDTree なり tmux の操作なりは、基本的にマウスを使うことが多いので、基本的には GUI チックにしか Console 系を使えない軟弱系です。間違っても硬派ではない。

あと、 tmux 2.1 は色々パッチを当てたヤツを使うために、

http://the.nyarla.net/entry/2015/10/27/114924Homebrew formula for tmux 2.1 with waltarix's patches を作った - カラクリサイクル

という記事で貼り付けた Homebrew formula 経由でコンパイルしたヤツを使ってます。それと、僕の場合、コンソールで日本語を打つことはほぼ皆無で、日本語を打ち込むのはほぼ Vim 上だけなので、 その際には、

tyru/eskk.vim

とか重用しています。

が、基本的には、コンソールの Vim で日本語の長文を書く機会は今のところ遭遇していないので、果して今このブログのエントリを書いている時みたいに、スムーズに日本語長文を Vim 上で書けるのか、という点についてはまだ未知数です。はい。

で、最後。

3. 主なデプロイ先: Google App Engine (Managed VM)

まあ、主なデプロイ先……というか、実際のデプロイとかはまだそこまで開発が進んでない、というか辿り付いてないので、 単なるデプロイをする予定の想定環境にしかなってないんですが、基本的には、

App Engine — Google Cloud Platform

の Managed VM を想定して開発しています。

で、何故 AppEngine の Managed VM を想定しているか、っていうと、理由としては、

  1. インフラを維持して云々……っていう技量が、ぶっちゃけると自分には (今のところ) 無い
  2. コストが安い (というか無職に AWS とか GCE でクラスタリングとかは辛い)
  3. Managed VM は Dockerfile を使えるので、自由度がそこそこには高い

という感じでしょうか。

まあ、本心を言うと、マネーというかキャッシュがそれなりに有って、また、インフラに対するエンジニアリング能力が有るのであれば、多分、自分でまるっと色々インフラ構築するのもアリかな、なんて思いますが、実際の現実の僕には、インフラ周りを安定運用する技量なんてないし、ましてや、インフラを維持するためのコストも 無職 には結構つらぽよ……と言う感じなので、その辺り、 ぶっちゃけ手抜きするためAppEngine の Managed VM を想定環境として開発している、っていうのが有ります。

ただまあ、それでも一応は AppEngine ベッタリなコードはあまり書かないよう気を使うことは使っていて、まあ、大体のところでは、

  1. AppEngine の API を呼ぶ箇所は、Golang の interface 型で抽象化する
  2. API の抽象化を行なうパッケージと、 API の実際の中身を実装するパッケージは名前空間を分ける
  3. AppEngine 依存なコードは、 AppEngine 用の名前空間を使う (例えばリポジトリ内の gaego パッケージに全部切り出すとか)

という様な感じのコトを行なっています。

まあ、 API は特定の環境に対して非依存にしておいて、実際の処理は、それに依存するパッケージに切り出しておく、っていう手法は、AppEngine に限らず、例えば一つの Web Application で複数の RDBMS をサポートするとか、そういうケースでも使えると思いますが、この手法にも一長一短が有って、あまりに性質が違いすぎるモノ同士を抽象化して一緒くたに使えるようにすると、却って効率やらコードの再利用性が落ちるとかそういう面も有る、と僕は思うので、あんまり多用するのもどうかなーとは個人的には思ってます。

なんというか、抽象化が必要な度合いは、それぞれの Web Application 毎に違うとは思いますが、僕の経験上で言えるコトは、 細かいクエリレベルとかで抽象化するのではなくて、ある程度のまとまり、例えば、

  • データベースやデータストアからアカウント情報を引っ張ってくる、とか
  • ソーシャルアカウントでのログインを抽象化して一緒くたにできるようにする、とか

と言ったような、そういう感じのレベルでの抽象化を行なうと良いんじゃないか、と僕は思います。

ただまあこの辺り、ぶっちゃけ僕のレベルは高が知れてるんで、もうちょっと実務に関わったコトのあるゴイスーなエンジニアな方々に聴くとか、あるいは、先人の叡智をまとめたデザインパターンの書籍とか読んだ方が良いのでは、と思います。まあ、投げ斧とイスとか飛んできてもアレデスシオスシ。

というコトで以上です

なんか凄い気の抜けた感じで書いてきたんですが、この文章の時点で 4800 字前後になってるってどういうコトよ。自分でもこんなにヒマな人間だなんて思わなんだわ。まあ途中で夕食は挟んでるけど。あと、前半の言語周りの話が長くなっている影響で、なんか文章量のバランスが微妙にアンバランスになってるのが個人的にはびみょい。

で、まあ長々と書いてきましたが、まあ最近はそんな感じで開発とかしてます、って話でした。

まあ、もうちょっとで 5000 字超えるぐらいの文章を書いてるのですが、なんというか、自分、本当にヒマなんだなーとか思ってます。いや、何時間も掛けて文章を書ける時間って、それこそ、そう言う文章を書くことを生業としている方々ぐらいしか持てないよなぁ、とか、思わないでもなかったり。

ただまあ、そういう長い時間文章を書き続けることが出来るのって、或る種の能力では有るっちゃあ有るので、誇って良いのかしらん? と思わないでも無いです。まあ、僕の場合はこの能力はブログを 9 年ぐらい続けてきた結果ですが。なんていうか、 好きこそモノの上手なれ 、とかそういう感じです。はい。


まー良い加減ダラダラ書いててもキリが無いので、もうそろそろこの辺りで切り上げますが、大体、今日なんとなく書こうと思ったコトは以上です。なんか文章が量だけハンパない感じですけども。

というワケで以上で今回のエントリは以上です。終わります。はい。