「再利用」を含む日記 RSS

はてなキーワード: 再利用とは

2022-05-21

かつて人類は1と0を打ち込んでプログラムを書いていたらしい

それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた

多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの?という人たちと、まさにブレークスルー世界が変わるとエキサイトした人たちだろう。

色々あったが、人にも読めるソースアセンブリ言語に変換してくれるCが出来た。

多分このときも単なるアセンブリスーパーセットだろ?なんか意味あんのか?っていう人たちと、やばいレベルプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。

その後Javaが登場してオブジェクト指向が花開いた。

このときも、構造プログラミングに毛が生えた程度のもんだろ?何が嬉しいんだ?という人と、オブジェクト指向なら何でもできる!とエキサイトした人たちで溢れかえったことだろう。

Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。

何が何でも継承カプセル化ポリモーフィズムだとオレオレフレームワーク雨後の筍のごとに開発され結局Strutsに一網打尽にされた。

その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。

もはやこの時点で継承だのポリモーフィズムだのはそれほど重要ものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。

人月神話時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたことき誕生している。DIファクトリリフレクションでなんとでもなることでしょ?何が嬉しいの?と。

その後関数型プログラミング誕生する。

これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ?小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。

マシン語からアセンブリ、CからOOPトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。

抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからいくらいに思考が固まった人、はたまたこ技術なら全て解決できるのだからのものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。

多分20年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。

しか人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議ものだ。

しかに極端な話1と0だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。

オブジェクト指向が最適だった時代は確かにあった。

企業システムにせいぜい20台程度のホストを導入するようなものだった。

今は百や千のオーダーでは聞かない仮想ホストDockerコンテナ複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータアクセスするところではトランザクションに強いJavaというように適材適所住み分け必要がある時代になった。

当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術目的になっている。

継承ポリモーフィズムをする以上はスーパークラスライブラリもなくてはならないが、それも億劫になっているのかもしれない。

今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。

それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代過去のものになったと考えたほうが良いだろう。

関数型プログラミング理解よりも、オブジェクト指向習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。

そういう意味では業界としてだいぶ健全になったようにも思える。

まりにもポエミーで恥ずかしくなったので増田に書くことにした

かつて人類は1と0を打ち込んでプログラムを書いていたらしい

それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた

多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの?という人たちと、まさにブレークスルー世界が変わるとエキサイトした人たちだろう。

色々あったが、人にも読めるソースアセンブリ言語に変換してくれるCが出来た。

多分このときも単なるアセンブリスーパーセットだろ?なんか意味あんのか?っていう人たちと、やばいレベルプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。

その後Javaが登場してオブジェクト指向が花開いた。

このときも、構造プログラミングに毛が生えた程度のもんだろ?何が嬉しいんだ?という人と、オブジェクト指向なら何でもできる!とエキサイトした人たちで溢れかえったことだろう。

Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。

何が何でも継承カプセル化ポリモーフィズムだとオレオレフレームワーク雨後の筍のごとに開発され結局Strutsに一網打尽にされた。

その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。

もはやこの時点で継承だのポリモーフィズムだのはそれほど重要ものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。

人月神話時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたことき誕生している。DIファクトリリフレクションでなんとでもなることでしょ?何が嬉しいの?と。

その後関数型プログラミング誕生する。

これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ?小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。

マシン語からアセンブリ、CからOOPトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。

抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからいくらいに思考が固まった人、はたまたこ技術なら全て解決できるのだからのものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。

多分20年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。

しか人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議ものだ。

しかに極端な話1と0だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。

オブジェクト指向が最適だった時代は確かにあった。

企業システムにせいぜい20台程度のホストを導入するようなものだった。

今は百や千のオーダーでは聞かない仮想ホストDockerコンテナ複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータアクセスするところではトランザクションに強いJavaというように適材適所住み分け必要がある時代になった。

当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術目的になっている。

継承ポリモーフィズムをする以上はスーパークラスライブラリもなくてはならないが、それも億劫になっているのかもしれない。

今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。

それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代過去のものになったと考えたほうが良いだろう。

関数型プログラミング理解よりも、オブジェクト指向習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。

そういう意味では業界としてだいぶ健全になったようにも思える。

2022-05-19

anond:20220519163252

通はトイレットペーパーつかってトイレに流すもしくは乾かして再利用する

大量に使いやすいし

ちなみにおれは物心ついたときから床オナだったが25年くらいたって矯正できたぞ

2022-05-17

ゴーストタウンって何でゴーストタウンなんだ?

廃墟といえば、日本的には(アトラクションとしての)ディズニーランドホーンテッドマンションとか旭川かにある大正時代炭鉱で栄えた街の成れの果てといった廃墟施設なんかを思い起こすと思う。

漫画とかメディアミックスされたものだとそこに人に危害を加えるお化けがいるらしいんだけど

一度も遭った事ないんだよね。

霊感がある人にしか見えないとか言うんだけどじゃあ霊感が見えない人にはゴーストタウンって場所ゴーストタウンとは言わないよね。

現実的に見れば暴走族とか反社会的勢力隠れ蓑として廃墟再利用されてるという話はよく聞くんだけど

例えば検索してはいけない場所で暗がりの長いトンネルには人を死に誘う幽霊がいるぞとか噂や都市伝説話題になるけど

あれだって実は暴走族とか反社会的人達再利用してるだけで

ついでに言えばそこでよく亡くなる人っていうのはそういう連中に捕まってリンチされたりレイプされたり強盗目的殺害されたりといった事に尾ひれがついて

幽霊が出るぞ!危ないから近寄るな!というオチなんだけどね

ゴーストタウンだって多分国や自治体がしっかり管理してたらゴーストタウンって絶対言わないと思う

軍艦島だって本来ゴーストタウンだぜ?

でも世界遺産登録に則って反社を追い出したり環境整備をした結果、ゴーストタウンでなく見れる廃墟施設になったんじゃないか

きっとゴーストタウンっていう建物廃墟っていうのは誰にも管理されてない放棄地なんだけどそこに悪い人たちが入り浸ってしまって文字通り常人が入れる場所でなくなった

すなわちゴーストタウンだ!という事かもしれないよね。

2022-04-30

小便を火にかけたらやばい

ホテルのケトルで「カニ茹でた」宿泊客損害賠償請求される - 弁護士ドットコムニュース

https://b.hatena.ne.jp/entry/s/www.bengo4.com/c_18/n_14410/

このブコメで「おしっこを沸かすやつがいる」という噂が広まっているが、いっぺんでいいか自分おしっこを沸かしてみてほしい。

その部屋にいられなくなるくらいの臭気を発するぞ。カニを茹でるどころの騒ぎではない。

 

俺の自宅では冬場はトイレに小さな電熱ヒーターを置くんだけど、ある日うっかり小便をひっかけてしまった。

ありゃりゃ、と思った数秒後には涙が止まらいくらいの猛烈なガスが発生してパンツも履かずにトイレを飛び出さなければいけなかった。

映画マルサの女』でも、捜査官に自宅を包囲された容疑者が苦しまぎれに玄関で小便を沸かして捜査官を撃退するシーンがある。

「うわっ、ションベン沸かしやがった!」と逃げ出す捜査官のリアクションは、経験者の目から見て納得のいくものだった。

小便を火にかけるとそのくらいの殺傷力があるのだ。

 

ホテルの部屋のケトルで小便を沸かそうものなら、ケトルのみならず部屋も当分使い物にならないと思う。

寝るどころじゃないし、廊下にも臭気漏れると思う。

常識的に考えて、ホテルとしては一度小便を沸かされたケトルを洗って再利用する選択肢はないはずだ。

少なくとも俺が従業員なら小便を沸かしたケトルを洗いたくはないし、それをもう一度客に使わせようという気にもならない。

 

それやこれやを考え合わせると、「ホテルのケトルは小便を沸かしたかもしれないから使わない」というブクマカ判断杞憂にもほどがあるという気がする。

まあ好きにすればいいけど。

 

そんなことを心配するくらいなら備え付けテレビリモコンもっと関心を払ったほうがよいと思う。

男性客がテレビで有料チャンネルを視聴しながら何してるか想像してみ?

ホテルによっては「消毒済み」と書いたビニールでくるんであることもあるが、友達ホテルマンは「してるわけないじゃんw」って笑ってたぞ。

2022-04-25

おしぼりは洗って再利用されるものから

自分おしぼりおっさんが顔を拭いていたものかもしれないと思うと嫌だから

たとえ洗って高温殺菌されてても気持ち的に嫌。

2022-04-17

千羽鶴無駄になっていない!広島では卒業証書原爆資料館チケットなど、さまざまに再利用されている!

っていうのは、全国からいらない紙が大量に集まってきて、どうしようもないかしょうがなく再生紙にしているというだけだよね。千羽鶴を折った人は、自分の作った鶴が使い捨てチケットになって、半分ちぎられて、1、2時間で捨てられたかったの? 卒業証書をもらう人は、人生の節目にもらう大事な1枚を、折り紙を溶かして作った低品質再生紙でもらいたかったの?

2022-03-28

https://www.itmedia.co.jp/news/articles/2203/28/news082.html

アプリプリインストール禁止

メッセージングサービスの基本機能相互運用性の確保

買収と合併についての欧州委員会への通知

製品サービス内での自社優先の禁止

サービス収集した個人データの別サービスでの再利用禁止

ビジネスユーザーへの不公平な条件確立禁止

アプリストア登録開発者に支払いシステムなどの特定サービス使用強制禁止

これ発行されたら今のビジネスモデル完全に終わるな

まだ可決してないっていうけど、状況からして可決しないわけがないだろ

2022-03-12

anond:20220312153858

ツイッターツイッターが認めた方法での再利用は許容するという条件で会員登録してるんやで

なのでリツイートtogetterまとめもAPI引用著作権的には合法

2022-03-03

anond:20220303165940

自分プログラミングとか挫折したけど、環境構築とかドットインストールとかで教えてくれてるのじゃダメなんか?

今はDockerとかでやるんじゃないの?Dockerを使ったこともないし、それが環境構築を簡単にできるものなんだろうという推測でしかないけど

要は、あれって開発環境をいちいちやることによって整えるのが面倒だから仮想的な環境をいくつも簡単に作ったり、削除したりできるみたいな発想なんだろ

Dockerの前のなんだったかなー、その仮想環境みたいなのドットインストール最初にやったな

プログラミングってこういうなんか効率的に考えてやっていかないとぐちゃぐちゃになるんだよな

整理整頓大事みたいな感覚

なんでも再利用できるもの再利用やすいように作る感じ

2022-02-28

余った大学ノートは、4分割してメモ帳に使おう

まもなく3月ですね。

授業で使った大学ノートをたくさん処分する季節になりました。

しかし、ノートが全部使い切れなかったのに処分するのはもったいない!と思う人も多いはず。

そこで、大学ノートのまだ使っていないページを、どうにか再利用する方法を考えてみました!

もちろん、使ったページを破り、残りのページをそのまま大学ノートとして使うという方法もありますが、

授業や職場などで、そんな半端なノートを使うのもみすぼらしいですよね。

なので、ノートは加工して、書いてすぐ捨てるような形に変えた方が良いです。

そこでオススメなのが「メモ帳」です。

作り方は以下のとおりです。

大学ノートは、既に書き込んだページを破り捨て、白いページだけを残す。

ノートの長い辺に一枚一枚糊付けし、表紙から裏表紙まで全てくっつける。

③定規を用意して、ノートの表紙に十字に線を入れる。

④押し切りを用意し、その線の通りに切る。

そうすると、いい感じのサイズメモ帳が4ブロックできますエコにも繋がるので、お試しあれ。

2022-02-22

WEB系のエンジニアって今の仕事が窮屈じゃないんだろうか?

かく言う、自分も俗に言うWEBエンジニア

この業界が息苦しいなと感じているものの、この業界に居続けている

トレンドを追うと、高速化効率化みたいな内容しか出てこない。

自動デプロイだの、描画速度の向上だの、テスト自動化だの、新しいAWSサービスだの…

からサービスは作れるし、外部サービス連携APIを見ればプレーンで書ける。

VPSみたいにサーバー用してもらえれば、プレーン運用も出来る。

でも、プレーンで描くと「車輪の再発明」だの「再利用出来ない」って言われる(幻聴かもしれんが…)

いかシェア率が高いメジャーライブラリ方法を使って開発する事ばかり

フロント周りもそう

この世界に入った時は、色々華々しい事ができるって思っていた

実際は、開発環境やらモダンな開発手法やらごった煮なお作法勉強しないと「トレンドを追え」と鼻で笑われる

フレームワークやらECMAScriptを使わずプレーンで描いたら白い目で見られる。

そこまで使いこなせて初めて新しい技術を触る権利がある位面倒くさい

追ったら追ったで、「これ今すぐ使う必要なくね?」ってなって勉強の意義を見出せなくなる

今の自分が、コピペで開発で満足していた過去自分を見たら、自分説教してくれた先輩のように説教をするだろう

ブログ鵜呑みにするな、ドキュメントを見ろ」「コードコピペすんな、書け」「闇雲に手を加えんなログを読め」ってね。

ただ、あの頃みたいに、とりあえず作ってブラッシュアップして行こうっていう気持ちが今もあればまた違ったのかもしれない

プログラム所詮道具なのに、道具の手入ればかり勉強している気がして何か窮屈だなって思う

だけど、その思考で数年やって来たからこの思考から抜け出せない。

プログラムでモノを作るってもっと自由で良かったはずなんだがな…

結局、自分の中で答えが見出せなくて、WEBから離れる事にした

2022-02-14

anond:20220214105936

高級店を愛用しているブルジョワどもが、残飯再利用していたことに誰一人として気が付かなかったんだろう

残されたわさびわさび醤油にして再利用されても気が付かない人が何万円も食事お金を出す人の全員だったわけだ

2022-02-09

政治家として出馬するのに相応しい漫画家って誰だったんだろう

UQホルダーの終わり方どう思った?

俺は「まあ。出涸らし再利用の割には頑張ったね」ぐらいの気持ちかな。

ぶっちゃけネギま最終話の頃にはとっくにゲームバランスぶっ壊れて戦闘に緊張感なかったのによくまあ続けたわと感心する。

ラストカラーページについては……うーん……出馬表明した50代のオッサン金髪ロリとのキスシーンをハッピーエンド象徴にしちゃうかぁ……って気持ち

これと比べると進撃の巨人は凄いよく終わったね。

捨てきれない思春期衝動世界を巻き込む少女趣味、そんな子供じみた激動をそれぞれが抱えながらも、誰かのために幸せのために目の前の戦いに挑むのが人生なんだって終わり方は非常に健康的だ。

俺は赤松健政治家になるのはどうかと思うけど、諫山創だったら応援できた気がするんだよな。

描いてる漫画の感じでさ。

赤松って結局は若くてキレイで死ななくて強いロリショタが正しいんだって世界じゃん。

でもそれってリアルの汚らしい老人や年相応にバカなだけのガキとちゃんと向き合ってくれなそうだなって印象があるんだよ。

要するに、政治家向きの人が描く漫画に感じられないんだな。

じゃあどういう漫画家が向いてるんだろうって考えちゃったんだけど答えがでねーのよ。

なんかコレはって戯言を喋って見せてくれよ。

100文字ありゃお前らなら十分だろ

2022-02-08

ウルトラマントリガー』を遠くから眺める

『ウルトラマントリガー』からニュージェネレーションシリーズを眺めるからの続き

トリガー終わりました。

ブルーレイパッケージに、新型コロナ感染対策のために脚本を8割書き直したという情報があるらしく(未確認)、スタッフキャストの皆様大変お疲れ様でした。

なので、内容云々というより、何故こんな企画になったんだ、という憶測を連ねて、トリガーに関しては閉じることにします。

・『ウルトラマンティガ』のリブート

ティガは年数を経ているにも関わらずトップクラスの高い人気を誇っており、物語構成上は再登場し辛い終わり方をしているものの、何かしら再利用したいという思惑が円谷・バンダイ双方にあった筈で、落とし所として、ティガと繋がりのある別世界とされた様子。実際、トリガーの1エピソードで、ティガの登場を望む人がいればティガ召喚できるというご都合設定が作られたので、トリガーの使命は果たされたような(酷い)。

・これからどうするんですかね

次はウルトラマンダイナのリブートらしいです。

2022-02-05

anond:20220205141525

そういうときは使い終わった変数再利用するといいよ(さらなる地獄への誘い)

2022-02-02

月の手取りが 100 万円を超えた

額面で言うと 160 万円。40 代男性外資系 SE、既婚、二子23 区内戸建て。ボーナス込みで年収は 2,500 万円。この位になると金感覚がどう変わるのか、という話をしてみたい。

平均的なサラリーマン家庭よりは裕福な子供時代だったが、いうて金持ちというわけでもない東京寄りの埼玉の家庭で生まれ育った。今の知識感覚を持って当時の記憶から推測すると、世帯年収は 700〜800 万円くらいだったろうと思う。倹約家の母は、割り箸ラップも洗って再利用するし、油のついた皿を重ねると食器用洗剤の消費が増えるからと怒る、そんな人だった。

新卒一年目の年収は 400 万円強。諸事情があって実家お金を入れながら会社近くのぼろアパートに住むという貧乏一人暮らし経験したりしつつも、20 年以上ほぼ毎年年収を伸ばし続け今に至る。

年収が 1,000 万円を超えた時はすげぇ嬉しかった。…が、同時にこんなもん?とも思った。その時点ですでに二人養っていたからというのはあるにせよ、二倍稼いだら二倍贅沢な暮らしなんて事は全然なかった。年収 400 万円の頃と変わらず、値引きシールの貼られた商品ばかりを狙って買うし、松屋心の友だった。

年収が 2,000 万円を超えたあたりでふと気付く。別段贅沢をしている「つもり」はない。お得なクーポンを探すのは相変わらず好きだ。でもさすがに五倍稼ぐと金感覚が変わっていた。一般年収 1,000 万円というと稼いでいると思われがちだが、たぶんその一般的な感覚に当てはまるのは現実では 2,000 万円からだと思う。

例えば、


一万円以下は誤差という感覚がある。それ以上は値段に対する価値吟味するが、値段相応と思えば 100 万円まではすっと出せる。そんな感じ。

あらためて書き出すとずいぶん贅沢な暮らしをするようになったなと思う。子供のころに描いていた裕福な暮らしのものではないか。とは言え元が貧乏性なもんで、これ以上の贅沢はもはや思いつかない、というかこれより上は値段相応価値を感じない。例えば高級車とか全然要らない。

仮に年収が 5,000 万円にまでなったらレクサスに乗り換えるだろうか?そんな気はしないんだけど、10 年前は今ほど金銭感覚が変わるとも思っていなかったから、分からんね。もしもそうなる事があったらまたレポートしよう。

追記

謎の誰かが勝手に返信つけてるのウケる。持ち家だから家賃は払ってないよ。住宅ローン返済はしてて、その金額は 16 万だから近いけどw

2022-01-30

環境配慮したNTR

弊社では恥丘環境配慮したNTRを実現するため、NTR3Rを徹底しております

Reduce

無自覚ハーレム主人公からヒロインを全員NTRことにより、ゴミクズのようなNTRれ男の数を削減いたします。

Reuse

堕とした女は使い捨てせず、繰り返し使用いたします。

なお、昨今人気の定点カメラ演出の導入も行っており、より長時間長期間使用を実現しております

Recycle

堕としきった女を多数の男に提供再利用いたします。こちらは嗜好性が大きく分かれる部分でもありますため、お客様においては説明欄の記述や表紙のマークなどをよくご確認ください。

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

2022-01-23

どうして日本って、UE5、Unityのような投資効果が長期的に効くのではなく、1発逆転ジャンルばかりになるん?

日本だとエンタメゲームといった、1回作ってしまうと次回作アセットが活かせない・活かしにくいものばかりに投資しているように見える。

タイトル変わる度に、作った物をリセットとか、1から作るとか。

もちろんシリーズ物にして再利用する、とかやっているのはわかるけど、どこかでリセットが入る。


アニメ漫画なども強みって言ってるけど、毎回博打を打っているようなものでさ。

2022-01-06

anond:20220106104730

これ、増田で伸びない典型的な奴

増田で伸ばそうと思ったら

はてサホルホル再利用できる日本sage

はてサ反論与党叩きできる勘違いウヨ

はてサホルホル再利用できるフェミキチ

はてサ反論でオタ叩きできる勘違いキモオタ

このどれかで行かないと伸びない


https://anond.hatelabo.jp/20220106040323

これが伸びる増田

はてサ反論でオタ叩きできる勘違いキモオタ

2022-01-04

anond:20220104145459

さ、さよか…

なんかごめんな…

あれをいいかんじになんとかしといて / 小遣い

その作業基準にそってやっといて / 生活費・小遣い

作業を手順通りに行って結果これを目指して / 生活費・雑費・小遣い

この作業をするために準備と作業をしたら次のために整理を / 食費・雑費・小遣い

ここに決まった準備があるから、これをつかって作業をして、終わったら次の予定のための整理と、おわった作業確認から次の手順の準備を / 食費・光熱費固定費・雑費・小遣い

こんな感じでな、分けることができるってことは片づけることができるってことで片づけることができるってことは準備ができるってことかなと思ったわけなんよ…

小遣い→多い・少ない だから ふやす・減らす

ってなんの予定も立たないし何が多いのか少ないのかもわからないじゃん…

なんでも出したら出しっぱなしにしてどこにあるか覚えてるから問題ないと言って生活空間まったく共有する気なく再利用性なんかなくても都度いるものとりだせるからいいっていってるやつかなと思ったんよ・・・

食費が多いぞとか、生活雑貨が多いとか服に金かけすぎじゃねとか、趣味なんじゃないのとか言えるってことはそれだけ分けてるってことなんよな

食費にいれてるからとか雑費とか教育研修費用になってるとか、その科目に問題があるのだったら分けてる事じゃなくて用途の話で逆に用途が明確にできてるから指摘もできる

食費→通ってよし ってそれ おなら→通ってよし で漏らしちゃうのと同じで 中身チェックしてないと問題があるのは同じだしむしろ全部小遣いだったら小遣いの内訳をだせってことになれば家計簿と同じことになるじゃん…

anond:20220104070507

ツイート権利について

トゥギャッターTwitter利用規約に基づいて運営されておりますTwitter規約では、外部サービスTwitter上のツイート規約範囲内で自由に利用することを認めており、ユーザー再利用を認めていることになっておりますhttp://twitter.com/tos

そのため、ツイート投稿者許可をとっているかどうかに関わらず、「ツイートをまとめた」という行為自体Twitter,Togetter利用規約違反することはありません。

ツイート勝手にまとめられた」という理由のみでお問い合わせ頂いても、利用規約に則った利用の範囲内の場合運営にて対応ができませんのでご了承ください。

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