Blogaomu

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

金沢でリモートワーク始めました

雑記 Remote working

今週から金沢の実家でリモートワークを始めました。まだ始めて4日間ですが金曜まで終えて一区切りと言うことで感想でも書いてみようと思います。

背景

もともと東京のオフィスに通って働いていたのですが、家庭の事情により実家に戻ることになりました。金沢に拠点を置く企業に転職するという選択肢もありましたが、積極的に今の会社を辞める理由も無かったので上司や社長に事情を話したところOKが出たので今に到っています。

会社では他のチームで週一のリモートワークが認められており運用実績があったこと、また私が携わっているチームでも別拠点で働いているメンバーがいたり深夜メンテナンス作業で自宅で作業したりなどと自分自身でも少ないながらも実績があったことがOKを出しやすかった要因なのかなと思っています。ただ、私のように完全リモートかつ関東圏以外に拠点を置くのは社内初の試みなので人柱感半端ないですw

そもそもどういう仕事をしているのかという話なのですが、現在携わっているのはコンシューマー向けアプリの開発・運用で、私の行う作業としては、APIの設計・実装・コードレビュー、お問い合わせに関する調査や対応、AWS上で構築されているサーバー群の運用というところがメインです。こういう具合なのであまり一人でもくもくと作業するという感じではなく、同期／非同期にコミュニケーション取りながら進めていくことが多いです。

準備

準備としてここ1ヶ月くらいは約週1回のペースで東京もしくは金沢の家で仕事するようにしていました。私もオフィスにいるメンバーもお互いに慣れる期間として設けていました。普段からSlackやSkypeのチャットベースでやり取りしていたので、リモートワークでもそこは普段通りです。まだ自分だけリモート越しの会議をやっていないのでこれはどうなるか気になってます。当初はオフィスだけで話が進んでてリモートで自分がやるべき対応が遅れてしまったなんてこともありましたが、このところはそういう問題も少ない気がします。

あとは、他のメンバーがQiita:Teamに書いたリモートワーク制度についての記事を見て参考にしたり、実際にリモートワークしているメンバーにどんな感じですか〜というのを聞いたりして知見を増やしていました。

実際やってみて

気付いたら作業しっぱなしになる

休憩取るのは自分のペースで行けるんですが、逆に休憩を取るタイミングが無さすぎて気付いたら昼過ぎてたとか日が暮れてたというのはあります。オフィスにいるときはSlackの雑談チャンネルで腹減ったーとか言って昼飯を食べに行ってたので、半強制的？に作業が切れていました。今は実家(両親が住んでる)なので母親がご飯を準備してくれてじゃあできたので食べようとなるんですが、初日に仕事のキリが悪くあとでーとなったので、もう自分のタイミングで食べてくれってなりました(汗) キリが悪くても一緒に食べるのが理想ではありますが。

通勤が無くなった

自由に使える時間が増えました。といっても今週はまだ慣れてないので疲れて横になってしまってますが。ただ、歩くことも減ってしまったので意識的に動かないと体が鈍りそうだなと思ってます。

お土産が貰えない

弊社では、週末にどこどこ行ってきてお土産買ってきましたー、という風景がしばしば見られるのですがリモートワークだとその恩恵にあずかれないことが分かってしまいました。。まさかこんなデメリットがあるとは思いませんでした(汗)

おわりに

まだ始まったばかりなので、これからいろいろなことが起こるんだとは思いますが、ひとまずは1週間終えたというところで良かったです。慣れてきたら周辺の技術コミュニティーにも顔出していこうかなと思ってます。

f:id:TAKAyuki_atkwsk:20160719095803j:plain

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