かけちゃんねる2

エモいことを書く

エンジニア研修をふりかえって

やったこと

Webエンジニアのツール

  • シェルコマンドの学習(ghq, xargs, peco, jq, tmux, find)
  • tmux について発表
  • cURL を使ってjsonを渡すことで GitHub の個人データを変更した
  • Git を活用してコミットやプルリクを正しく出す練習

アプリケーション講座

  • Ruby のクラスとモジュールについて学習
  • Sinatra でじゃんけんアプリを作成
  • Rails でタスク管理アプリをつくった
    • タスクの締切を過ぎると Slack に通知がいくようにした
  • RSpec のテスト(Model, Controller)の写経
  • レビューの仕方についての学習
    • 指摘するときは「なぜだめなのか」理由をちゃんと書く
    • 「だめ」だけじゃなくて提案をする
    • 文字だと感情が欠落してしまうので3割増でコメントする
    • めでたいLGTMをするように心がけた
    • 参考 f:id:Kaketan:20161104155226p:plain
  • travis CIに監視してもらう

レゴスクラム

フロントエンド

インフラ構築と構成管理

  • Itamae で Vagrant環境(CentOS7)の環境構築を自動化するコードを書いた(主にMySQL
    • コマンド実行のときの留意点
      • execute の場合、 -y をつけなければならない
      • mysql のコマンドを実行するときに ; を忘れてしまうと入力待機中になってしまうので注意
      • そこら辺をいい感じにしてくれる package というリソースがあるので利用可能ならそちらを使う

重要ミーティング

  • @udzura さんとのお茶会

セキュリティ座学

インフラ運用

  • シェルスクリプトを用いたToDoアプリのDBサーバの監視

  • ケーパビリティの表層に触れた

  • PHPとペパボの話を聞いた
  • インフラ運用の仕事はアラート対応だけじゃなくて、ユーザ対応、環境構築など多岐にわたる
  • カーネルのお仕事はたくさんある
    • ハードウェアの制御
    • プロセスの管理
    • 物理メモリの管理
    • ファイルシステム
    • ネットワーク

技術発表研修

Webサービス開発

  • リーンキャンパスの作成
  • エレベーターピッチバトル
  • スプリント計画
  • ログはいいぞ
  • HomeのViewをつくったり、スタイルあてたりした。

その他

  • 同期や先輩とのランチに全参加(全23回)
  • 福岡支社の人に積極的に話しかけた

学んだこと、できるようになったこと

  • ファイルやディレクトリを探すときに find, xargs, peco といったコマンドを使うことができるようになった
  • あたりまえのように tmux を使っている
  • Git 研修のときに学んだ git diff --cachedgit add -p はサービス研修のときに活用することができた
  • git rebase を使ってプルリクをきれいに出せるようになった
  • RailsAPIとして使用することができるようになった
  • Rubyのクラスの継承を概念的に理解することができた
  • RSpec で簡単なテストが書けるようになった
  • travis CIを用いてアプリケーションの監視ができるようになった
  • スクラム的なチーム開発が自然とできるようになった
  • アロー関数など ES6 が従来のJSと比較してどのように変化したか理解することができた
  • React についてコンポーネントがどのような構造で記述されているか大まかに理解することができた
  • Itamae を用いて構成管理をすることができるようになった
  • コンピュータ・ネットワークの知識がなさすぎることに気づいた
  • sar を用いて cpu や memory, disk, network の情報を診ることができるようになった
  • 今はまだエンジニア技術としての希少性が高くないからLTのテーマも決定しづらいということに気づいた
  • 「レビューをすることのタスク」と「自分が受け持っている開発のタスク」の、どちらを優先すべきなのかが難しかった。今回は、MVPとして出したものの優先順位に沿って、できるだけ細部にこだわり過ぎないように心がけた。

気持ちが変わったこと

  • 所属事業部のふりかえりでよく「ちゃんと共有しよう」という反省があがっていて、どうしてそうなるんだろうと思っていたけど、プレイヤーとして開発をすることで理解ができたし、認識を合わせることの難しさを実感することができた。
  • 仕様書に100%のゴールが書かれていることはないので、自分で手を動かしながら、そして目の前のことに集中すればするほど「ゴール」を歪曲してわかったような気になってしまう。また、人は忘れる人は忘れる生き物でもある。したがって、朝会や夕会などを用いて細かにコミュニケーションをとっていくことが大事である。
  • エンジニアとしてのプロ意識。エンジニアは実際に自分の手を動かすことができるので決して力は弱くない。だからこそコードを書くことに責任感をもたなければならない。
  • 自分でググって自分で解決するという癖がどうしても抜けずにあまり先輩エンジニアに質問することができなかったので、実務では15分ググって解決できそうになかったら聞くことを心がけようと思った。
  • gem ひとつを使うにしても、そもそもその gem で何を実現しようとしているのかというところを考えることを欠いていたので、そこを深掘りしていって、そこから苦手な低レイヤの知識をインプットしていくべきだと感じた。

配属先で今後やっていきたいこと

  • PPO(プチPO)。POの視点を意識しながら、目の前のタスクに拘泥しすぎずに全体のプロダクト・サービスとして何を優先するべきかを考えていきたい。
  • すぐには結果がでなくても長期的にみるとジワジワ効果が期待できるようなタスクがあったら「やりたい!」と声を上げる。
  • 周りの人を頼っていいから、任されたことはやり遂げる。先輩の肩に乗って効率的に学習して、自分の力でやり遂げて、できることをどんどん増やしていきたい。

こんなエンジニアになるぞ、と持つことができたイメージ

  • チーム開発において気軽に真剣に議論しあえる関係性を構築できるエンジニア
    • まず自分がチーム内のエンジニアの関係性の中だけで問題を解決しないように注意して、マネージャやデザイナに意見を伺ったり、他部署の専門分野の人に相談したりする。
    • そうすることで、様々な視座からプロダクトや機能を眺めることができると思うから。
  • ユーザの求めているものを最優先で考えることのできるエンジニア
    • ユーザーのために技術をつかうことを心がける。ユーザーがどう幸せになるのかという視点で開発を行い、そこと現場の動きがズレていると感じたときには、勇気を持って発言する。