「オーバーヘッド」を含む日記 RSS

はてなキーワード: オーバーヘッドとは

2022-11-12

anond:20221111113625

開発者1人って会社のほかの人は何してんのって思った。

オーバーヘッド大きすぎなんだろうか。

2022-10-23

スポーツ試合って本末転倒になってない?

客がみたいのスーパープレイなのに、試合で勝ち負けつけるせいで皆つまんねープレイばっかしてんじゃん。

面白プレイショーとかにしたほうが効率的に凄いプレー見れるでしょ。

なんで見てて面白くならない方向に競技性持たせちゃったの?

オーバーヘッドシュートしたら+2点とか、予告ホームラン成功で+2点失敗で-1点とかにしようよ。

今のスポーツ観戦ってマジで無駄が多すぎるよ。

投手の肩壊すために粘るのが当然とかになってるの見て誰が面白いんだよ。

勝ち組人生持ち崩すのが嬉しい下卑たジジイとかは「ゲヘヘヘヘいいでゲスぞ。もっと壊し合うでゲス。ぐひょひょビールうまいゲゲゲゲゲゲゲ」

2022-10-20

「ならどんなiPadが欲しかったんだよ!!」

以下、ボクの考えた最強の iPad Pro

Magic Apple Pencil

強化されたタッチパネルにより、どんな金属芯のプラスチック棒も Apple Pencil 2 並みの入力デバイスに変わります

Stable Diffusion などのお絵描きAIサポート

最新の AI技術iPad でも。オープン自動画像生成の力をあなた仕事に取り入れましょう。

UI 描画をスピードアップさせるプロモード

熟練プロさらなる力を。すべての UI アニメーションを短くして、あらゆる操作魔法のように素早く。

ターゲットディスプレイモード2, ターゲットディスクモード

Thunderbolt4 で接続すれば、あなた許可で、iPad を外部ディスプレイに変えられます

接続したコンピュータから一般ストレージのように自由アクセスできます

Rosetta on iOS

macOS のすべてのアプリiOS に。

iSL

iOS subsystem for Linux の登場です。歴史ある GNU/Linuxユーティリティオーバーヘッドなしで利用しましょう。

USB to Smart Connector 変換アダプタ

指に馴染んだ USBキーボードが、最新技術で生まれ変わります

iPad はありません

今年の新しい iPad はありません。その代わり、従来のiPadが$200 安くなりました。

それともうひとつ

まったく新しいワンチップコンピュータ apple chipiOS の基本部分が動きます。$10 です。最先端技術と一緒に、電子工作世界を探索しましょう。

2022-10-19

anond:20221019142508

小学校時代キャプ翼TVアニメが始まったら部活に女が急増したり、Jリーグ選手が「キャプテン翼読んでサッカー始めました」って言ってるのを知ってるから別に評価だと思っていない

  

それはそうと

東邦学園キーパー若島津が右肩を怪我したってチームに打ち明けた後、DFが「俺たちが頑張って若島津の怪我フォローするんだ!!!MFが「追加点を取って若島津を安心させてやるぞ!!」って叫んでたら南葛怪我した方を集中的に狙ってきて、「どうやら南葛若島津の怪我に気づいたらしい(←さっきお前らが全力で叫んでた」って展開とか

・翼がダイビングヘッドでシュート決めた時に実況が「翼君のオーバーヘッドーーーー!!!!!」って叫んでたと思ったら、次週の頭で作者が「ダイビングオーバーヘッドシュート」というオリジナル技の解説をするとか

そういうギャグ視点での評価は低いと思う

2022-10-01

所謂JTCの総合職2年目なんだけど謎の事務作業に追われすぎて吐きそう

新卒2年目

とりあえず安定してるし公務員より若干待遇良いしええかと思って適当会社職種選んだ自分も悪いんだけど、ここまで意味不明兼務やらされると思わんかった。

現状の職種としては法人営業なんだけど、あらゆる事務作業の後始末みたいな業務押し付けられてて、周り見ても業務時間の2割も客とやり取りしてないのマジで意味分からん

なんというか自分本業(この場合法人営業)をこなすためのオーバーヘッドがでかすぎて、一周回って自分が何やってるかわからなくなってくる。

雑に例を書くと

・客から正式見積契約書案出してくれやと頼まれる(もちろんこれは普通仕事)

・社内サイト(最近Chromeで開けるようになった)から見積用のExcelマクロフォーマットを発掘・DL (~15分)

見積必要フローを社内サイト確認Chrome対応についてこれず表示できていない部門が扱う商材だったのでEdgeIEモードで開きなおす (~15分)

見積フォーマット必要商品コードがあるらしいのでその一覧を社内サイトから発掘 (~15分)

マクロから出力されたexcel方眼紙の表示が崩れているのでポチポチ成型。あと備考欄に書くべき免責のための文章過去申請から発掘して貼り付け (~45分)

・社内決裁の前準備として、『社内料金部門価格を審議させる申請書.xslxを出力させるためのexcelマクロツール』とかいファイルがあるのでそれの最新版DLして、起動中は他のexcelを開けない縛りを受けつつ申請書を作成 (~30分)

・社内料金部門価格を審議させる (1週間)

・客の要望契約書に文言の追加が必要になったのでWord契約書っぽい言い回しを作って社内の契約審査に回す(~3日)

・審議完了後、社内決裁のための文章を作り決裁のための正しい承認者を探す。最近あったグループ再編で契約周りをロクに整備しないまま適当に移行した後遺症もあり、無駄に問い合わせに時間がかかる。 (~2時間)

・社内決裁(~3日)

・ハンコ押してもらう(~10分)

・客に提案(普通仕事)

みたいな感じなんだけど、言語化できるだけまだマシな部類なんだよな。

こんなんが何十種類もあるので毎回手探りでやってる。

上の一個一個の作業は大した手間じゃないけどこれが7,8社×各3~5案件くらい並行してるので、ワイの貧弱なワーキングメモリ悲鳴を上げてる。

というか客に関係あるの最初最後だけだから、極論、間に挟まってる作業を俺がやってる意味なんもない気がする。

でも間の作業規定から外れるとまたその修正作業が増えて糞手間が掛かるので、客とのやり取りを削って雑にして社内用excelマクロを延々ポチポチしてる。

これに加えて「各部署内で事務作業効率化を図りましょう!」とかお達しがあってRPAライセンスだけ渡されて、通常業務の片手間でシナリオ作って効果検証して提出みたいなことをやらされたりする。(もちろんそもそもの仕組みがゴミなのでどんなに頑張って使いこなしても焼け石に水)

なんだかんだ業界トップのクソデカ企業しまがいなりにもITだDXだとか言ってるからもう少しマトモな仕組みがあるのかと思ってたわ。

何より何の意味もない作業時間を取られて、何のスキルも身につかないまま無為時間精神を削られるのが一番つらい。

これって国内企業総合職だと普通なのか?

2022-07-02

そんな貴方中国産👲CPU兆芯をプレゼント

パソコンってもう劇的に処理能力上がらないのか?

ベンチマーク数字としては上がってくのだろうが。

CPUクロック微妙に速くなっているがシングルコアの性能はほぼ変わらない。

マルチコアになったとして、ThreadripperのようにIOダイを使って大きくしても、劇的に速くならない。

3D V-Cacheで積層してキャッシュを増やしても、アプリレベルでは劇的に速くなってない。

更に積層するのはあるかもしれないが、熱問題に対する解決策がないので出来ないでいる。

UCIe規格経由で複数チップレットを接続するのが今後出てくると思うが、どれだけ専用の回路を搭載し利用するかで処理能力は変わるが、

Apple M1 UltraのようにProResの本数が増えても使いこなす人が居そうにないというのと似たことになりそうじゃないか

GPUのように広帯域のHBM/GDDRと、データ依存性がない場合は処理能力高くなるが、

CPU側のメモリーGPU側のメモリーとのコピーやらオーバーヘッドが合ったり、ゲームAIの一部といった感じだし、

ゲームもベンチ上は数字が変わるが体感変わらねーなってのに金額が高くなるのもな。

ユニファイドメモリーにするとApple M1系のように性能でないしさ。

メモリーだとDDR4DDR5で体感的にほぼ変わらない。

レイテンシは変わらないし、DDRの代わりになるものも出て来てない。

インテルがフォトニクスに注力してたり、日本半導体戦略でもフォトニクスとしてが上がっていたりするが、

光は早いようで遅く、メリットだと低電力か発熱源の分散しかない。

HPEがフォトニクスで先行していたが、処理能力というより、発熱分散での設計のし易さアピールだった。

DPU(データ プロセッシング ユニット)、OPU(Optical Processing Unit)はスパコンクラウドでは追加されるかもしれないが、

パソコンにはまだ遠そう。

DVD不要になり5インチベイがなくなり、SATA SSDがなくなって2.5インチベイもなくなり、

GPUカードも2枚以上搭載しても性能上がらず1枚のみ、

ケースがバカかい割に、中がスカスカになってしまっている。

ちょっとずつパーツ買って性能上げるなんてことはなくなって、全部とっかえ。

もう少しなんとかならないか

GPUレイト対応と言っているが、映画プロダクトでやっているようなレイトレとは全然かけ離れていて、

ゲームレイトレはまだなんちゃってしかない。

https://anond.hatelabo.jp/20220702145051

パソコンってもう劇的に処理能力上がらないのか?

ベンチマーク数字としては上がってくのだろうが。


CPUクロック微妙に速くなっているがシングルコアの性能はほぼ変わらない。

マルチコアになったとして、ThreadripperのようにIOダイを使って大きくしても、劇的に速くならない。

3D V-Cacheで積層してキャッシュを増やしても、アプリレベルでは劇的に速くなってない。

更に積層するのはあるかもしれないが、熱問題に対する解決策がないので出来ないでいる。

UCIe規格経由で複数チップレットを接続するのが今後出てくると思うが、どれだけ専用の回路を搭載し利用するかで処理能力は変わるが、

Apple M1 UltraのようにProResの本数が増えても使いこなす人が居そうにないというのと似たことになりそうじゃないか

GPUのように広帯域のHBM/GDDRと、データ依存性がない場合は処理能力高くなるが、

CPU側のメモリーGPU側のメモリーとのコピーやらオーバーヘッドが合ったり、ゲームAIの一部といった感じだし、

ゲームもベンチ上は数字が変わるが体感変わらねーなってのに金額が高くなるのもな。

ユニファイドメモリーにするとApple M1系のように性能でないしさ。


メモリーだとDDR4DDR5で体感的にほぼ変わらない。

レイテンシは変わらないし、DDRの代わりになるものも出て来てない。


インテルがフォトニクスに注力してたり、日本半導体戦略でもフォトニクスとしてが上がっていたりするが、

光は早いようで遅く、メリットだと低電力か発熱源の分散しかない。

HPEがフォトニクスで先行していたが、処理能力というより、発熱分散での設計のし易さアピールだった。


DPU(データ プロセッシング ユニット)、OPU(Optical Processing Unit)はスパコンクラウドでは追加されるかもしれないが、

パソコンにはまだ遠そう。


DVD不要になり5インチベイがなくなり、SATA SSDがなくなって2.5インチベイもなくなり、

GPUカードも2枚以上搭載しても性能上がらず1枚のみ、

ケースがバカかい割に、中がスカスカになってしまっている。

ちょっとずつパーツ買って性能上げるなんてことはなくなって、全部とっかえ。

もう少しなんとかならないか


GPUレイト対応と言っているが、映画プロダクトでやっているようなレイトレとは全然かけ離れていて、

ゲームレイトレはまだなんちゃってしかない。

2022-06-28

anond:20220628084752

ワイはにわかだからBIG3オーバーヘッドプレス+たまに懸垂、しかやっとらんで。

1日1,2種目、8回4セット程度しかやってない。

もう仕事ストレスと疲れで、この程度で限界を感じる。

2022-04-25

MATLABは今後どういう扱いになるのか

MATLABを使っているが、どうも中途半端存在になっている。

端的にいうと、お金を払っただけの価値があるか、だ。


言語的な競合はもちろんPythonになるが、Pythonとの差別化が出来てない。

Python側は純粋Pythonだと遅いが、今はC++ラッパーとして使うのが多くなっており、Pythonの方が速いということが起こる。

最近MATLABJITコンパイラによって昔ほどfor文を気にしなくても良くなっているが、それでも遅さは気になる。

GPU分散コンピューティングMATLAB対応しているが、使いこなすのに苦労する。

GPU使う場合だと、CUDAをそのまま使いたくなるし、GPUメモリーとのやり取りといったオーバーヘッドが加わるので、

単純にGPU使うようにしたら速くなるってことはなく、処理時間を測りながらトライアルを繰り返すことになる。


MATLAB側のエディタ機能が増えているとはいえPython+VSCodeとの対抗となると辛いものがある。


toolboxを追加で課金してCコードを吐き出すことはできるが、劇的に速くなるわけではない。



②toolboxは沢山あるが、使い始めると色々足りておらず、Pythonエコシステムが欲しくなる

toolboxは追加課金で開放されるDLCだ。

toolboxが多くなりすぎていることと、手を広げすぎているのかtoolboxを買って使ってみると色々足りないことがある。

買う前に調べるわけだが、色んな事ができそうだと思って購入し、実際使っていくと、嘘は言ってないが事あるごとに使いにくい所が出てくる。

GUI周りに関しては不満が多い。



GUIが重い、使いにくい

事あるごとにGUIが重たいのが気になって仕方ない。

また使いにくいのが多い。デザインが良いというのはコンシューマ用ではないので気にしないが、重たさと使いにくさで嫌になってくる。


④plotや可視化周りが重い

エクセル普通になっている今、エクセルで出来ないことが出来て欲しいが、そうなっていない。



色々書いたが、MATLAB中途半端なのだ

そりゃ便利な場合もある。あるが、かなり限定的だったりする。

2022-04-07

anond:20220407101012

うそう、メールで送る機能なら昔からあるんだよな。

こないだのおじさん(おばさんかも?)が言ってたのは、

SMTPじゃなくてSMBで送りたいっていう概念だった。FAX回線使って。

かにSMTP経由しないかダイレクトルーティングオーバーヘッドも少ないし面白いなと思った。

しかし56Kbpsというねw

2022-03-10

M1 Ultra」の感想

インテルAMDなどのCPUと、NVIDIAなどのGPUとの間の接続PCIeが速くなってきたとはいえ

双方向データのやり取りが発生するような場合は帯域の狭さがネックになる。

ゲームのようにGPUに投げっぱなしにして、GPUGPU側のメモリー、そしてディスプレイへの出力だけで閉じても大丈夫場合問題にならないが、

世の中そういうアプリケーションだけではない。

GPUカードが高くなっているのにも関わらず、CPU側のメモリーGPU側のメモリーで似たようなデータコピーしないといけないという、

部品代とコピーにかかるオーバーヘッドもある。


なので、「M1 Ultra」のように、CPUGPU間の帯域が大きく、ユニファイドメモリCPUGPU共通メモリーアクセス出来るというのはメリットがある。

インターポーザを介して帯域は確保出来ているが、遠いメモリーへのアクセスへのレイテンシは防ぎ用がないので、

チューニングしようとするとインターポーザを介するメモリーアクセスが発生するかどうかは、プログラミングで気にする必要はあると想像する。


さすがのApple最先端プロセスを使う、予約していたTSMCキャパを使い切る状態にしないといかず、数を出荷しないといかないのだろう。

良品選別したダイインターポーザで接続して、出荷するチップ数を増やすというのは選択肢としてよかったのだろう。

トランジスタ数も多くなりすぎて、EDAツール設計する時に必要になるシミュレーション時間馬鹿にならないはずで、

タイミング検証が済、動くことが保証できている領域があるというのは、段階を踏んで設計するということでも合理的だ。


ただ機能面では、単純に倍になってしまっているため、ProResの本数が増えて、使い切るような状況があるのか?という不安はある。

M1 Max」でそれなりにバランスを取っているわけで、「M1 Ultra」では多くなりすぎて使われない部分も出てくるだろう。

価格がそれなりに高いので、使われない部分があるというのは、あまり許してもらえないのではないだろうか。


インターポーザで接続する技術確率出来たので、そこのIF周りは変更せずに「GPUだけ増やしたチップ」と「M1 Max」を接続する

といったのは考えられるが、数がでないといかず、そういうのを作れるかどうか。


他にデスクトップ向けだが低消費電力を売りにしているのは気になっている。

Apple内に、電力を消費するがパフォーマンスを上げるという技術があるかどうかだ。

2022-01-26

中途半端に「リアリティがある!」なんて漫画は良くないよな

その漫画を見てその道に進もうとする子供はそりゃいるもんな

それが現実だと勘違いされたら困るに決まってる

キャプテン翼みたいにめちゃくちゃだと、誰も真似しねーもんな

メッシとか影響受けてたって人も、誰もオーバーヘッドシュートしねーし

ツインシュートもしないし

ドリブルで蹴散らして突破もしねーし

キャプ翼サイコー!!!

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-12-23

anond:20211223200953

中華製でWindowsが入ってる似たようなのがポツポツ発売されてるけど、あくまWindows

SteamDeckはSteamOSっていうLinuxベースのものらしいんだよね。

LinuxWindows仮想化は近年かなり進んでて、GPUパススルーオーバーヘッド無しにできるようになったてことでしょうな。

オーバーヘッドマスク

がほしいんだけど、どれがいいのかわからん。安くて十分な機能があるやつおせーて

2021-11-12

TypeScriptバリバリ使ってると説明されたので体験入社したけど

TypeScriptスペシャリストでない俺が見ても型定義は本当に局所的でAnyばっかりだわstrictFunctionTypesがfalseだわts-ignoreばっかだわでTypeScriptの型チェックをまともに使ってなかった。

言語仕様のうちメインの機能を使ってない時点でバリバリ使っているという印象ではなかったしただトランスパイルオーバーヘッド増やしてるだけのようにしか感じなかったのでとても不誠実だなって思った。

私たちTypeScriptを使って堅牢設計を構築してまーす」みたいな文言があったら警戒しておくに越したことはないなって感じ。

2021-10-27

アンドロイドJavaなのがね...

ここ10年でさらレガシーなっちゃった

まあ今ではKotlinフレームワーク使うから生でJava触ることはあんまないんだろうけど、

VMがある分のオーバーヘッド永遠にiPhoneに勝てないんだよね。

もともといろいろなハードウェアに載せたいという趣旨Java採用したんだろうけど、

実際はARM一強になっちゃったし、たまにx86アプリ動かそうとすると動かなかったりで、

結局アーキテクチャに合わせたチューニング必要という、中途半端な状況になってる。

まあ後知恵諸葛亮なんですけどね。

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、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年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

2021-08-16

【未経験から1ヶ月で】現役エンジニアが教える最良のプログラミング勉強法

プログラマーに憧れる皆さん!こんばんは。

自分文系から」「未経験から」と諦めていませんか?大丈夫です!プログラミングセンス不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます

今日は、未経験から最短で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)に変換してみましょう。そうすることで、自分が本当にそのコード理解しているのか、確かめることができます

フローチャートUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要スキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業顧客にとっては貴重な資料となるからです。プロエンジニアは、COBOLソースコード10万行を1週間でフローチャートにして、Excel転載することができます

ここで一つ注意すべきことがありますフローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたもの業務ではフローチャートとは認められません。これはまともな企業就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。

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構文を用いて、例外を潰すようにしましょう。

おわりに

全体的に専門用語盛りだくさんの記事になってしまいましたが、

部分的にでも理解すればプログラミングを見る目が変わるはずです。

うさんくさい記事インターネットには多いですが、

そういう情報に惑わされずに本物の技術を身につけてもらえればと思います

2021-07-02

初心者から中級者になるためのプログラミングのコツ

変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。

変数名は短く

プログラムで使う変数名は可能な限り短くしましょう。

理想は、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構文を用いて、例外を潰すようにしましょう。

2021-05-27

ミドリムシ水素

といわれたらん~水素かなあと感じる。

ミドリムシCO2再吸収するとはいってもCO2結局排出するし、

それなら水しか排出しない水素のほうがオーバーヘッドがないというか、未来感あるよね。

そもミドリムシ生物から化石燃料と同じで、生命依存してるし。

https://response.jp/article/2021/04/10/344838.html

問題水素を作り出すうえで必要な電力やらだけどそこは技術向上でなんかなりそ。

やっぱミドリムシより水素だなあ。

http://hydrogen-navi.jp/technology/manufacture.html

ログイン ユーザー登録
ようこそ ゲスト さん