├── .gitignore ├── .textlintrc ├── LICENSE ├── README.md ├── _config.yml ├── docs ├── html-css │ ├── css.md │ └── html.md ├── http │ └── README.md ├── linux │ ├── README.md │ ├── command.md │ ├── task.md │ └── vim.md ├── management │ ├── EngineerTechnicalInterview.md │ └── README.md ├── mysql │ └── README.md ├── server-side-programming │ ├── JavaScript │ │ ├── README.md │ │ └── task.md │ └── PHP │ │ ├── README.md │ │ ├── task1.md │ │ ├── task2.md │ │ ├── task3.md │ │ ├── task4.md │ │ ├── task5.md │ │ ├── task6.md │ │ └── task7.md ├── system-design │ ├── OOPDesign.md │ ├── README.md │ └── database.md └── tips │ ├── AntipatternOfLearningMethod.md │ ├── ChangeJobManual.md │ ├── CreateDevelopmentEnvOnMac.md │ ├── HowToChooseJob.md │ ├── HowToContinueLearning.md │ ├── HowToFindJob.md │ ├── ITSkillLearningMethod.md │ ├── README.md │ ├── RecommendedBooks.md │ └── Shachiku.md ├── package.json └── yarn.lock /.gitignore: -------------------------------------------------------------------------------- 1 | # Created by .ignore support plugin (hsz.mobi) 2 | ### macOS template 3 | # General 4 | .DS_Store 5 | .AppleDouble 6 | .LSOverride 7 | 8 | # Icon must end with two \r 9 | Icon 10 | 11 | # Thumbnails 12 | ._* 13 | 14 | # Files that might appear in the root of a volume 15 | .DocumentRevisions-V100 16 | .fseventsd 17 | .Spotlight-V100 18 | .TemporaryItems 19 | .Trashes 20 | .VolumeIcon.icns 21 | .com.apple.timemachine.donotpresent 22 | 23 | # Directories potentially created on remote AFP share 24 | .AppleDB 25 | .AppleDesktop 26 | Network Trash Folder 27 | Temporary Items 28 | .apdisk 29 | 30 | # Logs 31 | logs 32 | *.log 33 | npm-debug.log* 34 | yarn-debug.log* 35 | yarn-error.log* 36 | 37 | # Runtime data 38 | pids 39 | *.pid 40 | *.seed 41 | *.pid.lock 42 | 43 | # Directory for instrumented libs generated by jscoverage/JSCover 44 | lib-cov 45 | 46 | # Coverage directory used by tools like istanbul 47 | coverage 48 | 49 | # nyc test coverage 50 | .nyc_output 51 | 52 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 53 | .grunt 54 | 55 | # Bower dependency directory (https://bower.io/) 56 | bower_components 57 | 58 | # node-waf configuration 59 | .lock-wscript 60 | 61 | # Compiled binary addons (https://nodejs.org/api/addons.html) 62 | build/Release 63 | 64 | # Dependency directories 65 | node_modules/ 66 | jspm_packages/ 67 | 68 | # Typescript v1 declaration files 69 | typings/ 70 | 71 | # Optional npm cache directory 72 | .npm 73 | 74 | # Optional eslint cache 75 | .eslintcache 76 | 77 | # Optional REPL history 78 | .node_repl_history 79 | 80 | # Output of 'npm pack' 81 | *.tgz 82 | 83 | # Yarn Integrity file 84 | .yarn-integrity 85 | 86 | # dotenv environment variables file 87 | .env 88 | 89 | # IntelliJ IDEA Setting Files 90 | .idea 91 | web-developer-ojt.iml 92 | -------------------------------------------------------------------------------- /.textlintrc: -------------------------------------------------------------------------------- 1 | { 2 | "rules": { 3 | "max-ten": { 4 | "max": 3 5 | }, 6 | "preset-jtf-style": true, 7 | "no-mix-dearu-desumasu": true, 8 | "preset-ja-technical-writing": true 9 | } 10 | } 11 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2017 keita-koga 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # web-developer-ojt 2 | 3 | 意外とたくさんの人に見られているので内容が古くなっている箇所を徐々に修正していきます、お待ち下さい！ 4 | 5 | ## Web開発者向けのOJT（仮） 6 | 7 | ## 目標 8 | 9 | 未経験者が0からWebサービスを開発しリリース、運用まで出来るだけの技術を身につける為、必要な学習内容をまとめます。 10 | 11 | ## 事前準備 12 | 13 | ### 事前準備（各種アカウント） 14 | 15 | 以下のアカウントの準備が必要です。 16 | 17 | - [GitHub](https://github.com/) 18 | - [Qiita](https://qiita.com/about) 19 | - [Google](https://accounts.google.com/SignUp?hl=ja) 20 | - [AWS](https://aws.amazon.com/jp/account/) 21 | 22 | [Qiita](https://qiita.com/about) はGoogleアカウントやGitHubアカウントがあれば簡単に作る事が出来ます。 23 | 24 | 今後、様々なサービスのアカウントが出てきますが、なるべくGoogleアカウントやGitHubアカウントで登録するようにするとアカウントの管理が楽になるのでオススメです。 25 | 26 | 反面不正利用された時のダメージが大きいので、各アカウントには二段階認証の設定を行っておきましょう。 27 | 28 | 特にAWSが不正アクセスされると、身に覚えのない金額を請求されたりするリスクがあるので必ず設定を行っておく事をオススメします。 29 | 30 | 参考までに役に立ちそうなリンクを載せておきます。 31 | 32 | - [GitHubで二段階認証に変更する](https://qiita.com/non0311/items/a67a7e7c5599c7ace0c4) 33 | - [2 段階認証プロセスを有効にする](https://support.google.com/accounts/answer/185839?hl=ja) 34 | - [AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ](https://qiita.com/tmknom/items/303db2d1d928db720888) 35 | 36 | ### 事前準備（開発用のPC） 37 | 38 | 個人的にはMacをオススメします。 39 | 理由としては、以下の点が挙げられます。 40 | 41 | 1. 持ち運びが楽 42 | 1. マウスがなくても操作に困らない（個人の主観による） 43 | 1. iOSアプリの開発（本件では触れませんが将来的にiOSエンジニアになる可能性もある為） 44 | 1. [UNIX](https://ja.wikipedia.org/wiki/UNIX) ベースなのでサーバでよく使うコマンドがほぼそのまま使えるしローカルに開発環境を作る敷居が低い 45 | 46 | 4に関してはWindows 10からBashシェルが使えるようになったらしいので、ともかくとしても、3に関しては今後もサポートされる可能性は低いでしょう。 47 | 48 | これは個人の主観ですが、Web開発においてはまだまだ `Windows < Mac` だと筆者は感じています。 49 | 50 | 新たに購入する際のスペックの選び方ですが、CPU、SSDは低めに抑えても、メモリは最低でも16GB積んでおく事をオススメします。 51 | 52 | ## 具体的な学習内容 53 | 54 | 下記の通りです。 55 | 56 | 全ての項目に言えますが座学よりも手を動かす事を重視します。 57 | 58 | よって無理に暗記したりする必要はありません。記憶する事は最小限に、手を動かしながら自然と身につくそんなカリキュラムの作成を目指します。 59 | 60 | 各学習内容はディレクトリごとに分かれてマークダウン形式にまとめてあります。 61 | 62 | `task.md` というファイルがその項目における課題でここに載っている成果物を提出し、メンターのレビューを終えたら、その項目は終了となります。 63 | 64 | ### 1. HTML CSS基礎 65 | 66 | 以下の資料を見て、HTML、CSSの概要を理解します。 67 | 68 | - [HTMLの基礎知識](https://github.com/keitakn/web-developer-ojt/blob/master/docs/html-css/html.md) 69 | - [CSSの基礎知識](https://github.com/keitakn/web-developer-ojt/blob/master/docs/html-css/css.md) 70 | 71 | その後 [Progate](https://prog-8.com/) や [ドットインストール](https://dotinstall.com/) で実際に手を動かします。 72 | 73 | 最終的に自身の自己紹介ページを作成して完了とします。 74 | 75 | この時点ではあまり拘らずに概要を理解したら速やかに次のステップに進みましょう。 76 | 77 | ### 2. Linuxの基礎 78 | 79 | [linux](https://github.com/keitakn/web-developer-ojt/tree/master/docs/linux) 配下の資料を見てLinuxの概要とコマンドに慣れます。 80 | 81 | ここには載っていませんが、[Git](https://git-scm.com/) と呼ばれるバージョン管理システムに対する理解も重要です。 82 | 83 | 以下のサイトを参考にGitやGitHubの使い方を理解しましょう。 84 | 85 | - [サルでもわかるGit入門](https://backlog.com/ja/git-tutorial/) 86 | - [GitHub超初心者入門](https://qiita.com/nnahito/items/565f8755e70c51532459) 87 | 88 | ### 3. ネットワークの基礎 89 | 90 | ### 4. サーバサイド向け言語（環境構築） 91 | 92 | 環境構築したサーバサイド言語を使って基本的なアルゴリズムとデータ構造を理解します。 93 | 94 | ### 5. アルゴリズムとデータ構造 95 | 96 | ### 6. TCP/IPの基礎 97 | 98 | ### 7. HTTPの基礎 99 | 100 | ### 8. RDBMSの基礎 101 | 102 | MySQLを使う予定です。 103 | インストール方法やコマンド操作の方法、index等の用語を理解する、サーバサイド向け言語からMySQLを利用する方法。 104 | 105 | ### 9. デザインパターン & DB設計 106 | 107 | 簡単なアプリケーションを作りながら設計全般について学びます。 108 | 109 | ### 10. セキュリティ 110 | 111 | ### 11. テストの自動化 112 | 113 | ### 12. アプリケーションフレームワーク 114 | 115 | ### 13. 最終課題 116 | 117 | 実際に使えるWebサービスとして公開します。 118 | 119 | ## 間違った内容を見つけたら 120 | 121 | PR大歓迎です。（誤字、脱字が結構多いので修正大歓迎です） 122 | 123 | もしくは [こちら](https://github.com/keita-nishimoto/web-developer-ojt/issues) からissueを作成して頂いても問題ありません。 124 | 125 | issueの内容は「こういう観点も必要」等の内容も大歓迎です。（ただし筆者の力量不足でそれが叶えられない可能性はあります…） 126 | 127 | ## PRの際の注意点 128 | 129 | PRを作成する前に、`textlint` による文書校正を行って下さい。 130 | 131 | 以下のコマンドで実行が可能です。 132 | 133 | - 校正のみを行う場合 134 | 135 | ``` 136 | yarn run lint [実行対象のファイル名、もしくはディレクトリ名] 137 | ``` 138 | 139 | - 校正ルールに従って修正を行う場合（ただし自動で修正されるのは、一部のルールだけです） 140 | 141 | ``` 142 | yarn run lint:fix [実行対象のファイル名、もしくはディレクトリ名] 143 | ``` 144 | 145 | `yarn run lint:all:fix` を実行すると全てのファイルに対して自動修正が行われます。 146 | 最低限こちらのコマンドを実行してからコミットをお願いします。 147 | 148 | 校正ルールに関しては以下の内容を利用しております。 149 | 150 | - [textlint-rule-max-ten](https://github.com/textlint-ja/textlint-rule-max-ten) 151 | - [textlint-rule-no-mix-dearu-desumasu](https://github.com/textlint-ja/textlint-rule-no-mix-dearu-desumasu) 152 | - [textlint-rule-preset-ja-technical-writing](https://github.com/textlint-ja/textlint-rule-preset-ja-technical-writing) 153 | - [textlint-rule-preset-jtf-style](https://github.com/textlint-ja/textlint-rule-preset-JTF-style) 154 | 155 | Atomを使っている場合、[linter-textlint](https://atom.io/packages/linter-textlint) をインストールするとリアルタイムで校正を行ってくれるのでオススメです。 156 | 157 | 既存文書でもtextlintに違反しまくっている文書が多々あります。 158 | 159 | この辺は時間があれば徐々に修正していきますのでご了承下さい。（それよりもカリキュラムを最後まで作り上げる事を優先したいので） 160 | 161 | ※ textlintの導入に関しては [快適なMarkdown編集環境](https://qiita.com/daichiii/items/d36f52c45c744177eb7c) という記事を参考にさせて頂きました。 162 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-cayman -------------------------------------------------------------------------------- /docs/html-css/css.md: -------------------------------------------------------------------------------- 1 | # CSSの基礎知識 2 | 3 | ## CSSの概要 4 | 5 | 正式名称はCascading Style Sheetsといいます。 6 | 7 | HTMLで作られた文書の体裁や見栄えを整える為の言語です。 8 | 9 | ## CSSの書き方 10 | 11 | 下記のように記載します。 12 | 13 | ```css 14 | p { 15 | font-size: 18px; 16 | } 17 | ``` 18 | 19 | 装飾を適用させたい要素を指定します。 20 | 21 | 上記の例だとp要素ですね。その横に `{}` を書きます。 22 | 23 | 続いてp要素に加えたい装飾の内容を記述します。 24 | 25 | 装飾を適用させる対象となる要素が『セレクタ』になります。 26 | 27 | 波括弧の部分が『宣言ブロック』と呼ばれます。 28 | 29 | 続いて『プロパティ』と『値』(あたい）を記述します。プロパティと値は必ずセットになります。 30 | 31 | font-sizeと記述し、そこに `:` をはさみ、さらに18pxと記述し最後に `;` を入れます。 32 | 33 | 上記の場合、font-sizeが『プロパティ』です。18pxが『値』になります。そしてプロパティと値がセットになった部分は『宣言』と呼ばれます。 34 | 35 | 基本はこれだけです、このプロパティの種類が非常に多いので、下記のリファレンス等を参考にしましょう。 36 | 37 | https://developer.mozilla.org/ja/docs/Web/CSS/Reference 38 | 39 | ## CSSの記述場所 40 | 41 | 基本的に `.css` という拡張子のファイルを作成し、HTMLのheadタグに読み込ませます。 42 | 43 | ```html 44 | 45 | ``` 46 | 47 | ` 55 | ``` 56 | 57 | しかしこれをやってしまうとそのhtml内でしか使う事が出来なくなる為、復数のページで共通のCSSを利用する事が出来なくなってしまいます。 58 | 59 | よって基本は外部読み込みの一択と考えて良いでしょう。 60 | 61 | もちろん、そのページでしか絶対に使わないというのであればstyleタグを使って書いても良いですが、そういう事が事前に分かる事は稀です。 62 | 63 | Webとは利用者の都合に合わせて常に進化してこそ価値があるので、変更しやすい構造にする為にも外部読み込みをオススメします。 64 | 65 | ## CSS学習で重要な点 66 | 67 | まず最初にお伝えしておきたいのは間違ってもプロパティの暗記等はしなくても良いです。 68 | 69 | 良く使うプロパティは自然に覚えますし、調べればすぐに出てくる事に労力を使うのはもったいないです。 70 | 71 | CSSではこういう事が出来るというざっくりとした知識を持っていれば、問題ありません。 72 | 73 | 筆者はCSSのデザインセンスに自信はありませんし、かっこいいデザインや可愛いデザインを作るのは苦手です。 74 | 75 | しかし、それでも下記の事を意識する事は非常に大事だと思っています。 76 | 77 | - 予測しやすい（良い命名） 78 | - 再利用しやすい（DRY、同じ事を繰り返して書かない） 79 | - 保守しやすい（依存関係を減らす） 80 | - 拡張しやすい（コードの記法を一貫させる） 81 | 82 | これらは全て良い設計を行う事で得られるモノになります。 83 | 84 | よってCSS学習をするに当って重要なのは、設計スキルだと考えます。 85 | 86 | 下記に役に立ちそうな記事を載せておきます。 87 | 88 | - [こんなHTMLとCSSのコーディング規約で書きたい](https://qiita.com/pugiemonn/items/964203782e1fcb3d02c3) 89 | - [2留でも書けるCSSコーディング規約](https://qiita.com/oreo/items/33da466480b2653bd5af) 90 | - [HTMLやCSS設計がよく分から無いというあなたへ。知ることから始める5つのTIPS](https://qiita.com/R-Yoshi/items/30f965dc44b7c533ef95) 91 | 92 | 命名にBEMというルールがあります。 93 | 94 | 上記の記事ではその点にも触れているので、読んでおく事をオススメします。 95 | 96 | ### 古い情報には注意 97 | 98 | HTMLのところでも触れましたが、こちらも同じような問題があります。 99 | 100 | CSS2の情報は既に古いので、そういう記事を見つけたらその内容全体が古い可能性を疑って下さい。 101 | 102 | 基本は下記のリファレンスを参考にするのが良いでしょう。 103 | 104 | https://developer.mozilla.org/ja/docs/Web/CSS/Reference 105 | 106 | ## 最近のCSSの流れ 107 | 108 | オープンソースで便利なツールがたくさん出てきており、進化の流れが早いです。（この内容もおそらく数年後には古い内容になっているでしょう） 109 | 110 | CSSの拡張性を高めるメタ言語 [Sass](https://ja.wikipedia.org/wiki/Sass) や便利なCSSツールを作成する為の [PostCSS](https://qiita.com/morishitter/items/4a04eb144abf49f41d7d) 等があります。 111 | 112 | 最近では [CSS Modules](https://github.com/css-modules/css-modules) という考え方が広まり、CSSの部品をComponentとして捉えるのが主流になりつつあります。 113 | 114 | 英語ですがこれらの進化の歴史を解説した記事があります。 115 | 116 | https://m.alphasights.com/css-evolution-from-css-sass-bem-css-modules-to-styled-components-d4c1da3a659b 117 | 118 | 非常に進化が早いですが、CSSのWebページを装飾するという役割は変わっていません。 119 | 120 | 基本的なプロパティや適応方法も意外と変わっていなかったりするので、今の段階では基本的な事を抑えておけば問題ないでしょう。 121 | 122 | それから誰でもある程度良さげなデザインを作れるCSSフレームワークがたくさん出ています。 123 | 124 | 使ってみると分かるのですが、マジで簡単にそれなりのデザインのサイトが作れてしまいます。 125 | 126 | 人気のある物をいくつか紹介します。 127 | 128 | ### [Bootstrap](http://getbootstrap.com/) 129 | 130 | Twitter製のCSSフレームワークです。 131 | 132 | 割りと昔からあるので、有名です。利用者も多いです。 133 | 134 | 結構有名なサイトとかでも使われていたりするので情報も多い点が良いです。 135 | 136 | ### [Material-UI](http://www.material-ui.com/#/) 137 | 138 | Googleが提唱する [マテリアルデザイン](https://qiita.com/nogson/items/804dd3a879f482fb7018) という手法を実現する為のフレームワークです。 139 | 140 | ただこちらは [React](https://reactjs.org/) を利用するという前提になっていますので、Reactを採用していないプロジェクトには利用出来ないという欠点があります。 141 | 142 | ※ Reactはfacebook製のJavaScriptライブラリです。この項目では触れませんが、後半このReactを用いた開発の演習等も行いますので今は名前だけ頭の片隅に置いておいて下さい。 143 | 144 | ### CSSの勉強法 145 | 146 | このあたりのlessonをやっておくのが良いでしょう。 147 | 148 | - [CSS入門](https://dotinstall.com/lessons/basic_css_v3) 149 | - [CSS3入門](https://dotinstall.com/lessons/basic_css3_v2) 150 | - [レスポンシブウェブデザイン入門](https://dotinstall.com/lessons/basic_responsivewebdesign) 151 | 152 | ただやるのではなく、先に紹介した設計手法等を意識しながらlessonで作る成果物を改造していく事でスキルを高める事が出来ます。 153 | 154 | また近年ではインターネットの中心は完全にスマートフォン等のモバイル端末に移行していますので、[レスポンシブウェブデザイン](https://liginc.co.jp/369022/) や [AMP](https://digitalidentity.co.jp/blog/seo/amp/what-is-amp.html) 等の手法にも目を通して行きましょう。 155 | 156 | 最近見た記事で「恐竜に教える現代のCSS」という記事が良かったので載せておきます。 157 | 158 | モダンなCSSの手法が一通り紹介されていますので目を通しておく事をオススメします。 159 | 160 | - [恐竜に教える現代のCSS – Part 1](https://postd.cc/actualize-networkmodern-css-explained-for-dinosaurs/) 161 | - [恐竜に教える現代のCSS – Part 2](https://postd.cc/modern-css-explained-for-dinosaurs-2/) 162 | - [恐竜に教える現代のCSS – Part 3](https://postd.cc/actualize-networkmodern-css-explained-for-dinosaurs-3/) 163 | 164 | 他にも覚える事が多いのであまり時間を掛けすぎずに、ある程度やったら、次のステップに進む事をオススメします。 165 | -------------------------------------------------------------------------------- /docs/html-css/html.md: -------------------------------------------------------------------------------- 1 | # HTMLの基礎知識 2 | 3 | ## HTMLの概要 4 | 5 | 正式名称はHyperText Markup Languageといいます。 6 | 7 | wikipediaより抜粋。 8 | 9 | >>HyperText Markup Language（ハイパーテキスト マークアップ ランゲージ、HTML（エイチティーエムエル））は、ハイパーテキストを記述するためのマークアップ言語の1つである。World Wide Web (WWW)において、ウェブページ（1990年代後半頃からはコンテンツという語も利用されている。「中身」という意味の語であり、大層な意味は無い）を表現するために用いられる。ハイパーリンクや画像等のマルチメディアを埋め込むハイパーテキストとしての機能、見出しや段落といったドキュメントの抽象構造、フォントや文字色の指定などの見た目の指定、などといった機能がある。 10 | 11 | 端的に言うと、Webページの要素や構造を指定するための言語です。 12 | 13 | 言語と言ってもプログラミング言語ではないので条件に合わせて動的に表示を変えたりする事は出来ません。 14 | 15 | ChromeやFirefoxのようなWebブラウザはこのHTMLを解釈してページを表示させています。 16 | 17 | なのでWebプログラミングの最終的な目的はそれがどんなに複雑な物であったとしても最終的には計算結果をHTMLにして出力する事が目的となります。 18 | 19 | ## HTMLの書き方 20 | 21 | 下記にHTMLの例を記載します。（wikipediaより抜粋） 22 | 23 | ``` 24 | 25 | 26 | 27 | 28 | 29 | HyperText Markup Language - Wikipedia 30 | 31 | 32 |
33 |

HyperText Markup Language

34 |

HTMLは、SGML 35 | アプリケーションの一つで、ハイパーテキストを利用してワールド 36 | ワイドウェブ上で情報を発信するために作られ、 37 | ワールドワイドウェブの基幹的役割をなしている。 38 | 情報を発信するための文書構造を定義するために使われ、 39 | ある程度機械が理解可能な言語で、 40 | 写真の埋め込みや、フォームの作成、 41 | ハイパーテキストによるHTML間の連携が可能である。

42 |
43 | 44 | 45 | ``` 46 | 47 | この文書をコピーして `index.html` というファイル名で保存してWebしてブラウザで開いてみて下さい。 48 | 49 | ブラウザがどのようにHTMLを解釈し表示させているのかがある程度分かると思います。 50 | 51 | HTML文書は `<タグ名>...` のような形で予め決められたタグ名を組み立てていく形で記載していきます。 52 | 53 | 例えば下記のような形の場合は、div要素の中にp要素が2つ入っているという感じです。 54 | 55 | ``` 56 |
57 |

あいうえお

58 |

かきくけこ

59 |
60 | ``` 61 | 62 | 要素の順序は、上から順に並ぶようになっています。 63 | 64 | このように、HTMLは要素を入れ子にして記述することで、構造を表します。 65 | 66 | またこれらの要素には、idとclassを振り分けることができます。 67 | 68 | idは下記のように指定します。 69 | 70 | ``` 71 |

名前

72 | ``` 73 | 74 | classは下記のように指定します。 75 | 76 | ``` 77 |

名前

78 | ``` 79 | 80 | idはページ内で一意である必要がありますが、classは同じページ内に同じ物が存在しても良いです。 81 | 82 | 端的に言うとHTMLの基本はこれだけです。 83 | 後はその都度利用するタグを調べていけば良いでしょう。 84 | 85 | ※ 間違ってもタグを暗記しよう等と思わなくて良いです。 86 | 87 | ## 最低限把握しておきたいタグ 88 | 89 | 最低限把握しておくべきタグがあるので、記載しておきます。 90 | 91 | ※ 繰り返しますが暗記の必要はありません、把握しておき頭の片隅にでも置いておく程度で良いです。 92 | 93 | ### `` 94 | 95 | ぶっちゃけなくても動くブラウザが多いですが、HTMLはこれを宣言する事ではじめます。 96 | 97 | `` と先頭に記載しましょう。 98 | 99 | ### `` 100 | 101 | `` の次はこの要素になります。 102 | 103 | langの部分にはページ内で利用する言語を入れます。 104 | 日本語の場合は "ja" です。 105 | 106 | ### `` 107 | 108 | 文書のヘッダ部分を指定するタグです。 109 | 110 | この部分に関しては、Webページの利用者には見えないですが、ブラウザはこの部分を解釈して表示を変えたりするので、最低限記載の事は記載しておく必要があります。 111 | 112 | #### `` 113 | 114 | 文書に関する様々な属性を定義するタグです。 115 | 116 | `` のように最低限、charsetを記載しましょう。 117 | 118 | charsetは文字コードの事を指します。 119 | 120 | 文字コードとは、文字をコンピュータで扱うために個々の文字や記号に割り当てられた、固有の番号のことです。 121 | 122 | この部分は非常に奥が深い部分なので詳しい説明はこの章では割愛させて頂きます。（これで [1冊の本](https://www.amazon.co.jp/dp/477414164X) が書けるくらいなので…） 123 | 124 | 今の段階で覚えておけば良いのは、日本語を扱う時は、UTF-8を選択しましょうという点です。 125 | 126 | 他の文字コードは使える文字が少なかったり、色々問題を抱えていたりするので本カリキュラムでは扱いません。 127 | 128 | 文字コードに関しては非常に詳しく解説してあるスライドを見つけたので共有させて頂きます。 129 | 130 | [新人さんに知ってほしい「文字コードのお話」](https://qiita.com/yuji38kwmt/items/b3a7820b4d3b544da4ff) 131 | 132 | このスライドはだいたい15分くらいで読めるので読んで見る事をオススメします。 133 | 134 | ※ 今の時点で内容が理解出来なくても構いません、勉強を進めてからもう一度読むと理解出来るようになっているかと思います。 135 | 136 | #### `` 137 | 138 | 文書の題名を表すものです。 139 | 140 | HTMLはWebページの為の言語なので、Webページのタイトルを記載します。 141 | 142 | このタイトルに関してはブラウザのタブやブックマークに保存する際のデフォルトのタイトルになるので、ある意味利用者にも関係があります。 143 | 144 | この内容とWebページの内容が全く異なる場合等はGoogle等の検索エンジンの検索順位に悪影響を及ぼすので、それなりに考えてタイトルを付ける必要があります。 145 | 146 | ### `<body>` 147 | 148 | Webページの内容を表します。 149 | 150 | この部分に利用者に伝える為の情報を記載します。 151 | 152 | この中で使えるタグの種類は非常にたくさん種類があるのですが、今の段階ではとりあえず、Webページに載せるコンテンツの内容は全て `<body>` タグに記載するという事を覚えておきましょう。 153 | 154 | ## HTMLで大切な事 155 | 156 | ### タグは正しく使う 157 | 158 | 多少間違えても表示崩れも起こらない場合もありますが、見た目で問題がなくてもバグの温床になる可能性はあるので正しいタグの使い方を心がけましょう。 159 | 160 | 下記のReference等を参考にしましょう。 161 | 162 | - [W3CのHTML仕様の原文（英語）](https://www.w3.org/TR/html5/) 163 | - [W3CのHTML仕様の日本語版](http://www.html5.jp/tag/elements/) 164 | - [MDN HTML要素Reference](https://developer.mozilla.org/ja/docs/Web/HTML/Element) 165 | 166 | ### コーディング規約を決める 167 | 168 | 好き勝手に書いていくと非常に読みにくい物が出来上がるので、[googleの規約](https://google.github.io/styleguide/htmlcssguide.html) 等を参考に一定のルールを設けましょう。 169 | 170 | HTMLに関わらず、コーディング規約等のルールを守るようにしないと、あっという間にメンテナンス性が低下します。 171 | 172 | [こんなHTMLとCSSのコーディング規約で書きたい](https://qiita.com/pugiemonn/items/964203782e1fcb3d02c3) という記事を見つけました。 173 | 174 | 非常に参考になるので一読しておきましょう。 175 | 176 | 本カリキュラムでは、インデントはスペース2個、ファイルの文字コードはUTF-8、改行コードはLFで統一します。 177 | 178 | ### 古い情報には注意 179 | 180 | タグ等が分からない場合でもGoogle等で検索すれば大抵の情報は見つかります。 181 | 182 | その中に下記のような書き方をしている例が見つかる場合があります。 183 | 184 | ``` 185 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 186 | <!-- ↑これ(っぽいの)が書かれてるのがHTML 4.01 --> 187 | 188 | <?xml version="1.0" encoding="Shift_JIS"?> 189 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 190 | <!-- ↑これ(っぽいの)が書かれてるのがXHTML 1.0 --> 191 | ``` 192 | 193 | これは「HTML4.01」や「XML1.0」と呼ばれる古いHTMLのバージョンの書き方です。 194 | 195 | よってこのような記述があった場合、その情報は既に古い可能性が高いので信用しないほうが 196 | 良いでしょう。 197 | 198 | HTMLは [WHATWG](https://ja.wikipedia.org/wiki/Web_Hypertext_Application_Technology_Working_Group) によって仕様が作られ、[W3C](https://ja.wikipedia.org/wiki/World_Wide_Web_Consortium) によって勧告されるという流れになっています。 199 | 200 | よって https://www.w3.org/TR/html5/ が正しい仕様が書かれたドキュメントになります。 201 | 何か判断に迷う事があった場合は公式ドキュメントを参考にしましょう。 202 | 203 | ## HTMLの勉強法 204 | 205 | [ドットインストール HTML入門](https://dotinstall.com/lessons/basic_html_v3) をやりながら実際にHTMLを書いていくのがオススメです。 206 | 207 | ただし、これも公式の情報ではないので、利用しているタグの使い方が正しいかどうかは、[W3CのHTML仕様の原文（英語）](https://www.w3.org/TR/html5/) を見ながら行ったほうが良いでしょう。 208 | 209 | ※ HTMLはWebサービスを作っていくうちに嫌でも覚えると思うので、あまり時間を掛けすぎずにある程度で良いと思います。 210 | -------------------------------------------------------------------------------- /docs/http/README.md: -------------------------------------------------------------------------------- 1 | # HTTP 2 | 3 | HTTPとはHyper Text Transfer Protocolの略でブラウザ等のクライアントとWebサーバとの通信を行う為のプロトコル（通信手段です） 4 | 5 | この資料ではWebエンジニアには必須であるHTTPの基本的な事を学びます。 6 | 7 | ## HTTP通信を実際に行ってみる 8 | 9 | まずはHTTPサーバとコマンドで通信してみましょう。 10 | 11 | ターミナルを開いて以下のコマンドを実行して下さい。 12 | 13 | `curl -v http://laravel.jp` 14 | 15 | するとめちゃくちゃ長いですが、下記のような結果が表示されているかと思います。 16 | 17 | ``` 18 | * Rebuilt URL to: http://laravel.jp/ 19 | * Trying 133.242.20.234... 20 | * TCP_NODELAY set 21 | * Connected to laravel.jp (133.242.20.234) port 80 (#0) 22 | > GET / HTTP/1.1 23 | > Host: laravel.jp 24 | > User-Agent: curl/7.54.0 25 | > Accept: */* 26 | > 27 | < HTTP/1.1 200 OK 28 | < Date: Mon, 04 Dec 2017 15:28:21 GMT 29 | < Server: Apache/2.2.22 (Ubuntu) 30 | < X-Powered-By: PHP/5.3.10-1ubuntu3.25 31 | < Set-Cookie: laravel_session=tskf6tvimo2unifp6jb6tj3j01; expires=Mon, 04-Dec-2017 17:28:21 GMT; path=/; HttpOnly 32 | < Set-Cookie: laravel_session=tskf6tvimo2unifp6jb6tj3j01; expires=Mon, 04-Dec-2017 17:28:21 GMT; path=/; httponly 33 | < Cache-Control: no-cache 34 | < Set-Cookie: docs_versions=eyJpdiI6InhoQ1NoMTZDN2lJMHJBcTNyaXZIWGdET21PZXR1TTVrQ3F5cG5GZjAwQ1E9IiwidmFsdWUiOiJuSUtLbmdVSEJSK1N3WlVqZ3pncnRMTGxLTzZUUVBYQk1RRXBnaThMRzFBPSIsIm1hYyI6ImIwYWI2M2RjMDk3MjRiZGI4NGJmNWRkMTBjOWUzMGVkYjQwZjkwNDBhZDE2MzJhZTM3ZjE0ZjViOTAzZThkZGYifQ%3D%3D; path=/; httponly 35 | < Vary: Accept-Encoding 36 | < Transfer-Encoding: chunked 37 | < Content-Type: text/html; charset=UTF-8 38 | < 39 | <!doctype html> 40 | 41 | <html lang="ja"> 42 | 43 | <head> 44 | <title>Laravel - ウェブ職人のためのPHPフレームワーク 45 | -------長いのでこれより下は省略-------------------------------- 46 | ``` 47 | 48 | これは http://laravel.jp/ というWebサーバに対して、`curl` というHTTPクライアントを使って接続した結果となります。 49 | 50 | 次にこのURLをブラウザ（GoogleChrome）で開いてみましょう。 51 | 52 | ![laravel](https://user-images.githubusercontent.com/11032365/33560680-c66c4918-d953-11e7-8927-5d6ae7d9d38c.png) 53 | 54 | DeveloperToolを開いてみると先に実行した `curl` と似たような `200 OK` とか `GET` みたいな単語が表示されているかと思います。 55 | 56 | ブラウザと `curl` では表示されている結果が全く異なりますが、実はこの2つはどちらもHTTP通信を行ってその結果としてHTMLのテキストを受信しているという点では同じです。 57 | 58 | ブラウザのほうはHTMLを解釈しレンダリングする能力があるので、人間が見て分かりやすいグラフィカルな表現が出来ているだけです。 59 | 60 | これがHTTPによる通信になります。 61 | 62 | ## HTTPの通信の流れ 63 | 64 | 先程の `curl` コマンドを元に解説していきます。 65 | 66 | まずはじめの `*` で始まっている部分に注目してみましょう。 67 | 68 | ``` 69 | * Rebuilt URL to: http://laravel.jp/ 70 | * Trying 133.242.20.234... 71 | * TCP_NODELAY set 72 | * Connected to laravel.jp (133.242.20.234) port 80 (#0) 73 | ``` 74 | 75 | こんな感じの記述ですね。 76 | 77 | 裏側では以下のような動きが行われています。 78 | 79 | ### DNSによる名前解決 80 | 81 | まず初めに `laravel.jp` のIPアドレスをDNSサーバに問い合わせします。 82 | 83 | DNSサーバはIPアドレスとドメイン名を紐付ける為のサーバです。DNSサーバは限られた組織内で限定公開のものもあれば、インターネット上で公開されているものもあります。 84 | 85 | 有名なのはGoogleが公開している `8.8.8.8` ですね。 86 | 87 | 下記図の1の部分、これをDNS Queryといいます。 88 | 89 | DNSサーバは応答（DNS Response）を返します。 90 | 91 | ![http-dns](https://user-images.githubusercontent.com/11032365/33562227-1b803f78-d958-11e7-90a9-e084c16e07a4.png) 92 | 93 | ちなみにこの時点でIPアドレスが得られなかった場合は下記のようなエラーが返ります。 94 | 95 | ``` 96 | * Rebuilt URL to: http://aaa/ 97 | * Could not resolve host: aaa 98 | * Closing connection 0 99 | curl: (6) Could not resolve host: aaa 100 | ``` 101 | 102 | `Could not resolve host` つまりホスト名をDNSサーバに問い合わせたけど、IPアドレスが返って来なかったという内容です。名前解決が出来なかった等と言ったりします。 103 | 104 | ### TCPコネクションの確立 105 | 106 | HTTPはTCPというプロトコルを使っています。 107 | 108 | HTTPは80番ポートを使って通信を行うので、クライアントからWebサーバ（この場合 `laravel.jp`）の80ポートに接続します。 109 | 110 | その際の手順は下記の図のようになります。 111 | 112 | ![http-tcp](https://user-images.githubusercontent.com/11032365/33609863-16fafc3a-da0d-11e7-9ff3-7bd00891330e.png) 113 | 114 | 1. クライアントからWebサーバに `TCP syn` パケットを送信します。 115 | 116 | 1. Webサーバからクライアントに `TCP syn/ack` が送信されます。 117 | 118 | 1. クライアントからWebサーバに `TCP ack` を送ります。 119 | 120 | これはTCP通信を始める際のルールで [3ウェイ・ハンドシェイク](https://ja.wikipedia.org/wiki/3%E3%82%A6%E3%82%A7%E3%82%A4%E3%83%BB%E3%83%8F%E3%83%B3%E3%83%89%E3%82%B7%E3%82%A7%E3%82%A4%E3%82%AF) と呼ばれます。 121 | 122 | 友人とLINE等でやり取りする時に例えると分かりやすいです。（AとBの会話） 123 | 124 | 1. A（クライアント）「今LINE大丈夫？（`TCP syn`）」 125 | 1. B（Webサーバ）「大丈夫だよ！（`TCP syn/ack`）」 126 | 1. A（クライアント）「よかった！今日さー〜〜（`TCP ack` 通信開始）」 127 | 128 | ざっくりとしたイメージはこんな感じです。 129 | 130 | ※ TCP通信に関してはかなり重要なので、TCP/IPのlessonでさらに詳しく説明します。 131 | 132 | ### HTTP Method "GET" によるファイル要求 133 | 134 | クライアントは `TCP ack` を送信後は相手からの反応を待たずにWebサーバに対して `GET` リクエストを送信します。 135 | 136 | 先程の `curl` コマンドの結果を再度見てみましょう。 137 | 138 | ``` 139 | > GET / HTTP/1.1 140 | ``` 141 | 142 | この `GET / HTTP/1.1` という部分がそれに該当します。 143 | 144 | `GET` というのはHTTPMethodの一種でサーバからファイルをダウンロードするという意味です。 145 | 146 | つまり `GET / HTTP/1.1` はHTTPのバージョン1.1を使って `Host: laravel.jp` からファイルをダウンロードする、という意味になります。 147 | 148 | これをWebサーバに送信します。 149 | 150 | ### HTTPステータスコードと要求したファイルの送信 151 | 152 | Webサーバは要求を受けると、`HTTP/1.1 200 OK` という文字列と共に要求したファイルが送られてきます。 153 | 154 | ※ `HTTP/1.1` の部分はWebサーバが利用しているHTTPのバージョンによって変わる可能性があります。 155 | 156 | この時、ファイルサイズが例えば1460Byte以上のMSS値（TCPが格納するユーザデータの受信可能なセグメントサイズの最大値）に収まりきらない量の通信が必要な場合は、サーバのOSがTCPセグメンテーションにより分割して複数パケットにして送ります。 157 | 158 | 下記の図のようなイメージです。 159 | 160 | ![http-response](https://user-images.githubusercontent.com/11032365/33614880-e2c03e4e-da1b-11e7-94f6-80256ffa2312.png) 161 | 162 | 以上がHTTP通信の基本的な流れです。 163 | 164 | `curl` コマンドやブラウザの結果が表示されるまでは一瞬ですが、その間にこれだけのやり取りが行われている訳です。 165 | 166 | ## HTTPリクエストの構成 167 | 168 | 先程の `curl` コマンドの結果からHTTPのリクエストの構成について説明します。 169 | 170 | HTTPリクエストは主に3つのパーツに分類されます。 171 | 172 | - リクエストライン 173 | - Header 174 | - Body 175 | 176 | の3つです。 177 | 178 | ### リクエストライン 179 | 180 | `GET / HTTP/1.1` と記載されている部分がリクエストラインです。 181 | 182 | ここではHTTPメソッド、URLパス、HTTPバージョンの3つが指定されます。 183 | 184 | #### HTTPメソッド 185 | 186 | クライアントが行いたい処理をサーバに伝える為の決まり事です。 187 | 188 | HTTPメソッドの種類は9つあります。 189 | 190 | |メソッド|意味| 191 | |:---|:---| 192 | |GET|リソースの取得| 193 | |POST|新しいリソースを作成する| 194 | |PUT|リソースを更新する| 195 | |PATCH|リソースを部分的に更新する| 196 | |DELETE|リソースの削除| 197 | |HEAD|リソースの削除| 198 | |OPTIONS|リソースがサポートしているメソッドの取得| 199 | |TRACE|プロキシ動作の確認| 200 | |CONNECT|プロキシ動作のトンネル接続への変更| 201 | 202 | ※ [リソース](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9_(WWW)) というのはWebで使われる言葉で意味が若干曖昧な部分がありますが、Webサーバ上に存在するデータの事だと思って下さい。 203 | 204 | 各メソッドの解説に関しては説明すると長くなるので、参考になりそうな記事を載せておきます。 205 | 206 | - [HTTP リクエストメソッド](https://developer.mozilla.org/ja/docs/Web/HTTP/Methods) 207 | - [HTTPメソッド(CRUD)についてまとめた](https://qiita.com/Ryutaro/items/a9e8d18467fe3e04068e) 208 | 209 | `curl` コマンドでHTTPメソッドを指定するには次のようにします。 210 | 211 | ``` 212 | curl -v \ 213 | -X POST \ 214 | https://qiita.com/api/v2/items 215 | ``` 216 | 217 | `POST` の部分に利用したいHTTPメソッドを指定すれば、OKです。 218 | 219 | ちなみに `curl` の場合、何も指定しなければ `GET` を使う事になります。 220 | 221 | ### Header 222 | 223 | クライアントから追加情報をWebサーバに渡す時に利用されます。 224 | 225 | ユーザーの入力値を渡すという使い方よりは、補足情報的な情報を渡す事が多いです。 226 | 227 | HTTP Headerはキー名と値を `: ` で繋いで設定します。 228 | 229 | 下記のようにリクエストに `-H` オプションを付けて実行します。 230 | 231 | `curl` でリクエストHeaderを設定するには以下のように `-H` オプションを付けて実行します。 232 | 233 | ※ 例としてQiita APIへのアクセスを行います。 234 | 235 | ``` 236 | curl -v \ 237 | -X GET \ 238 | -H "Authorization: Bearer rgnbfncaidaih4umxfn9yf7znfkx788ax7k55ttg" \ 239 | https://qiita.com/api/v2/users/qiita 240 | ``` 241 | 242 | こちらは [Qiita API](https://qiita.com/api/v2/docs#アクセストークン) を `Authorization` に設定している例です。 243 | 244 | ※ アクセストークンの値はデタラメですので上記のリクエストをコピーして実行しても403エラーが返ってくると思います。実際にご自身でアクセストークンを発行して試してみましょう。 ※ [Qiita API 認証認可](https://qiita.com/api/v2/docs#認証認可) を参照。 245 | 246 | Qiitaでは `Authorization` に有効なアクセストークンが入っているとAPIが利用出来る範囲が広まったり、1時間あたりに呼び出せる回数が増えたりします。 247 | 248 | 以下Qiita公式より抜粋。 249 | 250 | >利用制限 251 | 認証している状態ではユーザごとに1時間に1000回まで、認証していない状態ではIPアドレスごとに1時間に60回までリクエストを受け付けます。 252 | 253 | このように `Authorization` HeaderはクライアントとWebサーバ間の認証に利用されます。 254 | 255 | 他にもいくつか標準で定められているHeaderがあるので、詳しくは [MDN HTTP ヘッダー](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers) を参照しましょう。 256 | 257 | 後でセキュリティのところでやりますが `Set-Cookie` や `Cookie` 等は利用頻度が高いので自然と覚えると思います。 258 | 259 | ### Body 260 | 261 | リクエストの本文です。 262 | 263 | 先程に例に挙げた `https://qiita.com/api/v2/users/qiita` へのリクエスト等はパラメータであるユーザーID（"qiita" の部分がユーザーID）をURLのパスとして指定しましたが、URLにくっ付ける方法だとデータが大きい場合に非常に長いURLになってしまい分かりにくいという問題や一部のブラウザではURLの長さに制限があったりします。 264 | 265 | よって大きなデータを送信する際はリクエストボデイにデータを入れるという方法で対応を行います。 266 | 267 | 例えば、こんなWebフォームを作ってsubmitボタンをクリックすると↓ 268 | 269 | ![qiita-form](https://user-images.githubusercontent.com/11032365/33724500-e88b0d20-dbb2-11e7-854e-c8bac2a469df.png) 270 | 271 | ```html 272 |
273 |
274 | 275 | 283 |
284 | 285 |
286 | ``` 287 | 288 | formが存在するURLに対してPOSTリクエストを送ります。（formの `action` にはURLパスを設定出来るので他のURLに対しても送信出来ます） 289 | 290 | この時に `value` にユーザーが入力した値が送信されますので、Webサーバ側は `name` に指定されている `userId` というキー名でユーザーの入力値を受取る事が出来ます。 291 | 292 | 同じ事を `curl` で行う為には以下のようにオプションを設定すれば実現出来ます。 293 | 294 | URLは `https://sample.com/qiita/users` だと仮定（実際には存在しません） 295 | 296 | ``` 297 | curl -v \ 298 | -X POST \ 299 | -H "Content-Type: application/x-www-form-urlencoded" \ 300 | -d "userId=qiita" \ 301 | https://sample.com/qiita/users 302 | ``` 303 | 304 | このフォームデータの送信に関しては、かなりよく利用するので [MDN フォームデータを送信する](https://developer.mozilla.org/ja/docs/Learn/HTML/Forms/Sending_and_retrieving_form_data) を確認しておくと良いでしょう。 305 | 306 | また、階層構造がある複雑なデータを送信したい際は `Content-Type: application/json` を利用するのが有効です。 307 | 308 | ※ JSONに関してはデータ形式の一種です。詳しくは [こちら](https://dev.classmethod.jp/etc/concrete-example-of-json/) を参照して下さい。 309 | 310 | ``` 311 | curl -k \ 312 | -X POST \ 313 | -H "Content-Type: application/json" \ 314 | -d \ 315 | ' 316 | { 317 | "userId": "qiita", 318 | "list": [10, 100, 200] 319 | } 320 | ' \ 321 | https://XXXX.execute-api.ap-northeast-1.amazonaws.com/dev/auth/authentication 322 | ``` 323 | 324 | このくらいのデータだと対した差はないですが、Bodyの構造が複雑であれば、JSONを利用したほうが分かりやすくてオススメです。 325 | 326 | ### Query String 327 | 328 | 単に `query` と呼ばれる事も多いです。 329 | 330 | これはURLの後ろにパラメータをくっつけて送信する方法です。 331 | 332 | `curl -v https://qiita.com/api/v2/schema?locale=ja` のようにURLの後ろに `?locale=ja` とします。 333 | 334 | こうするとWebサーバ側では `locale` というキー名で `ja` という値が取得出来ます。 335 | 336 | 複数繋げる場合は `?page=1&per_page=20` のように `&` で繋げます。 337 | 338 | 基本的には `GET` でオプションパラメータ的な値を送信する際に利用される事が多いです。 339 | 340 | ## HTTPレスポンスの構成 341 | 342 | [HTTP メッセージ](https://developer.mozilla.org/ja/docs/Web/HTTP/Messages) にあるように基本的に3つの要素で構成されます。 343 | 344 | ### ステータスコード 345 | 346 | [HTTP レスポンスステータスコード](https://developer.mozilla.org/ja/docs/Web/HTTP/Status) を確認しながら以降の説明を読んで下さい。 347 | 348 | Webサーバからクライアントにレスポンスを返す時にそのリクエストが成功したのか、失敗したのかを示す数値です。 349 | 350 | 詳しくは [HTTP レスポンスステータスコード](https://developer.mozilla.org/ja/docs/Web/HTTP/Status) を参照するのが良いですが、ざっくりと以下の点を覚えておきましょう。 351 | 352 | ### 200番台のステータスコード 353 | 354 | 200番台から始まるステータスコードはリクエストが成功した事を表します。 355 | 356 | `GET` なのであれば、クライアントが要求するリソースが見つかったという意味で `200 OK` を返しますし、`POST` の場合は `201 Created` を返しクライアントがリクエストした新しいリソースが作成された事を伝えます。 357 | 358 | ### 400番台のステータスコード 359 | 360 | これはクライアントのリクエストが正しくない等、クライアントに原因がある場合に返されるコードです。 361 | 362 | 例えば `404 Not Found` はクライアントが要求するリソースが存在しない事を示し、`403 Forbidden` はクライアントにリソースへのアクセス権がない事を表します。 363 | 364 | このステータスコードが返却された場合、クライアントはリクエストの方法を見直す必要があります。 365 | 366 | ### 500番台のステータスコード 367 | 368 | Webサーバ側が原因で何らかの問題が発生している場合に返すステータスコードです。 369 | 370 | これが返ってきた場合は、400番台と違いクライアント側に出来る事は基本的にありません。 371 | 372 | Webサーバの管理対象が自分ではない場合はWebサーバの管理者に問い合わせる等を行うしかないでしょう。 373 | 374 | その他、リダイレクト（URLが変更になった際にWebサーバ側で新URLに転送する仕組み）を表す300番台があります。 375 | 376 | `301 Moved Permanently` は自分がWebサーバの開発者でURLを変更した時等に良く使います。 377 | 378 | ### Header 379 | 380 | レスポンスに含まれるHTTPHeaderです。 381 | 382 | 一番初めに例に上げた `curl -v http://laravel.jp` の結果で言うと下記の部分になります。 383 | 384 | ``` 385 | < Date: Mon, 04 Dec 2017 15:28:21 GMT 386 | < Server: Apache/2.2.22 (Ubuntu) 387 | < X-Powered-By: PHP/5.3.10-1ubuntu3.25 388 | < Set-Cookie: laravel_session=tskf6tvimo2unifp6jb6tj3j01; expires=Mon, 04-Dec-2017 17:28:21 GMT; path=/; HttpOnly 389 | < Set-Cookie: laravel_session=tskf6tvimo2unifp6jb6tj3j01; expires=Mon, 04-Dec-2017 17:28:21 GMT; path=/; httponly 390 | < Cache-Control: no-cache 391 | < Set-Cookie: docs_versions=eyJpdiI6InhoQ1NoMTZDN2lJMHJBcTNyaXZIWGdET21PZXR1TTVrQ3F5cG5GZjAwQ1E9IiwidmFsdWUiOiJuSUtLbmdVSEJSK1N3WlVqZ3pncnRMTGxLTzZUUVBYQk1RRXBnaThMRzFBPSIsIm1hYyI6ImIwYWI2M2RjMDk3MjRiZGI4NGJmNWRkMTBjOWUzMGVkYjQwZjkwNDBhZDE2MzJhZTM3ZjE0ZjViOTAzZThkZGYifQ%3D%3D; path=/; httponly 392 | < Vary: Accept-Encoding 393 | < Transfer-Encoding: chunked 394 | < Content-Type: text/html; charset=UTF-8 395 | ``` 396 | 397 | たくさんの種類が多いので詳しくは [こちら](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers) を参照して下さい。 398 | 399 | [HTTPレスポンスヘッダによるセキュリティ対策](https://qiita.com/mint__/items/a4039d3cc659959d9231) に書いてあるようにセキュリティ対策目的で付与されるケースも多いです。 400 | 401 | RFCで定義されている物以外にも、Webサーバの実装者が独自のHeaderを定義する事が出来ます。MDNに以下の記述があります。 402 | 403 | >'X-' 接頭辞を使用して独自のヘッダーを追加できますが、この慣習は 2012 年 6 月に非推奨になりました。これは、RFC 6648 で非標準のフィールドが標準になったときに発生した不便さのためです。 404 | 405 | ただし現行でも `X` から始まる独自のResponseHeaderは結構使われています。（AWSのサービスとか特に独自のHeaderが結構あります） 406 | 407 | 例を1つ挙げると `X-Request-Id` というRequestの識別を行う事を目的とした物があります。 408 | 409 | これは [Ruby on Rails](http://rubyonrails.org/) という有名なWebアプリケーションを利用した際に自動的にResponseHeaderに含まれます。 410 | 411 | ### Body 412 | 413 | Responseのデータそのものです。 414 | 415 | 返ってくるデータ形式はHTMLやJSONをはじめとして様々な物があります。 416 | 417 | ResponseHeaderの `Content-Type` を見ると、どのような形式のデータかが分かります。 418 | 419 | ## Webサーバ 420 | 421 | Webサービスを作成する為にはWebサーバが必要になります。 422 | 423 | Node.jsのような単体でWebサーバとしての機能を備えている物もありますが、基本的には全面にWebサーバを置いてWebサービスを配信するケースが多いです。 424 | 425 | ここでは代表的な2つを紹介します。 426 | 427 | ### [Apache](https://ja.wikipedia.org/wiki/Apache_HTTP_Server) 428 | 429 | おそらく世界で最も使われているWebサーバです。 430 | 431 | [日本語の公式ドキュメント](https://httpd.apache.org/docs/2.4/ja/) はこちらになります。 432 | 433 | 利用用途としてはApache経由でPHP等のプログラムを実行してそれをWebサービスとして配信する形が最も多いです。 434 | 435 | 特徴としてはプロセス駆動アーキテクチャでマルチプロセス。 436 | 437 | 各リクエストをプロセスに割り当てて処理を行う方法です。 438 | 439 | この為、各プロセスは独立しており、サーバ側のプログラミングはシンプルになりますが、一度に大量のリクエストが来るとメモリ不足になりやすい等の欠点を抱えています。 440 | 441 | ### [nginx](https://ja.wikipedia.org/wiki/Nginx) 442 | 443 | こちらも有名なWebサーバです。 444 | 445 | - [公式ドキュメント](http://nginx.org/en/) 446 | - [日本語ドキュメントLink](http://nginx-ug.jp/link/) 447 | 448 | イベント駆動アーキテクチャ、シングルスレッドモデル。 449 | 450 | イベントループ方式で起動します。 451 | 452 | 詳しくは下記の記事を参照して下さい。 453 | 454 | https://blog.mosuke.tech/entry/2016/06/04/180122/ 455 | 456 | 同時接続数が増えても消費メモリは少なく、非同期処理なので高速に動作しますが、リクエストの処理時間が長いとキューにリクエストが溜まってしまい、性能が劣化します。 457 | 458 | よって一度のリクエストで時間がかかるような処理が多いサービスには向いていません。 459 | 460 | ## [Apache](https://ja.wikipedia.org/wiki/Apache_HTTP_Server) と [nginx](https://ja.wikipedia.org/wiki/Nginx) どちらを採用するべきか？ 461 | 462 | どちらも長所と短所があり、どちらが優れているという話ではありません。 463 | 464 | 下記のような記事を参考にどちらを採用するか考えると良いでしょう。 465 | 466 | - [Apacheとnginxどちらを採用すべきかメリット・デメリット比較](https://qiita.com/pink/items/7709218310b5cf11eabe) 467 | - [NginxとApache HTTP Serverの違いメモ](https://qiita.com/tomoyamachi/items/06b2eca14987a30b8fda) 468 | - [ApacheとNginxについての比較](https://www.marineroad.com/staff-blog/8095.html) 469 | 470 | ## HTTPの学習をさらに進めるには？ 471 | 472 | HTTPは単純なように見えてかなり奥の深い技術です。 473 | 474 | しかし、Webエンジニアにとっては基本となる非常に大切な技術なので、本格的に学習しておく事をオススメします。 475 | 476 | ※ 一度習得してしまえば、長く使える技術なので非常にオススメです。 477 | 478 | 学習を進める上で最もオススメなのは [Real World HTTP](https://github.com/oreilly-japan/real-world-http) という書籍です。 479 | 480 | HTTPの歴史から、最新仕様であるHTTP2まで対応しているので非常にオススメです。 481 | 482 | また [Webを支える技術](https://www.amazon.co.jp/dp/4774142042) という書籍もオススメです。 483 | 484 | こちらはHTTPの事だけでなく、良いURLの設計やJSON等のデータフォーマットに関しても記述があるのでWebエンジニアの最初の一冊としても最適だと思います。 485 | 486 | ただし内容が少し古い点があるので、以下の点に注意しましょう。 487 | 488 | - HTMLは最新仕様の5ではなく古い4系の記述なのでこれをそのまま開発に活かす事は難しいです。開発ではHTMLの5系の記述でマークアップしましょう。 489 | - XMLの説明に第11章〜第13章までのかなり長いページ数を割いていますが、現在ではデータフォーマットに使われるのはJSONが主流なので、このあたりは軽く読んでおけば問題ありません。（逆にJSONについての知識は現在のWeb開発において非常に重要です） 490 | -------------------------------------------------------------------------------- /docs/linux/README.md: -------------------------------------------------------------------------------- 1 | # Linuxの基礎知識 2 | 3 | ## Linuxの概要 4 | 5 | OSの一種です。 6 | 7 | OSとはオペレーティングシステムの略で、コンピュータを操作する為の基本的な機能を提供します。 8 | 9 | Linux以外だと [Microsoft Windows](https://ja.wikipedia.org/wiki/Microsoft_Windows) や [macOS](https://ja.wikipedia.org/wiki/MacOS) 等があります。 10 | 11 | 1991年に当時フィンランドの大学生だった「リーナス・トーバルズ」氏によりUNIXを参考に開発・公開されました。 12 | 13 | UNIXに関しては [こちらの記事](https://eng-entrance.com/unix_linux) が詳しいので見てみて下さい。 14 | 15 | UNIXベースで一番身近なOSだと [macOS](https://ja.wikipedia.org/wiki/MacOS) があります。 16 | 17 | ## Linuxの特徴 18 | 19 | 以下のような特徴があります。 20 | 21 | - オープンソース（誰でも無料で使えるしソースコードの改変も自由） 22 | - 軽量なので比較的古いPCでも動く 23 | - GUI（Character User Interface）が中心の操作 24 | 25 | ## Linuxの利用用途 26 | 27 | オープンソースという特性上、世界中の様々な箇所で使われています。 28 | 29 | 一番身近な例だとスマートフォンに搭載されている、AndroidはGoogleが開発したLinuxベースのOSです。 30 | 31 | ## Linuxを学ぶ目的 32 | 33 | WebエンジニアにとってもWebサービスを提供する為のWebサーバやデータを永続化する為のデータベースサーバを作成する際にLinuxを利用するのが一般的です。 34 | 35 | よってWebエンジニアにとってはLinuxは必須スキルとなります。 36 | 37 | ## カーネル 38 | 39 | OSの中核となる部分でハードウェアと直接やり取りするもっとも中心的な機能を受け持ちます。 40 | 41 | カーネル以外の部分をユーザランドと呼び、ファイルシステム、ファイル操作コマンド、シェルなどの基本的なソフトウェア郡を指します。 42 | 43 | ## Linuxディストリビューション 44 | 45 | ごく一般の利用者が利用する際にはカーネルをダウンロードしただけでは、コンピュータを利用出来る状態に持っていくのは難しいでしょう。 46 | 47 | そこでカーネルに様々なオープンソースソフトウェアを組み合わせて、インストーラーと一緒に配布しています。 48 | 49 | これをLinuxディストリビューションと呼びます。 50 | 51 | ### Linuxディストリビューションの種類 52 | 53 | [Linuxディストリビューション](https://ja.wikipedia.org/wiki/Linux%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E3%83%AA%E3%83%93%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3) 54 | にはたくさんの種類があります。 55 | 56 | 主にDebian系、 Red Hat系、 Slackware系があります。 57 | 58 | ※ Slackware系は玄人向けで現状はあまり利用されていない。 59 | 60 | それぞれが目的にあったカスタマイズがされており、その中から用途にあった物を選ぶのが良いでしょう。 61 | 62 | 例えば普通の個人PCとして利用するなら、Debian系の[Ubuntu](https://www.ubuntulinux.jp/) 、 63 | 64 | サーバ用途として利用するならRedHat系の[CentOS](https://www.centos.org/) 等を選択します。 65 | 66 | 本カリキュラムではRedHat系の [Amazon Linux](https://aws.amazon.com/jp/amazon-linux-ami/) を利用して学習を進めます。 67 | 68 | 理由はAmazon LinuxはAWS上で利用が推奨されているディストリビューションなので学習を進める上で効率が良いと判断した為です。 69 | 70 | 使い方も [CentOS](https://www.centos.org/) によく似ています。 71 | 72 | ## Linuxの学習方法 73 | 74 | まずは使って見るのが一番です。 75 | 76 | [ojt-linux-vagrant](https://github.com/keitakn/ojt-linux-vagrant) というリポジトリを用意しました。 77 | 78 | こちらは使って学習のほうを進めていきましょう。 79 | 80 | 使い方はリポジトリのREADMEに記載しておきます。 81 | 82 | また体系的に学習をする為には [Linux標準教科書](http://www.lpi.or.jp/linuxtext/text.shtml) を読むのが良いでしょう。 83 | 84 | 無料でダウンロードが可能です。 85 | 86 | 最近公開された [Linuxの基礎用語を完全理解するためにエンジニアが作成した「10のミニプロジェクト」](https://gigazine.net/news/20210220-getting-better-linux-10-project/) もオススメです。 87 | -------------------------------------------------------------------------------- /docs/linux/task.md: -------------------------------------------------------------------------------- 1 | # 課題1内容 2 | 3 | [ojt-linux-vagrant](https://github.com/keitakn/ojt-linux-vagrant) を使い以下の環境を構築して頂きます。 4 | 5 | 作成するのはNode.jsの実行環境 + OSの基本設定です。 6 | 7 | 完了条件として以下の条件を満たして頂きたいです。 8 | 9 | - OSの各パッケージが最新に更新されている事（yumアップデート） 10 | - nodebrewによりバージョン管理が行われており最新のNode.jsがインストールされている事（Node.jsは特別なパッケージ等は入れなくてOKです） 11 | - タイムゾーンが日本時間（JST) になっている事 12 | - localeが日本語設定になっている事 13 | - swap領域が追加されている事（どのくらいの領域を確保するかはお任せします） 14 | - 個人名のユーザーが追加されている事（追加したユーザーでサーバ上にSSH接続が出来る事） 15 | - IPv6が無効化されている事 16 | 17 | ## アウトプット 18 | 19 | 成果物として、環境構築の手順を示したQiitaの記事を作成して下さい。 20 | 21 | ※ インターネット上に公開されてしまうので抵抗がある場合は限定共有投稿でも構いません。 22 | 23 | あまり良い書き方でもないですが参考までに私が過去に書いた記事 [Rails5,MySQLの開発環境構築を行う](https://qiita.com/keitakn/items/b19bf134ff76e6e579eb) を共有させて頂きます。 24 | 25 | 記事は下記の点に注意して作成して下さい。 26 | 27 | - 書いてある手順通りに行うと間違いなく環境構築が出来る事 28 | - 各コマンドを実行している理由（なぜそれが必要かを）が記載されている事 29 | 30 | ## 分からない時 31 | 32 | 自分で調べてどうしても分からない時はメンターに相談しましょう。 33 | 34 | メンターは質問されたら丁寧に対応する事！ 35 | 36 | [質問は恥ではないし役に立つ](https://qiita.com/seki_uk/items/4001423b3cd3db0dada7) という素晴らしい記事がありましたので、参考にすると良いでしょう。 37 | 38 | ## 参考になりそうなリンク 39 | 40 | - [Amazon EC2 初期設定 | AmazonLinuxを立ち上げたら最初にすべき10の設定 [sshログイン〜ec2-userの削除まで] 41 | ](http://www.carameltrip.com/entry/20170112/1484222151) 42 | - [Amazon Linux サーバセットアップメモ](https://qiita.com/Ping/items/09deb80a0be86d5e3145) 43 | 44 | -------------------------------------------------------------------------------- /docs/linux/vim.md: -------------------------------------------------------------------------------- 1 | # vi(vim)の基礎知識 2 | 3 | viはLinuxに搭載されているテキストエディタです。 4 | 5 | サーバ上でファイルを編集する際に利用します。 6 | 7 | かなり奥が深く、ここでは説明しきれないので最低限覚えておくべき内容だけ記載しておきます。 8 | 9 | よく似たモノに `vim` がありますがこれは `vi` 上位に位置するエディタで非常に高機能です。 10 | 11 | Linuxディストリビューションによっては `vi` のエイリアスに `vim` が設定されている事も多いです。（Amazon Linuxは設定されています） 12 | 13 | ターミナル上で以下のコマンドを実行してみて下さい。 14 | 15 | ```bash 16 | which vi 17 | ``` 18 | 19 | 下記のように表示されるかと思います。 20 | 21 | ```text 22 | alias vi='vim' 23 | /usr/bin/vim 24 | ``` 25 | 26 | なので `vi` と打ってもこのようにエイリアスが設定されている場合は `vim` を利用している事になります。 27 | 28 | ちなみに `vim` を使った後に `vi` を使うと不便で仕方なく感じます。 29 | 30 | これから覚える人は `vim` の一択でいいでしょう。 31 | 32 | ちなみに完全に余談ですが `vim` を極めた人達は全てにおいて `vim` を使いたがります。 33 | 34 | このような人たちの事をネット上では [Vimmer](http://d.hatena.ne.jp/keyword/Vimmer) と呼ばれてたりします。 35 | 36 | ## vi(vim)の使い方 37 | 38 | 以下のコマンドでファイルを開きます。 39 | 40 | ```bash 41 | $ vi ファイル名 42 | ``` 43 | 44 | 簡単に使い方の説明をします。 45 | viにはノーマルモードと入力モードがあり、はじめはノーマルモードで起動されます。 46 | 47 | ### ノーマルモードで利用出来る機能 48 | 49 | 以下はノーマルモードで利用出来る機能です。 50 | 51 | #### カーソル移動 52 | 53 | カーソルの移動はノーマルモードで行います。 54 | 55 | 対応するキーは下記の通りです。 56 | 57 | | コマンド | 動作 | 58 | |:--------|----:| 59 | | k | 上移動 | 60 | | l | 右移動 | 61 | | h | 左移動 | 62 | | j | 下移動 | 63 | 64 | 65 | ただし先程も記載した通り、実質使っているのは `vi` ではなく `vim` なので、普通に方向キーで移動が出来ます。 66 | 67 | ただしvi互換モードという状態の場合は方向キーでの移動が出来ません。 68 | 69 | おそらく多くの人が方向キーで移動するという一般的な操作に慣れているかと思うので、 70 | 71 | その場合はホームディレクトリに `.vimrc` というファイルを作り以下の記述を追加しましょう。 72 | 73 | ```bash 74 | $ touch ~/.vimrc 75 | $ vi ~/.vimrc 76 | ``` 77 | 78 | ↓以下を追記する事で「vi互換モード」を無効化する。 79 | 80 | ```text 81 | set nocompatible 82 | ``` 83 | 84 | 真の [Vimmer](http://d.hatena.ne.jp/keyword/Vimmer) の方々から言わせれば、キー操作に慣れろよと言われるかもしれませんが、 85 | 86 | 本カリキュラムの目的は「Webサービスを0から開発出来るようになる」事なので、ここにあまり時間をかけなくても良いと個人的には思います。 87 | 88 | もちろん `vim` を極めようと思う事自体は悪い事ではなくむしろ良い事です。 89 | 90 | しかし一通りの事が出来るようになってから少しづつ極めるのが良いでしょう。 91 | 92 | 当たり前ですが `vim` だけを極めてもWebサービスは作れないので。。。 93 | 94 | ちなみに私が今まで触ってきたRedHat系のディストリビューションは「vi互換モード」が無効化状態（方向キーで移動が出来る状態）でした。 95 | 96 | なので上記の設定等も頭の片隅程度に留めておくだけで十分です。 97 | 98 | #### 入力モードへの移行 99 | 100 | キーボードの `a` を押すと入力モードに移行します。 101 | 102 | 他の方法でも移行できますが、ここでは割愛します。 103 | 104 | もう一度ノーマルモードに戻るには `esc` キーを押します。 105 | 106 | #### 検索 107 | 108 | `/***` のように `***` の部分に検索したい文字列を入れます。 109 | 110 | 例えばこんな感じのテキストがあって "sample" という文字列を検索します。 111 | 112 | ```text 113 | sample0 114 | sample1 115 | sample2 116 | sample3 117 | ``` 118 | 119 | ↓こんな感じで検索結果がハイライトされます。 120 | 121 | vi-1 122 | 123 | `n` キーを押すと見つかった箇所に上から順番に飛びます。 124 | 125 | #### 置換え 126 | 127 | 開いているファイル内の全てのファイルを置き換える例です。 128 | 129 | :%s/置換えたい単語/置換後の単語/g 130 | 131 | "example" という単語を "sample" に置き換えるには `:%s/example/sample/g` を実行します。 132 | 133 | [vim 文字列置換 基本的な事](https://qiita.com/shirochan/items/a16487d0739f455b5e8a) という良い記事がありましたので共有させて頂きます。 134 | 135 | #### コピー&ペースト 136 | 137 | コピーしたい行に移動して `yy` と入力します。 138 | 139 | `p` でコピーした内容を貼り付けます。 140 | 141 | `3yy` のように入力すると今いる行から3行文コピーされます。 142 | 143 | 全体をコピーしたい時は `:%y` と入力すると全コピー出来ます。 144 | 145 | 他にもn行目からm行までを指定行をコピーする場合は以下のように入力します。 146 | 147 | ↓は1行目から4行目までコピーする際の例です。 148 | 149 | `:1,4y` 150 | 151 | #### 行番号を表示する 152 | 153 | `:set number` と入力しましょう。 154 | 155 | #### 指定の行にジャンプ 156 | 157 | `*G` で指定行にジャンプします。 158 | 159 | Gは大文字です、なので20行目にジャンプする場合は `20G` と入力します。 160 | 161 | #### 最初の行にジャンプ 162 | 163 | `gg` と入力します。こちらは小文字です。 164 | 165 | #### 最後の行にジャンプ 166 | 167 | `GG` と入力します。こちらは大文字です。 168 | 169 | #### 文字コードの変更 170 | 171 | 文字化けしている場合は `:set encoding=utf-8` 等と文字コードを指定すれば見れる可能性があります。 172 | 173 | #### 1つ前の状態に戻る（undo） 174 | 175 | `u` を押すと1つ前の状態に戻ります。 176 | 177 | Macで言う `command + z` , Windowsで言う `Control + z` ですね。 178 | 179 | #### 今いる行を削除する 180 | 181 | `dd` と入力すると現在いる行を削除します。 182 | 183 | #### 前のコマンドを繰り返す 184 | 185 | `.` を押すと前に入力したコマンドを再度実行します。 186 | 187 | （例）1つ前に `dd` を実行していたら `.` を入力する事で再度 `dd` を実行する。 188 | 189 | #### ファイルを保存する 190 | 191 | `:w` を入力すると保存出来ます。 192 | 193 | #### 閉じる 194 | 195 | `:q` で閉じます、この時に `:wq` と入力すると編集内容を保存してから閉じます。 196 | 197 | 逆に編集内容を破棄して閉じたい場合は `:q!` と入力します。 198 | 199 | ### 入力モードで出来る事 200 | 201 | キー操作がいろいろありますが。ここでは割愛させて頂きます。 202 | 203 | 普通にクリップボードに保存されている内容の貼り付けやコピー等も出来るので、案外それで何とかなったりします。 204 | 205 | #### ノーマルモードへの移行 206 | 207 | `esc` キーを押下するとノーマルモードへ戻ります。 208 | 209 | ### その他 210 | 211 | #### viewコマンド 212 | 213 | `view ファイル名` で参照専用で `vim` を開きます。 214 | 215 | しかし巨大なファイルを開くと結構なメモリを消費するのでサーバに悪影響を及ぼす可能性があります。 216 | 217 | そもそも参照専用なので `less` や `cat` を使うようにしたほうが良いと個人的には思います。 218 | 219 | ## vimは奥が深い 220 | 221 | ここで紹介したのは、ほんの一部です。（ちょっと調べると分かりますが、マジで奥が深いです） 222 | 223 | 他にも色々な事が出来ます、例えば [Vim plugin](https://qiita.com/okamos/items/caf5a0b19ce893a75363) で機能を追加したり自分でPluginを開発したり、[復数のファイルを開いて](https://qiita.com/akata/items/52653ffbc02f46709e3a) 編集したり等です。 224 | 225 | しかし最低限ここに載っている内容をある程度、練習したら次のステップに進む事をオススメします。 226 | 227 | Web開発を0から行う為にはまだ覚える事がたくさんあるので。。。 228 | -------------------------------------------------------------------------------- /docs/management/EngineerTechnicalInterview.md: -------------------------------------------------------------------------------- 1 | # エンジニアを採用する時に面談で聞くこと 2 | 3 | 私はフリーランスエンジニアですが委託先の採用面接、書類審査も業務として行った経験があります。 4 | 5 | エンジニアに対して、どのような視点で採用を決めていたかをここに記載します。 6 | 7 | ## 経歴をベースとした質問 8 | 9 | 例えばこんな経歴があったと仮定し話を進めます。 10 | 11 | ``` 12 | # 医療従事者向けのコミュニティサイトの全面リプレイス 13 | 14 | ## 概要 15 | 医療従事者向けのコミュニティサイトのDBも含めた全面リプレイス 16 | 17 | ## 利用技術 18 | PHP（Laravel） 19 | TypeScript 20 | Next.js（React） 21 | Nuxt.js（Vue.js） 22 | AWS 23 | JIRA 24 | Confluence 25 | GitHub 26 | CircleCI 27 | 28 | # プロジェクトの規模 29 | 開発者5名、プロジェクトマネージャー1名 30 | ``` 31 | 32 | ### 役割が明確に分かるように質問を行う 33 | 34 | 既に職務経歴書に書いてある場合は省略します。 35 | 36 | この中でどのような役割を担っていたかを明確にします。 37 | 38 | 技術選定やアーキテクチャの設計に深く関わっていたケースと1人のメンバーとして参画したのでは、同じ案件でも得られる経験値は大きく違うからです。 39 | 40 | 技術選定やアーキテクチャに深く関わっていた場合、良い評価になります。 41 | 42 | ### アーキテクチャの全体概要を詳しく質問する 43 | 44 | アーキテクチャの詳細に対してより突っ込んだ質問をします。 45 | 46 | 例えば以下のような質問です。 47 | 48 | - AWS上でどのようなサービスが使われていましたか 49 | - Nuxt.jsはどのモードで運用され、どのような実行環境で動作していましたか 50 | - PHPとLaravelはどのような環境で実行されていましたか 51 | - アプリケーションのログはどのように運用されていましたか 52 | - CI/CDはどのように実現されていましたか 53 | 54 | これらは例えアーキテクチャ選定に関わっていなかったとしても答えられる質問です。 55 | 56 | 曖昧な答えや分からない部分が多いと、全体構成を意識した開発が出来ない可能性を疑います。 57 | 58 | ### 失敗の経験 59 | 60 | 今までの経歴からどのような失敗を経験し、どのような事を学んだかを聞きます。 61 | 62 | - 失敗から何を学んでいるか 63 | - 失敗の原因を論理的かつ客観的に分析出来ているか 64 | 65 | この2つが曖昧だとメタ認知能力が低い可能性ありと判断します。 66 | 67 | ## 技術に関する質問 68 | 69 | 各技術に関するマニアックな知識は問いません。 70 | 71 | 基礎技術があるか、技術に対してどれだけ自分の考えを持っているかを重視します。 72 | 73 | ### 技術選定の基準について 74 | 75 | 例えば以下のような質問をします。 76 | 77 | これらの問いには絶対な正解はありません。 78 | 79 | 答えは人によって様々ですが、技術に対して自分なりの考えがないと答えるのが難しい質問です。 80 | 81 | - 技術についてどれだけ深く考える事が出来るか 82 | - 曖昧な質問に対して具体的な言葉で返答出来るか 83 | 84 | これらの点をチェックします。 85 | 86 | >最近、技術の進歩やビジネスのスピードが上がっています。 87 | >これらの状況に対応する為に技術選定やアーキテクチャ設計でどのような事を意識するか教えて欲しいです。 88 | 89 | >オブジェクト指向における設計に関してあたなの基準を教えて下さい。 クラス・メソッドはそれぞれ何行くらいの大きさまで許容出来ますか？ またメソッドの引数は何個まで許容出来ますか？ それぞれ理由を交えて教えて下さい。 90 | 91 | >長い間、オブジェクト指向がメインでしたが最近は関数型のプログラミングが見直されていると感じます。 その理由についてはどのように考えますか？ またあなたが関数型のパラダイムを取り入れる場合はどのような状況を想定しますか？ 92 | -------------------------------------------------------------------------------- /docs/management/README.md: -------------------------------------------------------------------------------- 1 | # マネジメント入門 2 | 3 | この資料ではマネジメントの基礎を学びます。 4 | 5 | 私は過去に6人程のチームをマネジメントしていた経験しかないので、専門職としてのマネージャーではありません。 6 | 7 | しかしある程度はマネジメントについて学び実戦した経験があるので、それについて書かせて頂きます。 8 | 9 | ## マネジメントとは何か 10 | 11 | マネジメントとは何をする仕事かを考えてみましょう。 12 | 13 | 有名な書籍 [マネジメント基本と原則](https://www.amazon.co.jp/dp/4478410232) では以下のように定義されています。 14 | 15 | >組織の目標を設定し、組織を作る。部下の動機付けやコミュニケーションをはかり、その部下を評価し、それを元に人材育成するという使命を持った役職です。 16 | 17 | また著者のドラッカーはマネジメントを「組織に成果をあげさせるための道具、機能、機関」と定義しています。 18 | 19 | マネジメントを専門で行う人をマネージャーと言います。 20 | 21 | 簡潔に言うと様々な手段で自発的に人を動かす人の事です。 22 | 23 | ## 技術者がマネジメントを学ぶ意味 24 | 25 | 将来もずっと技術者として生計を立てて行きたいと思っている人がマネジメントを学ぶ意味はあるでしょうか。 26 | 27 | 私の答えは「Yes」です。 28 | 29 | それは下記のような理由からです。 30 | 31 | ### 無能なマネージャーから自らを守る為 32 | 33 | [社畜にならない事の重要性](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/Shachiku.md) で触れましたが、日本の教育とは基本的に命令に忠実な兵隊を生み出す為の教育です。 34 | 35 | その為、大局的な視点を要求されるマネージャーには全く向いていません。 36 | 37 | それもあって日本企業のマネージャーの中にはかなり高い確率で無能なマネージャーが存在しています。 38 | 39 | ※無能なマネージャーの定義は後で書きます。 40 | 41 | このような連中から身を守る為には、マネジメントのアンチパターンを知って論理武装しておく事が重要です。 42 | 43 | エンジニアリングのスキルがお金を稼ぐ為の武器なら、マネジメントの正しい知識は理不尽から身を守る盾の役割を果たします。 44 | 45 | ### 社畜思想に洗脳される事を防ぐ為 46 | 47 | 無能なマネージャーの基本方針は洗脳と恐怖によって人を動かす事です。 48 | 49 | その言動は現代で最も避けるべき社畜的な思想が色濃く出ているのが特徴です。 50 | 51 | [社畜にならない事の重要性](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/Shachiku.md) で語っているように社畜を避ける事は良いエンジニアを目指す上で必要不可欠です。 52 | 53 | 正しい知識を習得して、社畜思想に洗脳されないよう立ち回る事が重要です。 54 | 55 | ## 無能なマネージャーの特徴 56 | 57 | 一言で言うと [社畜にならない事の重要性](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/Shachiku.md) で定義されている社畜の特徴を持っている事です。 58 | 59 | 代表的な特徴を順番に見ていきましょう。 60 | 61 | ### ヒエラルキーが物事の判断基準になっている 62 | 63 | ヒエラルキーを絶対視するマネージャーは [社畜にならない事の重要性](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/Shachiku.md) でも最もヤバイ特徴として紹介した権威主義に囚われています。 64 | 65 | 物事の正しさよりも組織内のヒエラルキーを優先し物事を判断する為、組織全体が間違った方向に進む事が多々あります。 66 | 67 | この手のマネージャーは社長や役員が言った事を良く考えもせずに真に受け、意味不明な忖度を勝手に行います。 68 | 69 | その目的は組織に利益をもたらす事ではなく、マネージャー自らの評価を上げる事なので、直下で働くエンジニアには十分に本来の目的が伝わりません。 70 | 71 | 無能なマネージャーが持つ特徴の中でも最も厄介な物です。 72 | 73 | [失敗の本質](https://www.amazon.co.jp/dp/4478016879) という書籍ではこの権威主義がもたらす弊害を紹介しているので読んで見ると良いでしょう。 74 | 75 | ### 細かい指示を出す（マイクロマネジメント） 76 | 77 | マネージャーと言うのは人を動かして組織全体のパフォーマンスを向上させるのが仕事です。 78 | 79 | マネージャーがいちいち開発の細かい事や酷い場合は採用する言語やフレームワークまで決めてしまっているような状態はマイクロマネジメントと言えるでしょう。 80 | 81 | これをやると開発者から自主性が失われてしまいます。 82 | 83 | 開発チームが自立していないと常に指示を出す側がボトルネックとなり、組織全体のパフォーマンスは低下します。 84 | 85 | さらに人数が多くなればなるほどコミュニケーションコストが増えていくので、非効率に拍車をかけた状態になります。 86 | 87 | そんな無能なマネージャーには下記のTweetを見せると良いでしょう。 88 | 89 |

@kimutakura 私の経験では生産性を発揮させるのに有効なのは強制ではなく自由です。規範は必要なこともあるでしょうが、あくまでも自発的なものです。

— Yukihiro Matsumoto (@yukihiro_matz) 2010年9月15日
90 | 91 | マイクロマネジメントをするマネージャーは人を動かし、人を育てるというマネージャー本来の責務を完全に見失っていると言えるでしょう。 92 | 93 | ### 性別という概念に囚われ過ぎている 94 | 95 | 昔、ある管理職（社畜）と会話した時に下記のような発言をしていました。（この発言を行っていたのは男性です） 96 | 97 | - 女はどうせ結婚して辞めるから教えたくない 98 | - 女だから調整業務のほうが得意そうだしそっちに回すよ 99 | - 男であんなに仕事が出来なかったらヤバイ 100 | - 男だから幹部候補生にする 101 | 102 | これらの発言から分かるのは、この社畜が旧来の日本的思想に強く囚われているという事です。 103 | 104 | 「男は仕事をして女は家を守る」という価値観です。 105 | 106 | 最近の研究では、男女に脳の違いはないという事が言われています。 107 | 108 | 男はこうだ、女はこうだというのはタダの思い込みに過ぎないという事です。 109 | 110 | - （参考）[完全な“男脳”と”女脳”は ほぼ存在しないことが判明](http://karapaia.com/archives/52206786.html) 111 | - （参考）[「男脳・女脳」は時代遅れのエセ科学？最新研究でメッタ斬り](https://matome.naver.jp/odai/2148802879635505701) 112 | - （参考）[男脳・女脳の嘘と「エセ脳科学」の罪深さ](https://leeza-phoneki.com/2019/02/23/fake-neuroscience/) 113 | - （参考）[「男脳」「女脳」のウソ、思い込みを手放す](https://ameblo.jp/mikicry2/entry-12249304869.html) 114 | - （参考）[信じていたら恥ずかしい…男性脳・女性脳診断は大嘘 違いはあるがごくわずか](http://1000nichi.blog73.fc2.com/blog-entry-9927.html) 115 | 116 | 世の中全体が暗示にかけられているという事でしょう。 117 | 118 | まあ科学的にどうこうという話を置いておいたとしても、普通に考えて、役割を任せる時に考慮すべき点は「業務遂行能力が十分にある事」のみです。 119 | 120 | 無能なマネージャーとはこのように意味不明な価値観で人事を決定したりします。 121 | 122 | ### 年齢という概念に囚われ過ぎている 123 | 124 | 無能なマネージャーは必要以上に年齢を気にします。 125 | 126 | 例えば下記のような発言です。 127 | 128 | - もう◯◯歳なんだからそろそろ管理職にならないと 129 | - あいつはまだ若いからリーダーは早いな 130 | - もういい歳なのにまだこんな事やってるのか 131 | 132 | 見破る特徴として、やたらと人に年齢を聞いたりするのが特徴的です。 133 | 134 | このようなマネージャーは年功序列的な要素で評価を決める傾向にあるので、若く優秀な人間の離脱を招きやすいのも特徴です。 135 | 136 | このようなマネージャーには注意したほうが良いでしょう。 137 | 138 | 業務遂行において能力があるかないかが全てであり、その人が何歳であるかは全く関係がありません。 139 | 140 | そんな無能なマネージャーには下記のTweetを見せましょう。 141 | 142 |

agree to disagreeなんだけど「もう○歳なのだから、○○すべきだ」みたいなラベルは自分だけに貼ってほしいよね。
年齢が価値だと思う人もいれば、そうでない人もいる。
生きて重ねた月日を「いい歳」なんて言わないでほしいよね。

— あやにー / Ayaka Kato (@ayanie_jp) 2018年4月21日
143 | 144 |

「もう○歳なのに」とか「いい歳して」みたいな年齢フィルタリングをしていいのは自分自身に対してだけで、他人にするのはとても失礼で侮辱的な行為。

セクハラやパワハラなどいろんなハラスメントが話題になりますが全てにおいて「他人を自分軸で評価、批判する」が根本なんじゃないか、と。

— あやにー / Ayaka Kato (@ayanie_jp) 2018年4月21日
145 | 146 |

中学卒業したばかりの15歳の女の子でも、GitHubに公開されたソースコードがすごかったら、年収800万で即採用するIT企業なんてたくさんある。GitHub採用主義というトレンドは、学歴偏重も性差別も年功序列も全てを吹き飛ばす究極に風通しのいい社会を創り出すすごい社会的イノベーションだと思う。

— ふろむだ🍀執筆中 (@fromdusktildawn) 2018年3月8日
147 | 148 | ### 無能なマネージャーはウォーターフォール脳である 149 | 150 | ソフトウェア開発においてウォーターフォールはアンチパターンです。 151 | 152 | ソフトウェア開発は単純作業ではありません。 153 | 154 | 最初の計画通りに行く事などまずないでしょう。 155 | 156 | アジャイル方式で細かいイテレーションを繰り返す事で理想の成果物に近づけていくしかありません。 157 | 158 | またウォーターフォール脳は頭数が揃って時間をかければ良いソフトウェアが出来ると信じています。 159 | 160 | ウォーターフォール脳マネージャーは下記のような特徴があります。 161 | 162 | - ガントチャートを引けと言ってくる 163 | - 上流工程、下流工程という言葉が良く出てくる 164 | - 計画作成にやたらと時間をかける 165 | - 最初から大きな物を作ろうとする 166 | 167 | ウォーターフォール脳は「アジャイルでは計画が立てられない」と言いますが、アジャイルでも計画を立てる方法は存在します。 168 | 169 | むしろウォーターフォールよりも遥かにプロジェクトの成功確率が高いです。 170 | 171 | ### 無能なマネージャーは感情論で評価を行う 172 | 173 | あいつは印象が良いからプラス評価。 174 | 175 | あいつは面倒くさいからマイナス評価。などの自分の感情で評価を決めるタイプです。 176 | 177 | このようなマネージャーが権力を持つと、周りには腰巾着系の社畜が群がり、マネージャーをヨイショするだけの人間が集まる無能集団になります。 178 | 179 |

・感情に訴えかける、感情論を肯定する
・普通、当然、常識といった言葉を好む
・仲間意識や帰属意識に訴えかける
・他人からどう見られるかを善悪や規範の基準にする
・結果より過程、正確には言う通りにしたかで評価する

一つでも該当したら立派なモラハラだから耳を傾ける価値はない。

— 犯された宮殿 (@Raped_Palace) 2018年3月10日
180 | 181 | 飲みにケーション（笑）を重視しているマネージャーも感情論で評価する傾向が強いです。 182 | 183 | このような組織が変化の激しいこれからの時代を生き残る事が出来ないのは言うまでもないでしょう。 184 | 185 | （参考）[飲み二ケーションって考えうざすぎ。効果なんてないからな！](http://www.amamiyashion.com/entry/2016/05/19/183000) 186 | 187 | ### 無能なマネージャーは能力によって賃金に差をつけない 188 | 189 | 無能なマネージャーは優秀な人とそうでない人を同じような賃金で働かせようとします。 190 | 191 | エンジニアの仕事は単純作業とでも思っているのか、成果を上げている人とそうでない人で報酬の差がほとんどありません。 192 | 193 | このような状況が続くと優秀な人間から組織を離脱していき、組織全体のレベルを大きく低下させる事に繋がります。 194 | 195 | そのような無能なマネージャー、経営者には下記のTweetを見せましょう。 196 | 197 |

「怠けたらその分給料を下げられてしまうが、頑張ったら頑張った分ご褒美としてノルマを増やされるだけで給料は上がらない」
のが今の日本でその点ソ連より劣悪な社会なんだからそりゃイノベーションなんか生まれねえよ。
みんなできるだけギリギリまで頑張ってるように見せかける事に知恵を搾るよね。

— 貝澤 　カイザー (@Kaiser_ritsuko) 2018年4月9日
198 | 199 |

今の業界で初めて働いた会社にいためちゃくちゃ仕事の早いインド人の先輩が、「俺は10日かかる仕事が来たら4日で片付けて残りの6日間をゆっくり過ごしてきたんだが、日本でそれをやると5日目に新しく仕事が増やされるだけだと気がついてやめた」て言ってて日本社会の崩壊を感じた。

— ガチコ@🇺🇸 (@gatch_new) 2018年4月10日
200 | 201 |

さらに横にいた日本人の先輩（めちゃ優秀）が、「おう！日本で働くためにはな！早く終わらせるよりいかに適度にサボるかが大事だぞ！」て言ってて日本社会の闇を感じた。

— ガチコ@🇺🇸 (@gatch_new) 2018年4月10日
202 | 203 |

@kimutakura 次に「ダメエンジニアでも使いようで良いソフトが作れる」と素朴に信じているところがまずいでしょう。数で勝負できるのは単純作業だけです。ソフトウェア開発はそんなに単純じゃないでしょう。

— Yukihiro Matsumoto (@yukihiro_matz) 2010年9月15日
204 | 205 | 賃金を上げにくい理由は日本的な雇用システムの問題があります。 206 | 207 | 正社員雇用した、従業員を解雇する敷居が高く一度雇用すると例え仕事が出来なかったとしても解雇出来ない為、賃金UPが抑えられる傾向にあります。 208 | 209 | あえて極端な言い方をすると日本の雇用システムは極めて共産主義的な思想で出来ています。 210 | 211 | その為、このあたりの問題はマネージャーだけの問題ではないと考えます。 212 | 213 | このあたりの内容に関しては下記の記事がより詳しく解説をしていますので読むといいでしょう。 214 | 215 | （参考）[解雇規制緩和がこれからの時代に必要な理由](https://axia.co.jp/2018-03-26) 216 | （参考）[今後、やる気が無く、無能な人間ばかりが日本の企業で働くようになる理由](https://www.ino-kawa.com/?p=1045) 217 | 218 | マネージャーは良いエンジニアが得をする組織を作る努力をしなけらばなりません。 219 | 220 | 経営層を巻き込み良い環境を作る努力を出来ないのであればマネージャーをやるべきではありません。 221 | 222 | ### 無能なマネージャーは仕事と関係のない事を気にする 223 | 224 | 無能なマネージャーは仕事と関係ないどうでもいい事を評価対象にします。 225 | 226 | 例えば下記のような事です。 227 | 228 | - 朝ちゃんと来ているか（遅刻が多くないか） 229 | - 席を立つ回数が多い 230 | 231 | これらの行為の結果、その人が成果を出していないのであれば問題ですがそうでなければ問題ではありません。 232 | 233 | これらのような事を気にするという事は仕事の成果で評価出来ない事を意味します。 234 | 235 | >朝ちゃんと来ているか（遅刻が多くないか） 236 | >席を立つ回数が多い 237 | 238 | 遅刻に関しては会議などの特別な理由がなく、事前連絡があればそれで大きな問題とは思いません。（成果を出している前提） 239 | 240 | 席を立つ回数に関しても同様です。 241 | 242 | 人によって集中出来る時間は異なるので、いつ働こうが人の自由です。 243 | 244 | こういう考え方はリモートワーク導入の足枷にしかならないので本当に止めて欲しいです。 245 | 246 | これらの考え方の根底にあるのは、エンジニアを稼働時間でしか評価出来ていないという事です。 247 | 248 | `成果を評価出来ない = 何がその組織における成果なのかを定義出来ていない` という事になるので非常に問題です。 249 | 250 |

日本の働き方がいびつなのは出社時間には厳しいけど退社時間にはゆるいところ。働き方改革では退社時間を厳しくする方向になっているけど、エンジニアのようなアウトプットを重視する職種の場合、退社時間の厳格化ではなく出社時間の寛容化のほうがパフォーマンスは上がると思う。

— ひさじゅ@すたてく社長（PG） (@hisaju01) 2018年4月10日
251 | 252 |

働き方をもっと自由にしたかったら遅刻も含めた「勤務態度」というばかげた評価項目をなくせばいい。勤務態度のような項目はプロセスでしかなく、結果が出ない人のプロセス改善として使う程度にとどめ、評価項目を結果のみにすれば時間で縛る必要がなくなる。

— ひさじゅ@すたてく社長（PG） (@hisaju01) 2018年7月17日
253 | 254 |

社員を性悪説で管理しなくてはいけないような会社はマネジメント能力が足りてないか採用が間違ってるかのどっちかだな。営業の売り上げ目標も開発の納期もキツキツにしないで3年トラブルも退職者もないよ。

— INST石野@29日は大原イサキ (@ishiko618) 2018年2月27日
255 | 256 |

日経の働き方改革、イクメン応援の記事で違和感。19時消灯や勤務時間が15分短くなった話を賞賛してる。

そろそろ帰る時間をみんなで決めるの止めるのはどうだろうか。

保育園のお迎え担当の日は早く、働きたい時は働くなど、メリハリを個人が自由につければ良いのでは。多様な働き方を賞賛してほしい

— ふぃりっぷ@Findyの中の人 (@yuichiro826) 2018年7月16日
257 | 258 | ## マネジメントで生きるという選択肢について 259 | 260 | マネージャーになりたいという人はそれを目指すのも良いでしょう。 261 | 262 | 良いマネージャーがいればそれだけチームのパフォーマンスは向上しますし、そのようなマネージャーが増える事は大歓迎です。 263 | 264 | ただし、マネジメントの学習を行い安定した成果を出せるようになる事は普通のエンジニアよりも難しい事を自覚しましょう。 265 | 266 | - 人を動かす 267 | - 人を育てる 268 | - 人を適切に評価する 269 | 270 | これらを環境に関わらず発揮するのは非常に難しいです。 271 | 272 | エンジニア以上に自らのリソース（お金、時間を使った学習）を割く必要があります。 273 | 274 | ## 無能なマネージャーが多い理由 275 | 276 | 日本の奴隷量産教育が非常に悪い影響を与えていると考えられます。 277 | 278 | もう1つの理由としてエンジニアのマネージャーをやっている人で一定割合存在する「技術を諦めた人」です。 279 | 280 | 「技術が出来ないからマネジメントで勝負」という発想は非常にマズイ発想です。 281 | 282 | エンジニアの学習よりもマネジメントの学習のほうが遥かに難しいからです。 283 | 284 | 「技術を諦めた人」は端的に言うと技術の学習に時間を使いたくないと言う人です。 285 | 286 | このような心構えと日本のダメ教育が融合して無能なマネージャーが誕生するという訳です。 287 | 288 | 私の所感ですが、今まで出会ってきた無能なマネージャーはほぼこのパターンでした。 289 | 290 | マネージャーになりたいのであればマネジメントの学習を一生続けていくくらいの気持ちがないと到底良いマネージャーにはなれないでしょう。 291 | 292 | 権力を得たと思って自分が偉いと勘違いして偉そうに振る舞うだけなら誰でも出来ます。 293 | 294 | そういう人間は害虫以下なので、絶対マネージャーになってはいけません。 295 | 296 | そしてそのような人間は即刻排除されるべきです。 297 | 298 |

エンジニア35歳定年説とかで「マネジメントできないと生き残れない」とか言われてたが、改めてマネジメント眺めると「遅延叩くだけの進捗管理」「担当責任で問題対処」「残業休出でカバー」とかの猿マネジメントもどきばっかで、これでいいなら誰でも生き残れるんじゃね、と思ってしまうな。

— ケルビン＠斜壊人 (@legendkelbin) 2018年4月13日
299 | 300 | ## マネジメントの学習方法 301 | 302 | 私も現在マネージャー専門ではないので、自信を持ってこれと言い切る事は出来ないのですが、基本的に以下の事を学ぶと良いでしょう。 303 | 304 | - 歴史 305 | - 歴史を知る事で人間がどのような性質を持っているかその本質を捉える事が出来ます 306 | - 心理学 307 | - 心理学はマネジメントにおいて非常に重要なスキルです 308 | - マネジメントその物に関する書籍を読む 309 | - アジャイル開発に関する書籍を読む 310 | 311 | 私の所感ですが、いきなりマネジメントの本を読むよりも歴史・心理学あたりを勉強して人間の本質をある程度学習してからマネジメント本を読むとより理解が深まります。 312 | 313 | ### 歴史 314 | 315 | [逆説の日本史〈1〉古代黎明編](https://www.amazon.co.jp/dp/4094020012) を読んでみましょう。 316 | 317 | 日本人はよく「和を乱すな」という言葉、この言葉の意味は結構重要です。 318 | 319 | あと近代史あたり、幕末〜第2次世界大戦あたりの歴史を良く調べると、社畜思想がなぜ生まれたのかが大まかに理解出来ます。 320 | 321 | 社畜思想がもたらした重大な欠陥に関しては [失敗の本質](https://www.amazon.co.jp/dp/4478016879) という書籍が分かりやすいです。 322 | 323 | ### 心理学 324 | 325 | 心理学とは少し違いますが [人を動かす](https://www.amazon.co.jp/dp/4422100513) はオススメです。 326 | 327 | どうやったら人は自発的に動くのかが書かれています。 328 | 329 | 他にもオススメな本をいくつか記載しておきます。 330 | 331 | - [嫌われる勇気](https://www.amazon.co.jp/dp/4478025819) 332 | - [マンガでわかる! 心理学超入門](https://www.amazon.co.jp/dp/4791624343) 333 | - [伝え方が9割](https://www.amazon.co.jp/dp/447806864X) 334 | - [本当にわかる心理学](https://www.amazon.co.jp/dp/4534046839) 335 | 336 | ### マネジメント 337 | 338 | - [マネジメント基本と原則](https://www.amazon.co.jp/dp/4478410232) 339 | - [仕事の進め方が良くなる！アンチパターン10選](https://qiita.com/maiton/items/79a5c7480d85ca76593f) 340 | - [[翻訳] スクラムがアジア圏でうまくいかない4つの理由 - Scrum does not work here in Asia](https://qiita.com/wataradio/items/6b79130b8ea53aa698aa) 341 | - [管理をなくせばなくすほど生産性が高まる新しい組織の形「ホラクラシー」その背景とメリット](https://kuranuki.sonicgarden.jp/2015/08/holacracy.html) 342 | - [非エンジニアのマネージャがエンジニアチームと上手くやる方法](https://qiita.com/jonathanh/items/79056e13ac1f32a658ea) 343 | 344 | ### アジャイル開発 345 | 346 | - [SCRUM BOOT CAMP THE BOOK](https://www.amazon.co.jp/dp/4798129712) 347 | - [アジャイルな見積りと計画づくり](https://www.amazon.co.jp/dp/4839924023) 348 | - [アジャイルサムライ](https://www.amazon.co.jp/dp/4274068560) 349 | 350 | アジャイル開発に関しては別途専用のページを作成します。 351 | 352 | ### [Googleの良いマネージャーの定義](https://rework.withgoogle.com/jp/subjects/managers/) 353 | 354 | Googleが定義する良いマネージャーの行動規範が書かれています。 355 | 356 | ここから必要なスキルを逆算し学ぶ事が出来たら良いマネージャーになれるかもしれません。 357 | 358 | ## 最後に 359 | 360 | マネジメントに関して簡単にまとめてみました。 361 | 362 | 技術の学習と同じく基本はアンチパターンを避ける事だと考え、記事の内容もアンチパターンの紹介をメインとしました。 363 | 364 | 良いマネジメントを行い為には、学習した内容を地道に実践していくしかないでしょう。 365 | 366 | 一番大事なのはメンバーから信頼される事だと考えます。 367 | 368 | 一度信頼を失うとその後取り戻すのは並大抵の事では無理です。 369 | 370 | マネジメントは人間関係に大きく依存するのでそこが最も難しいところです。 371 | 372 | このカリキュラムでは良いエンジニアを目指す事を重視しているので、これ以上は語りません。（筆者に語る力がないという事情もあります） 373 | 374 | 完全に技術者志望の方も最低限ここに書いてある記事を読んでみて、無能なマネージャーから身を守りましょう。 375 | -------------------------------------------------------------------------------- /docs/server-side-programming/JavaScript/README.md: -------------------------------------------------------------------------------- 1 | # JavaScript 2 | 3 | JavaScriptの基礎を学びます。 4 | 5 | 最初はこのJavaScriptを使って、基礎的な構文やアルゴリズムのトレーニングをして行きましょう。 6 | 7 | ※ アルゴリズムというのは問題解決の手順の事でアルゴリズムの学習の際に詳しく解説します。 8 | 9 | ## JavaScriptの特徴 10 | 11 | プロトタイプベースのオブジェクト指向言語で主にWebブラウザで動作します。 12 | 13 | 昔は癖があり使いくいという印象を持たれる事も多かった言語ですが、最近はモダンな機能等も取り入れられているので、そのような印象は大分薄くなったのではないでしょうか。 14 | 15 | 詳しくは [wikipedia](https://ja.wikipedia.org/wiki/JavaScript) を参照してみて下さい。 16 | 17 | ## なぜJavaScriptを最初に学習するのか？ 18 | 19 | 私が最初に学ぶべき言語としてJavaScriptをオススメする理由は下記の通りです。 20 | 21 | ### 理由1フロントエンド（ブラウザ）でもサーバでも利用出来るから 22 | 23 | JavaScriptはブラウザでしか動かないというイメージは過去の物です。 24 | 25 | [Node.js](https://nodejs.org/ja/) の登場でサーバでも実行させる事が可能だという点が選定理由の1つ目です。 26 | 27 | ### 理由2多くのプロジェクトで使われているので学習した内容がながく使える可能性が高い 28 | 29 | [Node.js](https://nodejs.org/ja/) の恩恵はサーバ側でJavaScriptが実行出来るようになった事だけではありません。 30 | 31 | [npm](https://www.npmjs.com/) という強力なパッケージ管理システムの存在により、ブラウザでもサーバでも実行出来る様々なパッケージが利用出来ます。 32 | 33 | これらを利用する事で自分で1からプログラムを作るよりも開発速度を大幅に短縮出来ます。 34 | 35 | ※ 他の言語にもパッケージ管理システムはあります。Rubyの[RubyGems](https://rubygems.org/) やPHPの[composer](https://getcomposer.org/) 等ですね。 36 | 37 | このパッケージ管理システムとブラウザ、サーバ両方で動くという性質上、ほとんどのプロジェクトで [Node.js](https://nodejs.org/ja/) が利用されています。 38 | 39 | サーバサイドの言語に関してはNode.jsを使わずにRubyやPHPを利用しているケースも多いですが、Web開発だとフロントエンド（ブラウザ）では、事実上JavaScriptの一択です。 40 | 41 | 参加するプロジェクトによってサーバサイドの言語は様々な物（PHP, Ruby, Java等）がありましたが、JavaScriptが全く登場しないプロジェクトは1つもありませんでした。 42 | 43 | よって習得した事を活かせる可能性が高いという点がメリットになります。 44 | 45 | ### 理由3ブラウザで動かす事だけを考えるなら開発環境の用意が非常に簡単 46 | 47 | [Node.js](https://nodejs.org/ja/) を使わなくてもシンプルに動かすだけならWebブラウザとテキストエディタだけあれば開発を進められます。 48 | 49 | Webエンジニアを目指すのであれば開発環境構築のスキルは必須ではあるのですが、初心者はここで挫折してしまう可能性が結構高いので、この点は結構なメリットだったりします。 50 | 51 | ### 理由4言語仕様がモダン（現代的）になってきている 52 | 53 | JavaScriptは [ECMAScript](https://ja.wikipedia.org/wiki/ECMAScript) という標準仕様によって仕様が策定されています。 54 | 55 | このバージョン5.1までは、正直なところを言うと、他の言語と比較して独自仕様や罠が多く、考慮しなければいけない点が多く存在していました。 56 | 57 | しかし2015年に最新の言語仕様である、 ECMAScript 6(2015) が登場してから状況が大きく変わりました。 58 | 59 | オーソドックスなオブジェクト指向プログラミングと、関数型言語のエッセンスなどを備えたモダンな言語に生まれ変わりました。 60 | 61 | もしこの仕様がリリースされていなかったら私は最初に学ぶべき言語にJavaScriptをオススメしなかったと思います。 62 | 63 | ※ 補足ですが、ECMAScript 6以降はECMAScript 2015のような呼び方で呼ぶのが正しいそうです。 64 | 65 | ネット上ではECMAScript 6とかES7（2017の事）みたいな呼び方をしている場合もありますがECMAScript 20◯◯ が正しい呼び方です。 66 | 67 | ## 学習の進め方 68 | 69 | [ojt-node](https://github.com/keitakn/ojt-node) というリポジトリを作りました。 70 | 71 | こちらを利用して学習を進めて行きましょう。 72 | 73 | まずはREADMEの手順の通りに動かしてみて下さい。 74 | 75 | ※ 動作させるには [こちらの課題](https://github.com/keitakn/web-developer-ojt/blob/master/docs/linux/task.md) が終わっている必要があります。 76 | 77 | ## 学習の際に参考にするリンク 78 | 79 | 学習の際に参考になるリンクをいくつか紹介させて頂きます。 80 | 81 | ### [MDN JavaScript リファレンス](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference) 82 | 83 | mozillaの公式リファレンスです。 84 | 85 | ネット上に公開されている記事等はあくまでも2次情報なので、ここで正しい仕様等を確認しましょう。 86 | 87 | ### [JavaScript入門](https://dotinstall.com/lessons/basic_javascript_v2) 88 | 89 | 動画形式で基礎的な構文がある程度身につきます。 90 | 91 | 本格的な学習に入るまでに一度やっておくといいでしょう。 92 | 93 | ## JavaScriptの学習の注意点 94 | 95 | ネット上の記事は古い可能性があります。 96 | 97 | 特にJavaScriptはECMAScript 2015以降とそれ以前のバージョンで全く書き方が異なる部分があるので注意しましょう。 98 | 99 | ※ 今から習得するのであればECMAScript 2015以降の構文を覚えるのが良いでしょう。 100 | 101 | 見分け方の1つとして下記のように `var` を使って変数宣言を行っているケースは古い情報の可能性があります。 102 | 103 | ```javascript 1.8 104 | var myName = 'K'; 105 | ``` 106 | 107 | ECMAScript 2015以降では下記のように `const` を使っての変数宣言が一般的です。 108 | 109 | ```javascript 1.8 110 | const myName = 'K'; 111 | ``` 112 | 113 | 現代的なJavaScriptを書く上でいくつか参考になりそうな記事を載せておきます。 114 | 115 | ### [イマドキのJavaScriptの書き方2018](https://qiita.com/shibukawa/items/19ab5c381bbb2e09d0d9) 116 | 117 | 少々極端な主張ですが、記事の内容は概ね同意出来ます。（筆者の方があえてそうしているのだと思っています。） 118 | 119 | 一点気になったのは、`function` による宣言は完全に捨てて良いと書いてあるところです。 120 | 121 | 確かにこの記事の通り `const` とアロー関数のみでだいたいの場面は対応出来ますが、ジェネレータ等一部ではまだ `function` が必要だったりします。 122 | 123 | [関数宣言 vs 関数式 | ES2015+](https://qiita.com/raccy/items/aac3b8e3981564bbd1fa) でも関数宣言の方法は `const f = () => {};` を基本的に利用するのが良いと結論を出しています。 124 | 125 | ### [JavaScript 長く使える系の知識](https://qiita.com/yamadar/items/bfdfc58cec49bf2690e1) 126 | 127 | 基本を抑えておくという意味で一読しておくと良いと思います。 128 | 129 | この記事に書いてある言葉で非常に良いと思った内容を引用させて頂きます。 130 | 131 | >冒頭にも書きましたが、基礎知識は土台の様なものです。土台があれば、その上にあるものは自分で考えられます。新しい技術を目にしても、理解が容易になります。 132 | 133 | まさにその通りだと私も考えます。 134 | 135 | [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) でも基礎を重視した学習オススメしています。 136 | 137 | ### [JavaScript初級者のためのコーディングガイド](https://qiita.com/raccy/items/bf590d3c10c3f1a2846b) 138 | 139 | コメント欄でも白熱した議論がなされていますが、ここに書いてある事は概ね同意出来ると思いました。 140 | 141 | 一部の方が言われていますが、この記事には「何故そうするのか」という理由が記載されていません。（筆者の方があえてそうしている） 142 | 143 | 徐々にで良いので、1つ1つの項目に対して「何故そうするのか」を考えるようにしましょう。 144 | 145 | 疑問を持ち自ら考える事はエンジニアにとって非常に大切な事だと私は考えます。 146 | 147 | 例えば [「JavaScript初級者のためのコーディングガイド」に補足を試みる](https://qiita.com/ms2sato/items/94ed459640a1d89cb4de) を書いた方のように、自分なりの意見をアプトプット出来るようになると理想です。 148 | 149 | ### [【2018年版】今押さえておきたいフロントエンド関連](https://qiita.com/sawadays0118/items/88efc7c85caeb6d1bbd1) 150 | 151 | こちらはJavaScriptに特化しているというよりはフロントエンドのWeb全般での最新テクニックが載っています。 152 | 153 | 内容盛りだくさんなので、ストックしておいてざっと眺めておくと良いでしょう。 154 | 155 | ### [2018年に見直した現代的なJavaScriptの記法を紹介するぜ](https://ics.media/entry/17262) 156 | 157 | 最新の言語仕様を分かりやすく解説している良記事です。 158 | 159 | ### 非同期処理に関する記事 160 | 161 | JavaScriptでは非同期処理が非常に重要です。 162 | 163 | 非同期処理の核となる `Promise` の理解は必須です。 164 | 165 | 参考になりそうな記事を載せておきます。 166 | 167 | - [JavaScriptの同期、非同期、コールバック、プロミス辺りを整理してみる](https://qiita.com/YoshikiNakamura/items/732ded26c85a7f771a27) 168 | - [Promise と async/await の理解度をもう1段階上げる](https://qiita.com/SotaSuzuki/items/f23199e864cba47455ce) 169 | 170 | `async/await` は Promiseをより簡潔に書けるようにした仕組みです。 171 | まずは [async function](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function) を見て概要を理解しておきましょう。 172 | 173 | 下記の記事も分かりやすく解説されているのでオススメです。 174 | 175 | - [async await の使い方](https://qiita.com/niusounds/items/37c1f9b021b62194e077) 176 | - [async関数においてtry/catchではなくawait/catchパターンを活用する](https://qiita.com/akameco/items/cc73afcdb5ac5d0774bc) 177 | 178 | ## コーディング規約について 179 | 180 | 様々なコーディング規約がありますが、私のオススメは [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) です。 181 | 182 | オープンな議論を通じてスタイルが決定していること、スタイルについてパフォーマンスに関するエビデンスがあることがオススメの理由です。 183 | 184 | GitHub上でも多くのスターを獲得しています。 185 | 186 | 本カリキュラムではこのAirbnbのスタイルで学習を進めていきます。 187 | 188 | [日本語版](http://mitsuruog.github.io/javascript-style-guide/README.md) もあります。 189 | 190 | ちなみに [JavaScript初級者のためのコーディングガイド](https://qiita.com/raccy/items/bf590d3c10c3f1a2846b) でもAirbnbのスタイルを推しています。 191 | 192 | 最近では [Prettier](https://github.com/prettier/prettier) や [ESLint](https://eslint.org/) といったツールを利用しコードを整形するのが主流です。 193 | 194 | コーディング規約を理解する事は大事ですが、実際のコード整形はツールに任せてしまったほうがミスがないので確実です。 195 | 196 | - [Prettier 入門 ～ESLintとの違いを理解して併用する～](https://qiita.com/soarflat/items/06377f3b96964964a65d) 197 | -------------------------------------------------------------------------------- /docs/server-side-programming/JavaScript/task.md: -------------------------------------------------------------------------------- 1 | # 課題1パスワードジェネレータ機能の作成 2 | 3 | [ojt-node](https://github.com/keitakn/ojt-node) 上にパスワードジェネレータと呼ばれるランダムでパスワードを生成するWebフォームを追加して頂きたいです。 4 | 5 | ## アウトプット 6 | 7 | [ojt-node](https://github.com/keitakn/ojt-node) をcloneして自身のgithubに取り込み、プルリクエストのレビュワーにメンターを追加して下さい。 8 | 9 | ※ フォークすると私のRepositoryに対してプルリクエストを出す事になるので、あくまで自身のRepositoryに対してマージされるようになってしまうので面倒ですが、cloneしてから自身のgithub上に上げる事をオススメします。 10 | 11 | レビューのやり取りはpublicリポジトリだと全世界に公開されてしまいます。 12 | 13 | もし抵抗がある場合はprivateリポジトリを作る事をオススメします。（月7$かかりますが・・・） 14 | 15 | このあたりの手順は後でWikiにでもまとめます。 16 | 17 | ## 完了条件 18 | 19 | 以下の条件を満たして頂きたいです。 20 | 21 | - [JavaScriptでパスワードジェネレータを作ろう](https://dotinstall.com/lessons/pwd_generator_js_v3) と同等の仕様が実装されている事 22 | - `http://localhost:3000/password` で対象機能にアクセス出来るようにする事（localhostの部分は実際はVM環境のIPになると思います） 23 | - トップページに `/password` へのリンクが貼られている事 24 | - レビュワーのレビューを通過しており、masterブランチにマージが完了している事 25 | 26 | ## ポイント 27 | 28 | 基本的に [JavaScriptでパスワードジェネレータを作ろう](https://dotinstall.com/lessons/pwd_generator_js_v3) で紹介されているコードを参考にしても構いません。 29 | 30 | ただし、この動画は初心者向けに作られている事もあり、ES2015以降の新しい構文やscriptの外部ファイル化等が考慮されていません。 31 | 32 | このレベルの小さい機能であれば全てhtmlファイル内に書いても同じかもしれませんが、HTMLとJavaScriptは分離して書きましょう。（実戦では同じところに書くというケースのほうが圧倒的に少ないです） 33 | 34 | それから以下の2点も意識して頂きたいです。 35 | 36 | - ES2015以降の新しい書き方で書くように頑張ってみましょう。 37 | - 変数名や関数名を付ける時は分かりやすい名前を心がけましょう。 38 | 39 | 良い名前をつけるには以下の記事等が参考になります。 40 | 41 | - [よりよいネーミングを目指して](https://qiita.com/takasek/items/693c57dc9ddc6c1eb1ba) 42 | - [うまくメソッド名を付けるための参考情報](https://qiita.com/KeithYokoma/items/2193cf79ba76563e3db6) 43 | - [プログラミングでよく使う英単語のまとめ【随時更新】](https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923) 44 | 45 | ※ このあたりの方法はかなり重要なので別途Wikiあたりにまとめます。。。 46 | 47 | 逆にHTMLの見た目やデザイン等は手を多少手を抜いて良いです。（今回の課題の本質ではないので） 48 | 49 | [ojt-node](https://github.com/keitakn/ojt-node) のsampleのページではbootstrapというCSSフレームワークを使っています。 50 | 51 | [こちら](http://getbootstrap.com/docs/4.0/components/alerts/) がドキュメントになります。 52 | 53 | # 課題2バイナリサーチを行う関数の実装 54 | 55 | [ojt-node](https://github.com/keitakn/ojt-node) 上に [バイナリサーチ](https://ja.wikipedia.org/wiki/%E4%BA%8C%E5%88%86%E6%8E%A2%E7%B4%A2) を行う関数の実装をお願いします。 56 | 57 | - src/algorithm/search.js内に `binarySearch` を追加 58 | - src/tests/algorithm/search.test.js内に作った関数のテストコードを追加 59 | 60 | 上記の2点の対応が必要になります。 61 | 62 | ## アウトプット 63 | 64 | プルリクエストのレビュワーにメンターを追加して下さい。 65 | 66 | ## 完了条件 67 | 68 | - 数値の検索が出来る事 69 | - 関数のインプットとして検索対象の配列と検索対象の数値の2つを受取る事 70 | - 関数のアプトプットとしては、検索対象となる配列のindexとループ回数の2つを返す事 71 | - 検索対象の数値が見つからなかった場合はErrorを返す事 72 | - レビュワーのレビューを通過しており、masterブランチにマージが完了している事 73 | 74 | ## ポイント 75 | 76 | 今回は比較的簡単なアルゴリズムを実装しながら、テストコードの書き方とコマンドでのNode.jsの使い方を覚えてもらう事が目的です。 77 | 78 | 課題1と同じようにES2015以降の書き方や、良い名前を考える点を意識しましょう。 79 | 80 | # 課題3 Qiita APIを使ってユーザー検索フォームを作成する 81 | 82 | まずは完成品を見たほうが早いと思うので、[こちら](http://ec2-13-115-160-223.ap-northeast-1.compute.amazonaws.com:3000/qiita/users) をご覧下さい。 83 | 84 | 例えばQiitaの公式アカウントの https://qiita.com/qiita だったら "qiita" がユーザーIDになります。 85 | 86 | フォームからユーザーIDを受け取り、Qiita APIにそれを渡し、Qiitaのユーザー名とプロフィール画像を画面に出力します。 87 | 88 | ## アウトプット 89 | 90 | 完了の条件を満たしているプルリクエストを送り、メンターのレビューを通過する事。 91 | 92 | ※ [ojt-node](https://github.com/keitakn/ojt-node) 上に作成して下さい。 93 | 94 | ## 完了条件 95 | 96 | - URLは `/qiita/users` として下さい。（[こちら](http://ec2-13-115-160-223.ap-northeast-1.compute.amazonaws.com:3000/) のように「Qiitaユーザー検索」へのリンクも忘れずに追加しましょう） 97 | - htmlファイルを直接利用するのではなく [ejs](https://github.com/mde/ejs) のテンプレートエンジンを利用して下さい。 98 | - Qiita APIへの通信は [axios](https://github.com/axios/axios) というライブラリを利用して下さい。 99 | - フォームにはValidation処理を実装し、ユーザーIDのValidationを行う事（半角英数字と記号で1文字以上、30文字以内の文字列のみ許可する事） 100 | - 見つからない場合はエラーメッセージをフォームの下に表示して下さい。 101 | - Qiita APIに通信を行う処理とユーザーIDのValidationは `src/server/domain/Qiita.js` というファイルを作成しQiitaクラスを宣言しその中に実装して下さい。 102 | - Qiitaクラスにはテストコードを実装して下さい。 103 | - フォームの送信には [CSRF攻撃対策](https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/301.html) を実施して下さい。 104 | - 各ページには適切なHTTPステータスコードを設定するようにお願いします。（正常時は200, 結果が見つからない時は404, ValidationError時は422、それ以外の異常は500） 105 | 106 | ## ポイント 107 | 108 | 今までの課題とは違い難易度が格段に高いと思います。 109 | 110 | さらに作業量も多いので、プルリクエストを複数回に分けて進める事を推奨します。 111 | 112 | PRを段階的に送り、1ステップをクリアする毎に次のPRの作成に取り掛かります。 113 | 114 | 例えば以下のような形で進めると全部いっきにやるより、問題解決が楽になると思います。 115 | 116 | ※ こうするとレビューするメンターも楽だったりします。 117 | 118 | - 最初のPRはフォームを作成し、フォームからPOSTパラメータを送信しユーザーIDを受け取れるところまで。 119 | - 2回目のPRはQiita APIからデータを取得するテストコードを書くところまで。 120 | - 3回目のPRはQiitaユーザーIDのValidation処理を行うメソッドのテストコードを書くところまで。 121 | - 4回目のPRは作成したQiitaクラスを利用し、Webフォームから正常に検索出来るパターンのみを実装する。 122 | - 5回目のPRはQiita APIの結果がエラーの場合のエラーメッセージを表示させるところまで。 123 | - 6回目のPRはフォームに入力した値がValidationエラーだった場合にフォームのテキストボックスを赤く表示させる。 124 | - 7回目のPRはCSRF対策を行われた事を想定してセキュリティ対策を実装する。 125 | 126 | ## この課題で身につける事 127 | 128 | - セキュリティも考慮したWebフォームの実装方法 129 | - テンプレートエンジンの使い方 130 | - パッケージの追加インストール方法 131 | - JavaScriptをやる上で避けては通れない非同期プログラミングの実装方法 132 | - WebAPIの使い方 133 | - 実戦的なテストコードの書き方の練習 134 | - POST、GET等のHTTPメソッドの扱い方 135 | - HTTPステータスコードの扱い方 136 | - 複雑な問題を分割し、小さな課題に分離出来る能力（開発を進める上でかなり重要です） 137 | 138 | 一部、Node.js固有の知識もありますが、基本的にどの言語であっても必要な技術がこの課題を行う事で身につくかと思います。 139 | 140 | ## ヒント 141 | 142 | 今回の課題は今までと比較してかなり難しいので、ハマりそうなところを予め記載しておきます。 143 | 144 | ### テンプレートエンジンについて 145 | 146 | `src/views/qiita.ejs` というファイルを定義しましょう。 147 | 148 | ファイルの内容は下記のようになります。 149 | 150 | ```html 151 | 152 | 153 | 154 | 155 | 156 | OJT JavaScript Qiitaユーザー検索 157 | 163 | 164 | 165 |
166 |
167 |

Qiitaユーザー検索

168 | <% const hasDangerClass = isValidationError ? 'has-danger' : '' %> 169 | 170 |
171 |
172 | 173 | 181 | <% if (isValidationError === true) { %> 182 | 185 | <% } %> 186 |
187 | 188 |
189 | 190 | 191 | <% if (Object.keys(userResponse).length !== 0) { %> 192 |
193 | alt="QiitaUserImage"> 194 |
195 |

Qiitaユーザー名: <%= userResponse.name %>

196 |
197 |
198 | <% } %> 199 | 200 | 201 | 202 | <% if (Object.keys(errorResponse).length !== 0 && isValidationError === false) { %> 203 | 206 | <% } %> 207 | 208 |
209 |
210 | 211 | 212 | 213 | 214 | 215 | ``` 216 | 217 | 一見普通のHTMLのように見えますが、この中で変数を利用したり、別のテンプレートファイルを呼び出したりする事が出来ます。 218 | 219 | こうする事でHTMLを部品化し共通化する事が容易になります。 220 | 221 | 下記の記事が参考になりますので、載せておきます。 222 | 223 | https://qiita.com/y_hokkey/items/31f1daa6cecb5f4ea4c9 224 | 225 | 通常はプロジェクトルートに `views` というディレクトリを作成するのですが、今回は `/src/views` の下に作るので以下のような設定を `app.js` で行っておきます。 226 | 227 | ```javascript 228 | const express = require('express'); 229 | const ejs = require('ejs'); 230 | 231 | const app = express(); 232 | const port = 3000; 233 | 234 | app.set('views', __dirname + '/src/views'); 235 | app.engine('ejs', ejs.renderFile); 236 | 237 | // 利用する時はこんな感じで利用する（renderParamsには好きな値を定義出来る） 238 | const renderParams = { 239 | userId: '', 240 | }; 241 | 242 | res.status(200).render('qiita.ejs', renderParams); 243 | ``` 244 | 245 | ### Qiitaクラスを外部から利用可能にする 246 | 247 | 以下のように宣言します。 248 | 249 | ```javascript 250 | class Qiita { 251 | // この中に必要な処理を書く 252 | } 253 | 254 | module.exports = Qiita; 255 | ``` 256 | 257 | `module.exports = Qiita;` がポイントです、これを行う事で外部から利用出来る状態になります。 258 | 259 | 下記は `app.js` から呼び出す際の例です。 260 | 261 | ```javascript 262 | const Qiita = require('./src/server/domain/Qiita.js'); 263 | 264 | const qiita = new Qiita(); 265 | ``` 266 | 267 | ### フォームの値を受取るには 268 | 269 | サンプルで用意したHTMLはsubmitボタンが押された時に `/qiita/users` に対してPOSTリクエストが送信されます。 270 | 271 | つまり、POST（検索する処理）とGET（検索フォームを表示させる）で同じURLだけど行うべき処理が全く異なるという事です。 272 | 273 | まずはGET, POSTでそれぞれURLルーティングが出来るような設定を追加する必要があります。 274 | 275 | POSTデータを受取る為には、HTTPリクエストのBodyを解析する必要があります。 276 | 277 | `body-parser` というライブラリを調べてみましょう。 278 | 279 | ### Qiita APIについて 280 | 281 | [公式ドキュメント](https://qiita.com/api/v2/docs) を見るのが最も良いと思います。 282 | 283 | 今回の課題で利用するのは、`https://qiita.com/api/v2/users/{user_id}` のみで認証も不要です。 284 | 285 | よってアクセストークンが・・・みたいな記述はとりあえず読まなくても大丈夫です。 286 | 287 | ※ 本カリキュラムの後半ではこのあたりの事も学習します。 288 | 289 | Macのターミナルで `curl -v https://qiita.com/api/v2/users/qiita` と実行してみて下さい。 290 | 291 | JSON形式でレスポンスが返却されるかと思います。 292 | 293 | これをNode.jsのプログラム上から [axios](https://github.com/axios/axios) を使って呼び出し、結果を表示するという訳です。 294 | 295 | >認証している状態ではユーザごとに1時間に1000回まで、認証していない状態ではIPアドレスごとに1時間に60回までリクエストを受け付けます。 296 | 297 | とQiitaの公式に書いてあるので、もし予期しないエラーが返ってきたらこの件を疑ってみて下さい。 298 | 299 | ### 非同期処理について 300 | 301 | Qiita APIを使う時に非同期プログラミングについての知識が必要になります。 302 | 303 | [axios](https://github.com/axios/axios) はPromiseと呼ばれる非同期処理を行う為のオブジェクトを返してきます。 304 | 305 | かなり長いですが [JavaScript Promiseの本](http://azu.github.io/promises-book/) に詳しく仕様が書いてあります。 306 | 307 | [MDN](https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Using_promises) も確認しておいたほうが良いでしょう。 308 | 309 | 参考になりそうなQiitaの記事を何個か載せておきます。 310 | 311 | - [JavaScriptのPromise](https://qiita.com/ysk_1031/items/888a84cb259cec4e0625) 312 | - [JavaScriptの同期、非同期、コールバック、プロミス辺りを整理してみる](https://qiita.com/YoshikiNakamura/items/732ded26c85a7f771a27) 313 | 314 | また `async` `await` というのはPromiseをより便利にした書き方で非同期処理の書き方がシンプルになります。 315 | 316 | 下記の記事が参考になります。 317 | 318 | - [async/await 入門（JavaScript）](https://qiita.com/soarflat/items/1a9613e023200bbebcb3) 319 | 320 | 内部で利用されているのは結局PromiseなのでPromiseの基本的な動きを理解する事が大事です。 321 | 322 | このあたりは最初はかなり難しく感じるかと思いますが、JavaScript開発をやる上で非同期プログラミングは避けては通れないので、この課題を通じて理解するようにしましょう。 323 | 324 | # 課題4 Qiita APIを使って記事の一覧ページを作成する 325 | 326 | これがJavaScript基礎の最終課題になります。 327 | 328 | まずは [完成品](http://ec2-13-115-160-223.ap-northeast-1.compute.amazonaws.com:3000/qiita/items) を見てみましょう。 329 | 330 | こんな感じでQiitaの記事の一覧を取得し、表示させます。 331 | 332 | 初期状態で表示させるのは5件で「次の5件を表示する」をクリックされたら、次の5件を表示して下さい。 333 | 334 | Qiita APIとの通信中はプログレスバーを表示させて下さい。 335 | 336 | HTMLは [完成品](http://ec2-13-115-160-223.ap-northeast-1.compute.amazonaws.com:3000/qiita/items) を参考にして頂ければ問題ありません。 337 | 338 | また [トップページ](http://ec2-13-115-160-223.ap-northeast-1.compute.amazonaws.com:3000/) へのリンクの追加も忘れずにお願いします。（Qiita投稿一覧） 339 | 340 | ## 最初に `/qiita/items` に遷移した時の挙動 341 | 342 | この課題はサーバ側の実装とクライアント側（ブラウザで動くJavaScript）の両方を実装する必要があります。 343 | 344 | 最初に `/qiita/items` にページ遷移した際は課題3で作ったQiitaクラスを使って、Qiitaから最新記事の一覧を取得します。 345 | 346 | この時に利用するAPIは `https://qiita.com/api/v2/items` です。 347 | 348 | QiitaクラスにこのAPIを使って、記事の一覧を取得するメソッドを実装しましょう。 349 | 350 | このAPIの結果を画面に表示させます。 351 | 352 | `src/views/qiita_items.ejs` というファイルを新規で作成しこのテンプレートに結果を渡して表示して下さい。 353 | 354 | なお、記事の取得に失敗した場合（APIの結果が200以外だったら）以下のようにエラー画面を表示させます。 355 | 356 | ![qiita-items-sync-error](https://user-images.githubusercontent.com/11032365/34081525-2a1adc58-e391-11e7-9665-c36308e92c7e.png) 357 | 358 | エラーの表示用に `src/views/qiita_error.ejs` というエラー用のテンプレートファイルを別途用意して下さい。 359 | 360 | ここまでの実装はサーバ側のプログラムだけで実現出来るハズです。 361 | 362 | ## ブラウザから次の5件を取得するリクエストが来た時の挙動 363 | 364 | ここからが結構複雑なので、以下のシーケンス図を用いて説明します。 365 | 366 | ![javascript-task4](https://user-images.githubusercontent.com/11032365/34081565-bc3cba2a-e391-11e7-8f3c-8adfbadf290a.jpg) 367 | 368 | ### 1. POST /api/qiita/itemsへリクエストを送信する 369 | 370 | ブラウザからサーバ側に対してリクエストを送信します。 371 | 372 | このリクエストを送信する処理は `/public/js/qiita.js` というファイルを新規で作成しそこで行いましょう。 373 | 374 | 要求する際にページパラメータを渡してあげる必要があります。 375 | 376 | リクエストBodyに `page` を含めて下さい。 377 | 378 | ここで `page` に渡す値は初期値が1なので、最初は2、2回目にButtonがクリックされた際は3と1づつ増えていきます。 379 | 380 | 直接Qiita APIにリクエストを行うのではなく、Node.jsのサーバを通じて行うのがポイントです。 381 | 382 | `/api/qiita/items` というルーティングを定義しましょう。受け付けるリクエストメソッドはPOSTです。 383 | 384 | 何故直接、Qiita APIに通信するのが駄目なのか？という理由ですが、このあたりはセキュリティの学習の際に説明します。 385 | 386 | ともかくこうする事で、Qiitaクラスに作成した記事の一覧を取得するメソッドを使いまわす事が出来るハズです。 387 | 388 | ### Qiita APIから次のページの記事一覧を取得 389 | 390 | シーケンス図で言うところの2, 3の実装です。 391 | 392 | `/api/qiita/items` でQiitaクラスを使って記事の一覧を取得しましょう。 393 | 394 | 結果をJSON形式で返却しましょう。 395 | 396 | 下記のようなJSONデータが返すように実装出来ればOKです。 397 | 398 | ```json 399 | { 400 | "items": [ 401 | { "id": "545da3485f05598461b9", "title": "記事1", "url": "https://qiita.com/t-mochizuki/items/562a758e5e23f25f7899"}, 402 | { "id": "545da3485f05598461b1", "title": "記事2", "url": "https://qiita.com/t-mochizuki/items/545da3485f05598461b1"}, 403 | { "id": "545da3485f05598461b2", "title": "記事3", "url": "https://qiita.com/t-mochizuki/items/545da3485f05598461b2"}, 404 | { "id": "545da3485f05598461b3", "title": "記事4", "url": "https://qiita.com/t-mochizuki/items/545da3485f05598461b3"}, 405 | { "id": "545da3485f05598461b4", "title": "記事5", "url": "https://qiita.com/t-mochizuki/items/545da3485f05598461b4"} 406 | ] 407 | } 408 | ``` 409 | 410 | `page` パラメータにはバリデーションが必要です。 411 | 412 | 課題3の時と同じくQiitaクラスにバリデーションを用意しましょう。 413 | 414 | バリデーションエラーになった場合は以下のようにエラーを示すJSON形式のデータを返しましょう。 415 | 416 | ```json 417 | { "code": 422, "message": "Unprocessable Entity" } 418 | ``` 419 | 420 | `page` は1から100の整数型を受け付けるようにしましょう。 421 | 422 | 文字列の "1" 等は受け付けても良いですが、 "abc" のような文字列や -1等の範囲外の数値は受け付けないようにしましょう。 423 | 424 | ### Qiita APIからの結果を元にJSONを解析してHTMLを生成する 425 | 426 | シーケンス図で言うところの4, 5の実装です。 427 | 428 | `/public/js/qiita.js` で `/api/qiita/items` からの通信結果を受け取り、HTMLを組み立てます。 429 | 430 | [insertAdjacentHTML](https://developer.mozilla.org/ja/docs/Web/API/Element/insertAdjacentHTML) という機能を利用します。 431 | 432 | 似たような機能に `innerHTML` がありますが、こちらよりもinsertAdjacentHTMLが高速に動作するのでこちらを利用します。 433 | 434 | なお通信結果がエラーだった場合は以下のようにエラーメッセージを表示させましょう。 435 | 436 | ![qiita-async-error](https://user-images.githubusercontent.com/11032365/34082328-3af58f38-e39f-11e7-9146-6b962409f195.png) 437 | 438 | ## 課題4で作成するファイルまとめ 439 | 440 | 新規で作成するファイルは以下の通りです。 441 | 442 | - `public/js/qiita.js`（クライアント側のメインロジック） 443 | - `src/views/qiita_items.ejs`（記事を表示させる為のテンプレート） 444 | - `src/views/qiita_error.ejs`（記事取得でエラーが発生した際に利用するテンプレート） 445 | 446 | 他にもQiitaクラスが実装されている `src/server/domain/Qiita.js` やそれに対応するテストコード `src/tests/server/domain/Qiita.test.js` や `app.js` の修正対象になるかと思います。 447 | 448 | ## 注意点 449 | 450 | 以下のような点に注意して実装を行って下さい。 451 | 452 | - 課題3と同じくQiitaクラスのメソッドには単体テストを用意しましょう。 453 | 454 | - 「次の5件を表示する」を連続で押されると、Qiita APIにリクエストが連続で行われてしまいます。 455 | よって通信終了まではButtonを非表示にする等の対策を実施しましょう。 456 | 457 | - `/public/js/qiita.js`（ブラウザ）から `/api/qiita/items`（サーバ）に通信する際は [Fetch](https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch) を利用しましょう。 458 | まだ実装されていないブラウザもありますが今後こちらのAPIがブラウザからHTTP通信を行う為の標準APIになりますので使い方を覚えておきましょう。 459 | 460 | - クライアントからサーバに通信する際にもCSRF対策が必要です。課題3と同じく実装を行いましょう。 461 | 462 | ## この課題で身につける事 463 | 464 | - 高機能なUIを作成する為に必要不可欠なサーバ通信を行うJavaScriptアプリケーションの開発の基礎 465 | - ブラウザからHTTP通信を行う基礎的な技術 466 | 467 | 近年では [SPA(Single Page Application)](https://qiita.com/takanorip/items/82f0c70ebc81e9246c7a) と呼ばれる手法で開発を行う事が多くなってきました。 468 | 469 | この課題の設計・実装方法は少々古いやり方ではありますが、モダンなSPAを開発する為にはこの基礎が重要となります。 470 | 471 | 完成後、課題3で作成したアプリケーションの性質と何が違うかを見比べてみましょう。 472 | 473 | ## ヒント 474 | 475 | この課題は課題3よりさらに難易度が高い為、つまりそうな箇所を予め記載しておきます。 476 | 477 | ### Qiita APIの利用制限について 478 | 479 | 本課題は課題3以上にQiita APIの利用制限に引っかかる可能性が高いです。（下記ドキュメントの利用制限を参照） 480 | 481 | https://qiita.com/api/v2/docs 482 | 483 | もし利用制限に引っかかった場合は以下の3つが解決策となります。 484 | 485 | - 1時間経過するのを待つ（実際はそれより早く利用可能になる） 486 | - 接続元のIPアドレスを変更する（Proxyサーバを用意すれば可能） 487 | - アクセストークンによる認証認可を行う 488 | 489 | オススメは [アクセストークンによる認証認可を行う](https://qiita.com/api/v2/docs#%E8%AA%8D%E8%A8%BC%E8%AA%8D%E5%8F%AF) です。 490 | 491 | ユーザーの管理画面からトークンを発行出来るので一時的にこのトークンをプログラムに埋め込む事で認証付きのリクエストを行うことが可能になり、利用制限に引っかかる事はまずなくなります。 492 | 493 | ただしアクセストークンは外に漏れると、自信のQiitaアカウントが悪用されてしまうリスクがあるので、GitRepositoryには登録しないように注意しましょう。 494 | 495 | ※ 特にpublicなRepositoryで作業している場合、アクセストークンをGitRepositoryに登録する行為は絶対に避けるべきです。 496 | 497 | ### Ajaxについて 498 | 499 | クライアント側からサーバ側に通信を行い、通信結果を元にJavaScriptでHTMLを組み立てるような手法を [Ajax](https://ja.wikipedia.org/wiki/Ajax) と呼びます。 500 | 501 | HTML全体を書き換えるのではなく、必要な部分だけを書き換えるので、ページ全体を書き換えるより時間を短縮出来るのと、通信中もユーザー操作が可能な点がメリットです。 502 | 503 | Ajaxでググると、おそらく [jQuery.ajax](http://api.jquery.com/jquery.ajax/) が引っかかる事が多いと思います。 504 | 505 | jQueryは昔流行ったJavaScriptのライブラリで一時期はこれなしでは、Web開発は出来ないとまで言われた程でしたが、今では標準のJavaScriptが十分に高機能になったので、このライブラリを利用しない流れになっています。 506 | 507 | AjaxでCSRF対策を行う際に `csurf` を利用している場合は `X-CSRF-Token` というHTTPHeaderを送信する必要があります。 508 | 509 | `curl` で言うと下記のように送信する必要があります。 510 | 511 | ```bash 512 | curl -v http://localhost:3000/api/qiita/items \ 513 | -X POST \ 514 | -H "Content-Type: application/json" \ 515 | -H "X-CSRF-Token: 0s4oYoa0-85zSh6fJUr3Qkv8-WQ9ljc56ilo" \ 516 | -d '{"page": "1"}' 517 | ``` 518 | 519 | このあたりを理解する為にはHTTPの基礎的な知識が必須となります。 520 | 521 | 本カリキュラムの [HTTP](https://github.com/keitakn/web-developer-ojt/blob/docs/master/http/README.md) 等を読み、HTTP通信の基礎を理解しておきましょう。 522 | 523 | また `csurf` を利用している場合は `csurf` のドキュメントにも目を通しておきましょう。 524 | 525 | ### 見本で読み込まれているJavaScriptファイルについて 526 | 527 | [完成品](http://ec2-13-115-160-223.ap-northeast-1.compute.amazonaws.com:3000/qiita/items) のJavaScriptをGoogleDeveloperTool等で見てみると、非常に読みにくいJavaScriptFileが読み込まれているかと思います。 528 | 529 | このJavaScriptファイルは難読化の処理が施してある為です。 530 | 531 | 課題を行う皆さんはこのような難読化の処理を行う必要はありませんので、普通に `/public/js/qiita.js` を開発して頂いて問題はありません。 532 | 533 | ### 大きな課題を分離する能力の重要性 534 | 535 | 課題3と同じく、プルリクエスト（PR）は複数回に分けて送信しましょう。 536 | 537 | 今回はこちらからPRの分離方法を指定しませんので、課題をやる皆さんがPRをどのような単位で分けるかを考えてみましょう。 538 | 539 | 課題を分ける際には以下のような事を意識すると良いです。 540 | 541 | - まず正常に動く状態を一刻も早く作る事、色々な条件はありますが、バリデーションエラーやCSRFエラー等のエラー発生時の挙動は後回しにする事で問題が単純化出来ます。 542 | - 正常に動くという状態も色々あります、例えばこの課題であれば、最初の段階（初期表示の5件が表示されている段階）で次の5件を表示するButtonが存在しなかったとしても、最初に5件表示されているという機能は満たしていますので、これでも十分PRを出す事が出来ます。 543 | - 単独でテストが出来る物は分離しやすいので、ユニットテストが可能な範囲は分離しやすいです。 544 | 545 | 上記の点から言えるのは、一度に全ての機能をマージする必要はないという事です。 546 | PRを細かい単位に分割し、細かい単位でレビューを受ける事は大幅な手戻りを軽減し、品質を向上させます。 547 | 548 | これは [アジャイル開発](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA) の基本的な考え方でもあります。 549 | 550 | 「複雑な課題をいくつかの単純な課題に分離する能力」は開発者にとって非常に重要なスキルです。 551 | 552 | 身につけようと思っても一朝一夕で身につく物ではありません。 553 | 554 | よって普段から意識しておく事が大事です。 555 | 556 | [アジャイルな見積りと計画づくり](https://www.amazon.co.jp/dp/B00IR1HYGW/ref=dp_kinw_strp_1) の「ユーザーストーリーの分割」がもっとも参考になりました。 557 | 558 | 下記のスライドも参考になるでしょう。 559 | 560 | https://www.slideshare.net/aratafuji/ss-38057768 561 | 562 | 課題の分離方法に悩む場合はメンターに相談しましょう。 563 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/README.md: -------------------------------------------------------------------------------- 1 | # PHP 2 | 3 | サーバサイド言語PHPの基礎を学びます。 4 | 5 | ある程度JavaScriptの基礎をやったら次はこちらに挑戦してみましょう。 6 | 7 | ## PHPの特徴 8 | 9 | Webサービスを開発する為の言語でWebサーバで動作します。 10 | 11 | Webの機能に特化している分、Webサービスを作る事は得意ですが、それ以外はあまり向いている言語ではありません。 12 | 13 | Javaに似たオブジェクト指向の書き方も出来るし、HTMLに簡単に埋め込んで使う事も出来ます。 14 | 15 | 詳しくは [wikipedia](https://ja.wikipedia.org/wiki/PHP_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E)) を見て下さい。 16 | 17 | ## PHPを学習する理由 18 | 19 | ### 初心者にも扱いやすい 20 | 21 | 構文がJavaやC言語に似ていて分かりやすく、比較的癖が少ないです。 22 | 23 | またコンパイルが不要なインタープリタ型言語なので環境構築も比較的容易です。 24 | 25 | ### 市場でも多く使われている 26 | 27 | あくまで日本での話ですが、Javaに続き2番目に使われています。 28 | 29 | ちゃんと統計は取ってないですが、Web系の企業に限定すれば一番多く使われているのではないでしょうか？ 30 | 31 | どちらにせよ、多く使われている事は間違いないと思います。 32 | 33 | [2017年に最もシェアを伸ばしたサーバサイドプログラミング言語は?](https://news.mynavi.jp/article/20180109-567522/) という記事によるとPHPが2017年最もシェアを伸ばしたようですね。 34 | 35 | ### 最近のバージョンには堅牢な設計に必要な機能が揃ってきた 36 | 37 | [型定義](https://qiita.com/bokotomo/items/1ead446ef689dc45b487) やクロージャー、使いやすいパッケージ管理システム等、開発に必要な物が一通りあります。 38 | 39 | 最初、サーバーサイドで最初に学ぶべき言語を何にするかめちゃくちゃ悩みました。 40 | 41 | 最終的にRubyかPHPか？で悩んでいたのですが、最近のPHPは型定義のサポートが充実してきたので、この点が決め手になりました。 42 | 43 | これは個人の主観ですが、オブジェクト指向を学ぶ際には型定義がある程度厳密に出来たり、interfaceや抽象クラス等を言語レベルでサポートしていたほうが進めやすいと思ったのも理由の1つです。 44 | 45 | この感覚は別の静的型付け言語（Java, Scala, Go等）を学ぶ際にも経験を活かせるという点が良いと思います。 46 | 47 | ※ [オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方](https://www.amazon.co.jp/dp/B01L8SEVYI) を見てRubyの設計も良いなとは思ったのですが、Ruby独自のテクニック等も結構多いので、汎用性を重視しました。 48 | 49 | ちなみにオブジェクト指向の良い情報はJavaの書籍も多いです、だったら最初はJavaで！と思うかもしれませんが、初心者が最初にJavaをやるとかなり難しいと私は思います。 50 | 51 | Javaは言語自体がマルチスレッドをサポートしていますが、これが非常に難しく、性能を引き出す為にはかなりの技術を必要とします。 52 | 53 | Javaを学ぶ事自体はもちろん有効なのですが、最初はPHPのような簡単な言語から始めたほうが挫折する確率は低いと思います。 54 | 55 | ### 扱いやすいフレームワークが登場してきた 56 | 57 | おそらく一番有名なWebアプリケーションフレームワークが [Ruby on Rails](http://guides.rubyonrails.org/) ですが、PHPにも [Laravel](https://laravel.com/) という非常に高機能なフレームワークがあります。 58 | 59 | 少し学習コストが必要ですが使いこなせば、開発効率を大きく高める事が出来ます。 60 | 61 | ※ このフレームワークを使った開発は後のlessonで行う予定です。 62 | 63 | ## 学習の進め方 64 | 65 | [ojt-php](https://github.com/keitakn/ojt-php) という学習用のリポジトリを作りました。 66 | 67 | こちらを利用して学習を進めて行きましょう。 68 | 69 | ※ 学習内容と課題は決まり次第記載します。 70 | 71 | ## 学習の際に参考にするリンク 72 | 73 | ### [PHP マニュアル](http://php.net/manual/ja/index.php) 74 | 75 | 公式です。 76 | 77 | かなり詳しいので基本的な構文やメソッド等はここを調べれば、だいたい分かります。 78 | 79 | ### [PHP: The Right Way](http://ja.phptherightway.com/) 80 | 81 | PHPは利用者が多いので、かなり古い情報がネット上に溢れかえっている状況です。 82 | 83 | ここを見ればモダンなPHPの開発手法や現時点でのベストプラクティスが分かるでしょう。 84 | 85 | ## コーディング規約について 86 | 87 | PHPには標準で定められたコーディング規約が存在します。 88 | 89 | `PSR-◯◯` という名前が付いています。 90 | 91 | なのでこの標準のコーディング規約に準拠して行きましょう。 92 | 93 | PSRはいくつかの章に分かれていて、これら全てを合わせて1つのコーディング規約となります。 94 | 95 | ### [PSR-1](http://www.infiniteloop.co.jp/docs/psr/psr-1-basic-coding-standard.html) 96 | 97 | 基本的なコーディング規約です。 98 | 99 | ### [PSR-2](http://www.infiniteloop.co.jp/docs/psr/psr-2-coding-style-guide.html) 100 | 101 | こちらもコーディング規約です。なおこの内容は [PSR-1](http://www.infiniteloop.co.jp/docs/psr/psr-1-basic-coding-standard.html) に準拠しているという前提で書かれています。 102 | 103 | よって [PSR-1](http://www.infiniteloop.co.jp/docs/psr/psr-1-basic-coding-standard.html) の内容を理解している事が必要です。 104 | 105 | ## その他のPSR規約 106 | 107 | ここからはコーディング規約からは少し離れますが、PHPで開発する上で必要なルールが記載されています。 108 | 109 | ### [PSR-3](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md) 110 | 111 | アプリケーションログ等のログに関するルールを定めた物です。 112 | 113 | ログを出力する際はこの規約に準拠しているライブラリを利用する事で自然と準拠する事が出来ます。 114 | 115 | ### [PSR-0](http://www.infiniteloop.co.jp/docs/psr/psr-0.html) 116 | 117 | オートローダー（プログラム内で利用されているファイルを自動で読み込んでくれる仕組み）を扱う為に必要な規約です。 118 | 119 | ### [PSR-4](https://qiita.com/rana_kualu/items/f41d8f657df7709bda0f) 120 | 121 | こちらも同じくオートローダーのルールです。 122 | 123 | [PSR-0](http://www.infiniteloop.co.jp/docs/psr/psr-0.html) の上位版で、基本的にこちらのルールに従っておけば良いでしょう。 124 | 125 | ### [PSR-7](http://www.php-fig.org/psr/psr-7/) 126 | 127 | HTTPレスポンス・リクエストに関するルールを定めた物です。 128 | 129 | 他にも色々なルールがあります。 ※ [PHP PSR一覧 2017年版](https://qiita.com/rana_kualu/items/f41d8f657df7709bda0f) という記事がありましたのでここに載せておきます。 130 | 131 | 全部読むと大変なので初めは下記の4つくらいを読んでおきましょう。（流し読みレベルで全然構いません） 132 | 133 | - [PSR-1](http://www.infiniteloop.co.jp/docs/psr/psr-1-basic-coding-standard.html) 134 | - [PSR-2](http://www.infiniteloop.co.jp/docs/psr/psr-2-coding-style-guide.html) 135 | - [PSR-4](https://qiita.com/rana_kualu/items/f41d8f657df7709bda0f) 136 | - [PSR-7](https://qiita.com/asaokamei/items/b86e384867bcf0379cea) 137 | 138 | このようにたくさんの標準規約がありますが、コーディング規約はJavaScriptと同じようにツールで自動修正出来る物はあるので、そちらを利用していきましょう。 139 | 140 | またその他のルールに関してもPSRに準拠しているライブラリを選ぶ事で自然と準拠するようになりましょう。 141 | 142 | ## PHP学習の落とし穴 143 | 144 | これはどの言語にも言える事ですが、PHPには他の言語と較べて、結構不思議な仕様があります。 145 | 146 | 少々過激なタイトルですが [PHPができても他言語の学習には役に立たない理由を考えてみた。](https://qiita.com/raccy/items/335b819626974f0a14cd) という記事があるので、これを一読して見ると良いでしょう。 147 | 148 | ちなみにこの記事を読めば分かりますがタイトルで言っている事は少々大げさです。（この記事の筆者自身もコメント欄で同様の事を言っています） 149 | 150 | ## ネット上でのPHPに関する批判について思う事 151 | 152 | ネット上ではPHPに関する批判的な記事がかなり多くあります。 153 | 154 | 裏を返せばそれだけ多くの場所で利用されているという事です。 155 | 156 | どんな言語でもそうですが使いこなすには基礎的なコーディング力が大事になります。 157 | 158 | 基礎的な事をしっかりと抑えてあればPHPであろうと何であろうと、それなりに堅牢なコードを書けますし、逆に基礎が出来ていない人がScala等の高機能な言語をやっても良いシステムは作れません。 159 | 160 | プログラミング言語というのはエンジニアの問題解決を助ける為の道具なので、特定の言語を強く批判したり、逆に特定の言語に強く肩入れするような行為は避けるべきだと私は考えます。 161 | 162 | PHPにはPHPの得意な事がありそういう場面では使えばいいし逆に向いていない場面では使わなければ良いだけの話です。 163 | 164 | ※ 本カリキュラムのPHP編では基礎的なコーディング力や設計スキルが身につくような内容を作る事を強く意識して作成します。 165 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/task1.md: -------------------------------------------------------------------------------- 1 | # 課題1（PHPの実行環境を作成する） 2 | 3 | ## アウトプット 4 | 5 | [ojt-linux-vagrant](https://github.com/keitakn/ojt-linux-vagrant) 上にPHPの実行環境を作成して下さい。 6 | 7 | また作成の手順をQiitaの記事として公開して下さい。（最初は限定共有公開でメンターレビュー後に全公開でOK） 8 | 9 | ## 完了条件 10 | 11 | 以下の条件を満たしていた時に課題は完了となります。 12 | 13 | - [ojt-php](https://github.com/keitakn/ojt-php) のクイックスタートを参考に `http://192.168.33.100:8080` へアクセスして正常にHTML形式のレスポンスが確認出来る事 14 | - `/etc/php.ini` にタイムゾーンの設定と日本語を扱う為の設定が行われている事 15 | - `/etc/php.ini` でエラーログが出力されるように設定されている事 16 | - 作成したQiitaの記事の手順を踏む事で環境構築を再現出来る事 17 | 18 | Node.jsの時と同じく [ojt-php](https://github.com/keitakn/ojt-php) は [ojt-linux-vagrant](https://github.com/keitakn/ojt-linux-vagrant) の共有ディレクトリに設定されています。 19 | 20 | もしもvagrant上で [ojt-php](https://github.com/keitakn/ojt-php) を確認出来ない時は最新のリポジトリを取り込んで下さい。 21 | 22 | ## ヒント 23 | 24 | ### インストール方法 25 | 26 | [公式ドキュメント](http://php.net/manual/ja/install.php) を見るとインストール方法にも様々な方法があります。 27 | 28 | 一番簡単な `yum` によるインストールを行いましょう。 29 | 30 | ただしPHP7.2のような新しいパッケージはyumリポジトリの追加を行う必要があります。 31 | 32 | 必要なリポジトリは `epel` と `remi` の2つです。 33 | 34 | それぞれ下記のような手順でインストールが可能です。 35 | 36 | ``` 37 | yum install epel-release 38 | yum install http://rpms.famillecollet.com/enterprise/remi-release-6.rpm 39 | ``` 40 | 41 | PHPはいつくかのパッケージに依存しています。 42 | 43 | AmazonLinuxの場合、以下のパッケージが入っていないので、インストールを行っておきましょう。 44 | 45 | ``` 46 | yum install httpd libmcrypt libtool-ltdl zlib-devel autoconf automake libevent libevent-devel 47 | ``` 48 | 49 | おそらくそのままインストールすると、`yum` のエラーが発生します。 50 | 51 | これは元々存在するAmazonLinuxのyumリポジトリと先ほど入れた `remi` リポジトリの間でパッケージの衝突が起こっているからです。 52 | 53 | インストールを完了させるには、`remi` , `remi-php72` のリポジトリを有効にして、`amzn-main` というリポジトリを無効化します。 54 | 55 | `yum` のコマンドに引数を渡す事でリポジトリの有効・無効化が出来ます。 56 | 57 | `--enablerepo` , `--disablerepo` というオプションを調査してみましょう。 58 | 59 | またその後のレッスンで必要になるので、最低限以下のパッケージを入れておきましょう。 60 | 61 | - php 62 | - php-devel 63 | - php-opcache 64 | - php-mbstring 65 | - php-pdo 66 | - php-mysqlnd 67 | - php-pecl-xdebug 68 | - php-fpm 69 | - php-xml 70 | 71 | `php -v` と実行した結果が以下のようになれば成功です。（実行時期によって多少バージョンが異なる事はあります） 72 | 73 | ``` 74 | PHP 7.2.1 (cli) (built: Jan 3 2018 09:08:32) ( NTS ) 75 | Copyright (c) 1997-2017 The PHP Group 76 | Zend Engine v3.2.0, Copyright (c) 1998-2017 Zend Technologies 77 | with Zend OPcache v7.2.1, Copyright (c) 1999-2017, by Zend Technologies 78 | with Xdebug v2.6.0beta1, Copyright (c) 2002-2017, by Derick Rethans 79 | ``` 80 | 81 | 少々バージョンが古いですが過去に [私が書いた記事](https://qiita.com/keitakn/items/7d0a8d6e24c1861d799f#php%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB) が参考になるでしょう。 82 | 83 | ### `/etc/php.ini` の設定 84 | 85 | 様々な設定がありますが、最低限、完了の定義に記載してある設定は行っておきましょう。 86 | 87 | 特にエラーログが出ないと何が起こったのか本当に分からなくなってしまうので忘れずに設定を行いましょう。 88 | 89 | `/etc/php.ini` の設定に関しては以下の記事も参考になります。 90 | 91 | - [CentOSにPHP7をインストールしたらやっておくべき初期設定](http://affiwork.net/php-settings/) 92 | - [【PHP】PHPをインストールしたらやっておきたい設定](https://qiita.com/knife0125/items/0e1af52255e9879f9332) 93 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/task2.md: -------------------------------------------------------------------------------- 1 | # 課題2（ユーザー登録を完了させる） 2 | 3 | [ojt-php](https://github.com/keitakn/ojt-php) をベースに開発を進めて行きましょう。 4 | 5 | JavaScriptの時と同じようにリポジトリをGitHubにフォークする等をして自分の開発スペースを確保して下さい。 6 | 7 | 仮ユーザー登録（`/preregistration`）からメールアドレスを入れて、仮ユーザー登録の手続きを済ませて下さい。 8 | 9 | すると「仮ユーザー登録完了のお知らせ」というメールが届きます。 10 | 11 | 下記のような画面が表示されるので、ここからユーザー登録を完了させて下さい。 12 | 13 | ![task2-1](https://user-images.githubusercontent.com/11032365/37466632-9751476c-28a1-11e8-99df-dcff5d7b8efc.png) 14 | 15 | ## ユーザー登録の流れ 16 | 17 | ユーザー登録は以下の流れで行います。 18 | 19 | 1. ゲストユーザーが `/preregistration` に遷移する 20 | 1. ゲストユーザーがメールに記載された認証トークン付きのURLに遷移する 21 | 1. ユーザーがパスワードを入力する 22 | 1. 確認画面が表示されるので「登録する」を押すと登録が完了する（戻るを押すと前の画面に戻る） 23 | 24 | ## アウトプット 25 | 26 | ユーザー登録が完了しDBにユーザー情報が作成されるプログラムを作成する事。 27 | 28 | ## 完了条件 29 | 30 | 仕様として以下の条件を満たして下さい。 31 | 32 | - パスワードは「半角英小文字、大文字数字をそれぞれ一種類以上含む8文字以上100文字以下」とする事 33 | - DBに保存するパスワードは不可逆な形で保存する事 34 | - ユーザーIDは連番数値でユニークになるよう設計する事 35 | - 既に登録済のメールアドレスは登録出来ないようにする事 36 | - 「戻る」を押した時にユーザーが入力した値をフォームに引き継げている事 37 | - URLに含まれているトークンが有効期限切れの場合はエラー画面を出力し、再度の仮ユーザー登録を促す事 38 | - 登録完了後は `preregistrations.is_registered` が1に更新されている事 39 | - 一度ユーザー登録完了したトークンはユーザー登録のフローに進めないよう制御する事 40 | 41 | メンターのコードレビューで承認を得た時点で完了とします。 42 | 43 | ## ヒント 44 | 45 | ### パスワードのハッシュ化について 46 | 47 | パスワードは非常に重要な情報です。 48 | 49 | その為、ハッシュ値を計算して保存し例えシステムの管理者であってもユーザーのパスワードが何か分からない状況を作り出す事はマストです。 50 | 51 | PHPの場合は [2018年のパスワードハッシュ](https://qiita.com/rana_kualu/items/3ef57485be1103362f56) という記事が参考になります。 52 | 53 | たまに暗号化とハッシュ化を混合している人がいますが、この2つは明確な別物です。 54 | 55 | パスワードを暗号化して保存するのはアンチパターンです。（ハッシュ値を保存するのが正しい） 56 | 57 | この2つの違いについて把握しておきましょう。 58 | 59 | ちなみに近年では [Amazon Cognito ユーザープール](https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-identity-pools.html) のような安全にユーザーの個人情報を保存出来るサービスもあります。 60 | 61 | このようなサービスが成り立つのも、それだけパスワードのような情報を安全に保管する事が極めて難しい事を表していると言えます。 62 | 63 | 筆者の個人的な見解だとパスワード認証を避けられるなら実装は避けるべきであり以下のような代替手段を使うのが良いと考えます。 64 | 65 | - ソーシャルログイン（GoogleやTwitterによるログイン） 66 | - [Amazon Cognito ユーザープール](https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-identity-pools.html) 67 | 68 | しかしまだパスワード認証が必要な場面も多いので実装方法を押さえておく事は必要です。 69 | 70 | ### オブジェクト指向について 71 | 72 | ここからの課題はオブジェクト指向の基礎を押さえながら開発しましょう。 73 | 74 | 書籍ですが [現場で役立つシステム設計の原則](http://gihyo.jp/book/2017/978-4-7741-9087-7) という書籍がオススメです。 75 | 76 | - [初心者向けに徹底解説！オブジェクト指向とは？](https://eng-entrance.com/what-oop) 77 | - [オブジェクト指向と10年戦ってわかったこと](https://qiita.com/tutinoco/items/6952b01e5fc38914ec4e) 78 | 79 | ### テーブル設計について 80 | 81 | この課題を完了させる為にはDB設計を行う必要があります。 82 | 83 | 作成したテーブル構造は `ojt-php/database/database.sql` に記載して下さい。メンターのレビュー対象になります。 84 | 85 | テーブル設計は非常に奥が深いですが、このレッスンでは以下の点を意識しましょう。 86 | 87 | 1. テーブル名やカラム名を省略しない事 88 | 1. 適切なデータ型を使う事 89 | 1. ユニーク制約、NOT NULL制約、外部キー制約を適切に利用する事 90 | 91 | 命名規則に関しては [データベースオブジェクトの命名規約](https://qiita.com/genzouw/items/35022fa96c120e67c637) に書かれているルールを採用しましょう。 92 | 93 | また以下のカラムは必ず全てのテーブルに入れて下さい。 94 | 95 | ``` 96 | `lock_version` int(10) unsigned NOT NULL DEFAULT '0', 97 | `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 98 | `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 99 | ``` 100 | 101 | `created_at` は作成日時、`updated_at` は更新された日時が自動で入ります。 102 | 103 | 後のレッスンで学習しますがActive Record等のORMを利用する際にこれらのカラムが自動生成されます。 104 | 105 | システム的にもあると便利なので作成しておきましょう。 106 | 107 | `lock_version` は楽観的ロックを行う際に必要です。 108 | 109 | 「MySQL楽観的ロック」等の単語で調べてみましょう。 110 | 111 | # このレッスンで身につける事 112 | 113 | - オブジェクト指向プログラミングの実戦 114 | - DB設計の実戦 115 | 116 | ユーザーデータを処理してデータベースに保存する処理はWebアプリケーションの基本です。 117 | 118 | どのような言語であっても必要なスキルになるのでここで基本を身につけましょう。 119 | 120 | 開発規模が大きいのでJavaScript課題で行ったようにPRを細かい単位に分割しましょう。 121 | 122 | # メンター向け 123 | 124 | メンターはプロジェクト構成を受講者に対して説明して下さい。 125 | 126 | 受講者は不明点や設計方針の相談をメンターに良く相談してから実装して下さい。 127 | 128 | このくらいの規模になるとちょっとした認識の齟齬で大きな手戻りが発生する事もありえます。 129 | 130 | そうならない為にもPRは細かく、都度レビューを入れながらインクリメンタルに開発するアジャイル的な開発を意識しましょう。 131 | 132 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/task3.md: -------------------------------------------------------------------------------- 1 | # 課題3（ログイン） 2 | 3 | 他の課題と同様に [ojt-php](https://github.com/keitakn/ojt-php) をベースに開発を進めて行きましょう。 4 | 5 | この課題で作成するのはログイン機能になります。 6 | 7 | ## アウトプット 8 | 9 | ログイン処理を行うプログラム。 10 | 11 | ## 完了条件 12 | 13 | 以下の仕様を満たすプログラムを完成させましょう。 14 | 15 | - メールアドレスとパスワードでログインが出来る事 16 | - バリデーションが実装されている事 17 | - ログインフォームにCSRF対策が実施されている事 18 | - パスワードを間違えた際は適切なエラーメッセージが表示される事 19 | - ログイン状態を維持出来ている事 20 | - ログイン状態の場合、ログインページとユーザー登録系の画面には遷移出来ない仕様になっている事 21 | 22 | ## ヒント 23 | 24 | ### 認証について 25 | 26 | メールアドレスとパスワードで認証を行った後はログイン状態を維持している必要があります。 27 | 28 | これをどのように実現するかを考えてみましょう。 29 | 30 | 認証（Authentication）とは通信相手が誰かを特定する行為です。 31 | 32 | ログイン前はユーザーが誰か分からないので、メールアドレスとパスワードで本人確認を行います。 33 | 34 | これが認証です。 35 | 36 | ではログイン後はどうかと言うとこれもページ遷移毎に本人確認を行う必要があります。 37 | 38 | ログイン成功時にログインセッションを発行して、それをユーザーのブラウザ上に保存します。 39 | 40 | ログイン後の認証はログインセッションを元に行います。 41 | 42 | 要するにやる事は課題2のユーザー登録と同じです。 43 | 44 | どのようなデータが必要か考えてみましょう。 45 | 46 | ### ログイン後のリダイレクト処理について 47 | 48 | 多くのログイン処理を持つWebシステムはログイン完了後に会員専用ページ等へリダイレクトする処理が入っています。 49 | 50 | この課題ではログイン中ユーザー専用ページである `/users/{id}` へリダイレクトさせましょう。 51 | 52 | ### エラーメッセージについて 53 | 54 | ログイン失敗時のエラーメッセージはフォームを赤く表示させる等の工夫を行いましょう。 55 | 56 | またパスワードが間違えているか、メールアドレスが登録されていないか、でエラーメッセージを出し分けるようにしましょう。 57 | 58 | 実戦のシステムではエラーメッセージの出し分けはセキュリティ的な理由であえて詳しく書かない場合もあります。 59 | 60 | エラーメッセージからクラッカー（IT技術を悪用する人）にヒントを与える事になります。 61 | 62 | よってセキュリティを重視する場合はエラーメッセージをあえて分かりにくくする場合もある事を覚えておいて下さい。 63 | 64 | エラーメッセージを出し分けるほうが実装的には難易度が高いので今回は出し分ける方向で実装しましょう。 65 | 66 | ## このレッスンで身につける事 67 | 68 | - Webシステムで認証を行う為の方法 69 | - 安全なログイン処理の作り方 70 | 71 | ログイン処理は簡単に見えますがちゃんと作ろうとすると非常に大変です。 72 | 73 | 実戦ではかなり気を使うのでここを安全に作れるスキルがあれば他のシステムを作成する際にも必ず役に立ちますので頑張りましょう。 74 | 75 | また余裕がある場合は [こんな会員制システムにはユーザー登録したくない（ID・パスワードの扱い/入力画面）](https://qiita.com/otagaisama-1/items/18effbe525572eb71ce6) を読んでユーザーが使いやすい仕様を考えて実装してみるのも良いでしょう。 76 | 77 | この設計が [課題4（ユーザー情報を表示させる）](https://github.com/keitakn/web-developer-ojt/blob/master/docs/server-side-programming/PHP/task4.md) にも大きく影響するので先にある程度仕様を見ておくと良いでしょう。 78 | 79 | ## メンター向け 80 | 81 | セキュリティ面で問題ないかを重点的にレビューして下さい。 82 | 83 | また課題2と同じようにオブジェクト指向での開発になりますので、オブジェクト設計やテーブル設計等も重点的にレビューして下さい。 84 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/task4.md: -------------------------------------------------------------------------------- 1 | # 課題4（ユーザー情報を表示させる） 2 | 3 | 他の課題と同様に [ojt-php](https://github.com/keitakn/ojt-php) をベースに開発を進めて行きましょう。 4 | 5 | この課題で作成するのはログイン中のユーザー情報を表示させる機能になります。 6 | 7 | ## アウトプット 8 | 9 | `GET /users/1 HTTP/1.1` or `GET /users/1 HTTP/2.0` にアクセスした際、対象ユーザーのメールアドレスを表示させるプログラムを作成して下さい。 10 | 11 | ## 完了条件 12 | 13 | 以下の仕様を満たすようにシステムを実装して下さい。 14 | 15 | - ログイン状態でのみ閲覧出来るページになっている事 16 | - 非ログイン状態の場合、ログインページへリダイレクトする事 17 | - URL部分を他ユーザーの物に置き換えられた場合、情報を表示させないようになっている事 18 | 19 | ## ヒント 20 | 21 | この課題は一見簡単そうに見えますが、以下のようなケースが起こると重大なセキュリティホールを作る事になるので注意する必要があります。 22 | 23 | 1. ユーザーID `1` のユーザーがログイン 24 | 2. ユーザーID `1` のユーザーで `GET /users/2 HTTP/1.1` にアクセスする 25 | 26 | この時にユーザーID `2` の情報を表示させてはいけません。 27 | 28 | この状態を許すという事は他ユーザーの個人情報が見れるという事です。 29 | 30 | アプリケーションを実装するエンジニアとしては絶対起こしてはいけないミスです。 31 | 32 | これを起こさない設計を考える必要があります。 33 | 34 | ポイントは認証と認可です。 35 | 36 | - 認証（その人は誰か） 37 | - 認可（その人にはどういう操作をする権限があるか） 38 | 39 | [課題3（ログイン）](https://github.com/keitakn/web-developer-ojt/blob/master/docs/server-side-programming/PHP/task3.md) でログインセッションを発行しているハズなので、ログインセッションにこれらの情報を紐づけておく事です。 40 | 41 | ユーザーID `1` のログインセッションはユーザーID `1` のユーザー情報を操作する権限しか持たない。という状況になっていればOKです。 42 | 43 | ## このレッスンで身につける事 44 | 45 | - ログイン認証が必要なWebシステムの設計手法 46 | - 認証と認可が必要なシステムの設計手法 47 | 48 | ## メンター向け 49 | 50 | セキュリティホールがないか十分に設計レビューを行って下さい。 51 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/task5.md: -------------------------------------------------------------------------------- 1 | # 課題5（退会） 2 | 3 | 他の課題と同様に [ojt-php](https://github.com/keitakn/ojt-php) をベースに開発を進めて行きましょう。 4 | 5 | ## アウトプット 6 | 7 | ユーザーを退会（cancel）させる機能を作成して下さい。 8 | 9 | ## 完了条件 10 | 11 | 以下の条件を満たすようにして下さい。 12 | 13 | - トップページのメニューに退会ページへのリンクが表示されている事 14 | - 退会完了後は対象ユーザーに紐づく全てのログインセッションが無効化されている事 15 | - 退会後、再び同じメールアドレスでユーザー登録が可能になっている事（ユーザーIDは新規発行） 16 | - 退会時にユーザーが持っているメールアドレスは退会後も管理者が確認出来るようになっている事 17 | 18 | ## ヒント 19 | 20 | >退会後、再び同じメールアドレスでユーザー登録が可能になっている事（ユーザーIDは新規発行） 21 | 22 | ログイン時のメールアドレスを保存しているテーブルからデータを削除する必要があります。 23 | 24 | >退会時にユーザーが持っているメールアドレスは退会後も管理者が確認出来るようになっている事 25 | 26 | `cancelled_users_○○` テーブルを作って退会するユーザー情報を残しておきましょう。 27 | 28 | 完全削除してしまうと対象ユーザーがどのような操作を行っていたか全く分からなくなるので、システムで予期しない問題を発生される可能性があります。 29 | 30 | 退会ユーザーと生きているユーザーは別のテーブルで管理するのが分かりやすいです。 31 | 32 | ただしパスワード等の認証情報は完全に削除してしまって問題はありません。 33 | 34 | ## このレッスンで身につける事 35 | 36 | - 退会時処理の作成時に最低限必要な実装 37 | 38 | ## メンター向け 39 | 40 | 以下の点を重点的にレビューして下さい。 41 | 42 | - 要件を確実に満たしているか 43 | - 必要なデータが削除されている 44 | - 必要なデータが別テーブルに保管されている 45 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/task6.md: -------------------------------------------------------------------------------- 1 | # 課題6（パスワードリセット） 2 | 3 | 他の課題と同様に [ojt-php](https://github.com/keitakn/ojt-php) をベースに開発を進めて行きましょう。 4 | 5 | ## アウトプット 6 | 7 | ユーザーのパスワードをリセットする機能を作成して下さい。 8 | 9 | ## 完了条件 10 | 11 | 以下の条件を満たすようにして下さい。 12 | 13 | - ログインページ内に「パスワードを忘れた方はこちら」のリンクが設置されている事 14 | - パスワードリセット完了後は対象ユーザーが持つ全てのログインセッショントークンを無効化する事 15 | - リセット前と同じパスワードは設定出来ないようになっている事 16 | 17 | ログインが必要なWebアプリケーションでは必須機能です。 18 | 19 | この課題を通じてしっかりと設計方法を学習しましょう。 20 | 21 | ## ヒント 22 | 23 | ざっくりとした流れは以下の通りです。 24 | 25 | 1. ユーザーが「パスワードを忘れた方はこちら」からパスワードのリセット申請を出す 26 | 2. システム側は `1` で受け取ったメールアドレス宛にトークン付きのメールを送信する 27 | 3. ユーザーはメールに届いたトークン付きのURLにアクセスする 28 | 4. システム側はトークンが正しいかチェックして正しくないトークンの場合はエラーメッセージを出す 29 | 5. ユーザーは新しいパスワードを入力する 30 | 6. システム側はパスワードをチェックして条件に合わない場合はエラーメッセージを出す 31 | 7. システム側はパスワードを変更し、ログインセッショントークンを全て無効化する 32 | 33 | 流れ的にはユーザー登録と良く似ています。 34 | 35 | パスワードを忘れた人が使う機能なので、メールアドレスはユーザーに入力してもらう必要があります。 36 | 37 | 当然メールアドレスからユーザーIDを特定するのはシステム側の責務です。 38 | 39 | どのようなデータ設計が必要か考えてみましょう。 40 | 41 | >パスワードリセット完了後は対象ユーザーが持つ全てのログインセッショントークンを無効化する事 42 | 43 | これが必要な理由はこの機能が単にパスワードを忘れた時だけではなく、不正ログインをされてパスワードを変更したい時にも利用されるからです。 44 | 45 | このようなケースにおいては不正利用を防ぐ為、自身が持つ全てのトークンを無効化する事が期待されます。 46 | 47 | ## このレッスンで身につける事 48 | 49 | セキュリティを考慮したパスワードリセット機能を実装出来るようになる。 50 | 51 | ## メンター向け 52 | 53 | セキュリティ面で漏れがないか重点的にレビューをお願いします。 54 | -------------------------------------------------------------------------------- /docs/server-side-programming/PHP/task7.md: -------------------------------------------------------------------------------- 1 | # 課題7（ソーシャルログイン） 2 | 3 | 他の課題と同様に [ojt-php](https://github.com/keitakn/ojt-php) をベースに開発を進めて行きましょう。 4 | 5 | ## アウトプット 6 | 7 | Googleアカウントでユーザー登録、ログインが出来るようにシステムを改修して下さい。 8 | 9 | ## 完了条件 10 | 11 | 以下の条件を満たすようにして下さい。 12 | 13 | - TwitterやLINE等他のSNSアカウントでの改修要件が来ても耐えられる設計になっている事 14 | - OAuth、OpenID Connectのクライアントとして必要な実装が行われている事 15 | 16 | ## ヒント 17 | 18 | この課題を行う為には https://console.developers.google.com/ に登録を行う必要があります。（Googleアカウントを持っていれば可能です） 19 | 20 | 流れを理解するだけなら [GoogleでログインするWebサービスを作ろう](https://dotinstall.com/lessons/google_connect_php_v2) を見ると良いでしょう。 21 | 22 | ただし実装方法は実戦で使うには不十分なのであくまでも参考程度に捉えて下さい。 23 | 24 | ここで利用するGoogleAPIはOAuthやOpenID Connectの仕組みに準拠しています。 25 | 26 | 下記の記事等を見てこの仕組について理解しておきましょう。 27 | 28 | - [一番分かりやすい OAuth の説明](https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be) 29 | - [OpenID Connect](https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe) 30 | 31 | 今回の課題は専門用語を使って説明するとGoogleというOpenIDProviderにクライアントアプリケーションを登録する事です。 32 | 33 | OAuth、OpenID Connectのクライアントとしてどのような実装が必要かは下記の記事が参考になります。 34 | 35 | - [OAuth 2.0の代表的な利用パターンを仕様から理解しよう](https://www.buildinsider.net/enterprise/openid/oauth20) 36 | - [OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ](https://www.buildinsider.net/enterprise/openid/connect) 37 | 38 | OAuthやOpenID Connectは世界的に広く使われているID連携方法です。 39 | 40 | ここでしっかりと理解しておきましょう。 41 | 42 | ちなみに仕様の原文は下記になります。（正確には原文の日本語訳） 43 | 44 | - [The OAuth 2.0 Authorization Framework](https://openid-foundation-japan.github.io/rfc6749.ja.html) 45 | - [OpenID Connect Core 1.0](https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html) 46 | 47 | これらを全てこの課題中に理解するのは大変なのでクライアント実装に必要な部分だけ押さえればOKです。 48 | 49 | ## このレッスンで身につける事 50 | 51 | - OAuth、OpenID Connectに対する理解 52 | 53 | ## メンター向け 54 | 55 | OAuthクライアントとして必要な実装が全て行われているか重点的にレビューして下さい。 56 | -------------------------------------------------------------------------------- /docs/system-design/README.md: -------------------------------------------------------------------------------- 1 | # システム設計 2 | 3 | ここではシステム設計の基本的な考え方を学習します。 4 | 5 | ## システム設計に関する誤解 6 | 7 | もう少なくはなっていますがシステム設計に以下のようなイメージを持っている人がいます。 8 | 9 | - Excelで処理の内容を箇条書きにした設計書を作る 10 | - 作図ツールを使って図解入りの説明資料を作る 11 | - Excelでテーブル定義書やER図を作る 12 | 13 | もしこれらのイメージを持っていたらそのイメージは捨てて下さい。 14 | 15 | 設計とは限りなくコーディング（実装）に近い物です。 16 | 17 | 設計者とはプログラミングが出来る技術者の事です。 18 | 19 | コードを書けない人がExcel等で作図した物を設計とは呼びません。（あえて名前を付けるなら机上の空論とでも名付けましょう） 20 | 21 | 「システム設計」でググると上流工程とか下流工程、外部設計、内部設計等の用語解説が上位に表示されます。 22 | 23 | これらの用語も一旦忘れてしまって構いません。 24 | 25 | これらの解説を行っている記事はウォーターフォール的な考え方で書かれています。 26 | 27 | あえて極端な言い方をしますが、ウォーターフォールはアンチパターンです。 28 | 29 | ウォーターフォールをベースにした考え方は現実世界ではまず上手く行きません。 30 | 31 | 良い設計とはアジャイル開発的な考えでしか生まれないと私は考えます。 32 | 33 | - （参考）[プログラミングと設計は本来切り離せないもの](http://d.hatena.ne.jp/ryoasai/20101030/1288432422) 34 | - （参考）[ソースコードは設計書であり、コーディングは設計作業である](https://qiita.com/mdstoy/items/5510f94c9ed981cfbb85) 35 | 36 | ## 設計の基本的な考え方 37 | 38 | 先程、設計とは資料作りの事ではないと説明しました。 39 | 40 | では何が設計の成果物なのかを以下に記載します。 41 | 42 | - 試行錯誤の結果完成したクラス設計やディレクトリ構成 43 | - RDBMS等のDBスキーマ 44 | - AWS等のCloudServiceを管理する [Terraform](https://www.terraform.io/) のソースコード 45 | 46 | プログラム設計、DB設計、ネットワーク設計等様々な物がありますが、全てに共通して言えるのは成果物が動くモノだと言う事です。 47 | 48 | 設計とは動くモノを作る行為です。 49 | 50 | これだけ聞くと実装との違いが分かりませんが、単なるプログラムなのか設計の成果物なのかは以下の点を意識した作りになっているかで決まります。 51 | 52 | - 拡張性が考慮されている事（機能やデータ構造を追加しやすい） 53 | - 保守性が考慮されている事（機能変更がやりやすい） 54 | 55 | これらが考慮され、かつ動いている成果物であれば設計の成果物と言えます。 56 | 57 | ### 設計とは良い実装の延長線である 58 | 59 | 良いコードを書く為の手法を紹介した [リーダブルコード](https://www.amazon.co.jp/dp/4873115655) という書籍があります。 60 | 61 | これは実装の本ですがここに記載されているテクニックの一部は設計でも重要になります。 62 | 63 | - 名前に情報を詰め込む（良い名前を付ける事は設計でも最重要） 64 | - 巨大な式を分割する（本では関数の分割方法を紹介しているが、サブシステムやテーブルを分割する時の考え方とも似ている） 65 | - 一度に1つのことを（UNIXという考え方にも出てきた考え方、複雑なシステムもシンプルなサブシステムに分ける事でシンプルに作れる） 66 | 67 | 良い設計が出来るようになる近道は良いコードを書けるようになる事だったりします。（それだけではありませんが） 68 | 69 | - （参考）[リーダブルコード](https://www.amazon.co.jp/dp/4873115655) 70 | - （参考）[UNIXという考え方―その設計思想と哲学](https://www.amazon.co.jp/dp/4274064069) 71 | 72 | ### 良い設計は初めから手に入らない 73 | 74 | ウォーターフォール的な考えでは、要件定義 → 設計 → 実装と流れに従って進めるモノとされています。 75 | 76 | この方法は机上の空論なのでまず上手くいく事はないでしょう。 77 | 78 | 良い設計とは要件定義 → 設計 → 実装を短いスパンで繰り返し何度も作成と破壊を繰り返す事によってしか得られません。 79 | 80 | 最初から良い設計が出来るという考えを捨てる必要があります。 81 | 82 | よって手戻りが発生しても良いように、短いスパンで成果物のレビューを行う事を徹底する事が大事です。 83 | 84 | ### 詳細仕様書とはテストコードの事 85 | 86 | システムの仕様をもっとも正確に表わしているのはソースコードです。 87 | 88 | それ以外の仕様書等はソースコードとズレている可能性があるので完全に信用する事は出来ないという事を覚えておきましょう。 89 | 90 | 良い仕様書を書く方法を考えるくらいなら、良いテストコードを書けるようになりましょう。 91 | 92 | 現在はユニットテストだけではなく、E2Eテスト（Webサービスの場合はブラウザテスト）等も自動化出来るのでよりその傾向が強まっています。 93 | 94 | ### 完璧を目指すよりアンチパターンを避ける 95 | 96 | 世の中に完璧な設計という物は存在しません。 97 | 98 | 逆に明らかな間違いを探す事は比較的可能です。 99 | 100 | よって完璧な設計を追求するよりもアンチパターンを避けるようにしましょう。 101 | 102 | 各分野で詳しく解説をしますが、例えばデータベースの設計なら [SQLアンチパターン](https://www.amazon.co.jp/dp/4873115892) を参考にする等です。 103 | 104 | ### 巨人の肩の上に立つ 105 | 106 | 意味は [こちら](https://big-mac.jp/recommend/lifehack/stand-on-the-shoulder-of-the-giant/) を見て下さい。 107 | 108 | 設計分野も既に先人が解決している場合が多いので解決策がないかを探してみる事が基本となります。 109 | 110 | ### ドキュメントはなるべく書かない 111 | 112 | ドキュメントをどんなにキレイに書いてもソースコードとズレる可能性をゼロにする事は出来ません。 113 | 114 | どんなにキレイに書かれていてもソースコードの動きと異なる情報が一度でも書かれていたら、そのドキュメントに対する信頼は一気になくなります。 115 | 116 | そこで発想を変えます。 117 | 118 | ドキュメントを自ら書くのではなく、ソースコードからドキュメントを自動生成する方法を考えます。 119 | 120 | オープンソースで様々なモノがあるので、代表的なモノをいくつか紹介します。 121 | 122 | - [Swagger](https://swagger.io/) 123 | - YAMLからREST APIのドキュメントを作成するツール 124 | - [JSDoc](https://github.com/jsdoc3/jsdoc) 125 | - DOCコメントからHTML形式のドキュメントを生成するツール 126 | - [MySQL Workbench](https://www.mysql.com/jp/products/workbench/) 127 | - MySQLの操作やER図の作成を自動で行う 128 | - [Ansible](https://www.ansible.com/) 129 | - ミドルウェアの状態を管理するツール 130 | - ドキュメントだけでなく環境その物を自動生成出来るのでサーバの手順書が不要になる 131 | - [Terraform](https://www.terraform.io/) 132 | - AWS等のCloudServiceの状態をコードで管理する 133 | - ドキュメントだけでなく環境その物を自動生成出来るのでインフラ構築の手順が不要になる 134 | - [Cloudcraft](https://cloudcraft.co/) 135 | - AWSのアカウントからネットワーク構成図を自動生成するツール 136 | 137 | ここで紹介出来ない物もたくさんあるので便利なツールは積極的に導入していきましょう。 138 | 139 | ただし `README.md` は書いたほうが良いでしょう。 140 | 141 | ここにはアプリケーションの起動方法やテストの実行方法、設計の基本方針等をまとめておくとシステムを引き継ぐ人が分かりやすいです。 142 | 143 | 参考までに私が過去に書いた物を共有させて頂きます。 144 | 145 | - [aws-serverless-prototype](https://github.com/keitakn/aws-serverless-prototype) 146 | 147 | 他にも必要なドキュメントを作成する事は問題ありません。 148 | 149 | ただし出来る限りソースコードから自動生成出来ないか考えるようにしましょう。 150 | 151 | ### とりあえず早くリリースするという考え方について 152 | 153 | 「品質とスピードはトレード・オフの関係にある」という主張をする人がいます。 154 | 155 | しかしこれは誤りだと私は考えています。 156 | 157 | 設計の基本を知っている、キレイなコードの書き方を知っている、という事が全てになります。 158 | 159 | キレイに書いたら遅くなる、汚く書いたら早くなるという訳ではありません。 160 | 161 | 品質の高いプロダクトをそれなりの速度で作れるようになる為には設計手法を学ぶ事が必要不可欠です。 162 | 163 | （参考） http://kobase16.hatenablog.com/entry/2019/10/31/230509 164 | 165 | ## 終わりに 166 | 167 | 以上が設計に関する基本的な心構えになります。 168 | 169 | 同階層のページに各分野での設計方法を記載した資料を作成しますので参考にしてみて下さい。 170 | -------------------------------------------------------------------------------- /docs/system-design/database.md: -------------------------------------------------------------------------------- 1 | # データベース設計 2 | 3 | この資料ではデータベース設計で押さえるべきポイントを記載します。 4 | 5 | 基本的にMySQLベースで話を進めさせて頂きますので [RDBMSの基礎](https://github.com/keitakn/web-developer-ojt/tree/master/docs/mysql) を読んでMySQLの基礎を理解してから読み進めるようにお願いします。 6 | 7 | ## データベース設計で押さえるべきポイント 8 | 9 | RDBMS設計には既に様々なノウハウが確立されています。 10 | 11 | 特に参考になりそうな資料を下記に記載します。 12 | 13 | - [SQLアンチパターン](https://www.amazon.co.jp/dp/4873115892) 14 | - [達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ](https://www.amazon.co.jp/dp/4798124702) 15 | - [現場で役立つシステム設計の原則](https://www.amazon.co.jp/dp/477419087X) 16 | 17 | [現場で役立つシステム設計の原則](https://www.amazon.co.jp/dp/477419087X) はデータベースの専門書ではありませんが、押さえるべきポイントが簡潔に守られており、非常に良い教材となっています。 18 | 19 | ここでは [現場で役立つシステム設計の原則](https://www.amazon.co.jp/dp/477419087X)「第6章データベースの設計とドメインオブジェクト」をベースに話を進めていきます。 20 | 21 | この書籍を保持している場合はこの書籍を読んでもらってから本ドキュメントを読むと、より理解を深める事が出来ます。 22 | 23 | ### 名前を省略しない 24 | 25 | メーカー品番を表すカラム名を例に説明します。 26 | 27 | `mk_cd` 等のような意味不明な略称は使わないようにしましょう。 28 | 29 | `maker_code` のような誰が見ても分かる命名を行う事を徹底しましょう。 30 | 31 | 略名が使用されているのはかつてデータベースびテーブル名やカラム名に厳しい文字制限があった時代の名残です。 32 | 33 | 現在では文字列制限は緩和されており、略名を使う理由はありません。 34 | 35 | 「テーブル名、カラム名」で何を表わしているか分かるのがベストです。 36 | 37 | 良い名前を付けるというのは、データベース設計でも重要になります。 38 | 39 | [データベースオブジェクトの命名規約](https://qiita.com/genzouw/items/35022fa96c120e67c637) という記事を参考にすると良いでしょう。 40 | 41 | また良く使われる項目には既に世の中に標準的な仕組みがあったりします。 42 | 43 | 例えば、性別は [ISO 5218](https://en.wikipedia.org/wiki/ISO/IEC_5218) で仕様が決められています。 44 | 45 | 以下が正しい仕様です。 46 | 47 | ``` 48 | 0 = not known 49 | 1 = male 50 | 2 = female 51 | 9 = not applicable 52 | ``` 53 | 54 | man、womanではなくmale、femaleです。 55 | 56 | 良く使うユーザー属性名も [OpenIDConnect 5.1.Standard Claims](http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#StandardClaims) で物理名が定められています。 57 | 58 | 日本国内のみで利用する想定であれば [データベース列名の名前付け（英単語での）採用例を集めてみた](https://qiita.com/otagaisama-1/items/4d7e2eb5c274e9fce664) も参考になります。 59 | 60 | 世の中の流れはグローバル化なので今後サービス開発を行う時は多言語に対応する事がマストになってくると考えられます。 61 | 62 | [OpenIDConnect 5.1.Standard Claims](http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#StandardClaims) のような国際的に利用されているものがあれば日本独自の慣例よりも国際基準を優先したほうが良いでしょう。 63 | 64 | ### 適切なデータ型を利用する 65 | 66 | たまに全てを文字列型で保存しているような設計を見かけますが、数値を扱うのであれば数値型を入れるべきだし、日付を扱うなら日付型を使うべきです。 67 | 68 | 細かい事を言うと数値型だけでも以下のようにたくさんの種類があります。 69 | 70 | - INTEGER 71 | - INT 72 | - SMALLINT 73 | - TINYINT 74 | - MEDIUMINT 75 | - BIGINT 76 | 77 | これらは扱える数値の範囲が異なります。（詳しくは [公式ドキュメント](https://dev.mysql.com/doc/refman/5.6/ja/integer-types.html) を参照） 78 | 79 | これらも踏まえて適切なデータ型を利用しましょう。 80 | 81 | データ型については [公式ドキュメント](https://dev.mysql.com/doc/refman/5.6/ja/data-types.html) を参考にして下さい。 82 | 83 | ただし [ENUM型](https://dev.mysql.com/doc/refman/5.6/ja/enum.html) は注意して利用しましょう。 84 | 85 | テーブル定義は後で変更する事も可能ではありますが、プログラムと比較して後で変更するコストが大きいです。 86 | 87 | ENUMを使うとそのカラムに対する拡張性は完全に失われるので注意して利用しましょう。 88 | 89 | ちなみに先程紹介した性別コードのようにコードが決まっている物は数値型で管理したほうがデータベースの容量は少なくて済みます。 90 | 91 | 数値型のほうが文字列よりもデータを検索する効率も良い事を覚えておきましょう。 92 | 93 | ``` 94 | 0 = not known 95 | 1 = male 96 | 2 = female 97 | 9 = not applicable 98 | ``` 99 | 100 | ### 制約を適切に利用する 101 | 102 | 制約は必ず利用しましょう。 103 | 104 | データベースが持つ3つの制約は下記の通りです。 105 | 106 | - NOT NULL制約 107 | - ユニーク制約 108 | - 外部キー制約 109 | 110 | これらを利用する事の重要性について説明します。 111 | 112 | #### NOT NULL制約 113 | 114 | ユーザー情報を管理するテーブルを例に説明します。 115 | 116 | ユーザー情報には以下の3つがあります。 117 | 118 | - ユーザーID 119 | - メールアドレス 120 | - 誕生日 121 | - 電話番号 122 | 123 | この中でユーザーIDとメールアドレスは必須ですが、誕生日と電話番号の登録が必須ではありません。 124 | 125 | さらに以下の条件を満たしている必要があると仮定します。 126 | 127 | - メールアドレスはユーザー1人につき、1つまで登録可能 128 | - メールアドレスは全ユーザーでユニークになる必要がある 129 | - 電話番号は1人のユーザーが何個でも登録出来る 130 | 131 | ユーザーIDと誕生日を保存するテーブルを考えてみましょう。 132 | 133 | 普通に考えると下記のようなテーブル構造になります。 134 | 135 | ```mysql 136 | CREATE TABLE `users` ( 137 | `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 138 | `email` varchar(128) COLLATE utf8mb4_bin NOT NULL, 139 | `birthdate` date, 140 | `lock_version` int(10) unsigned NOT NULL DEFAULT '0', 141 | `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 142 | `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 143 | PRIMARY KEY (`id`), 144 | UNIQUE KEY `uq_users_01` (`email`) 145 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC; 146 | ``` 147 | 148 | 結論から言うとこのテーブル構造は良い構造ではありません。 149 | 150 | 誕生日がないユーザー数だけ `birthdate` カラムに `NULL` が登録されます。 151 | 152 | `NULL` は未知を表すデータ型です。 153 | 154 | データベースは既知の事実を記録する仕組みです。 155 | 156 | また `NULL` を許可するとプログラム側で常に `NULL` かどうかをチェックするコードが必要になり、複雑化の原因になります。 157 | 158 | このようなケースでは下記のようなテーブル構造にするのが良いでしょう。 159 | 160 | ```mysql 161 | CREATE TABLE `users` ( 162 | `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 163 | `lock_version` int(10) unsigned NOT NULL DEFAULT '0', 164 | `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 165 | `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 166 | PRIMARY KEY (`id`) 167 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC; 168 | 169 | CREATE TABLE `users_emails` ( 170 | `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 171 | `user_id` int(10) unsigned NOT NULL, 172 | `email` varchar(128) COLLATE utf8mb4_bin NOT NULL, 173 | `lock_version` int(10) unsigned NOT NULL DEFAULT '0', 174 | `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 175 | `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 176 | PRIMARY KEY (`id`), 177 | UNIQUE KEY `uq_users_emails_01` (`user_id`), 178 | UNIQUE KEY `uq_users_emails_02` (`email`), 179 | CONSTRAINT `fk_users_emails_01` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) 180 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC; 181 | 182 | CREATE TABLE `users_birthdates` ( 183 | `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 184 | `user_id` int(10) unsigned NOT NULL, 185 | `birthdate` date NOT NULL, 186 | `lock_version` int(10) unsigned NOT NULL DEFAULT '0', 187 | `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 188 | `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 189 | PRIMARY KEY (`id`), 190 | UNIQUE KEY `uq_users_birthdates_01` (`user_id`), 191 | CONSTRAINT `fk_users_birthdates_01` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) 192 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC; 193 | 194 | CREATE TABLE `users_phone_numbers` ( 195 | `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 196 | `user_id` int(10) unsigned NOT NULL, 197 | `phone_number` varchar(32) COLLATE utf8mb4_bin NOT NULL, 198 | `lock_version` int(10) unsigned NOT NULL DEFAULT '0', 199 | `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 200 | `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 201 | PRIMARY KEY (`id`), 202 | KEY `idx_users_phone_numbers_01` (`user_id`), 203 | KEY `idx_users_phone_numbers_02` (`phone_number`), 204 | CONSTRAINT `fk_users_phone_numbers_01` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) 205 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC; 206 | ``` 207 | 208 | テーブルを4つに分けました。 209 | 210 | これで誕生日を登録しないユーザーがいたとしても、`users_birthdates` テーブルにデータが登録されないだけで `NULL` データを回避する事が出来ます。 211 | 212 | さらにこの構造にした事で後で要件が変化してメールアドレスの登録が必須でなくなったとしても対応が可能になっています。 213 | 214 | データベース設計には正規化と呼ばれるテクニックがあります。 215 | 216 | 詳しくは [4ステップで作成する、DB論理設計の手順とチェックポイントまとめ](https://qiita.com/nishina555/items/a79ece1b54faf7240fac) を見て下さい。 217 | 218 | しかし正規化の知識がない状態であったとしても、`NOT NULL` 制約の利用を徹底する事で自然と正規化されたテーブル設計になります。 219 | 220 | #### ユニーク制約 221 | 222 | テーブル内で一意な値になる事を担保する機能です。 223 | 224 | 先程例に上げた `users_emails` テーブルの下記に注目しましょう。 225 | 226 | ```sql 227 | UNIQUE KEY `uq_users_emails_01` (`user_id`), 228 | UNIQUE KEY `uq_users_emails_02` (`email`), 229 | ``` 230 | 231 | `user_id` と `email` は重複登録されるとシステムとして成立しなくなります。 232 | 233 | 特に `email` をログインIDとして利用しているケースでは致命的です。 234 | 235 | ログイン時にユーザーを特定する際にどちらのユーザーがログインするか分からなくなってしまいます。 236 | 237 | このように重複する事が許されないデータを管理する時は必ずユニーク制約を利用しましょう。 238 | 239 | ユニーク制約を使わずにプログラムで重複チェックを行う方法もあります。 240 | 241 | - データベース登録前にSELECTでデータベースを検索する 242 | - 検索結果が見つからない場合はユーザー情報をデータベースに登録する 243 | - 検索結果が1件以上存在する場合は登録エラーを出す 244 | 245 | 結論から言うとこの方法はアンチパターンです。 246 | 247 | ほぼ同時刻に同じメールアドレスからリクエストを受けた場合、重複登録を完全に防ぐ事は出来ません。 248 | 249 | データベースが出来る事を無理にプログラムでやろうとするよりもデータベースの仕組みを適切に利用する事を考えましょう。 250 | 251 | #### 外部キー制約 252 | 253 | `users_emails` テーブルの以下に注目しましょう。 254 | 255 | ```sql 256 | CONSTRAINT `fk_users_emails_01` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) 257 | ``` 258 | 259 | これがMySQLにおける外部キー制約を表す記述です。 260 | 261 | `users_emails` テーブルはユーザーのメールアドレスを管理するテーブルです。 262 | 263 | `users` テーブルに存在しないユーザーIDが `users_emails` テーブルに登録されているという事はあってはいけません。 264 | 265 | このような状況を防ぐ為の仕組みが外部キー制約です。 266 | 267 | 外部キー制約に関しては反対派意見もあります。 268 | 269 | 主に以下のような反対意見です。 270 | 271 | - テストデータを用意するのが面倒くさい 272 | - パフォーマンスが劣化する 273 | - プログラムでも十分に担保出来る 274 | 275 | >テストデータを用意するのが面倒くさい 276 | 277 | 面倒くさいと言われてしまってはそれまでですが、言い方を変えると常に正しい状態のデータでテストが実施されるので、後から問題が起きるよりは全然良いと考えます。 278 | 279 | データ仕様に関してはテスト用データベースにデータを自動登録する仕組みがあるのでそれを利用すればさほど手間ではないでしょう。 280 | 281 | >パフォーマンスが劣化する 282 | 283 | 多少のオーバーヘッドがある事は事実です。 284 | 285 | しかし経験上、それが問題になった事は一度もありません。 286 | 287 | 少なくとも人間に感じるレベルのパフォーマンス劣化が外部キー制約を付けただけで起こるという事はないと考えられます。 288 | 289 | >プログラムでも十分に担保出来る 290 | 291 | 完璧に書かれているプログラムなら確かにそうですが、人間とはミスをする物です。 292 | 293 | これはバグのないプログラムしか書かないという前提の考えの元にのみ成り立つ考えで非常に危険な考え方です。 294 | 295 | 人間が書くプログラムにミスがあってもデータベース側でエラーを出してくれたほうがミスに早い段階で気がつけるので良いと考えます。 296 | 297 | ### indexを適切に利用する 298 | 299 | RDMBSにはindexという検索を効率的に行う為の仕組みがあります。 300 | 301 | `users_phone_numbers` テーブルの以下の記述に注目しましょう。 302 | 303 | ```sql 304 | KEY `idx_users_phone_numbers_01` (`user_id`), 305 | KEY `idx_users_phone_numbers_02` (`phone_number`), 306 | ``` 307 | 308 | ここでは詳しい説明は割愛しますが内部では「B木」と呼ばれるアルゴリズムが利用されています。 309 | 310 | （参考）[MySQL with InnoDB のインデックスの基礎知識とありがちな間違い](http://techlife.cookpad.com/entry/2017/04/18/092524) 311 | 312 | 簡潔に言うとテーブルの特定カラムに対してindex（索引）を追加する事で効率良くデータを見つけるように出来る仕組みです。 313 | 314 | `users_phone_numbers` テーブルの場合、ユーザーIDと電話番号でSELECTする事が想定されます。 315 | よって `user_id` と `phone_number` にindexを付けています。 316 | 317 | SQLを作る際はindexが適切に利用されているかを確認する必要があります。 318 | 319 | 確認方法ですが、下記のようにSQLの前に `EXPLAIN ` を付けます。 320 | 321 | ```sql 322 | mysql> EXPLAIN SELECT * FROM users_phone_numbers WHERE user_id = 3; 323 | +----+-------------+---------------------+------------+------+----------------------------+----------------------------+---------+-------+------+----------+-------+ 324 | | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | 325 | +----+-------------+---------------------+------------+------+----------------------------+----------------------------+---------+-------+------+----------+-------+ 326 | | 1 | SIMPLE | users_phone_numbers | NULL | ref | idx_users_phone_numbers_01 | idx_users_phone_numbers_01 | 4 | const | 1 | 100.00 | NULL | 327 | +----+-------------+---------------------+------------+------+----------------------------+----------------------------+---------+-------+------+----------+-------+ 328 | 1 row in set, 1 warning (0.00 sec) 329 | ``` 330 | 331 | 見方ですが、まず `type` という部分に注目しましょう。 332 | 333 | 以下の値のどれかが入ります。 334 | 335 | - const 336 | - eq_ref 337 | - ref 338 | - range 339 | - index 340 | - ALL 341 | 342 | 上から効率の良い順番に並んでいます。 343 | 344 | `const` が最も効率が良く、 `ALL` が最も効率が悪いという事です。 345 | 346 | （参考1）[8.8.2 EXPLAIN 出力フォーマット](https://dev.mysql.com/doc/refman/5.6/ja/explain-output.html) 347 | （参考2）[EXPLAINを見て気をつけること（自分なりの忘付録）](https://qiita.com/Tsuji_Taku50/items/43eb2a41915d03173773) 348 | （参考3）[MySQL EXPLAINのそれぞれの項目についての覚書](https://qiita.com/kzbandai/items/ea02727f4bb539fcedb5) 349 | 350 | 数百件程度のデータなら `const` でも `ALL` でもほとんど変わりません。 351 | 352 | しかし件数が多くなると人間でも感じる程にSQLの性能は劣化していきます。 353 | 354 | SQLを作った際は `EXPLAIN` で効率が悪いSQLを書いていないか確認を行いましょう。 355 | 356 | ちなみに `UNIQUE KEY` や `PRIMARY KEY` はindexが付いている状態と同様の効果（それ以上の効果）があるので、indexを付ける必要はありません。 357 | 358 | さらに高度なテクニックとして `rows_examined` を見て性能を判断する方法もあります。 359 | 360 | 詳しくは [MySQLのクエリの良し悪しはrows_examinedで判断する](http://blog.kamipo.net/entry/2018/03/22/084126) をご覧下さい。（非常に良い記事です） 361 | 362 | データを1件返すだけの比較的単純なSQLであれば `EXPLAIN` で十分です。 363 | 364 | 複数件のデータを返す可能性があり、かつ性能が求められる場合は上記記事で紹介されている `rows_examined` を確認する事も検討してみて下さい。 365 | 366 | #### 全てのカラムにindexを付けるのはダメ 367 | 368 | SELECTのパフォーマンスが良くなるからと言って、全てのカラムにindexを付けてはダメです。 369 | 370 | indexを増やすとINSERTやUPDATEのSQLにオーバーヘッドが生じてパフォーマンスが劣化します。 371 | 372 | またメモリ使用量が増えるのでデータベース全体のメモリ容量が不足する要因になります。 373 | 374 | ビジネス要件に対して適切なindexを付けるようにしましょう。 375 | 376 | #### 無意味なindexを作らない 377 | 378 | 良く言われる事は「カーディナリティが低いカラムには作るべきではない」という事です。 379 | 380 | カーディナリティとは「あるカラムにおける、取りうる値の種類」のことです。 381 | 382 | 性別を表すカラムがあり、「男性」「女性」の2種類があったとします。 383 | 384 | 男女比がほぼ1対1になる場合、性別カラムにindexを作ってもほとんど効果がありません。 385 | 386 | また日本の都道府県と当道府県コードを管理するようなレコード数が極端に少ない（最大で47件）テーブルもindexを作る意味はないでしょう。 387 | 388 | このようなテーブルは `ALL` で検索する前提のテーブル構造だからです。 389 | 390 | - [MySQL with InnoDB のインデックスの基礎知識とありがちな間違い](http://techlife.cookpad.com/entry/2017/04/18/092524) 391 | - [MySQL(InnoDB)でカーディナリティの低いカラムにINDEXを張る](https://qiita.com/hmatsu47/items/2d44c173a9114fd06853) 392 | 393 | ちなみにindexはテーブル作成時だけでなく、後で追加する事も可能です。 394 | 395 | `ALTER TABLE テーブル名 ADD INDEX インデックス名(カラム名);` 396 | 397 | 詳しくは下記の記事を参考にして下さい。 398 | 399 | （参考）[14.11.1 オンライン DDL の概要](https://dev.mysql.com/doc/refman/5.6/ja/innodb-create-index-overview.html) 400 | （参考）[MySQLのスキーマ変更をオンラインでやるための選択肢比較](https://qiita.com/masamasa/items/0dc0c7f35f2bffc02db1) 401 | 402 | 単純にindexを追加するだけなら問題ないですが、大きな変更をシステム稼働中に行うのはリスクがあります。 403 | 404 | 可能ならば一度システムをメンテナンス状態にして書き込みが全く起こらない状況を作ってから、テーブル構造を変更したほうがより安全です。 405 | 406 | ### 必ず作るカラム 407 | 408 | 私の場合以下のカラムを必ず全てのテーブルに作ります。 409 | 410 | ``` 411 | `lock_version` int(10) unsigned NOT NULL DEFAULT '0', 412 | `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 413 | `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 414 | ``` 415 | 416 | これらはビジネス上必要なデータというよりはデータを管理する上で必要なカラムです。 417 | 418 | - lock_version 419 | - [楽観的ロック](https://qiita.com/qsona/items/01feada22c8f9fe17c7b) を実装する際に利用 420 | - [Ruby on Rails](http://rubyonrails.org/) ではこのカラムがあると楽観ロックを自動で行ってくれる 421 | - created_at 422 | - いつレコードが登録されたかを調査する際に利用する 423 | - updated_at 424 | - いつレコードが更新されたかを調査する際に利用する 425 | 426 | 場合によってはこれらのカラムがなくても成り立つケースもあるでしょう。 427 | 428 | その場合はこれらのカラムを無理に作成する必要はありません。 429 | 430 | 例えば仕様的にデータを貯めるだけのテーブルで更新が発生しないケースの場合は `lock_version` と `updated_at` は意味のないデータです。 431 | 432 | また全てのテーブルの主キーに `id` カラムを利用しています。 433 | 434 | これも [Ruby on Rails](http://rubyonrails.org/) を意識した作りです。 435 | 436 | 本カリキュラムでは [Ruby on Rails](http://rubyonrails.org/) を強く意識している為、このような構造になっています。 437 | 438 | 全テーブルの主キーを `id` にする手法は [SQLアンチパターン](https://www.amazon.co.jp/dp/4873115892) で [IDリクワイアド](https://qiita.com/fatomy/items/cf048fc0461224ddfbd7) と呼ばれるアンチパターンです。 439 | 440 | [Ruby on Rails](http://rubyonrails.org/) 等を利用しない場合はこれも避けたほうが良い設計です。 441 | 442 | このあたりは利用するフレームワークの規約等を見て最適な手法を取って頂ければと考えます。 443 | 444 | ## まとめ 445 | 446 | 長くなりましたが、要点は以下の3つになります。 447 | 448 | - 名前を省略しない 449 | - 適切なデータ型を利用する 450 | - 制約を適切に利用する 451 | - indexを適切に利用する 452 | 453 | この4点を徹底するだけでもかなり良いテーブル設計にする事が出来ます。 454 | 455 | データベースはプログラムよりも寿命が長く簡単に構造を変更する事は出来ません。 456 | 457 | 上達への近道はたくさん動くシステムを設計して慣れる事です。 458 | 459 | 良い設計が出来るようになるように常に意識しておきましょう。 460 | -------------------------------------------------------------------------------- /docs/tips/AntipatternOfLearningMethod.md: -------------------------------------------------------------------------------- 1 | # 学習方法のアンチパターン 2 | 3 | [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) では学習方法の具体例等を紹介しましたが、ここで紹介するのは逆にやってはいけない学習方法になります。 4 | 5 | 私の経験を元に書かせて頂きます。 6 | 7 | ## アンチパターンその1「暗記しようとする」 8 | 9 | プログラムの構文やLinuxコマンドのオプション等を暗記しようとする方法です。 10 | 11 | IT技術という物は日々進化していて、同じ言語でも新しい構文や関数等が次々に登場します。 12 | 13 | これらを全て暗記する事はまず不可能な上にそもそも意味がありません。 14 | 15 | エンジニアの仕事は技術による問題解決なので暗記する事よりも、持っている知識や技術をどう活かすかを考えるほうがはるかに重要です。 16 | 17 | 実際に現場のエンジニアでも全ての言語の構文を正確に記憶している人はまずいません。調べながら作るのが普通です。 18 | 19 | しかし知識がまったく0の状態だとそれはそれで困ります。なので、大事なのは暗記ではなく把握をする事です。 20 | 21 | 例えばJavaScriptには対象のHTMLを書き換える `innerHTML` というプロパティがあります。 22 | 23 | ```html 24 |

JavaScript

25 | ``` 26 | 27 | ```javascript 1.8 28 | document.getElementById('message').innerHTML = 'TypeScript'; 29 | ``` 30 | 31 | 暗記指向の考え方だと「innerHTMLはgetElementByIdで要素を選んで、値を代入して。覚えなくちゃ」となります。 32 | 33 | これは非常にマズイ考え方です。 34 | 35 | このような場面では、「JavaScriptはHTMLを書き換える事が出来る」という事実だけを把握すれば十分です。 36 | 37 | ちなみに、一度学習した事を何らかの形（GitHubとかブログ記事etc）でアウトプットする事はかなり有効です。 38 | 39 | 暗記等よりもはるかにその技術を自分の物に出来るでしょう。 40 | 41 | ## アンチパターンその2「まずは書籍から入る」 42 | 43 | 暗記と似た部分もあるのですが、まずは基礎理論からという思いで書籍を読む事から始める人が割と多くいます。 44 | 45 | しかしこれはかなり効率が悪いです。 46 | 47 | 書籍は体系的な知識が手に入るのである程度その技術をやった事がある人には有効な選択肢になります。 48 | 49 | しかし初心者はそもそも書籍を読む為に必要な前提知識が欠けているので読んでも理解出来ない事が多いです。 50 | 51 | それよりも最初はまずプログラミングレッスンの動画等を真似しながらやってみて、動くモノを一通り作れるようになってから書籍を読む事を推奨します。 52 | 53 | そのほうが圧倒的に学習効率が良いです。 54 | 55 | ## アンチパターンその3「完璧主義」 56 | 57 | 学習を進めていると、どこかでどうしても理解出来ない事が出てきたりします。 58 | 59 | しかし、最初のうちはあまり気にしないでさっさと動くものを作れるように一通りの工程を経験したほうが良いです。50点くらいの出来でも良いので一通り動くWebサービスを作ってみましょう。 60 | 61 | 理解ができない部分はとりあえず飛ばして、一通り学習を終わらせても最低限の技術しか身につかないのは事実です。 62 | 63 | しかし、一通り学習することで「スタートからゴールまでの流れや全体を把握すること」ができます。 64 | 65 | そうすると自分が分からなかったのはどういう部分だったのか、足りない部分はどの部分なのかが理解できるようになります。 66 | 67 | 「あとはこの部分が理解できればOK」という状態になります。 68 | 69 | それによって明確に自分の分からない部分を質問すること等が出来るようになります。 70 | 71 | その結果、学習がスムーズに進み、上達も早くなります。 72 | 73 | 「これが分からないうちは先に進んじゃダメだ」みたいな考え方で自分にブレーキをかけるのは非常にもったいないし、効率も良くないです。 74 | 75 | ## アンチパターンその4「手段の目的化」 76 | 77 | たまに勉強や学習でアプトプットする事自体が目的になっている人がいます。 78 | 79 | 趣味として技術を学ぶ事は悪い事じゃありません。むしろ良いことです。 80 | 81 | 「技術が好き」というのはそれだけで強力な武器になります。 82 | 83 | しかしこの記事を読んでいる方にも学習を進めようと思った動機があるハズです。 84 | 85 | - 世の中のある問題を解決したい 86 | - 作りたいWebサービスやアプリがある 87 | - 収入を上げたい 88 | - ブラックな労働環境から抜け出したい 89 | 90 | IT技術は問題解決の為の手段であるという事を忘れてはいけません。 91 | 92 | 「学んだ技術を何に活かすか」を常に考える事が重要です。 93 | 94 | ## アンチパターン5「安易に自己流に走る」 95 | 96 | IT技術は進化が早いですが、ベストプラクティスを他の優秀なエンジニアが既に発見しているケースも少なくありません。 97 | 98 | よってベストプラクティスが既に存在していないかを探す事から始めるのが基本となります。 99 | 100 | 例えば以下のようなケースです。 101 | 102 | - WebAPIのエラーフォーマットは [RFC-7807](https://tools.ietf.org/html/rfc7807) で提案されている 103 | - WebAPIを外部公開する際の認証・認可の仕組みは [OpenIDConnect](http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html) の仕組みを利用する 104 | - 各言語のコーディング規約やベストプラクティスに従う 105 | 106 | このような仕組みは様々な人間が議論した上で策定されている事が多いので、自分で0から考えるより遥かに効率が良いです。 107 | 108 | [守破離（しゅはり）](https://matome.naver.jp/odai/2135645674995970001) という言葉がありますがエンジニアの世界は守を大切にすべきだと私は考えます。 109 | 110 | 「守」とは標準規約や業界のベストプラクティスに従う事です。 111 | 112 | それらを意識する事で汎用的なスキルを身につける事が出来ます。 113 | 114 | 少しドキュメントを読んで分かった気になって我流で進めてしまうと重要なポイントを見逃すリスクがあります。 115 | 116 | 創造するという事はまず真似る事から始まります。技術に対してはいつでも謙虚な気持ちを忘れないようにしましょう。 117 | 118 | だからと言って権威主義に走るのはダメです。 119 | 120 | 「あの人が言ったから間違いない」というのは思考停止ですが「世界標準は何か」を探すのはエンジニアの流儀には反しません。 121 | 122 | ## アンチパターン6「頭の中だけで終わらせる」 123 | 124 | 技術は手を動かして初めて身につきます。 125 | 126 | 書籍とかネットの記事を読んで知識があっても、実際やると全く出来ない人はかなりいます。 127 | 128 | 頭で考えた通りに事が運ぶ事はまずありません。大抵は想定外の事が起こる物です。 129 | 130 | 考える事よりも手を動かす事を重視しましょう。 131 | 132 | Don't think. Take action. 133 | 134 | ## アンチパターン7「勉強会に参加する事を学習だと勘違いする」 135 | 136 | 勉強会への参加を学習と考えているのもアンチパターンです。 137 | 138 | ハンズオン等の手を動かす系であればまだマシですが、基本的に発表者の発表を聞くだけの勉強会は学習効果がほとんどありません。 139 | 140 | これは受け身で先生の授業を聞いているだけの座学がほとんど学習効果はない事と似ています。 141 | 142 | 技術というのは自分で手を動かして初めてみにつく物です。 143 | 144 | 座学形式でスピーカーの発表を聞いているだけの勉強会は学習効果が皆無です。 145 | 146 | 勉強会というよりは交流会の意味合いが強いでしょう。 147 | 148 | 勉強会に参加する際は以下の点を意識するようにしましょう。 149 | 150 | - 勉強会で得たインプットをただ聞いているだけでは意味がないので帰ったらその情報を活かすアウトプットを作る事 151 | - 交流会の意味あいで参加する場合は周りの参加者と会話してみて自分が現在どの程度のレベルなのかを把握するように務める事 152 | - 参加してみて特に得られる物がなさそうだったらさっさと帰って自分の学習をする事 153 | 154 | 勉強会後の懇親会が楽しみで勉強会通いをしている人がいますが個人的にはかなりのアンチパターンだと考えています。 155 | 156 | その時間を自分の学習に当てたほうが確実に力は付きますし、交流ばかりに力を入れて人脈だけあっても実力がないと意味がありません。 157 | 158 | 勉強会に否定的な意見を書きましたが、自身が勉強会で発表するのであればオススメです。 159 | 160 | 発表用のスライドをそのものが学習のアプトプットになるので学習効果は高いです。 161 | 162 | 交流会も全否定ではありません。 163 | 164 | それが縁で仕事をゲット出来る場合もありますし、一緒に学習する仲間が出来る可能性もありますのでたまに参加するなら良いでしょう。 165 | 166 | ## アンチパターン8「資格を取る事を学習だと勘違いする」 167 | 168 | これに関して良い記事があったので紹介します。 169 | 170 | まずは [ITエンジニアに資格は必要ない理由。勉強してる暇あったら発信しろ。](https://www.ryukke.com/?p=5418) という記事を見て下さい。 171 | 172 | 記事の主張をまとめると以下の通りです。 173 | 174 | - アウトプットをする事はインプットにもなる 175 | - 資格の費用対効果は薄い 176 | - 資格の勉強をするくらいならGitHubでコードを書いたほうが良い 177 | 178 | この記事、少々言葉は荒いですが、私は共感出来る内容だと感じました。 179 | 180 | 記事に載っていない事を補足すると、IT資格というのは基本的に暗記すれば合格出来るようになっています。 181 | 182 | `アンチパターンその1「暗記しようとする」` でも述べましたが、そもそも暗記自体がアンチパターンです。 183 | 184 | 機械が出来る事をわざわざ人間が頑張る必要はありません。（把握するレベルの事は必要ですが） 185 | 186 | 資格の勉強で得られるのは知識だけです。 187 | 188 | 「知識だけ」の状態と「実際に動く物を作れる」という状態は天と地ほど差があります。 189 | 190 | 資格はある種の権威になりますので権威主義者の中には資格に固執する人もいますが、個人的には完全にアンチパターンだと考えます。 191 | 192 | 資格の勉強をするくらいならGItHubでコードを書いたり、自作アプリを公開したほうが学習効果の面でも営業効果の面でも有効でしょう。 193 | 194 |

イケてるIT企業は、どこも、ITの資格なんてゴミだと思ってますよ。彼らがなによりも信じているのは、GitHubに公開されたソースコードです。ソースコード＝実力で、それ以外のものはゴタクです。 #peing #質問箱 https://t.co/6P2RJovnb6 pic.twitter.com/INFhmqnsBo

— ふろむだ🍀執筆中 (@fromdusktildawn) 2018年3月8日
195 | 196 |

中学卒業したばかりの15歳の女の子でも、GitHubに公開されたソースコードがすごかったら、年収800万で即採用するIT企業なんてたくさんある。GitHub採用主義というトレンドは、学歴偏重も性差別も年功序列も全てを吹き飛ばす究極に風通しのいい社会を創り出すすごい社会的イノベーションだと思う。

— ふろむだ🍀執筆中 (@fromdusktildawn) 2018年3月8日
197 | -------------------------------------------------------------------------------- /docs/tips/ChangeJobManual.md: -------------------------------------------------------------------------------- 1 | # 転職マニュアル 2 | 3 | ## この資料の目的 4 | 5 | 転職（フリーランスが新しい別の企業と契約する事も含む）の成功確率を少しでも上げる為のTipsです。 6 | 7 | ## 転職をすべきタイミング 8 | 9 | [学習方法のアンチパターン](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/AntipatternOfLearningMethod.md) でも触れましたが、終身雇用という考え方は既に幻想です。 10 | 11 | 一度も転職を経験しないで人生を終えるという事はまずないでしょう。（仮に出来たとしてもしないほうがいいです） 12 | 13 | 現在においては自分自身で稼ぐ力を身に着ける事が重要になります。 14 | 15 | 幸い、ITエンジニアは転職しやすい業種なのでやり方を間違えなければ、それなりに高い確率で転職を成功させる事が出来るでしょう。 16 | 17 | さて転職を決意するのはどのようなタイミングでしょうか。 18 | 19 | ざっと思いつくのは下記のようなところでしょうか。 20 | 21 | - 給料が安い 22 | - 残業が多い 23 | - 上司や同僚との人間関係の悪化 24 | - 自分が描いていたキャリアと会社からの要望の不一致（技術者志望で入ったのに外部委託エンジニアとの調整業務ばかりとか） 25 | 26 | 良くある理由を挙げてみました。 27 | 28 | どれにも共通するのは何かが嫌になって転職したいと決意した事です。 29 | 30 | 建前はともかくとして極論を言えば「嫌だから辞める」のです。 31 | 32 | この事実に関して何ら恥じる事はありません。 33 | 34 | 旧来の日本的な価値観が強い人は「石の上にも3年」という言葉を盾にして「3年は続けろ」みたいな言葉を使う人がいますが、これは企業側が都合良くこの言葉を利用しているに過ぎません。（企業が新卒社員の教育コストをペイ出来るのがだいたい3年と言われています） 35 | 36 | そもそもあなたの人生なので、やりたくもない事を必死に我慢する必要はありません。 37 | 38 | 嫌なら辞めてしまって少しでも待遇の良い環境に行こうと考えるのは当然なのです。 39 | 40 | ## 転職の際の心構え 41 | 42 | 以下は転職を行う際に私が意識している内容です。 43 | 44 | ### 求職者と企業は対等な関係であるという点を意識する 45 | 46 | 求職者と企業は対等な関係です。 47 | 48 | 旧来の日本的な考え方の人は求職者の立場だと「雇ってもらっているんだから」と考え、経営者の立場だと「雇ってやっている」と考えるようですがこれは誤りです。 49 | 50 | 企業側も事業を存続する為には人材協力が必要不可欠です。 51 | 52 | その為にわざわざ高いお金を払って求人広告を載せたりしているのです。 53 | 54 | 逆に求職者も自分の持つスキルを提供しその代価として賃金をもらっているに過ぎません。 55 | 56 | どちらかが、契約が果たせなくなったらその時は契約終了するだけです。それ以上でもそれ以下でもありません。 57 | 58 | よってどちらが下であるとかどちらが上であるという価値観はナンセンスです。 59 | 60 | 経営者側は専門家としてのスキルを信頼し、その人が能力を発揮出来るような環境を作っていく事が大切だと考えます。 61 | 62 | 上から目線で「うちの会社の方針は正しい、お前らが合わせろ」等と思っているような経営者のところでは働くべきではありません。 63 | 64 | 求職者は賃金に見合った価値を提供する義務がありますので、常に学習を怠らずに技術力を高め、 65 | エンジニアの本質である技術による問題解決能力を高める努力が必要です。 66 | 67 | これが出来ないのであれば、契約を解除されても文句は言えないと私は考えます。 68 | 69 | ### 相手に対して何を提供出来るかを意識する 70 | 71 | あなたが求職者だとしたら相手（企業や経営者）に対して何を提供出来るかを考える事が大事です。 72 | 73 | 例えばECサイトの運営を行っている会社なら以下のような点が考えられます。 74 | 75 | - インフラを自分が持つAWSのスキルでクラウド環境に置き換える事で運用コストと耐障害性を改善する 76 | - テストの自動化が行われていない環境であれば自分の持つテスト自動化スキルを活かしてテストを自動化してバグを軽減させる 77 | 78 | このように自分が持つスキルセットでどのような問題を解決出来るかを常に考えておく事が重要です。 79 | 80 | ### 転職対策の書籍は参考にしない 81 | 82 | 全ての書籍がダメとは言いませんが面接対策本のような書籍は正直何の役にも立たないと私は考えます。 83 | 84 | 例えば下記のような物ですね。 85 | 86 | http://kenjasyukatsu.com/mensetsu_situmon 87 | 88 | `自分を動物に例えると` とか意味不明です。そんな事聞いてどうするんでしょうか。 89 | 90 | 全体的に企業に媚びている印象が強いですが、そもそも求職者と企業は対等です。 91 | 92 | 全ての面接対策本がそうだと断言する事は出来ませんが、面接対策本は極めて社畜的な思想が色濃く出ているのが特徴でエンジニアの立場では全く参考になりません。 93 | 94 | ※　私が考える社畜に関しては [こちら](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/Shachiku.md) に定義があります。 95 | 96 | 「私はこういう事が出来ます。あなたには私を雇う事でこのようなメリットがあります」という事が伝えられれば十分です。 97 | 98 | ### どのようなエンジニアが求められているかを意識する 99 | 100 | 私が考える世界で求められるエンジニア像は下記の通りです。 101 | 102 | - 自ら思考する能力があり問題解決の為に柔軟な思考を働かせる事が出来る 103 | - [技術者としてスポンジであり続けること](http://blog.toshimaru.net/like-a-sponge-as-an-engineer/) に書いてあるような常に技術に対して謙虚で学ぶ姿勢を忘れない人（誰に対してもフラットな態度というのもポイント） 104 | - 責任感がある人（責任を取って辞めるとかナンセンスな責任の取り方ではなく単純に最後まで自分が言った事をやり遂げられる人） 105 | 106 | 自分がこれらの条件を満たしているかは常に意識し続ける事が大事です。 107 | 108 | ### 落ちても気にしない 109 | 110 | 面接や試験の結果、採用に至らず落ちてしまう事は当然あります。 111 | 112 | しかし必要以上に悩まないほうが良いです。 113 | 114 | 先程も書きましたが求職者と企業は対等な関係です。 115 | 116 | 求職者が企業を選ぶ権利があるように企業側にも採用する人を選ぶ権利があります。 117 | 118 | また金額面等の条件が合わない事も多々ありますので、落ちたという事は合わなかったというだけで、あなたの能力が否定されて訳ではありません。 119 | 120 | 極端な例を挙げると、旧来の日本的な価値観を重視する企業でここに書いてある方針で面接を受けるとまず確実に落ちるでしょう。 121 | 122 | しかしそんな企業で働きたいと思わないので別に何ら問題はないという事です。 123 | 124 | 落ちた時はこのように単に自分に合わなかったと考えるのが良いです。 125 | 我慢して自分を殺してその企業に入っても後からもっと辛い事になるのはあなた自身です。 126 | 127 | ### 転職エージェントには注意 128 | 129 | 私は転職エージェントを利用した事がないのですが、利用した人に話を聞くと良くない話も結構聞きます。 130 | 131 | 彼・彼女達は基本的に営利団体なので求職者を企業に紹介する事で利益を得ています。 132 | 133 | よって求職者の立場だけを考えて行動している訳ではない点に注意しましょう。 134 | 135 | どうしても転職エージェントを利用したければITに強い転職エージェントを利用する事を強く推奨します。IT知識が皆無なエージェントにまともなやり取りが出来るとは思えません。 136 | 137 | - [ワークポート](https://www.workport.co.jp/) 138 | - [Geekly](https://www.geekly.co.jp/) 139 | 140 | また下記のようにネットで探せるサービスもあるのでこちらもオススメ出来ます。 141 | 142 | - [Green](https://www.green-japan.com/) 143 | - [Find Job](https://www.find-job.net/) 144 | 145 | ## 転職に期待してはいけない事 146 | 147 | 以下のような事は転職に期待するべきではありません。 148 | 149 | ### この会社に入ったら人生安泰だと考える 150 | 151 | これはかなり危険な考え方です。 152 | 153 | 会社と自分を切り離せていないのは社畜思想の始まりだし、さらに言うとどんな会社でも倒産の可能性があります。 154 | 155 | 仮に自分が生きている間潰れなかったとしても自分が最後まで残れるという保証はありません。 156 | 157 | ※ このカリキュラムを読んでいる人はこのように考える人はいないとは考えますが、念の為書かせて頂きました。 158 | 159 | ### 自分の要望は全て満たされる 160 | 161 | 転職を行ったからと言って自分の要望が全て満たされると考えるのは危険です。 162 | 163 | 求職者には求職者の事情があるように企業には企業の事情があります。 164 | 165 | よって前の職場より悪化する点が出て来る事も少なくありません。 166 | 167 | 完璧な人間が存在しないのと同じで完璧な企業も存在しないのです。 168 | 169 | そもそも大事なのは自分自身の力で稼ぐ事が出来る能力を身につける事です。 170 | 171 | それが身につくまでの間は妥協する事も時には必要です。 172 | 173 | 自分が絶対に譲れないという条件とこれなら妥協出来るという条件を書き出しておきましょう。 174 | 175 | 自分が絶対に譲れないという条件があまりにも多い場合は企業で正社員として働く事は難しいでしょう。 176 | 177 | その場合はフリーランスや起業をオススメします。 178 | 179 | ※ 私のオススメはどちらかと言うとフリーランスや起業です。 180 | 181 | 最近 [転職ドラフトで1000万円超えのオファーを2度貰ったエンジニアが「評価された理由」と「正社員で働く意味」について考えてみました。](https://qiita.com/poly_soft/items/a6db13a6e18efc1e7db8) という良い記事を見つけました。 182 | 183 | ここに書いてある通り、日本は正社員エンジニアの待遇が低くなりがちなので、ある程度の実力があればフリーランスが良いと私も同意します。 184 | 185 | しかし正社員で働くメリット（有休・産休・育休とか）もあるので、どちらが良いかは個人の価値観によるでしょう。 186 | 187 | ## 職務経歴書の書き方 188 | 189 | ### 管理方法 190 | 191 | 職務経歴書はGitHubで管理を行う事をオススメします。 192 | 193 | 正確に言うとGitHubである必要はないのですが、必要な人には公開出来るようにしておく事が重要です。 194 | 195 | 定期的に最新状態にアップデートしておく事も大事です。 196 | 197 | - [職務経歴書をGitHubに公開するのはいいぞ](http://okoysm.hatenablog.jp/entry/2016/12/19/060000) 198 | 199 | ただし私は全世界に自分の氏名や生年月日等が常に公開される事に抵抗がある人間です。 200 | 201 | よって https://gist.github.com のsecret gistを利用しています。 202 | 203 | これなら検索にヒットしないし、必要な人間だけにURLを共有するだけで情報共有が可能です。 204 | 205 | GitHub管理の他には [LinkedIn](https://jp.linkedin.com/) のようなサービスを使う事もオススメです。 206 | 207 | ### 文書形式 208 | 209 | GitHubで管理するならマークダウン形式がオススメです。 210 | 211 | WordとかExcelとかは極力触りたくないですし管理もやりにくいのでマークダウンの一択で良いでしょう。 212 | 213 | ### 内容について 214 | 215 | 下記のようなテンプレートを参考にすると良いでしょう。 216 | 217 | - https://github.com/okoysm/Curriculum-Vitae-template 218 | - https://dev.classmethod.jp/etc/curriculum-vitae-oss/ 219 | - https://github.com/Sa2Knight/Curriculum-Vitae 220 | 221 | どのような情報を載せるかについてですが、私は下記のような情報が乗っていれば十分だと考えます。 222 | 223 | - 名前（ネット上のハンドルネームも可） 224 | - GitHub、Qiita、Twitter等のアカウント 225 | - 職務経歴 226 | 227 | 生年月日、住所、学歴等の仕事に直接関係のない資料に関しては、載せる必要はないと考えます。 228 | 229 | ### 昔ながらの履歴書とか職務経歴書のフォーマットを求められる場合はどうしたら良いか 230 | 231 | GitHubのページを印刷するくらいはやってもいいですが（本当は印刷すらしたくないけど）それ以上の事はしなくても良いでしょう。 232 | 233 | そのような古いフォーマットを強要してくる企業は柔軟性に欠け、入社してもその会社でしか通用しないようなローカルルールを強制させる可能性が極めて高いです。 234 | 235 | このようにGitHubで管理した職務経歴書を受け入れるかどうかも柔軟性がある企業を見極める1つの指標となります。 236 | 237 | ### 可能であれば英語版を用意しておく 238 | 239 | 仮に日本の会社で働くにしてもグローバル化が進んでいく流れは避けられないので、英語版の経歴書も用意しておきましょう。 240 | 241 | ## 履歴書の書き方 242 | 243 | [Wantedly](https://www.wantedly.com/resume) を使うのがオススメです。 244 | 245 | 書く内容に関しては今までの自分の経歴を素直に書けば良いでしょう。 246 | 247 | 履歴書に関してはさほど重要ではないのであまり時間をかけないようにしましょう。 248 | 249 | ## アウトプットの重要性 250 | 251 | 職務経歴書や履歴書よりも圧倒的に重要なのは今まで作ってきたアウトプットです。 252 | 253 | 雇用する側からすると職務経歴書や履歴書はいくらでも嘘を書けるがアウトプットは普段の積み重ねが必要なので相手の実力・情熱をより正確に判定が出来るからです。 254 | 255 | アウトプットには下記のような物があります。 256 | 257 | ### GitHub上に公開したコード 258 | 259 | [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) でも書いたようにGitHub上でコードを公開する事は学習効果が大きいので非常にオススメです。 260 | 261 | GitHub上に公開出来る物としては以下のような物があります。 262 | 263 | - [paiza](https://paiza.jp/) で書いたアルゴリズムのコード 264 | - [ドットインストール](https://dotinstall.com/) 等で作成した成果物 265 | - 自作したオープンソースのライブラリ 266 | 267 | もちろん上記以外の物でも構いません。 268 | 269 | ただし [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) に記載してあるように普段から高品質なコードを書くように心がけましょう。（難しいアルゴリズムしか書いたらダメとかそういう事ではない） 270 | 271 | 適当なコードを書いているとマイナスに受け取られ書類審査で落ちてしまう可能性をかえって高めてしまう場合もあります。 272 | 273 | [意外！IT転職の職務経歴書にGitHubを載せない方が良い3つの理由](https://tenshoku-seikou.jp/github/) 274 | 275 | 余談ですが、最近は履歴書や職務経歴書よりもGitHubのアカウントで審査を行う「GitHub採用」を行う企業も出てきています。 276 | 277 | - [GitHub採用をしている企業まとめ](https://matome.naver.jp/odai/2150981068141527301) 278 | 279 | ### Qiitaやブログの記事 280 | 281 | GitHubと同じくこちらも重要なアウトプットです。 282 | 283 | GitHubにも同じ事が言えますが急に用意しようと思っても出来ないので普段の積み重ねが重要になります。 284 | 285 | [IT転職成功への近道！応募書類にQiitaを載せると受かりやすい3つの理由](https://tenshoku-seikou.jp/qiita/) 286 | 287 | ### 自分で作ったWebサービスやアプリ 288 | 289 | これらを持っていれば少なくとも1つのサービスを1人で作成したという何よりの証明になるので、持っていたら是非とも職務経歴書にリンクを追加したいところです。 290 | 291 | ### その他 292 | 293 | その他には [SlideShare](https://www.slideshare.net/) 等で作成した勉強会の資料等があります。 294 | 295 | これらの点から言えるのはアウトプットを普段から外の世界に公開しておく事が非常に大事だと言えます。 296 | 297 | 下記のようなメリットもあるので学習効果の面でも非常に有効な方法です。 298 | 299 | - 外部公開する事でネットの向こう側にいる優秀なエンジニアの意見を貰える 300 | - 「外部に晒すからいい加減な情報は出せない」という意識が働きアウトプットの品質が向上する 301 | - アウトプットの品質が向上するという事はより深い技術を身につける事が出来る 302 | 303 | ## 転職活動、特に面接時におけるアンチパターン 304 | 305 | 以下のような事は転職時にやってはいけない事です。 306 | 307 | ### 企業に媚びる 308 | 309 | 思ってもいないようなお世辞を言ったり、必要以上に企業を褒めるような行為をする必要はありません。 310 | 311 | 先程から何度も書いていますが、求職者と企業は対等な関係です。 312 | 313 | 求職者がやる事は面接官や企業に媚を売る事ではなく、「自分を雇うとあなたにはこういうメリットがありますよ」と伝える事です。 314 | 315 | 目的を間違えないようにしましょう。 316 | 317 | ### 必要以上に自己アピールに必死になる 318 | 319 | 正確には自己アピールをする事自体がダメという訳ではありません。 320 | 321 | 「自分を雇うとあなたにはこういうメリットがありますよ」という点を強調するのはOKです。 322 | 323 | しかし「頑張ります」とか「根性なら誰にも負けません」のような精神論的なアピールは絶対に避けるべきです。 324 | 325 | これらの言葉は社畜思想のブラック企業が最も好みますので誤ってブラック企業に入ってしまう危険性を秘めています。 326 | 327 | それに「頑張ります」とか「根性なら誰にも負けません」とかは要するに思考を放棄しているのと同じです。 328 | 329 | エンジニアに必要なのはこのような精神論ではなく問題解決を出来る論理的な思考能力です。 330 | 331 | それを自ら否定するようなアピールは絶対に避けましょう。 332 | 333 | ### アプトプットの目的が自己アピール一辺倒になる 334 | 335 | アピール目的でアウトプットを作り出すようになってくると目的を見失っていると言えるでしょう。 336 | 337 | 真に重要な事は今この転職を成功させる事ではなく、自らのスキルを高め特定の組織に依存しなくても稼げるようになる事です。 338 | 339 | スキルを磨く事を怠らなければ、どこでも活躍出来る人材になりますしそれを目指す事こそが重要と私は考えます。 340 | 341 | ### 出来もしない事を出来ると言う 342 | 343 | 後でトラブルになるので絶対にやめるべきです。 344 | 345 | 出来ない事は出来ないとハッキリ言いましょう。 346 | 347 | ## 質問への返答例 348 | 349 | 良く聞かれそうな質問に対する回答例と回答のポイントを記載します。 350 | 351 | ### 転職理由 352 | 353 | 私なら例えばこう答えます。 354 | 355 | >前職ではエンジニア志望で入ったのですが、実際に開発をガッツリ出来たのは最初の1年だけで後は調整業務に回されてしまいました。 356 | 私にはフルスタックエンジニアになり、エンジニアとして独立したいという目標があるので、このままではその目標を達成出来ないと思い転職を決意しました。 357 | 358 | ポイントは自分には目標があり、その為に自分がやりたい事と会社が望む方向性に不一致があるという事を伝える事です。（要約すると嫌だから辞めるなんですけどね） 359 | 360 | ただ単に嫌だからと感情だけを伝えるのではなく、論理的に答える事が重要です。 361 | 362 | 何故ならエンジニアとって論理的な思考能力はもっとも大切な事の1つだからです。 363 | 364 | ### 志望動機 365 | 366 | 「同業他社の中から何故、弊社を選びましたか」みたいな質問です。 367 | 368 | これに関しては同業他社と比較して志望する企業に自分が感じるメリットを伝えればOKです。 369 | 370 | >フルスタックエンジニアになり、エンジニアとして独立するという目標があるので、御社のような新規の自社サービスを次々と立ち上げているような企業が望ましいと考えたからです。 371 | 同業他社でもここまで幅広いサービスを行っている企業は私が知る限りないと考えたので御社を志望しました。 372 | また、御社はリモートワーク等の働き方の多様性を認めているので学習や自分のサービス開発に当てる時間も確保出来そうだと言うのも魅力的でした。 373 | 374 | こんな感じでしょうか。 375 | 376 | この段階では「私を雇うとあなたにこういうメリットがありますよ」という点に関しては触れる必要はありません。 377 | 378 | ### うちの会社に入って何をしたいか 379 | 380 | これも良く聞かれるパターンですね。 381 | 382 | ここで企業側が聞きたい事は主に以下の2つです。 383 | 384 | - 求職者を雇用した場合どのようなメリットがあるか 385 | - 求職者がどのような分野に興味があるか（配属場所の検討をする為という意味あいが強い） 386 | 387 | そこで、ここでは以下のように自分を雇った時にメリットを踏まえて伝えるのが良いでしょう。 388 | 389 | >新規サービスの開発を行い、新技術の導入等を進めたいと思っております。 390 | 私はCIツールを用いたテストの自動化経験やスクラムマスターの経験があるので、そのような面で貢献出来ると考えています。 391 | 392 | 自分の要望を言っておく事は非常に大切です。 393 | 394 | ここで「何でもやります」みたいに答えると誰もやりたがらない人が足りていないだけの部署に回されてしまう危険性がありますのでしっかりと要望を伝えましょう。 395 | 396 | ### 失敗の経験 397 | 398 | どのような失敗をした事があるかという質問です。 399 | 400 | ここで企業側が知りたいのは下記のような項目です。 401 | 402 | - 失敗から何を学んでいるか 403 | - 失敗の原因を論理的かつ客観的に分析出来ているか 404 | 405 | 例えば下記のような回答例です。 406 | 407 | >旧システムのリプレイス案件（プロジェクト期間が1年くらい）を行った時の話です。 408 | 開発は順調に進んだのですが、旧DBのテーブルから新DBのテーブルにデータを移行するところで、新テーブルの構造上どうしても移行が難しいデータが出てきてしまい、スケジュールの遅延を余儀なくされました。 409 | 失敗の原因はデータ移行を楽観視していた事と新システムを作り上げてからデータコンバーターを作るというウォーターフォール的な考えをしてしまっていた事だと思っています。 410 | それ以降はアジャイルの原則に則り技術的なリスクが高い課題はなるべく早めに問題を発見する為に開発から統合テストまでの流れを短いイテレーション毎に繰り返す手法を徹底するようにしています。 411 | 412 | ### 今後のキャリアプランについて 413 | 414 | 「うちの会社に入って何をしたいか」と似ていますが、この場合は会社の枠に囚われず、自分が目指すべき最終系を答えれば良いでしょう。 415 | 416 | >フルスタックエンジニアになりエンジニアとして独立したいです。 417 | 独立後は自社サービスを立ち上げ事業化を目指しながら、業務委託での開発も平行して行っていきたいです。その際には自分が興味のある◯◯分野での開発を中心に行っていきたいです。 418 | 419 | ### 技術的な質問に対する回答 420 | 421 | 何を聞かれるかは正直その企業の面接官によるのですが、私が考えた質問をいくつか書いておきます。 422 | 423 | この記事を読んでいるあなたなりの答えを考えてみましょう。 424 | 425 | - 質問1 426 | 427 | >オブジェクト指向における設計に関してあたなの基準を教えて下さい。 428 | クラス・メソッドはそれぞれ何行くらいの大きさまで許容出来ますか？ 429 | またメソッドの引数は何個まで許容出来ますか？ 430 | それぞれ理由を交えて教えて下さい。 431 | 432 | - 質問2 433 | 434 | >この業界は技術進歩が早くある技術が流行っていても1年もすれば廃れている事も珍しくありません。このような状況ですがシステムアーキテクトを設計する場合、あなたはどのような点に気をつけて設計を行いますか？ 435 | 436 | - 質問3 437 | 438 | >長い間、オブジェクト指向がメインでしたが最近は関数型のプログラミングが見直されていると感じます。 439 | その理由についてはどのように考えますか？ 440 | またあなたが関数型のパラダイムを取り入れる場合はどのような状況を想定しますか？ 441 | 442 | - 質問4 443 | 444 | >静的型付け言語と動的型付け言語はそれぞれメリット・デメリットがありますが、あなたはこれらをそれぞれどのような状況で使い分けますか？ 445 | 446 | 初めに言っておくとこれらの質問には明確な答えはありません。（明らかな間違いはありますが） 447 | 448 | これらの質問を通じて知りたいのはあなたが技術に対して、掘り下げて考える事が出来るかどうかを問いています。 449 | 450 | 分からない場合はメンターに相談しても良いので自分なりの答えを考えて文章にしてみましょう。 451 | 452 | ## 企業に行うべき質問 453 | 454 | 以下の質問は最低限聞いておくべきでしょう。 455 | 456 | ### 給与・評価制度について 457 | 458 | 最重要なので必ず聞きましょう。 459 | 460 | >御社の評価制度はどのような仕組みで、どのような人が高く評価されているのでしょうか？ 461 | また昇給率はどの程度でしょうか？ 462 | 463 | 給与もそうですが評価制度も大事です。 464 | 465 | ここが曖昧だと入ってから不当な評価を受ける可能性があるのでしっかり聞いておきましょう。 466 | 467 | ### 残業の有無 468 | 469 | これも重要です。遠慮せずに必ず聞きましょう。 470 | 471 | >個人サービスや技術の学習をする時間が確保したいので、残業がどのくらいあるか知りたいです。 472 | 473 | はっきりと答えなかった場合はまず間違いなく残業まみれになると考えていいでしょう。 474 | 475 | ### 技術的な環境について 476 | 477 | 利用言語やミドルウェア等をしっかり確認しましょう。 478 | 479 | 個人的にはAWS等のサービスを使っている事は必須だと考えます。 480 | 481 | オンプレミスサーバの場合、ネットワークエンジニアとの社内調整が多くその部分で疲弊してしまいます。 482 | 483 | コードを書くだけでなくミドルウェアのチューニングまで含めて担当出来る環境かをしっかりと確認しましょう。 484 | 485 | ※ 現在クラウドサービスを使っていなくても、これから導入予定、または現在導入を進めているという事であれば検討するのもアリだと考えます。 486 | 487 | ### その他質問すべき事 488 | 489 | 他にも気になった点はどんどん質問しましょう。 490 | 491 | 遠慮して聞かないのは絶対NGです。 492 | 493 | 求職者と企業の関係はあくまで対等です。 494 | 495 | 企業が誰を採用するかを選ぶ権利があるように求職者にもどの企業に入るか選択する権利があります。 496 | 497 | しっかりと確認して後悔のない転職を目指しましょう。 498 | 499 | ### 質問すべき事の補足 500 | 501 | 最近、[就活で採用者がマイナス評価する､｢NG質問｣](http://toyokeizai.net/articles/-/207832) というアンチパターン記事を偶然見つけました。 502 | 503 | この記事には勤務地や職種、福利厚生の質問はNGだと記載があります。 504 | 505 | 前提として先程から何度も書いている求職者と企業は対等だという当たり前の事が全く意識出来ていません。 506 | 507 | どんな企業に質問したのかは分かりませんが、このような考えを持つ企業こそ最も選んではいけない企業だと私は考えます。 508 | 509 | 私は読んでいて不愉快な気持ちになりましたが、旧来の日本的な企業とはこういう考え方をするんだという点では参考になりました。 510 | 511 | ## 技術試験対策 512 | 513 | 簡単なプログラムのテストをする企業もあります。 514 | 515 | 割と技術を重視しているような有名企業でもなかったり、そうでもない企業なのにあったりするので、これがあるかどうかはその企業次第でしょう。 516 | 517 | 技術試験では主に以下のような物があります。 518 | 519 | ### アルゴリズムのテスト 520 | 521 | バイナリサーチ等の検索アルゴリズムやクイックソート等のソートアルゴリズムを実装するパターンです。 522 | 523 | またデータベースに接続する実戦的なプログラムを書くような場合もあります。 524 | 525 | 出題形式は企業によって様々です。 526 | 527 | 紙に書くところもあれば、PC持参で制限時間内に解くみたいなことろもあります。（事前に解いてくるみたいなパターンもありますね） 528 | 529 | 私は紙に書くパターンを経験した事があります。 530 | 531 | 基本的なアルゴリズムを練習しておくと良いでしょう。 532 | 533 | ### コードレビューを行う 534 | 535 | 企業側から問題があるコードを渡されて、制限時間内にコードレビューを行わせるパターンです。 536 | 537 | コードに対してどのような考え方を持っているかと、基本的なコーディング作法を知っているかの確認を行う事が目的です。 538 | 539 | 私は未経験ですが、結構面白い取り組みだと感じています。 540 | 541 | - [エンジニアの面接でコードレビューさせてる](https://anond.hatelabo.jp/20141009020104) 542 | 543 | 対策としては [リーダブルコード](https://www.amazon.co.jp/dp/4873115655) に載っているようなコーディングテクニックを地道に身に着けておくしかないでしょう。 544 | 545 | ### 技術試験対策まとめ 546 | 547 | 私が知っている限りでは、上記の2つがメインだと感じます。 548 | 549 | 求職者がコードレビューを行っているところは、2、3社程聞いた事がある程度なので、あるとしたらアルゴリズムの試験が一番多いのかなという印象です。 550 | 551 | こればっかりは蓋を開けてみないと何とも言えないので、普段から学習を地道に行っておく以外に対策はないと考えます。 552 | 553 | ## 避けたほうが良い企業の特徴 554 | 555 | ### 面接での質問内容が不適切な企業 556 | 557 | 面接でされた質問内容を分析し、これを聞かれたらその企業は辞めたほうが良いという質問をまとめました。 558 | 559 | #### 圧迫面接 560 | 561 | http://kenjasyukatsu.com/archives/402 562 | 563 | こちらの記事によると下記のような理由だそうです。 564 | 565 | ちなみにこれは新卒の面接向けの記事ですが中途採用でも圧迫面接をする企業はあります。 566 | 567 | >具体的な対策のポイントに入る前に、「なぜ企業は圧迫面接をするのか」を考えてみましょう。 568 | 企業が圧迫面接をするのは、「学生のストレス耐性を試すため」です。 569 | 最近、若者がすぐ辞める、と問題になっていますよね。いくら優秀でも、ストレス耐性がなく、すぐに会社を辞められたり、無気力化されては困ります。 570 | だから、企業はあえて学生にストレスを与え、学生がストレス状況に上手く適応し、対処できるかを試すのです。 571 | つまり、学生のストレス耐性を見るために、面接官は、あえて圧迫的な、高圧的な振る舞いをしているのですね。圧迫的な対応をしてくるのは、単にそういう形式の面接だからで、あなたが悪いのではありません。 572 | だから、こちらも「圧迫に屈さず、普段通りに回答する」だけで良いのです。そうすれば、ストレスに負けない人間だと評価を得られます。 573 | 574 | 一般的にも「ストレス耐性を見る」と言われていますね。 575 | 576 | しかし良く考えてみて下さい。 577 | 578 | ストレス耐性を見るという事は「入社後、毎日あなたにストレスを与えますよ」と言っているようなものです。 579 | 580 | こんな企業で働くメリットは、はっきり言って何もありません。（社畜根性は着くかもですがそんな物はいらないので） 581 | 582 | なので、正解は一刻も早くその面接を切り上げて帰宅する事です。 583 | 584 | 下記のようにでも言ってその場を立ち去りましょう。 585 | 586 | >圧迫面接ですか。 587 | 申し訳ありませんが圧迫面接のような行為をするような人たちと一緒に働きたくありません。 588 | もう面接は結構ですので帰らせて頂きます。 589 | 590 | 圧迫面接は明確な悪です。 591 | 592 | いかなる理由があっても許されないと私は考えます。 593 | 594 | このような企業で働くのは絶対に避けましょう。 595 | 596 | 圧迫面接の基準ですが感じ方は人によってそれぞれなので、一応、圧迫面接の例を載せておきます。 597 | 598 | https://kimisuka.com/contents/column/2513 599 | 600 | ここに色々例が載っていますが、ぶっちゃけ本人が嫌だと感じたらそれは圧迫面接になるので、その場合はその場を速やかに立ち去るのが正解です。 601 | 602 | 圧迫面接のような非人道的な行いをするような非常識な企業にあなたの貴重な時間をあげる必要はありません。 603 | 604 | #### 残業はどのくらい出来ますか 605 | 606 | これを聞いてくる企業は基本的に残業させるつもりなので辞めたほうが良いです。 607 | 608 | 残業前提で考えている企業は非効率的で無駄が多く、意味不明なローカルルールばかりのタコツボ的な組織である事が多いので避けたほうが良いです。 609 | 610 | エンジニアは技術が資本なので残業によってスキルアップをする時間がなくなる事は絶対に避けなければいけません。 611 | 612 | #### 抽象的な質問 613 | 614 | 抽象的な質問は何故ダメかと言うとその企業が正確に人を評価出来ない可能性が疑われるからです。 615 | 616 | これは私個人の主観が入りますが、以下のような質問は抽象的な質問だと考えます。 617 | 618 | - あなたの長所は何ですか 619 | - あなたの短所は何ですか 620 | - 好きな言葉・座右の銘（モットー）は何ですか 621 | 622 | >あなたの長所は何ですか 623 | 624 | >あなたの短所は何ですか 625 | 626 | 志望動機とか技術的な質問をやり取りした後でこんな質問が出て来るようだと人を見る目がないのかなと感じます。 627 | 628 | >好きな言葉・座右の銘（モットー）は何ですか 629 | 630 | これも似たような理由ですが、抽象的過ぎますね。 631 | 632 | これを聞くという事は求職者のアウトプットからその人の大切にしている事は何なのかを推測出来ていないという事です。 633 | 634 | アプトプットや業務経験からその人の強みや趣向が分からないようでは、社内評価も曖昧で単に上司と仲がいい等の理由で評価を決めている可能性が疑われます。 635 | 636 | このような企業は避けたほうが良いでしょう。 637 | 638 | 聞くならこういう聞き方をして欲しいところです。 639 | 640 | >あなたのRSpecのテストコードを拝見しましたが、非常に良く書けていたと感じました。あなたはテストを書くのが得意ですか？ 641 | 642 | このような聞き方であれば提出したアウトプットに目を通しているという裏付けになるし、こちらも安心出来ます。 643 | 644 | ### 会社ホームページに闇を感じる 645 | 646 | 経営者のサクセスストーリーが漫画になっていたり、やたらと経営者が全面に押し出されている企業はワンマン企業の可能性が非常に高いです。 647 | 648 | ワンマン企業は経営者の周りに腰巾着系の社畜が群がっていて、経営者に気に入られた人だけが優遇される傾向が強いです。 649 | 650 | そのような企業は辞めたほうが良いでしょう。 651 | 652 | また会社の文化というかサークル活動的なノリを全面的に押し出しているケースも避けたほうが良いでしょう。 653 | 654 | 宗教的なノリで意味不明な社内イベントへの参加を強要させられるリスクがあるからです。 655 | 656 | ### 価値観を押し付けてくる企業 657 | 658 | 価値観の押し付けを行ってくる企業も避けたほうが良いです。 659 | 660 | 企業理念とか企業文化という物はあっても良いですが、人に強制的に押し付ける物ではありません。 661 | 662 | その文化が開発者の自主性を重んじていたり、風通しの良さを感じさせる内容であれば良いです。 663 | 664 | しかし、押し付けを行ってくる企業の文化は大抵その会社でしか役に立たない固有の価値観である事が多いです。 665 | 666 | 例えば朝礼で社訓を読ませるような企業や社訓に関して考えると称して意味不明なMTGを定期的に開催している企業は避けるべきでしょう。 667 | 668 |

ブラック企業と言うのは低賃金、高残業などの待遇面だけではありません。

短観的な物の見方を押し付け、社員を世間知らずにして見えない鎖に繋ぐやり方もあります。

自分の手綱を自分で持てない会社も十分ブラック体質です。社員なのだから会社の方針に完全に従えと言うのは、ただの奴隷契約です。

— 金子 周平 (@skaneko414) 2018年4月30日
669 | 670 |

@kimutakura 私の経験では生産性を発揮させるのに有効なのは強制ではなく自由です。規範は必要なこともあるでしょうが、あくまでも自発的なものです。

— Yukihiro Matsumoto (@yukihiro_matz) 2010年9月15日
671 | 672 | ### 避けたほうが良い企業まとめ 673 | 674 | 正直正確に判定するのはかなり難しいです。 675 | 676 | 求職者も人を見る目を養っておく事が大切になります。 677 | 678 | 当たり前ですが「あなたはブラック企業ですか」と聞いて「はい。そうです」と答える企業はいません。 679 | 680 | 面接官の言動、企業のホームページ、転職会議等のサイトの評判を総合的に判断して自分に合った企業を探すしかありません。 681 | 682 | 下記の2つは会員登録を行い、対象の会社をリサーチしておきましょう。 683 | 684 | - https://jobtalk.jp/ 685 | - https://www.vorkers.com/ 686 | 687 | #### 2018-02-13追記 688 | 689 | 最近、参考になる記事を見つけたので載せておきます。 690 | 691 | - [エンジニアが転職する時に必ずチェックしたい募集要項(2017年版) 692 | ](https://findy-code.io/engineer-lab/tenshoku-bosyu-yoko-2017) 693 | - [絶対にエンジニアが転職してはいけない会社の募集要項](https://findy-code.io/engineer-lab/tenshoku-ng-jd) 694 | 695 | この記事を書いている [Findy](https://findy-code.io/) という会社はGitHubアカウントを審査してエンジニアに転職先を紹介している面白いサービスです。 696 | -------------------------------------------------------------------------------- /docs/tips/CreateDevelopmentEnvOnMac.md: -------------------------------------------------------------------------------- 1 | # Macで開発環境を構築する 2 | 3 | ## この記事の目的 4 | 5 | 本カリキュラムを進める上ではMacOSを推奨していますが、場合によってはMacを触るのが初めての人もいると思うのでここに最低限開発において用意しておいたほうが良いツール等を記載しておきます。 6 | 7 | なおここにある内容は強制ではなく、慣れてきたら自分好みの開発PCにカスタマイズして行くのが良いと思います。 8 | 9 | ## Command Line Tools 10 | 11 | 後述のパッケージマネージャー「Homebrew」の動作にも必要なため、必ずインストールします。 12 | 13 | ターミナルを開いて以下のコマンドを実行して下さい。 14 | 15 | `xcode-select --install` 16 | 17 | ## Homebrew 18 | 19 | Mac用のパッケージマネージャーです。 20 | 21 | 開発ツールをインストールする時に必須です。 22 | 23 | インストール方法は [公式サイト](https://brew.sh/index_ja.html) を見れば簡単に分かるのでここでは割愛させて頂きます。 24 | 25 | ※ Homebrewに関して詳しい解説が載っている記事がありますのでこちらに記載させて頂きました。 26 | 27 | https://qiita.com/omega999/items/6f65217b81ad3fffe7e6 28 | 29 | ## テキストエディタ 30 | 31 | 私の個人的なオススメは [Atom](https://atom.io/) です。 32 | 33 | github社が開発したエディタで各種Pluginを駆使すれば、最新の言語仕様にも対応しています。 34 | 35 | 欠点を上げれば少々起動が重い事ですが最近のPCは性能も上がっているのでそれほど気になりません。 36 | 37 | [こちらの記事](https://eng-entrance.com/free-texteditor-mac-2) にMacでのオススメエディタが載っていますので参考にするのも良いでしょう。 38 | 39 | ## Gitクライアント 40 | 41 | コマンドでのgit操作に十分に慣れてしまえば不要な気もしますが、初心者のうちはGitクライアントを入れておくと良いでしょう。 42 | 43 | 私のオススメは [Sourcetree](https://ja.atlassian.com/software/sourcetree) です。 44 | 45 | Atlassianという会社が作成していて同社のbitbucketやgithubとの連携も出来るので使いやすいです。 46 | 47 | ただ [Sourcetree](https://ja.atlassian.com/software/sourcetree) のようなツールを使う場合でも裏でどのようなGitコマンドが使われているかは理解するようにしておいたほうが良いです。 48 | 49 | gitは現在の開発においては必須なので、少しづつで良いのでgitその物を理解するように知識を蓄積していく事を強く推奨します。 50 | 51 | 初心者が学習する為に役に立ちそうなURLをいくつか載せておきます。 52 | 53 | - https://www.backlog.jp/git-guide/ 54 | - https://qiita.com/amymd/items/056864438b839855b6d7 55 | 56 | 例によってIT技術というのは手を動かす事が一番重要だったりするので最初から書籍でがっつり学習するというよりは、使いながら少しづつ覚えていく事をオススメします。 57 | 58 | ## ターミナルソフト 59 | 60 | Macに標準搭載されているターミナルでも十分ですがより高機能な [iTerm2](https://www.iterm2.com/) を推奨します。 61 | 62 | 参考になりそうな記事をいくつか載せさせて頂きます。 63 | 64 | - [MacのターミナルアプリにはiTermがオススメ](https://qiita.com/k_saito/items/ab73032a82632af3cd3c) 65 | - [Macのターミナルよりおすすめ！分割と移動がイケてるiTerms2が素敵！](https://laugh-raku.com/archives/3127) 66 | 67 | ## IDE 68 | 69 | 統合開発環境と呼ばれる物で、有名どころだと [Eclipse](https://ja.wikipedia.org/wiki/Eclipse_(%E7%B5%B1%E5%90%88%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83)) があります。 70 | 71 | しかし私のオススメは、[IntelliJ IDEA](https://www.jetbrains.com/idea/) です。 72 | 73 | 様々な言語での開発をサポートしており、これ1つあれば大抵の状況に対応が可能です。 74 | 75 | 私は今まで様々なIDEやエディタを試しましたがこれに勝る物はなかったです。 76 | 77 | 唯一の欠点を言えば有料だと言う事です。（IntelliJ IDEA Ultimateを購入した場合、初年度は$149 , 2年目は以降は更新量が安くなっていきます） 78 | 詳しくは公式サイトをご覧下さい。 79 | 80 | https://www.jetbrains.com/idea/buy/#edition=personal 81 | 82 | エディタで十分とか（[達人プログラマー](https://www.amazon.co.jp/dp/427421933X) というめちゃくちゃ有名な書籍がありますがこの中ではエディタ推してます）有料ソフト等買いたくないとか、様々な意見を言う人がいます。 83 | 84 | エディタを十分に使える事は確かに良いプログラマの条件の1つだと言う事は分かります、しかし初心者のうちはなるべく早いうちに全体像を把握して開発全体の流れを把握したほうが良いため、 エディタを極めるとかは後でやれば良いと思います。（IDEは高機能なのでプログラミング自体の負荷はかなり下がります） 85 | 86 | 有料である点も [IntelliJ IDEA](https://www.jetbrains.com/idea/) は費用に見合う価値は十分にあると思いますので、購入をオススメします。 87 | 88 | 参考までに [IntelliJ IDEA](https://www.jetbrains.com/idea/) の使い方を書いた記事をいくつか紹介させて頂きます。（中には私が書いた物もあります） 89 | 90 | - [IntelliJ IDEAのインストールと日本語化](https://qiita.com/keitakn/items/31e8af9ccb4b3bdd74d0) 91 | - [IntelliJ IDEA初期設定（主にエディタ）](https://qiita.com/keitakn/items/5968b9eee4177c302481) 92 | - [IntelliJ IDEA ショートカットリンク集（随時更新）](https://qiita.com/keitakn/items/b9a77efbcc17f8844081) 93 | - [IntelliJ IDEA Rubyの開発環境を作成する](https://qiita.com/keitakn/items/76d6707db7d23fe4ca85) 94 | - [IntelliJ IDEA PHP7の開発環境を作成する](https://qiita.com/keitakn/items/638b080a1420b401c315) 95 | 96 | ※ 一番最初に日本語化の方法が書いてありますが日本語化は不具合が発生する可能性があるのでオススメしません。 97 | プログラマにとって英語はかなり重要なので英語に慣れる意味でも英語のまま利用する事を推奨します。 98 | 99 | ## dnsmasq 100 | 101 | 自身のPC上に構築した環境に接続する際にIPアドレスではなく利用予定のドメイン名を用いて接続したいケースが良くあります。 102 | 103 | DNS登録されていないドメインに接続する為には `/etc/hosts` にIPアドレスとドメイン名を記載して名前解決出来るようにする必要があります。 104 | 105 | その際にこのdnsmasqがあると便利なのでインストール ＆ 初期設定しておきましょう。 106 | 107 | ※ DNSが何なのかはネットワークの基礎のことろで説明します。 108 | 109 | インストール方法ですが [こちらの記事](https://laccie.blogspot.jp/2017/04/mac-osxdnsmasq.html) が分かりやすかったので記載させて頂きます。 110 | 111 | ## Alfred（ランチャーアプリ） 112 | 113 | Macはなるべくキーボードで操作出来るようになったほうが効率が良いので、ランチャーアプリを使う事を推奨します。 114 | 115 | Alfredは無料で使える高機能なランチャーアプリです。 116 | 117 | 参考になりそうな記事を載せておきますので参考にインストールしておく事をオススメします。 118 | 119 | - [Alfredの 設定 & Tips メモ](https://qiita.com/pawjun/items/f45f8980ac9941c893c5) 120 | 121 | ## GoogleChrome（Webブラウザ） 122 | 123 | [Chrome DevTools](https://saruwakakun.com/html-css/basic/chrome-dev-tool) の使い勝手やPluginの豊富さ、情報量等あらゆる面で他のブラウザを上回っているのでWeb開発ではGoogleChromeを使う事を推奨します。 124 | 125 | ## Clipy（スニペットアプリ） 126 | これは、クリップボートを遡ってペーストしたり、定型文をコピーしておけるMacOS用のスニペットアプリです。 127 | ![](https://clipy-app.com/img/screenshot1.png) 128 | 129 | 公式：https://clipy-app.com/ 130 | -------------------------------------------------------------------------------- /docs/tips/HowToChooseJob.md: -------------------------------------------------------------------------------- 1 | # 仕事の選び方 2 | 3 | [仕事の探し方](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/HowToFindJob.md) を実践するとそれなりに仕事を探せるようになりますが、ここでは受けたほうが良い案件と避けたほうが良い案件を見極める方法をまとめます。 4 | 5 | ## 対象読者 6 | 7 | - 正社員就業中で副業（複業）を探している方 8 | - フリーランスエンジニアで案件を探している方 9 | 10 | 正社員で就業する予定の方は [転職マニュアル](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ChangeJobManual.md) を参照して下さい。 11 | 12 | ## 選んではいけない案件 13 | 14 | このカリキュラムでは私は一貫して理想の状態を探すよりアンチパターンを避けるべきと主張してきました。 15 | 16 | それは仕事選びに関しても同様です。 17 | 18 | 理想は人によって解釈が異なりますが、アンチパターンに関しては共通認識である事が多いからです。 19 | 20 | なお、ここで言う選んではいけない案件は以下の条件を満たしている前提です。 21 | 22 | これらの条件が満たされない場合はそもそも応募自体を避けたほうが良いです。 23 | 24 | - 自分に合った技術（もしくは興味ある技術）が利用されている 25 | - 依頼者に対してある程度のバリューを提供出来る 26 | 27 | 基本方針としては少しでも契約違反や不誠実な対応をされた場合、そのクライアントは切りましょう。 28 | 29 | 相手にしていると自分もイライラしてきますし、何より一番貴重な時間という資産がモンスタークライントによって奪われてしまいます。 30 | 31 | エンジニアにとっては技術力が自らの資本となるので、時間は非常に貴重です。（時間は可能な限り技術力の向上に当てるべきです） 32 | 33 | 不誠実なクライアントに割く時間はないのです。 34 | 35 | それからクライアントとはエンジニアにとっては「お客様」という事になります。 36 | 37 | しかしだからと言って「お客様は神様」等と言う思想は捨てましょう。 38 | 39 | こちらは技術力と問題解決という商品を提供していて、その対価としてお金を貰っているに過ぎないのです。 40 | 41 | 対価に見合った価値を提供する事は必須ですが、対価に見合わない理不尽な要求をしてくるクライアントは即刻取引を停止するべきです。 42 | 43 | ### 約束を守らない企業 44 | 45 | お金を期日までに払わない企業や契約と違う業務をさせる企業は論外です。 46 | 47 | 私が遭遇したケースを例として挙げます。 48 | 49 | - 毎月25日が入金日なのに結局翌月の10日まで支払われない 50 | - 新規開発の案件という事で契約したが、結局レガシーコード保守案件に回された 51 | 52 | このように約束（契約）を平気で破るクライアントは論外なので直ちに契約を解除するのが正解となります。 53 | 54 | ### 常駐が必須の企業 55 | 56 | 週5で常駐が必須のクライアントも避けたほうが良いです。 57 | 58 | このような企業は時代遅れと言わざるをえません。 59 | 60 | 常駐必須のクライアントが言ってくるのは主に下記のような事です。 61 | 62 | - 常駐していないと監視出来ないからサボる 63 | - 仕事ぶりを見ないと評価出来ない 64 | - コミュニケーションが取りにくい 65 | 66 | これらの問題点を上げてみます。 67 | 68 | >常駐していないと監視出来ないからサボる 69 | 70 | まずサボるという事自体に問題がある訳ではなく、サボる事によって成果が出なくなって初めて問題となる訳です。 71 | 72 | 監視するという発想自体が的外れだと言わざるを得ません。 73 | 74 | >仕事ぶりを見ないと評価出来ない 75 | 76 | これはつまり成果物の質や量で評価出来ないので、人間の感情に強く依存した評価が行われている可能性が高いです。 77 | 78 | これを言ってくる時点で、成果で評価は出来ませんと言っているような物です。 79 | 80 | >コミュニケーションが取りにくい 81 | 82 | 対面のコミュニケーションに依存した働き方を行っている可能性が高いです。 83 | 84 | このような職場は、暗黙知をドキュメント化する文化がないので、属人化や技術的な負債が生まれやすい環境になっている可能性が高いです。 85 | 86 | 労働人口も減り、少子化が進む現代においては場所に囚われず、人員を確保する事は重要です。 87 | 88 | 対面コミュニケーションに依存している職場は時代遅れと思ってよいでしょう。 89 | 90 | もう1つの理由は週5で常駐してしまうと他の案件が非常に受けにくくなるというデメリットがあります。 91 | 92 | 変化の激しいこの時代に収入源を一箇所のクライアントに依存しているというのは大きなリスクです。 93 | 94 | そういう意味でも週5常駐案件は避けたほうが良いというのが私の見解です。 95 | 96 | ちなみに今は週5常駐でもリモートワークの導入を進めているのであれば、その他の要素次第で契約を進めるのはアリだと感じます。 97 | 98 | ただし口だけで行動しないケースも多々あるので、必ず具体的な時期を確認しましょう。 99 | 100 | ### 作業環境を選べない企業 101 | 102 | 渡されたPCがWindowsオンリーでメモリ4GB、CPUはデュアルコアといった現場は絶対に避けるべきです。 103 | 104 | 自分のPCを持ち込んで良いならまだいいですが、このような現場は大抵それも禁止になっています。 105 | 106 | 理由は簡単でエンジニアの作業効率に大きく悪影響を与えるからです。 107 | 108 | PCのスペックは生産性に大きく影響します。 109 | 110 | そこをケチるような企業は避けたほうが良いでしょう。 111 | 112 | ### 正社員と非正社員を必要以上に差別する企業 113 | 114 | 正社員のみ利用可能なエレベータがあったりと露骨に差別しているようなところもあります。 115 | 116 | これはもう論外として、割と良くあるのが正社員は一切コーディングをしないで、開発作業を全て業務委託であるフリーランスエンジニアが行っているケースです。 117 | 118 | これ自体はまあその会社の方針なので好きにどうぞで終わるのですが、フリーランスエンジニアに意見を述べる機会や一切の裁量がないのは問題です。 119 | 120 | このようなケースの場合、フリーランスエンジニアにある程度の裁量がないと良いシステムは作れません。 121 | 122 | 実装をしない正社員が全て技術要素を決定して、フリーランスエンジニアはただ言われた事をやる。 123 | 124 | このような現場では良いシステムは出来ないでしょう。 125 | 126 | またこの件に限らず、このようにヒエラルキーをやたらと感じさせる組織は経験上ロクな組織でない事が多いです。 127 | 128 | 権威主義が蔓延した組織には未来はないと私は考えます。 129 | 130 | 権威主義の問題点に関しては [社畜にならない事の重要性](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/Shachiku.md) や [マネジメント入門](https://github.com/keitakn/web-developer-ojt/blob/master/docs/management/README.md) でも触れているので読んでみて下さい。 131 | 132 | 正社員と非正社員で待遇の差はともかくとして、露骨にヒエラルキーを感じさせる企業は避けたほうが良いでしょう。 133 | 134 | ### 納期を確約させてくる企業 135 | 136 | 例えば明らかにやり方が決まっていたり、小規模な機能に対して納期を指定されるのは問題ではありません。 137 | 138 | エンジニア側もそれを守るべきだと考えます。 139 | 140 | しかし長期プロジェクト（数ヶ月単位）で納期確約を迫ってくるような企業は極めてウォーターフォール的な考え方なので避けたほうが良いでしょう。 141 | 142 | ある程度経験がある方なら分かるように、システム開発は当初の計画通りに進むという事はまずあり得ません。 143 | 144 | アジャイル的な思考で細かいイテレーションを繰り返し、少しづつ完成に近づけていくのが現時点でベストな方法だと私は考えます。 145 | 146 | ウィーターフォール脳のクライアントは柔軟性に欠け、無茶な要求を行ってくる傾向が強いので避けるべきだと考えます。 147 | 148 |

エンジニアに残業が多い理由の第一は「他人が算出した見積もりに引きずられてしまうこと」で、何らかのプロジェクトに参加する際には「スケジュールは都度見直し」的な約束を必ず文書ベース(チャットでも可)で確保しておかないと凄い危険なので若い人はここら辺是非気をつけて頂きたいなと(^.^;)

— 勝又健太@エンジニア系Youtuber (@poly_soft) 2018年6月18日
149 | 150 |

そもそもサービス全体の開発工数の見積もりなんて誰にとっても無理ゲーなので、「スケジュールを守る」という考え自体がナンセンス。

スケジュールはあくまでも「努力目標」であって、残業してまでそれを守る義務なんて誰にも無いので、集中して働いているという自信があるなら容赦なく帰りましょうｗ

— 勝又健太@エンジニア系Youtuber (@poly_soft) 2018年6月18日
151 | 152 |

そして自分で見積もりを作成する際のコツは、「納期を絶対に約束しない」こと。

SIerさんの労働環境がブラックになりがちなのも結局はこれが原因なので、「納期は絶対に約束しない」「納期を約束させようとする会社とは付き合わない」ことを心がけた方が幸せに働けるかなと思うですｗ(^.^;)

— 勝又健太@エンジニア系Youtuber (@poly_soft) 2018年6月18日
153 | 154 | 納期が決まっていても、スコープの縮小が認められていたり、柔軟に計画変更を行う意思があるのであれば問題ありません。（これがアジャイル的な思考） 155 | 156 | ## 選ぶべき理想の仕事 157 | 158 | アンチパターンの逆が理想に近いと考えます。 159 | 160 | - 約束を守り信頼出来る 161 | - リモートワーク等の柔軟な働き方を認めてくれる 162 | - 作業環境を選べる 163 | - フラットな風土が根付いている組織 164 | - アジャイル文化が根付いている組織 165 | 166 | あとたまにお金よりもやりがいを重視でみたいにいう人がいますが、別に金額とやりがいは反比例しません。 167 | 168 | お金が安いからやりがいのある職場、お金が高いけどやりがいはない、みたいな主張は的外れだと私は考えます。 169 | 170 | むしろ私の肌感だと報酬が安い仕事ほどやりがいがなく（レガシーコードの保守オンリーとか）報酬が高い仕事ほどやりがいもある事が多いと感じます。 171 | 172 | ※ 報酬が高い案件のほうが新技術を採用したり、新しい事にチャレンジしている。 173 | 174 | やりがいとお金はトレードオフ等と考えずに、高単価でやりがいもある仕事を選ぶべきです。 175 | 176 | その為にも常に自らの技術力を高めていく努力をしなければならないと考えます。 177 | 178 | ## 理想の仕事を得る為にやるべき事 179 | 180 | エンジニアとして理想の案件を得る為には学習を続け、技術力を高めていく必要があります。 181 | 182 | 学習方法に関しては以下の記事を参考にしてみて下さい。 183 | 184 | - [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) 185 | - [学習を続けるコツ](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/HowToContinueLearning.md) 186 | - [学習方法のアンチパターン](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/AntipatternOfLearningMethod.md) 187 | 188 | これらの記事に書いてある事以外でやったほうが良い事を記述していきます。 189 | 190 | ### やった事のない技術を使っている案件に応募する 191 | 192 | 「この技術をこの現場で勉強させて下さい」とか「勉強になりそうな案件だから応募しました」というのはNGです。 193 | 194 | これは向こう側（クライアント側）の立場になってみれば至極当然の事で勉強させる為にお金を払うという事はまずあり得ないでしょう。 195 | 196 | お金を払ってさらに無償で教育までするというのは考えられません。 197 | 198 | このような発言は自身の成長を組織に依存する人間だと思われてしまうので絶対に避けるべきです。 199 | 200 | とは言っても、事実として業務経験を積んだほうが一番技術力をつけられるのも事実です。 201 | 202 | そこで以下のようなアプローチを取りましょう。 203 | 204 | - GitHubで自分が習得したい技術を使った成果物を見せて、何とか任せてもらえないか交渉する 205 | - 自分の得意な領域で価値を提供する引き換えに新しい技術を使った案件を回してもらえないか交渉する 206 | 207 | 私は以前フロントエンドの技術を強化したいと思っていた時期がありました。 208 | 209 | React未経験でしたが、GitHubの成果物を見せるのと、バックエンドの環境構築を自動化する事を引き換えにReactでのゼロベース案件を取得した事があります。 210 | 211 | 最初はダメでも新技術に積極的な企業と契約して、徐々に信頼を得ていけば、良い仕事が回ってくる可能性もあります。 212 | 213 | このあたりも交渉次第で決して不可能ではないので、チャレンジしてみる事をオススメします。 214 | 215 | もちろん引き受けたからには最後までやり抜く事が重要です。 216 | 217 | ### 金になる技術を習得する 218 | 219 | 自分の興味がある技術をやるのが一番ですが、どうせなら市場で求められている技術を習得しましょう。 220 | 221 | - Ruby + Ruby on Rails 222 | - スタートアップ企業での採用率が高いので案件の数が多い 223 | - PHP + Laravel 224 | - Ruby on Railsと並びスタートアップ企業での採用率が高い 225 | - GitHubのスター数はRailsを超えた 226 | - Golang 227 | - Ruby on Railsでスタートしてこの言語に乗り換えるパターンが最近結構多いです 228 | - 平行処理が簡単に書ける 229 | - DockerやKubernetesなどのコンテナ技術に多く利用されている 230 | - React 231 | - モダンなフロントエンド開発が出来る 232 | - Vue.js 233 | - Reactと並ぶモダンなフロントエンド開発が出来る 234 | 235 | これらはほんの一例でまだまだ習得したほうが良い技術はたくさんあります。 236 | 237 | 常にアンテナを張り巡らせて情報に対して、敏感になる事が大切です。 238 | 239 | [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) にも書いていますが、学習を行う上で基礎技術をしっかり抑えておくと新しい技術を習得するスピードが桁違いに早くなるので基礎をしっかり抑えておく事が重要です。 240 | 241 | またフリーランスエンジニアの場合、以下のような課題をやる事が多いです。 242 | 243 | - ごちゃごちゃしているコードのリファクタリング 244 | - テストコードの自動化 245 | - 環境構築の自動化 246 | - 業務フローの自動化 247 | - デプロイの自動化 248 | 249 | 多くの企業は事業優先なのでこのようにやったほうが生産性は上がるけど、事業側の要求を捌くだけで手いっぱいだったりします。 250 | 251 | このような業務をスポット参戦技術者に任せる事が実に合理的です。 252 | 253 | 万が一問題があっても直接事業への影響が少ないからです。 254 | 255 | その為、以下のような技術も習得しておいて損はないです。 256 | 257 | これらはリファクタリングを行いキレイな設計を行う為に必要な技術です。 258 | 259 | - [オブジェクト指向の基礎](https://qiita.com/tutinoco/items/6952b01e5fc38914ec4e) 260 | - [関数型プログラミングの考え方](https://qiita.com/tail-island/items/1782e4c1e7b620a4f9c0) 261 | - [ドメイン駆動設計](https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html) やそれに伴うデザインパターン 262 | 263 | これらは特定の言語に依存した技術ではない（明らかに向いていない言語とかもあるので一概には言えませんが）一度習得すると長く役に立つのも特徴です。 264 | 265 | 下記は環境構築やオペレーションを自動化する技術です。 266 | 267 | - [Terraform](https://www.terraform.io/) 268 | - Cloud環境の構成管理を自動化する 269 | - [Ansible](https://www.ansible.com/) 270 | - サーバの構成管理を自動化する 271 | - [CodeDeploy](https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/welcome.html) 272 | - デプロイ自動化 273 | - [Amazon EKS](https://aws.amazon.com/jp/eks/) 274 | - フルマネージドなコンテナ管理 275 | - [Serverless](https://serverless.com/) 276 | - フルマネージドサービスだけでアプリケーションを開発する技術 277 | 278 | このように何かを自動化する技術は人件費を分かりやすく削減出来る為、価値を出しやすいです。 279 | 280 | 属人化をある程度防いだり、オペレーション負荷を軽減させたりする効果もあるので、このあたりが強い人は重宝されます。 281 | 282 | また今後どのような技術を習得していくかと迷っている人は以下の動画が参考になります。 283 | 284 | [AI時代に生き残れるエンジニアの条件とは？](https://www.youtube.com/watch?v=cHaE5oFaVuI) という動画です。 285 | 286 | 私も共感する部分が多く非常に参考になった動画です。 287 | 288 | エンジニアの本質はやはり技術を組み合わせた問題解決能力だと私は考えます。 289 | 290 | その基礎となる技術、問題解決能力の両方を強化していけば今後も良い案件を取り続けられるでしょう。 291 | 292 | ### 対面のコミュニケーションに依存しない働き方をする 293 | 294 | 複業でリスク分散を行う為にはリモートワークに慣れておく必要があります。 295 | 296 | その為、エンジニアも対面のコミュニケーションに依存しない働き方を心がけましょう。 297 | 298 | 下記のような事が頻繁に起こっていたら要注意です。 299 | 300 | - 主に直接話した内容で仕事が進行しており、文章ベースで決定事項が残っていない 301 | - 形骸化している対面での定例会議が毎週ある 302 | - アジェンダがない行くまで何を話すか分からないMTGがある 303 | 304 | これらは全て対面コミュニケーションに依存した働き方です。 305 | 306 | リモートワークでは基本全てがSlackを始めとするチャットベースの非同期コミュニケーションが基本となります。 307 | 308 | その為、以下のような事を意識する必要があります。 309 | 310 | - すぐに返事が来る事を期待しない、返答の待ち時間に雑務を済ませる等時間を効率的に使う 311 | - 逆に質問が来たらなるべく早めの返答を心がける（すぐに返事出来ない場合でも、調べて返答しますと返すだけならすぐに出来るハズ） 312 | - TODOリスト系のWebサービスやアプリを上手く活用すると良いです 313 | - 決定事項は必ず文章に残す 314 | - 何か相談したい事があったら、まず自分が言いたい事を文章にして共有する 315 | - とりあえず集まろう的な会議を入れない 316 | - 文章にする過程で思考が整理され、自己解決する事も多いです 317 | - 何かあってもいきなり電話をかけない 318 | - 電話はあくまで最終手段として捉える 319 | - 本当に電話が必要な時は、電話をかける前に相手の状況を確認する 320 | - issueやPRは細かい単位に分割する 321 | - issueやPRの完了の定義を明確にする 322 | - Gitのコミットを意味のある単位で行う 323 | - Gitのコミットメッセージに変更を行った意図を書く 324 | - [相手を不快にさせないコードレビュー](https://employment.en-japan.com/engineerhub/entry/2018/01/24/110000?amp=1) を心がける 325 | - 他人の影響を受けない開発環境が存在する事（DockerやVagrantでのローカル環境） 326 | - もしこれがない現場なら、自分で作成する事を提案して作っちゃいましょう 327 | - 複数人で開発が行いやすいようにモジュール同士が疎結合になるように設計する 328 | - これが出来ていると、各開発者で開発が完結する場面も多くなるので、コミュニケーションコストが削減出来る 329 | - もしそういう設計になっていない場合は、提案して改善しちゃいましょう 330 | 331 | これらは身につけようと思ってもすぐに身につくものではありません。普段からの積み重ねが重要です。 332 | 333 | これらを意識する事でコミュニケーションの改善だけでなく、成果物の品質も向上します。 334 | 335 | これらがクライアント、エンジニア双方で出来ていれば、対面で話さなくても非同期コミュニケーションで十分にやっていく事が可能です。 336 | 337 | 私は一度も音声会議なしで4か月間の開発プロジェクトを終えた事があります。（開発者3名、うち一人はヨーロッパの人で日本語が分からない） 338 | -------------------------------------------------------------------------------- /docs/tips/HowToContinueLearning.md: -------------------------------------------------------------------------------- 1 | # 学習を続けるコツ 2 | 3 | IT技術の学習を継続する為のコツをまとめました。 4 | 5 | ## この記事を書こうと思った動機 6 | 7 | Webエンジニアという仕事と出会って8年程経ちました。（この記事を書いている2018年5月で） 8 | 9 | 私は今まで独学でエンジニアの学習を続けてきました。（途中挫折していた時期もありましたが） 10 | 11 | よって、今まで続ける為のコツというのは意識していませんでしたが、最近学習を続けるコツを相談される事があったのでこの機会に文書化してみました。 12 | 13 | ## 学習を続けられる人は少ない 14 | 15 | 少し前に [技術者としてスポンジであり続けること　あるいは老害回避戦略の話](http://blog.toshimaru.net/like-a-sponge-as-an-engineer/) という記事を読みました。 16 | 17 | この記事にも書いてありますが学習を続ける事は良いエンジニアになる為の必須条件だと考えて良いです。 18 | 19 | というか今後の時代においては学習をしない事によるデメリットが大きくなっていくでしょう。 20 | 21 | Twitter等で有名なエンジニアをフォローしていると、そのフォロワーにも優秀そうなエンジニアをたくさん見かけます。 22 | 23 | 世の中は良いエンジニアで溢れていると考えがちですが、実際は学習をしていない人が大多数を占めています。 24 | 25 | Twitterやブログで情報発信を行っている時点で学習している側の人間です。 26 | 27 | ネットでは見つからない情報発信もしない、学習もしない人間のほうが圧倒的多数派です。 28 | 29 | 私は今までにエンジニアとして働いてきた中で様々な人と接触しました。 30 | 31 | 私の体感からしても、有名なIT企業で働いている人でも学習を全くしていない人、もしくはほとんどしていない人のほうが圧倒的大多数でした。 32 | 33 | [業務時間外に勉強しないエンジニアは給料が上がらない](https://se-tenshokucenter.com/column/gyomujikangai-benkyo/) という記事に「日本のITエンジニアは勉強しなさすぎ」という項目があるので見て下さい。 34 | 35 | 最近Twitter上で以下の画像を見かけました。 36 | 37 | ![img_1284](https://user-images.githubusercontent.com/11032365/39638235-85195af4-5000-11e8-9c2d-7b7017fbfc65.jpg) 38 | 39 | このような画像が出回るという事はそれだけ学習を続けるという行為が難しい事を意味しています。 40 | 41 | 「続ける」という事は立派な才能なのです。 42 | 43 | 逆に言うと続ける事さえ出来れば間違いなく成果を出す事が出来ますし金銭的な余裕も出来る事を意味します。 44 | 45 | 続ける方法を確立する事はとても意味のある行為なのです。 46 | 47 | ## 時間を確保する方法 48 | 49 | ここからは具体的に続ける為の方法を考えていきましょう。 50 | 51 | まずともかく時間を確保する事が大事です。 52 | 53 | 私が実践している方法を記載しておきます。 54 | 55 | ### 人間関係を整理する 56 | 57 | 以下のような物は自分にとって有意義とは言わないので参加しないようにしましょう。 58 | 59 | - 別に楽しくはないけど付き合いで行っている飲み会（会社の飲み会） 60 | - 薄い人間関係を維持する為の飲み会やBBQ等のイベント 61 | - 愚痴を言い合うだけの非生産的な集まり 62 | 63 | これらの行事を全否定はしませんが、義務感で参加しているのであれば行かないほうが良いです。 64 | 65 | 義務感で参加していたり、嫌々参加しているのであれば、時間とお金の浪費的行為と言えるでしょう。 66 | 67 | [一人ぼっちでも大丈夫？ 「友達ゼロ」の人の結末](http://wol.nikkeibp.co.jp/atcl/column/15/112800113/060100007/) という記事を見ていただきたいです。 68 | 69 | 友達ゼロでも良いというのは極論です。しかし以下の点は的を得ていると言えます。 70 | 71 | >表面的な友達は、いざという時に助けてくれない 72 | 広く浅くの表面的な関係で結ばれた友達が、いざという時に、本気であなたを助けてくれますか。相手が苦しい時に自分の身を投げ出してでも何とかしようとする。そうした深い人間関係は、「孤独を知った者同士」の間にこそ生まれる。人間は本来孤独であり、それぞれ自分の道を生きるしかない。 73 | そうやって孤独を引き受けた者同士だから、分かり合うための努力をする。孤独を知った者同士だからこそ響き合える、深い出会いがあるんです。 74 | 75 | 自分が一緒に居て楽しいと思える人とだけ付き合うようにすれば、人付き合いにそれほど時間は取られませんしストレスもなくなります。 76 | 77 | 一度、自身の人間関係を見直してみる事をオススメします。 78 | 79 | ### 無駄な時間をなくす 80 | 81 | 例えば私はあまりTVを見ないのですが、TVをリアルタイムで見るのはかなり時間の無駄です。 82 | 83 | 見たい番組があれば録画して見るようにするだけでCMをカット出来るので時間の節約が可能です。 84 | 85 | また動画サイト等をダラダラ見てしまいあっという間に時間が経っている事も良くありません。 86 | 87 | 一日の学習を終えてから見る等、ある程度時間を区切る事が必要不可欠です。 88 | 89 | ### 無駄な仕事ばかりさせる会社は辞めてしまう 90 | 91 | 会社の仕事をこなすだけで疲弊して学習を出来ないくらいなら辞めてしまいましょう。 92 | 93 | 日本人は何故か仕事を辞める事に異常な抵抗感を持つ人が多いですが、意味のない事を毎日続ける事ほど無駄な物はありません。 94 | 95 | 嫌な仕事など、さっさと辞めてしまって、スキルアップ期間を置いてから再スタートしたほうが良い成果をあげられるでしょう。 96 | 97 | 少しぐらい低収入な期間があっても人生どうにでもなります。 98 | 99 | それよりも無駄な時間を強要する会社に人生を捧げ続ける事のほうが遥かに大きなリスクです。 100 | 101 | ## モチベーションを保つ方法 102 | 103 | 次にモチベーションを保つ方法を考えてみましょう。 104 | 105 | 私は正直あまり今まで意識した事はなかったのですが、現時点で思いつく事を書いておきます。 106 | 107 | ### 人生の目標を明確にする 108 | 109 | 最終的に自分がどうなりたいかを明確にしましょう。 110 | 111 | 「良いエンジニアになりたい」とか「お金を稼げるようになりたい」とかは通過点に過ぎません。 112 | 113 | そうではなく最終的に理想と言える生活を自分の中に思い描く事が大切です。 114 | 115 | 私の場合、現在は下記の状態を理想と考えています。 116 | 117 | >何らかの方法で不労所得を得る。 118 | エンジニアとしての活動は好きなOSS活動や興味のある開発だけを行う。 119 | 時間とお金の余裕が出来たら次世代のエンジニアを育成する事に集中したい。 120 | 少しでも多く日本の社畜思想に洗脳されていない真に自由なエンジニアを育成していきたい。 121 | 122 | これは人によって異なるので、自分なりの理想の生活を思い描いて下さい。 123 | 124 | 社会貢献がどうのこうのだの、立派な目標である必要はありません。 125 | 126 | 社会の常識等という訳の分からない物に囚われず理想をイメージして下さい。 127 | 128 | エンジニアは学習すればするだけ成果を出せます。 129 | 130 | 学歴や性別などの差別も吹き飛ばせる力を得る事も決して不可能ではありません。 131 | 132 | 理想の生活を実現する為に頑張りましょう。 133 | 134 | ### 目標を達成した自分を想像する 135 | 136 | 目標を決めたらそれを達成した自分を想像してみましょう。 137 | 138 | そして自分は必ずそこにたどり着けると強く信じて下さい。 139 | 140 | 学習を続けられるかどうかは自分自身を信じ続けるかどうかも大きく影響してきます。 141 | 142 | ### 絶対になりたくない状態を考えておく 143 | 144 | 「人生の目標を明確にする」とは逆のアプローチです。 145 | 146 | 私の考える絶対になりたくない状態は下記の通りです。 147 | 148 | >私は日本の体育会系的な根性論が大嫌いです。 149 | 意味不明なヒエラルキーに取り込まれる事は人生で最も避けたい状態です。 150 | 学習を怠れば自分の市場価値が下がり、そのような場所で仕事をするしか選択肢がなくなります。 151 | 私は絶対にそうなりたくないので、それが学習を続けるモチベーションになっています。 152 | 153 | これも人それぞれ違うので、自分なりに「どうなりたくないか」を考えておくようにしましょう。 154 | 155 | ## 学習を習慣化する 156 | 157 | モチベーションを高める事は重要ですが、モチベーションというのは時間と共に低下していくのが普通です。 158 | 159 | よってモチベーションだけで学習を継続する事はかなり難しいでしょう。 160 | 161 | モチベーションに依存せず学習を続ける為の方法として学習を習慣化してしまう方法があります。 162 | 163 | 毎日歯を磨かないと気持ち悪いような感覚で学習をしないと気持ち悪いとか、落ち着かないという状態を目指しましょう。 164 | 165 |

やる気駆動ってほぼ失敗すると思うんだよねー

やる気ないとんでもないクズな自分でも出来る仕組みを作るのにやる気を使って、あとは適当にしてりゃいい。

そんなこんなで、ブログはじめてもう少しで 1 年です。
プログラミングは 2.5 年ほぼ毎日やってます。

— とだ@元営業フリーエンジニア (@cohki0305) 2018年6月29日
166 | 167 | ### 1日1つアウトプットを出す 168 | 169 | 毎日必ず1つのアウトプットを出すようにしましょう。 170 | 171 | アウトプットは何でも構いませんが、インターネット上で公開出来る形になっている事が重要です。 172 | 173 | 例えば下記のような物です。 174 | 175 | - ブログや [Qiita](https://qiita.com) の記事 176 | - [GitHub](https://github.com/keitakn) 上のPR 177 | 178 | 何でも構いません、とにかく1日1アウトプットのルールを自分の中に作りましょう。 179 | 180 | ### GitHubを用いた方法の紹介 181 | 182 | 私が行っているGitHub学習法を紹介します。 183 | 184 | 私は定期的にGitHubにコードを上げています。 185 | 186 | GitHubにはcontributionを可視化する機能があります。 187 | 188 | [GitHubAccount](https://github.com/keitakn) の「contributions in the last year」という部分に注目して下さい。 189 | 190 | ![contributions](https://user-images.githubusercontent.com/11032365/39643278-3bbae83c-500f-11e8-9b91-c9c3cb4191f3.png) 191 | 192 | 緑色の部分が直近1年間でのGitHub活動履歴です。（PCで見ないと見れません） 193 | 194 | 濃い緑色になっている日は活動回数が多く、白になっている部分は活動していない事を示しています。 195 | 196 | contributionが増える条件は [こちら](https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile/) になります。 197 | 198 | 簡単に言うと、主に以下の行動でcontributionが増えます。 199 | 200 | - GitHub上でPRを作成する 201 | - GitHub上にコミットを行う（masterにマージする） 202 | - GitHub上でissueを追加する 203 | 204 | [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) にも書いてあるようにアウトプットによる学習効果は非常に大きいのでオススメです。 205 | 206 | また完全に自己満足ですが、contributionが可視化されるのはモチベーション維持効果があります。 207 | 208 | 書くコードの内容は何でも構いません、例えば下記のような物です。 209 | 210 | - 有名なアルゴリズムを色んな言語で書いた物 211 | - 書籍のサンプルコードを [写経](https://qiita.com/yuya_takeyama/items/b8a8c548a4a1c6a05531) した物 212 | - [paiza](https://paiza.jp/) 等のオンラインサービスの問題 213 | - [ドットインストール](https://dotinstall.com/) のレッスン内容 214 | - Webフレームワークのチュートリアル 215 | - Webフレームワークの[ボイラーテンプレート](https://qiita.com/re-fort/items/0f0695fd30c80fc0a4b1) 216 | - オープンソースで公開されているライブラリへのコミット 217 | - 自作したオープンソースのライブラリ 218 | - [til（Today I Leaned）](https://qiita.com/sta/items/c69d73fb1bb781fe6b9c#til) リポジトリを作成して学習記録を付ける 219 | 220 | [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) にも書いてありますが、現時点で自身の持てる最高のコードを書くように心がけて下さい。 221 | 222 | ただし極端に完璧主義に走るとコードを書く事自体にストレスを感じるようになります。 223 | 224 | あくまで自分が出来る範囲で大丈夫です。 225 | 226 | 数ヶ月後に自分が書いた過去のコードを見て、それがダメだと感じるならば、自分が成長している証拠です。 227 | 228 | PRを細かい単位で出すように心がければ、1日30分程度の作業でも十分に続ける事が可能です。 229 | 230 | とにかく毎日継続する事が一番大切です。 231 | 232 | 下記の記事も参考になるので是非読んでみて下さい。 233 | 234 | - （参考）[毎日コードを書いてGitHubのcontributionを途切らせないようにしている](https://queryok.ikuwow.com/entry/everyday-commit/) 235 | - （参考）[Githubで草を生やし続けるためのコツ：目的編](https://findy-code.io/engineer-lab/github-kusa-kotsu-mokuteki) 236 | 237 | # アンチパターン 238 | 239 | 以下のパターンはアンチパターンです。 240 | 241 | これらに陥ると学習を継続する妨げになるので、避けるようにしましょう。 242 | 243 | ## 無理にモチベーションを上げようとする 244 | 245 | 先程も書きましたがモチベーションだけで継続を行うのは無理があります。 246 | 247 | やる気のない時にやる気を出そうとする事ほど辛い事はありません。（[やる気が出ない時に一番してはいけないこと](http://dennou-kurage.hatenablog.com/entry/2013/06/15/154041) を参照） 248 | 249 | ただしやる気がない時でも最低5分くらいは学習のアウトプットに出す時間を作りましょう。 250 | 251 | 例えやる気がなくても習慣化が出来ていれば、1日5分程度なら手を動かす事は可能です。 252 | 253 | 5分あればGitHub上に1コミットくらいはする事が出来るハズです。 254 | 255 | モチベーションに依存するより習慣化する事を意識しましょう。 256 | 257 | ## 他者にモチベーションを依存する 258 | 259 | 例えば下記のような例です。 260 | 261 | - 上司が褒められたいから頑張る（その逆で上司に怒られたからやる気をなくした） 262 | - 友人が辞めたのでやる気をなくした 263 | - 今までチームを引っ張ってきた◯◯さんがいなくなったので士気が下がった 264 | - 周りに白い目で見られやる気がなくなった 265 | 266 | これらは全てモチベーションを他者に依存している状態です。 267 | 268 | 例えばこれ。 269 | 270 | >友人が辞めたのでやる気をなくした 271 | 272 | その仕事自体へのやる気を失わないのであれば、友人が辞めるので自分も会社を辞めるのは問題ないでしょう。 273 | 274 | ただしその仕事自体のやる気を失うのであればモチベーションの他者依存と言えるでしょう。 275 | 276 | 他者依存のモチベーションは長続きしない上にその人の状態によって大きく左右されてしまいます。 277 | 278 | モチベーションとは他人に求める物ではなく自分自身の中から湧いてくるべきものです。 279 | 280 | - [モチベーションを他人に依存しないで](https://ogatism.jp/other-motivation/) 281 | - [モチベーションの他者依存](https://ameblo.jp/and-kei/entry-12257905846.html) 282 | 283 | ## 必要以上に考え込む 284 | 285 | 必要以上に考え込む事はマイナス効果が大きいのでオススメ出来ません。 286 | 287 | 例えば下記のような事です。 288 | 289 | - この言語の将来性はどうか、学んだ事が無駄になるのではないか 290 | - エンジニアは学習ばっかりでコスパが悪い 291 | - 自分には向いていないのではないか 292 | 293 | この手の悩みはいくら考えたところで無駄です。 294 | 295 | 頭の中でいくら考えても決して解決する事はありません。 296 | 297 | 学習した事が全く無駄になるという事はまずないでしょう。 298 | 299 | 考えるよりもとにかく行動しましょう。 300 | 301 | # 最後の言葉 302 | 303 | 「学習を続けるスキル」はエンジニアにとってもっとも大切な技術です。 304 | 305 | ここに書いてある事が少しでも学習を続けるヒントになれば幸いです。 306 | -------------------------------------------------------------------------------- /docs/tips/HowToFindJob.md: -------------------------------------------------------------------------------- 1 | # 仕事の探し方 2 | 3 | ここでは仕事の探し方を記載します。 4 | 5 | エンジニアは売り手市場ですが、それには依存しないどの状況でも通用する方法を記載します。 6 | 7 | ## 対象読者 8 | 9 | - 正社員就業中で副業（複業）を探している方 10 | - フリーランスエンジニアで案件を探している方 11 | 12 | ## 基本方針 13 | 14 | ネットで検索すると様々な意見が出てきます。 15 | 16 | 例えば下記のような物です。 17 | 18 | - エージェントは使わないほうが良い 19 | - とにかく人脈が大事だから人脈を広げよう 20 | 21 | 私の考えはこうです。 22 | 23 | 「基本的に手段を選ばずにどの手段も使うべき、ただし集中と選択は必須」 24 | 25 | もう1点大事な点があります。 26 | 27 | それは無意識のうちに作っている自分ルールを取り払う事です。 28 | 29 | 無意識に作っている自分ルールには例えば下記があります。 30 | 31 | - 私はTwitterをやらない 32 | - 私はエージェントを使わない 33 | - 私はこのグループ会社の仕事は受けない 34 | 35 | これらは自らの選択肢を狭めるだけで何もメリットはありません。 36 | 37 | 先程も述べた通り、使える物は全て使ったほうが良質な案件を取れる可能性は高まります。 38 | 39 | もちろん選択と集中は必須です。 40 | 41 | とりあえず仕事なら何でもみたいに安請け合いしていると、金銭的に割の合わない仕事や失礼なクライアントを相手にして消耗するハメになります。 42 | 43 | この点を踏まえて以降の説明を行っていきます。 44 | 45 | ## ポートフォリオを充実させておく 46 | 47 | まず最初に手をつけるべきはこれです。 48 | 49 | GitHubが真っ白な人やアカウントがない人と比較すると圧倒的に仕事を探しやすいです。 50 | 51 | [学習を続けるコツ](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/HowToContinueLearning.md) や [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) を参考にGitHubやQiitaを充実させましょう。 52 | 53 | 私はこれをやっているだけでメールやTwitterのDMを頂き、仕事をGET出来たという経験があります。 54 | 55 | これは考えてみれば当たり前の話で、例えどんなに優秀であってもそれが世の中に知られなければ意味がありません。 56 | 57 | アプトプットを一切しないというのは、例えるなら一切宣伝をしないで飲食店を開いているような状態です。 58 | 59 | これではお客さんを呼び込むのは難しいというか普通に考えて無理です。 60 | 61 | 情報発信は極めて重要だという事です。 62 | 63 | また情報発信の頻度も大切です。 64 | 65 | GitHubを作ったは良いが、ずっと真っ白な状態が続いているとかはNGです。 66 | 67 | 何でも良いので1日1アウトプットを心がけましょう。 68 | 69 | 職務経歴書、スキルシートは何らかの形でバージョン出来ている形が望ましいです。 70 | 71 | このあたりの説明は [転職マニュアル](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ChangeJobManual.md) に書いてありますので参考にして下さい。 72 | 73 | あと日本式の履歴書はゴミなのでどうでもいいです。 74 | 75 | 提出を求められたら適当に書いて出せば良いです。 76 | 77 | モダンな企業であれば履歴書不要というケースも多いです。 78 | 79 | 私はここ数年一度も履歴書を出していませんが普通に新規契約出来ていますので、問題ないと考えて差し支えないでしょう。 80 | 81 | 履歴書を頑張って書くなら、Twitterのプロフィールを充実させたほうが高い成果を挙げられるでしょう。 82 | 83 | 主に自分が触っている技術や仕事を受け付けられる時期等を書いておくと良いでしょう。 84 | 85 | 「気軽にDM下さい」と書いておくとDMを送るほうも送りやすいのでオススメです。 86 | 87 | ## エージェントを利用する 88 | 89 | エージェントを利用する上で意識する点は1つです。 90 | 91 | それはエンジニアが主導しているエージェント組織を選ぶ事です。 92 | 93 | 例えば下記のような会社です。 94 | 95 | - [Findy Freelance](https://freelance.findy-code.io/) 96 | - [CODEAL](https://www.codeal.work/) 97 | - [シューマツワーカー](https://shuuumatu-worker.jp/) 98 | 99 | 理由は簡単でITの知識がロクにないエージェントがまともな案件を紹介出来る訳がないからです。 100 | 101 | またIT知識が少ない紹介会社は手数料も高い傾向にあります。 102 | 103 | 自分が手数料を払う訳ではないですが、毎月自分の単価から一定のパーセンテージを搾取され続ける事になります。（つまり事実上は自分で手数料を払っているのと同じ） 104 | 105 | このようなエージェントは避けたほうが良いでしょう。 106 | 107 | ## Twitterで仕事を探す 108 | 109 | 別にTwitterでなくても良いですが、SNSを利用して仕事を探すという事です。 110 | 111 | エンジニアを募集している企業担当者にDM、リプを送ってみるのが最もてっとり早いです。 112 | 113 | ただし相手に何を提供出来るかを明確にした上でメッセージを送って下さい。 114 | 115 | NGなのが「勉強したいです」とか「優秀なエンジニアが揃っている御社で働きたいです」と言った類のメッセージです。 116 | 117 | このようなtake思考のメッセージは相手にされない事が多い上に相手の時間を奪う事になるので絶対に避けましょう。 118 | 119 | また普段からgive思考である事が大切です。 120 | 121 | - Twitter上で困っているビキナーの方がいたら解決策を提示する（上から目線の言葉はうざいだけなので絶対NG） 122 | - 自分が解決した問題をQiitaやブログ等で公開する 123 | 124 | 相手から何を得られるかではなく、相手に何を与えられるかを意識しましょう。 125 | 126 | Twitterで仕事を探す最大のメリットは雇用主と直接契約を結べる点です。 127 | 128 | 直接契約はマージンが一切発生しないので、同じ仕事内容でも単価は高くなりますしリピートしてもらえる確率もが上がります。 129 | 130 | エージェントを利用するのも良いですが、直接契約を行ってくれるクライアントを見つける事も同時に行っていきましょう。 131 | 132 | ## 営業力を鍛える 133 | 134 | エンジニアの営業力とは人と上手く話せるとか、誰でも仲良くなれるとかそういう能力ではありません。 135 | 136 | 私は下記のような事を鍛えるべきだと思っています。 137 | 138 | - Qiitaで記事を書く際は分かりやすい記事を書くように心がける 139 | - 想定読者をちゃんと意識する 140 | - 前提知識や前提条件をちゃんと記載する 141 | - 何も知らない人がその記事を見て実際にその問題を解決出来るように記載する 142 | - GitHubに作っている個人リポジトリは人に見られている成果物だと意識する 143 | - キレイな設計を心がける 144 | - READMEは必ず書く 145 | - PRやissueは適切な大きさに分割する 146 | - Twitter等のSNSで情報発信する 147 | - Twitter上の困っている人に積極的に協力する 148 | - [Stack Overflow](https://ja.stackoverflow.com/) の質問に答える 149 | - 意見を求めているTweetに対して意見を出す（マサカリを投げるとかそういう事はNGなのでやらない） 150 | - ポートフォリオを充実させる 151 | - 可能な限り情報は公開する 152 | 153 | 昨今ではリモートワークの重要性が増してきており、このように分かりやすい文章を書く能力やSNS上で人を不快にさせないコミニケーションを取れる事は重要です。 154 | 155 | 今から言う事は少々極論ですが私はこう考えています。 156 | 157 | 「エンジニアの営業活動というのは結局のところ、役に立つコードを書いて、それを世の中に発信する事」です。 158 | 159 | ## 交渉力を鍛える 160 | 161 | まず自分を安売りしない事です。 162 | 163 | エンジニアにとって自分の技術力は商品です。 164 | 165 | 安い単価で仕事をするというのは、商品をタダ同然で売っているという事です。 166 | 167 | プロならキッチリと適切な報酬を請求するべきです。 168 | 169 | 経験年数がこれくらいだとだいたい相場がこのくらいみたいに言う人がいます。 170 | 171 | しかしエンジニアをやっている皆さんであれば経験年数と実力が比例しない事はお分かりでしょう。 172 | 173 | 自分が提供出来る価値を明確にして、その代わりに適切な単価を要求して下さい。 174 | 175 | クライアント側もエンジニアを採用するにはコストがかかります。 176 | 177 | 多少高単価を要求しても相手が欲しがっている物を提供出来れば、十分交渉は成立します。 178 | 179 | 相場というのは単なる目安に過ぎないという事です。 180 | 181 | Twitter上で [#hiyokonitsuduke](https://twitter.com/hashtag/hiyokonitsuduke?src=hash) というタグが流行っています。 182 | 183 | 率直に言ってこのタグで求職を行っている人達は自分を安売りしている人が多いと感じます。 184 | 185 | 自分を安く売っても何のメリットもないので適切な単価を請求しましょう。 186 | 187 | 交渉の際には心理学のテクニックを利用するのも有効です。 188 | 189 | 下記の単語を調べてみましょう。 190 | 191 | - ドア・イン・ザ・フェイス 192 | - 返報性の原理 193 | 194 | どちらにせよ、向こう側にもメリットがないと交渉は成立しません。 195 | 196 | Win-Winの関係になるように自分が提供出来るバリューをしっかりと提示する事が大切です。 197 | 198 | ## 人の紹介で案件をGETする 199 | 200 | まず、[僕がエンジニアに「裏口入社」をお薦めする理由](https://www.youtube.com/watch?v=jTZXkbDYwz0) という動画を見て頂きたいです。 201 | 202 | 内容を要約すると以下のような主張を行っています。 203 | 204 | >イベントや勉強会で顔を売って、企業で働いているエンジニアと繋がりましょう。 205 | その人に紹介してもらえば目的の企業に入りやすいです。 206 | 人の紹介だと面談する側も不合格にしにくいです。 207 | だから紹介で入るのがオススメです。 208 | 209 | 確かに言っている事は間違っていないし、事実紹介のほうがその案件にアサインされる可能性は高まるでしょう。 210 | 211 | しかし人の紹介で入るという事は以下のような副作用もある事を覚えておいて下さい。 212 | 213 | ### 副作用その1（人脈作りは時間を取られる） 214 | 215 | 人脈が大事なので勉強会やイベントに積極的に参加しまくる人がいます。 216 | 217 | この件に関しては [学習方法のアンチパターン アンチパターン7「勉強会に参加する事を学習だと勘違いする」](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/AntipatternOfLearningMethod.md) でも触れています。 218 | 219 | 人脈というのは名刺交換して終わりではありません。 220 | 221 | その後当然、交流を重ねていく必要があるのですが、これが多くなればなる程自分の時間を失っていきます。 222 | 223 | 学習に割ける時間が減ってしまうのは大きなデメリットです。 224 | 225 | ### 副作用その2（離脱の心理的ハードルが上がる） 226 | 227 | 案件を紹介してもらうという事はそれなりに関わりがあるという事です。 228 | 229 | SNS上で繋がっていたり、リアルなイベントでも一緒になっていたりする事でしょう。 230 | 231 | 動画の中では、人の紹介で入れば面談で断られにくいという主張がありました。 232 | 233 | これ自体はその通りなのですが、これは裏を返せばもし自分がその案件に合わず、すぐに辞めたいと思っても言い出しにくくなるという事でもあります。 234 | 235 | 基本的に合わない職場は時間の無駄なので、すぐに離脱するのが良いのですが、紹介で入った場合、感情的な要素がそれを阻む可能性があります。 236 | 237 | ### 人の紹介を使う際の注意点 238 | 239 | 人の紹介を全く否定する訳ではありません。 240 | 241 | しかし、以下の点を意識したほうが良いでしょう。 242 | 243 | - 他人に期待しすぎない 244 | - どんなに仲良くなったとしても紹介してくれないケースだってある 245 | - むしろ紹介して貰えないケースのほうが圧倒的に多い 246 | - 紹介して貰えたらラッキー程度に思っておく 247 | - 人脈作りにばかり力を入れて学習を疎かにしない 248 | - 毎週勉強会（その後交流会）でGitHubは全く更新されていない、という状況は避ける 249 | 250 | 人脈はあったほうが良いですが、TwitterやGitHub、Qiita等で情報発信して仕事を増やしていけば自然と人脈は出来てくると考えます。 251 | 252 | またリアルな集まりやイベントに高頻度で参加するとかなりの時間を使ってしまいます。 253 | 254 | 先程も触れましたが、[Stack Overflow](https://ja.stackoverflow.com/) の質問やTwitter上のリプやDMを送る方法でもコミュニケーションは取れます。 255 | 256 | 今はオンラインサロン等もあるので、そこに参加する等でも良いでしょう。 257 | 258 | どちらにせよ、メインのリソースは学習や自分のサービス作りに当てたほうが最終的には成果を出しやすいというのが私の意見です。 259 | 260 | この点を十分に意識出来ているのであれば、人の紹介というのは有効な手段だと考えて良いでしょう。 261 | -------------------------------------------------------------------------------- /docs/tips/ITSkillLearningMethod.md: -------------------------------------------------------------------------------- 1 | # IT技術の学習方法 2 | 3 | ## この記事の概要 4 | 5 | IT技術の学習を進める上でのコツ等を記載します。 6 | 7 | 私は独学で未経験からWebエンジニアになった経験があるので実体験を元に書かせて頂きます。 8 | 9 | 人によってベストなやり方というのは変わってくるので何かの参考になれば幸いです。 10 | 11 | ## 学習を行うメリット 12 | 13 | 学習を継続的に続けるメリットは下記のようなモノがあると考えます。 14 | 15 | 1. 高待遇な案件にアサイン出来る可能性が向上する（または高待遇な職場に就職出来る） 16 | 17 | スキルが向上するので、その分だけ高待遇な職場に行ける可能性が高くなるという理屈です。 18 | さらに、そういう職場は周りの人間のレベルも高い傾向にあるので、その人達から色々吸収出来ればさらにスキルが向上していくという好循環になりやすいです。 19 | 20 | スキルが十分ではない場合、この逆になります。 21 | 22 | レベルが低い職場は周りの人間のスキルも低い傾向が高く、さらに人間的にも終わっている上司等いたりします。 23 | 24 | 労働環境も悪い傾向にあり、学習の時間と意欲を奪われ、さらにやる気がなくなると言った悪循環に陥ります。 25 | 26 | 2. 自分に自信がつく 27 | 28 | とても大事な事です。個人的にはこれが一番のメリットだと考えます。 29 | 30 | スキルが向上する事により自分に自信が持てます。転職や独立（何をやるかによる）のハードルが下がります。 31 | 32 | もし現在会社と何らかの労働契約を結んでいる場合はその会社との交渉で優位に立てます。（スキルUPしてその会社で実績積んでいるという前提） 33 | 34 | ITエンジニアは不足気味で売り手市場（この記事を書いている2017年現在）なのも、追い風になっています。 35 | 36 | 学習を行っていない場合、転職しようと思っても自信が持てないので、会社との交渉は常に不利になってしまいます。 37 | 38 | 最悪、理不尽な扱い（過度な残業、パワハラ、セクハラ等）を受けても、「働く場所がなくなったら」等と考えてしまい言いなりになってしまうケースもあります。 39 | 40 | まあそもそも、過度な残業、パワハラ、セクハラ等をやるような会社とか上司は存在しないほうが世の中の為です。 41 | よって潰れてくれという話ですが、現実このような会社は存在しますし、それらの犠牲になった人間を私は何人も見てきました。 42 | 43 | またここまで最悪なケースにならない場合でも安い給料で都合良く使われるという事は普通に良く聞く話です。 44 | 45 | ## 学習項目の分類 46 | 47 | 私はIT技術の勉強は大きく3つに分けられると考えます。 48 | 49 | ### 基礎技術 50 | 51 | 何を基礎とするかは人によっても異なるのですが、私は下記のような事が基礎だと考えています。 52 | 53 | 1. アルゴリズムとデータ構造 54 | 2. Linuxの基礎技術（コマンド使い方、OSの基礎的な事） 55 | 3. HTML CSSの基礎文法 56 | 4. ネットワークの基礎技術（TCP/IP、DNS、セキュリティ、暗号化、等） 57 | 5. コーディングの基礎（良い名前を付ける、分かりやすいコードを書く技術、テストコードを書く技術、セキュアコーディング） 58 | 6. 設計（オブジェクト指向、デザインパターン） 59 | 7. DB（SQL、テーブル設計、SQLチューニング） 60 | 61 | 以下の内容もバージョンアップはそれなりに早いですが、根幹的な部分はそう変わらないので基礎に分類します。 62 | 63 | 8. フロントエンドで動くプログラミング言語の基礎技術（WebだとJavaScript） 64 | 9. バックエンドで動くプログラミング言語基礎技術（Java PHP Ruby Python Node.js Scala Go等） 65 | 66 | バックエンドで使える言語は種類が多く（ここに挙げたモノ以外にもたくさん種類がある）全てを極めるのは正直難しいです。 67 | 68 | しかし基礎的な使い方やその言語の特徴を抑えるだけなら、学習を継続していけば不可能ではありません。 69 | 70 | これらの基礎技術だけでもWebサービスを作る事は出来ます。 71 | 72 | しかし実際にはほぼ全ての現場で何らかのフレームワークが導入されていたり、AWSのようなクラウドサービスを使っていたりします。 73 | 74 | これらの基礎技術は、そのまま実践で使える特効薬ではありませんが、しっかり習得しておく事で応用技術（後で説明します）の習得コストを大幅に下げる事が出来ます。 75 | 76 | ### 応用技術 77 | 78 | 基礎技術以外の技術を応用技術と呼びます。（私が勝手に呼んでいるだけでそういう呼称は公式にはありません） 79 | 80 | 応用技術には以下のようなモノがあります。（多すぎて書ききれないです） 81 | 82 | - [AWS](https://aws.amazon.com/jp/)のようなクラウドサービス 83 | - [Docker](https://www.docker.com/)のようなコンテナ技術 84 | - [Vagrant](https://www.vagrantup.com/)のような仮想マシンを操作する技術 85 | - [Ansible](https://www.ansible.com/)のような構成管理ツール 86 | - [Ruby on Rails](http://rubyonrails.org/) のようなアプリケーションフレームワーク 87 | - [Vue.js](https://jp.vuejs.org/index.html) や [React](https://reactjs.org/) のようなモダンなフロントエンドを開発する為のライブラリ 88 | 89 | 他にも [WebAssembly](https://developer.mozilla.org/ja/docs/WebAssembly) のような新しい技術や [WebSocket](https://ja.wikipedia.org/wiki/WebSocket)、[HTTP2](https://ja.wikipedia.org/wiki/HTTP/2) 等の比較的新しいプロトコル等もあります。 90 | 91 | これらの応用技術は習得すれば、爆発的に生産性が上がる事もあり、実践投入するとすぐに効果が出る事も多いです。 92 | 93 | 「こんなに簡単にWebサービスが作れるのか」と圧倒される事もありますが、基本的には裏側で基礎技術が使われており、それを便利に使えるような形にしてあるという事が多いです。 94 | 95 | 進化の流れが非常に早く1年も経つとあっという間に、APIが変更されているという事も珍しくありません。 96 | この流れが早いという事はメリットとも言えますが、デメリットでもあります。 97 | 98 | 開発者としては便利な機能で開発が楽になるので大歓迎ですが、反面、最新版を追従し続けるのは大変だという点もあります。（ネット上の記事等は1年もすればあっという間に古い情報になります） 99 | 100 | ### その他技術 101 | 102 | 分類が難しいのですが、ここに上げました。 103 | 104 | 基本的には基礎技術よりで、開発を進める上では避けては通れないモノを挙げてあります。（基礎に分類してもいいかも） 105 | 106 | - Gitを初めとするバージョン管理システムの使い方 107 | - 自分に合うエディタやIDEを見つけて生産効率を上げる努力をする 108 | - 英語の学習（エンジニアは英語が大変重要です） 109 | 110 | これらは開発を効率的に進める為には、必要不可欠です。 111 | 112 | ## 学習の基本的な考え方 113 | 114 | 最初に結論から言うと、開発者として活躍する為には、どの種類の技術（基礎、応用、その他）も必要になります。 115 | 116 | すぐに実戦で効果があるので、応用技術の学習に走りがちなのですが、私は基礎技術を重視した学習をオススメします。 117 | 118 | 基礎技術はスポーツで言う、筋トレや走り込み、英語学習で言うなら英単語の習得や基礎文法の習得のようなモノです。 119 | すぐには効果は現れませんが、やっておく事で応用技術の学習コストを大きく下げる事が出来ます。 120 | 121 | とは言っても、応用技術の学習も必要なので、以下のような事を意識すると良いでしょう。 122 | 123 | ### その裏側でどのような基礎技術が行われているか理解する（応用技術学習） 124 | 125 | 応用技術の裏側では基礎技術が使われています、例えば [Rails Active Record](https://railsguides.jp/active_record_basics.html)。 126 | 127 | これはSQLを書かなくてもプログラマが少しの記述量でデータベースの操作が出来る大変便利なモノです。 128 | 129 | しかし当然データベースの操作にはSQLが必要で、最終的にはActive RecordがSQLを生成して実行しています。 130 | このように裏側で何か使われているかを把握するという事です。 131 | 132 | 把握していれば何か問題が起きても基礎技術と同様のアプローチで解決が出来る可能性はあります。 133 | しかしActive Recordは裏でSQLを使っているという事を知らないと問題解決に非常に時間がかかってしまうリスクがあります。 134 | 135 | ### どのような背景で応用技術が誕生したかを理解する（応用技術学習） 136 | 137 | 例えば、 [React](https://reactjs.org)。 138 | 「何故この技術が生まれたのか」「jQueryとかめっちゃ流行ってたけどそれじゃダメなのか」「Virtual DOMとは何なのか」 139 | 140 | このような疑問を持ち、自分なりの答えを得る事が大事だと思っています。（上記の件に関して気になった方は調べてみましょう） 141 | 142 | 技術というのは基本的に問題解決の手段なので、新技術が生まれるにはそれなりの理由があります。 143 | また同じように流行っている技術にもそれなりの理由があります。 144 | 145 | これらを知り、自分なりの答えを見つける事で、今後Webがどのような方向に発展していくのか予想を立て次の学習を有利に進める事も可能です。（予想が外れる事もたくさんありますが） 146 | 147 | ### この技術を使ってどのような問題が解決出来るだろうと考える（応用技術学習） 148 | 149 | 日々便利なツールやライブラリ、フレームワーク等がリリースされていますが、技術というのは問題解決の道具として使って初めて価値が出ます。 150 | 151 | エンジニアとは「技術によって問題解決をする人」の事を指すと私は考えます。 152 | 153 | よって便利な応用技術を学ぶ際は「これを使って◯◯のあれを解決しよう」とか「これを利用してこんなアプリを作ったらいいかも」等を考えながらやるようにしましょう。 154 | 155 | このように考える事で技術力を活かすようにしましょう。ただ学習だけしていても、それが何らかの成果（自分のサービスが出来た、収入が上がった）に結びつかないとやる気を維持するのは難しいでしょう。 156 | 157 | 私は以下のような方法をオススメします。 158 | 159 | - 自分の気に入った技術やサービスの開発が出来る環境に行く（転職、部署異動） 160 | - 自分でWebサービスなりアプリ等を開発し世の中に公開（一番オススメ、意思決定も自分1人なので決断すれば早い） 161 | 162 | ## 具体的な学習方法 163 | 164 | ここからは筆者が行っている具体的な学習方法を紹介します。 165 | 166 | これが全て正解という訳ではないので、自分に合った方法を見つけて下さい。 167 | 168 | ### 1. [Qiita](https://qiita.com/) やブログ等で最新情報をチェックする 169 | 170 | 一番手軽に出来る勉強法です。 171 | 172 | 主な目的は最近の技術トレンドをチェックする事です。 173 | 174 | チェックするブログや記事ですが、主に以下のような物をチェックしています。 175 | 176 | - [Qiita](https://qiita.com/) 177 | - 気になるタグをフォローするとタイムラインに上がってきて便利です 178 | - [はてなブックマーク(テクノロジー)](http://b.hatena.ne.jp/hotentry/it) 179 | - [Publickey1](http://www.publickey1.jp/) 180 | 181 | 他にもTwitterでエンジニア専用アカウントを作り、優秀な技術者をフォローするのも有効です。 182 | 183 | またスマホアプリのGoogleはかなり優秀で技術系の記事等を調べているとニュースとして検索画面の下に表示させてくれます。 184 | 185 | ※ これが地味に情報収集の役にたっています。 186 | 187 | 他にも [エンジニアの情報収集法まとめ](https://qiita.com/nesheep5/items/e7196ba496e59bb2aa28) という良い記事もあったのでこちらも参考にすると良いでしょう。 188 | 189 | この方法は手軽に出来る反面、ただ情報を見るだけなので、これだけやっても当然技術力は向上しません。 190 | 191 | ただ次に何をやるかを決める際の最初の一歩にはなるので結構大事だったりします。 192 | 193 | 私の場合はPCでじっくり見るのではなくスマホで移動時間に電車の中なので見るようにしています。 194 | 195 | そうする事で時間を有効活用するように心がけています。 196 | 197 | ### 2. 書籍を読む 198 | 199 | ある程度、その技術に慣れてきたら書籍を読むと知識が体系的に整理されるのでオススメです。 200 | 201 | ただし、初心者がいきなり書籍から入るのはオススメ出来ません。 202 | 203 | 書籍はある程度の前提知識を持っている前提で書かれている事が多いです。 204 | 205 | 初心者はその前提知識が欠けている為、途中で挫折してしまう可能性が高いです。 206 | 207 | またIT技術は手を動かす事が極めて重要なので、書籍を読んで知識が付いても実戦で出来るようにならないと意味がありません。 208 | 209 | しばらくやってみると分かりますが、「知識だけ」の状態と「実際に動くコードを作れる」は天と地ほど違います。 210 | 211 | 一通り手を動かして、ある程度その技術に触れた事がある状態で書籍を読んだほうが知識も入りやすくなるので、そのように進める事をオススメします。 212 | 213 | 私の場合は書籍を読むのは寝る前の1時間と決めています。ネットの記事と同じように移動中に読むのも良いでしょう。 214 | 215 | ### 3. プログラミングをする & 環境構築を行う 216 | 217 | 一番オススメの方法です。 218 | 219 | IT技術の習得は手を動かす事が最も重要です。 220 | 221 | 先に挙げた2つは補助であくまでも手を動かす事がメインの学習方法です。 222 | 223 | 実際にコードを書く上でどのような方法があるのか、いくつか例を挙げます。 224 | 225 | #### 有名なアルゴリズムをコードで書いてみる 226 | 227 | 基本的なソートのアルゴリズムや探索のアルゴリズムを実際にコードで書いてみましょう。 228 | 229 | 新しく言語を習得する際にも簡単なアルゴリズムを書いてみる事である程度その言語に慣れる事が出来、基礎も強化出来るのでオススメです。 230 | 231 | [paiza](https://paiza.jp/) 等のサイトがオンラインでアルゴリズムの学習が出来、ある程度のスキルチェックも出来るのでオススメです。 232 | 233 | #### [ドットインストール](https://dotinstall.com/) 等の動画サービスでレッスンを行う 234 | 235 | 初心者にも分かりやすいのでオススメです。 236 | 237 | ドットインストールは「◯◯を作ってみよう」のようなタイトルで実際に簡単なアプリケーションを作ってみる形式になっているのが良い点です。 238 | 239 | ※ 実際一番、学習に効果的なのは動くWebサービスを自分で作る事なので。 240 | 241 | 初めはただ動画の通りにやるだけでも良いのですが慣れてきたら以下の事を意識してみましょう。 242 | 243 | - 動画で紹介されている変数名や関数名、クラス名等をもっと良い命名がないか考えてみる 244 | - 動画で紹介されているレッスンを元にオブジェクト指向やデザインパターンを適用して再設計してみる 245 | - [PHPでTwitterログインを実装しよう](https://dotinstall.com/lessons/tw_connect_php_v3) 等の「◯◯で◯◯を作ろう」系のレッスンで別の言語、別のフレームワークで同じ物を実装してみる 246 | 247 | これらを意識する事でコーディングスキルと設計スキルをより効率的に身につける事が出来ます。 248 | 249 | #### 自分でWebサービスを作り公開してみる 250 | 251 | 実戦がもっとも学習効果も高いので一番オススメな方法です。 252 | 253 | ※ ただ最初は自分で作りたい物が分からないみたいなケースもあるので、はじめのうちは [ドットインストール](https://dotinstall.com/) から始めても良いです。 254 | 255 | エンジニアは世の中の問題を技術によって解決するのが仕事なので、その為に必要な考え方も身につき、さらに万が一サービスがヒットすれば不労所得を得られる可能性もあります。 256 | 257 | またサービス公開には環境構築やネットワークの技術等、一通りの技術が必要なので、Webサービス開発に必要なスキルが体系的に身につく点も非常に良いです。 258 | 259 | ※ 本カリキュラムの最後には実際に動くWebサービスを作成して頂きます。 260 | 261 | #### オープンソースのプロジェクトにプルリクエストを送ってみる 262 | 263 | いきなりハードルが高いと感じる初心者もいるでしょう。 264 | 265 | オープンソースのプロジェクトは誰でも参加出来る権利があるので、慣れておく事をオススメします。 266 | 267 | 自分で直すのが難しい場合はバグ等を見つけた際にissueを作るだけでも良いです。 268 | 269 | 以下に初心者がオープンソースに初めて参加する際、参考になりそうな記事があったので載せておきます。 270 | 271 | - [初めてのPull Requestを送りたいあなたへ](https://qiita.com/icoxfog417/items/3d23aa154b483ef611d3) 272 | - [意外ととっつきやすいOSS開発参加方法まとめ](https://qiita.com/shunsuke227ono/items/94dd6e707d34a1da2617) 273 | - [オープンソースプロジェクトでバグを修正する方法 : あるNodeJSモジュールへの修正を例に](http://postd.cc/how-to-fix-a-bug-in-an-open-source-project/) 274 | 275 | オープンソースはWebの世界に大きな影響を与えています。 276 | 277 | その文化に触れる為にも参加出来る時は参加する事をオススメします。 278 | 279 | #### コードを書く上で大事な事 280 | 281 | 1. 書いたコードは必ず何らかの形でアウトプットする 282 | 283 | ソースコードならGitHubやGist、環境構築であれば [Qiita](https://qiita.com/) の記事を書く。 284 | 285 | とにかくアウトプットした内容は積極的に外部に公開する事です。 286 | 287 | 参考までに私が過去に書いた記事 [Amazon API Gateway の Custom Authorizer で ServerlessなAPIを作ってみた](https://qiita.com/keitakn/items/508744fe7dc3b5f75d4c) を共有させて頂きます。 288 | 289 | ※ これはGitHub上にサンプルコードを作成して、その設計思想等をQiitaの記事で説明しています。 290 | 291 | ソースコードや記事を公開する事で私は下記のようなメリットが得られると考えます。 292 | 293 | - 人に見られているという意識が働くので適当な書き方や間違った情報を載せられないという心理が働き成果物の質が向上する 294 | - 対象の技術に詳しい上級エンジニアからコメント等でアドバイスを貰える可能性がある 295 | 296 | 他にも、企業の採用担当からスカウトの連絡が来たりする事もあります。 297 | 298 | 同様の問題で悩んでいる他のエンジニアを助ける事にも繋がります。 299 | 300 | オープンソースソフトウェアの世界はこのように自分のノウハウを積極的に公開する文化があったからこそ、進化のスピードが早いのです。 301 | 302 | [学習を続けるコツ](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/HowToContinueLearning.md) という記事にGitHubを使った学習方法を紹介しています。 303 | 304 | 参考にしてみて下さい。 305 | 306 | 2. 常に実戦だと思って書く 307 | 308 | ソースコードや記事を公開する形にしていると、自然に意識するかもしれませんが、常に実戦のつもりでコードを書きましょう。 309 | 310 | - 良い命名を心がける 311 | - オブジェクト指向（または関数型）での設計を意識する 312 | - テストコードは出来る限り用意する 313 | 314 | これらを意識したコードを自分のGitHubに上げておくと、実戦で一部流用出来たりして実際の開発が早く進んだりする事も多いのでオススメです。 315 | 316 | 逆にこれらを意識せずに、適当なコードを公開していると、アプトプットが逆にマイナス効果となってしまう事もあります。 317 | 318 | アウトプットを見た人から「汚いコードを書く奴」や「適当な記事を書く奴」と思われてしまうようなアウトプットは避けましょう。 319 | 320 | ## 参考記事 321 | 322 | 最近見た中で特に参考になった記事を挙げさせて頂きます。 323 | 324 | この記事で私が書いている事とも共通する部分もありますが、どれも非常に参考になる内容です。 325 | 326 | - [勉強会聴講：「エンジニアとしてこの先生きのこるために」](https://qiita.com/sakaizay/items/e4ae74bfecd026925e3b) 327 | - [エンジニアの次のステップへの勉強法](https://qiita.com/newta/items/f4aff8cdd8706d5d08c5) 328 | - [エンジニアになる覚悟](https://speakerdeck.com/yosuke_furukawa/enzinianinarujue-wu) 329 | 330 | 以下は動画です。 331 | 332 | - [エンジニアが毎日チェックするべき情報源についてご紹介します。](https://www.youtube.com/watch?v=YaGXyEFSbok) 333 | - [AI時代に生き残れるエンジニアの条件とは](https://www.youtube.com/watch?v=cHaE5oFaVuI) 334 | 335 | [AI時代に生き残れるエンジニアの条件とは](https://www.youtube.com/watch?v=cHaE5oFaVuI) は少し特殊で「どのようなエンジニアを目指すべきか」という点でとても参考になります。 336 | 337 | ## 具体的な学習方法まとめ 338 | 339 | 様々な方法を紹介させて頂きました。 340 | 341 | それぞれ自分にあった方法を見つけて頂ければ良いです。 342 | 343 | IT技術は進化のスピードが早いので、学習に終わりはありません、常に学び続ける事が必要です。 344 | 345 | その為には学習を習慣化する事が必要になります。 346 | 347 | 毎日30分でも良いので、何らかのアウトプットを行いましょう。 348 | 349 | [学習を続けるコツ](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/HowToContinueLearning.md) という記事を書いてあります。 350 | 351 | こちらも参考に学習を継続する事を目指しましょう。 352 | -------------------------------------------------------------------------------- /docs/tips/README.md: -------------------------------------------------------------------------------- 1 | # Tips 2 | 3 | このディレクトリ（tips）には学習を進める上で役に立つであろう豆知識を記載していきます。 4 | 5 | 以前Wikiに書いてあった内容は全てこのディレクトリ配下に移動させました。 6 | 7 | 一応、一通り目を通しておく事をオススメします。 8 | 9 | 下記に特に読んで欲しい記事を記載しておきます。 10 | 11 | # 学習方法に関する記事 12 | 13 | - [IT技術の学習方法](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ITSkillLearningMethod.md) 14 | - [学習方法のアンチパターン](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/AntipatternOfLearningMethod.md) 15 | - [学習を続けるコツ](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/HowToContinueLearning.md) 16 | - [オススメの書籍](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/RecommendedBooks.md) 17 | 18 | # 古い常識に囚われる事の危険性を書いた記事 19 | 20 | - [社畜にならない事の重要性](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/Shachiku.md) 21 | - [転職マニュアル](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/ChangeJobManual.md) 22 | -------------------------------------------------------------------------------- /docs/tips/RecommendedBooks.md: -------------------------------------------------------------------------------- 1 | # オススメの書籍 2 | 3 | [学習方法のアンチパターン](https://github.com/keitakn/web-developer-ojt/blob/master/docs/tips/AntipatternOfLearningMethod.md) では書籍から学習するのはオススメ出来ないと批判的な意見を書きました。 4 | 5 | しかしあくまでも最初の一歩としてはオススメ出来ないという話であって、ある程度その技術に触れた事があるのであれば書籍を読む事は有効な学習方法です。 6 | 7 | ここでは私が今までに読んだ書籍の中で特にオススメな書籍を紹介させて頂きます。 8 | 9 | ※ もちろん、ここに載っているもの以外にも良い書籍はたくさんありますので、あくまでも参考程度に捕らえて下さい。 10 | 11 | ## コーディングに関する書籍 12 | 13 | ### [リーダブルコード](https://www.amazon.co.jp/dp/4873115655) 14 | 15 | メンテナンス性の高いコードを書く為のノウハウが載っている本です。 16 | 17 | 言語問わずに長く使える技術が身につくので、かなりオススメの一冊です。 18 | 19 | 私がコードレビューを行う際はこの書籍に載っている内容を参考にしています。 20 | 21 | 本の中でも触れていますが、プログラミングでは変数名やクラス名、ファイル名、URL等様々なモノに名前を付けます。 22 | 23 | この良い名前を付けるという行為が極めて重要なので、この部分だけでも読む事をオススメします。 24 | 25 | 良い名前は良い設計に自然と繋がります。 26 | 27 | 良い名前に関しては以下の記事も参考になるので、読んで欲しいです。 28 | 29 | - [モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう](https://qiita.com/jnchito/items/459d58ba652bf4763820) 30 | - [よりよいネーミングを目指して](https://qiita.com/takasek/items/693c57dc9ddc6c1eb1ba) 31 | - [プログラミングでよく使う英単語のまとめ【随時更新】](https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923) 32 | - [うまくメソッド名を付けるための参考情報](https://qiita.com/KeithYokoma/items/2193cf79ba76563e3db6) 33 | - [うまくクラス名を付けるための参考情報](https://qiita.com/KeithYokoma/items/ee21fec6a3ebb5d1e9a8) 34 | 35 | ## 設計に関する書籍 36 | 37 | ### [現場で役立つシステム設計の原則](https://www.amazon.co.jp/dp/477419087X) 38 | 39 | オブジェクト思考での設計手法の基礎が載っている書籍です。 40 | 41 | プログラミングに関する設計だけではなく、DBの設計やREST APIの設計等幅広く網羅しています。 42 | 43 | 比較的新しい書籍ですが、最初に読む設計本としてオススメです。 44 | 45 | ### [オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方](https://www.amazon.co.jp/dp/B01L8SEVYI) 46 | 47 | オブジェクト指向で設計する為の考え方が身につくのでオススメです。 48 | 49 | ただし読む前にRubyの基礎をやっておいたほうが良いでしょう。 50 | 51 | Rubyで書かれていますが、この本に載っている考え方は他の言語でも応用出来る事が多いです。 52 | 53 | こちらは記事ですが、[オブジェクト指向と10年戦ってわかったこと](https://qiita.com/tutinoco/items/6952b01e5fc38914ec4e) という記事もオススメです。 54 | 55 | オブジェクト指向とは何か？を分かりやすく説明してくれています。 56 | 57 | ### [Webを支える技術 -HTTP、URI、HTML、そしてREST ](https://www.amazon.co.jp/dp/4774142042) 58 | 59 | Webの歴史や基礎知識、さらにWebサービスの設計手法を網羅した書籍です。 60 | 61 | 少々古いですが、今でもオススメ出来ます。 62 | 63 | ※ 書籍の中でXMLに関する解説にかなりのページを使っていますが、近年はデータのやり取りで利用するのはJSONがメインなので、この点だけは注意したほうが良いでしょう。 64 | 65 | ### [エリック・エヴァンスのドメイン駆動設計](https://www.amazon.co.jp/dp/4798121967) 66 | 67 | 変更に強いソフトウェアを設計する為のドメイン駆動設計という設計手法を解説した書籍です。 68 | 69 | かなり難解なので、まず初めに [現場で役立つシステム設計の原則](https://www.amazon.co.jp/dp/477419087X) を読んでからチャレンジする事をオススメします。 70 | 71 | ### [実践ドメイン駆動設計](https://www.amazon.co.jp/dp/479813161X) 72 | 73 | [エリック・エヴァンスのドメイン駆動設計](https://www.amazon.co.jp/dp/4798121967) と同じくドメイン駆動設計を解説した書籍ですが、こちらは実際にドメイン駆動設計で開発した人の経験を元に実装の具体案を詳しく解説しています。 74 | 75 | ### [マイクロサービスアーキテクチャ](https://www.amazon.co.jp/dp/4873117607) 76 | 77 | マイクロサービスと呼ばれる設計手法を解説した書籍です。 78 | 79 | マイクロサービスとは簡単に言うと、小さなシステム（これをサービスという）をたくさん繋ぎ合わせて1つの大きなシステムを構築しようという考え方です。 80 | 81 | このような作り方をする事でサービス毎に最適な技術を選択したり、障害の影響を局所化出来たりと様々なメリットがあり、近年このような手法で設計される事が多いです。 82 | 83 | ※ マイクロサービスにも当然デメリットがあり、全てのシステムで適応出来るような物ではありません。 84 | 85 | 下記の記事はマイクロサービスのメリットやデメリットを解説した記事になります。 86 | 87 | - [マイクロサービス・アーキテクチャのメリット／デメリットまとめ](https://qiita.com/hhiroshell/items/f5d9c0de71f2a509350c) 88 | - [「マイクロサービス」のメリットをざっくり言うと「変化に対応しやすい」こと──ただしファウラー氏は“使い過ぎ”を警告](https://knowledge.sakura.ad.jp/3377/) 89 | 90 | ### [Web API: The Good Parts](https://www.amazon.co.jp/dp/4873116864) 91 | 92 | マイクロサービスアーキテクチャでもよく出てくるWeb APIの設計手法に関する書籍です。 93 | 94 | Web APIの設計に関しての基礎知識が手に入るので、読んでおいて損はないでしょう。 95 | 96 | 完全なマイクロサービスで設計しないにしても、Webアプリ、iOS版、Android版のネイティブアプリ等、UIが復数存在するケース等では間違いなくWeb APIが登場するので、Web APIの設計スキルは極めて重要であると言えるでしょう。 97 | 98 | [IoT](https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%8E%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%8D%E3%83%83%E3%83%88) 等の普及により今後さらに重要性が増していくと思われます。 99 | 100 | ネットの記事になりますが、Web APIの設計手法に関しては下記の記事も参考になります。 101 | 102 | - [翻訳: WebAPI 設計のベストプラクティス](https://qiita.com/mserizawa/items/b833e407d89abd21ee72) 103 | - [「WebAPI 設計のベストプラクティス」に対する所感](https://qiita.com/ryo88c/items/0a3c7861015861026e00) 104 | 105 | この2つを合わせてみる事をオススメします。 106 | 107 | ### [サーバーレスシングルページアプリケーション](https://www.amazon.co.jp/dp/4873118069) 108 | 109 | サーバーレスとはAWS Lambda等のホスティングサービスを利用して設計を行う為の手法です。 110 | 111 | マイクロサービスの1サービスを担わせるのも有効です。 112 | 113 | これにより、サーバの管理の手間やスケールアウト（Webサーバを増やす事）をAWS等のサービスが裏側でやってくれるので、急なアクセスの増加にも耐えられる事や料金も使った分だけの課金（従来のEC2インスタンス等は起動させるだけでお金がかかるが、こちらは本当に純粋に利用した分だけ課金）なので料金にも優しいです。 114 | 115 | これだけ言うと魔法のような設計手法ですが当然デメリットもあります。 116 | 117 | ※ デメリットについては、本カリキュラムでサーバーレスアーキテクチャで開発を行う際に説明します。 118 | 119 | いくつかのデメリットはあるものの、個人的にはかなり注目しているアーキテクチャです。 120 | 121 | 書籍の内容ですが、サーバーレスアーキテクチャで実際にアプリケーションを作る体系的な説明をしていますが、注意点として載っている方法の中には既に古くなっている物もあるので、そこは注意しましょう。 122 | 123 | ## インフラに関する書籍 124 | 125 | ### [インフラエンジニアの教科書](https://www.amazon.co.jp/dp/4863541333) 126 | 127 | 最近はAWS等のクラウドサービスを使う事が一般化してきているので、あまり裏側に触れる事はないかもしれませんが、裏側で何が行われているかを知る事は重要です。 128 | 129 | インフラの入門本としてオススメです。 130 | 131 | ### [試して理解 Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識](https://www.amazon.co.jp/dp/477419607X) 132 | 133 | Linuxの動きをサンプルコード付きで解説しています。 134 | 135 | サンプルコードはC言語とPythonで書かれていますが、それらの言語に詳しくない人でも十分に解読可能です。 136 | 137 | この本に載っているサンプルコードを別の言語（例えば [Rust](https://www.rust-lang.org/ja-JP/) や [Golang](https://golang.org/)） で書き直したりするとさらに学習効果が高まるでしょう。 138 | 139 | 難易度は結構高いのである程度Web開発が出来るようになってより基礎を深掘りしたい時に読む事をオススメします。 140 | 141 | ## データベースに関する書籍 142 | 143 | ### [SQLアンチパターン](https://www.oreilly.co.jp/books/9784873115894/) 144 | 145 | SQL自体の解説というよりは主にテーブル設計時のアンチパターンを紹介した本です。 146 | 147 | ここに書いてあるアンチパターンを避ければ自然と良いテーブル設計が出来るでしょう。 148 | 149 | [データベース設計](https://github.com/keitakn/web-developer-ojt/blob/master/docs/system-design/database.md) でもこの本に書かれている事を一部紹介しています。 150 | 151 | ### [達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ](https://www.amazon.co.jp/dp/4798124702) 152 | 153 | こちらもオススメです。 154 | 155 | ただある程度はデータベースを触った事がないと読んでもピンと来ない（これは書籍全般的に言える事）ので最初は [RDBMSの基礎知識](https://github.com/keitakn/web-developer-ojt/tree/master/docs/mysql) を見て、ある程度データベースの操作やテーブル作成等を行ってから読んだようが良いです。 156 | 157 | ## アルゴリズムに関する書籍 158 | 159 | ### [おうちで学べるアルゴリズムのきほん](https://www.amazon.co.jp/dp/4798145289) 160 | 161 | アルゴリズムの入門本として最適です。 162 | 163 | この本の良いところはアルゴリズムがどのように使われているか身近な例を交えて紹介している点です。 164 | 165 | サンプルコードこそ少ないですが、初学者でも挫折の可能性は低いでしょう。 166 | 167 | また本ではありませんが、以下のサイトが非常に分かりやすいです。 168 | 169 | http://algorithm-visualizer.org/ 170 | 171 | アルゴリズムをビジュアルで確認出来るので理解が進みます。 172 | 173 | ### [アルゴリズム図鑑（スマホアプリ）](https://itunes.apple.com/jp/app/%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0%E5%9B%B3%E9%91%91/id1047532631?mt=8) 174 | 175 | スマートフォンアプリですが、オススメです。 176 | 177 | これもビジュアルでアルゴリズムの動きを分かりやすく解説しています。 178 | 179 | 公開鍵認証や暗号化アルゴリズム等の複雑なアルゴリズムもこれを見れば理解しやすいです。 180 | 181 | ## プロジェクト管理 182 | 183 | ### [SCRUM BOOT CAMP](https://www.amazon.co.jp/dp/4798129712) 184 | 185 | アジャイル開発の一番有名なフレームワーク（多分）であるスクラムの入門本です。 186 | 187 | 漫画形式で読みやすいので、最初の1冊としてオススメです。 188 | 189 | ### [アジャイルな見積りと計画づくり](https://www.amazon.co.jp/dp/4839924023) 190 | 191 | アジャイル開発でプロジェクトの計画と見積もりを行う為の手法が書かれた書籍です。 192 | 193 | ここに出てくる相対見積もりという考え方はプロジェクト管理において非常に重要だと私は考えます。 194 | 195 | ## その他の書籍 196 | 197 | ### [UNIXという考え方―その設計思想と哲学](https://www.amazon.co.jp/dp/4274064069) 198 | 199 | 古い本ですがオススメです。 200 | 201 | 具体的な事例はあまりないですが、ここに書いてある考え方は、プログラミング、設計、プロジェクト管理等、様々な場面に応用出来ます。 202 | 203 | 比較的新しい [マイクロサービスアーキテクチャ](https://www.amazon.co.jp/dp/4873117607) もこの書籍の中で言われている、「1つのことをうまくやるようにせよ」という考え方をWebの世界に持ってきた事が元になっているし、「できる限り早く試作品を作れ」という考え方はアジャイル開発にも通じる考え方です。 204 | 205 | ### [達人プログラマー 職人から名匠への道](https://www.amazon.co.jp/dp/427421933X) 206 | 207 | 良いプラグラマになる為の考え方や道筋を示した本になります。 208 | 209 | これを読んだだけでは、何か具体的な事が身につく事はないですが、どのような事を学習すれば良いかの指標として見るとかなり良い書籍だと思います。 210 | 211 | ### [プログラマが知るべき97のこと](https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/) 212 | 213 | 元々有名な書籍だったのですが今ではWebで読めます。 214 | 215 | 毎日少しづつ読んでいくと良いでしょう。 216 | 217 | 内容的には良いプログラマを目指す為に知るべき事が載っています。 218 | 219 | 技術的な事から心構え的な事まで様々です。 220 | 221 | 「36. ハードワークは報われない」や「12. コードは設計である」のような項目を読むと、旧来の日本的な社畜思想がいかに間違っているかが良く分かります。 222 | 223 | 書籍版は [こちら](https://www.amazon.co.jp/dp/4873114799) です。 224 | 225 | ## 書籍の選び方 226 | 227 | ここに紹介した以外にも良い書籍はたくさんあります。 228 | 229 | あくまでも私の考え方ですが、私が選定基準にしているのは以下の3つです。 230 | 231 | - 言語を問わずに利用出来る知識・技術が載った書籍を選ぶ 232 | - なるべく多くの技術者に読まれている書籍を選ぶ 233 | - 長く使える基礎知識が載っている書籍を選ぶ 234 | 235 | 逆に下記のような書籍は買わないようにしています。 236 | 237 | - 特定の言語でしか使えない知識が大部分を占める書籍 238 | - 一時的に流行っているだけのライブラリやフレームワークの解説本 239 | - ウォーターフォールをベースにしたプロジェクト管理本 240 | - UML等の記法を厳密に解説したような書籍 241 | 242 | ウォーターフォールに関しては私は否定的な考えを持っています。 243 | 244 | Web開発において厳密なウォーターフォールで上手くいった例を私は一度も見た事がありませんし、良い書籍の大半はアジャイル開発を前提として書かれている事が多いです。 245 | 246 | UML等の記法を厳密に解説したような書籍に関しては、ある程度知識として知っているのは良いのですが、正直図形をキレイに書く暇があったらコードを書いたほうが良いという考えからです。 247 | 248 | 私は [ソースコードは設計書であり、コーディングは設計作業である](https://qiita.com/mdstoy/items/5510f94c9ed981cfbb85) という考えに強く賛同しています。 249 | 250 | よってこのような設計書をキレイに書くスキルを磨くなら、キレイなコードや見通しの良いクラス設計を行う技術を身に着けたほうが建設的だと考えるからです。 251 | 252 | このあたりは設計のレッスンで詳しく解説します。 253 | 254 | # 書籍を読む時の考え方 255 | 256 | [学習を加速させるインデックス読書術](https://qiita.com/dkatsura/items/3364b293ed1451a66a8a) という記事があったので紹介します。 257 | 258 | ここに書いてある考え方は非常に有効です 259 | 260 | ネットで調べる時と同じでただのデータストレージと認識すれば良いです。 261 | 262 | また書籍を読むだけでなく読んだ内容を使って何らかのアウトプットを行うと内容がより身につくのでオススメです。 263 | 264 | # 書籍を読む時の考え方 265 | 266 | [【Webエンジニアど素人から３年生ぐらいになるまでに読むと良い本】を段階的にまとめた](https://qiita.com/jjj20/items/3aa5f7f3fc991de17f3f) という記事があります。 267 | 268 | ここに紹介されている本を全て読むという必要はないと思いますが、私が考える書籍の選び方で重要と主張している「言語を問わない知識が身につく」や「長く使える技術が載っている」書籍が多く紹介されています。 269 | -------------------------------------------------------------------------------- /docs/tips/Shachiku.md: -------------------------------------------------------------------------------- 1 | # 社畜にならない事の重要性 2 | 3 | 社畜にならない事は良いエンジニアになる上で大切な事だと考えます。 4 | 5 | その理由は後の章で説明しますが、まずは社畜の定義から考えてみます。wikipediaより引用。 6 | 7 | > 社畜（しゃちく）とは、主に日本で、社員として勤めている会社に飼い慣らされてしまい自分の意思と良心を放棄し奴隷（家畜）と化した賃金労働者の状態を揶揄したものである。 8 | 9 | ネット上でも社畜の定義には様々なモノがあります。 10 | 11 | ここでは私が考える社畜の定義について記載させて頂きます。 12 | 13 | 社畜とは以下の定義を満たしている人物を指します。 14 | 15 | - 会社と自分を分離して考える事が出来ない（滅私奉公の精神、従業員なのに経営者目線とか） 16 | - 常に会社駆動で動く（行動の理由が全て上司や会社の命令） 17 | - 人間関係が会社に偏っている（社内の人間関係を何よりも優先する） 18 | - 権威主義（何が正しいではなく、誰が言ったかで判断する） 19 | - 精神論が心の拠り所（困ったら残業でカバー、周りにも強要する奴は論外） 20 | 21 | 以上になります。 22 | 23 | これらが1つでも当てはまれば社畜の素養があると考えます。 24 | 25 | ## 社畜の何がダメなのか 26 | 27 | 一言で言うと、良いエンジニアの考え方や文化と日本的な社畜思想との相性が悪いからです。 28 | 29 | オープンソースソフトウェアで高い技術力を持つ、技術者達が書いた書籍や記事を読むと日本の社畜思想とは真逆な事が書いてある事が多いです。 30 | 31 | 日本人の多くが社畜思想に取り憑かれてしまう原因として私は日本の義務教育に大きな問題があると考えます。 32 | 33 | 誤解を恐れずに言うと、日本の義務教育というのは社畜を大量生産する為の洗脳教育なのです。 34 | 35 | この件に関しては、様々な記事を書いている人がいるので共有させて頂きます。 36 | 37 | - [問題点ばかり！部活制度が学生に社畜根性を植えつけている](http://www.amamiyashion.com/entry/2016/09/23/200000) 38 | - [日本の教育は社畜を生産する洗脳教育](https://www.ino-kawa.com/?p=130) 39 | 40 | また、学校教育の問題点を指摘したTweetで実に的を得ていると思った物をいくつか載せておきます。 41 | 42 |

まあさ。学校なんてのは、個性をなくすための場所なんですよ。よく言うじゃないですか。「高校生らしい服装を〜」とか。なんですか。高校生らしい、って。要するに、平均化しろってことでしょう。なんだか、ぼくには学校が「鳥から尻尾を切って、飛べなくさせる」場所にしか、もう見えないんですよね。

— プロ奢ラレヤー🍣 (@taichinakaj) 2018年6月7日
43 | 44 |

でもさ。いまどこかしらの分野で活躍している日本人を見ると、ほとんどが「教育工場の最高傑作」というよりも、むしろ、「教育工場で弾かれた欠陥品」みたいなタイプばかりのような気がして、ああ、そういうことね、って思っちゃうよね。結局は、あそこを素早くドロップアウトしたもん勝ちなとこある。

— プロ奢ラレヤー🍣 (@taichinakaj) 2018年6月18日
45 | 46 |

あと「授業中スマホを使うから悪い」みたいなコメントもあって驚きますね

「だから非常時にスマホを取り上げる必要性」になんら結びついてない…

「権力者には絶対服従、疑問も抱いてはならない、いかなる時も」という奴隷の掟があるようですね…

— まいのこ💛デザインと心理研究 (@CreamyMainoko) 2018年6月21日
47 | 48 |

その通りですね…。
基本的に学校という場所は子供の心と思考力を長年かけて潰す最悪の洗脳施設だと思ってます

「大人になってよかったこと」の1番か2番目に「もう学校に行かなくていい」が来るくらい酷い強制収容所でした

— まいのこ💛デザインと心理研究 (@CreamyMainoko) 2018年6月22日
49 | 50 | 日本の教育を簡単にまとめると下記のような点を重視していると言えます。 51 | 52 | - 暗記を重視した受験勉強 53 | - 暗記よりも技術をどう使うかが重要なエンジニアの流儀に反する 54 | - 過度な権威主義。教師・先輩の言う事は絶対 55 | - 実力主義のオープンソースの世界観と真逆 56 | - 集団主義、個人よりも集団を重視し、大勢で1つになって頑張る 57 | - アジャイル開発では自立した少人数の精鋭チームが理想とされている。その考えとは真逆 58 | - 協調性を重視（というか日本で言う協調性は同調圧力という単語のほうが適切） 59 | - この同調握力が非効率なルールへの改善提案を許さずに新しい技術への参入障壁を高めている 60 | - 結果よりも過程を評価する（頑張る事に意味がある、苦労する事をまるで美談のように語る） 61 | - エンジニアじゃなくても世の中の多くが結果ベースで評価されている事は言うまでもない 62 | 63 | これらの特徴は戦前、優秀な兵隊を生み出す為の教育がベースになっています。 64 | 65 | ちなみにこのような傾向は学校を卒業して、会社に入ってからも続きます。 66 | 67 | 朝礼で社訓を唱和させられたり、強制参加の飲み会があったりするのは、基本学校でやらされている事が形を変えただけで本質的には何も変わっていません。 68 | 69 | その為、普通に過ごしていると多かれ少なかれ社畜よりの思想に染まってしまいます。 70 | 71 | [UNIXという考え方―その設計思想と哲学](https://www.amazon.co.jp/dp/4274064069)より「できるだけ早く試作を作成する」というモノがあります。 72 | 73 | これは早めに動くモノを作ったほうが問題点も早く洗い出されるし、アイデアはだけでは憶測の域を出ないから意味ないよね、というような事を言っています。 74 | 75 | これは[アジャイル開発](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA)にも通じる考え方です。 76 | 77 | ちなみに、良い書籍と呼ばれる大半の書籍がアジャイル開発を前提とした条件で書かれています。 78 | 79 | 社畜思想が強い日本の企業だと、今だに [ウォーターフォール](https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A9%E3%83%BC%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A9%E3%83%BC%E3%83%AB%E3%83%BB%E3%83%A2%E3%83%87%E3%83%AB) ベースでスケジュールを変更するのは許されない雰囲気があります。 80 | 81 | これは上が決めたスケジュールの為なら残業をして組織に滅私奉公するという考え方やシステム開発、プログラミングを単純作業のように捉えている事からだと思われます。 82 | 83 | 設計者と開発者が別だったり（しかも設計者はまともにプログラミングが出来ない人だったりする事も多い） 84 | 85 | 細かい部品単位で担当者が分かれていたりと、非効率極まりない体制もシステム開発を単純作業を捉えているからこその考え方です。 86 | 87 | それから、少々古い文書ですが [ハッカーになろう](http://cruel.org/freeware/hacker.html) という文章です。 88 | 89 | ここに書いてある「ハッカー的心構え」は日本的な社畜思想とは真逆の事が書かれています。 90 | 91 | 「暗記」や「まずは書籍から入る」を重視してしまう人がいるのも、日本の教育は暗記が大事という事が原因です。 92 | 93 | 手段の目的化も学校では勉強する意味や勉強した事の活かし方をほとんど教えない、つまり考える能力の欠如によって起こります。 94 | 95 | つまり社畜思想と良いエンジニアの考え方は極めて相性が悪いと言えるのです。 96 | 97 | ## 会社と自分を分離して考える事が出来ない事の弊害 98 | 99 | 日本における終身雇用の時代はとっくの昔に終わりを迎えています。 100 | 101 | その為、自分の身は自分で守るという行動が必要不可欠になります。 102 | 103 | エンジニアは技術が資本です。 104 | 105 | よって技術力を身につけ、転職や起業をしやすい状態を作っていく事が大事です。 106 | 107 | 滅私奉公の精神や従業員なのに経営者目線を持っているような行動はただ都合良く会社に使われているだけに過ぎません。 108 | 109 | 「今やっている仕事が将来自分の為になるか」と常に考える事が必要不可欠です。 110 | 111 | （参考）[現代において「嫌な仕事をしない」は圧倒的に正しい。](https://blog.tinect.jp/?p=45088) 112 | 113 | ## 常に会社駆動で動く弊害 114 | 115 | 旧来の日本的な会社というのは従業員を自社の文化に染めようと様々な手段を使ってきます。 116 | 117 | 日本の会社で新卒一括採用を重視している事の理由の1つには自分の会社の文化に染めやすいという点があります。 118 | 119 | 他の現場でも使えるような汎用的なスキルであれば、まだ良いです。 120 | 121 | しかし社内ルールへの共感を必要以上に強要する会社は他社では役に立たないローカルスキルしか身につかないケースが多いです。 122 | 123 | 例えば以下のようなケースです。 124 | 125 | - とっくの昔にサポートが切れた古いバージョンのフレームワークのメンテナンス 126 | - スパゲッティコードで訳が分からないコードからひたすらデバッグを行うだけの不毛な作業 127 | - マイナーでその会社でしか使っていないような言語や技術 128 | - プログラマ志望で入ったのに外注会社の管理ばかりやらされる（しかも開発フローが会社独特） 129 | 130 | このような状態が長く続くと市場で使われている技術と自分がやっている技術の乖離が大きくなり、転職する事が困難になってしまいます。 131 | 132 | 下記は私が過去にある社畜とした会話です。 133 | 134 | この社畜は会社駆動で動く、典型的な社畜でした。 135 | 136 | ``` 137 | 私「PHP5.4からトレイトが使えるようになったらしいよ。便利そうだね」 138 | 139 | 社畜「ふーん。でもこの会社はPHPのバージョン5.2だから別に覚えなくていいや」 140 | 141 | 私「」 142 | ``` 143 | 144 | 先程も書きましたが、エンジニアは技術が資本です。 145 | 146 | その為、汎用的なスキルを身につける事は非常に重要です。 147 | 148 | この社畜は行動や思考が常に会社駆動なので外にある便利な情報や技術を自ら取り入れようという発想が存在しないのです。 149 | 150 | 会社駆動でしか動けない人はせっかく学びのチャンスがあるのに自らそれを放棄します。 151 | 152 | ## 人間関係が会社に偏っている事による弊害 153 | 154 | これに関しては一言で言うと視野が狭くなるからです。 155 | 156 | また労働環境が最悪だったり、他の会社では信じられないような非常識な事にも気がつけなくなります。 157 | 158 | 社畜思想に囚われた人々は [飲みニケーション](https://matome.naver.jp/odai/2140030902245337801) なるモノが重要と言い、行きたくもない飲み会の幹事や参加の強要を行ってきたりします。 159 | 160 | これは定年まで同じ会社で働くから社内の人間関係が最も重要であるという前提の考えに成り立っています。 161 | 162 | また会社が主導で飲みニケーションを推奨している場合は会社内に人間関係を閉じ込めて、自分の会社のおかしい部分を隠そうという悪質な企業も存在します。 163 | 164 | 会社内の人間関係にどっぷり浸かっていると、その会社を中心とした情報しか入らなくなるので、新しい技術や世の中の流れ等をキャッチする感覚がどうしても鈍くなります。 165 | 166 | さらに行きたくもない飲み会に時間とお金を使うとIT技術の学習に使う時間を削られてしまうというデメリットもあります。 167 | 168 | こうならない為にも会社の外の人間とも交流を持つ事を意識したほうが良いでしょう。 169 | 170 | 勘違いしないで欲しいのは、会社の人と仲良くなる事を否定している訳ではありません。 171 | 172 | 普通に仲良く出来そうな人は仲良くすればいいし、楽しいと感じる飲み会は参加すれば良いです。 173 | 174 | ただ参加するイベントや付き合う人間は選んだほうが良いという話です。 175 | 176 | したくない事に時間を使うのはもったいないのでそれだけは避けるように意識しましょう。 177 | 178 |

1つの社会にしか属さないと視野が狭くなってしまって、理不尽なことでも「自分が悪いのかも…？自分さえ我慢すれば…」ってなっちゃうから、全く関係のない別の組織にいくつか加わっておいた方がいいです。
広い視野で判断できるようになるし、1つだめになっても「他いくか」って強くなれるから。

— むちょこ webエンジニア (@aya_lachelier) 2018年4月14日
179 | 180 | ## 権威主義による弊害 181 | 182 | 社畜が持つ特徴の中で最も悪影響なのがこの権威主義です。 183 | 184 | ちなみに私は権威主義者が大嫌いです。 185 | 186 | 日本の体育会系の部活に居た人はこのような考え方をする事が多いです。（特に男性） 187 | 188 | 権威主義者の上司は下記のような特徴があります。 189 | 190 | - 上にはヘコヘコして下には横柄な態度を取る 191 | - 同じ意見でも役員や社長が言えば賛成し部下が同じ事を言ったら否定する 192 | - 職位が人間的な序列を決めると思っている 193 | - 部下の手柄は上司の物、失敗責任は部下に押し付ける 194 | - コンサルが言う事を鵜呑みにする 195 | - 自社には全然当てはまらないケースなのに権威を持ったコンサルという肩書で全てを信用する 196 | 197 | 典型的な無能上司ですが、このような連中が存在出来ているのは日本人に幼い頃から植え付けられた、社畜思想が色濃く残っているからです。 198 | 199 | このような無能上司の元で働いている人たちは以下のような行動を取るようになります。 200 | 201 | - 問題を報告すると叱責されるので、それを恐れて問題を報告しないようになる 202 | - それが原因で後で取り返しのつかない問題が起こる 203 | - 意見を言っても却下されるので改善提案をしなくなる 204 | - ミスをしたら責められるので、無難な事しか言わなくなり、新しい技術にも挑戦しなくなる 205 | - ひどい場合はミスを隠蔽する為に嘘を付くという場合もある 206 | 207 | 問題解決を行う為には、冷静に何が起こっているかを分析し、適切な対処を取る必要があります。 208 | 209 | 権威主義に支配された組織では改善提案がされなくなる為、どんどん衰退していきます。 210 | 211 | 権威主義は企業を衰退させている大きな原因だと私は考えます。 212 | 213 | [[翻訳] スクラムがアジア圏でうまくいかない4つの理由 - Scrum does not work here in Asia](https://qiita.com/wataradio/items/6b79130b8ea53aa698aa) という記事を見て頂きたいです。 214 | 215 | >私の観察から、すべてのものが階層化されるべきだという考えがスクラムがアジア圏でうまくいかない主たる理由だ。 216 | 217 | スクラム（アジャイル開発の1手法）を成功させる為には情報の透明化が必要不可欠なので、この主張は実に的を得ていると言えるでしょう。 218 | 219 | 権威主義に囚われない為には以下の点を徹底して意識する必要があります。 220 | 221 | - 理不尽に耐える事は努力ではない 222 | - 上司が「偉い」のではないただ会社内で職位が上なだけ、ただの役割の違いでしかない 223 | - 上司が偉くないのと同じで年上が偉いという考え方は捨てる 224 | - 年齢が上というそれ自体には何の価値もない。年齢を重ねてそれなりに成果を出せるようになって初めて尊敬に値する 225 | - 上司が常に答えを持っている訳ではない 226 | - むしろ普段から技術に触れている技術者のほうが良い提案を出来るケースが多い 227 | - 「誰が言ったか」ではなく「何が正しいか」で物事を判断する事 228 | - 上司が言った事を鵜呑みにしない。その背景にある真の目的を理解しそれを達成する為に動く事 229 | 230 | [ハッカーになろう](https://cruel.org/freeware/hacker.html) から良い言葉があったので引用します。 231 | 232 | >ハッカーたちは本来的に反権威主義です。 233 | >あなたに命令できる人は、何かあなたが興味を持っている問題を解決するのを止めさせてしまえます。 234 | >しかも、権威主義的な頭の特徴として、そのやめさせる理由もあきれるくらいくだらないものであるのが普通です。 235 | >だから権威主義的態度に出会ったら、必ず戦わないといけないのです。 236 | >そうしないとあなたや他のハッカーたちが窒息させられてしまいます。 237 | >（だからといってすべての権威と戦えということではありません。子どもには指導がいるし、犯罪者は拘束されるべきです。ハッカーは、命令に従うための時間以上にほしい何かを手にいれるためなら、ある種の権威を認めることに同意することもあるでしょう。 238 | >しかし、それには制限のついた意識的な取引です。 239 | >権威主義者が求める個人的な降伏などは提供しないのです）。 240 | >権威主義者は検閲と秘密が大好きです。 241 | >さらに自発的な協力や情報共有を信用しません。 242 | >彼らは自分たちが管理できる「協力」だけを好みます。 243 | >だから、ハッカーらしく行動するためには、検閲や秘密、そして責任ある大人に無理強いするような圧力やごまかしの使用に対し、本能的に敵意を感じなくてはなりません。 244 | >そしてこの信念を実行に移す用意が必要なのです。 245 | 246 | 技術者に権威主義は不要です。 247 | 248 | 権威主義に取り込まれる事は決してあってはいけません。 249 | 250 | - （参考）[「体育会の部活型組織」に未来はない](http://dennou-kurage.hatenablog.com/entry/2013/04/05/211550) 251 | - （参考）[管理をなくせばなくすほど生産性が高まる新しい組織の形「ホラクラシー」その背景とメリット](https://kuranuki.sonicgarden.jp/2015/08/holacracy.html) 252 | 253 |

なにかを評価するとき、最もやってはいけないのは「●●が言っていたから」を軸にすることですね。だれかの評価をそのまま鵜呑みにするのは、とても危険な考え方。評価というのは、じぶんで見たもの、そしてそこから感じたものを軸にして行われるべきだし、その過程を通ったものしか評価とは呼べない。

— プロ奢ラレヤー🍣 (@taichinakaj) 2018年7月4日
254 | 255 | ## 精神論による弊害 256 | 257 | プロジェクトの遅延原因は様々なモノがありそれらの原因を取り除く事でしか問題解決は不可能です。 258 | 259 | 必要なのは冷静に問題を分析する能力と論理的な思考能力です。 260 | 261 | 根性とか気合でコンピュータが思い通りに動くなら苦労はしません。 262 | 263 | また自動化出来る作業を延々と手作業でやっているのも、精神論による弊害と私は考えます。 264 | 265 | 実際に私が過去に体験した例だと、Webサーバ情報（IPアドレスとか役割とかが記載されたやつ）の管理をExcelによる手作業によって行っていた事がありました。 266 | 267 | このような単純作業はいくらでも効率化出来る手段が見つかるし、積極的にそうするべきなのです。 268 | 269 | しかし社畜は「これが社内で決まったフォーマットだ」の1点張りで改善しようという気持ちがまるで感じられませんでした。 270 | 271 | この社畜はいつも遅くまで残業している社畜でした。 272 | 273 | 「遅くまで頑張っているから自分は偉い」のように頑張っていますアピールをされた事もあります。 274 | 275 | 苦労を美談としたり、結果よりも過程を重視する日本的教育の弊害であると私は考えます。 276 | 277 | 「頑張っていますアピール」をした物が高く評価され、実際に価値を出している人が軽視されるような組織はさっさと辞めましょう。 278 | 279 | 精神論が高く評価される組織は問題解決能力が極めて低い傾向は強く、今後衰退していく運命にあるでしょう。 280 | 281 | ## 協調性（同調圧力）の弊害 282 | 283 | まず旧来の日本的組織で言われているのは、協調性ではなくただの同調圧力です。 284 | 285 | 協調性とは本来下記のような事を指します。 286 | 287 | >異なった環境や立場に存する複数の者が互いに助け合ったり譲り合ったりしながら同じ目標に向かって任務を遂行する素質。 288 | 289 | 社畜が良く言う「みんなやっているからお前も我慢してやれ」はそもそも強調性ではありません。 290 | 291 | 真の強調性とは多様性を認める事、そして自分の強みを活かしてチームに貢献する事です。 292 | 293 | 同調圧力に支配された組織は少数化の正しい意見が殺され、集団で間違った方向に進む危険性が高いです。 294 | 295 | - （参考）[社畜以外が会社にいるのが許せない! 「ゾンビ型社畜」への対処法](https://news.mynavi.jp/article/datsushachiku-12/) 296 | - （参考）[みんなが不幸になる日本の「同調圧力」は、絶対悪だ](http://www.amamiyashion.com/entry/2016/07/30/193000) 297 | - （参考）[日本の同調圧力は異常すぎる|これでは誰も幸せになれない](https://kaihoudebut.jp/retire/retiremind/7812/) 298 | 299 |

「みんな本当は嫌だけど、我慢してやってるからお前も我慢してやれ」というのは最悪のロジックだと思う。これはもはやロジックとは言わず、思考停止というのでは。

— 日野瑛太郎 (@dennou_kurage) 2018年2月7日
300 | 301 |

そもそも「わかり合える！わかり合おう！」を相手に強要すること自体が暴力的なんですよね。ひとは絶対にわかり合えない。なのに、そういう人達は、ひとの気持ちの中に土足で上がり込んで、ぐちゃぐちゃにして帰っていく。ほんとうに大事なのは、「わかり合えない！認め合おう！」なんだとおもいます。

— プロ奢ラレヤー🍣 (@taichinakaj) 2018年5月26日
302 | 303 | ## 社畜にならない為にはどうすべきか 304 | 305 | 社畜思想を避ける事はエンジニアとして成長する為に必要不可欠であると私は考えます。 306 | 307 | 「能力ある人はいいけど自分は能力ないから」のような事を言う人がいますが、私は「能力がないから社畜になるのではなく、社畜だから能力がない」と考えます。 308 | 309 | それ程までに社畜的な考え方は良いエンジニアを目指す為の足枷となるのです。 310 | 311 | よって社畜思想に洗脳されないよう、立ち回る事が重要となります。 312 | 313 | まず第一歩として社畜思想の強い人間との関わりを出来る限り避けましょう。 314 | 315 | その為には、無駄な会社の飲み会を避け、本当に将来自分に必要な事だけに時間を使う事が重要となります。 316 | 317 | 時間を使うのは楽しい事か自分の役に立ちそうな事だけに限定しましょう。 318 | 319 | 次に日本の常識に囚われるのは辞めましょう。 320 | 321 | - 同調圧力 322 | - 勤勉は美徳であるという意味不明な精神論 323 | - 組織第一主義（全体主義） 324 | - くだらない年功序列 325 | 326 | これらは全て現代では通用しない常識です。（これに囚われている人を社畜と呼びます） 327 | 328 | 常識（日本の常識は特に）とは本来時代と共にアップデートされていくべき物です。 329 | 330 | これだけ流れの早い世の中なので、いつまでも老害が作った古い常識に囚われる事は何のメリットもありません。 331 | 332 | 社畜によっては、何とかしてこちらを洗脳しようと様々な手段を使ってきます。 333 | 334 | 社畜に洗脳されない為にはこちらも論理武装しておく事が有効です。 335 | 336 | いくつか役に立ちそうなブログや書籍を紹介させて頂きます。 337 | 338 | ### [雨宮の迷走ニュース](http://www.amamiyashion.com/entry/518728) 339 | 340 | ドイツ在住の日本人フリーライターの方が書いているブログです。 341 | 342 | エンジニアの方ではないので、技術的な内容はないですが、日本の常識や社畜思想の問題点等を言及した記事が多く、社畜教育の洗脳を解く最初の一歩としては有効です。 343 | 344 | ### [脱社畜ブログ](http://dennou-kurage.hatenablog.com/) 345 | 346 | 日本企業の働き方や日本の常識のおかしな点を指摘したブログです。 347 | 348 | 著者の方はブロガー兼ソフトウェアエンジニアで書籍も出しています。 349 | 350 | [社畜度診断](http://sshindan.dennou-kurage.com/) というサービスは現状の自分の状態（社畜or非社畜）をある程度判断出来るのでやってみると面白いです。 351 | 352 | ### [すべての教育は「洗脳」である～21世紀の脱・学校論～](https://www.amazon.co.jp/dp/B06XGXMNW4) 353 | 354 | こちらは書籍です。 355 | 356 | 著者の方は有名な企業経営者なので誰でも名前くらいは知っているでしょう。 357 | 358 | この中で社畜という言葉は出てきませんが、日本の教育を鵜呑みにする事がいかに危険かという点は参考になりました。 359 | 360 | ## 最後に 361 | 362 | 社畜にならない事は現代においては非常に大切な考え方です。 363 | 364 | 良いエンジニアを目指す視点でも非常に大きな足かせになります。 365 | 366 | 1人でも多くの人が社畜思想に支配された不幸な人生を回避する事を望みます。 367 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "web-developer-ojt", 3 | "version": "1.0.0", 4 | "private": true, 5 | "description": "Web開発者向けのOJT", 6 | "scripts": { 7 | "lint": "textlint", 8 | "lint:fix": "textlint --fix", 9 | "lint:all": "textlint 'docs/**/*.md' 'README.md'", 10 | "lint:all:fix": "textlint --fix 'docs/**/*.md' 'README.md'" 11 | }, 12 | "repository": { 13 | "type": "git", 14 | "url": "git+https://keita-nishimoto@github.com/keita-nishimoto/web-developer-ojt.git" 15 | }, 16 | "author": "keita-koga", 17 | "license": "MIT", 18 | "bugs": { 19 | "url": "https://github.com/keita-nishimoto/web-developer-ojt/issues" 20 | }, 21 | "homepage": "https://github.com/keita-nishimoto/web-developer-ojt#readme", 22 | "devDependencies": { 23 | "textlint": "^10.2.1", 24 | "textlint-rule-max-ten": "^2.0.3", 25 | "textlint-rule-no-mix-dearu-desumasu": "^3.0.3", 26 | "textlint-rule-preset-ja-technical-writing": "^3.1.3", 27 | "textlint-rule-preset-jtf-style": "^2.3.4" 28 | } 29 | } 30 | --------------------------------------------------------------------------------