今日もヤバさをI/O中。

新卒2年目のエンジニアブログです。基本的に何かが足りません。

新卒1年目を終えて、学生時代から今までを振り返ってみた

4月になり、新卒1年目が終わりました。

学ぶことが沢山あり、これからやりたいことも明確になった新卒1年目でした…が、新卒2年目ともなると後輩も入ってくるしもっと大きな成果を求められます。

そのためには今の自分のままではダメで、もっと成長する必要があります。

そこで今回は、自身のエンジニア人生である2年半分の振り返り(超大作)について書こうと思います!

今回も例に沿って YKPWT で振り返ります!

やったこと

開発アルバイト時代(2016/10/01 ~ 2017/03/31)

株式会社ウィルゲートに開発アルバイトとして、入社。

当時は集団で開発した経験がなく、フレームワークもほぼ触ったことがないような状態。Git に至っては初めて存在を知る…

仕事

最初は開発のテストがメイン。また、業務理解のために、画面遷移図やフローチャートを書く。

徐々に業務にも慣れた頃に小規模の機能実装を任されるようになり、CakePHP を使った開発がメインの業務に。

コーディング / Pull Request ルールや、 Git 開発フローなど git を用いた集団開発の基礎を実践しながら学ぶ。

プライベート

大学では通常授業を受けつつ、学生プロジェクトとして Arduino や swift を触ってボードゲームを作成。

また、ボードゲームのコンセプトや内容詰めのために UI / UX やサーベイも実践しながら少しずつ学ぶ。

Kamihira Project 2016

就活も始まる頃だが、企業で働くエンジニアのイメージが1ミリも湧いていない状態。そこで技術的インプットも兼ねて、技術系のイベントに参加し続けていた。

先輩社員の誘いで、若手エンジニアの勉強コミュニティに参加(活動内容は後の時代で触れます)

内定者インターン時代前半(2017/04/01 ~ 2017/09/30)

株式会社ウィルゲートにて4月上旬に内定をもらい、内定者インターンとして働くことになる。

1年以上に渡ってお金を頂いているので、肩書きは開発アルバイト。

仕事

開発アルバイト時代から継続して、CakePHP を使った小規模の機能実装をこなす。

夏休み中は中規模開発プロジェクトに、実装者としてジョイン。

CPM やガントチャートを用いたスケジューリングや結合 / 受け入れテストなど…本格的に集団で開発することについて、実践しながら学ぶ。

プライベート

大学の授業と卒業演習でいっぱいいっぱいだったこともあって、それ以外の動きは乏しかった。

とはいえ、web 系についてのインプットは休日にやっていた(wordpress 構築してみたり、virtual box や vagrant を使ってみたり)

内定者インターン時代後半(2017/10/01 ~ 2018/03/31)

仕事

10, 11月は働きすぎで親の扶養から外れてしまう可能性があったため、お仕事はお休み。

12月以降は小規模の機能実装、3月からはまた中規模開発プロジェクトに、実装者としてジョイン。

業務と直接関係はないが、社内輪読会に参加。

輪読会はじめてます! | ウィルゲート開発ブログ

プライベート

CoinStep という仮想通貨バーチャルトレードゲームを、若手エンジニアの勉強コミュニティメンバーらで集団開発をしていた。

主に Golang を使いながらAPI の実装を担当。他にも、一部フロントで vue.js / vuetify.js を使った実装もした。

あとは初めて isucon に参加したり、イベントに参加したり…コワーキングスペースを借りて開発してたりもした。

新卒1年目時代前半(2018/04/01 ~ 2018/09/30)

正社員になった。同期のエンジニアが皆自分より技術力があることや、業務で一緒に開発をしてきた社員らと同じ立場になったことで緊張と焦りもあった。

仕事

4月中旬では新卒研修、4月下旬 ~ 5月までは、内定者インターン時代後半からジョインしていた中規模開発プロジェクトにて実装をしていた。この時業務で初めて SQS を使った。

SQSで処理を非同期化したらストレスフリーになった - WILLGATE tech blog

また、開発アルバイト・内定者インターン時代ではやらなかった運用保守を担当することになり、お問い合わせに対するログ調査などをやるようにもなった。

6月からは、新しいプロダクトの開発プロジェクトにジョイン。構成はレイヤードアーキテクチャ + Laravel + vue.js 。中でもレイヤードアーキテクチャは社内でも初めての試みで、皆で相談しながら理解を深めつつ、実装をしていった。

また、Laravel も初めて触るフレームワークだったため、チームで勉強会をしつつ自分でも勉強していた。

プライベート

正社員として入社してから3ヶ月ぐらいは思うように時間が取れず、いっぱいいっぱいの状態に。

(当時は実家から通っており、通勤時間は片道2時間15分…。平日に勉強する時間が全く取れないので、通勤時間が1/3の時間になるところへ引っ越した)。

この時期は仕事でレイヤードアーキテクチャに初めて触れたため、DDD やドメイン設計について調べて、どう実装していくのが正解なのか考えて理解を深めていた。

去年若手エンジニアの勉強コミュニティメンバーと一緒に参加していた isucon にも参加した。

新卒1年目時代後半(2018/10/01 ~ 2019/03/31)

仕事

6月から触っていた新しいプロダクトがリリースし、こちらの運用保守も担当することに。

ただ残念ながらこのプロダクトは、様々な観点から見て品質が悪いという課題があった。加えて、当初4人いた開発メンバーも自分と LDR だけに。

どう解決するのか自分で分析 / 提案 / 実行まで LDR に相談しながら協力してサービスの課題に向き合い続けた。

その影響で、初めて E2E テストをプロダクトで書いたり(puppeteer, nightmareJS)、テスト技法やテスト計画書について輪読会で学んだりした。

また、弊社で品質保証 PRJ を立ち上げ、自社の障害分析を行なっている最中である。

プライベート

今までに比べると多くのアウトプットをした。

あとは社内イベントのスタッフをしたり、技術系カンファレンスの当日スタッフに参加したり…

2月ぐらいから QA に興味が出てきたため、独学で勉強しつつ少しずつ勉強したりイベントに参加している最中である。

Keep

エンジニア面

  • 企業で働くエンジニアのイメージがわからない状態から、ここ数年で企業にて働くエンジニアとしてやりたいことがかなり具体化するまでに至った
    • 描きたいキャリアパスが入社前より具体化した
    • 企業に対して自身がどのような価値を提供できるのか、その価値は企業が求めているものなのかも考えるようになった
  • エンジニアとしても社会人としても成長が感じられた(特に新卒1年目後半は自分でもわかるぐらいめちゃめちゃ成長した)
    • 以前よりも自走力が上がったように感じる
    • エンジニアとしての自分に少しだけ自信がついた
  • 着実に技術力を身につけている
  • アウトプットする量が、以前よりも多くなった
    • 以前は「技術力ないからマサカリ投げられるのこわいな〜〜〜」と思っていたが、今は「どうせ技術力ついたところで投げられるときは投げられるんだから、気にするだけ無駄」と考えるようになった
  • 自身の興味(これから専門性として極めたい領域が)設計と QA であることがわかった

それ以外面

  • アウトプットする量が、以前よりも多くなった

Problem

エンジニア面

  • 業務で大きな成果は出せていない
  • 未だ自身の専門性(強み)が弱い
  • 新卒入社前でももっと成長できる余地があったのではないかと感じる
  • お世辞にも、アウトプットの質はまだ良いとは言えない
  • 思わぬところで基礎知識が抜けている

それ以外面

  • まだまだコミュニケーションが下手
    • 説明下手の域を出ていない
  • 「地頭」「論理的思考」「メタ認知力」などが課題に挙げられるが、残念ながら PDCA の回している回数が少ない
  • 「成果」を達成するまでのストーリー立てが下手
  • 段々人前で喋る機会が増えたため、自分の喋り下手なところが露呈した

わかったこと

  • 自分の描きたいキャリアパスが今のところ「まずは QA エンジニアになりたい。そのあと設計と QA を武器にしたアーキテクトを目指したい」っぽい
    • 弊社でも、品質保証の分野は求められているため自身のやりたいこと(Will)と、会社が求めているやるべきこと(Must)は一致している
    • あとは自身の専門性 / できること(Can)が一致すれば、業務でも大きな成果を出せる
  • 新卒入社後(特に新卒1年目時代後半から)成長したのは、実践しよう・試してみようという姿勢と振り返りがあった(≒ とにかく PDCA を回す)から
    • そのためにはインプットとアウトプットの両立と振り返りが大事
  • いきなりアウトプットの質を求めるのは無理
    • 量を重ねてから質を求めるべき
  • 登壇は素振りが大事
    • 喋りが苦手な自分はなおさら回数を増やすべき
  • 「地頭」「論理的思考」「メタ認知力」などが課題に挙げられるが、残念ながら PDCA の回している回数が少ない
  • 「成果」を達成するまでのストーリー立てに適した考えの骨組みがまだないかも

次にやること

  • QA の知識を最優先で身に着け、業務で実践する
    • ただし、最終的に目指したい姿はアーキテクトなので、設計の知識も身につけ実践する
  • 設計の知識を実践する場として、プライベートでプロダクト開発をする
  • 継続的なアウトプットは続けつつ、半年ごとに自分のアウトプットを振り返る機会を設ける
  • 人前で喋る機会を得たときは、絶対に素振りをする
    • 回数をこなせば、喋り下手も改善する道筋が見える
  • 思考法・ストーリー立てに適した思考のフレームワークを見つける
    • これは別途ブログ記事にして考えてみる

PHPerKaigi 2019 に当日スタッフとスピーカーとして参加してきたので振り返ったった

PHPerKaigi 2019?

phperkaigi.jp

2019年3月29日(金)〜 3月31日(日)はPHPerたちのお祭りです! この一文につきると思います!

他の技術系イベントと比べても参加者を楽しませるコンテンツが多数用意してあり、(いい意味で)異色の技術系イベントです!

発表内容共有

今回は LT スピーカーとしても参加したので、振り返りの前にスライドの共有をします!

speakerdeck.com

speakerdeck.com

後日発表時の動画もアップロードされるはずなので、アップロードされ次第こちらの記事にURLを貼り付けます!

振り返り

それじゃあまた振り返りをします!振り返り方法は、例のごとく YKPWT で行います

ただ、前回の振り返りだと詳細に書きすぎたので、少し簡潔にします!

やったこと

  • 当日スタッフ
    • 会場設営
    • ノベルティを用意する作業
    • トラックA の進行
  • LTスピーカー
    • 本編 LT
    • 懇親会 LT
  • 参加者
    • セッション聴講
    • 懇親会参加
      • PHPreParty, PHPer茶会, 懇親会, PHPostParty

Keep

当日スタッフ

  • 3日間という初めての長期間スタッフだったが、無事終えられた
  • 指示された作業よりも、自分で考えて(工夫して)作業した内容の方が多かった
  • 一部の当日スタッフらと後日ボルタリングへ行く約束をした

LTスピーカー

  • 2,300人という大人数の舞台で初めて登壇した
    • というか、応募時点では社外で LT をしたことがなかったが無事終えた
  • 時間内にきっちり喋り終えることができた
  • ちょっとしたハプニングがあったし、緊張もしていたが、素振りで練習した内容通りのことを話せた

参加者

  • やはり無料でセッションや懇親会に出れるのは最高(当日スタッフ・スピーカー特典)
  • 全日程の懇親会を通して交流を深められたので、通常のイベントの3倍(3日分)の繋がりが増えた

Problem

当日スタッフ

  • 明らかに最終日に近づくにつれて、疲れが隠せなくなっていた(小さなミスがいくつかあった)

LTスピーカー

  • 懇親会 LT で割とすべった
  • pdfpc と呼ばれる、pdf のプレゼンツールを使ったが会場の設備との相性が悪くて使えなかった
  • 事前に予告していた内容と少し違う内容になった

参加者

  • 当日スタッフの仕事やスライド作成・修正に時間をかけすぎて、一部積極的に参加できなかったコンテンツがあった(PHPerチャレンジとか)

わかったこと

  • 「最悪コアスタッフに相談すれば大丈夫」という気持ちがあると、色々いい感じに対応することができる
    • そういう安心感を抱かせてくれるコアスタッフの皆さんマジすごい
  • LT に問わず発表の素振り、何回もするの大事
  • LT、すべることもある。そういうこともある
  • 当日スタッフとはいえ、3日分も参加すると達成感とスタッフ同士の繋がり度合いが半端ない

次やること

  • 自分がイベント開催者になるときは、自分がうまく立ち回るのではなく他のイベントスタッフが動きやすいように立ち回る
  • 発表の素振り、何回もやっていき💪
    • 特にスライドが pdf だったら、スライドの内容を覚えこむまでやる(そうでなかったら、大人しく pdf ではなく keynote とかにする)
  • 次は PHP カンファレンス北海道のCfPにレギュラートーク枠で応募する
    • そのためにネタを考える・作る
  • 日頃からダジャレを言って冷たい目線を向けられることに慣れ、すべっても動じない心を身につける
  • 来年の PHPerKaigi も参加する

最後に

関係者、スタッフの皆さま、参加者の皆さまお疲れ様でした&ありがとうございました!

これだけ参加者を楽しませる取り組みがすごいカンファレンスは、そうそう無いと思います!!(現に知人とも「イベント運営面でお手本にしたいけど、正直再現性がわからんし、すぐ真似できなそう」って話をしました)

また次の PHPerKaigi でお会いしましょう!

avgメソッド Collectionメソッドソースコードリーディング100本ノック2本目

メソッド概要

コレクション 5.8 Laravel

avgメソッドは、指定したキーの平均値を返します。

<?php

$average = collect([['foo' => 10], ['foo' => 10], ['foo' => 20], ['foo' => 40]])->avg('foo');

// 20

$average = collect([1, 1, 2, 4])->avg();

// 2

average メソッドも同じ処理です。

ソースコードリーディング

avg メソッド

では早速、ソースコードリーディングをやって行きましょう。

<?php

/**
 * Get the average value of a given key.
 *
 * @param  callable|string|null  $callback
 * @return mixed
 */
public function avg($callback = null)
{
    $callback = $this->valueRetriever($callback);

    $items = $this->map(function ($value) use ($callback) {
        return $callback($value);
    })->filter(function ($value) {
        return ! is_null($value);
    });

    if ($count = $items->count()) {
        return $items->sum() / $count;
    }
}

後で解説しますが valueRetriever メソッドは、$callback をコールバックとして読み取れる値に整形するメソッドです。

$callback の戻り値を、 map メソッドを使って Collection へ整形します。

戻り値が null だった時は、 Collection に含めません。 null を平均の対象へと含めないようにする意図のようですね。

最後に Collection 内の値の平均値を返す…といった処理になります。

参考:

github.com

valueRetriever メソッド

<?php

/**
 * Get a value retrieving callback.
 *
 * @param  string  $value
 * @return callable
 */
protected function valueRetriever($value)
{
    if ($this->useAsCallable($value)) {
        return $value;
    }

    return function ($item) use ($value) {
        return data_get($item, $value);
    };
}

$callback を、コールバックとして読み取れる値に整形するメソッドです。

最初にそもそもコールバックとして読み取れる値だったら、そのまま値を返します。

コールバックとして読み取れない値だったら、コールバックとして読み取れる無名関数を返します。例えば以下のようなコードがあったとします。

$callback = $this->valueRetriever($value) 
$callback($item)

この場合、 $callback($item) は以下のようになります。

$callback($item) =
    function ($item) use ($value) {
        return data_get($item, $value);
    }

data_get は、配列やドット区切りのオブジェクトから要素(配列 or データ型の値)を取り出すヘルパメソッドになります(data_get ヘルパメソッドについては、別の記事にて解説します)。

$item が配列だったり Collection だった時のために、このような処理になっているようです。

参考:

github.com

github.com

useAsCallable メソッド

関数として呼び出し可能 かつ 文字列ではないかを返します。

呼び出し可能な関数名ではなく、関数そのものか判別したい時に使うようです。

<?php

/**
 * Determine if the given value is callable, but not a string.
 *
 * @param  mixed  $value
 * @return bool
 */
protected function useAsCallable($value)
{
    return ! is_string($value) && is_callable($value);
}

最後に

この記事を書いているうちに、 Laravel 5.7 -> 5.8 へとバージョンアップしました。

もたもたしているとすぐバージョンが上がってしまい、過去に書いた Collection メソッドをまた再度検証する…なんてことになってしまうので他のメソッドもどんどん書いていこうと思います!

次は chunk メソッドです!

LaravelJPConference 当日スタッフとして人生初参加してきたので、振り返ってみた!

2/16 開催の LaravelJPConference に当日スタッフとして参加してきました! conference2019.laravel.jp

人生で初めて大規模イベントの(当日)スタッフ参加です…!当日は進行を担当していました!

もちろん LaravelJPConference も、今年初の開催なので初めての参加ですw

ですが、スタッフも含め参加者は334名だったそうです! 初開催なのにすごい!

当日の様子やセッションについては、以下を見ていただければと思います!

ハッシュタグ#laraveljpcon

Laravel JP Conference 2019 スライドまとめ - Qiita

振り返り(YKPWT)

YKPWT を使って個人的な振り返りをしました! cocoeyes02.hatenadiary.jp

以下やったこと、Keep、Problem、わかったこと、次やることになります!

やったこと

  • Laravel Track の準備
    • 機械設備の仕様把握(PCの規格に合わせた表示変更、マイク音量調節、照明調節、空調など)
    • 設営(スピーカー台設置と後方のパネルの組み立て)
  • Laravel Track の進行
    • スピーカー対応
      • お水配布
      • 疎通チェック(スピーカーのPC に合わせて)
    • 司会
      • アナウンス(開始前 / 開始後)
      • 質疑応答
    • タイムキーパー
    • 機械設備操作
    • 質疑応答時のマイク運び
  • Closing Talk 後の片付け
    • 現状復旧
    • ゴミ片付け

Keep

当日スタッフとして
  • 連絡を見逃さないよう、定期的に slack で当日スタッフ用のチャンネルを見た
  • 誰も機械整備の仕様について詳しく知らなかったので、分かったことを随時 slack や口頭にて共有した
  • アナウンス内容を変える対応が何回かあったが、なんとか対応することができた
  • 設営担当の撤去の手伝いなど、特に割り振られていない仕事も少しやった
  • 初開催の LaravelJPConference だったが、大成功かつ無事終えることができた
  • イベント運営の経験を経て、対応力やナレッジなど得られるものがあった
一参加者として
  • Laravel や PHP 問わず知見や知識が深まった
    • しかもタダで!(今回当日スタッフはチケット代無料でした )
  • PHPer 界隈の知人がめっちゃ増えた(フォロワーも40人ぐらい増えた)
  • 自分の OSS 活動が評価されたようにも感じたし、他の人への勧め方など知見を得られた(ういろうさん @nyamucoro ありがとうございます!)
  • お昼御飯がめっちゃおいしかった(ランチサポンサーの株式会社デザインワン・ジャパンさんありがとうございます!)

Problem

当日スタッフとして
  • 事前にアナウンスのテキストを用意されていたので、iPad で確認できるよう持ってきていたが当日に iPad が初期化されていたことに気がついた 😇
  • アナウンス担当時に緊張し過ぎて、その時やってたセッションの内容が頭に入ってこなかった
  • Track がほぼ満員だった時、空き席への案内などの対応が満足にできなかった(コアスタッフの人に任せてしまった)
  • 事前説明会で言われたタスク以上のことが、あまりできなかった気がする
  • スマホの電池残量がギリギリだった(イベント終了時に7%)
一参加者として
  • 恒例(?)のじゃんけんで決勝まで上がったが最後で負けた :kanashii:

分かったこと

当日スタッフとして
  • イベントスタッフ用のワークスペースを用意する時、緊急連絡用のチャンネルがあるとすぐ報告できるし安心
  • 持ち場が固定のスタッフは持ち場以外の状況等が把握できないので、小さな出来事でも slack で共有してあげると良い
  • 会場の設備について、まだ把握していないのであればできるだけ早く理解して共有することが吉
  • イベントスタッフの経験豊富な人がいると、いろいろと円滑に進む(ありがたい。。。)
  • やっぱり午前中にトラブルが起きがち(逆に午後は安定する)
  • 定期的に slack を見たり、ツイートしたらすぐにスマホの電池残量が減る
  • 司会やばいぐらい緊張する
  • 当日スタッフとして参加すると、普通の参加以上に界隈の人と仲良くなれるチャンスがある
一参加者として
  • php 系のカンファレンスでやるじゃんけん大会は、前でじゃんけんをする人がなんの手を出すか予告するので、途中まではその手に勝つ手を出す
    • どこで裏切られるかを推測するのが勝利の鍵
その他
  • 自分のイベントアドリブ対応力の低さが露呈した
    • ホスピタリティが足りない
    • 経験値が足りない
  • デブなので立ち仕事やると、すぐに足に疲れが出てくる

次やること

  • 他のイベントにも参加して、イベントスタッフ経験を積む
    • 今度は自分が進行を円滑に進められるような人へ…
    • 自社のイベントスタッフやコアスタッフになることにも繋がるはず
  • 小さなことでもいいので、なるべく slack に流して共有する
    • ただし、緊急時の内容は、他の共有内容で流れてしまうとまずいので専用のチャンネルで共有する
  • スマホ充電用のモバイルバッテリーを持っていく
    • 持ち歩くことになるので、できるだけ小型の方が良い
  • 前日に自分が持っていくデバイスが正常に起動しているか確認する
  • 次のじゃんけん大会こそ、どこで裏切られるかを推測して景品をゲットする!!!!
  • 運動しよう…

最後に

拙い個人的な振り返りの共有になってしまいましたが、全体を振り返ってみても当日スタッフ参加はとても得るものが多いです!!

他のPHPカンファレンスでも当日スタッフを募集していると思いますので、参加されたことが無い方は是非参加をお勧めします!!!

2019年に開催される全国のPHPカンファレンスのまとめ - Qiita

日報の形式は「YKPWT」がオススメ

TL;DR

  • 日報は「YKPWT (やったこと Keep Problem 分かったこと 次やること)」がオススメだよ
  • KPT より優れている点
    • 当日の業務内容を報告できるよ
    • 良かったことの深掘りができるよ
  • YWT より優れている点
    • 良かったことを書いた方が、自身の成長を実感できるよ
    • やったこと→分かったことをいきなり書くより、やったこと→ Keep Problem →分かったことの順で書いた方が、日報に慣れていない人でも書きやすいし説明しやすいよ
  • あくまで個人的なオススメだから、実際に使ってみて自分に合ってるか判断してね

YKPWT とは

YKPWT は

  • Y やったこと
  • K Keep
  • P Problem
  • W 分かったこと
  • T 次やること

の略です。役割としては

  • Y → その日の業務、事実報告
  • K・P → 所感をまとめる
  • W 分かったこと → 所感から内省、分析
  • T 次やること → 得られた学びを行動につなげる

という構成になります。少し項目が多い感じは否めないですね。

YKPWT は内容から見てわかる通り YWT と KPT を混合させたフレームワークです。ただ混ぜただけのように思われるかもしれませんが、日報に関しては YWT や KPT よりも YKPWT の方が良いと個人的に感じます。

ちなみに YWT と KPT については、以下の記事でよくまとめられています。

yoshitsugumi.hatenablog.com

KPT より優れている点

その日の業務内容が書ける

日報は個人の振り返りだけでなく、報告先(上司やメンターなど)へその日何をやったのか報告する意味もあります。

KPT で振り返るとその日の業務内容を書く枠がなく、その日何をやったのか報告することができません。

良かったことの深掘りができる

日報に限らず KPT でありがちなことですが、Problem と Problem を解決する Try に意識を向けすぎて、 Keep の深堀りが足りないことがあります。「じゃあ良かったことはそのまま続けていただいて…」で終わってしまう例を、何度も見たことがあります。

Keep も深堀り次第では型化のキッカケを見つけたり、良かったことを見つけるスキルの向上になったりします。

YWT より優れている点

自分自身を褒める要素がある

日報のモチベーションの観点から、自身の成長を感じることは大事だと思います。

YWT は振り返りのフレームワークとしては優秀ですが、学びを得ることに特化しすぎている気がします。もちろん学びを得ることは、自身の成長に繋がる大事な点です。ですが学びを得ることだけでなく、その日の良かったことを確認するだけでも自身の成長を感じることが出来ます。

  • 他の人には当たり前のことでも、自分が今までできなかったことが出来た!
  • 学びになるようなことじゃないけど、いい感じの動きができた!

これらを学びにならないからといって、書かないのはもったいないです。

Y→W の難しさを緩和している

個人的に YWT で一番難しいことは、やったことから分かったことを考えることだと思っています。やったことから分かったことを加筆するとき、よく起きやすいのが…

  • 時間がかかっている、気がついたら 30 分近くも経っていた
  • やったことからどういう背景で分かったことが出てきたのか、報告先にうまく説明できない・伝わらない

だと思っています。

これはやったことから、分かったこと(≒ 学び)をいきなり思いつこうとするのが難しいからだと感じます。

YKPWT では、やったことと分かったことの間に「やったことの結果」を書く作業を追加しました。それは Keep と Problem です。

まずは良かった点と反省点を整理して、次に良かった点と反省点から学びを得るフローになっています。良かった点と反省点を出すことはそこまで敷居が高くないことと、自然と分かったことの理由づけができるので、質の高い Y→W を書くことが出来ます。

やったこと

管理画面の E2E テスト(nightmareJS)作成 6.5h

Keep

Problem

  • 間違って git reset をしてしまい、3時間分の作業が消えてしまった
  • nightmareJSで、ファイルのアップロードができなかった

わかったこと

  • CUI 以上に、GUI で全ファイルの git reset は簡単に出来てしまう
  • Vue インスタンスのプロパティの値を変えないと、nightmareJS を使って input の value を変えてもテストできない
  • nightmareJS 単体では、テスト中にファイルのアップロードができない
  • nightmareJS で悩んでいることを、nightmareJS の処理で解決する必要はない

次やること

  • GUI 上で git reset するときは、全ファイルではなく1ファイルずつ git reset する
  • vue 周りのテストをするときは、なるべく vue でテスト用のデータを用意する methods を作成する
  • ライブラリである nightmare-upload を使ってみる

最後に

この YKPWT は個人的なオススメです。人や環境によっては別のやり方のほうがあっているかもしれません。

ですが、日報をどう書けば良いか悩んでいる人は、まずこの YKPWT を試してみましょう。それから自分のやり方にあっているか考え、改良するか別のやり方にするか検討してはいかがでしょうか。

「メッセージが少なくとも 1 回配信されること」にまつわる SQS 使う上での注意点

この記事は Willgate Advent Calendar 2018 - Qiita の 9 日目の記事です。

以前弊社のブログで、 Amazon Simple Queue Service (以下 SQS と呼ぶ) を導入した例についての記事を書きました。

tech.willgate.co.jp

当時は「メッセージが少なくとも 1 回配信されることしか保証されていない」ということがイマイチピンときていなかったため、調べながら導入・実装に当たっていました。

今回は「メッセージが少なくとも 1 回配信されることしか保証されていない」ことで、実装時に何を気をつけなければいけないか分かったことをまとめます。

保証されていることは「メッセージが少なくとも 1 回配信されること」のみ

まず前提として、SQSは「メッセージが少なくとも 1 回配信されること」しか保証されていません。そのため以下のようなことが起こります。

  • 同じメッセージを重複して取得した
  • 別のシステムからA, B, C, Dという順番でメッセージを送信したが、受信するときにはB, D, A, Cという順番で取得した。
  • SQSにメッセージが存在してるにも関わらず、空のレスポンスが返ってきた
  • 削除済みのメッセージを取得した

一つずつ見ていきましょう。

同じメッセージを重複して取得した

「少なくとも 1 回配信」ということなので、同じメッセージを複数取得することがあります。

対処法としては、「メッセージ ID を見て、重複していた時には重複を消す」といった処理の追加が挙げられます。

別のシステムからA, B, C, Dという順番でメッセージを送信したが、受信するときにはB, D, A, Cという順番で取得した

SQS にはスタンダードキューと FIFO キューというものが存在します。この現象は SQS のスタンダートキューで起きる現象です。

「キューは普通、先入先出し(FIFO)じゃないの?」というツッコミが来そうですが…残念ながら、スタンダートキューではメッセージ送信の順番は保証されていません。もし、メッセージ送信の順番を保持してほしいならば、 FIFO キューを使いましょう。

2018/12/25 現在、東京リージョンでも FIFO キューを使用することができます。 aws.amazon.com

FIFO キューを使用しないならば、パッと思いつく限りだと「メッセージに送信時間を含ませ、メッセージをキューから受け取った後に送信時間でソートする」でしょうか?

確実にできる保証はないので、出来れば FIFO キューを使う方が良いかなと思います。

SQS にメッセージが存在してるにも関わらず、空のレスポンスが返ってくる

こちらバグではなく、どうやら仕様のようです。

docs.aws.amazon.com

Amazon SQS は分散システムであるため、キューにあるメッセージが非常に少ない場合は、受信したリクエストに対して空のレスポンスを表示する場合があります。

対策としては ReceiveMessageWaitTimeSeconds を1秒以上に設定する、いわゆるロングポーリングを設定することが挙げられます。

例えば、ReceiveMessageWaitTimeSeconds を10秒に設定すると、メッセージを取得するまで最大10秒待つことになります。10秒の間にメッセージを取得できなかった時は空のレスポンスが帰ってきます。

詳しくはこちらに書いてあります。

docs.aws.amazon.com

削除済みのメッセージを取得した

こちらもバグではなく、仕様だそうです。

docs.aws.amazon.com

この場合、使用できないサーバーではメッセージのコピーが削除されず、メッセージの受信時に、そのメッセージコピーをもう一度受け取る場合があります。

どういった目的で SQS を使用するかによりますが、既にそのメッセージを使った処理が行われているか判定するロジックが必要になります。

例えば、メッセージに DB へ登録するための ID が挿入されているとします。その時は「保存先の DB を参照し、既に ID が登録されていた時にはメッセージを削除する」といった処理が必要になってきます。

まとめ

最初は SQS 特有の注意点が多くて、戸惑うことや面倒だと思うことも多いと思います。 それでも享受できるメリットの方がはるかに大きいサービスだと思いますので、是非プロダクトにてご活用ください!

ソースコードリーディングはいいぞ

この記事は Willgate Advent Calendar 2018 - Qiita 2 日目の記事です。

皆さんソースコードリーディングしていますか?お恥ずかしながら、僕は最近読むようになりました!

実際やってみると、ソースコードリーディングによって得るものが多いことを知り、今では読書感覚でフレームワークやライブラリのソースコードを読むことも…

今回は、ソースコードリーディングによって何が得られるのかについて書きたいと思います!

結論:ソースコードリーディングはアウトプットするチャンスの塊

何故ソースコードリーディングが良いのか。それは、ソースコードリーディングがアウトプットに繋がりやすいからだと僕は思います。

僕自身、アウトプットのきっかけとなっているのがソースコードリーディングによるものが一番多いです。

チャンスその1:業務で活かせる

ライブラリやフレームワークなどのソースコードを読んでいくと、細かい挙動まで処理を把握することができます。

すると、「思わぬ挙動によってバグが発生してしまった!」なんていうことを防ぐことができます。どんどん読み進んでいけば、「あのライブラリ・フレームワークについてならこの人に聞くと良いよ」という評価を得ることもできるかも…!

特にフレームワークソースコードを読むと、徐々に「良い設計とはなんなのか?」ということも学べるので、設計の勉強にもなります。

チャンスその2:ブログ記事のネタになる

ソースコードを読んだ結果わかったことをブログに書くだけで、立派なアウトプットの 1 つとなります。

僕も Laravel の Collection メソッドについて記事を書いていますが、1 メソッドだけでもなかなかの分量になります。

参考; cocoeyes02.hatenadiary.jp

チャンスその3:OSS に参加できる

ソースコードを読み進めていくと、「あれ? 何故ここでは、こんな処理が無いのだろう?」「あれ、ここにエラーハンドリングが無いのは何故だろう?」など疑問点が出てくることがあります。それは、思想によるものだったり、単なる考慮漏れだったり…様々な理由があります。

そんな時、もちろん身近で詳しい人に聞くのもありですが、issue や pull request を立てるというのも手です!

僕自身もソースコードを読んでいて、疑問に思ったことや思ったことを何回か issue に立てています。

github.com

github.com

issue や pull request を立てると GitHub では 1 contributionとして扱われるので、commit 以外でもcontributionの草を生やしていくことができます。

最後に

今回あげたアウトプットチャンスは、あくまで一例です。他にも LT 会やセッションの登壇ネタになったり、読み進めていけば執筆のチャンス…なんていうこともあるかもしれません。

「最近アウトプットしていないなあ…」と悩んでいる人は、ぜひソースコードリーディングをお勧めします!