下級エンジニアの綴

新しく発見したことを綴っていこうと思っています。夢はでっかく上級エンジニアになることです。

モブプロを初めて1ヶ月立ったので感じた事のまとめ

どうもやんてらです。私が開発チームのリーダーになって2ヶ月くらいになりました。

以前書いた記事から1ヶ月くらいたったので、久々の更新です。

今回はチームでモブプログラミングを初めて大体1ヶ月ほどたって感じた事を書いていきます。

はじめはモブプロではなくペアプロもどきをやっていたのですが、 私の時間がレビューコストとリーダーの業務とメンテ等で全て奪われて行き、更に開発もしないといけない状況になりました。 流石にこれは無理だと思ってやり始めたのがモブプログラミングです。

※参考書籍はモブプロをする時、めっちゃ勉強になりました。

モブプロを導入しようと思ったのは以下の点です。

  • 相互レビューしながら開発するのでレビューのコストがなくなるのでは?
  • 案件の認識を合わせるMTGがなくなって常に同期されるのでは?
  • 自分も開発に参加出来るのでは?
  • 個人的に一度やってみたかった←ココ重要!!

モブプロを行う時のルールは以下のとおりです

モブプロのルール

  • 毎朝、1日の予定を決める
    • 各メンバーに会議が入っている等を洗い出す
    • 開発を行う時間を決める
      • 自分たちのチームは10:00-18:00でモブプロをしてます
      • 残りの1時間は各々やりたいことをやってます。
  • 休憩
    • 自己判断で休憩をとるのが難しくなるので、強制的に休憩を取るタイミングを決める(1、2時間単位ぐらい
    • 大体10~20分くらい休む
    • 全員で考えて10分詰まったら強制的に休憩する
    • 17時を過ぎているとそのまま振り返りをして自習(解散)ということもある
  • 1日の振り返りは絶対にする
    • これをやらないと最適化されないのでよりチームに合ったやり方と見つけるために振り返りの時間を30分ほど取ってます
    • google driveなどで今日やった事やKPTの写真を取って成果の管理する。
  • PCは各々によって環境が違うので、ドライバー交代時はブランチをpullする。
  • 案件の見積もりはメンバー全員でする
    • issueは機能単位で切り、出来るだけMinimumにする
      • ここで言うMinimumとは見積もりが出来る且つ、少し余裕があるくらいの見積もりの大きさです
    • 追加や漏れがあった場合、別issueで行う
    • 案件で発生するissueをまとめるissueを作成する
  • 2週間のスプリントで区切り、見積もり含めて順調に案件が進んでいるかを見直すようにした。

モブプロのルールは毎日の振り返りを行い、毎日振り返りをして最適化した結果こうなりました。 個人的に見解ですがルールが変わらなくなれば、見積もりを含めてほぼ完璧に成果が出せるようになっていると思います。

やってみた結果(メリット)

  • プルリクを投げるとすぐにマージできるようになった。
  • 細かくcommit&pushをするようになった。
  • 互いが何をやっているかの共有会がなくなった。
  • 私も開発に参加出来る時間が増えた。
  • メンバー間のコミュニケーションがよくなった。
  • 周りから見て楽しそうに開発しているように見えているらしい。
  • 教育コストが減った。
  • 雰囲気が良さげだと別のチームが真似をしてモブプロに近いことを始める。
  • いらない会議を減らせた

やってみた結果(デメリット)

  • 正直めちゃくちゃしんどい。
  • サボる事は不可能になった。
    • 自分のタイミングで気分転換するのが難しいので、そこはいい感じに解決しないと問題になる。

まとめ

自分のチームでは基本的にモブプロ+アジャイルというスタンスでやってます。

基本的にMAX6.5時間ほどモブプロをして、後の1時間は各々でやりたい業務をするという流れにした結果、良い雰囲気で開発出来るようになったかなと思っています。(残りの0.5時間は休憩です

あと、余裕がなくなると愚痴が多くなりパフォーマンスが下がるので、出来るだけ余裕を持って作業出来るようにするとチームは良いパフォーマンスを発揮するのでは無いかなと思いました。

参考書籍

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

カイゼン・ジャーニーを読みながらマネジメントっぽい事を始めて2週間ぐらいたったので感じた事をメモ

最近チームのリーダーの人が抜けて急遽自分が代わりにマネジメントっぽい事を始めたので気づいた事をメモ。

今までスクラムを意識してやっていたのですが、どうもチームで作業している感が無くて改めて今までの開発フローを見直しました。 (ほとんどカイゼン・ジャーニーを参考にして行いました)

やめた事

  • 開発チーム (4人)の代表とプロダクトオーナーだけで話し合って案件(githubのISSUEのチケット)の優先順位を決めていた事。
  • ↑の会議で話し合った案件をチームに割り振る事(優先度の理由は別途聞き直す理由があった)。
  • 1つの案件に対して1人で作業する事。

始めた事

  • 案件の優先度は開発チーム全員とプロダクトオーナーで話し合って優先順位を決める事。
  • 決めた優先順位の案件に対して2人以上で取り組む事。
    • スコープが小さすぎると1人でやる事もある
  • ISSUEのテンプレートを作成した。
    • issueは開発チーム以外から上がることが多いので案件について誰が見てもわかるようなテンプレートを作成。
  • トレードオフスライダー
  • 星取表(スキルマップ)

やった結果

  • 案件の優先度は開発チーム全員とプロダクトオーナーで話し合って優先順位を決める事。
    • 開発チームに危機感や一体感が出てきた。
  • 決めた優先順位の案件に対して2人以上で取り組む事。
    • これは相談できる相手がいるというのがあったりするのでチームの雰囲気は少し良くなったなと思います。
  • ISSUEのテンプレートを作成した。
    • これは作成したばかりなのでまだ結果はわかりません。
  • トレードオフスライダー
    • 開発チームのメンバーが何故このサービスにジョインしているのか知ることが出来た。
    • メンバーの優先度が互いに共有できた。
  • 星取表(スキルマップ)
    • メンバーが今の開発チームで不安に思っていることが知れた。
    • メンバーの苦手な部分を知れた。
    • メンバーのやりたいことが知れた。
    • これは各自の技術的なスキルマップだけでは無くサービスに関しての機能単位でもやることにより、どの機能を誰に聞けば良いかなども明確になった。
      • 逆に誰も知らない機能があるというのも明確になったのでより危機感を覚えました笑

最近始めようと思っていること

  • 朝の案件の共有をもう少し時間を取ること。
    • 具体的にはファイブフィンガーを取り入れようと思ってます。

まとめ

結果がすぐに出ている訳ではないですが、チームで見えていない部分の共有が出来るようになったかなと思ってます。 個人的な考えですが、メンバー1人1人の課題はチームの課題だと言っても過言ではないと個人的に思ってます。 なのでこれからはどんどん不要な課題は取り除けたら良いなと思ってます。

カイゼン・ジャーニーは勉強になる事ばかりだったので、困ったらとりあえず読み直そうと思います。

rubyのcountについてメモ

countを使わなくて失敗したので戒めを含めメモ。

Active Recordのデータ(配列)に対して

sizeを使えば配列を全てオンメモリで扱って、結果を返す。

countはを使えばdbに投げて結果を返してくれる。

↑のことはわかっていたけど、物理的な部分を理解しているつもりで終わっていた。

例えば、100件程度のデータならsizeの方が良いと思うが、数十万件となるとcountの方が良いと思う。

理由としては

数十万件のデータを全てメモリに載せようとするとおそらくメモリが足りずに落ちる

からである。

blank?とかpresent?とかも同じことが言える。

配列を判定する時に値が存在する、存在しないという処理も配列のデータをオンメモリで扱おうとするので仮に数十万件データが入っていると落ちる可能性がある。

array.count > 0

という処理はpresent?を使えば良いと思っていたけど、時には必要なんだなと思った。

countが使えない場合はfind_eachとかを使って頑張るしか無いかなと思う。

その辺をわかっているつもりでわかっていなかったから、不具合を産んでしまった。次は絶対に同じミスをしない。

railsのparamsについて調べたのでメモ

今回はparamsのメソッドについてハマったので色々調べたメモです。

railsのバージョンは4.1.8でrubyのversionは2.1.5です(古いバージョンで辛い・・・

内容

作成した成果物を一覧で表示する処理を書いており、スクロールを行うと自動で次の成果物を表示するロジックを書いていた時に発生しました。

ロジックとしては、一定以上の座標に到達した時、非表示にしているlinkタグを動的に叩かせる処理で、linkタグはget形式です。

原因

getのパラメータの引数が膨大な長さになっており、それが原因でエラーになっていました。

処理の流れとしては

paramsを送信 (ブラウザ)→paramsを加工(サーバ)→linkタグを生成(ブラウザ)

みたいな流れです。

なぜ急に発生したのかと調べているとparamsを加工する処理が一番の原因でした。

サーバ側で〇〇_id_in[1,2,3.....]みたいな形のparamsを生成しており、

↑のparamsを元にgetのpathを生成すると

〇〇_id_in=1&〇〇_id_in=2&〇〇_id_in=3...のような形式でpathが生成されました。

色々調べたところ、pathを作る時にparamsを元にしているっぽかったです。(配列で渡されたら↑のような形式になるのかな?未検証ですみません)

対応

  • paramsを直接書き換えないようにする事(加工する時はdupなどで複製した物を使う)
  • ransakを使うときは〇〇_id_inみたいなparamsをブラウザで生成しない事

まとめ

railsのparamsは直接触らずにdupなどで複製し、その複製したものに変更を加え流のが良いですね。あとransackの〇〇_in怖い・・・

参考リンク

stackoverflow.com

params (ActionController::StrongParameters) - APIdock

destroy_allの挙動が思ったのと違ったのでメモ。

railsでまとめてデータを削除したいときにdestroy_allを使用していたのですが、実際に動いているsql文を見て想定と違ったので調べたのでメモ。

内容としては 数十万件のレコードを舐める時に1000件単位で削除を行おうと思ってコードを書いており、1000件のオブジェクトごとにdestroy_allをかけていました。

想定していた挙動は 1000件まとめてレコードを削除するdelete文が叩かれる事 でしたが、 実際は1レコードずつ削除するdelete文 が叩かれていました。

気になったのでrailsのapidockを見たところdestroy_allの実際の処理は配列のオブジェクトをeachで回して1つずつdestroyを叩いていました。

# File activerecord/lib/active_record/relation.rb, line 398
    def destroy_all(conditions = nil)
      if conditions
        where(conditions).destroy_all
      else
        to_a.each {|object| object.destroy }.tap { reset }
      end
    end

勉強になりました。今回はこれで終わりです。

ssh先のサーバでrailsサーバを立ち上げるシェルを書いたのはいいけど、sshをkillするとrailsのプロセスが残ったままになったのでメモ

今回ハマった点ですが、タイトルの名の通りssh先のサーバでrailsサーバを立てるシェルを書いたのでが、ctrl + c で抜けるとsshはkillされてrailsのプロセスがssh先のサーバで残ったままだったので、解決方法を模索したメモになります。

ssh hostname 'rails s -b 0.0.0.0 -p 3005'

とコマンドを実行した時、ssh先のサーバでrailsサーバを立ち上げてテストを行おうと思っており、実際に問題なく立ち上げることには成功しました。しかし、ctrl + cで処理を終了させるとsshのプロセスだけ死んでrails sのプロセスだけずっと残ったままでした。

プロセスを確認すると↓のようになっており、

$ ps aux | grep ruby
508      17276  1.0  5.2 406732 155300 ?       Sl   12:24   0:05 bin/rails s -b 0.0.0.0 -p 3105
508      17587  0.0  0.0  81796   836 pts/0    S+   12:32   0:00 grep ruby

調べてみると、ttyとかptsの問題のようでした。 下記の記事でわかりやすく説明してくださってました。

qiita.com

簡潔に説明すると

ターミナルからアクセスしていると pts/ というものが表示され、 と表示されている場合はdemonで立ち上がっているよという目印みたいでした。

上記を解決する方法ですが、

ssh -t hostname 'rails s -b 0.0.0.0 -p 3005'

-t オプションを付ければ良いみたいでした。

LINE DEVELOPER DAY 2017に行って来ました

Line Developer Day に行って来ました f:id:yanterakun:20170929003922j:plainf:id:yanterakun:20170929003757j:plain 昨年も参加したのですが、ブログに書くのは今年が初めてになります。

受付

受付を完了するとお昼代としてヒカリエお食事券をいただきました。(2000円分) 写真を撮り忘れていたので、写真はありませんorz 受付を済ませオープニングセッションのホールへ向かう途中に f:id:yanterakun:20170929003820j:plain ホームスピーカーが展示されていました。(めっちゃ欲しかったです

午前のセッション

午前のセッションは2つだけでLineのオープニングとLineが最近力を入れているAI、clovaの2本立てでした

Opening Session

openingはLINEがどのようにしていきたいという話と、もっとossに力を入れていくので、エンジニアのみなさんも力を貸してくださいという内容でした。私自身は勿論OKでした。エンジニアに優しいLINEのお願いとあっては断れるはずありません。

www.slideshare.net

The Technologies in Clova

clovaのセッションではlineがclovaをどのように定義し、これから展開していくかというお話でした。

一番びっくりしたのが、clovaを搭載したwavaは1年前にプロジェクトが始まったらしいです。地固めをしっかりしているLINEさんだからこその開発スピードなのかなと思いました。

(Line Developer Dayのアンケートに回答するとwaveが50名に当たるそうなので、めっちゃ欲しいです。ブログ書くので当たらないかなーって思ってました。)

www.slideshare.net

LUNCH TIME

ランチはお寿司を頂いて来ました。とっても美味しかったです。 f:id:yanterakun:20170929010954j:plain ランチが終わると11階のカフェで休んでいました。f:id:yanterakun:20170929011251j:plain (これだけものが無料で提供されていたので、Lineの懐の深さに驚愕です。

午後のセッション

Gateboxのこれまでとこれから

Gateboxってなにかというとホームスピーカー1つですが、AmazonGoogle、Lineと違うところは端末にキャラクターが存在しており、感情豊かなキャラクターがいるということでした。

いわゆる俺の嫁みたいな感じらしく、コンセプトムービーを見ましたが、これは是非欲しいなと思いました。

clovaとgateboxの提携が決定しているらしく、どちらかに吸収されるという事ではなく、互いに良いところを取り入れて来たいねという形での提携されるそうです。

www.youtube.com

www.slideshare.net

Paying back technical debt - LINE Androidクライアントの事

リファクタリングをしやすい文化と技術を取り入れましょうという内容でした。 ボーイスカウトルールはチームの文化に是非取り入れていきたいなと思いました。(めっちゃ耳が痛いですが

www.slideshare.net

休憩

ここから1時間ほど元会社の上司の方とお話していました。

LINEにおけるBluetoothを活用した取り組みの紹介

主にline beaconの話でした。 本屋と連携しており、LINE漫画を読むことにより、限定特典などもらえるみたいでした。

Tappinessは自販機にline beaconを仕込んでおり、 lineを立ち上げて自販機に端末を近づけるとline payまたは現金で決済が出来、15ポイントでクーポンがもらえるみたいです。

なるほど、line beaconをlineの入った端末のネットを使ってサーバと連携するのか・・・(web buletoothを参考にしているらしいです。

line simple beaconはbuletoothの端末をline beaconに出来るソフトウェアらしく、ラズパイとか使って一回試して見たいなと思いました。

www.slideshare.net

Parallel Selenium Test With Docker

翻訳機を使っていたのですが、英語がかなり聞きやすかったので、英語聴きながら日本語を聞くと訳が分からなくなるので、途中から使うのをやめました。

内容はスライドを見ていただくと8割くらい理解できると思います。

docker+jenkins+seleniumでのテスト行う環境、良いなぁ。

www.slideshare.net

休憩

疲れたので次のセッションは参加せずに休憩してました。 フラフラしていると、上記セッションでお話をされていたTappinessの自販機を発見したので、利用させていただきました。

使い方はLineを起動すると自販機のline beaconが反応するので、Line Payまたは現金で決済を行うと買えました。

suicaと違ってドリンクポイントが貯まり、何回か利用するとお得になると思うと、あったら使うなと思いました。 f:id:yanterakun:20170929012919j:plain f:id:yanterakun:20170929012902j:plain

BOT and the new Comfortableness

最後の技術セッションは message api とline loginの連携が出来るようになったみたいです。

グループを作成した時にユーザーのIDを取得できるようになったので、 個別のユーザーに対してのリアクションが可能に。

rich menuのレイアウトが自由に構築できるようになるみたいです。 自由なデザインが可能になるので、これは遊ぶ楽しさが増えますね。

ただし、rich menuのapiの更新はcommig soonらしいです。 line bot studioも近いうちにリリースされるみたいです。 ( 非エンジニアの人がカルーセルとかで出てくるものを選択してline botが作れるみたいです。コード書けなくてもできるというのが凄いなと思いました。

clovaのAPIも近い内に公開されるみたいです。

結論、rich menuのapiの更新・line bot studio ・clova apiはまだなので、とりあえずmessage apiとline loginで遊んでみてくださいとのことでした。

line api expertが公開されるみたいで、要は一緒にline api作ってくれる人募集との事でした。

www.slideshare.net

Closing Session

クロージングでは本日のセッションの振り返りとLineのこれからどのように展開していくのかというお話でした。京都にも開発拠点は学生との交流がメインであったりと、次を見据えているLineは改めてすごいなと感じさせられました。

www.slideshare.net

最後に

本日のアンケートに回答するとノベルティがもらえました。 その時にclova waveの抽選もあったのですが、筆者は見事当選しました!!

(左上 : ステッカー、右上 : マグカップ、下 : クローバー栽培キット f:id:yanterakun:20170929021621j:plain (clova wave f:id:yanterakun:20170929021656j:plain これで当分頑張れそうな気がします。

本当Line Developer Day最高でした。

開催して下さった関係者のみなさんありがとうございました!

来年も開催されたら是非参加させて頂きたいなと思っています。