  |
はてなキーワード: オーバーヘッドとは
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
TypeScriptのスペシャリストでない俺が見ても型定義は本当に局所的でAnyばっかりだわstrictFunctionTypesがfalseだわts-ignoreばっかだわでTypeScriptの型チェックをまともに使ってなかった。
言語仕様のうちメインの機能を使ってない時点でバリバリ使っているという印象ではなかったしただトランスパイルのオーバーヘッド増やしてるだけのようにしか感じなかったのでとても不誠実だなって思った。
「私たちはTypeScriptを使って堅牢な設計を構築してまーす」みたいな文言があったら警戒しておくに越したことはないなって感じ。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、その利便性からプログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
そのとおりで、
APUやiGPUというものができてもう20年くらいになるけど、
いまだにオンチップのSoCとディスクリートGPUでは性能に雲泥の差があるのは面白い。
1978年のインベーダーから1988年のPCエンジンまで10年で、
結論、グラフィックとサウンドでは処理の難しさが天地ほど違うということだと思う。
https://btopc-minikan.com/note-gpu-hikaku.html
それに関連して、
GPUの仮想化もマイクロソフトがRemoteFXっていう技術で開発してたけど性能が悪くて断念した。
最近は日本人技術者メインにGPU-P（GPUパーティショニング）っていうものが開発中で、
これがもしオーバーヘッドなしで、
1940 年代後半から 1950 年代前半、土木技術者は、今日の技術者と同様の問題を経験していた。しかし、1950 年代と 1960 年代の一時期、これは変化した。大陸間弾道ミサイル(ICBM)計画の運用計画が始まったことで、ミサイルの地上環境の設計者は、ミサイルの設計者と一体となって仕事をしなければならないことが明らかになりました。
第二次世界大戦後、空軍はドイツの科学者を採用し、ドイツのV-2ロケットの備蓄品を捕獲してミサイル開発に着手した。1953年8月にソ連が熱核爆弾の実験に成功したと発表するまでは、資金不足がその努力を妨げていた。突然、ドワイト・D・アイゼンハワー大統領は、ソビエトに追い抜かれないようにICBMの開発に向けた大規模な努力を求めた。空軍の Bernard Adolph Schriever 少将は、ミサイルとその地上支援を開発するための努力の先頭に立った。
ICBMs
1.5段のアトラスと多くのサブシステムを交換可能な2段のタイタンの2つのICBMの開発がほぼ同時に開始され、知識ベースを広げ、最短時間で兵器を完成させるための競争を活性化させました。ICBMの開発と開発へのプレッシャーは強烈でした。推定 13 年かかっていた作業が、5 年以内に達成された。このことは、空軍の土木技術者にとって大きな意味を持っていた。時間的な制約よりも重要なのは、兵器システムの開発において、地上環境が後回しにされていないという事実であった。"飛行機は最低限の地上支援があれば飛行できるが、弾道ミサイルは適切な発射設備がなければ意味がない」というのが、このプロジェクトを主導した民間技術者の一人である空軍研究開発司令部弾道ミサイル部（BMD）民間技術部副司令官ウィリアム・レオンハード大将の見解である。
用地選定
ミサイルの特殊な要件と圧縮されたスケジュールは、建設作業のあらゆる面に影響 を与え、まず候補地の選定プロセスに着手しました。空軍のエンジニア、工兵隊の代表者、建築家・エンジニアファームのメンバー、BMDの職員で構成される数十人の調査チームが、アトラス計画だけでも250以上の候補地を調査するために、全国に散らばっていました。チームはネブラスカ州からジョージア州まで、ニューメキシコ州からニューヨーク州までを調査しました。候補地の適合性を判断する際に使用された厳格な基準には目を見張るものがありました。深さ174フィート、直径52フィートのミサイルサイロ、幅40フィート、深さ40フィートの発射管制センターサイロ、2つのサイロをつなぐ人員用トンネルとケーブルウェイを建設するためには、厳しい土壌と地質条件が必要でした。さらに、距離の要件は、サイロがその支援基地から少なくとも18マイル、人口25,000人以上の町から18マイル以上離れていなければならないことを意味していました。また、互いの距離は7マイル、人が住んでいる住居から1,875フィート、公道から1,200フィートでなければなりませんでした。サイトへの公共アクセス道路は、大型のミサイル運搬車を収容しなければならなかった。技術的基準が評価された後、最終的なサイトの選択は、サイトの経済的実現可能性に依存した。サイトが選択され、承認されると、作業を開始することができた。
地上設備の設計・建設を担当した技術者が直面した困難の一つは、ミサイルとその支援構造物の作業が同時進行で急ピッチで進められていたことである。ミサイルの準備ができたときには、発射設備を準備しなければならない。ミサイル自体に必要な設計変更が設備の変更に反映されてしまうため、ほぼ戦時中の緊急性の高い状況下での工事を余儀なくされていた。
ミサイルの保管モード、発射モード、ミサイルの分散度の多様性が技術者の作業に影響を与えました。例えば、アトラスDの一部のモデルは、サービスタワーで露出した垂直方向に保管されていましたが、他のモデルは水平方向に保管され、風雨から守られていました。アトラスEは半硬化構造の中で水平に保管されていました。アトラスF、タイタンI、IIはすべて、硬化サイロに垂直に格納されていました。
サイロの建設は膨大なエンジニアリング作業でした。例えば、カンザス州のシリング空軍基地では、エンジニアがアトラスFミサイルを収容するために12個のサイロを建設しました。作業は深さ40フィートの掘削から始まりました。これが管制センターの基礎となり、トンネルとサイロの上部を接続しました。その後、サイロの下部の残りの部分は、開 発部からさらに1.5m下で採掘されました。サイロ自体を構築するために、作業員はスリップフォームプロセスを使用しました。フレームがサイロの壁から約140フィート上に上がったところで、1時間に約14～16インチの速度でコンクリートが連続的に打たれました。作業員は昼夜を問わず、1つのサイロにつき、わずか6日間で500トンの鋼材と5,000立方ヤードのコンクリートを打設しました。完成時には、アトラスの1つのサイロには、15階建ての構造用鋼製ビル1棟の重量約1,500トンに相当する複合質量が含まれていました。
電力供給
打ち上げ施設に電源を供給するために、エンジニアはディーゼルエンジン、原子力、燃料電池、電池、ガスタービン、商用電源との様々な組み合わせなど、いくつかの代替案を評価しました。電源は、信頼性が高く、無停電で、打上げ施設内で自己完結するものでなければなりませんでした。また、核爆発による地上衝撃によって引き起こされる非常に高い加速度を吸収できるか、ショックマウントに取り付けられていなければなりませんでした。システムのイニシャルコストと運用・保守コストの両方が評価されました。サイトへの動力供給には、信頼性の高い旧型ディーゼルエンジンを選択しました。システムの設計では，水や流入空気の加熱など，装置から発生する熱を可能な限り利用しました．典型的なアトラスのサイトでは，各プラントに1,000kWのユニットが4基ずつ設置され，ミサイルのクラスターを支えていました．
サイロ上部ドア
サイロのオーバーヘッドドア設計は、エンジニアリングのジレンマを生み出しました。300平方フィートの開口部を覆うドアは、極端な天候、核放射線、過圧、構造的な反発からミサイルを保護し、ミサイルの発射と誘導に影響を与えないこと、発射合図後30秒以内に完全に開くこと、ミサイルのカウントダウン手順の中で連続した項目として動作すること、などが求められました。また、クロージャの構築、完全な組み立て、設置、フィールドでのチェックアウトを可能にするように設計されていなければなりませんでした。シングルリーフ設計やロールアウェイ設計のようなそれぞれの潜在的な設計には、それを考慮から排除する独自の特定の欠点のセットがありました。最終的に、ダブルヒンジ、ダブルリーフ、フラットドアのデザインが採用されました。2つの半分の間の中央の亀裂の問題は、ドアの特別なくさびの設計と、さらにシール性を向上させるためにネオプレンガスケットとステップメッシュを使用することによって解決されました。
様々なミサイルサイトの建設とアクティベーションに関与する多様な要素をすべてまとめることが、サイトアクティベーションタスクフォース司令官の仕事であった。彼は、親コマンドに関係なく、与えられた基地の弾道ミサイルサイトアクティベーションプログラムに参加しているすべての空軍の要素に対する作戦上のコントロールを与えられました。主に土木工学と諜報機関のキャリア分野から来た司令官は、現場支援施設と住宅の建設を指示し、建設監視を提供し、サイトの設置、チェックアウト、戦略航空司令部への転換を管理しました。土木、機械、電気技術者、低温工学、熱応力、衝撃実装の専門家、資金管理者、広報担当者、議会調査官への説明役などが求められた。要するに、彼らは空軍のためにそれを実現させた人物だったのです。1961 年までに、彼らはアトラス・ミサイル 120 発のアトラス・ミサイルを 11 基地に、タイタン・ミサイル 54 発のタイタン・ミサイルを 5 基地に配備していた。
おわりに
この記事では、この大規模な取り組みに関わった人々が直面した様々な工学的課題について簡単に触れただけです。その規模の大きさは今でも注目に値するものであり、土砂、岩石、泥の総量は3,755万立方ヤードに及びました。これは、ロサンゼルスからピッツバーグまでの深さ10フィート、幅10フィートの灌漑用水路に相当します。現場で使用された鋼材は、サンフランシスコからワシントンD.C.までの鉄道線路を建設することができました。当時、全国ニュース誌は「ミサイル基地建設計画はピラミッドをティンカー・トイの演習のように見せている」と述べています。アメリカ土木学会は、ICBM施設建設プログラムを1962年の "Outstanding Civil Engineering Achievement of the Year "に選出した。同様に重要なのは、この取り組み全体が、空軍の土木技術者に対する見方の転換点となったことです。空軍の技術者が自分たちのプロフェッショナリズムに対する尊敬と認知度の向上を求めていた時期に、ICBMプロジェクトでの彼らの仕事が道を切り開いたのです。
何言ってんだ、さてはアンチだなオメー。
―新しいARM Macは良いものだと思います。おおむねIntelモバイル上位機種の5割強くてRosettaで2～4割オーバーヘッドあってもまだ強いよというところが今回の勝つためのポイントだったのではないでしょうか。あとは低消費電力とAllways OnもあるけどSurface Pro Xでそれはユーザー・メーカーに届かなかった結果が出てるので…。
いやいやベンチガンガン攻めてんじゃん？
―気になる点がいくつかあります。
ネットで新Mac褒めてる人の実際の行動は「やっぱAppleってすげえな」でiPhone・iPadを買う。そう、Macの存在は知ってるけど必要はない。
Apple自身、桁違いのハード売上だけでなくロックインした市場でアプリ販売もあるiOSに比べMacにうまみがないのをよくわかってる。
なにしろiPhoneのおかげでこの10年Macにとって絶好最強の追い風コンディションだったのだけどシェア10%前後という状況は変わらなかった。
ARM版WindowsはそもそもMSにやる気がない感じもあるけど、ユーザーにとって「違いを意識せず移行できる」＝「特にメリットない」で、メーカーには「安くもならないしユーザーへのアピール少ないしアーキ変更の手間は多い」＝「デメリットしかない」から動かなかった。
Appleはその轍を踏まえて移行を決定事項にした上で実際速いM1で一点突破、無関心の壁を越えたいのだ。花嫁にドレス（新デザイン）も着せないまま。
でも超えてどうすんのかな…うまくARMに集約できてマルチスクリーン展開するiOSの未来しか見えないよ。
MacはAppleにとってアイデンティティなので政治的にもないがしろにはできない…しかしこれだけ騒いで数字が動かなければしようがない、でしょ？
| 必殺技 | 現実 |
|---|---|
| オーバーヘッドキック | 中途半端なクリアボールをシュートして押し込むケースが多い、センタリングを直接オーバーヘッドするのはスーパープレー |
| 直線的ドリブル | 真正面同士でショルダーチャージで吹っ飛ばすドリブルはない、反則 |
| ヒールリフト | ブラジル選手などが魅せ技でやる、欧州の選手は侮辱されたと感じるので反則で潰してやり返したりする |
| ツインシュート | 偶然で発生することはあるが狙って出せないしあくまでただのシュート |
| 三角蹴りディフェンス | 無駄な動きなので現実ではやらない |
| 隼シュート | ただの強めなシュート |
| ドライブシュート | 普通にある。コントロールが難しいので一流選手でもゴールを決められる選手は少ない |
| カミソリシュート | バナナシュートのように楕円軌道を描くシュートはあるがいきなり鋭く曲がるシュートはない（無回転シュートならそのように錯覚はさせる） |
| スカイラブハリケーン | ただの反則 |
| イーグルショット | ただの強めなシュート。地を這う強力なシュートはプレミアリーグでは撃つ選手はかなりいる |
| タイガーショット | ただの強めなシュート |
| 顔面ブロック | 偶然で発生する。発生したら受けた選手は悶絶して苦しんでる |
| ファイヤーショット | 燃えるシュートなんかねえよ馬鹿野郎 |
| キャノンシュート | ジャイロ回転？のシュートということになるのだろうか。撃てる選手はいない |
| スライダーシュート | いきなり横に曲がるシュートを撃てる選手はほとんどいない。そこまでのクラスになると歴代でもFKからのベッカムぐらいしかいない。 |
| ハリネズミドリブル | だからドリブルで真正面から弾き飛ばすのは反則だってば |
| フライングドライブシュート | 普通にある。コントロールが難しいので一流選手でもゴールを決められる選手は少ない |
| サンターナターン | ドリブル中にわざわざ反転してやらないが似た技にシャペウという技がありブラジル選手などが使ったりする |
| ローリングオーバーヘッド | そんな体操選手みたいなシュート撃てる選手いません |
| 雷獣シュート | そんなシュートはない、たまにシュートした時に地面の芝生も抉れてるシュートはあるが別に威力は上がらない |
| ブーメランシュート | コーナーキックから直接決めたりするシュートはあるので事実上それになる |
| ムササビジャンプ | ある。みっともないのでプロではあまり見かけないがやった選手はいる。しかもワールドカップでやった。 |
| 反動蹴速迅砲 | 狙ってできる選手はいない |
| スカイダイブシュート | 相手選手の足を踏み台にしてる時点で反則です |
| 直角フェイント | そのまま模倣してできる選手はいないが結果的に近いのではダブルタッチがある。イニエスタなどが名手 |
| リバウールターン | 現実にあるトリック。ドリブルでやっと現実にできるトリックが出てきた |
| つま先シュート | ロマーリオやブラジルロナウドなどが使うシュート。ドリブルが上手い選手が使うとシュートタイミングが取りづらくゴールを決めやすいようだ |
| セグウェイドリブル | できるわけないだろバカにしてんのか |
プログラマ35歳定年説は、体力的なもの、新しいスキルを学び続ける事、SE、PM等へのシフトアップが必要な事から言われていますが、
私は、「その年になるまでPGなんてしてられるか」とか「その年までにはSE等のシフトアップは必要でしょ」みたいな感じでした。
匿名さんは、コーディングに限界が来て辞めるのではなく、人との絡みに嫌気がさして辞めているようにも感じます。
システム開発は、企業の都合で開発責任者が決められてしまうために、その人材により、下の者は苦労します。
プロジェクトは国家のようなもので、酷い政治家(PM、SE)の国で暮らす(開発する)のはしんどいと思います。
システム開発するうえで、一番効率が良いのは1人で作り上げる事だと思っています。つまり、35才定年説なんてありません。
1人で作り上げる理由は、人が言葉と文書だけでコミュを取って意思疎通するのには限界があるからで、
今では相当なモジュールが完成されているために1人で開発する環境は昔ほど悪くはないと思います。
規模がどんなに大きくなっても、根幹部分や仕組みは1人が仕様決定してコーディングしておき、
その他はテストやメンテが容易になるようなコーディング規則と、
出来る限り単純な仕組みを作って他のプログラマに守りやすいようにして複数で開発することがいいと思います。
サブシステム毎にSEがいて、同時開発していけば、似たような機能を持つ関数・メンバが大量に別名で作られてしまい非効率になってしまいますので、
この雑務SEは重要なポジションで、意図や目的が明確になっていて中でどのように動くかが明確でなければ、
あと、人が増えれば意思疎通のミーティングも必要になり、冗長的になってしまいますので、その効率化も求められます。
話しを定年説に戻しますが、
という体力的な面について、日々感じている事を書きます。
20代では、携わるシステムの関数・メンバ・変数等は、約数千個程度は記憶出来ていますが、
30代では、それが半分程度になります。40代では更にその半分程度になり、50代ではせいぜい数百が限界になってきます。
それを補うための開発環境の進化と、コーディング内のコメントの充実で、逆に不具合の少ないシステム構築が出来るので、
20代では一気に開発が出来ますが、デバッグに時間がかかり、50代では開発は時間がかかりますが、デバッグには時間がかからないという傾向にあります。
それでも数百程度を越えて来ると翌日には忘れていく部分があるため、日々、忘れている部分を確認して思い出す時間だけ開発にオーバーヘッドがかかります。
そのため、常に忘れては思い出してを繰り返す事になり、自身の記憶容量の限界を痛感する日々になってしまいます。
【人との絡みで限界を感じているのでしたら】
限界だと感じた時が、定年なのかもしれませんが、システム構築をする事が楽しいのであれば、いつでも現場復帰していいんではないでしょうか？
技術は日々、新しくなって行きますので、頭に入れるのは大変かとは思いますが、根幹はそんなに変化ありません。
私自身も、必要にかられて自分でマルチタスク・スクリプト言語を開発していましたが、
量子コンピュータにならなければ、どれも似たような構造でしかありません。
また開発したいと思ったりクライアントがいて需要があるなら、1人で出来る範囲を開発して、足りない部分は誰かに委託してみてはどうかなあと思います。