読者です 読者をやめる 読者になる 読者になる

Wondershake 開発者ブログ

Locari(ロカリ)の運営会社の開発者ブログです。

LOCARI のコードレビューについて

この記事は Wondershake Advent Calendar 2016 22日目の記事です

Wondershake では基本的にほぼすべてのアプリでコードレビューが導入されています。(一部ソロ開発のものはレビューがない)

自分は基本的に LOCARI (のサーバーサイド)を開発してるので、それのワークフロー及びコードレビューで自分なりに気をつけていることを書きます

LOCARI のワークフロー

PivotalTracker, Github を使ってます 😄 (その他諸々ツールを使ってますが、基本的に見てるのはこの2つのみです)

  1. PivotalTracker に issue 起票
  2. 勝手に issue を取っていったり、アサインされたりする
  3. issue に紐づく pull request (以下 p-r)を WIP: で作成
  4. WIP: が取れたらレビュー担当によるレビュー
    • コードレビューと動作レビューがある
    • 機能追加の場合は後者必須
  5. すべてのレビューが通れば、 p-r 作成者がマージ

PivotalTracker への起票をスキップしていきなり p-r 出すこともあります(主に自分)

地味に [WIP] ではなく WIP: としてあるのは嬉しさがあります。タイプ数が1文字分減ります。(どうでもいい)

コードレビューで自分が気をつけていること

ここからは自分語りです。イタい

70 ~ 80 %で approve 出す

物議を醸しそうですが、自分が 100 % だと思うものを求めてしまうと(おそらく)どっちでもいいことが混在したり、レビューで説明しきれない可能性があったりするので...

「本当はこう実装した方が」みたいな時は「自分であとで p-r 出せばいい」と思うので、実際にそうしてます

その機能開発が本当に正しいかどうかはユーザーに触ってもらって初めて評価できると思うので、なるべくリリース優先になるようにしています。

が、本来は100%でいけるに越したことないので難しいなぁと日々感じています 😇💔

WIP 段階でもなるべくチェック

「WIP だから!まだ見んといて!」となる方もいるかもしれませんが、お互いに余計な時間を使うのを避けるために、方向性に疑問を持ったりしたらコメントを残すようにしてます。

Review changesRequest changes は使わず、 Comment / Approve を使う

Github 限定の話です

機能としてはとてもいいんですが、思いっきり ❌ って出ちゃうのが心理的にアレで自分は避けてしまいます(すごいどうでもいい)

最近導入された Reviewers 機能 で右上に status が出るので別に Comment でもいいかなという気がしてます

最優先タスクをコードレビューにする

コードレビュー自体の話になってしまいますが、自分が以前働いていたところでそういう風に仕事してる方がいてかなり開発がしやすかったので、それをリスペクトして自分も真似してやってます

自分の開発は基本的に後回しにして、 p-r が作成されたらまず目を通します 😎🔎

他人の作業を止めるのが一番害だと思うし、出来てすぐのコードをチェックしてもらった方がモチベーション的にも良さそうなので。(自分は昨日書いたコードとか覚えてないので余計にきつい)

おわり

当たり前のことばかり書きましたが、以上になります。

明日は Go エンジニアの greg です。趣味でちょこちょこ Go を勉強しているので個人的に楽しみです 😍

Elixir / IEx の便利なコマンド

この記事は Wondershake Advent Calendar 2016 21日目の記事です。

僕もまだまだ Elixir のことを勉強中ですが、今回は僕が気に入ってる便利なコマンドお伝えしたいと思います!

IExで hを使う

基本的なコマンドかもしれませんがすごく便利だです。普通に iexh のコマンド使うとElixirのstandard libraryのドキュメンテーションしか見れませんが、 iex -S mix から h のコマンド使えばプロジェクトをロードしているモジュールのドキュメンテーションを全部見れます。僕はphoenixのプロジェクトでよく h Ecto.Queryを見ます。

h(Module)

f:id:dykstra:20161221141932p:plain

h(Module.function)

f:id:dykstra:20161221141945p:plain

h(Module.function/arity)

f:id:dykstra:20161221142038p:plain

IExで iを使う

もともとはRubyを書いているので、最初はRuby .inspect.class を使えないので不便だと思っていましたがElixirのイントロスペクションはかなり良いです。

f:id:dykstra:20161221142057p:plain

f:id:dykstra:20161221142112p:plain

escriptでコマンドラインアプリケーションを簡単に作れる

1) 新しいプロジェクトを作る mix new cli_example

2) mix.exs で...

def project do
  [app: :cli_example,
   version: "0.1.0",
   elixir: "~> 1.3",
   build_embedded: Mix.env == :prod,
   start_permanent: Mix.env == :prod,
   escript: [main_module: CliExample], # <- これを入れるだけ
   deps: deps()]
end

3) lib/cli_example.exsCliExample のモジュールで main functionを作る

defmodule CliExample do
  def main(args) do
    args |> IO.inspect
  end
end

4) mix escript.buildコンパイルする

5) ./cli_example [args] で使える!

f:id:dykstra:20161221142122p:plain

まとめ

この記事でElixirの使いやすさ少しでもお伝えできていたら嬉しいです。

明日はまた @masa-myo です!楽しみです!

Rails のマイナーなコマンド

この記事は Wondershake Advent Calendar 2016 20日目の記事です。

ほんとは Elixir とかについて書きたかったんですが特にインプットがなかったため、しょーもないことを書きます。

tl;dr

The Rails Command Line — Ruby on Rails Guides に書いてることのうち、(個人的に)マイナー(そう)なやつについて書きます。

詳しくはリンク先を見てください

前提

5系以上はそれまで bin/rake だったコマンドもすべて bin/rails なので bin/rails として以下書いていきます

notes

bin/rails notes で FIXME, OPTIMIZE, TODO が付いているファイルをメッセージと一緒に表示してくれる

以下の拡張子に対応

bin/rails notes:fixme で FIXME だけ表示

自分たちしか使ってないカスタムメッセージを表示したい場合は

bin/rails notes:custom ANNOTATION=BUG のようにして、 BUG と書いてあるファイルを探せる

TODO, FIXME あたりはよく(?)使うので使いたい

tmp

bin/rails tmp:cache:clear はよく使うと思いますが、cache とか pid 用の dir を作る tmp:create コマンドは知りませんでした

$ bin/rails tmp:create
mkdir -p tmp/sessions
mkdir -p tmp/sockets
mkdir -p tmp/pids
mkdir -p tmp/cache/assets/development
mkdir -p tmp/cache/assets/test
mkdir -p tmp/cache/assets/production

rails app を clone した後とかによく使うかも(覚えていれば)

time

time zone 一覧を表示するタスク。これほんとに必要?

$ bin/rails time:zones:all
# ...

* UTC +09:00 *
Osaka
Sapporo
Seoul
Tokyo
Yakutsk

* UTC +09:30 *
Adelaide
Darwin

* UTC +10:00 *
Brisbane
# ...

console

bin/rails c(onsole) はよく使うと思いますが、その中で毎回めんどくさいことしてたなーというものがあったのでメモ

$ bin/rails c
# app で代用できる
> Rails.application.routes.url_helpers.root_path
"/"
> app.root_path
"/"

# helper で helper のメソッドを呼べる
> helper.number_to_currency 1_999
"1,999円"

dbconsole

config/database.yml に定義してある mysql server へアクセスできる(console と同じでデフォルトが development)

直接 SQL 叩きたい時とかは便利

おわり

小ネタでした

明日は Eric です!

LOCARIのデザイン環境について

こんにちは、業務委託でお世話になっておりますデザイナーのこけしです。(本名は長谷部えりです) この記事は Wondershake Advent Calendar 2016 の16日目の記事です。

様々な記事が書かれていて賑やかでうれしいですね(^o^)!
前回の板部くんの記事はコチラです。とっても素晴らしい記事でした!! engineering.wondershake.com

話すこと

  • デザイン作業フロー
  • フロー詳細と利用ツール

今回はLOCARIのデザイン環境についてです。

というのも以前よりデザイナーさんも増え、現在属人的な管理にならないよう、デザイン環境整備を意識して行っています。 そこでどのようにWondershakeデザイナーは働いて、その中でどのようなツールを利用して管理を行っているかおおまかにデザイン環境についてお話しようと思います。

デザイン作業フロー

ざっくりと書くとデザイン作業のフローは以下の通りです。
1. ディスカッション
2. 要件定義
3. アサイン
4. デザイン制作
5. クリエイティブチェック
6. エンジニアの共有

前提として、Wondershakeデザイナーの役割としては、デザイナーは要件定義された案件をもくもくとこなすというより開発メンバーと共にディスカッションをして組織として持っている課題をデザインで解決する役割も担当させていただいており、 UIUXデザイン〜広告グラフィックなど、広い領域で上流からデザイン制作を行うことができます。

フロー詳細と利用ツール

ディスカッション〜アサイン

週に1度、エンジニア・デザイナーの開発メンバーでディスカッションを行います。 こちらでデータから見えた課題や様々な窓口から受け取った課題を整理し、 優先度の高いものから各案件ごとに要件定義を行い、タスク化してアサインをしています。 タスクやアサインの管理はFlowを利用しています。

タスク管理ツール
Flow - Project and Task Management Software for Teams f:id:kokeshi2013:20161216154320p:plain 案件ごとに決定したもの、議論したいことも書き込み、ログを追えるようにしています。
タスクとなりきれなかったアイデアなどもストックしておくことで、課題解決のヒントになることも!

デザイン制作〜クリエイティブチェック

デザイン制作では主にUI制作はSketch、グラフィック制作は(言うまでもないですが)Photoshopの2つを使用しています。
UI制作ツール
Sketch - Professional Digital Design for Mac
f:id:kokeshi2013:20161216164226p:plain

グラフィック制作
Adobe Photoshop CC
Adobe XDも話題となっていますが、以前からデザインチームではSketchを導入していたところもあり もう少し様子を見て、導入コストをかけてでも変更すべきと感じたら検討しようとしています。

デザイン完成後はデザイナー上長確認、エンジニア+プロジェクトマネージャー確認を行い実装へ移していきます。

エンジニアへの共有

完成したデザインを共有するツールとしてはZeplinを利用しています。
デザイン指示書ツール
Zeplin

f:id:kokeshi2013:20161216164436p:plain デザインの最新バージョン管理、デザイン指示書、素材書き出しなどをこちらで行います。

今まで作業したデザイナーのみが最新版を確認できる状態で、 デザインチーム内でも「どれが最新?」と混乱が起きがちでしたがこちらで一括管理することで認識違いが起きることが少なくなりました。

さいごに

大まかにLOCARIのデザイン開発フロー・ツール紹介をさせていただきました。
日々すごいスピードで新しいものが増えていっているので、ぜひオススメのフロー・ツール等々情報共有いただけるとうれしいです! いろんなプロダクトのデザイン環境気になります。

お次はDIYレシピアプリのCreon Andoroidについて、たくみゅうみゅうことshirokuraさんが書いてくれます!楽しみです!
余談ですがshirokuraさんとわたしはWondershakeクラフトビール部に所属しています。
好きな方、ぜひ飲みに行きましょう〜!では〜!

色の基礎知識と配色のコツ

この記事は Wondershake Advent Calendar 2016 15日目の記事です。

自分について

学生でデザイナーのアルバイトをしている板部良平です。これまでにはイラストレーション、グラフィックスデザイン、映像をやっていて、今でも定期的に映像編集の仕事もしてます。専門は3DCGのキャラクターアニメーションです。未熟ですがよろしくお願いします。

なぜこのテーマか

  • 今後Locariをリニューアルする際、色にも統一性を持たせたデザインが必要
  • 開発メンバーはエンジニアの方が大半ですが、感覚や先天的な才能だと思われがちな配色も知識があればサイドプロジェクトや趣味等でデザインをする際にも役に立つ

と思い取り上げました。

色の力

そもそも色ってどんな効果があるの?ということで、色を利用したデザインの例をいくつか挙げてみます。

映像の例

PIXARではスクリーン全体の色によって視聴者に与える感情をデザインしています。

ROYGBIV: A Pixar Supercut from Rishi Kaneria on Vimeo.

例えば、蛍光色的な緑を使い視聴者に不安な印象を与えています。PIXARではこの様な色の使い分けが全ての人間の本質に訴えるものだと信じられています。監督やディレクターにより多少異なりますがアニメーションに限らず他の実写映画などでも基本的に同じようなカラー表現が使われています。(もちろん人々の感情を変化させる要素は色だけでは無く、複数の要素を組み合わせることで乗算的に効果を引き出されます。)

Webサイトの例

医療系のサイトでは白をメインに緑や青のアクセントを使い清潔的なイメージを持たせるところが多いです。
MedicalNote
f:id:ryohei_itabe:20161214181615p:plain:w300
Dr.Note
f:id:ryohei_itabe:20161215010112p:plain:w300
MYCODE
f:id:ryohei_itabe:20161215010117p:plain:w300

ちなみに実際の病院では院内の壁を淡いピンク色にしてリラックスできるようにデザインしているところもあります。(真っ白だと逆に恐怖感を与えるようです。)


色は人の感情的部分に訴えることが出来る効果的なツールとして役割を果たしています。

今回必要な色の基礎知識

覚えておくべき知識はたくさんありますが今回使わないものは省略します。 今回大切なのは、色には明度、彩度、色相の3つのパラメーターがあることです。
f:id:ryohei_itabe:20161215043132p:plain:w300
明度は明るさの度合い
彩度は鮮やかさの度合い
色相は色の種類
まずその3つを頭の隅に置いておいてください。

色は相対的なもの

色には絶対的なパラメーター(#fefefeやR255,G100,B30など)がありますが、それと人間が実際に目で見て頭の中で認識する色は異なります。付近にある色によってその色の認識のされ方も変わるということです。この色は相対的なものという考え方は、重要なのでこれも覚えておいてください。後ほど説明

実際に配色する際のコツ(基本)

使用する色同士の力関係(バランス)を考える

先ほど述べたように色には色相、明度、彩度の3つのパラメーターがあります。
f:id:ryohei_itabe:20161215043132p:plain:w300
彩度が高いものが色として一番強い力を持ちます。最強です。このレベルの色をいくつも使うと色同士が激しくぶつかり合い喧嘩してしまう為、見た目もうるさく良くありません。複数の色を使用する際は全体のバランスを考えます。

みんなが主役にはなれないので色にもサポート役が必要です。サポート役は主役との間にコントラストを作り出して主役を立てます。 コントラストの種類は4つあります。
1. 明度のコントラスト(明るいと暗い)
2. 彩度のコントラスト(鮮やかと鮮やかじゃ無い)
3. 色相のコントラスト(緑と赤など)
4. 面積のコントラスト(大きいと小さい)


バランスを保ちつつ明度、彩度、色相コントラストを意識する

f:id:ryohei_itabe:20161215050345p:plain:w300
今回は例として上の画像を調整します。 どれも主役になりうるポテンシャルを持った色たちですが今回は左端の赤を主役に決めました。左の赤を彩度が一番高いものにする為にサポートの右二つの彩度と明度を落とします。色数が多い為、真ん中は彩度を無くしたグレーにし、右端は主役を立てる反対色の鮮やかさの無い青にします。

f:id:ryohei_itabe:20161215050347p:plain:w300
これにより先ほどくすんでいた赤も他の色のサポートにより綺麗に輝いてくれます。これが色の相対性です。
多数の色を使用するとあらゆる方向にベクトルが散らばってしまいとまとめるのが大変になるので、出来るだけ使用する色を限定するのが色を綺麗にまとめるコツです。

面積のコントラストを意識する

デザインに注目させる意図がある際はさらに面積のコントラストを調整する必要があります。主役の強い力を持つ色は面積がある程度小さければアクセントとなり、人々の目に止まるようになります。
f:id:ryohei_itabe:20161215102828p:plain:w300
アクセントにしたい色は面積が大きくなりすぎないように注意してください。アクセントとしての効果が無くなります。

暖色と寒色による色相のコントラスト(応用)

明度、彩度のコントラスト以外に色相(寒色と暖色)のコントラストをうまく使うことで、デザインが引き締まり深みのある魅力的な配色となります。世の中の素晴らしいデザインの多くにはこのテクニックが使われています。

現実世界での例

f:id:ryohei_itabe:20161215021549j:plain:w300
写真のストレージから掘り起こした1年前に僕が撮った夕日の写真です。夕日や朝日に人々を魅了する美しさがあるのは、明暗彩度のコントラストに加えて色相(寒色暖色)のコントラストがあるというのが一つの要因です。余談ですが君の名は。新海誠さんの作品には殆どのシーンにこの青→ピンク→オレンジの色相(寒色暖色)のコントラストが使われています。

絵画やイラストの例

f:id:ryohei_itabe:20161215020115j:plain:w300
f:id:ryohei_itabe:20161215020119j:plain:w300
© disney. all rights reserved
フェルメール真珠の耳飾りの少女スターウォーズフォースの覚醒のポスター絵は作られた年代が全く違うのですが、どちらも明暗彩度のコントラストと色相(寒色暖色)のコントラストが上手く取り入れられていています。
f:id:ryohei_itabe:20161215021713j:plain:w300
ゴッホの絵でもよく使われています。全体の7割ほど占めるくすんだ青のおかげでヒゲの鮮やかなオレンジが際立って見えます。

アプリの例

f:id:ryohei_itabe:20161215013124p:plain:w300
Musicは音符内の水色とピンクがコントラストになっています。Safariは文字盤の青とコンパスの針の赤が大きなコントラストになっています。

写真などで逆に締まりのあるパキッとしたデザインでは無くほんわかしたムードにしたい場合でも、明度彩度か色相のコントラストのどちらかは残すように意識した方が良いです。もしコントラストが殆ど無いデザインだった場合、単体では掴み所の無いためにそのデザインを眺める時間が減ったり、印象に残りづらかったりします。


綺麗なグラデーションの作り方

プロデザイナー向けSNSのdribbbleなど見ていてもグラデーションを美しく使った作品が多いです。 グラデーションは下手すると初心者感がモロに出てしまうため扱うのは難しいですが、綺麗にグラデーションがハマると透明感のある美しいデザインになります。寒色と暖色のコントラストを意識することで美しいグラデーションを作ることができます。

  1. 元の色から少し明度をずらす
  2. 元の色を見て寒色よりか暖色よりかに色相を少しずらす

f:id:ryohei_itabe:20161215025356p:plain:w300
先ほど紹介したSafariですが、実はもう一つ寒色と暖色のコントラストが使われている部分がありました。 コンパスの文字盤の部分は同じ青系統によるグラデーションですが、ただ単に明度の違うグラデーションではありません。上から下にかけて黄色寄りの暖色系の青から原色の青の方へと変化しています。

このように赤は暖色!青は寒色!と決まっているわけではありません。一番重要な概念色は相対的なものなので、片方と比較してもう片方はどうなのかで色の性質が変わります。
f:id:ryohei_itabe:20161215034852j:plain:w300
この犬がどちらも同じ色という目の錯覚の画像を見てもらえば色が相対的なことを理解して貰えるかと思います。周りの色によって決まります。

配色に便利なウェブサービス

ここまでのことが理解出来れば便利なカラーパレットサービスも正しく使えるようになります!

カラーパレットサービスというのはネット上にたくさんありますが、色に関する知識が無ければあれらのサービスは応用するのは難しいです。バランスとコントラストを意識すればカラーパレットも思うままに使えるようになるでしょう。 ウェブサービスたくさんありますので、主要なものを2つだけ載せておきます。

Coolors
f:id:ryohei_itabe:20161214192720p:plain:w300
Adobe Color CC
f:id:ryohei_itabe:20161214192722p:plain:w300
基本的にどのサービスもパレットには5、6色もありますが、全てを使い切る必要はありません。多すぎる場合は任意で減らして使いましょう。

まとめ

実際に使おうとしてもすぐには上手く行かないかもしれませんが、少しでもお役に立てれば光栄です。配色する際はバランスとコントラストを忘れずに。

明日はデザイナーの先輩のこけしさんです!よろしくお願いします。

LocariとOpsworks

この記事は Wondershake Advent Calendar 2016 14日目の記事です。

ワンダーシェイクのインフラエンジニアの@whiteray_19です。

Locariでは、最近 Opsworks を利用し始めたので、それについて書きたいと思います

はじめに

Locariでは、Batch, Job, API/Web サーバ群を扱っており、
各サーバの bootstrapping, provisioning は knife-solo を利用していました。

Opsworks 以前は、 API/Web に対して、EC2 autoscaling を利用し、
ロード、スケジュールに応じたスケール イン / アウトを行っており、
あらかじめ想定される負荷に対しては、しっかり対応できていました。

一方で、autoscaling で利用するAMIの変更管理だったり、
Jobサーバのスケールアウトや、Batchサーバのメンテナンスのやりにくさがありました。

他にも、アプリケーションのデプロイはCapistrano を利用していたのですが、
Capistrano の バージョンアップに追従するのが比較的大変で、
デプロイ整備に注力するならアプリケーション開発に集中したい


インフラはコード化されてるといっても、
コマンド実行でサーバを立てるより、GUIから操作できた方が楽だし、わかりやすいよね

というような経緯があり、Opsworks移行が始まりました。


状況は改善されたのか

Jobサーバのスケールアウトについて

Opsworks の GUIからクリック一発でサーバを提供できるようになりました

素敵。

Batchサーバのメンテナンスについて

こちらも同様、Opsworks の GUIからクリック一発でサーバを提供できるようになりました

少し脱線しますが、

新規に立てたサーバに対して、メンテナンスを施し、新旧入れ替える運用ができるようになり、
Immutable Infrastructure 的な考えが組み込めるのはうれしいところです。

autoscaling について

Opsworks の autoscaling は EC2 autoscaling と 異なり、少し使いにくい部分があります。
ですが、Locariは比較的ピークタイムがわかりやすいサービスなので、
負荷設計を行い、 Opsworks の Timebase autoscaling を利用することにしました

移行前より、autoscaling の柔軟さはなくなってしまいましたが、
イメージ管理がなくなり、逆にメンテナンスコストは下がったと思います

デプロイについて

Capistrano で行っていることを、chef に変更し、
こちらもクリック一発でデプロイができるようになりました。


blue green deployment の採用

LocariではRack webサーバとして、 unicorn を利用しているのですが、
高負荷時にデプロイを行うと、新旧のプロセスが共存し、CPU負荷が上がってしまい、
一時的にサービス提供できない時間が存在してしまっていました。
それを解決する方法として、
Layer層の blue green deployment を採用することにしました。

blue green deploy を 実装する方法は様々あると思いますが、
Locariでは、Opsworksだけでなく、EC2、ELBが提供している
APIを素直に組み合わせて、運用ツールを作成しています


移行についてのハードル

  • Opsworks 用に chef recipe を改修するのが大変。
  • Capistrano で行っているデプロイを chef recipe として、作成するのが大変
  • Opsworks上での chef recipe のデバッグが結構大変

結構大変なことがありました笑


Opsworks 運用の感想

やはり、GUIの操作だけで、サーバの調達から提供まで行えることはうれしいところです。

また、開発のメイン言語が ruby であることもあり、
chefをプロビジョニングツールとして採用しているOpsworksは相性が良かったです

最近では、chef automateも提供されたので、
ぜひ試してみたいものです。

明日はいたべさんの記事です!
お楽しみに!

asdfって知ってる?色んな言語のバージョン管理が出来ます!

この記事は Wondershake Advent Calendar 2016 13日目の記事です。

ワンダーシェイクのバックエンドエンジニアの@dykstraです。

今回はasdf version managerを紹介したいと思います。

asdfとは?

asdfはバージョン管理ツールです。RubyとElixirのコミュニティーでオープンソースに貢献している@HashNukeさんが作りました。 Rubyrvmrbenv のようなツールで、非常に導入しやすいツールなので、色んな言語にasdfを使えます!

なぜ他のバージョン管理ツールよりasdf使う?

使い方は本当にシンプルです。色んな言語で使えるので、他のバージョン管理ツールのようにそれぞれの言語管理ツールを使うのが通常ですが、asdfなコマンドが同じなので、asdfだけですべての言語のバージョン管理をすることができます。Toolingがいい言語(例えば、Ruby)だけ使ってたら、asdfに乗り換える必要がないと思いますが、tooling良くない言語使っていたり、同じサーバーに色んな言語を使っている場合は、asdf使えば、言語アップグレードする時にとても便利になります。この記事書いてる時点で、既に以下の20の言語がasdfでバージョン管理出来ます。

簡単に、どうやって使う?

  1. asdfインストールして、設定します。 https://github.com/asdf-vm/asdf
  2. asdf plugin-add <言語名> <git-url> (git_urlはここで見つけれます)
  3. インストールしたいバージョンを探します。 asdf list-all <言語名>
  4. そのバージョンをインストールします。 asdf install <言語名> <バージョン>
  5. グローバルでバージョンを設定します。 asdf global <言語名> <バージョン>
  6. プロジェクトのバージョンを設定します。(ホームディレクトリからこのコマンドやったほうがいいです) asdf local <言語名> <バージョン> (なかったら、$PWD/.tool-versions作ります)

すごく簡単ですね!もし操作がわからなくなっても、 asdf -h をすれば、コマンドの説明が詳しく表示されます。

僕の好きな言語のプラグインはない!どうする?

新しい言語を導入したい場合は、asdfのplugin APIで作ればすぐ使えます。

まとめ

開発に専念するためには、バージョン管理のことで時間を使いたくないですよね。asdfなら一つのツールで全部の言語のバージョン管理が出来るので時間の節約になり、エンジニア間のミスコミュニケーションもふせぐことができます。是非、asdfを使ってみてください!

明日はインフラのエンジニアつかださん書きます!ネタはまだ秘密なんですけど、楽しみにしてます!