Blogaomu

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

2015年個人的振り返り

web開発 雑記

今年の初postが振り返り記事という何とも残念な感じですが、毎年のように振り返っていきます。

仕事

今年はひたすら新規プロジェクトをリリースまで持っていくということをやってました。前半はPlay(Scala)を使ってWebAPIを量産し、後半はチーム管理をやりつつコード書きつつインフラ整備しつつという感じでした。

Scalaについては1年間触ってきて、また経験者と一緒に仕事することでPlay上である程度はやりたいことはできるようになってきたと感じています。しかし非同期処理やファイル操作に関してはまだパッと書けるレベルではないので来年の課題です。

上記でもあるように年の後半は複数の役割をこなさないとならない状況でだいぶ苦しかったですね。慣れない管理や調整、コードを書きたいのに時間がないジレンマ、などなど思うように仕事が進まないストレスもだいぶありました。しかし、最近になって自分はコードを書かない(必要なら書く)というスタンスに切り替えてからは時間の余裕もでき、心の余裕もできつつあるかなと思います。逆に全くコードを書かなくなってしまうのも微妙感あるので、この辺りのバランスを取るのが来年の課題でしょうかね。

仕事以外

前半はScala勉強会(rpscala)やScala TV、Effective Akka読書会などScala系の勉強会に顔を出していたんですが、業務が忙しくなるにつれて全く参加できなくなってしまいました。また社内でも実践DDD読書会を@tyabeさんとやってたんですが、業務の忙しさを理由に休止となってしまいました(来年からは復活するぞ)。

今年のOSS活動ですが以下になります。どちらもドキュメントの修正でした。ドキュメント読んでて、あれ何か実装とずれてる？と思い修正出してみました。

つい先日ですが初めて北陸のコミュニティに顔を出しました。東京でずっと活動していて地元の開発者のつながりがほとんど無かったので新鮮でした。

仕事以外ではありますが、仕事の比重が大きくなってプライベートがおろそかになったのが反省すべき点でした。体作りや交友関係、勉強や趣味の時間をこれでもかというぐらい削ったので来年はこちらの方にも時間を振り分けられるようにしていきたいです。

来年に向けて

だいたい既に書いてきている事ではありますが、足りないスキルを身に付けること、仕事におけるリソース配分、生活におけるリソース配分というところを意識して過ごしていきたいです。また秋ぐらいから数学欲がまた湧いてきたので知識を身に付けていきたいです。

それでは皆様今年もお世話になりました。良いお年を。

2014年個人的振り返り

web開発 雑記

今年ももうすぐ終わりそうなので、毎年恒例の振り返りを書こうと思います。

なにやってたっけ？

仕事ではあいかわらず Rails / Ruby メインでコードを書くことが多かったです。 今年は(も？)あんまり Angular.js は触ってません。私の代わりに @mknkisk ががんばってくれましたw

去年と異なるのはインフラだとか開発基盤を見ることが多かったのかなということです。

バージョンアップ系

Ruby 1.9 系から 2.1 系へのバージョンアップを行ったのですが、バージョンを上げる際に既存の処理が動かなくなる心配があったので、 テストコードを充実させることを私が中心となって開発チームで進めました。 これをきっかけに自分以外の人もテスト書くようになってきたので副産物的によかったです。

あとは MongoDB を 2.4 -> 2.6 に上げるサポートをしました。というかこれはほぼ @mknkisk 先生のがんばりです。 ありがとうございました！

コアじゃない部分は外部サービスに任せる

今まで自前で管理していたこと(メール配信、CI)を外部サービスを使うようにしました。 メール配信、移行前は大量のメールを配信する難しさ、暗黙知みたいなところが多くてとても苦労しました。 移行自体は @sakagami3 がやってくれました、ありがとうございます。

CIも今までは Jenkins を自分たちで運用していて、出勤したらいつの間にか OutOfMemoryError で動かなくなっていたり などなかなか見守りが大変でした。Shibuya.rb の常連さんである @ryonext さんが CircleCI を導入したという話をブログで書いていたので 直接知見を聞き、弊社も無事に導入できました。ありがとうございます。

餅は餅屋に任せておけばいい的な考え方が今年は会社に浸透したのかなあという気がします。

インフラ周りその他

セキュリティに関してのEC2インスタンスメンテナンスアップデートが割と大規模に適用されててんやわんやしてましたw
事前に再起動すれば回避できるとかできないとか情報が錯綜していて混乱してましたが、なんとか対応できました。

オペレーションの自動化や Infrastructure as Code に関しては、 hubotを導入したり(まだ導入しただけでchat-opsまではできてない)、ほっかい道場をきっかけに Ansible 触ってみたり ということをやりました。ちょっと中途半端に終わってしまいましたね...。

開発しやすくする仕組みとか

どうやったら開発しやすくなるかな、というのを考えたり実践してみたりしたのも今年っぽかった項目だと思います。 ペアプロをやってみたり、スクラム的なことをやってみたり、プルリクを通したコードレビューをやってみたりなどなど。 個人レベルでは、去年から引き続きテストコードを書き続け、知見をドキュメントに残したり、設定ファイルをGitで管理する みたいなことをやってました。開発チーム内で習慣になりつつあることも増えてきたので、そこは良かったなと思います。

仕事以外の話

去年の年末ぐらいから関数型言語を触り始めました。最初は Haskell を勉強してましたが最近は Scala 寄りになっています。 関数や代数的データ型の考え方にはまだ慣れない部分が多いですが、こういう考え方やアプローチもあるのか！ と新たな発見があったりしておもしろいです。まだまだ時間をかけて勉強と実践を続けていきたいと思います。

自分でも驚いたのですが Shibuya.rb に顔を出すようになったのも今年からでした。 存在自体は去年から知っていたのですがタイミングが合わずにいけなかったのです。 何回か参加するうちに顔なじみの人が増えてきて一月に一度の密かな楽しみの一つとなっています。

EC Night というミートアップにて発表を行いました。40-50人くらいの規模での発表は初めてだったので かなり緊張しましたがいい経験になりました。

OSS活動はあまりできませんでしたが、こんな感じでした。Vimまわりで貢献できたのはとてもうれしいです！

mina-slackは会社でごくごく普通に使われているのでいい感じです。

とかなんとかやってたら1年終わってました。まさにあっという間だった...。

自分の限界？

やってたことの範囲が広すぎて、深く学ぶことがなかなかできなかったような気がしました。 とはいえ、去年に挙げたやりたいこと項目はひと通りできたように思います。

何かを作るモチベーションと自分の力の無さ

「あー、これあったら便利だなあ」と思って作り始めてみるものの、いらんところでハマったりしてそのままズルズルモチベーションが下がったことが多かったです。 プロトタイプぐらいはさくっと作れるようにしておきたいと強く感じました。とは言えども、2つ世の中に出せたのは良かったのかなと思います。

新しいこともやってみたいけど、それを実現するための基礎がしっかりしていないとだめだなあと実感した1年でした。

来年やりたいこと

アプリケーションでもライブラリでも思いついたものをとりあえず作りきる、ことをやりたいです。 これを補完するものとしてRubyだとかデザインだとか、引き続き関数型言語とかやる感じですかね。

会社に所属していて(インターネットコンテンツとして)私個人がWebメディアに出る機会が増えてきたので エンジニアとしての実力も伴っていかないといかんなーと気を引き締める2014年末であります。

また、今年はさまざまな人に助けられた1年でした。この場を借りて御礼申し上げます。

それでは良いお年を。

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

mac tool

新しい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-airline と tmuxline.vim を使ってみてます。 個人的にはこの組み合わせの方がキレイで設定も楽な感じがあります。

Gyazo

おわりに

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

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

Meetup

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分に収まらなくてかなり大変でした。世の中の発表者はこんな大変な思いをしてるのかーと気付けました。発表を準備していると、文字に起こすことで考えがまとまったり、意識が高まったりするので精神的には良い作業だなと思いました。

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

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

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

Ruby 雑記 Conference

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 が発生した

Ruby

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}) のエンコーディングが異なり、互換性がないため例外が起きてました。ケースとしては少ないと思いますが気をつけましょう...。

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

読書
リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法
著者 : Andy Hunt
オライリージャパン
発売日 : 2009-04-27
ブクログでレビューを見る»

TL;DR

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

概要

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

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

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

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

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

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

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

RモードとLモード

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

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

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

読み込み中

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

Instagramで閲覧

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

おわりに

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

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法
著者 : Andy Hunt
オライリージャパン
発売日 : 2009-04-27
ブクログでレビューを見る»
ベナー看護論―初心者から達人へ
著者 : パトリシア・ベナー
医学書院
発売日 : 2005-09
ブクログでレビューを見る»
決定版 脳の右側で描け[第4版]
著者 : ベティ・エドワーズ
河出書房新社
発売日 : 2013-01-17
ブクログでレビューを見る»