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

ポンコツWebエンジニアのかっこ悪く生きる日記

頭の中にあるうちは何だって傑作

2017年2月23日 明けましておめでとうございます

今年からGHEに毎日Activityログをつけるようにしているのですが、ついそっちに注力してしまいブログの更新が疎かになっていました。 そろそろActivityログの方も習慣化できてきたので、今年も今日からブログを更新していきます!

明けましておめでとうございます!今年もよろしくお願いします☺

3行まとめ

  • お問い合わせ対応で一日が終わってしまった感
  • 最近はバッチ処理を書いてます。
  • 昨日弊社に @t_wada さんが訪れ 「@t_wada さんを囲む会」 が行われました。
    • 非常に感銘を受けて背中を押される感覚を味わいました。
    • どれくらい続けられるかは分かりませんが僕も write code everyday していこうと思います!
    • ならびに、良い日課を作り省エネで実行していこうと思いました。
      • このブログをまた書き始めたきっかけも昨日の会が影響しています。感謝✨

詳しくは @inouetakuya の以下のブログをご覧ください 💁

blog.inouetakuya.infof:id:yutokyokutyo:20170223195546j:plain

f:id:yutokyokutyo:20170223195642j:plain

ひとこと

ブログを書かない期間が続くと「あっブログ書かなきゃ!」という気持ちが沸々と湧き始めるのは根底にブログを書く習慣が根付いているからなのかなと思いました。今年も頑張るゾイ!!

やっていき

今年から部署とサービスが異動となり「グーペ」というホームページ作成サービスでエンジニアをしていくことになりました。 楽しく圧倒的に成長してみんなを支える側に回っていくぞ〜!

goope.jp

2016年12月26日 年の瀬とふりかえり

3行まとめ

  • 2016年下期の半年間をカスタマージャーニーマップ形式でふりかえりメンバーと共に軽くふりかえった
  • 開発日直day
    • チームの方々のサポートを受けながらバシバシやっつけた感
  • お引っ越し

ふりかえり会スケジュール

  1. 主旨説明(5分)
  2. 一枚の大きな紙に、時系列に沿って 内容, 感情や気持ち, 学び の軸で書いていく(7分)
  3. 各メンバーのふりかえり内容発表(3分)
  4. フィードバックや質問コーナー(2分)
  5. 3、4 の繰り返し ×メンバー数
  6. ふりかえり会長より総評(3分)

ふりかえり会ふわっと感想

  • 7分間で個人のふりかえり内容を紙にまとめなければいけなかったけど、全然思い出せなくてふりかえり不足を感じた。
    • ふりかえり会が終わった後にたくさん思い出して追記した。
  • ふりかえり会メンバーの気付いたことや学びを共有していただき、とても価値のあるお話を聞くことができた。
  • ふりかえり会はしばらく行われていなかったけどやはり良いものだなぁと改めて感じた。今後もなんらかの形で続けていきたい。
  • 今ちょうど2016年下期の評価資料を書いているが、毎月のふりかえり不足により相当時間がかかってしまっている。これは結構ダメな気がするので来年からは絶対に毎月ふりかえることを宣言します!

brew update できない (error: The last gc run reported the following. Please correct the root cause and remove .git/gc.log.)

brew update しようと思ったらエラーとなってしまった。

% brew update 
Updating Homebrew...
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove .git/gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to remove them.

どうやらゴミを溜め込みすぎてしまったらしいのでガベージコレクトしてやれば良さそう。

しかし .git/gc.log. とは一体どの場所のことを言っているのだろうか。

ひとまず頻繁に使用しているリポジトリから git gc , git prune を使ってお掃除することにした。

% git gc                                                                                                                                                              (git)-[master]
Counting objects: 220332, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (50809/50809), done.
Writing objects: 100% (220332/220332), done.
Total 220332 (delta 167795), reused 219889 (delta 167392)
Checking connectivity: 220332, done.

% git prune                                                                                                                                                           (git)-[master]
Checking connectivity: 220332, done.

しかし、効果はなかった ... 。

homebrew 自体を少しだけ疑ってみる。

% brew doctor                                                                                                                                                         (git)-[master]
Your system is ready to brew.
% brew cleanup

特に異常なし。

エラーでググってみる。

stackoverflow.com

なるほどぉ。

しかし .git/gc.log. とは一体どの場所のことを言っているのだろうか。

ここだったようです 💁

% ls /usr/local/Homebrew/.git/gc.log
/usr/local/Homebrew/.git/gc.log
% cd "$(brew --repo)"
% pwd
/usr/local/Homebrew

% git prune && git gc                                                                                                                                                 (git)-[stable]
Counting objects: 71967, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (19701/19701), done.
Writing objects: 100% (71967/71967), done.
Total 71967 (delta 51484), reused 70860 (delta 50377)
% brew update
hoge
hoge
🍺
Already up-to-date.

年末の大掃除っぽいこともしつつ学びがありました 📝 (というのを先輩エンジニアとやってました)

2016年12月21日 川島先生のPHPフレームワーク(Laravel)入門を視聴した 👀

schoo.jp

  • 弊社エンジニアが先生として schoo にご出演されていました。
  • 視聴者への配慮が素晴らしく、丁寧で分かりやすい網羅的なご説明でした。笑顔も最高でした😊 ファンになりました!
  • Laravel を使ったことがなかったので導入の授業とてもありがたかったです。
    • Homestead 初めて知りました。
    • モデルは Eloquent で書かれているのだなぁ
  • Rails は経験したことがあるのですが PHPフレームワークは経験がなかったため比較しながら理解することができました。
  • 突き詰めていくと Rails と Laravel は真逆。なるほどぉ。
  • 「はい!完成ですね!」からの EUC-JP で文字化け〜の流れが親近感があって面白かった😆

僕も強くなったらいつか出演してみたいなと思ったのでしたまる。☺

f:id:yutokyokutyo:20161221194128p:plain

2016年12月20日 セキュアコーディング講習会

3行まとめ

  • あの徳丸先生が直々にお話されるセキュアコーディング講習会を受けさせていただいた。
    • 実際にデモを行っていただいたことで脆弱性をついた攻撃の様子を直接見ることができとても理解がしやすかった。これぞ百聞は一見にしかず。
  • 今後の業務にとても役立つであろう知識が身についたことはもちろん、個人で開発を進めているWebアプリケーションが全然セキュリティを意識していない設計だったことに気づいた。
    • 初期開発が終わって運用ができる状態になる前にセキュリティを強くしておきたい。
    • いただいた資料には こうするべき項目 がたくさん書いてあったので、一つづつ自分のアプリケーションと比較して足りない点を埋めていきたい。
  • フレームワークを使うことで自動的にセキュリティも担保されることを知った。
  • 研修を受けてそれで終わりにしたくない。入社時に少しだけ徳丸先生が書かれた『安全なWebアプリケーションの作り方』を読んだけど、今読んだらまた考えることが違うのだろうなと思ったので読んでみることにした。

http://booklog.jp/item/1/4797361190

フリースペース

【宣伝】今年もペパボの新卒採用サイトが設立されましたぞ 😆 ✨

僕もちょっとだけいます。

recruit2018.pepabo.com

コードレビューするのが怖いと思っていたエンジニアが半年間コードレビューを経験して思った 10 のこと

これは pepabo Advent Calendar 2016 - Qiita の14日目の記事です。 昨日は id:Fendo181 さんの 日報サービス「DuPo」を作った話でした!


それは、今からちょうど半年前のこと。

海の香りと共に暑い夏がやってくる ... 甘酸っぱい青春が再び来るのではないかと予感させる ... そんな季節でした。

開発チーム内で行っていたスプリントレトロスペクティブの時間に、チームメンバーから「そろそろコードレビューをやってみよう!」と提案があり、それから本格的にコードレビューをやり始めることになりました。

早いもので、あれから半年が過ぎました。

今宵は年の瀬ということもあり、ふりかえりを目的として半年間コードレビューを積み重ねたことで僕の中で起きた考えの変化や感じたことについて 10 個書き出してみることにしました。

教育関連に興味がある方や組織の成長を考えている方、僕のようにコードレビューに対し臆病になっている方に向けて、何か感じていただければ良いなと思って書きましたのでどうか最後までお付き合いいただければ幸いです🙏

目次

  1. コードレビューするのが怖かった。できないと思い込んでしまっていた。
  2. どんな内容でコードリーディングを行ったのか
  3. コードレビューに自信がないときはどうすれば良いか
  4. レビュー依頼時にレビュアーのことを考えるようになった
  5. レビューは取り込むもの
  6. チーム間で意識の摺り合わせを行うことでレビューが円滑に進むようになる
  7. 研修時の絶対良感が根底に染み付いている
  8. インデント修正は人間がやるべきではない
  9. コードレビューの目的
  10. 楽しく円滑にコードレビューする簡単な方法
  11. 最後に

1. コードレビューするのが怖かった。できないと思い込んでしまっていた。

お恥ずかしい話、当時僕はコードリーディングすらまともにできず、個人の開発業務ですら上手くいかないお粗末な状態でした。そのため、そんな状態の僕がコードレビューなんてできるはずがないと思い込んでいました。なぜなら、他人のコードレビューをするためにはまず個人の開発業務の中で培うコードリーディング力が必要だと考え、コードリーディングが出来て初めてコードレビューができると自分の中で勝手に学習の段階付けを設定していたためです。例えば、FF的に言うと サンダガ を覚えるにはまず サンダラ を覚えてからという順番があることと同様に考えていました。

しかし今だからこそ思えるのですが、それは間違っていました。

コードレビューとコードリーディングは縦に学習の段階付けがされているものではなく、それらは並行していて相互的に学習が可能でした。 そして、サンダガ を覚えるには サンダラ を習熟するのではなく、まずは サンダガ を体験してみることこそが学習の近道だと分かりました。

2. どんな内容でコードリーディングを行ったのか

とはいえ、やはりコードリーディングすらまともにできないエンジニアがレビューを行い LGTM としたプルリクエストが本番反映されるというのはちょっと怖いですよね。例えば、家電製品を量産している工場の新人チェック員が「何をチェックするのか全然分かってないけど、とりあえず大丈夫そうだから OK です!俺まだペーペーなんで、なんでも経験かなと思ってます!」といった具合ではちょっと不安です。というか問題です。

そこで僕の場合は、僕の不足分をチームメンバーに補っていただく形でどうにかレビューを体験することが可能となりました。

それでは具体的にどんな内容を行なったのでしょうか? それはシンプルに次の 2 点でした。

  1. 僕がコードレビューの一次受けを行う。
    • ただし、簡単なレビュー依頼であれば僕だけのジャッジでよしとする。
  2. 先輩エンジニアがコードレビューの二次受けを行う。

この体制は以下のメリットがありました。

  • レビュー不足によってサービスのコードに対し障害を招くような爆弾や技術的負債となりうるコードを反映させることなく安全性を担保できる。
  • 僕が判断した善悪のジャッジと技術力の高い先輩エンジニアの善悪のジャッジを直接比較することができる。
    • 良いことについては、そのまま継続していくべきだと自信が持てた。
    • 悪いことについては、何が悪かったのか、どこが考慮漏れとなっていたのかを知ることができた。

3. コードレビューに自信がないときはどうすれば良いか

なんとかコードレビューデビューを果たした僕でしたが、何回かレビューをしていくとある問題にぶち当たりました。 それは自分のレビューに自信が持てないことです。 なんとか先輩エンジニアのようにレビューをしたいと思っても「本当に僕が言っていることは正しいのだろうか?」と考え込むことがしばしばありました。 そこでチームメンバーにふりかえり会で相談したところ、以下のようなフィードバックをいただきました。

  • もちろん違和感を持った理由を明示して「こうするとより良いのではないかなと思いました」と自分で考えて改善案までコメントできたら立派だが、最初はそんなことまではできない。
  • 違和感を持つべき箇所は必ずあるので、その箇所について「なぜこのように書いたのですか?」と質問するだけでも良い。
  • 最悪スタイルガイドを知らなくても、間違え探しのように他のコードと比べながらコードを見てみると「妙だな..」と気づくことができる。
  • 何か疑問を持ったということは、やりたいことがそのコードから読み取れないからであって、必ずどこかに議論や改善の余地がある。
  • 違和感を持って提起しただけのコメントだけでも、レビュイーに再考させることで新たな発見が生まれたりすることもある。また、Github 上でのやりとりは Slack 上に通知されるため、これを見たチームメンバーからまた新たなコメントを貰えることだってある。そのような一歩は無駄にはならないので勇気を持って発言していこう。

当時とても納得しましたし「これならやっていけそう!」とテンションが上がったのを覚えてます。 今でもレビューするときには、このとき教えていただいたことを意識するようにしてます。

4. レビュー依頼時にレビュアーのことを考えるようになった

レビューをする立場になったことで、レビューし易いプルリクエストとし難いプルリクエストを区別できるようになりました。 例えば、レビューがし易いプルリクエストの特徴としては以下が挙げられます。(良いPRについては他にいくらでも既出のブログがあるのでざっくり述べます)

  • 意図がはっきり明示されていること
  • 一つのプルリクエストでやりたいことが一つとなっていること
  • コミットの粒度が適切で流れのあるものとなっていること
  • 動作検証結果やテスト結果が明示されていること
  • 関連する issue や PR のリンクが貼られていること

上記については分かっていたつもりではありましたが、先輩エンジニアのコードレビューをするようになってからは今までより一層第三者目線で一歩俯瞰した考えのもとの設計を心掛けるようになりました。

ただし、上の項目を満たしているプルリクエストは確かに見やすくレビュアーにとっては優しいですが、見やすさや分かりやすさを追求しすぎることで時間がかかりすぎてしまっては本末転倒です。そこで大切なのがレビュイーとレビュアー双方にとって最も効率の良いバランスを保つことだと思うのですが、先輩エンジニア達は皆そのバランスが上手く、彼らが書いたコードをレビューをすることでその微妙な平衡感覚を養うことができたと思います。

5. レビューは取り込むもの

これは新卒エンジニア研修を受けていたときに印象深かったエピソードです。 当時新卒エンジニア同士でコードレビューをするといった研修内容があったのですが、そこで指摘してもらった箇所について「修正しました」とコメントをしていました。 しかし、それでは直せと言われたから「はいはい直しましたよ。これでいいすか?」と言っているような感じになってしまい、レビュアーからレビュイーに対しての一方的なコードレビューとなってしまいます。 そこで研修担当さんに、本来コードレビュー文化のあるべき正しき姿はチーム間で議論をしてサービスにとって最終的に良いと判断したことを取り込むことであり、もしも修正するという内容なのであればそれはレビュアーの意見を取り込むことなのじゃぞと教えていただきました。 それからは 修正 という言葉は使わずに レビューを取り込む という表現を使うようにしています。

6. チーム間で意識の摺り合わせを行うことでレビューが円滑に進むようになる

ある日、チームで行っているスプリントレトロスペクティブにて「JavaScript のレビューについてオーバーヘッドが大きくなってしまっていないか?」という内容が議題に上がりました。 この問題の原因は、JS について統一されたルール(スタイルガイド)がチーム間において確立されていないことでした。

そこでチームのアクションとして JS に強いメンバーが先導する形で朝会後に Javascript-style-guide を5分間だけ読み進めることになりました。

すると、以下のような良いことが起きました。

  • 各個人のコードに対する流派のような「こう書くべき」という認識が多少異なっていることが分かり、その場で話し合うことでチーム間のスタイルガイドを確立することができた。
  • 今まで背景がブラックボックスとなっていたコードについても、一般的に最新の理想の環境では「こう書くべき」だがサービス固有の問題によって「こう書くべき」となっている といった作成経緯を把握することで、既存のコードについても理解が深まった。
  • チーム間で共通したガイドラインが生まれたことによりレビュアーのコメントが楽になった。
    • 例: 「ほら!これ前に一緒に勉強したところだよ〜!」「根拠はスタイルガイドにあります。」などなど。
  • 単純に JS 苦手な人の学習にもなりチーム内のボトムアップ効果があった。
    • お恥ずかしい話、僕はこの時間で初めて ES5 と ES6 があることを知り、担当するサービスが IE に対応しているため JS が ES5 で書かれているという事実を知ることができました。

チーム間でレビューのオーバーヘッドが大きいと感じた際には、このような手法を試してみると良いかもしれません。

7. 研修時の絶対良感が根底に染み付いている

エンジニア研修時は Ruby on Rails の思想を基調として MVC や TDD といった一般的に正しいと言われる Web アプリケーションの仕組みや開発手法を学びました。 サービス配属後はしっかりとしたフレームワークこそありませんでしたが、長年利益を出し続け会社の収益基盤を作ってきた敬意を払うべき歴戦の勇者のコードを触れるようになりました。

正直最初は環境が変わりすぎて慣れるまでは善悪の判断がつけられず大変でした。しかし、コードが少しづつ読めるようになってくると、研修で学んだことは環境に依存せずに正しいことだと理解できるようになり、まるでジャングルの中でコンパスを見つけたように少しづつ動けるようになりました。(行ったことないですけど..)

僕はこのとき、初めて開発に携わったコードが研修で学んだ正しいコードで良かったと思いました。 なぜなら、悪い環境が犯罪者を育ててしまうことと同じで、レガシーな環境が当たり前となり善悪の判断がつけられない人になってしまうことを恐れたからです。 レガシーは慣れるものではなく改善していくものです。

新人には正しいコードレビューをさせるためにも、善悪の判断がつけられるように絶対良感を養うような新卒研修を行うべきだなと思ったことを覚えています。

※ 絶対良感という言葉はこちらのテックブログから参照させていただきました。 tech.pepabo.com

8. インデント修正は人間がやるべきではない

自明ではありますが、この半年間で僕も強く思ったので自戒の念を込めて敢えて書きます。

人間がやるべきことと機械がやるべきことは区別するべきです。 機械ができることについては人間がやるよりも機械に任せた方が数百倍効率が良く正確なので積極的にやらせるべきです。

レビューについて当てはめると、具体的にはテストの実行は CI に、インデントの修正や指摘については言語毎にあるリントツールを使いましょう。

人間は機械にはできない発想や考えることに時間を費やすようにするべきです。

9. コードレビューの目的

よくコードレビューの話題では 気をつける言葉アンチパターン といった内容が挙がります。 しかしコードレビュー初心者にとって大事なのは、まずコードレビューがそもそも何のために行われているのかといった目的を理解することだと思います。

僕の中の一つの答えは 問題vs私達 という構図を常に忘れず、最良のコードをチームで考え、導き出し、残すことでした。 (もちろん属人化を防ぐことや安全性の担保、チームの成長という側面もあると思いますが今回は割愛)

チームの力を最大限に生かし、最大のバリューを発揮させるためにコードレビューは行われています。 そしてその目的を実現させるための手段やテクニックの一つとして 気をつける言葉アンチパターン があると思います。

例えばダイエットを成功させるために最も必要なものは、効率の良い最高なダイエット機材や食料といった手段ではなく、まずダイエッターとしての屈強な心を持ちダイエット戦士になってしまうことです。ダイエット戦士の心を持つことで、自ずとその手段としてダイエット機材や食料に手を出すといった順序が望ましいのではないかと思います。

話を元に戻すと、チームで最良のコードを残すという目的を忘れなければ、どんなレビューコメントも「最良のコードを残すために遠慮せずに意見を述べてくれている」と考えることできます。また、レビュアーとしてもそのような心掛けをするべきでしょう。レビュイーとレビュアーの双方が互いに目的を一致させ遠慮せずに歩み寄ることで最高のコードレビューができるのだと思います。

10. 楽しく円滑にコードレビューするための簡単な方法

とはいえ、全ての人が禅問答を解いたような仏の心を持っている訳ではないと思います。頭で理解していても心が納得できていないなんてことはよくある話です。

でも安心してください。それらの問題を解決する簡単な方法があります。

それは 絵文字, 顔文字, 感嘆符を適材適所に使う ことです。

我々は感情を持つ人間なので、例えば合理的故に少し厳しめなコメントとなってしまっていても、末尾に笑顔の顔文字や感嘆符があるだけで安心を得ることができます。 本来であれば、最良のコードを残すために遠慮せずに意見を述べてくれているという相手の考えをトレースして納得するべきですが、人間は論理と感情のパラドックスを持ち合わせているため、目的の他にこのような手段が有効となるんじゃないかなと思ってます。

ただし、全く関係のない絵文字の使用はオススメしません。 なぜなら、相手に意味不明な絵文字を使った理由を考えさせてしまうためです。勘違いや無駄を生むような行為はコミュニケーションコストを高めるだけなので避けるべきです。 僕は入社当初、意味もなく可愛いからという理由で 🗿 を連発して使ったり、LGTM の gif 画像を連投してしまったり、本当に意味のないタイミングで 🏩 の絵文字を使ってしまって相手を困らせてしまった経験があるのですが、今考えると黒歴史ですね。その頃はコードレビューの本来の目的を考えもせずに、ただ面白くてノリが良い方がみんな楽しくてハッピーになると思っていました。

コードレビューは自分一人で完結するものではなくチーム開発の一貫です。 今後もコードレビューの本来の目的を見失わずに、関係者各位の時間と労力を奪わず、かつ適宜いい感じにチームの士気を上げられるようなクリエイティビティに富んだ絵文字や顔文字の使い方を心掛けていきたいです。

とまぁなんやかんや述べましたが、僕が言いたいのは研修時代に受けたこちらの資料が最高ということです 😊 自分がコードレビューをする立場になってから改めて読んでみると、当時とはまた感じ方が違っていて面白いなぁと思いました。

hisaichi5518.hatenablog.jp

最後に

冒頭でも少し述べましたが、いざコードレビューをやってみるとそれに付随してコードレビュー以外の学習スピードが格段に上がりました。 具体的には、コードレビューに必要とされるコードリーディング力や将来を見据えた設計力、テスト力など、僕が冒頭で述べたいわゆる サンダラ にあたる力のことです。この分かりにくい例えをもっと続けると サンダガ を会得しようと サンダガ の修行を必死に頑張ってたら サンダラプリザラ, ファイラ のレベルも気がついたら上がっていたといった体験でした。 圧倒的成長の理由は、先輩エンジニア達による自分よりも綺麗で洗練されたお手本となるようなコードをレビュアーとしての立場で何度も何度も見たことにあるのではないかと思います。先輩方!本当にありがとうございました!

最後になりましたが、かつての僕と同じようにコードレビューの一歩を踏み出せずに尻込みしている方、またはチームの中にコードレビューをしていない未成熟のエンジニアさんがいる方に向けて一言。

綺麗なコードを一からコードリーディングするのも勉強になると思いますが、コードレビューを通してチームのエンジニアと共にプロダクトを造り上げながら実戦で得られる知見は代えがたいものがあるのではないかと思います。

このブログを読んで少しでも何か感じていただけたのであれば、是非この機会にコードレビューを始める、または提案してみるといったアクションをとってみるのはいかがでしょうか 😆 ✨

2016年12月9日 pepabo Advent Calendar 2016 書くぞぉ!!1

3行まとめ

  • 最近はずっと SQL と戦っている。今日はマルチカラムインデックスをざっくり理解できたと思う
    • インデックスの貼り方はとても大事

以下のようなマルチカラムインデックスが貼られている条件では del_flg をwhere句から削除してしまうと、hoge が使えなくなってしまい customer_id を検索するときに全データを見ることになってしまう。

index hoge (account_id, del_flg, customer_id, make_date),
index fuga (account_id, make_date)

そのため、もしも del_flg をwhere句から削除するのであれば以下のようなマルチカラムインデックスを作ってあげるのが理想となる。

index piyo (account_id, customer_id, make_date)
  • デプロイしたらバグを生んでしまった
    • デプロイ後は NewRelic でエラーレートを確認するべき
    • 型とか null とかは注意
    • 変数の初期化は常に念頭に置いておこう
    • 事前にバグを生まない実装をするのが何よりも大事
  • は特殊なカタカナなのでカタカナのバリデーションを実装するときには注意が必要。
  • pec 便利そう!

github.com

  • 色弱なのでエディタのカラースキーマを自分色にしてみた。
    • インスタンス変数とクラス変数の違いが色で見分けられてとても便利になった。
    • 背景色でスコープの違いを表してみた
    • 派手でバカっぽくなったけど見やすくなった
    • 一目瞭然にすると考えることが少なくなっていい気がする

ひとこと

ブログを書き続けてきた結果、最近は自分が学んだことややったことなんかはこうして吐き出していかないと気がすまない感じがあります。

やっていき

  • 家用の MacBook Pro 購入しました。セットアップしていかねば。

  • ワンダーコアを購入してしまいました。

www.wondercore.jp

  • pepabo Advent Calendar 2016 に参加しました!僕は12月14日(水)!

qiita.com

今週末はLINE BOT AWARDS×ハードウェアハッカソンアドベントカレンダー、1年の振り返り、執筆ネタの構想などやることがいっぱいあって忙しそうだけど、なんだかとっても強くなれそうな土日を迎えられそう!!😆 ☆彡