Blogaomu

WEBアプリケーション開発とその周辺のメモをゆるふわに書いていきます。

開発環境整えNight を一人でやってた

新しいPC(MacBook Pro!!!)に環境を整えたので、今後の自分用にメモを残しておきます。

あらすじ

インストールしたもの

  • Xcode
    • Git使いたい
  • iTerm2
  • homebrew
    • rbenv, ruby-build
    • libxml2, imagemagick (gem に依存するライブラリ)
    • redis
    • mongodb
    • postgresql
    • node
    • scala, sbt, typesafe-activator
    • vim (今までは自分でビルドしていたけどbrewからインストールしてみた)
    • tmux
    • tig
  • Ricty
    • 愛用フォントです!
  • td-agent
  • JDK 8
    • ジャバ
  • かわせみ2
  • Slack
  • Hipchat
  • Dropbox
  • Evernote
  • Gyazo
  • Alfred 2
    • Powerpack導入済み
  • Karabiner, seil
    • US配列なので調整してます
    • CapslockとCtrlを入れ替えるのはseilという別のアプリケーションで設定するようになってた
  • 1 Password
    • これがないと生きていけない。。
  • Trailer
    • プルリクnotifier 便利
  • Dash
    • 最近、課金しました!

Tmuxまわり

Tmux Plugin Manager(TPM)を使う を参考にTmuxのプラグインを入れてみました。 プラグイン管理ツールあると便利ですねえ。

set -g @tpm_plugins ' \
  tmux-plugins/tpm \
  tmux-plugins/tmux-yank \
  tmux-plugins/tmux-resurrect \
  tmux-plugins/tmux-sessionist \
'

ステータスライン

今までは Powerline を使っていたのですが飽きてきたので、vim-airlinetmuxline.vim を使ってみてます。 個人的にはこの組み合わせの方がキレイで設定も楽な感じがあります。

Gyazo

おわりに

個人的には「整えNight」という語感が好きなので今後も開催したいです。

EC Night #1 で発表してきた #ecnight

ECサービスを運用している人たちが集うEC Night という meetup に参加してきました。そこで ECサービスを取り巻く変化とチームの変化 // Speaker Deck という発表をしました。

STORES.jp PRO というサービスの運用に携わっていく中で、工夫したりしたことをチームという視点で発表しました。当日の補足とか感想を書いていきます。

After talk

STORES.jp PRO は 2014年3月にローンチされたサービスで、自分はローンチ後の4月ぐらいから少しずつ開発に参加していきました。最初の印象としては、ZOZOTOWNの連携部分などはとくに作り込まれているなあいう感じでした。そういう背景もあって STORES.jp 本体とは違った部分でハマったり、始まったばかりのサービスとして未知の問題にいちいちハマったりなどなかなか骨の折れる感じの日々でした。

ということで、ちょっとやり方を変えてみましょうかねという発想に到ったのかなあと、今振り返って思いました。それと、スクラムを取り入れてみるという観点では、当時在籍していたエンジニア @ma_ogawa さんと自分の興味が近い部分もありエンジニア主導で進めていった感じがあります。運用などで手作業でやっていた部分も徐々にですが自動化、半自動化したりする意識もこの辺で高まってきたのかなあと思います(設計や実装に時間を割きたいという理由から)。

あとは、チームメンバーの話をすると割と会話したり議論したりもともとしやすかった、というのが助かった部分かなあと思っています。@asonas さんの発表にもあったのですが、情報を独占しないみたいな話って大切で、定期的にだったり非同期的に情報を共有しておくのを意識してもろもろ取り組みました。今後取り組みたいのは、サービスのコンセプトだったり大切にしたいことを言語化しておく、というのをやっておきたいです。これは、@kitak さんの発表だったり、先日の渋谷Ruby会議01での @yaotti さんの発表 を聞いて思ったところです。迷ったときの拠り所になると考えていて、チームで取り組むときにこういう判断基準があればブレにくいのかなあと思っています。

自分の話

自分自身の話をすると、50名前後の前で発表するのが今回初めてでして、かなり緊張しました。実は @kitak さんからイベントの1週間前にDMが来て発表しませんか?と誘われたのですが、発表初めてだし1週間しかないし忙しいし結構悩みました。ですが、お誘いを受ける機会も今回を逃したらもう無いんじゃないかとか思って、発表する風に決めました。

発表するとは意気込んだものの、じゃあ何を言おうか?っていうところでまた悩みました。今思うと答えはすぐに出ていたのですが、そこにたどり着くまで(自分が納得するまで)結構時間がかかりました。最初はマインドマップ書き出してみてアイデアを膨らませて、行けそうだなっと思ったら結局まとまりがなかったり、なかなか難しかったです。スライドに起こして練習して、というサイクルを回してみたのですが、10分に収まらなくてかなり大変でした。世の中の発表者はこんな大変な思いをしてるのかーと気付けました。発表を準備していると、文字に起こすことで考えがまとまったり、意識が高まったりするので精神的には良い作業だなと思いました。

発表後はいろいろな人たちとしゃべることができて楽しかったです。ふだんは聞いてる側の人なので、聞き手の人が自分に対して話しかけに来たりっていう体験は初めてでした。SUZURIBOOTHSTORES.jpと結構近いことをやっているので話聞けておもしろかったですw

つらつらと自分の感想書きましたが、こんな感じです。EC Night 主催のみなさまありがとうございました!!

渋谷Ruby会議01 に参加してきた

11/01に開催された渋谷Ruby会議01に参加してきました。

毎月第3水曜日に開催している Shibuya.rb の拡大版としての地域Ruby会議ですが、いつも通りの "自分たちの" Ruby会議という雰囲気があって良かったです。 レポートは他の人がやってくれているので、自分の感想をつらつら書いていきます。

レポート

感想

自分たちは、自分なりの設計と実装と世界観で何かを表現できる

keynoteのこしばさんの発表やjokerさんの発表で主に感じたところで、Rubyとそのエコシステムを使って(いや、もちろん他のプログラミング言語とかフレームワークとかも使うけど) やりたいものとかほしいものとかを作れるんだよ、っていうメッセージを受け取りました。

jokerさんなんかは趣味でインターネットカラオケシステムを作っていて自己満足されてるようだし、技術的にもedge Railsを使ったりしててそこで得られた知見を仕事でも活用できているっぽくて素晴らしかったです。

こしばさんの話で出てきたエコシステムの自分なりの解釈です。

1) 先人たちが作ったgemやフレームワークを使う
2) 使ってるうちに足りない部分はプラグイン作ったり、バグにパッチを当てたり
3) 公開する
4) 誰かが(自分を含め)それを利用する
5) 2)に戻る

自分たちが大切にしたいことを文章化しよう

yaottiさんの「開発フローの作り方」という発表で感じたところで、 自分たち(これはチームでの文脈)が開発するにあたって大切にしたいこと・大事にしたいことを文章化しておくことで迷ったときの拠り所になっていいなあと思いました。

仕事においては、例えば問題が起きたときに判断に迷う場面があったりしますが、 文章化しておいた大切にしたいことを見ることによって判断の助けになることってあるのかなと考えています。 テンパってくると思考能力が低くなって誤った判断を下してしまうことも多いので、こういうのがあるといい結果になりやすくなるのかなあと。

大切にしたいことを公開することによって、これに共感した人たちがチームに集まってくるという副次的な効果もあるようで、 たしかにそうだなあと納得しました。

自分たちのRuby会議およびShibuya.rb

tyabeさんが最初の方で Shibuya.rbは寄り合い っていうことを言っててたしかになーと思いました。

私も今年から何回か Shibuya.rb に参加してて、渋谷あたりでRuby好きな人たちが集まって、立ち話したり勝手にLTしたりもくもくしてる、というイメージを抱いています。

今回のRuby会議はそれをそのまま体現していた感じがあって、

  • 当日参加のLTとかアンカンファレンス
  • 困っている人がいたらみんなで助けてあげてくださいっていう案内
  • ステッカー好きなだけ持ってっていいよ
  • お子様もリラックスして(?)会場にいれてた

など、やわらかい雰囲気みたいのが漂っていました。

ということで、tyabeさんをはじめスタッフの皆様方ありがとうございました!楽しかったです。

misc

弊社サービスキャラクターのストアくん、描きやすくて便利です。

自分の立ち位置とかを客観的に見れたり、モチベーション高まるのでいいと思いました。

合わせて読みたい

redis gem で Encoding::CompatibilityError が発生した

set(key, value) するときに、keyとvalueのエンコーディングに互換性がないと例外になる話。

keyに日本語入れることはあまり無いと思いますが、以下の例で発生します。

require 'redis'
require 'msgpack'

redis = Redis.new(host: "localhost", port: 6379)
redis.set('読書', MessagePack.pack({cnt: 14}))
#=> Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT

'読書'.encoding
#=> #<Encoding:UTF-8>

MessagePack.pack({cnt: 14}).encoding
#=> #<Encoding:ASCII-8BIT>

https://github.com/redis/redis-rb/blob/v3.1.0/lib/redis/connection/command_helper.rb#L28

この行で Redis#set に渡した引数を join するのですが、 読書MessagePack.pack({cnt: 14})エンコーディングが異なり、互換性がないため例外が起きてました。ケースとしては少ないと思いますが気をつけましょう...。

『リファクタリング・ウェットウェア』を読んだ

TL;DR

今までのやり方に行き詰まっている、意識的に学びたい、そんなときに読むと実践的な知見が得られてオススメです。

概要

原著の題名は "Pragmatic Thinking and Learning" ということで、実践的な思考法と学習法、といったところでしょうか。日本語訳の題名は、ウェットウェア(脳)のリファクタリング、となっていて何だろうと思わせるような感じになっています。副題は、達人プログラマーの思考法と学習法、です。

章の構成としては以下のようになってます。

  • ドレイファスモデルを使い、初心者と達人にはどのような違いがあるのか、どのように達人になっていくのかを始めに説いています。
  • 次に、人間の脳はどうなっているのか?というプログラマーは普段興味を持たない(であろう)分野の解説をしています。
  • 脳の特性を理解した上で、達人に近づくべく思考法や学習法を学んでいきます。
  • 最後に達人になってからのちょっとした注意喚起が書かれて締められています。

ここからは私が気になったトピックを2つ挙げて感想を書いていきます。

コンテキストスイッチングのコスト

短期記憶を全て読み込み直すには平均20分かかると言われています。コンテキストスイッチングをいかに行わないか、またそれを行うとしても集中状態を保つかということが書かれています。

これは自分自身の最近の仕事のやり方にもあてはまるな、と感じていて、複数のプロジェクトを進行したり、メールの対応、各種質問の対応、ミーティングなどコンテキストスイッチングが多く発生する状況になっています。自分自身のリソースは限られているため効率的に作業できないかなと考えていたところにこの本に出会ったので、なにか運命めいたものを感じました。意識的に割り込みを遮断するコントロールや他のコンテキストに戻れるように簡単なメモを残しておくなどのテクニックはすぐに実践しようと思います。

RモードとLモード

人間の脳には大きく2つのモード(Lモード: リニアモード, Rモード: リッチモード)があると書かれています。Lモードは言語的、分析的、計数的などのプログラミングに必要そうな特徴をもっています。Rモードは非言語的、総合的、具体的、非合理的などプログラミングとは一見かけ離れた特徴をもっています。しかし、このRモードを活用することで達人プログラマーに近づけると書かれています。

Rモードの脳は強力なパターンマッチングと検索機能を備えている、Rモードからの出力は言語で表現することができない、などかなり興味深い動きをするRモード。この機能を利用して思考を高める方法や効率的な学習法を提起していて、面白いアプローチだなと思いました。中には(科学的に実証されていないなどで)あやしげな方法もあるので自分の判断で取り入れるのをオススメします。

Rモードの働きをトレーニングするということで試しに上下反転になった絵を見てそれをそのまま描く、ということをやってみました。注意点は、30-40分くらい静かで邪魔の入らない環境を用意する。お手本にする絵の向きを変えてはいけない。特定の部位を認識しても、その名前を意識してはいけない。結果としてこのような絵を描くことができました。

読み込み中

リファクタリング・ウェットウェア』の認知転換の話で描いてみた絵。上下反対になったものを書き写しただけだが、うまく描けてる感があるw

Instagramで閲覧

私は絵が得意ではないので、認知の仕方を変えるだけでこうも違うのだなあと驚きました。

おわりに

普段使っている脳の働きを知ってそれに合うやり方を行う、というのは合理的だなあと思いました。プログラミング言語フレームワークの特性や中の処理を理解しそれを利用することと似ていて、プログラマーにもスッと入ってくる方法だと思います。個人的にはドレイファスモデルや認知の部分にも興味を持ったので、これらの分野の書籍も読んでみたいです。

AnsibleでRails appが動く環境を作ってる

先日のほっかい道場にてAnsibleを学ぶモチベーションが高まったので、早速ドットインストールのAnsible入門をやりました。 ここでは、基礎的なAnsibleの使い方を学んで、LAMP構成の環境を作りました。

ふむふむ、なるほど、と思いRailsアプリケーションが動く環境を作ってみようと思いました。 仕事でもプライベートでもRails使うことが多いので、より実践的な感じですね! ひとまずガガッと作ってRails appが動くところまでできたので感想などつらつら書いてきます。

ソースコード

https://bitbucket.org/TAKAyuki_atkwsk/ansible-rails-work/src/f3a7dbd72091

サーバー構成

こんな感じで環境を構築してみます。Vagrantを使って立てたサーバーに対して、ローカルからAnsibleであれやこれや行うイメージです。 Rails appは別途デプロイツール(Capistranoとかminaとか)でデプロイします(詳細は割愛)。

ハマったところ

  • Vagrantで立ち上げたサーバーに対してplaybookを適用するときに、単純に ansible-playbook コマンドを実行してもうまくいかなかった。
    • Vagrantfile のなかで config.vm.provision "ansible" do ... のブロックを書いておくと vagrant provision コマンドで playbook を適用することができる。
  • rbenvの初期化コマンドを .profile に書き込むのだが、playbook適用ごとに毎回追記されてしまった。
  • playbook 適用時に rbenv コマンドを絶対パスで指定しないと実行できない?
    • パスが通っていない模様。
    • 厄介そうだったのでいったん放置した。
    • playbookをリファクタするときに解決したい。

やってみて

とりあえずymlにやりたいことを書いて置けば、あとはコマンド実行すればインストールや設定などいい感じにやってくれるのでカジュアルでいいなと思いました。 参考にしたplaybookを見ているとディレクトリ構成などちゃんとしているので、ドキュメント見ながらリファクタしていきたいです。 ひとまずはRails appが動く最低限の環境が整ったのでよしとしよう。

Try

  • playbookのリファクタ
    • best practicesなど参考にする
    • ベタ書き部分の変数化(ユーザー名、パス、Ruby versionなど)
    • role を理解する
  • nginx.conf の管理
    • unicorn使いたいのでその設定を管理したい
  • rbenv コマンド実行できない問題
    • ハマったところを参照

参考

ほっかい道場 第二回勉強会に参加してきた

こちらの勉強会に参加してきました。 第二回勉強会 | GeekDojo 〜プログラミングの学習にぬくもりを〜

コンセプトとしてはこんな感じです。

DockerとかAnsibleを題材にディスカッションします。 作っているものとか、作っている資料とかあれば見てもらったりしましょう。

私の参加目的としては、インフラまわりももっと知りたいなあ、というところと自動化して楽したいなあ、というところでした。 とはいえ、ChefやPuppet, Docker などはちょろっと触ったぐらいなので、この道場を通してなにか一つでもモノにできたらいいなあ、という感じです。

話題

感想

今回は私を含め3人で雑談したりコード見たり、という感じでいい距離感でコミュニケーションできたなあと思いました。 (ほっかいさんが共通の知りあいだったというのもあって安心だった。) また、会場もおしゃれなところで、たまにラテン系の陽気なBGMが流れたりして雰囲気良かったです。 事前にツールをあまり触れられなかったのが私自身の課題でした。なので、次回までにドットインストールのAnsible入門をできるところまで進めていきたいです。

ということで次回も参加できたらなあと思います。