エンジニアが毎日チェックするべき情報源

①Qiita（のトップページ）
https://qiita.com/

トップページから技術トレンドを読み解く。

②はてなブックマークの「テクノロジー」カテゴリ（の「人気エントリー」のページ）
https://b.hatena.ne.jp/hotentry/it

はてなの機能で良質な情報は、長い間、人気ページに滞留するらしい。

③dev.toのサイトとツイッター

dev.toのアカウントの作り方
https://dev.to/programmingmonky/devto--25lm

dev.to公式ツイッター
https://twitter.com/twitterdevjp

④テッククランチ日本語版のツイッター
https://twitter.com/jptechcrunch

テッククランチ公式
https://jp.techcrunch.com/V

⑤Twitterでフォローしているアカウント
その１：@ThePracticalDev
その２：@jptechcrunch
その３：@publickey
その他：
@awscloud
@awscloud_jp
@googlecloud
@googlecloud_jp
@GCPcloud
@googledevs
@GoogleAI

情報収集に関する個人的なお薦め：
・Qiitaとはてブのテクノロジーカテゴリはなるべくサイトを毎日チェックする。
・dev.to公式Twitterアカウントをフォローする。

DRY原則/KISS原則/YAGNI原則について説明します。

プログラミング・エンジニアリングの格言、持つべきマインド解説

DRY＝「don'trpeat yourself」の略

・「重複させるな」という意味

・何を？
設定値や設定ファイル、データベースのスキーマファイルやドキュメント
重複定義したり、多重管理しないように一つで一括管理しなければならない。

そうしないと、設定しないとならない箇所が多くなることで、
相当な確率で変更漏れが発生して、不具合につながる可能性が上がり保守性が悪くなる。

最近トレンドの「マイクロサービスアーキテクチャ」の考え方を開発に
取り入れても各サービスのリポジトリも分割したりするとどうしても重複コードが発生する。
しかしこれは上級者向けの開発手法なので初学者はdryを守るように。

KISS＝「keet it simple, stupid」

・「複雑にするな、単純さを保て」と言う意味

元々航空機設計分野の格言

「リフレクション」や「ジェネリクス」やら
高度な手法を使って開発すると、保守性が悪くなるので
保守性を考えて、単純さを守って開発すること。

YAGNI＝「you ain't gonna need it」

・「どうせ使わないよ」という意味

RBDで出来るシステムをnosql使ったために、
サービス開発に時間がかかりすぎて、目的達成できなかったなど
無理に目新しい技術を使おうとするなという意味と考えられる。

プログラミングノートの作り方

新しい言語を学ぶ特に作るノート

書く内容としては
言語の文法・機能・環境構築の方法・自分なりのメモ

メモはMIを使って編集・dropboxに置いてる。

作り方としは、
言語のチュートリアルや入門記事の内容をコピペして、
そこに自分なりのメモを追加しているだけ。

let'sプログラミングさんのを使っている。

コピペしてきたコードを言語用の
・playground(主にブラウザ上でコードが実行可能なサービス)
・REPL（ローカル環境上で手軽に実行可能なツール）
に貼り付け実行して動作を確認しながら、
色々コードを自分で変更したりしながらハンズオン学習して
ノートにメモを追加して、１項目終わったら次に進む方式でやっている。

このようなノートを作っておけばアプリ開発の際に

自分専用のリファレンスとして活用できるので、
作業効率も高くなり、詰まったことや、発生したエラーとかに関するメモを追記していけば
同じような間違いを何回も繰り返して時間を浪費することを防止できるメリットもある。

Rubyメモ
https://gist.github.com/kenta-polyglo...

僕のGitとGitHubの使い方を紹介します。

ローカル環境でgithubのissueに対応する作業ブランチをmasterブランチから作成します。
（チームの方針によってはdevelopブランチから作成する）

作業ブランチ名のルール：

決まりごとがない場合は「feature/add_name_cliumn」みたいな感じで

「feature/」というプレフィックス付きで作業する場合が多いです。
（feature/の後ろには回収の簡単な概要を書きます）

不具合を改修するブランチの場合は「fix/」というプレフィックスをつけたりする
（基本、ブランチ名のルールがない会社が多い）

そして、ローカル環境での作業が完了したら、
「git status」で変更したファイルの一覧を見て「git diff」で差分を見て

問題がなければ「git add -A」して「git commit -m」して

最後に「git push origin HEAD」
コマンド実行してgithubのリモートブランチにpushします

「git push origin HEAD」はブランチ名を指定しなくても
カレントブランチをリモートにpushすることが出来る。

コミットメッセージは英語に書くようにしています。

そして、pushしたブランチからプルリクエストを作成して、
プルリクエスト用のテンプレートが設定されている場合はそれに必須事項を記入して
レビューして頂きたい方たちを「reviewers」の欄で選択します。

この際、プルリクのコメントに「close #issue番号（またはurl）」を入力しておいて
プルリクがマージされた際にissueも同時にcloseされるようにしておきます。

またslackとかのチャットルールにgithubとかの連携アプリをインストールしておいて
reviewsで選択された方たちに対してチャットツール上で通知が行くようにしているチームが最近は多い。

そしてレビューしてもらって改修依頼があった場合にはローカル環境で改修を加えて
「git add -A」して「git commit -m」して
「git rebase -i」コマンドを使ってコミットを一つにまとめた上で
「git push origin HEAD」コマンドを実行します。

そしてgithub上でLGTMを貰ったら、プルリク画面でマージを実行して完了。
（lgtmは「Looks good to me」の略で「良さそうです」の意味）

最近はgithubの「approve機能」を使って
レビュアの誰が一人がapproveするまでマージ不可という設定にしている現場も多い。

このマージの際には大抵の現場ではそのリポジトリの設定で
「automatically delete head branches」が選択してあるので、
github上の作業ブランチは自動的に削除されます。

また最近はそのリポジトリの設定で「allow squash merging」
だけが選択されることも多いのでマージされる際は自動的にコミットが一つにまとめられる。

そしてgithub上でマージが完了した後はローカル環境で
「git checkout master」と「git pull origin master」コマンドを実行して
masterブランチを更新しておいて次のタスクに備えておく。

補足：
別のブランチを作って作業する場合、
「git stach」コマンドを使うことになるので
このコマンドも覚えておくべき

他に「git add -A」「git commit -m」を取り消す
「git reset」コマンドも比較的よく使うので覚えておくこと。

Web系エンジニアが良質な人脈を効率良く形成していく方法
https://www.youtube.com/watch?v=QVYkffRqQL8

良質な人脈を効率的に形成する方法①

web系大企業に正社員として入社すること

メガベンチャーにいると
（サイバーエージェント・mixi・ヤフー）
高級な人材と関わる機会を、大企業が用意してくれる。

離職してビジネスを始める方が多いので、
能力があれば面白い話に混ぜてもらえる可能性がある。

web系エンジニアとしてキャリアのどこかで一度「大手web系企業に正社員として勤務する」
というのは人脈拡大の観点においては非常にオススメできる戦略。

良質な人脈を効率的に形成する方法②

「it系イベントや勉強会で登壇やLTする。」

（LTはライトニングトーク、短くてカジュアルな発表のことです）
最後に交流の時間があるが、最後に話しかけてもらえる確率が高まる。
求められる方が圧倒的に良い。

良質な人脈を効率的に形成する方法③

「it系のイベントや勉強会にボランティアスタッフとして関わる」

イベントに来る人から話しかけられる。自分も話しかけやすい。
テックプレイやコンパスでスタッフ募集は多いので参加してみること！

良質な人脈を効率的に形成する方法④

「it系のイベントや勉強会や交流会を自分で主催する」

自分で主催するということは当然自分で集客するので、
幹事を主催するのが一番仲良くなれるので自分で主催するのがベスト！