  |
はてなキーワード: リポジトリとは
文脈がよく分からないので、他での指摘と重複していると思うが、個人的に思ったこと。
文章がMECEでないので「まあそういうことね」という話は措いておいて。
a. 日本語ウェブサイトの記事本数で比較することはフェアではない
新しめの技術を活用している人の情報収集の順番としては、エディタでライブラリの当該部分のソースコードを読む、GitHubにリポジトリがあるのであれば、そこのissuesで検索をかける、Googleで英語（エラー文言等なので必然的に英語になる）で検索する、Stack Overflowで質問するという感じだと思うので、Qiitaでの出現数が減ることは仕方ないと思う。
ミクロで見ると、フロントエンド系の主要な論客がQiitaから離脱していることもある。
SSGの登場によってSPAのネガな部分のほとんどは潰されていると思う。
SPA的な手法を使うのであれば、SSGにしろという指摘であれば、的を射ていると思う。
他にも色々と言いたいことはあるが「SPAのことを言ったら一斉に突っ込まれた」という事象を観測できないので、とりあえず以上。
恋愛経験の有無3群で比較したところ，有意には至らなかったが（χ２=4.01,df=2,p=.135），交際経験を有する者の約75％が，記録を伸ばしているし，いずれの群でも過半数以上が大学3年生以上で記録を伸ばしている．今回の調査対象者には競技レベルの差があることは否めないが，恋愛経験と成績向上には負の関連性はないし，恋愛の肯定的効果も示唆される．
交際期間の長さ3群で比較した．対象は恋愛経験のある49名である．χ２検定の結果，5％水準で有意差が認められ（χ２=6.38,df=2,p=.041），長期間交際群の約8割は記録を向上させている．中期間では向上，低下が半数となっている．短期群13名でも記録低下させていた者は1名のみである．長期にわたる特定相手との交際のみならず，短い期間であっても，記録の向上とは関係なく，長期間の安定した恋愛経験は記録の向上に寄与することも考えられる．
我々のデータからは，大学運動選手の恋愛は競技のマイナス要因ではなく，競技生活を充実させるプラスの要因になると言える．本論の副著者は，在学中も全日本のトップレベルの女性アスリートで4年生次に最高成績を収めている．彼女自身，学生時代の恋愛には肯定的であったし，「あくまでも競技生活が第一優先事項という前提が不可欠で，恋愛関係と競技生活の優先度が逆転してしまうと、やはり競技生活に悪影響を及ぼしかねなかった」と回想している．
神戸大学学術成果リポジトリKernel http://www.lib.kobe-u.ac.jp/kernel/seika/cover/ISSN=21868719.html
棒が伸びると記録も伸びる (至言)。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
361あとで/3270users 逮捕にそなえる人生継続計画 - やしお
257あとで/1505users 筑波大教授が著した無料の初心者向けPython教材「とてもわかりやすい」「素晴らしすぎる」 | Ledge.ai
246あとで/1545users 【独学可能】英語を話す方法 第二言語習得研究と行動科学に基づく英語学習ロードマップ - ポリグロットライフ | 言語まなび∞ラボ
228あとで/1502users 「1Byteが8bitに決まったワケ」についての長い話 まずは「バベッジの階差機関」から | ITMedia
228あとで/1340users 1on1 ノウハウの共有 | DevelopersIO
218あとで/2069users 音声合成業界に激震! もはや人間の喋り声、入力文字読み上げソフトVOICEPEAKはビジネス用途でも自由に利用可能｜藤本健の “DTMステーション”
172あとで/1057users 2022年ウクライナ情勢をより深く理解するための歴史文化背景雑学｜tadhara｜note
170あとで/912users BIOSからUEFIへ BIOSはなぜ終わらなければならなかったのか | ITMedia
168あとで/1175users 早く寝るために自分自身をハックする - 本しゃぶり
160あとで/1187users 富士通の撤退する「メインフレーム」ってそもそも何？ | koduki | Zenn
152あとで/854users 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか | 櫛田 瑞穂 | SpeakerDeck
148あとで/1128users 【登大遊】天才エンジニアの安寧を求めない生き方「日本で“大義”を持って働く選択は有利」 - エンジニアtype | 転職type
146あとで/1624users 元葬儀屋のワイが神奈川県警の悪事を淡々と話すスレ : うしみつ-5chまとめ- #神奈川
143あとで/756users 事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選｜Shin｜note
142あとで/1250users 「Google検索は死んでいる」がバズったので「まとも検索」を作った。：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
138あとで/728users OSS未経験「なにから始めたらいいかわからない…」←これを一気に解決する神リポジトリ - Qiita
137あとで/1202users 中小企業でApple製品を利用する前にやっておくこと | Hiroshiman | Zenn
128あとで/1357users 1分でわかるウクライナの歴史 | anond.hatelabo.jp
124あとで/1265users 【Mac】Kindle本も永久保存！自動スクショでPDF化する方法｜脱凡リーマンブログ
124あとで/1192users これだけは押さえよう！住所フォームの作り方 - ケンオールブログ
119あとで/928users 今のウクライナ情勢が分かりやすくなる…地政学漫画『紛争でしたら八田まで』が凄いと話題 | Togetter
118あとで/875users 「詩」というもの／谷川俊太郎｜「新潮」編集部｜note
118あとで/955users 子どもの自己肯定感を下げるNG言動 5000人を育成してわかった低い子の特徴（みらのび） - Yahoo!ニュース
115あとで/1012users 人は「楽と感じる方法」しか選ばないことを前提に、仕組みを作らなければならない。 | 桃野泰徳 | Books & Apps
112あとで/1044users 定年退職後に料理をはじめた父の「大葉漬け」がヤミツキ必至の美味しさでご飯がとまらない/ 大葉の大量消費にもオススメ！ | 砂子間正貫 | RocketNews24
112あとで/760users 東京都デジタル人材確保・育成基本方針 ver.1.0 | 東京都 | SpeakerDeck
111あとで/631users ソフトウェアアーキテクチャの基礎 | O'Reilly Japan
108あとで/652users ブラウザで動くサービスを作るときの技術選定 | moga | Zenn
105あとで/755users 2024年に制度変更「つみたてNISA」 始めるなら2022年が有利な理由 | マネーポストWEB
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
なんかの機能追加というタスクがあるとまずタスクを分割してTODOアプリに登録する
こんな感じ。できる限り1タスク1～5分くらいで終わる量に分割する
1メソッドが大きい場合は例外処理のみ、DB登録部分のみ、メール送信部分のみとかそれだけでもタスクを分ける。
30秒で終わるようなことでもタスクとして独立してたら分けて登録する
「30分あれば上から12個こなせるな」とか見積もりして該当タスクに印をつけて30分タイマーで都度タイムアタックする
タイムアタックが終わると5分ほど休憩。見積もってた分が30分より早く終わってもその時点で休憩。5分くらい？
Youtube見たり在宅だったらえっちぃビデオ見たり音楽聞いたり好きなことをする。
終わったらまた30分分のタスクを見繕ってタイムアタック。それの繰り返し
ちなみにSlackで問い合わせとか来た場合はその時点で返信より前にTODOとして登録。何故ならそうしないと絶対返信忘れるから。
プログラマだ。
売上は毎年1500万を越える。
お客さんからの信頼は厚い。
週に最低3本は電話がかかってくるぜ。
うちの会社で社員教育を真面目にしているのは、ぶっちゃけ俺くらいだ。
教育といっても新人なんて当然いないから、社内のイマイチ仕事ができない暇そうな(本人は忙しいつもりらしい)人を2人くらい適当に貰ってきて、イチからプログラミングやチーム開発や顧客対応やドキュメント作成を教えるって感じだ。
なんとか自走できて自律成長できるプログラマができあがるって寸法だ。
このように俺は売上以外の面で会社に貢献している。
俺偉い。
最近都市圏ではプログラマ(それともITエンジニアと呼ばれたいか?)の給料がうなぎ登りらしい。
うらやましい限りだ。
でも俺はそんなお前らに、本当に売上立てているのか?と問いたい。
会社の売上を均等割するんじゃねーぞ。
お前の売上だ。
いくらだ。
せめて800万は越えてるか?
だとしたら哀れだな。
これは例年の最低売上だ。
俺すごいだろ。
そうなんだ。
俺スゲーしたいだけでこの増田を書いたんだ。
別にお前らがうらやましいわけじゃない。
いや、うらやましいんだけど。
そもそも俺べつに偉くないしな。
なのに偉そうなこと言ってゴメンな。
思わずね。
吐き出したくなったんだ。
さっき教育頑張ってるって言ったじゃん。
チュートリアル用のリポジトリ作ったり、トレーニング用のプロジェクト作ってチーム開発の真似事したり。
みんな転職していったんだ。
さわやかな笑顔で。
ニコニコしながら。
なぜか涙が止まらないんだ。
昨日見つけたいくつかのGitHubのリポジトリを面白く眺めてる
20代のフランス人だったり、40代のブラジル人だったり、色々である
ブラジル人は体力有り余ってるのか、
絵だとやりにくいなぁ、と思ったりする
みんなでブクブク浸かって楽しむみたいな世界は、
で、思ったのは、やはりプログラミングというのは、
過去のゲームがルールの発明だったこととかは古臭いものとなり、
コードも言葉と同じように無償で自然と発するものに近づいていく
ここで思うのは、スティーブ・ジョブズがこの世界をIBMの、
いわゆる、ソフトはハードのおまけ、の世界に戻したことであり、
ビル・ゲイツだったか、ソフトウェアは無償化していくという予言は当たっていたのだろう
それをマネタイズするには、ApacheでWebサービスを立ち上げるみたいな、
いわゆるGNUライセンスであれ、運用やサポートではお金が取れるが、
Node.jsを開発したら、開発者は当たり前だが一番Node.jsに精通しているわけで、
企業を顧客にNode.jsのサポートを有償ですることでマネタイズできる
ソフトウェアは無償化し、コードは会話のように無償で、ライブなものになり、
あー、そういう世相を予測して、
先に牛耳っておこうという点でMicrosoftによるGitHub買収は正しかったのである
ソフトウェアがなんでも無償に向かうのはMSとしても良くは思えない動きだったはずだが、
今はまったく反対方向にMSは向かっており、収益の基盤をAzureなどに移している
今すぐはありえないが、WindowsというOSも意味はなくなっていく
これはAppleやGoogleのような企業でも同じ考えのように思う
もちろん、そのレベルでのシェア争いや小競り合いが今すぐ消えてなくなるわけではないが、
長い目で見ればいつかはそうなっていくことは容易に予想できるわけで、
つまり、ソフトウェア産業というか、近年のバズワードでもあるテック産業というのは、
人生だって、みんな崖に向かって歩いたり、走ったりしてるだけである
その崖がどれだけ近いか遠いかとか、どれぐらいのスピードで崖に向かってるかとか、
それだけの違いであって、誰もがいつかは崖に到達して落ちる、つまり死ぬのである
しかし、そこには一発逆転や一人勝ちするチャンスも乏しくなり、
そういった金を求めるギラギラしたアブラギッシュは寧ろ嫌悪される存在となり、
しかし、そうやってった末に待っているのはコモディティ化であり、
ただの暇つぶしにさえなっていく
今は楽しい
でも、その楽しさの果てに死が待っている
