  |
はてなキーワード: 環境変数とは
なるべく手持ちのPC（以下、ホストPC）の環境をレジストリとか環境変数とかで汚したり悩まないよう
Windows10 ProとWSL2とVSCodeとDockerでやる感じかな
UnityとかVisual StudioとかintellijとかAndroid Studioを使う場合はどうしようもないので諦める。
Android開発はVSCodeでビルドはコマンドラインでとかはできそうだけど。
あとはUSBなどでシリアル接続する必要のあるarduinoとかもちょっと難しいかもしれない
これが基本的なところだけど、WSL2をホストPCに入れるので若干汚れるのとWSL2上のlinuxも同じく汚れるところ
Hyper-VでWindowsの仮想マシンを作ってそのうえでWSL2を動かすのが一番汚れずクリーンに使えそう
ただRyzenとWindows10の組み合わせだと、Hyper-Vの入れ子ができないので仮想マシン上のWSL2は動かないらしい。
Windows11だとできる
手元じゃないのでクリーンに使えるが、ビルドなどはリモートのスペックに依存
そこをよしとすれば楽そう
教えてください。
「猿でも分かるプロンプト活用術」というタイトルでの電子書籍について、以下に簡単な目次と章ごとの概要を示します。実際の書籍を作成するには、これらの各セクションを詳細に説明し、例や図を追加する必要があります。
目次:
1. はじめに
2. コマンドプロンプトとは何か
8. まとめ
9. はじめに
・グラフィカルユーザーインターフェイス(GUI)との違い
・コマンドプロンプトの開き方
・基本的なコマンドの使い方（例：help、cls、exit）
...
はじめに
コンピュータの世界は日々進化し続けており、我々が日常的に使用するデバイスやソフトウェアは常に更新され、より使いやすく、効率的になっています。しかしながら、コンピュータの基本的な操作や理解には、依然として古くから存在するコマンドプロンプトという強力なツールがあります。このツールは、多くのユーザーにとって未知の存在であり、その力を十分に発揮できていないかもしれません。
本書「猿でも分かるプロンプト活用術」は、コマンドプロンプトをこれまで使ったことがない方や、基本的な操作しか知らない方を対象に、この強力なツールを効果的に利用する方法をわかりやすく解説します。また、既にコマンドプロンプトを使用している中級者にも、さらなる活用方法を学んでいただける内容となっています。
コマンドプロンプトは、グラフィカルユーザーインターフェイス（GUI）に慣れ親しんだ現代のユーザーにとっては、最初は少し難しく感じるかもしれません。しかし、本書を通じて、コマンドプロンプトの基本操作から高度な活用法までを習得し、日々の業務やパソコン操作に役立てることができるようになります。
各章では、具体的なコマンドの例やスクリーンショットを用いて、わかりやすく説明を行います。また、章ごとに練習問題やチャレンジを設けていますので、学んだ知識をすぐに実践して確認することができます。
この本を通して、コマンドプロンプトの力を最大限に引き出し、あなたのコンピュータスキルを向上させることができることを願っています。それでは、さっそく「猿でも分かるプロンプト活用術」の世界に飛び込んでみましょう！
ちなみに全くの未経験。
“helloworld”から一歩も進まない、Python死ね。
いやPythonは悪くないんだ。俺みたいなのがやろうとしたのが間違いなのだ。
逆恨みだが死んでくれ。
肉体労働者だからパソコン触るのも数年ぶり、そもそもプログラミングというものは、パソコンの素養がないとあかんのだな。
仕事で必要というわけでは全然なく、別にそっちの道を目指そうという気もない。
チェスが昔から下手な横好きなんだが、変則チェスのゲーム作りたいなと思っただけなんだ。
Pythonを選んだのは、定石なんかに機械学習があると良いのかな、くらいに思ったのと、初心者に優しいとググったら出てきたから。
Pythonのやり方ググると、ダウンロードしろというからダウンロードする。
コマンドプロンプトを起動して、
python-V
と打ち込むわけだ。
「’python’は内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチファイルとして認識されていません」
？？？？
py -V
だと
って出てくんのが尚更意味わからん。ランチャーとかいうもののおかげらしい、だからなんだよ。
予めどこのファイルにあるかコピペしとけって動画はたくさんあるが、し損ねたやつ向けの話が全然出ない。
検索するとたまにそれに触れた知恵袋的な質問が出てくるが、なぜかことごとくスルーされて回答されない。
隠しファイルなるものの存在も初めて知ったが、で？どこ？という核心がわからない。
一旦Pythonをアンインストールして振り出しに戻してからやろうとしたが
「復帰すんの？ええよ！」と言いたげなrepairなんたらかんたらって表記は出ても、結局どこでどうしたらええか出てこない。
掲示板とかで見てると「ぶちこめば良い」とかは言っても実際それがどんな手順を踏むのかわからん。
開始30分から2週間、全く進展がなくて流石に心が折れた。終わり。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
都議選に集まる批判、デンベレグリーズマン(海外セレブ)の日本人労働者への差別発言、国民感情を無視したオリンピック開催、天皇のお気持ち発表、鬼滅の刃大ヒット、全ては腐った民主主義が終了して天皇による寡頭政治が始まる布石や。自民の票田になってる国粋主義者達を本気出した天皇が掻っ攫って全部終わらせてくれ。皆がアホやから民主主義が機能せえへんって嘆いてるリベラルの本音も、優秀な人間だけで寡頭政治やって欲しい、やろ。
責任者不在の政治も当事者意識のない選挙もやめてまえ。選挙に絶望しててなるようになったもんを環境変数として受け入れる大衆とそれが出来ひんぐらい窮地に立たされて割りを食ってる一部の国民がこの国の構成員や。前者は誰が環境変数を設定したかに興味がないし、後者はいざとなったときにクーデター起こす相手がハッキリしてたほうがいいやろ。
私が悪かったので責任を取ります言うて一番目立つ席に座ってた人がひとつ下に移動して引き続き甘い汁吸って、組織自体は根本的には何も変わらんって政治をいつまでも続けるより、君主一人 対 国民全員の緊張感ある政治にしようや。
45歳多重派遣と言っても、噂のGitHubの人ではない。すまんな。。
皆さんはプロジェクトの共有ディレクトリの最下層に”女子大生”という何もないファイルを作ってアクセスログをとっていたのがバレて怒られた事はあるか？私はある。２回。
仕事でとうとうGitHubすら使わずにプログラマ人生を終えてしまった。
レガシーな技術を使いがちな金融プログラマではそこそこ居るのでは無いだろうか。
年収は20代後半からは550万～700万位だった。残業代・退職金は無く交通費は出ない。
所属会社は営業も事務も居ない小さな所帯のフリーの集まりのような所で、会社の運営に必要な金額をある程度毎月納めれば良い会社だった。
仕事がなくなれば自分、もしくは他社員の人脈で仕事をとってくる。フリーで居るよりは仕事を取りやすく、単価も上げやすいので一応会社の所属にしているだけの所だった。
私はやる気が無いプログラマだった。オフの時間にプログラムの勉強をしたことなんて殆どないが３０歳、３５歳の限界説を越え、４５歳まで働けた。
元ニートの高卒45歳。多重派遣の底辺プログラマの退職エントリ。
はてなのIT技術者諸氏はオフの日にも日々勉強をしているようで。
◯◯出来る人が居ないか？と聞き回る営業を見ていると多重派遣のSESとはいえ業務時間内に勉強させろと私は思う。
技術の勉強の話になると途端に何プペる？のような、仕事の為の無給勉強時間当たり前のように語られる事がやる気の無い私にはついぞ理解することが出来なかった。
足に鎖でもついてるのかね。私と一緒だね。
45歳で年収300万円多重派遣の彼は問題児なのかもしれないが、私よりはやる気があるプログラマなのではないかと思う。
退職までずっとプログラムを書き、テストをしていた。たまに客に直接要望を聴いて、仕様書に落とすこともした。
C/C++・Java・各種Shell・VB/VBA・SQL、UNIX/Linux・Windowsサーバーをなんとなーくしていて、他の人が書いたプログラムを流用しまくって書いていた。
ざっくりな話になるが、私より出来る人はわんさか居て、私より出来ない人・問題児が２割は居た。後者の彼らのおかげで私は仕事があったのだ。あと、東京だからあったのだ。
人並以上の理解をしていたのはLinuxの構造くらい。仕事でカーネル層に潜り込み、デバイスドライバの改造をしなくてはならず、月３５０時間くらい働いているうちに身についたものだ。年俸制という糞システムのおかげで1円も残業代は出なかったが。
全く知らない技術が使われている新しい現場に上位プロパー会社の営業に売りに出されることはままあった。
現場の人にさも「解ってます！」みたいな面で面接をし、何とか切り抜けることは出来た。このときばかりはいやいやながら上辺だけを勉強した。無給でな。
解っている事でも残業が沢山降ってきそうな場合は「ちょっと私には難しいですね・・・」「いやー、解らないですね。。」と出来ない振りをする度量もついていた。
仕事は”出来る（都合の良い）いい人”に回ってくるし、仕事をしてもめったに単価を上げてくれなし、切られる時は切られる。
３０歳を越えたあたりから必要な時は定時丁度に上がる精神的な技術も身についた。
それと同時にここ１０～１５年はブラックなIT業界でもようやく過残業を減らそうという機運が増えてきたように思う。
ライブやイベントにも足を運べるようになり、推しに投資が出来るようになった。
おそらくまだ10年はプログラマとしてなんとなく生活出来たのだろうと思う。
「あいつ、そこまで出来はしないけれど居ないと困ることもあるんだよなぁ」位のポジションで。
あるいはもう少しやる気を出し、転職をし、上位層で働くことも出来たのかもしれない。
・そしてその日、”1人日”以上の仕事が割り振られる。残業しても終わらない
・翌朝で何故おわっていないのか？を問い詰められる
・仕事のタスク割り振りが多すぎて終える事は出来ないとお伝えしましたが？と反論
・その状況で、空いている時間にやっておいてくれと新たなタスクが振られる
・空いている時間とは？と聴いてみるが、コンパイルしている1分の時間に少しづつといわれ、そんなの出来るわけ無いですよね？。どこに空いている時間があるか教えて下さい。
と、毎朝そんな問答を繰り返していた。
改善をする気もおきなかった。早く次の現場に行きたいなという事ばかり考えていた。
そして気づいた。この仕事にようやく私は飽きたのだと。
子供も数年前に生まれ、子供が成人するまでこの仕事をするのも耐えられないと。
そんな時に副業のほうを本業にする決意をした。会社を辞め、起業をした。
今は全く別業種の業界で働いている。この先うまくいくかは良くわからない。
３次請け、４次請けの会社に居たので理不尽やパワハラには事欠かなかった。
理不尽の例１）
まだ若手の時、鉄砲玉として使われた事があった。
フロッピーを本番端末のあるセンターに密かに持ち込み、定例メンテナンスの振りをしてシステムを黙って更新するという密命が若手の私と、他社の派遣PGで新人のK君に与えられた。何度も。
かばんの奥にフロッピーを隠し、かばん持ち込み検査で検査員にばれないようにし、潜り込む。メンテナンス用の作業IDを使用して黙ってシステムを更新するというのを繰り返し行った。
今考えると下手すると裁判沙汰なんじゃないだろうか。しかも見つかったら責任を取らされるという。
テンパった彼は入館証ではなく、隠していたフロッピーを検査員に見せつけたのだ。
だが、早朝ということもあり、検査員がほぼ寝ていたので問題なく通れてしまった。
今思うとあの時は首の皮一枚で大丈夫だったんだなと。
理不尽の例２）
大手家電メーカーの工場で仕事をした時、プログラムの仕事なのに作業服をまず”自費”で買わされた。作業服いらねえだろう。
工場内にある窓の無いプレハブ小屋が開発現場だった。人権が無ぇ。ファーウェイの工場にはヨーロッパの街並みが再現されているらしいが。
この現場は電機メーカーのIT子会社D社からE社に投げられ、部屋に私以外だと窓際管理職のD社社員１人とE社の人間しか居なかった。
何故、E社の人間の中に私１人だけ他社の開発要員が入るのか？
入ってすぐに理解した。担当するシステムが１人だけで長く開発していたシステムで、スパゲティすぎて破綻しかけているのだ。
これを開発し続けられればヨシ、破綻したら私の（会社の）せいということにしたいのだ。
入って１週間で営業にコレはダメだと、早く抜けさせてくれと直訴した。
結局抜けるのに４ヶ月かかったが、その間、本当に酷い日々だった。
小さな改修が多く、納期は１週間か２週間毎にやってくる。だが仕様を投げるD社の人が鬱で会社にあまり来ない。他のD社の人に聴いても何も解らないという。
１週間の仕事で金曜日納品なのに、木曜日の夕方に2日酔でやってきた担当者に仕様を聞き出し、金曜日に意地で納品するも、気に入らないところがあったらしく「前担当者よりスキルが低いですね～」と言い放たれた。精神の苦行だろうか。
私の抜けた後、E社の別な人間が担当するも無事破綻しかけているという話は後ほど聞いた。自分のスキルでは本当にギリギリだった。危なかった。
パワハラ１）
高校卒業後はニートだった。猫と母としか会話をしない２年を過ごした。
その後、大手新聞社とオペレーター派遣会社が共同で作っていた文科省認定ではなく定期の学割も効かない街のパソコンスクールに通った。
教師は二種(基本情報)も持っておらず、業界歴は１年だけで環境変数も理解していなかった。
その学校で多重派遣という底辺で生きる技術者の卵に他の２０名と一緒になった。
文科省認定の専門学校の情報処理科では少しマトモに勉強すれば大手SIerや商社の子会社の「何ちゃらソリューション」に入れる事も多い。
アホの一つ覚えのように大手の子会社は「何ちゃらソリューション」なので、「何ちゃらソリューション」というIT会社を見たらセンスの良い経営者が名付けた何処か大手の子会社だと思って差し支えない。あとイノベーションとかな。イノベータとかな。
就職氷河期の真っ最中に地方中核都市で就職をしたのだが、入社直前に東京勤務になった。
会社からは１５万円の引っ越し資金だけが支給された。氷河期の３月に転職は出来なかった。
親に敷金礼金４ヶ月分を負担してもらい、親父に秋葉原の石丸電気で家財一式を買って貰った。
SES企業はまず新人教育の当たりハズレががある。ハズレのほうが多い。
派遣法の隙間をついて、たぅった１人で新人が派遣されてくる事も多い。彼らの大体は苦労を強いられている。
私は運良く同じ会社の人が沢山居る現場に入ったのだが、教育担当が想像を絶するパワハラマンだった。とにかくどんなことにもキレる。
ある日個室に呼び出され「お前は田舎に帰って缶詰工場で働け。なるべく頭の働かなくて良い仕事を選んでくれ。業界にいると迷惑だ」と言われてしまった。
親に学校に通わせて貰い、引っ越し代も払ってもらったのに使い物にならないと言われたときの絶望感は大きかった。
地下鉄がホームに入ってきた時、ホーム下にふと吸い込まれて行きそうになり、寸前でハッとなり鼻先を電車がかすめていった。
知らないおばちゃんに「しっかりして！」と怒られた。都会の人も優しい。
それ以降、他社でも新人には丁寧に接している。私はまだ恵まれていた方なのかもしれない。
パワハラ２）
その家電はTronからLinuxにOSが切り替わり、開発・コンパイル用のソフトウェアのシミュレーターが新規開発となった。
Linuxのカーネルプログラミングが必要となり、日本語の文献もインターネット上の文献も少なく、オライリーの洋書（現在は日本語版もある）を取り寄せて読まざるを得ない状況だった。
英語は全く出来ない＆私が作るとなると当然開発は遅れた。
私はカーネルプログラミングなんて当時はしたことが無かったし、集められた人員もLinux上でC言語の仕事をしたことがある。くらいの人員が集められたのだ。
単価が安い人しか使ってはいけないというルールで運用されていたらしい。
苛立った家電メーカーの”部長”が私を広いフロアの大人数の前でこう叱った。
「こいつ全然解ってないじゃないか！！」「なんでこんなのにやらせているんだ！！」
中国出張で散々おねーちゃんを買った自慢をしていた糞みたいな人間に罵られるのである。
月単価５５万で３５０時間働かされ、残業代は１円も出ずである。誰もフォローをしてくれなかった。
徹夜が３日目に突入した午前３時、役職付きが私のPCの後ろで「まだ出来ないのか？」と１５分おきにやってくる。
何とか完成はさせた。恐ろしいことに若かった当時は満足感をそれなりに得ていた。
精神的に色々と凹んでいた時に励ましてくれたのは中国人の同じ派遣の人だった。
大卒の育ちの良い中国人派遣技術者が沢山居たが、彼らは本当に性格がまっすぐだ。彼らが私の中国感を大分良くしてくれた。
（ずっとメッセンジャーばかりやっている連中もいたが）
彼らのような有益な人材が来てくれる時代があと何年あるのだろうか。
私は所属未定のまま倒産した次の日も、土日も何故か働いていた。
自分が働かないと他の人が倒れてしまうと当時は考えていたし、ようやく仕事が出来るようになって謎のやりがいを感じていた。
そして、翌週、中間の会社から流石に所属未定はマズイのでフリーとして契約しましょうと言われたのだが、単価の話なんて当時若造だった私には解らないのである。
結局、３００時間以上働く中、残業代無しの４５万円固定と言われるまま契約をしたのだが、
当時の私には多い金額に思えていたものの、都内のフリーの技術者としては当然低すぎる金額であった。
忙しい中、アドバイスを貰う余裕もなく、無知のために中間会社の狸親父に低い金額で契約させられたのだった。
みなさんは自分の単価くらいは知っておいたほうが良い。
賢い同じ会社の同僚は失業手当で半年間遊んだか、会社契約と同じ単価でフリーとして契約していた。
余談その２、当時なんとなく興味を惹かれて当時流行っていた日本礼賛本を読んでみた。
国産OSのtronは携帯電話で世界を席巻！！みたいな事が書いてあったが、その本が出ていた頃、携帯電話のOSはLinuxとSymbianで締められていたのを知っていたので興味深く読んだのを覚えている。
他にも
「１次請けが私の単価を上げてくれても中間会社が搾取し、私には全く反映されない話」
「野田がドモホルンリンクルのバイトのように円高を注視し続けた時、円高＆オフショアブームで単価が２年で２回減った話」
「中間会社にオフショア開発の失敗の後始末を手伝って欲しいと言われ、現場をインフルで倒れた振りをして休んだ話」
「５０００円の著作権フリー音源をシステムに使用するのに数百万かかった話」
「メモリ枯渇エラーが頻発したのに数百万以上のコストをかけて打ち合わせをする虚無の話」
「メモリ初期化エラーが頻発した時に、解決方法としてとんでもない方法を提示され、阻止した話」
「１５万円のPCが６０万円で導入される仕組み」
「入社初年度の忘年会の一次会が新宿の有名なゲイのショーパブで、他の社員と会話も無く終わった話」
「無呼吸症候群で猛烈な睡魔との戦い、現場で怒られるようになり、睡眠薬で生活リズムを取り返した話」
「大手会社のコンプライアンス啓蒙画像に著作権違反を発見した話」
「キレる、人前でイライラする人とは働きたくない話」
「某銀行の開発子会社の美人率が高い・銀行員の婚姻率の格差社会の話」
などなど考えていたが長くなったので終わり。
多重派遣先は色々なキャリアの人が多い。元ホスト、元キャバ嬢もいれば元医師の中国人、元アニメ会社勤務、元美容師、元寿司職人等の転職組も多い。
以前いたプロジェクトの有名SI企業のPMもSES上がりの元寿司職人だった。
SESは就職の壁が低い。そこを足掛けとして転職し、さらなる転職で大手や大手子会社に転職するのは悪くないキャリアプランの一つなのかもしれない。
SESの会社も玉石混交なのでまずは良いSES会社に入るのは大事だし、多重派遣は改善されてほしいが。
何が書きたかったのか忘れたし飽きた。
業界からやる気の無い４５歳が１人減り、業界は少し平和になった。
追記：続編を書きました。
Webエンジニアの技術確認って、知識や経験が多方面に渡るから難しいと思ってる。
Webアプリ作れます！と言って完成物だけを見るとたしかにそれなりのができてる。
もちろんテストはない。動けばいい。
N+1やSQLインジェクションが埋め込まれてる（後者はフレームワーク側でほぼ無いが）。
Gitは漢のmaster(main)一本だし、rebaseはできない。何かgitでトラブったら全消ししてcloneし直す。
デプロイもHerokuコマンドをよく分からず打ち込んでるだけ。ちょっと凝ったことはできない。
データベースも大きなExcel程度と考えていて、一つのテーブルに全部のデータを入れる漢のスキーマ。
コマンドも例えばgrepやfindを使えない。XXenvの使い方がわからない。何でもかんでもsudoをつける。
vimが使えないからなんかのはずみでvimの画面になったらパニックになる。
まだまだいろいろあるけど挙げたらきりがない。
となるとどこかで線引きをしなければいけないけど、その線引きの一つの手段が対面での会話の内容、受け答えの態度だと思う。
使わなくなったWindowsラップトップにKODIをインストールしてHDMI出力をTVのHDMI入力へ挿すだけ
ライブラリ登録時にSambaを選ぶだけでKODIが勝手にネットワーク内を探してきてNASが見える
NASをライブラリ登録すると保存されてる動画とか音楽とか写真とか速攻で表示できる
ていうかSambaからBDドライブが見えていてWindowsに挿入されているディスクも見えることにビックリ
お前そこまでできるんか…
YoutubeアドオンでGoogleアカウントと連携するとSubscribeしているチャンネル一覧とか再生リストとかしっかり表示される
もちろん新しいチャンネルをSubscribe登録良いね評価、お気に入りリスト登録とか出来る
外部プレイヤーでNetflixやAmazonPrimeVideoを観れてしまう衝撃たるや
元増田は書いてなかったけどiOS端末からAirPlayできることが判明
公式も非公式もあるけどKODIリモコンから直接NASのメディアを指定できる
実際に使ってみてくれないとわかんないだろうけどKODIのリモコンはスクロールするだけじゃなくて色々直接指定できる
そして何よりKODIにインストールされているアドオンすらリモコン上から直接指定して制御できるのがヤバイ
ちなみにKODIリモコンは非公式の方がカッコ良いの多い気がする
スキンがいっぱいあってデフォルトスキンが合わなくてもきっと気に入るスキン見付かる
今までPCやiPadで観てたけど改めて映像作品はTVで観るべきと認識しましたわ
冷静に考えれば当たり前の話なんだけど今までネット動画だからと言ってPCやiPadしか使ってこなかったのは馬鹿だった
そしてTVは画質良いんだなと気付いたけどコレもアホな話だった
KODIというかネット動画を観るだけの環境なんだけどスマートSTBってスゴイ
いやでもやっぱり使わなくなったPC活かしてタダでスマートSTBが手に入るKODIもスゴイ
今晩ずっとKODIで遊べるし良いモノ知ったわ、そういうのに詳しいお前らもやっぱりスゴイ
構成はHDDへHOME以下をバックアップした後にUbuntuを削除、Windowsをクリーンインストールさせた
当然UbuntuとWindowsの共存も考えたが、共存状態だと使い慣れたUbuntuへ逃げる可能性があったので、少々可哀想だったがUbuntuは削除した
良い機会だったので隣で図解をまじえて教えながら娘自身にインストール作業をさせた
「えっじゃあ他のプライマリパーティションにUbuntuも一緒にインストールできるってこと？」
「その認識で間違いないけど今回はWindowsの練習のためにしない」
Windowsを起動してデスクトップを表示し、娘がまずやったことはWindowsキー(Superキー)を押下だった
「学生は遊ぶだろうしね余計なの消してんだろｗ」
「あー確かにｗ」
学校のパソコンにはないであろうパネルを「ふーん」とクリックしながら、何かに納得したのか「じゃあそろそろクリスタ」と言われ、最大の目的であるクリスタをインストールした
クリスタのインストールが終わると、もう良いよと言わんばかりに「わからなくなったら呼ぶね」とアッチ行けされ初日を終えた
数日経つと「ターミナルがない」と言われたので「SuperキーからのC,M,DしてEnterで起動するはずだけどcmdはLinuxと使い方が全く違うから調べたほうが良いよ」とアドバイスした
娘が自室に行くと直ぐ戻ってきて「cdできたけどlsできないんだけど？」と言われ「使い方違うと言ったろ？cmdの場合ディレクトリ内容一覧はD,I,R」と言いつつ娘の自室へ向かう
「昨日から少し試してたんだけどWindowsのターミナルって全然違うよね？」
「うん違うし、今使ってもらってるのcmdって呼ばれたりコマンドプロンプトって呼ばれてるんだけど、もう一個パワーシェル(PowerShell)というのもある」
「こっちの方がLinuxに近いかもなぁ。lsはできる。だけどtouchはできないぞ。その辺はググれ」
「えっ？touchできないって意味わかんないんだけど」
「PowerShellの場合はN,E,W,-,I,T,E,Mでできる。cmdは作成できないわけでないけど、ファイル作成のためコマンドというものがそもそも存在しない」
「Vimも無かった。というかアプリの設定ファイルがどれなのかすら判らない」
「この辺りはLinuxじゃないと諦めて新規にツールを追加するしかない。Windowsの作法に慣れろ」
「うーん・・・慣れかぁ」
予想通りLinuxとWindowsの違いに戸惑っている様だけど、本当に慣れてもらうしかない
娘が「そういえばアプリってどうやってアンインストールするの？」と聞いてきた
「スタートメニューでアプリアイコンを右クリックしてアンインストール。別窓でプログラムと機能が起動したらそこからアンインストール」
そう教えると再びアッチ行けされてしまった。父ちゃん寂しい・・・
そして昨日いろいろと娘にWindowsの使い勝手を聞いてみた結果が下記の通り
良いところも悪いところもまだまだ色々と言っていたけれど忘れてしまった。女の子は喋り出すとアッチコッチに行って止まらない・・・
また何かしら変化があったら報告しようと思う
-----------
追伸
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
ざまあみろと思う。
「便利なツールによって人は馬鹿になった」とは、上司の口癖のひとつである。
だが厳密にいうとこれは間違いだ。
便利なツールは人間を均しているのだ。つまり馬鹿になっているのは、あたまのいい連中だけだ。ははは。ざまーみろ。
テラタームの普及により、新人からはtelnetの概念が掴めなくなった。
環境変数が存在するから、javaのバージョンも変更できねえ。
みんなそうなんだ。ははははは。ざあまあみろ。ははははは。
かつて、コマンドとかカレントディレクトリとか、エンジニア界の絶対的な概念が理解できず躓いて、頭が悪いと認識されたやつ
そんなやつが、それを明らかにせず、あたまのいいやつと同等のパフォーマンスを上げられる時代になったんだ。
そうして自分が馬鹿であることに自覚がないやつは、ある程度の時期で気づく。浅い。考える力がない。
そして、できないやつとレッテルはっていた、自分がバカにしてきた、
作業の遅いやつが、一番だいじな「思考力」をもってるのだと気づく。
便利な道具うんぬんじゃなくて、
それは経過にちょっと影響を与えるだけで、
