レガシーなフロントエンドコードを整理するためにどう立ち向かったか

2エントリ連続でこんにちは、@mugi_unoです。

名古屋には台湾ラーメンイタリアンという名物があるそうです。

富山県民の私には理解が追いつきませんでした。


フロントエンドでの金額計算処理

さて、Misocaは請求書作成サービスなので、金額計算処理が欠かせません。

フロントエンドも例外ではなく、消費税額や合計額を算出するロジックが存在します。

機能変更が必要になった!!

諸事情により、そのロジックに変更を加える必要が生じました。

長くプロダクトを支えてくれていた存在ですが、内容的にはいわゆるレガシーなコードで、たびたび開発者ミーティングでも課題として挙げられることがありました。

git log で確認してみると、該当コードに対しての機能的な変更は2015年の冬から行われていません。

f:id:mugi1:20180907094553p:plain:w400

何が問題だったのか?

DOM操作と計算ロジックの混在

Misocaでは、新しくコードを書く際はVueやReactを使っていますが、まだまだjQueryで書かれたコードも残っています。今回の計算ロジックはそれが顕著で、100%jQueryで記述されていました。

参考としてこちらの図をご覧ください。

(画質は落としています)

f:id:mugi1:20180913131517p:plain:w100

これは、該当コードから一部を抜粋し、

  • ■緑 : DOMからの読み込み
  • ■黄 : 計算処理
  • ■赤 : DOMへの書き込み

でざっくりと色分けしたものです。カラフルで綺麗ですね!

さて、これはつまり、画面で見えている要素と計算処理が密接に絡み合ってる状態であることを示します。

今回の機能変更では、この中の 「■黄 : 計算処理」の変更が必要ですが、このまま挑んでも

  • 「計算処理を変えたつもりが、他の箇所でのDOMからの読み込みも変わっちゃった!」
  • 「DOM触ったら、全然違う場所のコードの計算処理も意図しない動きになっちゃった!」
  • 「つらいです」

となるのが容易に予想できます。

変更時の影響箇所が読めない

内部の複雑さだけではなく、該当コードはグローバルに定義されているため、あらゆるところから自由にコールされています。かつ、参考となる資料も特に存在していないため、変更時にどこまで影響が及ぶのかがわからない状態でした。

これによる最大の問題点は、コードを触るのが怖くなるという心理状態になることです。

修正をしても「関係のないところには影響がないです!」と誰も言うことができません。仮にPRを出したとしても、レビューする側は「ウッ...」となります。

まずはリファクタリングだ!

色々と大変なことはわかりましたが、嘆いてばかりでは何も改善しません。

もともとこのコードが作られた時期を考えると、jQuery全盛期であり、React/Vueといったものが世の中で活躍し始めるよりもずっと前の話ですので、むしろ今まで僕たちのプロダクトを支えてくれてありがとう、と言うべきなのかもしれません。

感謝の気持ちを込めて、リファクタリングを行うことにしました。

コードを知る

すぐにコードを書き直していきたくなるところですが、グッとこらえ、まずは誰が見ても分かる状態にコードを可視化することにしました。

というわけで、書いたのはこんな雰囲気の資料です。 draw.io で書きました。) f:id:mugi1:20180910163646p:plain

  • 緑色が読み込み専用のDOM
  • 赤色が書き込みも行うDOM
  • 線がデータの流れ

です。

資料書くとか無駄じゃない?という意見もあるかもしれませんが、

  • ある値が、一時的なものなのか、最終的な計算結果なのか
  • あるDOMを変えた場合、どこの書き込みに影響を及ぼすのか

を目に見える形で整理することで、コードを理解出来ると共に影響範囲が自分の中で整理できますし、リファクタリングする際にも様々な戦略を考えられるようになります。

また、レビューをしてもらう際にも、自信を持って「影響箇所はここです!」と言えるようになりますね。

リファクタリングの対象範囲を決める

一言にリファクタリングといっても、やみくもに始めると際限なく直してしまうので、 どこまでやるのか?も決めたほうがよいでしょう。

今回の目標は以下に設定しました

  1. 計算に必要なデータが、1箇所に集約できている
  2. DOMの変更を行う箇所が、1箇所に集約できている
  3. 計算処理が、DOM操作を伴わないJSの単一のfunctionになっている。

逆に、以下はやらないことにしました。

  • グローバル依存からの脱却
  • React/Vueといったフレームワークへの書き換え

「本来やりたい機能追加のためには、最低限ここまでやれば大丈夫だろう」というところまでを目標にしました。

怖い修正をする際には、小さく刻んでいくのも大事ですよね。

ちなみにこういった選択を出来たのは、最初にコードを可視化して整理したことで「どうやら小さくリファクタリングできそうだぞ?」ということが明確にわかったから、というのも大いにあります。

整理をしていなかったら、「全部Vueで書き換えるんじゃ〜〜、ウワァアア...」という未来が待っていたかもしれません。

テストコードを追加する

ここまでの整理をしても修正ミスをしてデグレを引き起こすのが人間です。

そんな時僕たちに自信をくれるのがテストコードです。Railsのfeature specによってある程度はカバーされていますが、いくつかの問題がありました。

  • 実行に時間がかかる(1分とか)
  • サービスのユーザ体験を担保しているものなので、網羅性は保証できない
  • リファクタリングした以外の箇所の問題とぶつかると永遠にハマる

特に実行時間がネックで、リファクタリング中は何十回・何百回と叩くことが予想されます。 そのたびに待たされていると作業ペースが落ちてしまうので、フロントエンドだけを対象としたテストコードを用意することにしました。

既存コードのInput/Outputのみにフォーカスしたテストを書く

さて、DOMにべったり依存しているコードですので、テストを書くと言っても一工夫必要です。

リファクタリングした結果、既存の挙動を壊していないことを担保したいので、

  • 該当のグローバル関数を実行する前のDOMをInput
  • 該当のグローバル関数を実行した後のDOMをOutput(期待結果)

として、ブラックボックステストを追加しました。

テストコードの例

影響のあるDOMのみを含む、最小限のテスト用テンプレートをpugで用意します。(先に資料化したものが役立ちました)

doctype html
html
  body
    //- Input
    input(
      name='quantity'
      value='1,000'
    )
    input(
      type='radio'
      name='tax_rate'
      checked
      value='8'
    )

    //- Output
    #total
    #sub-total
    #tax

...

テンプレートをロードして計算を行い、結果を確認します。

describe('計算処理', () => {
  beforeEach(() => {
    document.body.innerHTML = require('./test.pug')();
  });

  it('〜の計算結果が反映される', () => {
    window.run(); // リファクタリング対象のグローバル関数

    expect($('#total').text()).to.eq('10,800円');
    expect($('#sub-total').text()).to.eq('10,000円');
    expect($('#tax').text()).to.eq('税別 800円');
  });

...

最終的には、おおよそ200件ほどのexampleを書きました。

リファクタリング後に捨ててしまうことも視野に入れ、テストコードの綺麗さよりも、カバー範囲の広いテストを1件でも多く、時間をかけずに書くことに注力しました。

f:id:mugi1:20180911100127p:plain

テスト自体も3秒程度で終了します。いい感じですね!

小さく整理していく

ようやく準備が整いました。これで自信を持ってリファクタリングを始めることが出来ます。

リファクタリングする際は可能な範囲で小さい単位に区切りながら進めます。レビューする側の負担を軽減するという意味もありますし、そもそもリファクタリングの方向性が間違ってないか?というのを適宜確認できる効果もあります。

f:id:mugi1:20180912091111p:plain

ここまでやると、ある程度処理が分離された状態になってきます。

最後に、全体を通した整理を行い、ついでに不要な処理の削除やモジュール分割といったプラスαのリファクタリングを行いました。

f:id:mugi1:20180912092238p:plain

リファクタリングした結果どうなったか

リファクタリング前のコード同様に、 リファクタリング後のコードを抜粋してカラーリングしたものがこちらになります。

  • DOMからの取得処理

f:id:mugi1:20180913131930p:plain

  • DOMへの反映処理

f:id:mugi1:20180913131953p:plain

  • 計算処理

f:id:mugi1:20180913132012p:plain

  • グローバル関数本体

f:id:mugi1:20180913131837p:plain:w200

どこでなにをやってるかが明確で、綺麗になりましたね!

まとめ

今回はレガシーコードをリファクタリングしてみた話でした。

こういう作業には少なからず恐怖がつきまとうので、いかにしてそれを払拭しながら小さく進めていくかが重要だな〜と実感しました。

ただ、今回のリファクタリングである程度は綺麗になりましたが、正直なところ、まだまだ理想の状態には程遠いです。

と、いうわけで..

採用

Misocaでは、リファクタリングも楽しめるエンジニアを募集しています!

開発合宿の成果を新機能としてリリースしました!

こんにちは、@mugi_unoです。4歳の娘にトランプの神経衰弱で勝てません。

新機能をリリースしました 🎉

さて、先日Misocaに新しい機能がリリースされました。

www.misoca.jp

f:id:mugi1:20180828093504g:plain

国税庁のサイトで、法人の基本3情報(名称・所在地・法人番号)というものが公開されており*1、そのデータをもとに文書の送付先などを自動入力できるという機能です。

合宿成果からのリリース

この機能は、7月に行われた開発合宿*2での成果物がベースになっています。 今回は、合宿終了後からリリースまでどういった作業をMisoca内で行ったのかを中心にご紹介します。

合宿で作ったもの

Misocaでは以前から国税庁のデータを取得し保持していたものの、有効活用できていない状態になっていました。

そこで、私のいた合宿のチームでは「これ使ってなんかやってみよう!」というのをテーマに取り組みました。

(合宿時のチームメンバーです。Team 神)
f:id:mugi1:20180827110235j:plain

というわけで、以下を作ってみることにしました。

  • 請求書を作るときに、法人情報から検索して入力補完できるようにする。
  • 曖昧な入力でも検索結果がヒットするようにする。

3日間で概ね形になり、請求書だけではなく、見積書や納品書でも使えるようなプロトタイプが完成しました。

技術的には

  • 検索 / ElasticSearch
  • フロントエンド / Vue.js

を使っています。

リリース!...はまだ厳しい!

合宿最後の成果発表でもわりと評判がよかったので、このままプロダクトにリリースしよう!!

...と言いたいところですが、現実はそう甘くなく、ガッと作ったので色々と課題が残った状態でした。

さすがにこのまま使っていただくわけにはいかないので、プロジェクトとして、ちゃんとしたリリースに向けて動き出したくなりました。

リリースに向けてやったこと

ロードマップ会議で提案

Misocaでは週に一度、何を優先して着手していくかを整理するための、ロードマップ会議*3と言われる場があります。

これは誰でも参加でき、提案も自由にできます。

ということで、「合宿で作ったやつがいい感じなので、せっかくなのでブラッシュアップしてリリースしましょう!」と提案し、リリースに向けて動き出すことになりました。

(実際の提案時の内容)
f:id:mugi1:20180827151552p:plain

インセプションデッキをつくる&タスクの洗い出し

まずはメンバーの認識を揃えるため、インセプションデッキを書きます。

  • なんのためにやるのか?
  • どのぐらい期間をかけるのか?
  • リスクはなんだろう?

といったことをここで話し、必要となるタスクの洗い出しも行いました。

結果的には、ロードマップ会議で提案した時点では「数日程度でいけるでしょ〜」と思っていたのですが、実際にはやることがもう少し多く、1週間〜2週間程度は必要になりそうなことがわかりました。

UIの見直し

合宿では、とにかく機能が使えること自体を優先したため、UIには力を入れていませんでした。 改めて、複数人で「より使いやすくするにはどうしたらいいだろう?」という話をして、見た目の修正を行いました。

たとえば、以下のような変更を加えています。

検索導線

Before

  • 導線が常に見えていると、使わない人からするとノイズになる

f:id:mugi1:20180827145846p:plain

After

  • 使いたいときにのみ現れるようにする

f:id:mugi1:20180827153402p:plain

検索入力・検索結果の表示

Before

  • 「法人情報から検索」だと、データの出元がわからなくて使う時に不安になる
  • 会社名や都道府県など、何を使って検索できるのかがわからない

f:id:mugi1:20180827154234p:plain

After

  • タイトルの変更、補足メッセージやリンクを追加する

f:id:mugi1:20180827153506p:plain

検索結果から文書への反映

Before

  • 選択した法人情報が文書のどこに適用されるのかがわからない
  • 一部だけ編集する必要があることも多そう

After (新規に追加)

  • 文書へ適用する前にダイアログ上で確認を挟み、そこで編集もできるようにする

f:id:mugi1:20180827154739p:plain

バックエンド側の修正

UIだけではなく、バックエンド側も見直しました。

蓄積している法人情報はおおよそ500万件存在し、すでに利用されていないデータも混ざっている状態です。

色々整理すると、以下のような手直しが必要でした。

  • 不要なデータがElasticSearchにインデックスされないようにする
  • パフォーマンスが出るか確認し、適宜チューニングする
  • 都道府県名で柔軟に絞りこめるようにする (東京都 / 東京 などで絞り込む)
  • どういったフローでElasticSearchのIndexを最新化していくか考える

泥臭い作業も必要になりましたが、コツコツと1つずつ潰していきます。

加えて、今後のメンテナンスのために、書けていなかったspecも一通り書き足しました。

リリース 🎉

他にも細々した修正に加え、ヘルプなども最新化し、無事に新機能としてリリースされました。期間的には「やるぞ!」と決めてからはおおむね1週間強程度で大半の作業をやりました。なかなかのスピード感ですね。

まとめ

開発合宿の成果が実際にリリースされて嬉しい限りです。

これを繰り返していって合宿の価値を上げていって、最後はハワイでの開発バケーションを目指したいと思います!!


採用

Misocaではバリバリ新機能を作っていきたいエンジニアを募集しています!

LIFFアプリ作ってみました

Misoca開発チームのnao(@enda531)です。

涼しくなってきたかなと思ったら急に暑くなったりしてつらいですね。
開発合宿で食べたかき氷がまた食べたくなってきました。

f:id:endash:20180823083430j:plain:w400

ところでみなさんLIFF(LINE Front-end Framework)アプリ作っていますか?
今回はMisocaの開発合宿でLIFFアプリを実験的に作ってみたので、LIFFアプリについて紹介したいと思います。*1

tech.misoca.jp

LIFFについて

LIFFはLINE内で動作するウェブアプリのプラットフォームです。
LINE内でウェブアプリを起動でき、ウェブアプリからトークルームにテキストや画像を送信することができます。
LINEだけで操作を完結できるため、別アプリを起動する必要がなくシンプルな操作で済み、UXの改善に役立ちます。

詳しく使い方は公式ドキュメントにまとまっています。
またLINE Engineering BlogでもLIFFの使い方がまとめられています。

作成したアプリ

開発合宿では、Misocaで作った請求書をグループトークに直接共有できるアプリを作成しました。
アプリの流れとしては以下のような感じです。

  1. LINEのトークルームからウェブアプリを起動
  2. ウェブアプリ上に請求書一覧を表示
  3. 送信したい請求書の情報をMisoca APIで取得し、LINE Messaging APIで送信
  4. トークルームに請求書のサムネイルと請求書へのリンクがついたメッセージが投稿される

f:id:endash:20180823165427p:plain:w500

f:id:endash:20180823083354p:plain:w400

最終的には、こんな感じのアプリになりました。

トークルームからウェブアプリを起動する

LIFFアプリを起動するには line://app/xxxxxx のようなURIを開いてもらう必要がありますが、 毎回URIを貼るのはつらいので、今回のアプリでは「請求」に反応してBotがリンク付きのメッセージをトークルームに投げるようにしました。

f:id:endash:20180823084156p:plain:w300

こんな感じで「青くて四角いヤツ」*2がリンク付きのメッセージを投稿してくれます。

請求書一覧画面

請求書の一覧を取得して表示しています。

「この請求書を送る」ボタンを押すとモーダルが表示され請求書の詳細がされ、「送る」を押すと請求書をトークルーム内に送ります。

フロントはVue.jsで実装していて、簡単なページング機能をつけました。

f:id:endash:20180823085356p:plainf:id:endash:20180823085623p:plain

請求書の送信

トークルームに大きな画像を直接送ることができないので、テンプレートメッセージ を使用してトークルーム内ではサムネイル画像を表示し、詳細を知りたい場合にはWebへ飛ぶとようにしました。

f:id:endash:20180823090806p:plain:w400

実際のテンプレートのメッセージ送信方法こんな感じになります。

await liff.sendMessages([{
  type: 'template',
  altText: '請求書が届いています',
  template: {
    type: 'buttons',
    thumbnailImageUrl: thumbnail_url,
    imageAspectRatio: 'rectangle',
    imageSize: 'contain',
    title: '請求書',
    text: '請求書になります',
    actions: [
      {
        type: 'uri',
        label: 'Webで詳細を見る',
        uri: url
      }
    ]
  }
}]);

やってみた感想

アプリの使い勝手が良くなりそう

今までだとLINEやWebブラウザを行き来する必要があったのが、LINE内だけで操作が完結でき、メッセージの送信までやってくれるので操作が楽になるのがとても良いと思いました。

LINEの機能を使うのが楽

LIFF SDKが用意されているので、LIFFアプリの登録さえしてしてしまえば、トークルームへのメッセージ送信やユーザ情報の取得等は簡単にできるので簡単に始めることができました。

デバッグが難しい

LIFFアプリとして起動しないとLIFF SDKが動作しないので、メッセージ送信等を含む動作の確認がアプリをデプロイしないと確認できないので、動作しない場合等に原因を見つけるのが大変でした。
また、LIFFアプリからだとコンソールが見えないので、ひたすらトークルームにデバッグメッセージを流して確認しました。

f:id:endash:20180823093009p:plain:w400

情報がまだまだ少ない

リリースされてから日が経っていないので、まだ情報が少なく参考になる情報がなくデバッグ方法も含めて完全に手探り状態でした。*3
ただ公式のドキュメントが充実しているので基本的なところは問題ないと思います。

まとめ

  • ユーザ体験が良いアプリを作ることができそう
  • 手軽にアプリを作ることができる
  • まだリリースしてから日が経っていないので情報はあまりない

採用

Misocaでは新しい技術に興味があるエンジニアを募集しています!

*1:実験的に作っただけなのでリリースはしていません

*2:MisocaのLINEスタンプのキャラクターです。https://www.misoca.jp/blog/line-stamp1

*3:この手探り感も楽しい

Misocaに必要なことは全て受入プロジェクトで学んだ

こんにちは、 thara aka @zetta1985 です。
7月からMisocaに入社し、現在はRuby on Railsを中心に触っています。
Railsを仕事で使うのは初めてですし、採用面接のペアプログラミングではPythonを使いましたが、今のところなんとかなっています。

自分は入社後1ヶ月間 受入プロジェクト に配属され、そこでMisoca流の仕事の進め方を会得することになりました。 今回は、その受け入れプロジェクトという取り組みのご紹介と、実際に配属された上での感想を述べたいと思います。*1

受入プロジェクトとは

今回の受入プロジェクトでは、入社した人と受入担当の2人が配属され、1ヶ月間同じ課題に取り組みました。
その課題は、普段から開発チームが受入プロジェクトで取り組むのにふさわしいタスクとして日々積み重ねていたものの一つです。

f:id:zetta1985:20180815175114p:plain

具体的にどのようなタスクに取り組んだかはここで明らかにすることはできないのですが、以下のような特徴を持っていました。

  • 実装難易度が低い
  • UIに影響を与えない(見た目の変更がない)
  • DBマイグレーションが必要
  • データマイグレーションが必要
  • 運用担当との調整が必要

1ヶ月という短い間に取り組む課題として、タスクの粒度もリリースまでに必要とするプロセスも多様的であり、自分にとっても最初に取り組むタスクとしてちょうどよいものでした。

なお、自分は名古屋本社勤務で、受入担当の方はフルリモート勤務でした。

受入プロジェクトの進め方

プロジェクト開始直後は、受入プロジェクトの目的や受入タスクの全体像の把握、タスクや調整が必要なことの棚卸しを行いました。 このとき、受入タスクの解決すべき課題を理解することも兼ねて、既存プロダクトの機能をコードベースと照らし合わせながら説明を受けたり開発上のTipsなどを教えてもらったりなどしました。

プランニング後は、プランニングであげたタスクをベースに、毎日の朝会と振り返りとともに日々の作業を進めていきました。朝会や振り返りなどはzoomで画面共有しながら行いました。

朝会と振り返り

受入プロジェクトの朝会は、毎朝決まった時間に実施され、今日着手するタスクの確認などを行いました。 geekbotに回答した結果をベースに行われるので、すぐに終わります。 タスク以外の会社や組織/規定に関するちょっとした質問も、すぐに答えが出るようであれば、その場で答えてもらえました。 また、毎日17時ぐらいに振り返りを行い、タスクの進捗確認などをしました。 一日のタスクの進捗状況を見て、タスクを分割したり統合したりして、タスクの粒度を調整していました。

プロジェクト専用 channel

日中の受入プロジェクトに関するやりとりは、専用のSlack channel*2でやりとりしました。 先程のgeekbotに回答した結果がこのchannelに通知されるほか、PRレビューの依頼やタスク進捗上の質問、ペアプロやペアオペの依頼など、基本的にこのchannelをベースにプロジェクトが進行していきます。 テキストベースでは伝えづらいことは、このchannelにzoomのURLを貼りつけて口頭で伝えたりもしました。

このchannelでは入社後の受入タスク以外のイベントも展開されていたので、とりあえずここを見れば予定がわかるというのは、まだMisocaでの各ツールの使い方が確立してない状況だとありがたかったです。

f:id:zetta1985:20180816174357p:plain

*3

上の画像に含まれているイベント以外にも、試しにリモートをやってみたりMisocaのシステムアーキテクチャの概要を説明してもらったりと、新しくジョインした人向けの細かい取り組みがありました。

感想

今まで何回か転職してきましたが、ここまでしっかり受入してくれる会社は初めてでした。 プロジェクトのライフサイクルや調整が必要なDB/データマイグレーション含むリリースを早期に経験できたのは良かったと思います。 受入用のタスクを日々確保しておく、というのは目からウロコでした。*4

毎日朝夕と定期的に受入担当の方とリモートとはいえ直接話せる機会があったのは、組織に慣れていない身からするとすごく安心感がありました。 リモートでやり取りしたか否かはあまり問題ではなかったと思います。むしろ、リモートの方が抱えている問題にフォーカスできる気がしました。

自分が今までしっかりとした受け入れをされた経験がないからか、周りのメンバーがプロジェクトの枠を超えてバリバリとバリューを出していく中で、自分は受け入れタスクのみにフォーカスしており他の人に比べてバリューを出せてないことに後ろめたさを感じることもありました。しかし、PRレビューしたり esa.io 上のドキュメントを修正したりなど間接的にもチームに貢献することができましたし、チームとしてのやり方を把握した上で他のメンバーと協調してバリュー出すべきなので、これで良かったと思います。

総評

総評として、この受入プロジェクトは非常に良かったです。 ペアプロ/ペアオペでMisocaのやり方を身につけられましたし、毎日の朝会/振り返りで日々の疑問と不安を解消できました。
Misocaでよりバリューを出していくことを決意させてくれましたし、これからも受入プロジェクトという取り組みがさらに良くなっていくだろうことを感じました。

Misocaには、リモートワーク経験がない人でもRails経験がない人でもしっかりと受け入れてくれる土壌があります。
過去の経験ではなく、これから何を成し遂げていくかにフォーカスしたいエンジニアを募集しています。

recruit.misoca.jp

*1:Misocaは、プロセスやルールを組織やメンバーの成長または対象や状況によって、ドラスティックに変更していく文化があります。このエントリで言及したやりかたも、あくまでこのタイミングかつ対象が thara であることを背景としてあります

*2:このようなプロジェクト専用チャンネルは、受入プロジェクト以外のプロジェクトでも採用されています

*3:channelの人数が0なのはすでにアーカイブされているからです。当時はpublicだったので10人ぐらいはchannelに入って様子見てくれていたと思います

*4:自分が知らなかっただけで当たり前なのかもしれませんが

オフィス拡張パック適用しました!

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

最近の弊社はゴリラが流行っています。*1

結果ステッカーが爆誕して、バナナと交換されています。*2

「ゴリラ」の背景を知らないメンバーは完全に困惑しています。

楽しいですね。

はい。

そんなMisocaでは人が増えてオフィスが手狭になってきたので、オフィスの拡張を行いました!!!!!*3

🎉🎉🥁ドンドン🥁🎺パフパフ🎺🎉🎉

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

写真の左ほうが拡張されたところになります!

今のオフィスに引っ越したのが2年前だそうです。その時にの記事と見比べてみると広くなっているのがわかるかなーと思います!

tech.misoca.jp

ということで、オフィスのアップデートについて少し紹介しようかなーと思います!

個室の追加

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

コメダ席の左右に個室が増えました!!!

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

中に誰がいるかわからないという問題があって、予期せぬ出会いが複数回発生してました。*4
なので、紙を貼って使っているかどうか分かるようにしました!
貼ってある紙を裏返すと「空き」から「使用中」となります。アナログで味わい深いですね!

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

中はこんな感じです!

以前紹介した「i-Cave」*5と比べると前の囲いが無いのですが、高級になりましたね!

座り心地は良かったです。

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

コンセントも完備されていてUSBの充電ポートもあってすごいです。

「i-Cave」はどこに行ったかというと

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

拡張された執務エリアの端に移動しました。

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

「i-Cave」の椅子がアップグレードされてました!

新しい部屋

また新しい部屋が増えました!

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

もう一つのコメダ席がこっちに移動してきました!

扉がついたので、簡単なミーティングとかを行う時にさっと入れて周りの音とかをそこまで気にしなくても良くなりました!!

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

面白いところとしては

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

鍵が外についていることですね。

この鍵が外についている部屋の名前をどうするか考えているのですが、「天の川(物理)」「ドブ川(物理)」「ウホ川」*6「隔離コメダ席」「タコ部屋」「ゴリラの檻」など様々な案が出ています。

僕は「ゴリラの檻」推しですね。

まとめ

Misocaでは名古屋オフィスが広くなったため席がめっちゃ空いています。
なので空いている席に座りたい人、「ゴリラの檻」に入りたい人を募集しています!

*1:流行っているというか一部では完全に定着してしまっていて、ゴリラがあって当たり前になっています。

*2:仮想バナナと交換されています。

*3:拡張したけど、最近の名古屋は猛暑で出社する人が少ないです!

*4:社長がくつろいでいるところに出くわしたり、社長が仕事しているところに出くわしたりしました。

*5:i-Cave については こちらで!

*6:弊社の会議室には川の名前が付いているためそれを踏襲したものですね。

青空(開発合宿 3日目)

今日は快晴で、きれいな青空が広がっています。

3日間あった開発合宿も、いよいよゴールが近づいてきました。

f:id:kokuyouwind:20180720075727j:plain:w300

というわけで、開発合宿3日目、最終日です。

2日目の記事はこちら。

tech.misoca.jp

今日は午前中に開発を仕上げて、午後に成果発表会をして帰途につくというスケジュールです。

引き続き、リアルタイムで更新していきたいと思います。


(7:00 @kokuyouwind)

みなさん ! おはようございまーっす♪

今日も一日、元気いっぱいがんばろー ! #黒曜bot


(8:55 @corocn)

めっちゃ天気良くて、朝食会場から対岸の渥美半島が見える!

大根おろしとなめ茸和えると美味しいですよね。


(9:10 @kokuyouwind)

チェックアウト準備を済ませて会議室に来ました。

まだ全員揃っていないですが、最終日の開発スタート。

f:id:kokuyouwind:20180720091442j:plain:w300

13:30からの成果発表会に向けてラストスパートです。


(10:30 @mugi_uno)

@corocn: pushしたので最新取り込んでくださいよ〜
@mugi: NoMethodErrorって出てますよ
@corocn: あ、はい。&をつけてください
@mugi: バグじゃん!!

f:id:mugi1:20180720103014p:plain:w300

果たして午後の発表の結果やいかに...!!!


(10:35 merotan)

いやあーーーーーー

LIFF難しかったけど完成したんで完成ですね。

外も綺麗なんで完成ですよ

f:id:renya-mizuno:20180720103909j:plain:w300


(10:42 こまたつ)

できた!!!1できました!!!!!!!!


(11:00 @kokuyouwind)

Heroku USリージョンで立ち上げててレイテンシが結構あったので、このあいだ東京に来たAWS Fargate使って立ち上げようと試みています。

が、設定項目多くて難しい… ダメそう…


(11:30 @kokuyouwind)

Fargateで起動はできたんですが、HTTPSの設定とかDNSの設定とか考えるとどう考えても間に合わないので諦めました。

イヤッッホォォォオオォオウ!Heroku最高ー!!


(12:00 @corocn)

完成したので実質優勝


(12:15 @kokuyouwind)

他のメンバーはお弁当ですが、自分とmizukmbは外にご飯を食べに来ました。

f:id:kokuyouwind:20180720121810j:plain:w300

サイコロステーキランチ、優勝です。

f:id:kokuyouwind:20180720121837j:plain:w300


(13:11 oosawatechnica)

1時半からついに成果発表会です!Misoca及び、弥生に発表の様子が生配信されます。 本当はブログ閲覧者の皆さんにもお見せしたいけど、それは厳しいのでチームと発表内容を共有しますね!

開発合宿チーム紹介(および発表順)

1:Team 神

f:id:oosawatechnica:20180720131312j:plain:w300

チーム名由来

神がいるから

チームメンバー

開発テーマタイトル

取引先の入力簡単にするよ

開発内容とかいきごみとか

請求書作る時とか、請求先の名前とか住所とかの入力するのめんどくさくないですか?私はめんどくさいです。

ところで、国税庁が法人の名前とか住所とかって全部公開してるんですよね。 (https://www.houjin-bangou.nta.go.jp/download/

合宿の神は閃いた、富山の民よ、これで入力支援機能を作るのじゃ...!

2:シュッとしたやつ作るぞチーム

f:id:oosawatechnica:20180720131346j:plain:w300

チーム名由来

いい感じにシュッとしたやつ作る

チームメンバー

開発テーマタイトル

OCRで名刺をディープラーニングしてバーン

開発内容とかいきごみとか

TesseractというオープンソースのOCRを使って名刺や請求書に書かれた請求先情報を読み込み、取引先として登録できるようにする機能(いい感じにシュッとするやつ)を作成します

3:黄緑㌠

f:id:oosawatechnica:20180720131413j:plain:w300

チーム名由来

ちひろ LINEのアイコンが黄緑色なので

チームメンバー

開発テーマタイトル

LIFFアプリ

開発内容とかいきごみとか

黄緑㌠では、2018年6月6日に発表されたばかりのLINE Front-end Framework(LIFF)を使ってアプリを開発しました。 LINE内から離れることなく、グループトークに請求書を直接共有することができるようになっています。


(14:25 merotan)

くぅ~疲れましたw これにて完結です!

f:id:renya-mizuno:20180720142648p:plain:w300

ぼくのコミットがクソ


(14:45 @kokuyouwind)

成果発表会も終わり、これから名古屋に帰ります。

3日間お世話になった明山荘さんともお別れです。

f:id:kokuyouwind:20180720144904j:plain:w300

改めてまとめ記事を書きたいと思いますが、実況としてはここで一段落です。

お疲れ様でした!

鳥の詩(開発合宿 2日目)

近くの公園に行ったらカラスがいました。 多分そらだと思います。(雑なタイトル回収)

f:id:kokuyouwind:20180718224845j:plain:w300

というわけで、開発合宿2日目です。

1日目の記事はこちら。

tech.misoca.jp

昨日に引き続き、今日もリアルタイムで更新していきたいと思います。


(6:00 @corocn)

おはようございます!

と言いつつ朝までぐっすりしました。 私はもうおじいちゃんなので毎朝5時半に起きてます。

朝風呂最高だったので、今日も1日頑張れるゾイ!


(7:00 @kokuyouwind)

みなさん ! おはようございまーっす♪

今日も一日、元気いっぱいがんばろー ! #黒曜bot


(7:30 id:mizukmb)

おはようございます。

起きたらみんな朝食バイキングに行ってて部屋に誰もいませんでした。


(8:20 @mugi_uno)

合宿神の朝は早い

f:id:mugi1:20180719082750j:plain:w300


(8:52 @oosawatechnica)

今日の午前中はどうしても出社してやらなくてはならない仕事があったので合宿神よりも先に起きて名古屋に戻りました。 すると私の机の上にこれが…

f:id:oosawatechnica:20180719085442j:plain:w300

@mzpはもういないんだなあ…


(9:10 @kokuyouwind)

開発メンバーが全員会議室に揃いました。

2日目の開発開始です!

各チームのテーマはこちら。

f:id:kokuyouwind:20180718123403j:plain:w300


(9:40 @kokuyouwind)

右のチームから聞こえてきた会話

「何やります?」「今日で完成させます」「じゃあ僕はビルド通るようにしますね」

前のチームから聞こえてきた会話

「曖昧だけどあんまり曖昧じゃない検索にしたい」

みんな暑さで頭やられてない???


(9:45 id:mizukmb)

今度は下にズレてきた

f:id:mizukmb:20180719094755p:plain:w300


(9::55 merotan)

BGMほしいよね〜って言ってたら割と小さめの音量でT.M.Revolutionが流れ出して、集中できないということで速攻で停止された


(12:00 @kokuyouwind)

LIFFチーム、欲張ってフロントエンドをVue Routerにしたら何も描画されなくなってつらい感じになっている。

LIFFアプリからだとコンソールが見れないので、ひたすらトークルームにデバッグメッセージを流している。

f:id:kokuyouwind:20180719120728p:plain:w300

古き良きprintfデバッグ感…


(12:20 @kokuyouwind)

さようならVue Router、いままでルーティングをありがとう


(13:00 @mugi_uno)

辰巳というお店にランチを食べにきました!

海鮮丼越しの合宿神です。


(15:10 @kokuyouwind)

ご飯を食べて、かき氷を食べて、お散歩して帰ってきました。

午後の部も頑張るぞ!(遅)


(15:20 @kokuyouwind)

LIFFアプリチームの進捗です

f:id:kokuyouwind:20180719153301p:plain:w300


(15:36 oosawatechnica)

名古屋で割と重要目な仕事を終えて合宿に再合流!…の前にかき氷。 Cafe さかゑやさんのいちごかき氷です! 蒲郡産の凍らせたいちごといちごシロップがかかってます。

f:id:oosawatechnica:20180719153739j:plain:w300


(15:45 id:mizukmb)

直りました

f:id:mizukmb:20180719154958p:plain:w300


(16:21 corocn)

これから開発用DBを破壊します


(16:25 merotan)

合宿神の朝は早い

f:id:renya-mizuno:20180719162841j:plain:w300

「合宿は遊びじゃないんで...」そう言い残し、彼は開発用DBを破壊した。

f:id:renya-mizuno:20180719162758j:plain:w300


(17:30 @kokuyouwind)

LIFFアプリチーム、だいぶ動くようになってたのに少し弄った瞬間全てが動かなくなり、いろいろログを仕込んだけどわからなくなっためろたんの図。

f:id:kokuyouwind:20180719173256p:plain:w300


(18:00 @mugi_uno)

外部サービスのメンテナンスとともに散っていった勇者達です

f:id:mugi1:20180719180856j:plain:w300


(18:10 @kokuyouwind)

我々LIFFアプリチームではHerokuで開発をしています。

f:id:kokuyouwind:20180719181036p:plain:w300

f:id:kokuyouwind:20180719181024p:plain:w300

終了〜〜〜〜〜〜〜〜〜


(19:45 @k0matatsu)

f:id:komatatsu:20180719194936j:plain:w300

アイスを丸くとるのが上手い という褒められを得ました


(21:25 merotan)

ほし…きれい…

f:id:renya-mizuno:20180719212322j:plain:w300

雲が分厚くて、おまけに月がめっちゃ明るかったのであまり見えなかった…

f:id:renya-mizuno:20180719212824j:plain:w300

ちょっと分かりづらいんですが、真ん中の点が火星のはずです。

僕がそう思うので間違いないです。


(21:30 @kokuyouwind)

めろたんと一緒に星を見てきました。

「あれがデネブ、アルタイル、ベガ」って指さしたり、双星の写真を撮ったりしようと思ったんですが、雲が多くて星の判別が全然つかず。

月の入りが23時過ぎなので、その頃合いに雲が捌けてたらリベンジしたい。


(22:15 @kokuyouwind)

部屋のテレビでデレステMVを流しながら作業をしています。

f:id:kokuyouwind:20180719221654j:plain:w300

とはいえめろたんとnaoが頑張っててやることがなくなってきたので、とりあえず明日の発表用にVysorをセットアップしてデモを配信できるようにしたりしてます。


(23:50 @kokuyouwind)

温泉から上がりました。

LIFFアプリの基本機能は仕上がってきたので、ここからブラッシュアップをかけていきます。

夜はこれからだ!


(24:15 id:mizukmb)

温泉から上がり、コードを読み直したらおかしな点がたくさん見つかったので修正しました。温泉に入るとコードが良くなるのでおすすめです。


(24:30 @k0matatsu)

とても眠いです


(25:00 @mugi_uno)

明日が発表ということで、ラストスパートをかけている合宿神です。

私もとても眠いですが、せっかくなので気合いで頑張ってます

f:id:mugi1:20180720010625j:plain:w300


(25:55 id:mizukmb)

おやすみなさい


(26:15 nao)

キリが良いので寝ます!

おやすみです👋


3日目の記事はこちら。

tech.misoca.jp