  |
はてなキーワード: リポジトリとは
恋愛経験の有無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のような企業でも同じ考えのように思う
もちろん、そのレベルでのシェア争いや小競り合いが今すぐ消えてなくなるわけではないが、
長い目で見ればいつかはそうなっていくことは容易に予想できるわけで、
つまり、ソフトウェア産業というか、近年のバズワードでもあるテック産業というのは、
人生だって、みんな崖に向かって歩いたり、走ったりしてるだけである
その崖がどれだけ近いか遠いかとか、どれぐらいのスピードで崖に向かってるかとか、
それだけの違いであって、誰もがいつかは崖に到達して落ちる、つまり死ぬのである
しかし、そこには一発逆転や一人勝ちするチャンスも乏しくなり、
そういった金を求めるギラギラしたアブラギッシュは寧ろ嫌悪される存在となり、
しかし、そうやってった末に待っているのはコモディティ化であり、
ただの暇つぶしにさえなっていく
今は楽しい
でも、その楽しさの果てに死が待っている
の自由研究。
ネット上でよく見る話。ネットロアっていうのかしらん。違うかー！
DNA鑑定により家庭崩壊が多発することを懸念し国がDNA鑑定を禁止した。
って話。
で、ついでに托卵検知ができなくなったから婚姻率が激減したってオマケつき。
ネットの日本語情報しかあたってないので温度感はあるかもだけど、今現在伝聞で書かれてるのを見たら「(ネットの)井戸端会議特有の盛ってる感だな」って思っておくよ。
いざやってみるとうまい調べ方がわからないのでid:ibenzoさんの記事をひとつぐらいまともに読んでいればよかったわ。
日本語でぱっとでる以下のサイトによると2005年と2016年に関連法が改正されたようだ？
【託卵大国ﾄﾞｲﾂ･日本】DNA鑑定は無効「法律と裁判」訴えたらどうなる？
ttps://iirou.com/tom/
托卵が発覚したとしても
通ってしまったのか？
托卵調査の結果
10％が托卵と判明したとも言われる。
てか托卵率10％なら
無数の家庭が崩壊するだろう。
シングルマザーが溢れ、
路頭に迷う子供も多数でてくる。
そのため、
ほんまかいな。
すくなくとも「男たちがDNA鑑定に殺到すれば？」以降は筆者の妄想が入ってそうなんだけど。
素晴らしい法案がまとまった。
托卵であった場合、
托卵女は夫に実の父親（托卵男）の名を
明かさねばならない。
妻の同意によるDNA鑑定後に知る権利や費用の一部を得られるかんじだろうか。
私のググり力(ちから)が足りないために当時の日本語資料をサクッと見つけられなかったので、こちらの資料をお借りする。
ドイツ民法典における家族法 - digidepo_11538862_po_02850002.pdf
ttps://dl.ndl.go.jp/view/download/digidepo_11538862_po_02850002.pdf?contentNo=1
第1598a 条は、遺伝学的親子鑑定（genetische Abstammungsuntersuchung. 以下「DNA 鑑定」という。）の実施のための要件を規定する。DNA 鑑定の実施を望む者（父、母又は子のいずれか）は、残り2者に承諾及び遺伝情報試料の採取受忍を求めることができ、承諾が得られない場合は、家庭裁判所が承諾を代行し、遺伝情報試料の採取受忍を命じる。ただし、子が未成年者で、その子の福祉に反する場合には、裁判所は手続を停止する(58) ことができる。この条文は、民間のDNA 鑑定の普及により、母や子の同意を得ずに行われた遺伝子検査結果（秘密の父子鑑定）の証拠採用が争われ、連邦憲法裁判所の判決を受けて制定された「否認手続から独立した父子関係明確化のための法律」(59) により新たに追加された。
(59) 否認手続から独立した父子関係明確化のための法律 Gesetz zur Klärung der Vaterschaft unabhängig vom Anfechtungsverfahren (VaterKlG k.a.Abk.) vom 26. März 2008 (BGBl. I S. 441). 同法制定に関する連邦憲法裁判所の決定（1 BvR 421/05）は、秘密の父子鑑定による鑑定結果の証拠不採用を認め、一方で、父子関係否認手続とは関係なく、独立したDNA鑑定請求権を法律上の父に認めるべきであるとした。玉蟲由樹「子の出自を知る父親の権利（BVerfGE 117,202）〔2007〕」ドイツ憲法判例研究会編『ドイツの憲法判例IV』信山社出版, 2018, pp.55-58.
托卵うんぬんではなく勝手なDNA検査はダメで、でも検査が簡易になり、特に子供への同意無いDNA検査が増えてきたので家族法でも法整備し、同意ありでやろうねと明確に示したという考えはどうだろうか。
ドイツにおける遺伝情報の法制度 | 学術機関リポジトリデータベース
ttps://irdb.nii.ac.jp/00835/0002057570
第３に、自発性の原理（Prinzip der Freiwilligkeit）である。『連邦議会審議会答申』は、「遺伝子検査の実施は、被検者（getestete Person）の不可侵性を侵害する」がゆえに、「包括的な説明をしたうえで個人の同意を得てから行われる必要がある」との立場から、「この原理の例外は、法的にかなりかなり限定された範囲でのみ、しかもそれによって被検者の尊厳が侵害されない場合にのみ許されるにすぎない。特に遺伝子検査は、直接的にも間接的にも強制的に実施されてはならない」、と説き、ここから、当然のこととして、インフォームド・コンセントが要求されることに(33)なる。ここで興味深いのは、本人の了解や同意のない DNA解析に関する具体例として、2000年11月28日に下された、DNA分析の導入に関する初のバーデン・ヴュルテンベルク行政裁判所判決（2001年２月20日報道）が示されている点である。本件は、銀行の幹部を侮辱する匿名の文書を書いたのではないかと疑われた銀行員が、採取された DNAサンプルが本人の知らない間に DNA鑑定をされたことに基づき雇用主から無期限解雇の通告を受けたため、その解雇の違法性について争った事案である。本件について、同裁判所は、本人の知らないところで同意なく行われた DNA分析の結果に基づく解雇通告は違法である、と判示 (34)した。これは、注目すべき判決である。本判決を受けて、ドイツ連邦および各州情報保護委員会（Datenschutzbeauftragten）は、第62回会合での決定において、「法律上の権限なしに行われる遺伝子検査、または治療もしくは研究の目的のためにのみ原則として有効とされる本人の同意なしに行われる遺伝子検査を阻止するために、刑法典の中に基本的処罰規定［を盛り込むこと］」を要求して (35)いる。これは、刑法典では実現していないが、遺伝子検査法で実現した
４ つぎに、医療目的以外の検査について特徴を簡潔に挙げておこう。
第１に、出自の解明のための遺伝子検査については、本人への事前の説明と同意により実施することができるが、検査を行うことができるのは、医師のほか、出自鑑定の専門家で自然科学の高等教育を受けた者に限定されている（17条）
５ 最後に、制裁について述べておこう。本法でも、規定に違反して遺伝子検査を実施した場合、１年以下の自由刑または罰金刑が予定されており、対価を得てこれを実施した場合には、２年以下の自由刑または罰金刑が予定されている（25条）ほか、一定の行為について秩序違反として過料が予定されている（26条）。
素晴らしい法案がまとまった。
法改正と法案がまとまったではいささか指すものが違うような気がするが、普段立法に無関心なので怪しい。
ttps://twitter.com/akihiro_koyama/status/1338064643328131073
A new German law wants to force mothers to reveal their child’s biological father
ttps://www.newstatesman.com/politics/feminism/2016/08/new-german-law-wants-force-mothers-reveal-their-child-s-biological-father
を翻訳で見ると記事時点では提案段階。ただしakihiro_koyama氏のいうDNA鑑定義務化は読み取れなかったのでどういった文脈でこの記事とコメントを出したのかは不明。
いろいろ検索ワードをがんばってみたが、日本語のそれらしい話題がひっかからず。
コラム 75 「誰の子か白状しなさい」－自分の子が実の子ではなかったら ドイツの場合－ 2016/9/2 | 京都の弁護士による離婚相談｜姉小路法律事務所
ttps://www.aneyalaw.com/column/_75.html
ドイツで，カップルの子どもが，実は別の男性との間にできた子だった場合，母親はカップルの男性に子の生物学上の父親の身元を明らかにしなければならないという法案がまとまり，議会に提出される予定だそうです。
どうなんでしょうね？
自分の仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分で作業に当たったりと色々なんだけど、
最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分の案件にアサインされた。
内容としてはとあるテーブルの特定カラムのバリデーション処理が漏れているから追加してもらって、なおかつユニットテストを修正する、というもの。まあ簡単な奴。
Issueを振ってからしばらくすると同僚エンジニアから質問が来た。
「ん？」と思った。いや別に特殊なことなんて何もないIssueだし似たようなテストケースもリポジトリ上に山程あるしどうにでもなるじゃんって。
まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合のテストケースを網羅してください」みたいな返信をした。
しばらくするとまた質問が来た。「△△の場合のテストケースの実装方法がわかりません。」
いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有のビジネスロジックのことを聞かれるならわかるけどこんなレベルの対応どの企業のどの案件で振られても同じことやるだけやん。
この質問してるのが未経験の入社1ヶ月目の新入社員なら自分は笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。
その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。
成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。
自分はITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラやインタプリタレベルの不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。
こんな公式ドキュメントとデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。
その人はとにかく「わかりません」が多い。
レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。
うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。
こっちもいろいろ対策を考えた。
Issue振るときはソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。
でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。
もはやその人に仕事を振るのは「この作業を担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。
最低でもあと1年くらいは人事はこの状況らしい。。。
こういう状況ってどう扱うのがいいんだろうなぁ。
