コードレビューについて考える

いよいよあと二日で検証環境にリリースだぜ!
今月残業100hこえたぜ!死にそうだぜ!
こんばんは、お久しぶりです。カバサワです

コードレビューについて考える

最近、ほぼほぼ新卒3人+αのコードのレビューに1日の1/3くらい使ってます。
来月から3年目になるということもあって、一旦ですね、二年前の自分のような初心者に向けたプルリクを出すときの心構えや、プルリクについて色々振り返ろうと思う


ここから心構え編

1.テストをちゃんと通してあること

そもそもの話として、動かないコードをレビューしても意味がない。
以前あったのが、「一番厄介な処理は書いてないんですけど、プルリクを送りました!」
っていうのがあって、一度レビューを通したものの、後にそこの修正がコード全体に影響を出してほとんど構成が変わったコードで再度プルリクを出されて、めっちゃ時間の無駄を感じた。
最低限、考えられる正常系だけでも通してもらわないと、コスト的にはそぐわないかな、と

2.不要な変更が入っていないこと

リファクタしながらやってる 技術的負債を返済しながらやってると聞くと聞こえはいいけど、個人的にリファクタは優秀な人が本腰入れてやらない限りデグレが最も発生しやすい行為だと思う。
今日あったのが、ここエラーでるから少し処理を変えたっていうので、そこコメントアウトすると他の画面で動かなくなるんだけど。。。っていう奴
新入りの君の知見よりは実績のあるコードの方が信頼できるとは思わんかね

3.レビューもらったところはきちんとなおす

レビューもらったら適切に議論すべきだと思う。レビューしてくれる人が必ず正しいとは限らないので。
ただ、レビュー受けたところを無視して修正コミットしてこないでください。
コメント全部読んで、理解できないところは議論して、納得して修正してもう一度出してきてください。
その際ちゃんと1.2ができているか確認してきてね。



ここからコード編

4.未使用変数や未使用関数がないこと

少なくても小さい修正に対して、使っていないコードが存在するのは悪だと思う。
基幹部分の変更や新規機能開発のためにTODOがのこっている場合は別として、いらないコードはそれだけでレビューの妨げになるからやめてほしい

5.無駄に変数をつかいまくる

配列操作の時などにもよくあるけど、無駄に$tmpを用意してしまう奴
普通にみずらいし、命名がカオスになってくるから不要な変数は用意しないでほしい

6.謎ネーミングセンス

フレームワークやコード規約に沿って適切な名前をつけてください。
空気だけじゃなくて、他のコードも読んでください。
tmp_idArrayとかいう名前見たときは素直に引きました。なんだそれ
あとデータベースのカラム名にlabel1, label2とかいう謎命名するのやめてください、なんだこれ。

7.マジックナンバー祭り

countArray == 20とかやめてくれ
DEFAULT_NUMとか定義してくれ
個人的にはactiveFlg == 0もゆるせない
せめてactiveFlg == IS_ACTIVE とか isActive == trueとかにしてくれ

8.関数長杉内

validationが長くなるなら、別関数用意するなり、フレームワークが用意しているものを使ってくれ
よみずらい、デバッグしずらいと本当にひどいことになるので、とにかく簡潔に書く
なるべく簡単に書こうとすれば、自ずと短い関数で構成された読みやすいコードが欠けると思う

9.スコープ広杉内

とりあえずグローバル変数で持たせればおk的発想はやめましょう
思いもよらぬ箇所で変更が入って、処理を追うのが難しくなります。だいたいJSのバグってこれだと思う

10.Gitを理解してくれ

「プルリク出しました!リリースブランチにプッシュしておきました!」って言われてファッ!?ってなった。gitの基本的なコマンドはもちろん、なんのためにブランチを分けて、何のためにプルリク出しているのかを理解してほしい。「push -fしたら直ります!」じゃねぇよ。荒療治ってレベルじゃねーぞ



他にも細かいところはいっぱいあるんだけど、自分がコードレビューで指摘するのはこの辺が多い印象
こっちの実装の方が早いよ!なんて言える難易度のものじゃなくて、本当に簡単な修正に関してもこんだけのことがボロボロとでてきます。

新卒のときの気持ちを忘れずに引き続き精進を重ねていきます

最近の楽しいこと、悲しいことをなんとなくまとめておく

前回から一ヶ月しかたってないんですね。
個人的には半年くらい書いてない感じがします。カバサワです。
最近全然技術的なことをしていないので、最近のお仕事、楽しいことと悲しいことをなんとなくまとめておきます

最近のお仕事

既存システムにある機能を新システムにお引越ししています。
主にフロントのJavascript書いていますが、部下の書いたPHPのコードレビューをしています。
コードレビューっていってもあいつらまじでプルリクしないからね。できましたっていってチケット閉じるからね。殺すぞ
あげく俺がサンプルで書いたコードコピペしてプルリクしてきたぞ。変数名くらい変えろや。殺すぞ

前回の反省から、しっかりと見積もりをして開発を開始したのですが、メンバーの習熟度が低いので、早くも炎上する気配を感じています。
なので僕はリリース直前でもないのに月100h残業ペースでお仕事するのでした。

そして外国人のメンティーもいるので、もうはんぱなくやべーっす。
〆会発表して!って言われたけど、「PRJ一週間遅延ですかね!」って言ったら諦めてくれました。
上司がマネージャを説得しに行く姿、かっこよかったです。

楽しいこと

・仕事がなかなか忙しい
→忙しいアピール大好きですからね

・裁量が増えた
→部下?が3人できました。人使うの楽しいです

・周りからの期待がすごい
→そういうのに敏感なんです。〆会で発表よろーとか言われる。無理ですと断ったけど。

・部署での発言力が強くなった
→前までは何か言っても「うん。。。」みたいな感じだったけど、反応が良くなった。

・英語を結構使うようになった
→相変わらず発音はやばいですけどね。この会社選んだ一つの理由なんで満足です

・半年前なら無理だった仕事が簡単にできるようになった
JQuery力だけが伸びていきます。

悲しいこと

・部下の能力
→まぁ下っ端に渡される部下なんてそんなもんですよね。自走できないし、そもそも補助しても普通にすら満たない。

・部下のやる気
→リーダーでもないんだし、そこまでいってもねぇ。という気持ちが。
無理して詰めて、心が病んだら俺の評価下がるしね

・業務時間にコード書けない
→そりゃあもういろんな人に話しかけられます。定時過ぎてからコーディングする毎日

・新卒に対する部署の姿勢
→そもそも英語化進めんのか、どうなのかはっきりしてほしい
マネージャ陣が外国人だからって遠慮してる感はんぱない
他チームの人は関わろうとしない。メンターに丸投げというか、見て見ぬ振りしてる感はんぱない

・仕事の内容
→全く技術的なことしていない。問題に対して技術じゃなくて力で解決しようとしている
綺麗なコード、読みやすいコードに対する知見は広がったけどさ。

・自分の姿勢
→調子がいいときは、我ながらすごい量のコード書いて(長けりゃいいってもんじゃないけど)、チケットの消化率もすごいけど、そうでない時がひどい。
「仕事をすること」に注力して、長い目で自分の技術を磨いている意識がない。完璧土方

・自分の英語
→今日もペアプロしてたんですが、終わった後に「結局今日は何をやったの?」とメンティーに言われ心が折れました。
何やったのってお前、コピペするだけの機械かよ。What should I do?じゃねぇよ。




こんなかんじです。
とりあえずメンティーに言いたい言葉を後輩に英訳してもらったのでのせておきます。

・エディタ開いてる時間とメッセ開いてる時間どっちが長い?

  • > which have you spent your time more, for implementing code in editor or for chatting?

・仕事終わらせる気あるの?

  • > Are you even trying?

・質問はまとめて、かつ分かりやすくしろ

  • > I really want you to make clear, and collect what you want to know/solve before you give me question.


最後の一つは自分でも耳が痛いです。
人に優しく、自分に厳しく生きたいですね。

今の部署を知的にdisる

新年明けましておめでとうございます。
今年の目標はTOEIC900とるだけです。他には何もありません。


次のプロジェクトにアサインが決定し、前回プロジェクトの後始末も終わったので、いまいちど前回のプロジェクトを反省し、次につなげるために今日は知的に今の部署をdisっていこうとおもいます。


とりあえずフォーマット意識せずに箇条書きでいきます。

-要件定義編-

1.システムの開発に業界知識が必要で、その要望に沿ったシステムに落とすのが難しい。
知的にdisると言っておきながら最初から知的じゃないアピール
そのため要望にfitしたシステムが提供できている気がしない。あるいは要望は満たせたけどUIが終わっているものがある

2.そもそも営業側の人間もシステムを実際に使う人間ではない人が担当者なので、その人が必要と言った機能が本当に必要かどうかもわからない。
1年ほど前に数千万投資したシステムの稼働が全体の2割切りました。payって概念しってます?

3.実際にシステム使う人もどんなシステムがベストなのかは知らない。
優秀な寿司職人が優秀な寿司握り機作れるかって言われたら、別の話ですしね。万人が操作できる寿司握り機がほしいんです。

4.それでも要望を聞くと既存のシステムに引きづられるので、リプレースメントという概念が脅かされている
同等の機能を使いやすくしてほしい。と言われても、まず同等の機能を洗い出し、不要なもの削除、必要なもの追加、UI策定とやること多すぎ、見積もり甘杉内

5.要件ありきではなく、スケジュールありきの開発で、デスマーチが発生。3ヶ月?終電かつ土日出勤する人が出る。

-メンバー編-

1.新卒を詰める(まじで教えないけど、本気で怒る)とかいう謎文化があったしく、中堅(5年目~主力)クラスがほとんどいない。今は改善されてるらしい
1年間で5人やめさせたとかいう猛者がいたらしい。結果メンバーはおっさんと新卒というギャップがある

2.現在のプロジェクトに最初から参加したエンジニアが存在しない。あるいは存在しているが現行のプロジェクトからは、中核を外れている
つまり現在の主力が途中から参加している。引継が正しく出来てるわけがなく、設計/実装が場当たり。
設計に関しては、リプレースメントの主要目的に対して致命的な不具合があり、技術的負債を抱えている(現在で4人月程度とのこと)
実装に関しては、全員がその場しのぎで継ぎ足していくため、ある画面で同じjsファイルが5箇所に散りばめられ、それぞれ呼び出されるという珍事

3.派遣社員が主要機能の実装を担っている
主要機能の実装を任せられる社員が存在しない。仕様共有のMTGである程度解決できたが、現行で不具合が起きた時に対応はできない

4.チームビルディングの意識がない。メッセで陰口が飛んでくる

5.問題を糾弾するだけで逃亡する人がいる。

-開発編-

1.gitの基本的なmergeをしてくれない人が割といる。
歴史こわれすぎぃ!

2.自分で動作確認して、プルリクだしてレビューしてmergeしようね。という方針を守る人が少ない。
不具合を事前に検知する意識が足りない。不具合が出てからdisればいいみたいな雰囲気がある

3.正しく進捗報告をできない人がいる。
「遅れてます!助けてください!」という以前に、遅れていることを認識できない人がいる。

4.インフラ関係との調整と実作業を別々の人が行い、抜け漏れが半端ない。
手順をレビューしてもらおうとしない。あるいは、渡された手順を確認せずそのまま実行しちゃう

5.検証環境が本番環境と構成が違う。設定ファイルに差分がある。
各サーバに担当者がいたのに放置。したのを俺に丸投げ(リリース一週間前)



うん、とりあえずやばいのはこのくらいかな。
うまく分けきれてない気がするけど、書き切れた感じはある。

要件定義編に関しては、なんかもうガチのSIerよんだほうがいいんじゃないかな、って今思いました。
残りは割と、僕個人の努力/布教活動でいい線いくんじゃないかって勝手に思ってます。
なんでもかんでも他人のせいにする/disるだけではなくて、自分に原因を探して改善していくほうが健全ですしね。

再来週あたりからまた忙しくなりそうなのでがんばります。

Android開発環境構築で悲しんだお話

やっとリリース終わりました。
hotfixの嵐ですが、もう年末まではゆっくりできそうです。
ということで、日中はもう本当に仕事ないので勝手にAndroid開発を進めようと思い、環境構築して色々はまったお話


Macに環境を作る

家のPCはMacなので、順当に用意しようと。
以前AndroidStudioを導入していたのですが、今月の頭についにv1.0.0がリリースされたという事でインストールを試みる
Download Android Studio and SDK Tools | Android Developers

セットアップをしているとJDKの場所を教えてくれろ。と表示されたので適当に検索

kabaclone$ find ./ -name jdk

はい、ないですね。
ということでjdkを落としにいく。jdk7以上じゃないとだめみたい

http://www.oracle.com/technetwork/jp/java/javase/downloads/jdk7-downloads-1880260.html
問題なくインストールできた。と思ったら、なにやらエラーが。
どうやらMAC OS 10.7以降じゃないとだめとのこと。

自分のPCを確認したら、まさかの10.6.8 足りてません。
App StoreYosemiteを落としにいく。
入手ボタンをクリックしても無反応。まさか10.6.8じゃいれられないのか...

ここまでが昨日のお話

会社のノートPCに構築する

そういえば会社からPC支給されてんじゃん!なんもしてねーけど!と思って、今日は仕事をしている振りをしながら、インスコ
android studioを入れて、JDK7も問題なくいれられたが、(相変わらずWin環境の環境変数設定めんどい)
いざ、アプリケーションをビルドしようとすると、なにやらemulatorでエラーが発生

HAXM is not installed

というやつ。
いやいま、SDKで入れたとこじゃないですか。
と思って色々ぐぐると、どうやらPCのメモリの仮想化が許可されてない様子。
という事でPCを再起動してBIOS設定を開く。

lenovoだとロゴ表示の時にF1キー
Security > Virtulization
みたいなところがあるのでそこを確認。すると、案の定Vt-xがDisabledに。

はい、あとはEnabledに変えて終わりですね。と思ってEnterを押すと、PCから「ピー」という電子音。
よく見たら、Vt-xの項目が非活性になっていて変更出来ない様子。
なんだよこのPC 開発用じゃねぇのかよ

ということで、色々まとめ

MacでAndroidStudio入れたいなら、OS変えなきゃいけない
MacでOS変えたくないならAndoidStudioやめなきゃいけない
でもEclipseでもJDKひつようじゃね...

会社支給のノートPCでやりたいなら、BIOS設定突破しないといけない
でも、USBで実機で繋ぐ分には問題ないんじゃなかろうか

会社のデスクトップでやる分には問題ないみたい。(ビルド確認済み
でも、会社っていう場所に制約されるの困るな。

という感じです。

思い切ってAir買うか、やっすいノートPC買うかで悩んでます。
とりあえず明日上司に俺のノートMacに変えてくんね?って頼もうかと思う

手順書を幸せにする

デスマももうちょいで終わります


リリースのために手順書かけって言われること多いと思いますweb系な方。
もしdeployも自動化されてるなら本当に素晴らしい事だと思うのですが、
ソースコードのdeployだけではなく、設定ファイルの更新だったり新ホストの追加だったりすると、
どうしても自分で手順を書かなきゃ行けない場合がありますよね。
そこで、最近知って便利だな、と思った物をいくつか紹介します。

1.長い名前のファイルをリネームしたい時

たとえばとあるサーバのService outを行いたい時。
たいていの場合はなんらかのhealthcheckを探しに行き、なければSoutしているんだな。って判定していると思います

mv healthcheck _healthcheck

こんくらいだったら良いんですが、healthcheckの名前がドメイン含まれててくっそ長い時とか結構めんどうです

mv healthcheck{,_bk}

こうすると、省略してかけて便利です。cpとかでもよく使えます


2.capやブロードキャストを利用して各サーバに、ホストごとにホスト名に関する処理を行う時

capistranoってめちゃくちゃ便利ですよね。サーバ台数が二台とかいう弱小サービスの方はあまり恩恵受けないかもしれませんが、
三台超えてくるともうヒューマンエラーの入り込む余地ありまくりです。三回繰り返すなら自動化しろ、とは良くいった物ですね。

cap command="hoge-command" TARGET=hosts

設定とかにもよるんですがこれでhostsに対してhoge-commandを実行出来ます。
ただ、例えばconfファイルの名前はそれぞれのホスト名にして、ちゃんと確認したいだの、
このホストからだけ同期されている事を確認したいなんて時に、「いや同じ操作しかできないんだからどうすんだよ」って悩みました

cap command="touch `hostname`" TARGET=hosts

例えばこれで対象のhostsに対して、それぞれhostnameの実行結果=ホスト名のファイル作成を行えます。
shellscriptのバッククォートという機能です。知らない人はぜひぐぐっておくと幸せになります。
ちなみにbash/kshでは$(command)でバッククォートと同じ動作が出来ますが、shellという環境依存になってしまうので、指向に併せてどうぞ、と言われました。

3.上2つを組み合わせてちょいとおしゃれな事がしたかった

ホストごとにバックアップファイルが作りたかったんだか、良く覚えていないんですが、こんなことがしたかったんです。

cap command="cd HOGE_DIR && cp -r *.conf{,_bk}" TARGET=hosts

(多分、どこかに移動して、そこにあるconfファイルのバックアップをとる的な
(いや同じディレクトリでバックアップとるなって話はおいといて。


これ実行しようとすると、

cd HOGE_DIR
cp -r *.conf *.conf_bk

どうやら内部では*.conf_bkこいつが解釈されずにエラーだして悲しみました。
いや*.conf_bkあるけど!みたいな。*を解釈してくれないんですね。二回目は。

で、どうやったかっていうと

cap command="cd HOGE_DIR && ls *.conf | xargs -I@ cp -r @{,_bk}" TARGET=hosts

こんな感じで書きましたとさ。xargsでlsの結果をひとつずつ渡して行くイメージですね。
(2使ってないってことに気づいた。もうぐだぐだだよぉ...




結論
capとshellすごい

lsyncとrsync時々fluentd

こんばんは、椛澤です。

同期に社畜と煽られても、すでに色々足りてないので甘んじて受けていれてます。

本当はめちゃくちゃ悲しいので、あんまり言わんといてやってください。

 

 

最近怖い事

あ、今日悪夢見ました。実家に強盗?泥棒はいって来たかと思ったら、カニバリズムな方が入って来て僕の腕が食べられました。もう胸に手を当てて眠れないね。

ということはどうでもよくて、最近怖い事があります。

それは、「あいつ●年目なのに●○もできねーのかよ」っていうことです。

上のセリフは、僕自身が先輩に対してよく使う言葉なのですが、これよくよく考えたら俺に降り掛かるのもそう遠くない未来だな、と感じたので、ふと寒気が走りました。

具体的には某3年目の先輩だったり、5年目の先輩だったりします。

 

実務に併せて言うと、もちろん担当範囲は決まっていてその分野に詳しいのは当たり前なんですが、

共通基盤(DBだったり、サーバ構成だったり、ログ、監視、メンテにおける手順)に対する知識、経験が欠落していたり、挙げ句そんなことやってたの?!とか言う先輩がいてため息をついていたのですが、自分も仕事任せられなかったらこうなるんだろうな、と。

 

そこで一度初心に返り、昨日よりも何か出来るようになった、何かに疑問を持てるようになった、何かを触った自分を具体的にまとめる必要があるなーと思った次第です。

ってことで、少しだけ更新の頻度をあげて行こう、って思いました。

 

lsyncdさわった

ということで、今日はlsyncdを触りました。

詳しい説明は


リアルタイムミラーリングツール導入(lsyncd+rsyncd) - Fedoraで自宅サーバー構築

lsyncd と rsync でホスト間でリアルタイムにファイルを共有する - ようへいの日々精進 XP

CentOS6.5でlsyncdを動かす - Qiita

 

この辺の説明が分かりやすいと思います。

それぞれの記事に書いてあるようにホスト間でリアルタイムにファイルを共有します。用途としては小さなファイルの同期。画像なんかがよく使われているそうです。

 

何がすごいって

今までrsyncしかしらなかったので、あるホストにあげたファイルを各ホストに配るのにはcrontabに登録したrsyncの実行だけで住ませていました。

crontabによる実行だと

・決まった時間のみ(非同期)に実行される

→無駄なrsyncが走る

→必要なタイミングで手動たたかなきゃいけない

なんて事がおきて、結構歯がゆい思いをしました。

(そもそもリアルタイム性が求められるのにcrontab使うなって話ですが。

(かといって、共有領域に対して頻繁I/Oはしらせるのはボトルネックになりますしね。

 

しかしlsyncdはlinuxカーネルのinotifyって言う機能を用いるので、対象のファイルシステムに対して操作が行われた事を監視してrsyncを走らせる事が出来ます。

なので厳密にリアルタイムかって言われると、あれですが、イベント駆動(今回の例で言うなら、ファイルがアップロードされたら)でリアルタイムベースでファイルの同期が行われます。これは感動

 

感動していたら...

某同期に熱のこもった感じでlsyncdはんぱねーよ!!と語ったところfluentdやれよとさらっと言われました。

fluentdってログをいい感じにまとめる奴じゃないっけ?

と思って少し調べました。

Fluentdで始めるリアルタイムでのログ有効活用 (1/4):CodeZine

今さら聞けないfluentd〜クラウド時代のログ管理入門(1):増えるログ、多様化するログをどう効率的に運用するか (1/2) - @IT

 

めっちゃログ管理やん。いや、俺の伝え方がまずかったんだろうか。

プラグインでファイルの入出力出来るから、多分そう言う使い方してるんだろうと思われたんかな。

 

Fluentdのお勧めシステム構成パターン

素敵なslideshareを見た感じも画像とかのファイル共有には適さなそう。

あくまでログのフィルタリング、分析、出力に適したツールな印象。あーでも使ってみたい。

 

今日はこんなところで

異動する先輩から学んだ5つの事

こんなタイトルにしたら人の目に止まるんですかね。

今週全部24時で帰っているので、残業時間がすごいことになっています。

流石に疲れました。椛澤です。

 

先輩がいなくなる

会社に入ってから何度目でしょうか。再び先輩が居なくなります。流石に悲しいです。

当の先輩からは結構色々なことを学んだので、なんとなくまとめおく

 

1.生産性をあげろ

つまんない仕事でもだらだらやってもしょうがないから、その分生産性あげていいことやろうぜ。プラスでなんか学ぼうぜっていう話。

若手だからまじでしょうもないことって思う事もたくさんあるけど得るものはいくらでもある。とのこと。

実際、どうでも良い仕事には本気で手を抜く自分にはすごく耳の痛い話だった。

先輩はテストやってる時も常に自動化していたのが印象的だった。

 

2.調整をさぼるな

10の仕事があって、10の労力を割くんじゃなくて、7の仕事にできないか。1の仕事は誰かに任せられないかを常に考えろって。

仕事をサボれっていう意味じゃなくて、目的に対して本当に10の仕事が必要なのか、効率的にできるとことはないかをちゃんと考えて、一番いい方法を採用しようという話。

下っ端は「これお願い。」とポイッと投げられる事が多いけど、実際に話を聞いてみると、実はすでにある機能だったり、運用回避ができることなんて多々あるんだから、一つ踏み込んで調整しろという話

 

3.伝え方を工夫しろ

誰かに何かを聞きたい時、不具合が見つかった時、機能の実装をお願いするときは、要件だけ伝えるのなるべく避けてる。って言う話。

ロジカルシンキング的に要件だけいかに短く伝えるかがよく焦点に当たるけど、それだけでは角が立ったり、実は無駄にしている事もある。っていう話。

不具合が出た時、再現手順とデータだけ投げるんじゃなくて、「ここの確認させてもらっていいですか?」で切り出して話せば、自分の勘違いも防げるし、相手からの印象も変わるんだから、伝え方一つだけ工夫しろ。と。

結構丸投げしたり、はやとちりする自分には目から鱗だったりした。

自分では最高にロジカルに伝えられたぜって思っても案外伝わらないこと多いですしね。

 

4.やりたいことは曲げるな

仕事に振り回されたり、先輩に振り回されたりして、自分のやりたい事からそれたりすることばっかりだと思うけど、それでもやりたいことはちゃんとやろうと言う話。

別に誰かに話さなくてもいいし、誰にも公開なんてしなくてもいいから、やりたいことはちゃんとやれ、と。

周りからFBもらったり、批判受けてブラッシュアップできれば最高だけど、まずは自分でやることから始めろ。と。

誰かに言う目標と自分で決めた目標は全然違っていいじゃんっていう話

会社に入って、目標設定がめちゃくちゃ厳しくて、その視点が全く持てなかった自分にはこれまた刺激になる話だった

 

5.会社は給料稼ぐための手段か

今日最後のランチをしてぼそっと言われて、ハッとなった。

先輩は会社以外にも色々稼いでいて、そうなった時初めて、会社で評価されたり残業してお金稼ぐことに興味がなくなったっていう話。

今、24時まで働いて、得る物はたくさんあるだろうけど、それってお金のためにやってるの?それともサービスのため?自己研鑽だったり自己実現のため?

周りは結構ドライな人が多いけど、この人まじでドライ、というか激アツなんだな、って思った。

 

 

 

なんか全然まとまってないけど、こんな感じの事が印象に残ってる。

エンジニアとしては特別何かを学んだ印象はないけど、仕事のやりかたはかなり色々と学ばせてもらった。

まだまだもっと教えてほしい事はたくさんあったけど、明日が最終日。

次の場所でのご活躍を祈っています