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

Jenkinsとrrrspecと私

Misoca開発チームの黒曜(@kokuyouwind)です。
最近PS VRを買いました。画像は夏にSony StoreのPS VR体験会へ行った際、スタッフの方が撮ってくださった写真です。

f:id:kokuyouwind:20161130184820j:plain

OculusやViveと比べると解像度は低めですが十分な没入感がありますし、なによりアイマスVOCALOIDなどのキャラクターコンテンツが色々あるのは強いですね。
PS VRはいいぞ。

rspec-queueからrrrspecへの移行

MisocaではJenkinsを使ってCIを回しています。
またrspecでテストを書いており、Jenkins上では時間短縮のためにrspec-queueを使って並列実行していました。
しかし、テストが増えるにつれてrspecの実行時間が長くなってしまい、CPUコア数やメモリの制約で1ノード内での並列数も限界になっていました。

このため、ビルド時間の短縮を目的にrrrspecへの移行を行いました。 今回はこの移行についての話を紹介したいと思います。

rrrspecについて

rrrspecは、クックパッド社製のrspec分散実行ライブラリです。
複数のworkerがそれぞれジョブキューからジョブを取得して実行する構成になっており、workerのマシンやプロセスが落ちた際の自動復帰、無反応プロセスのタイムアウトなどの機能が特徴となっています。

技術的な詳細についてはクックパッド開発者ブログの記事がまとまっています。
また、Software Design 2016年8月号に特集記事が掲載されており、今回のrrrspec移行でも、こちらの特集記事を参考に作業を進めました。

サーバ構成

rrrspec移行前

rrrspec移行前は下図のような構成になっており、Jenkins Slaveノード上でrspec-queueプロセスを立ち上げて実行していました。
またMySQLはプロセスのメモリオーバーヘッドを考慮し、2つのJenkins Slaveノードのうち片方でのみ立ち上げて、それを両方から見る構成にしていました。

f:id:kokuyouwind:20161202112726p:plain

この構成だと、Jenkins SlaveノードのCPUやメモリ構成を簡単には変えられないため、rspec_queueで上げられる並列度には限界がありました。
またJenkins Slaveノードにはベアメタルサーバーを利用していたのですが、普段はかなりのリソースを余らせているものの、ジョブが集中するタイミングではリソースが全く足りない、という状況になっていました。

rrrspec移行後

rrrspec移行後は下図のような構成になっています。

f:id:kokuyouwind:20161202112746p:plain

移行前と比べるとかなり複雑な構成に見えますが、Jenkinsクラスタとrrrspecクラスタはrrrspec masterノードを間に挟んでいるだけで、クラスタ間では参照がない構成になっています。
こうしてみると、それぞれのクラスタについては比較的シンプルな構成となっているのが分かるかと思います。

rrrspec-workerノードについて、図中には1ノードのみ記載していますが、実際には複数台を起動しtaskが分散実行されるようにしています。
この際、rrrspec masterノードからはrrrspec workerノードを知る必要がないため、適切な設定でrrrspec workerノードを立ち上げるだけでスケールアウトすることができる、というのがrrrspecの素晴らしい点だと思います。

JenkinsのJob定義

rrrspecの移行と同時期にJenkinsのバージョンを2系に上げたため、rrrspecを実行するテストはPipelineを利用してJenkinsfileに記述しています。
以前のジョブ定義に比べると、Jenkinsfile化されたことで履歴管理ができレビューもしやすくなり、stage viewを見ることで失敗したstageを手早く把握できるようになりました。

stage viewでの表示

stage viewでの表示は以下のようになっています。

f:id:kokuyouwind:20161201180829p:plain

このうち、rrrspecに関連しているstageはRspec StartとRspec Waitです。

Jenkinsfileの内容

Rspec Start stageでは、以下のように rrrspec-client start を実行し、 taskId を取得します。

stage 'Rspec Start'
taskId = sh(returnStdout: true, script: '''#!/bin/bash -e
bundle exec rrrspec-client start \
  --rsync-name=jenkins-${NODE_NAME}-${EXECUTOR_NUMBER}
''').trim().split("\n").last()

一方、Rspec Wait stageでは取得した taskId を指定してrrrspecのタスクセット完了を待ち、完了したら結果を表示します。

stage 'Rspec Wait'
withEnv(["TASKID=${taskId}"]) {
  bash '''
bundle exec rrrspec-client waitfor $TASKID
bundle exec rrrspec-client show $TASKID
'''
}

この2つのstageの間に、lintやフロントエンドのテストを行うstageを挟んでいます。
これにより、pipelineとしては直列のまま先にrrrspecを回す、というちょっとした並列処理を行ってジョブ実行時間を短縮しています。

なお、Jenkinsではparallelを使って並列処理を定義することもできるのですが、parallel内部ではstageを定義することができません。
このためstage viewでrrrspecとlint・フロントエンドテストが1つのstageとして表示されてしまい、どこで落ちたか分かりにくくなってしまうという問題があったため、上述のような実装になっています。

rrrspec workerのスケーリング

rrrspec workerはインスタンスが突然停止されても問題ないことから、コストパフォーマンスの高いAmazon EC2 スポットインスタンスを利用しています。
前述の通り、適切な設定でAMIを作成しておけばインスタンスを起動しただけでrrrspec masterに接続してtaskの実行を開始することができます。
このため他ノードの設定などを行う必要がなく、簡単にAuto Scalingの仕組みに載せることができます。
CIでの自動テストでは、Jobがない状態ではリソースが不要な一方で、Jobが集中しているときには大量のリソースを必要とします。
このためAuto Scalingに載せやすいというのはコスト削減の点でもJobのスループット向上の点でも非常に重要です。

スケーリング設定

現在はrrrspec workerインスタンスのAuto Scalingを以下のように設定しています。

  • スケジュールされたアクション
    • 平日5時から、最小5, 最大5
    • 平日9時から、最小5, 最大15
    • 毎日20時から、最小1, 最大5
  • スケーリングポリシー

考慮したこと

Misocaでは、.rrrspecconfig.max_workers = 5と設定しているため、1つのTasksetにつきrrrspec workerを最大で5ノード利用します。
このため5ノード単位でworkerをスケールさせることで、各Tasksetを最大効率で実行することができます。

また、基本的には日中の決まった時間にのみ勤務しているため日中にリソースを集中させたいのですが、フレックス勤務を採用しており夜間に少し作業を行うこともあるため、夜間でもCIが実行できるようにしておく必要がありました。
さらにallnightジョブのプラクティスを取り入れており、作業の行われていない早朝に数回テストを実行して安定性を確認するJobを実行しているため、この時間帯はリソースを確保しておく必要があります。

設定の意図

スケジュールについては、最小数指定で最低限のインスタンスを常に確保しつつ、負荷があがったタイミングでは最大数までスケールするように意図しています。
5インスタンスのまとまりで考えると、allnightジョブを走らせる平日5時〜9時は1並列固定、平日日中は1-3並列です。
夜間はやや特殊で、常時確保するのは1インスタンスのみで、ビルドが始まったタイミングで5台までスケールするようにしています。
このため夜間は少しビルドに時間がかかりますが、5インスタンスを常に立ち上げておくのに比べるとほぼ1/5のコストに抑えられます。
夜間はたまにしかジョブが実行されないことを考えると妥当なトレードオフではないかと思います。

スケーリングポリシーについては、CPU負荷が高い場合はリソースが枯渇しているのでインスタンスを増やし、CPU負荷が下がったときには余っているリソースを開放する、という動作を意図しています。
インスタンス追加する基準が60%となっているのは、10台ある状態で5台だけが動いているときにはリソースが余っているため、インスタンスが追加されないようにするためです。

スケーリングの可視化

インスタンス数やCPU UtilizationなどはCloudwatchのダッシュボードを使って一覧できるようにしています。
左上のインスタンス数グラフとその下のCPU Utilizationをみると、CPU負荷に応じてインスタンス数がスケールしているのが分かるかと思います。

f:id:kokuyouwind:20161201191229p:plain

まとめ

Misocaではrrrspecを利用してテストを分散実行するようにすることで、以前は20分前後かかっていたビルド時間を10分程度まで短縮することができました。
またスポットインスタンスを利用し必要なタイミングでスケールさせるようにすることで、以前に比べてコストも削減できました。

今後の課題として、以下のようなことを考えています。

  • スポットインスタンスをm4.large以外も使えるようにして、よりコストパフォーマンスの高いものを自動で使うようにできないか
  • 常にm4.largeを確保しているMySQLノードについてもスケールさせられないか
  • CPU Utilizationではなくrrrspecのtasksetの状態に応じてスケールさせられないか

宣伝

Misocaは継続的にCIを改善したいエンジニアを募集しています!

あと島根で働きたいエンジニアも募集しています!

Slackを使いこなすための設定とMisocaにおけるSlackしぐさ

はじめに

MisocaチームのRKTMです。

この投稿は、ときどきナガノという、 長野県庁の企画を利用して、長野県松本市コワーキングスペースにて書いています。 Misocaではリモートワークができるため、金曜日に旅先へ移動して仕事->土日をフルに観光に使えます。

松本からは冠雪した北アルプスを眺めるられるかなーと思っていましたが、ちょっと雲がありますね。あの雲の向こうの雪山に心惹かれています。 f:id:RKTM:20161125132337j:plain

SlackはMisocaチームに欠かせないツール

MisocaチームではSlackをどうやって使っているか、という記事は過去に公開しています。

tech.misoca.jp

Misocaではリモートワークを推奨しているため、松江オフィス、岐阜など、名古屋オフィス以外でメンバーが活動しています。

www.wantedly.com

リモートの人がいることもあり基本的なコミュニケーションはSlackで行っています。(口頭のほうが早いことはハングアウトを使って同期的に話しています。)

f:id:RKTM:20161125135459p:plain

なお、MisocaのSlack statsは以下の通りです。

全期間でのメッセージ合計数 f:id:RKTM:20161122141558p:plain

782K。

メンバーのメッセージ数 f:id:RKTM:20161125135656p:plain

自分の発言数が多いことに気づきます。

自分とmzpの二人でMisocaの発言数の10%を占めている…という発見がありました。

Slackで読むスピードを上げよう/もっと気軽に書き込もう

最近Misocaでは開発メンバーが二人Joinしましたが、Slackに慣れないようです。

主なハードルは

  • メッセージ流量に追いつかない
  • 書き込みづらい

という2点の模様。

そこでMisocaに新しく入った/入る人を想定して、 流量に圧倒されず読むスピードを上げるためのおすすめ設定、 Slackに気軽に書き込むためのtipsを記載します。

早く読むためのSlackのおすすめ機能や設定

以下がSlackおすすめ機能です。

ショートカットキー

/shortcutsでショートカットキーが表示されます。 最低限知っておくと良いのは(環境によってキーに多少の違いがありますが)、以下の通りです。

  • Cmd+kでchannel検索
  • Option + ↑ or ↓でチャンネルリストの上下移動
  • Option + Shift+↑ or ↓で未読のチャンネルリストの上下移動
  • (ショートカットキーではないですが)入力エリアでで、自分が最後に投稿したメッセージの編集ができる(typoした時などに便利)

自分へのmention/reactionを表示

ヘッダー右のアットマークをクリックすると 重要なmention(依頼など)の見落としがないか確認できて便利。

f:id:RKTM:20161125135812p:plain

個人の設定変更

f:id:RKTM:20161121132225p:plain

Slackのチーム名プルダウンからPreferencesを選択すると、個人の設定変更画面が表示されます。

チャンネル一覧を未読のものだけにする

f:id:RKTM:20161121132618p:plain

この設定で、未読のチャンネルのみがサイドバーに表示されます。 この設定をしないと、大量のチャンネルがずらっと並んで非常につらいことになります。 未読ではないチャンネルに移動する時はCmd+kを使ってください。

人によって評価が分かれる設定

チャンネルのStar

特定のチャンネルをサイドバー上部にまとめて表示し、すぐにアクセスできるようにする機能。

ALL UNREADS

未読の発言だけを集約した仮想チャンネル。

チャンネルを移動せずに未読を消化できるので良いですが、 発言の文脈がわかりづらく、1時間ぐらいでやめました。

その他tips:参加するチャンネルを絞る

そもそも、自分に関係の少ないチャンネルからは勇気を持ってleaveしましょう。

MisocaにおけるSlack tips

気軽に書き込める個人チャンネルをつくろう

Misocaでは、各自が好きなことを好きに書き込める自分用のチャンネルを作っています。 そこは共有場ではなく、自分の場ということで、好きなことを好きなだけ書いてOKです。 仕事に関係ない独りごとから、作業メモや詰まっていることまで、誰に気兼ねすることなく書き込みましょう。

こちらを参考にしました。 c16e.com

Misocaではチャンネル名はcurrent_xxxというパターンにしています。

書き込んでいると色々な人が集まってきて解決してくれたり悪乗りしてくれたりします。 f:id:RKTM:20161122155103p:plain

自分で閉じずにとにかく書き込みましょう

  • 自分の作業が詰まった時や判断に悩んだ時はSlackに書きこみましょう。
  • 質問もお気軽に。気の良い人が優しく教えてくれます。

f:id:RKTM:20161122154309p:plain f:id:RKTM:20161122151757p:plain 質問から発展して最新の情報にアップデートできました。

秘密にしたいことでなければ、DMは使わないでおこう

オープンにしておけば、そのやり取りを見たチームメンバーが更にいいアイデア出してくれるかもしれません。 また、そのやり取りが他の人にとって有益な情報である可能性もあります。

最後に

Slackのおすすめ設定と、MisocaにおけるSlack tipsについて記載しました。
Slackは軽量で色々なサービスとも連携できる便利なサービスですが、 後から入った人には少し敷居が高いかもしれません。

本記事がそんな方やチームに、少しでもご参考になれば幸いです。
みなさんのSlackおすすめ設定などもぜひ教えてください!

esaからその他カテゴリを撲滅した

こんにちは、mzpです。最近は、毎日だれかが体調不良で休んでいて、恐怖に震えています。

最近、esaのカテゴリを整理しており、とうとう「その他」というカテゴリを廃止できました。 今日はその話を紹介します。

背景

Misocaでは情報共有ツールとしてesa.ioを利用しています。

ただ、当初からQiita:teamを使っており、2015年の中盤にesaに移行しました。 このとき、Qiita:teamにあったすべての記事は自前のスクリプトで移行しました。

その際、esaのカテゴリに相当するものがQiita:teamにはなかったため、とりあえず「その他」カテゴリ以下にすべての記事を分類しました。そのため以下の画像のように、その他カテゴリ以下には1000本以上の記事が分類されていました。

f:id:mzp:20161117135553p:plain

問題点

この状態のまま1年半ほど過してきたが、以下のような問題が生じてきました。

  • 目的の記事に辿りつくのに常に検索が必要。そのため、あると分かっている記事しか見れない。
  • 他にどのような記事があるか分かりづらいため、同じような記事がどんどんできていく。
  • 記事を新規作成したいときに、どこに作るのがよいか分かりづらい。

要するに、各自がメモを置いていく場所になってしまい、チーム全体で情報を共有する場になれていない、という問題点がありました。

esa自警団

これらの問題に対応するためにesa自警団を組織しました。まずは見通しをよくするために「第1階層のカテゴリ整理」と「その他を適切なカテゴリに分類する」を目的としました。

f:id:mzp:20161117135607p:plain

この自警団の組織と直前に、技術顧問であるkakutaniがesaに書いた文書がエモくてよかったので引用しておきます。

Wikiの格言(要出典)に「Wikiのもっとも良い書き手とは、それを読みたい読者である」みたいなのがあって。「自分が読みたい文書にしていく」活動がWikiなのでした。

Misocaのesaでいうと「自分が」よりももう少し広くて「Misocaのメンバーにとって」読みたい文書が集まっている場所にしていけるといいなと思ってます。

そのためには、「Misoca社っていうのはこうなってる」という文書について、メンタルモデルを不断に合わせていく活動が大事なのだ。

8年も前の文章だから恥ずかしくて自分ではもう読み返せないけど:第4回特別コラム 「なぜそんなにも(アジャイル開発者にとって)Wikiは重要なのか」:アジャイル開発者の習慣-acts_as_agile|gihyo.jp … 技術評論社っていう話を昔書きました。

まあ、Wikiのページがちぐはぐなチームや組織は、実際のところもちぐはぐなのです。

第1階層のカテゴリ整理

esaに「カテゴリ第1階層を整理するスレ」という記事を作り、そこで第1階層のカテゴリをどのようにするかを決めていきました。  f:id:mzp:20161117135825p:plain

esaにはカテゴリ移動機能があるので、どのようなカテゴリにするかを決めてしまえば、あとは楽です。

f:id:mzp:20161117135832p:plain

その他の整理

「その他」カテゴリの整理は、2段階に分けて行ないました。

  1. Qiita:teamのときに付与していたタグを元に、カテゴリを移動する
  2. 残った記事は1つずつ移動先を決める

この作業をWebインタフェースから行なうのは大変なので、esa-ruby gem を用いて記事を移動するスクリプトを書きました。

何度かAPIのリクエスト上限に達したり、大量の記事を更新するためトップページにあるRecently updatedが使い物にならなくなったりと大変でしたが、なんとか終わらせることができました。

今後にむけて

今後は、以下のような作業をしていきたいと考えています。


Misocaでは情報共有ツールを大事にするソフトウェアエンジニアを募集しています。

RubyWorld Conference 2016 参加レポート

こんにちは、Misoca 松江オフィスの日高 @hidakatsuya です。

2016年11月1日、島根県松江市に Misoca の開発拠点が誕生しました。現在、松江オフィスのスタッフは私一人で、オフィスづくりと開発と新しい仲間探しで、忙しくも楽しく過ごしている今日この頃です。一人で寂しいので皆さん遊びに来て下さい。

さて、11月3, 4日に、ここ島根県松江市で RubyWorld Conference 2016(以下 RWC)が開催されました。

2016.rubyworld-conf.org

それに合わせて、名古屋からは id:mzp@kokuyouwind、東京からは @kakutani が松江に集結するということで、 RWC 前日に Misoca 主催の RWC2016前夜にMisocaメンバーとご飯を食べよう というイベントを開催。今回はそのイベントと RWC の様子を中心に書きたいと思います。

前日(イベントの開催)

松江オフィスで3人の到着を待っていると、RWC のため県外から来ていた Ruby 方面の方々が来社されました。

f:id:hidakatsuya:20161107151104j:plain

ネットすら無い*1こんな状態でおもてなしもできず心苦しかったのですが、「何も無さ」をネタに色々と楽しくお話できて良かったです。

イベントについて

その後、イベント会場へ。イベントは、松江オフィスから 50m ほどのパーティ会場を貸し切って開催しました。1週間前の募集開始ということもあり、参加者が集まるか不安でしたが、定員の15名の方にご参加いただきました。感謝。

f:id:hidakatsuya:20161102195846j:plain

参加者のきむらしのぶさんに「最近流行りの機械学習を紹介してみる」というタイトルで発表いただいた時の様子です。最近購入されたというドローンの話と映像が面白かったです。

写真を撮り忘れてましたが、 RWC ウェルカムパーティーから駆けつけてくれた弊社技術フェロー @kakutani の締めの言葉でイベントは無事終了。

参加者の方々のご協力もあり、また地元松江からも6名の方にご参加いただき、私個人としては非常に楽しいイベントになりました。ご参加いただいた皆様にはこの場を借りてお礼申し上げます。

RubyWorld Conference 2016

f:id:hidakatsuya:20161103110844j:plain

RWC は今年で8回目の開催だそうです。私も 2010 年の RWC で発表させてもらったのですが、そういえば当時は2トラックで(しかも参加費無料!)、2012 年から現在の1トラックになったようです。個人的には2トラックぐらいある方が好みではありますが。

会場の様子

RWC の様子を何枚か貼っておきます。

f:id:hidakatsuya:20161103154925j:plain メイン会場

f:id:hidakatsuya:20161103111823j:plain 1F大ホール

f:id:hidakatsuya:20161103180832j:plain レセプション

セッションについて

最初はメイン会場に着席して聴いていましたが、1F大ホールでも中継されていることに気付いてからは、英語のセッション以外は 1F大ホールのテーブルに PC を広げて聴いていました。音声も映像もクリアで、なかなか快適でした。

RWC には毎年参加していますが、どちらかというとビジネス色の強いものや教育関連のセッションが多いことが RWC の特徴だと思います。今年も「A-3 電力比較サイト エネチェンジを支える技術」や「A-5-3 Rubyを使って顧客とともに成長していくビジネスモデル「ITお助け隊」の紹介」など、そういった内容のセッションがありました。

また、今年の特徴として、機械学習のセッションが充実していたと思います。「A-5-1 Ruby における機械学習のための環境整備の取り組み」では機械学習における Ruby の現状や今後どのように Ruby での機械学習の環境を整えていくかといった内容でとても興味深かったです。

セッションの中で個人的に印象に残っているのは、「A-5-4 小さな町で子供向けのプログラミング講座をはじめてみて」です。スピーカーの廣田さんが、ご自身の地元で子供たちを対象とした Ruby の勉強会を開催すべく奮闘した、というお話でした。私自身も、来月に「第3回リモートワーク勉強会」という勉強会を開催します。ただ、初めての幹事ということもあり、勉強会を開くことの大変さを痛感しているところだったので、非常に心に刺さるお話でした。

最後に

f:id:hidakatsuya:20161103192127j:plain 左から @kokuyouwind @hidakatsuya Matz id:mzp

Misoca 松江オフィスでは、私と一緒に働いてくれる仲間を募集しています。やることは Misoca の開発です。名古屋と松江でやることは変わりません。Misoca チームとして、ここ松江から、Misoca で世の中をシンプルにしませんか?興味のある方は、ぜひ下記 Wantedly からエントリーしてください!

www.wantedly.com

*1:今はネットも開通しもう少しいろいろ有ります

サーバわからないエンジニアがサーバレスでエントリーフォームをつくった件

こんにちは!
Misoca開発チームのめろたん(@renyamizuno_)です!

最近急に寒くなってきましたが、皆さんはいかがお過ごしでしょうか?僕はすこぶる不調です。

f:id:renya-mizuno:20161028103704j:plain

写真は新幹線内で撮った最高に不調な僕と、すこぶる元気な植物とのツーショットです。

最近あった面白いこととしては、少し前に学生時代の後輩達とキャンプに行ったのですが、買い出しのときの出来事で

これが最高にロックでパンクで面白かったです。
「えっ?なんすか?」みたいな顔でかごにそっとさつまいもを入れていたのも最高でした。

はい。

弊社は採用活動を活発に行っています。 その一環として、最近弊社ホームページのリクルートサイトを刷新しました!

recruit.misoca.jp

刷新前はWordPressの固定ページで作っていたのですが、刷新したものはS3に配置してホスティングしています。

しかしリクルートサイトにはエントリーフォームがあります。

刷新前はWordPressの問い合わせフォームのプラグインを活用してエントリーフォームをつくっていましたが、 S3だけではエントリーフォームを作ることは出来ませんでした。

そこで採用チームから何とかしてほしいと頼まれたのですが、Misocaではサーバサイドエンジニアが枯渇しているためたまたま手が空いていたサーバ全くわからないマンの僕が対応することになりました*1

サーバ全くわからないマンなので、最近良く聞くサーバレスっていうのを使えばサーバが不要*2だと聞いたので、やってみよう!ということでやってみました!

簡単な図にするとこんな感じになりました!

f:id:renya-mizuno:20161026155235p:plain

AWS Lambda

サーバレスというワードと一緒によく聞くLambda

aws.amazon.com

これを使えばサーバの管理をすること無く、任意のコードを実行できる!とのこと。

これにJS(Node.js)かPythonJavaでコードを記述できます。

今回は最近はフロントばっかやってたので慣れ親しんだJS(Node.js 4.3)でコードを書くことにしました。

Lambdaを作るときにBluePrintというLambdaの設定例がいくつか出てきます。

よくわからないので、HelloWorldがあるんじゃね?ってことで検索したところありました*3

f:id:renya-mizuno:20161026134946p:plain

ということで「hello-world」や他のBluePrintを参考にこう書くのかと雑に認識をしました。

コードを書き進めているときに「あああのパッケージほしいな」と思って入れようとしたのですが、Lambdaの編集画面からは入れれないのでローカルでLambdaで書いたコードをindex.jsにコピーして、その後npm install等で任意のパッケージを入れた後それらをzipでアップロードしないといけなくて、この時代に何故…という気持ちになりました。

API Gateway

Lambdaでコードを書いただけではPOSTされたデータを受け取れないので API Gatewayを使います。

aws.amazon.com

これを使うことで、入力されたデータをLambdaや他のサービスに渡すことができます。 API Gatewayの設定自体は特に苦労することもなくAWS Lambdaにつなぐことができました。

ですが一つ問題がありました。
エントリーフォームで添付した履歴書などのファイルが壊れてしまい、開くことができず辛い思いをしました。
Amazonさんに問い合わせたところ、バイナリデータの入力は対応中とのことでした。

なのでこれを回避するためにフロントでファイルをbase64エンコード*4し文字列でPOSTするようにしました。
そしてこれを、Lambda 内でデコードしてやれば壊れること無く扱うことができました。

Amazon SES

次に採用担当者にエントリーがあったことをメールで通知したいので Amazon SESを使ってメールを送信します。

aws.amazon.com

受け取ったリクエストを元にLambdaで成形した文章とかファイルをSESをつかって採用担当者のメールアドレスに送信!
といきたかったのですが、AWS SDKsendEmail でのファイル添付がわかりませんでした。
ドキュメントみても特に書いてなさそうです…。 Class: AWS.SES — AWS SDK for JavaScript

困りました。非常に。

ですがドキュメントをもう少し眺めてみると、メールをrawデータにしてsendRawEmailで送ればできそうでした。 Class: AWS.SES — AWS SDK for JavaScript

なのでnpmパッケージにmailcomposerというのがあるのでそれを使ってrawをつくります。

github.com

これを使うことで問題なくファイル添付もできました!

はまったポイント

フォームでファイルを添付してPOSTするにはformタグにenctype="multipart/form-data"とつけなければなりません。 こうするとmultipart/form-dataというデータがわたってきます。

これをパースしてやらないといけないのですがそんなライブラリはありませんでした。

仕方ないのでhttp requestにモックして、formidableというパッケージを使うことでパースすることができました。

github.com

Request.prototype.pause = function(){};

って言うコードが入っててすごく面白かったです。

ですが結果的にAPI Gatewayでファイルが壊れてしまうので無駄に時間を浪費して終わったということになって悲しかったです。

結果

実際に動いているのがこちら!

エントリーフォーム|Misoca採用情報

サーバレスの息吹を体感してみたい人は送信してみるといいと思います!おまけで弊社のオフィスを見学できる権利もついてきます!

ということで、サーバ全くわからないマンがサーバをレスしてエントリーフォームをつくった話でした。 Misocaでは新しい技術をどんどん取り入れています。

そんなMisocaではサーバサイドエンジニアを募集しています。
またサーバレスを活用したいエンジニアも募集しています。

recruit.misoca.jp

*1:ネタです。笑ってください

*2:ネタです。笑ってk(ry

*3:当方英語できないマンでもあるため、最初"hallo"と入力してて笑いの渦を巻き起こしました

*4:実際にはData URLにしてます

「prpr で GitHubのプルリクエスト運用を自動化する」というタイトルで発表してきました

こんにちは、島根県松江市在住の日高 @hidakatsuya です。趣味と言いながらサボっていたビリヤードを頑張ろうと、押入れからキュー(球を撞く棒)を出して手入れするところまではやりました。

さて、今回はイベントでの発表の報告です。

2016年9月24日に島根県松江市の松江テルサで開催された オープンソースカンファレンス 2016 Shimane にスタッフ・発表者として参加しました。

オープンソースカンファレンス Shimane は、松江での開催が今年で 9 回目だそうです。私自身、その半分以上に参加していると思いますが、今回初めてスタッフとして運営をお手伝いさせてもらいました。当日の会場の様子などは、近く公式レポートが公開されるとのことですので興味のある方は下記サイトをチェックしてみてください。

Category: OSC開催レポート

発表内容

今回の発表では prpr(ぷるぷる)というツールを紹介しました。

github.com

Misoca 開発チームでは、GitHub のプルリクエストを使って「WIP(作業中)→REVIEW(レビュー待ち)→マージ」のような流れで開発を行っています。プルリクエストの運用を続けていると、レビュー待ちにしたら Slack(チャットサービス)でレビューを依頼したり、全体のタスクを管理している Trello のカードを更新するなど、プルリクエストのステータスに応じて定型的に繰り返す作業が増えてきました。

prpr は、そういったプルリクエスト運用にまつわる定型作業を自動化するために、Misoca 開発チームの id:mzp が開発した bot です。GitHub のプルリクエストに反応します。

この prpr によって、プルリクエストの運用に伴なう繰り返し作業や定型的な作業を自動化したり、プルリクエストの機能を補完してより便利にすることができます。prpr の各機能はプラグインとして提供されていますので、運用スタイルに合わせて必要な機能を組み合わせて使うことができます。

例えば、 prpr-conflict_label はプルリクエストがコンフリクトした場合に、自動的に [CONFLICT] のような任意のラベルを追加して、コンフリクト状態を分かりやすくしてくれます。GitHub のデフォルトの表示だとちょっと分かりにくいですよね。

f:id:hidakatsuya:20161005030751p:plain

発表では、Misoca の開発フローとプルリクエスト運用を紹介し、prpr の機能(プラグイン)によってどのように運用の自動化を行なっているかを紹介しています。また、執筆時点で利用可能な prpr プラグインを全て紹介していますので、興味のある方はぜひスライドをご覧ください。

prpr を紹介しようと思った理由

私が Misoca に入社した 2015年10月の時点で、既に prpr は Misoca 開発チームの日々の活動を支えていました。Misoca に入社するまでは、GitHub やプルリクエストといえば、OSS の開発で使う程度だったので、 prpr によるプルリクエスト運用を知った時「面白いなー」とワクワクしたことを覚えています。それで、いつか勉強会などでカジュアルに発表する機会があれば、ぜひ紹介したいと思っていました。

そんな時 OSC Shimane にスタッフとして参加することになり、prpr は OSS ということもあり、ちょうど Misoca 松江拠点の紹介もしたいと思っていたため今回の発表に至りました。

もう少し詳しく知りたくなったら

prpr は非常に便利で楽しいので、興味を持った方はぜひ試していただければと思います。また、プラグインを作ることで簡単に prpr に機能を追加することもできます。そのあたり、もう少し詳しく知りたいという方は、GitHub に加えて、作者 id:mzp のブログも参考にすると良いと思います。

mzp.hatenablog.com

mzp.hatenablog.com

最後に

現在、Misoca 松江拠点始動に向けて準備を進めています。そんな Misoca 松江拠点では新しい仲間を募集しています。興味のある方は、ぜひ下記 Wantedly よりお問い合わせください!

Misocaの今昔話 - 4年前と今で変わった事

f:id:snowsunny:20160930105659j:plain

こんにちは、これが初めての投稿になります。フリーランスで仕事させて頂いておりますsnowsunny(@snowsunny1107)です、7月からMisoca開発チームにジョインしました。

今は発注機能のフロントエンド(React/Redux)を中心にお仕事をさせて頂いております。

そんな私ですが実は2012年に株式会社Misocaの前身であるスタンドファーム株式会社の時にも一度お世話になった事があり、社長の豊吉さんから聞いた話だと初めて人を雇ったのが自分だったと言うお話でした。

今回はそんな私がMisocaのオフィスや開発環境の昔と今について自分主観でご紹介してみたいと思います。

Misocaの昔と今

オフィスの違い

2012年2月

f:id:snowsunny:20160930083738p:plain

  • 場所は名古屋市中区大須にある豊吉さんの知人のガレージ。Misocaの聖地。
  • 広さは全体で8畳くらい。
  • お洒落な内装。
  • 作業スペースの隣には格好良いバイクが置いてありました。

入り口がシャッター式でそれをガラガラ開けて毎朝挨拶をしていたのが印象に残っています。大須に近かったので色々な飲食店があり、週に一度豊吉さん、共同創業者の松本さん、自分の3人でランチを食べに行っていたのを覚えています。(そのランチは毎回奢って貰っていましたー)

2016年9月現在

f:id:snowsunny:20160930105659j:plain

  • 場所は名古屋駅から徒歩5分!名古屋市中村区名駅にあるオフィスビル2階のワンフロア全て。
  • 広さ100畳以上の綺麗なオフィス!(Misocaがオフィスとして使っている所のみ)その隣には同じくらいの広さの弥生オフィスがあります。
  • さらに幾つかの会議室、セミナールーム、コメダ席、最近はコミュニティスペースが整備されて331カフェが出来ました。
  • ウォーターサーバー完備

f:id:snowsunny:20160608155630j:plain f:id:snowsunny:20160616124905j:plain f:id:snowsunny:20160930100300j:plain

※新オフィスの詳しい情報ついてはこちらの記事も是非ご覧下さい。

tech.misoca.jp

最初オフィスが名駅に移動したと聞いた時は「えっ名駅に!?凄い!」と感じ、初めて新オフィスに伺った時は昔と比べて桁違いの広さになっているオフィスを見て「おぉー…」と感慨深い物を感じました…(笑) オフィスのセキュリティにカードキーが採用されていた点も、昔との違いを強く感じました。

開発環境の違い

2012年2月

  • 一緒に働いていた方は豊吉さん、松本さん、自分の3人のみ。
  • タスク管理にはRedmineを使っていて、基本的に豊吉さんが作ってくれたチケットを自分が消化していくスタイルでお仕事をしていました。Misocaの開発自体はアジャイルソフトウェア開発(以下アジャイル開発)で行われていたと記憶しています、アジャイル開発関連の良い書籍を教えて貰った事もありました。
  • バージョン管理にはGitを使っていましたが、Gitに置き換えたばかりだったらしく豊吉さんがGitの本を買って「Git勉強するぞー」っと言っていた覚えがあります。
  • Railsはその時最新だったバージョン3系を使っていました。
  • チャットにはSkypeを使用していました。
  • 作業PCには用意して貰ったUbuntuを使って作業していました、松本さんはMac、豊吉さんはWindows上でVMを立ち上げUbuntuで作業をしていました。

アットホームな雰囲気で、3ヶ月間と短い間でしたがRailsLinuxを勉強し始めたばかりで、いわゆる黒い画面にそこはかとない恐怖を感じていた状態から、RailsMVCの流れを一通り理解する所まで成長させて貰いました。 この場を借りて改めてお礼をさせて下さい、本当にありがとうございました!

2016年9月現在

  • 一緒に働いている方はエンジニアだけで10名程、その内3名の方は基本リモートで参加されています。エンジニア以外のサポートの方やマーケティングの方を含めると15名程の人達がMisocaが働いています。
  • タスク管理にはTrelloを使用していて、アジャイル開発でMisocaのサービス開発を行っています。現在私が参加しているチームではスクラムを使ったアジャイル開発を実践しています。
  • バージョン管理にはGitを使用、リポジトリの管理にはGithubを使用しています。
  • Railsは最新のバージョン5!
  • チャットにはSlackを使用しています。
  • 作業PCには自分も含め殆どの方がMacを使用されています。自分はMacBookAirと支給されたディスプレイを使ってデュアルディスプレイで作業しています。

一番変わったと感じた点は一緒に働いている方の人数ですね。さらに増えた人達も色々な分野を精通している方が多く、出来るオーラを感じる人ばかりで、とても頼もしくいつもお世話になっております。

他には2012年から行われていたアジャイル開発の手法がより洗練され、今回ジョインした後も日々自分達に合った開発手法にドンドン最適化されていく文化はとても素晴らしいなーと感じています。

またMisocaではリモートワークの自由度がとても高く、台風が来る日や、子供の用事等がある時に特に事前申請無しでリモートワークをする事が出来ます。実際1名の方は完全リモートで、Rubyの聖地である松江市からMisocaに携わっています。 さらに仕事をする時間も融通が効くので、とても仕事がし易い環境が整っていると思います。

まとめ

オフィスはとても広くなり会議室や休憩出来るスペースまで増えました。開発環境も人が増え、ツールやルールが整備された事により、格段に働き易くなっていると感じます。

これもひとえに豊吉さんと、松本さんの手腕が成せる技なのかなーと、改めて尊敬の念を感じている日々です。

簡単にMisocaの昔と今についてお話してみましたがいかがだったでしょうか? 少しでもMisocaに興味を持って頂けたなら幸いです。

さて、この様に日々着実に成長を続けているMisocaですが、今一緒に働いて頂ける方を募集中です! 詳しくは下記の求人情報をご覧下さい、皆様のご応募を心待ちにしております。