- 1. エンジニア転職して一年経つので自宅学習で使った技術書&Udemyをジャンル別にまとめてみた
- 2. エンジニアのインプットと読書術
- 3. Operating System Concepts Chapter 4 Threads まとめ ( OS におけるスレッドについて)
- 4. 技術書プラットフォーム”Hello Books”の紹介と個人開発のすすめ
- 5. [プリンシプルオブプログラミング] プログラマーの見る視点
- 6. [プリンシプルオブプログラミング] プログラマの三大美徳と法則
- 7. この単語さえわかれば、英語の技術書がサクサク読める!英単語まとめ(保存版)
- 8. [プリンシプルオブプログラミング] UNIX思想
- 9. [プリンシプルオブプログラミング] UNIX哲学
- 10. [プリンシプルオブプログラミング] セオリーと基本原則
- 11. [プリンシプルオブプログラミング] プログラミングに特効薬は無い。コードの原則など
- 12. プログラミング初心者の学生が2年間で読んだ本の中でオススメを紹介する
- 13. 「UNIXという考え方」読書メモ
- 14. 良いコードを書く技術ー読みやすく保守しやすいプログラミング作法を読んで
- 15. リーダブルコードの読み方 ほぼ個人メモ
- 16. “Re:VIEW Starter”で技術系同人誌を書こうと思い、初期設定でつまづいたので健忘録がてらにまとめました。
- 17. リーダブルコードの要約（備忘録）
- 18. デートの時の話題について（ライフハック）
- 19. 社内でビブリオバトルを開催してみた ! (みんなでワイワイ本紹介をやるなら必見 !)
- 20. 何を学ぶかを決めるには from エンジニアの知的生産術(マイピックアップ)
エンジニア転職して一年経つので自宅学習で使った技術書&Udemyをジャンル別にまとめてみた
#はじめに
2021年7月でエンジニアになって1年経ちました。エンジニア転職直後に年収が700台から300台まで落ちて、爆速で市場価値をあげなければ！！というモチベーションで一年間いろいろ勉強してきました。
これまでその内容を振りかえることもなかったので、この機会に自宅学習で使った技術書とUdemyをまとめてみることにしました。参考資料選びに悩んでいる方の助けになれば幸いです。
ちなみに、転職して半年間は学習の成果も市場価値の向上も全く感じられなかったのですが、最近になってようやくそれらを感じられるような出来事が増えてきています。
– WantedlyやQiita Jobsで有名企業(Y社とか)からスカウト
– 転職ドラフト初参加で4社から指名(2社から700万提示)#JavaScript
JSの歴史やシングルスレッドについて触れられており、非同期処理(Promise)やPrototypeの項が特にわかりやすかった。
JS学習の2冊目としておすすめ。
Operating System Concepts という本を OS と英語の勉強を兼ねて読んでいます。アメリカの大学等で OS の基本教科書として一番よく読まれているものらしく、内容が網羅的で、かつ英語ではあるのですが内容がとてもわかりすいです。
今 4 章を読み終えたところなのですが、何もアウトプットしないと理解が進まないなと思いまして。思いつきでとりあえず 4 章から私なりに理解した内容をまとめていこうと思います。
# (マルチ) スレッドが生まれた背景と新たな要求
現代の汎用 OS (Windows, Linux など) は複数のタスクを見かけ上にも事実上にも並列で実行することが求められます。このような複数のタスク (マルチタスク) を実行するために、OS 上に複数のプロセスを起動するという発想が生まれました。これがマルチプロセスです。さらに、多数のユーザからのアクセスが要求されるシステムが生まれてくると (Web など)、より容易にスケールするマルチタスクが求められるようになりました。これによって生まれたのがマルチスレッドという概念です。もともと 1 プロセス 1 ス
技術書プラットフォーム”Hello Books”の紹介と個人開発のすすめ
仕事以外の時間もプログラミングやその他技術を学習するなどして過ごしているエンジニアも多いと思いますが、自分もその一人でした。インプットとして技術書などもよく読んでいるのですが、勉強する中で下記の様な不満を慢性的に持っていました。
* 買う前と買った後のギャップが大きい技術書が少なくない
* 技術書は比較的高価なことが多いので、ダメージが大きい。。。
* 何か良い書籍ないかな〜とブラウジングするのに適したプラットフォームがない
* amazonを基本的に利用しているものの、amazonの検索UIは様々な商品に適合する様に汎用的なデザインになっているため技術書のブラウジングに関してはあまり使い勝手が良くない
* 他のエンジニアさんがどんな技術書を読んでいて、それをどの様に評価しているのかリサーチして自身の学習方針の参考としたい
* amazonでレビュー自体は確認できるものの、参考とするには内容が薄かったり投稿主に関する情報が少ないため信憑性が判断できないいっそのこと自分で作ってしまおうかな、とリリースしたのが[“Hello Books”](https://hellob
[プリンシプルオブプログラミング] プログラマーの見る視点
# プログラマーのコードを見る視点
## 凝集度
モジュールは純粋に保ちましょう。
純粋なモジュールとは、独立性の高いこと、凝集度が高いものになります。
コードはモジュール化することによって管理しやすくなります。
分割したモジュールは独立性を保つことによって、コード複雑さを減少させ保守しやすくなります。モジュールが純粋ではなく、凝集度が低いものになると以下の弊害が起きます。
– コードが理解しにくい
– コードが保守しにくい
– コードが再利用しにくい
– コードが脆弱で、変更による影響を絶えず受け続ける一方、凝集度の高いモジュールは適度に細分化されたものなので、限定された目的に特化されています。
以下のような利点があります。– コードの設計の明確さと理解のしやすさ
– コードの保守と拡張が容易
– コードの再利用性が高い
– モジュール間の疎結合が促進する## 結合度
モジュール間の関係の密接さを表すのが結合度です。
結合度は疎結合であれば、それゆえに独立性が高いコードになるので、いいコードになります。
逆に結合が密なコードは互いに依存しあい、独立性が低いモジュー
[プリンシプルオブプログラミング] プログラマの三大美徳と法則
# プログラマの三大美徳
## プログラマは怠慢、短気、傲慢であれ
### 怠慢
楽をするのであれば、手間を惜しまない気質のことです。
コードやテストの自動化など、めんどくさいことはコードで行います。
業務やプロジェクトでは、めんどくさいと思う何回も繰り返すものがあります。そういったものを自動化して怠惰であれるようになりましょう。### 短気
上手く動かなかったらコードをかき直したりする気質です。
また、今ある問題に着目せず、今後起こりうる問題を想定したコードを書きます。
コードの動作が遅い、動作がおかしいなどの面で短気となり、すぐに修正しましょう。それらのコードを残すのは負債となりえます。### 傲慢
高いプライドを持つ気質です。
レビューされても指摘する場所が無いほどのコードを書きます。
プロフェッショナルの意識を持ちましょう。コードは時として汚いものになりますが、意識をすることで常にキレイな状態に保てます。## エゴレスプログラミング
プログラミングでエゴを捨てます。
うぬぼれやプライドを捨てて、仲間にコードを見せる、コードを見る時に、自分のほうが優れているという
この単語さえわかれば、英語の技術書がサクサク読める!英単語まとめ(保存版)
# はじめに
英語のプログラミング教材って、良いって聞くけど、英語に苦手意識があるから使ったことがない…。私もその一人でした。ですが、この単語さえわかっていれば、なんとか[英語のDjangoの本](https://www.amazon.com/Django-Beginners-Learn-web-development/dp/1980377898)を読み切ることができました。
これから英語でプログラミング学習したい人は見ていただけると役に立つかもです!
## execute 実行する
### 例文
execute the migrate command
migrate コマンドを実行する## navigate 移動する
### 例文
Navigate to our homepage at http://localhost:8000/
http://localhost:8000/のホームページに移動する## configure 設定する
### 例文
the project configured for local development
ローカル環境で設定された
[プリンシプルオブプログラミング] UNIX思想
# UNIX思想
UNIX思想とは、UNIXの文化で育まれたプログラミングの経験に基づいた実践的な技の集合体です。
以下の17個の原則があります。– モジュール化原則
– 明確性の原則
– 分離の原則
– 単純性の原則
– 倹約の原則
– 透明性の原則
– 安定性の原則
– 表現性の原則
– 驚き最小の原則
– 沈黙の原則
– 修復の原則
– 経済性の原則
– 生成の原則
– 最適化の原則
– 多様性の原則
– 拡張性の原則## UNIXの設計判断の正しさ
1969年にUNIXは生まれ、今なお使われ続けているこのソフトウェアのプログラミングから生まれた思想は、UNIXの堅牢さを見れば分かるとおり、このような設計判断は正しいことがわかります。### モジュール化の原則
– 肥大したモジュールは作らない
– 控えめなモジュールを心がける
– クリーンなインターフェースを持つ
– モジュールの入り口を狭くする
– 余分な他のモジュールと関係を持たない### 明確性の原則
– 巧妙なコードより、明確なコード
– パフォーマンスではなく読みやすさ
–
[プリンシプルオブプログラミング] UNIX哲学
# UNIX哲学
UNIX開発の根底にある哲学です。
9個の定理でまとめられています。– 小は美なり
– 一つ一つ仕事
– 速行プロトコル
– 効率性より移植性
– データはテキスト
– レバレッジ・ソフトウェア
– シェルスクリプト活用
– 対話インターフェース回避
– フィルタ化## 小は美なり
– 小さいソフトウェアは扱いやすく、美しい
– 理解しやすい
– 保守がしやすい
– マシンリソースを食わない## １つ１仕事
– ソフトウェアをピュアに保つ
– １つのソフトウェアに１つの仕事を集中して行わせる## 速行プロトタイプ
– できるだけ早くプロトタイプを作成する
– プロトタイプで確度を高める
– 方針を決めることでコードを作成しやすくする
– 要件不備を早い段階で見つけやすい## 効率性より移植性
– 効率性より移植性の高いコードを書く
– ソフトウェアの価値を持続させるコードを書く
– ハードウェアに依存しない## データはテキスト
– バイナリで持つよりテキストフ
[プリンシプルオブプログラミング] セオリーと基本原則
# プログラミングセオリー
プログラミングの最大の関心事は最高のコードを作り上げること。
最高のコードとは、拡張性が高く、余分な要素が無く、読みやすいコードのことです。
そのコードに到達するのは、3つの価値が重要になります。– コミュニケーション
– シンプル
– 柔軟性## 価値観を技術の選択に
上記に上げた価値を、技術の選択基準にしましょう。
プログラミングは、問題解決を目的としています。エンジニアとしては、技術を知る、理解する、覚えるというのは重要ですが、技術を知っていても「使える」ようにはなっていません。## 価値観は原則を通じてコードに適用
価値観を判断に使用しましょう。技術や手法の適用、不適用などの判断が正確になります。
しかし、価値をそのままプログラミングに使用するには抽象的すぎます。なので、価値をプログラミングに橋渡しをする６つの原則を使用して、価値を適用しましょう– 結果の局所化
– 対称性
– 繰り返しの最小化
– ロジックとデータの一体化
– 宣言型の表現
– 変更頻度# シンプル
## コードの複雑性を排除する
コードから余分な複雑性を排除し
[プリンシプルオブプログラミング] プログラミングに特効薬は無い。コードの原則など
# プログラミングに銀の弾丸はない
プログラムをする上で、エラーが発生するもの、処理が上手くいかないものなど、たくさんの事例があります。それらに対抗する銀の弾丸はありません。なぜならば、プログラムで最終的に出来上がるソフトウェアは困難であるからです。## ソフトウェアは基本的に困難である
ソフトウェアが困難な理由は以下の４つがあるからです。– 複雑性
– 同調性
– 可変性
– 不可視性### 複雑性
ソフトウェアは複雑です。
作っていくうちにファイル数が増え、依存関係が増え、また自分以外の人が書いた部分もあるでしょう。
規模が大きくなるうち、それらは非線形に増大します。### 同調性
ソフトウェアは実世界に同調していなければなりません。
ハードウェアやネットワーク、他のソフトウェアの連携、それを使う人間…
ソフトウェアはそれらと接続され、使用します。### 可変性
ソフトウェアは変化し続けるものです。
作り終えたソフトウェアは使われるうちに、さまざまな課題や問題点や改良点が見つかるでしょう。
ソフトウェアの開発に安寧はありません。### 不可視性
ソフトウェア
プログラミング初心者の学生が2年間で読んだ本の中でオススメを紹介する
# 目次
[01. はじめに](#1-はじめに)
[02. ネットワーク](#2-ネットワーク)
[03. データベース](#3-データベース)
[04. セキュリティ](#4-セキュリティ)
[05. linux](#5-linux)
[06. web](#6-web)
[07. 機械学習](#7-機械学習)
[08. 低レイヤ](#8-低レイヤ)
[09. uiux](#9-uiux)
[10. リファクタリング](#10-リファクタリング)
[11. aws](#11-aws)
[12. その他](#12-その他)
[13. さいごに](#13-さいごに)# 1. はじめに
プログラミングってなに？ってレベルの学生が2年間で読んだ技術書の中でオススメの書籍を分野別に紹介します。また、これから読もうと思っている書籍や現在読み進めている書籍など、気になっているものを一通り上げています。プログラミング言語やフレームワークなどの特定の言語を追求するような書籍は紹介していません。
# 2. ネットワーク
### マスタリングTCP/IP 入門編（第6版）
https://ww
「UNIXという考え方」読書メモ
# まえおき
以前、初めて業務の中でシェルスクリプトを使い効率化ツールを作った↓
[シェルスクリプトでスキャフォールドツール作った話](https://qiita.com/michida/items/dd186a73782c0b0aabf0)チームメンバーにも展開し使用してもらうことも出来て割と好評だった。
ただ作る上で迷いが生じた部分がいくつかあり、感覚的にそこは進めていったのだが、その解がこの本の中に書かれていた。更にこの本を読みながら思ったのは、平成13年に発行されたものとは思えなかった。
と言うのも約20年経った現在でも通じることばかりが書かれており、やはりこう言う思想や哲学という部分は何年経っても根底にあり続けるのだなと感じた。# お気に入りの一節
ここからはお気に入りの一説を抜粋していく。> – 小さなプログラムは、分かりやすい。分かりやすいと保守も容易になる。プログラムを理解するのが保守の第一歩だ。 p18
>
> – シンプルであるために簡単に書け、理解しやすく保守しやすい。人間にとってもマシンにとっても優しいのが小さいプログラムだ。さらに重要なことは、作
良いコードを書く技術ー読みやすく保守しやすいプログラミング作法を読んで
参考 [良いコードを書く技術ー読みやすく保守しやすいプログラミング作法を読んで](https://amzn.to/3v0EGNF)
# 1章
#### 良いコードの定義
本書での良いコードの定義
* 保守性が高い
* 素早く効率的に動作する
* 正確に動作する
* 無駄な部分がない#### 保守性が高い
コードは想像よりも長く利用される。あとから見て何をしているのかわかりにくいコードは良いコードとは言えない。
誰が見ても理解出来るコードが良いコードである。
意識する部分としては
* 名前付け
* スコープ
* コードの分割
* コードの集約#### 素早く効率的に動作する
効率の良い適切なパフォーマンスのコードが良いコードである。
いくつも似たようなコードを書く必要はない。#### 正確に動作する
確実に動作して、信頼性の高いことは良いコードである。
「防御的プログラミング」→正常に動くだろうと決めつけをせずに
不正な値が来ても被害を受けないように防御的にプログラミングを行うこと
「ユニットテスト」でバグが少なく正確に動作するコードを実現する#### 無駄な部分が少ない
リーダブルコードの読み方 ほぼ個人メモ
# 目的
– リーダブルコードという技術書を読んでみて自分に合った読み方を見つけたのでまとめておく
# 詳細
– 読んだ本
– リーダブルコード: [https://www.amazon.co.jp/dp/4873115655/ref=cm_sw_em_r_mt_dp_97MYJ3X5JEN95S49YD0P](https://www.amazon.co.jp/dp/4873115655/ref=cm_sw_em_r_mt_dp_97MYJ3X5JEN95S49YD0P)（アマゾンのリンクですがアフィリンクではないので安心してクリックしていただいて大丈夫です。）# この本の概要（ネタバレにならない程度の内容のまとめ記事を別途記載予定）
1. 読みやすいソースコードの書き方が書いてある。
1. 「初心者エンジニアはとりあえず読んだほうが良い技術書」として取り上げられる事が多い。
1. 初心者エンジニアだけではなくベテランエンジニアさんも読んでいらっしゃる。
1. もともと著者は海外の方で日本語訳されたものが多く出回っている。# 個人的におすすめの読み方（完全自分向
“Re:VIEW Starter”で技術系同人誌を書こうと思い、初期設定でつまづいたので健忘録がてらにまとめました。
# Re:VIEW Starterを使ってみる
## “Re:VIEW”とは？
”Re:VIEW”とは、Open Source Softwareで技術系の同人誌やプロが書くような書籍に使われているものです。
簡単にいうと、素人でもプロが書いたような書籍や電子書籍を書くことができるソフトです。
現在、ver. 5.0まで出ています。
詳しくは下をご確認ください。
[Re:VIEW knowledge](https://review-knowledge-ja.readthedocs.io/ja/latest/index.html)## “Re:VIEW Starter”とは？
そしてRe:VIEW Starterとは、Re:VIEWでは少々面倒くさい書籍の体裁の設定を、初心者にはわかりやすいUIで設定できるようにしたものです。[Re:VIEW Starter](https://kauplan.org/reviewstarter/)のページから、体裁に必要は初期設定を行います。
ちなみに、Re:VIEW StarterはRe:VIEW ver. 2.5で動作します。##”Re:
リーダブルコードの要約（備忘録）
# コードの基本定理
– コードは他人が読んで短時間で理解できなければならない
– コードは短い方がもちろん良いが、一番は理解するまでの時間を短くすること# 命名規則
## 名前に意味を持たせる。– 明確な単語を選び、汎用的な名前を避け、より具体的な名前を使う
– 接尾辞や接頭語を使用して情報を追加する– 類語辞典でより明確な単語を選択する
例) send
・代替案：deliver, dispatch, announce, distributes, routeなど– メソッド内で計算するためだけに登場する変数は簡単な名前でもOK
例)tmp
“`OK
if (right > left){
tmp = right;
right = left;
left = tmp;
}
“`上記のtmpはこのメソッド内で一時的に情報を保管するだけなので、具体的な命名にしなくてもOK
– ただ、以下の例はNG
“`NG
String tmp = user.name();
tmp += ” ” + user.phone_number();
tmp += “
デートの時の話題について（ライフハック）
イーロン・マスクがデートの時に電気自動車の話をしたとYouTubeで見ました。
彼女にはじめて会って、「電気自動車のことを考えたことある？」と質問したとのこと。ってな話をカミさんにしたら、じーっとこっちを見ていたので、
「もしかして俺もそうだった？」と聞いたら。
「うん。何を話しているか、全くわからなかった。」と言われた。
技術者あるあるかな。:relaxed:
社内でビブリオバトルを開催してみた ! (みんなでワイワイ本紹介をやるなら必見 !)
# はじめに
こんにちは！
KDDI アジャイル開発センターの小板橋です.
本記事では, 先週お昼休みに開催した**ビブリオバトルについてとその内容, 魅力などなど**お届けしたいと思います.
# 本記事は, こんな方におすすめ
* **チームやロールをこえて, 社内で「本」という共通の話題を作りたい方**
* **様々な本を知る機会が欲しい方**
* **新しいオンラインビデオ通話を試してみたい方**
* **みんなでワイワイするイベントをやってみたい方**# ビブリオバトルとは
さて, みなさんはビブリオバトルを知っていますでしょうか !
**ビブリオバトル**とは, 自分の好きな本をプレゼンし「**一番読みたくなった本** = **チャンプ本**」を競う**白熱のバトル**です.# 開催にあたって
さて, お
何を学ぶかを決めるには from エンジニアの知的生産術(マイピックアップ)
「[エンジニアの知的生産術](https://www.amazon.co.jp/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E7%9F%A5%E7%9A%84%E7%94%9F%E7%94%A3%E8%A1%93-%E2%80%95%E5%8A%B9%E7%8E%87%E7%9A%84%E3%81%AB%E5%AD%A6%E3%81%B3%E3%80%81%E6%95%B4%E7%90%86%E3%81%97%E3%80%81%E3%82%A2%E3%82%A6%E3%83%88%E3%83%97%E3%83%83%E3%83%88%E3%81%99%E3%82%8B-WEB-PRESS-plus-ebook/dp/B07JFRF6MW/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=2GRDGUXMBTF82&dchild=1&keywords=%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E
