  |
はてなキーワード: コンテナとは
それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた
多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの？という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。
色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。
多分このときも単なるアセンブリのスーパーセットだろ？なんか意味あんのか？っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。
このときも、構造化プログラミングに毛が生えた程度のもんだろ？何が嬉しいんだ？という人と、オブジェクト指向なら何でもできる！とエキサイトした人たちで溢れかえったことだろう。
Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。
何が何でも継承でカプセル化でポリモーフィズムだとオレオレフレームワークが雨後の筍のごとに開発され結局Ｓｔｒｕｔｓに一網打尽にされた。
その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。
もはやこの時点で継承だのポリモーフィズムだのはそれほど重要なものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。
人月の神話の時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたこのときに誕生している。DI？ファクトリとリフレクションでなんとでもなることでしょ？何が嬉しいの？と。
その後関数型プログラミングが誕生する。
これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ？小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。
マシン語からアセンブリ、CからOOPとトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。
抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからないくらいに思考が固まった人、はたまたこの技術なら全て解決できるのだから他のものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。
多分２０年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。
しかし人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議なものだ。
たしかに極端な話1と０だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。
企業がシステムにせいぜい20台程度のホストを導入するようなものだった。
今は百や千のオーダーでは聞かない仮想ホストにDockerコンテナが複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータにアクセスするところではトランザクションに強いJavaというように適材適所住み分ける必要がある時代になった。
当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術が目的になっている。
継承やポリモーフィズムをする以上はスーパークラスのライブラリもなくてはならないが、それも億劫になっているのかもしれない。
今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。
それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代は過去のものになったと考えたほうが良いだろう。
関数型プログラミングの理解よりも、オブジェクト指向の習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。
そういう意味では業界としてだいぶ健全になったようにも思える。
あまりにもポエミーで恥ずかしくなったので増田に書くことにした
＊＊＊追記
何も調べないで主観のみで適当に書き連ねた文章にどうもすごそうな人たちがやたらまじめに反応していて申し訳ない気分でいっぱいになった。
この文章を書くにあたって全く頭は使われておらず、裏もとられておらず、確認もされていないことだけは付け加えておかないとマジレスしてくれた人たちに申し訳ない気持ちがすごいので書いておくことにします。
それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた
多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの？という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。
色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。
多分このときも単なるアセンブリのスーパーセットだろ？なんか意味あんのか？っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。
このときも、構造化プログラミングに毛が生えた程度のもんだろ？何が嬉しいんだ？という人と、オブジェクト指向なら何でもできる！とエキサイトした人たちで溢れかえったことだろう。
Java以降のIT界隈ではもはやオブジェクト指向抜きには語ることはできなくなった。
何が何でも継承でカプセル化でポリモーフィズムだとオレオレフレームワークが雨後の筍のごとに開発され結局Ｓｔｒｕｔｓに一網打尽にされた。
その後RoRによるCoCによってXMLなんかいらねーわとなったがアノテーションを使う方に進んでいった。
もはやこの時点で継承だのポリモーフィズムだのはそれほど重要なものではなくなったと言ってもよく、このあたりからEoDだとか、再利用性、メンテナンスのしやすさに主軸は移っていったと感じている。
人月の神話の時代から語られた銀の弾丸はないというたった一つの真理は忘れ去られオブジェクト指向ならなんとかなる、オブジェクト指向だという人々もまたこのときに誕生している。DI？ファクトリとリフレクションでなんとでもなることでしょ？何が嬉しいの？と。
その後関数型プログラミングが誕生する。
これを見た人々の中には、関数型プログラミングなんかJavaよりもそけつこうにしたていどのものだろ？小さいクラス作ればJavaでもできることをなんでわざわざ関数型プログラミングに移行しなくてはならんのだときっとそうなったることだろう。
マシン語からアセンブリ、CからOOPとトレンドが移り変わる中で起きているのは、技術革新であり、もうこのままじゃきついからこっちにしようというムーブメントであり、それに乗る人、抗う人というのは必ず現れる。
抗う人の中には、新しい技術に対するモチベーションは失われているがポジションを失うのだけはごめんたといういわゆる老害と呼ばれる人たちや、本気でシフトする意味がわからないくらいに思考が固まった人、はたまたこの技術なら全て解決できるのだから他のものはいらないという信仰を持った人などがいるし、乗る人もこの対極にいるのだろう。
多分２０年後には関数型プログラミングとは違うなにかが天才たちの中から爆誕し、同じような議論が起きることは想像に難くない。
しかし人類はどうすれば簡単に1と0をコンピュータに保存できるのかということをひたすらに追い求めているのだから不思議なものだ。
たしかに極端な話1と０だけ打ち込めれば同じことはできるかもしれないが、その難易度は遥かに高くなっているし、現実的には不可能だろう。
企業がシステムにせいぜい20台程度のホストを導入するようなものだった。
今は百や千のオーダーでは聞かない仮想ホストにDockerコンテナが複数動きこれらが協調しなくてはならない、もしくは各自独立で動いても問題が起きてはいけないので、ここには関数型のデザインが合うと思うし、一方でデータにアクセスするところではトランザクションに強いJavaというように適材適所住み分ける必要がある時代になった。
当然Javaだけでもできるし、関数型たけでもてきるかもしれないが、こういう形の議論をする人はその技術が目的になっている。
継承やポリモーフィズムをする以上はスーパークラスのライブラリもなくてはならないが、それも億劫になっているのかもしれない。
今後関数型プログラミングがあらゆるものを席巻する時代になるかもしれない、OOPがそうであったように。
それとも人々はもうそういう不毛なことはしないのかもしれない。もはやそういう時代は過去のものになったと考えたほうが良いだろう。
関数型プログラミングの理解よりも、オブジェクト指向の習得よりも、目的を達成する最小のコードをエレガントに書くといういわゆる画力が何よりも先に求められる時代に入ったのではないだろうか。
保険業は古代の貿易船の保険から始まっているので、海運造船業界と保険業界は異種同業
船同士の事故、難破、事故船があえてコンテナを捨てざるを得なかった場合、過失割合、どちらの船がどこまで損害を負うのか
ドイツ帝国が率先して、国際法をまとめる国際法協会を作り、共同海損の保険規則を作った
そのドイツのシーメンスは薩摩閥と海軍軍人斎藤実などに贈賄したのはバレたが、当時の検事総長は忖度思想検察の平沼騏一郎
しまいには満州事変がおきて犬養が暗殺され、斎藤実の軍事政権が初登場
ナチス内閣は保険会社アリアンツ出身の閣僚が仕切り、平沼騏一郎も大審院長やら総理大臣になった
つまりナチス・保険業界・海運造船業界が、日本の人事をやって戦争計画を推進したようなもん（あるいは国際法協会も）
ロシアの政治家もよく「国際法がー」言うが、彼らは国際法協会の何だろうな
226事件だって斎藤の口を封じるための暗殺事件だったかもしれないしなぁ
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
こんな機能までロシア人同士で喧嘩していたような野蛮人共が、まともなコロナチェックもせずに入国していくのが悔しい。
相手がよどのVIPでもない限りはたとえオリンピックの選手であろうと入念に審査をする。
外国人であればPCRなんて簡単なチェックでは終わらせず、数日ほどは閉じ込めておいて発症しないかどうかを観察する。
ボディチェックなども念入りにやる。
荷物は全て二重底がないか確認するため財布の中身だろうが土産物だろうがしっかりと全てを開いて確かめる。
人体などは当然のごとく念入りだ。
尻の穴は男女問わず出し、男であるなら睾丸の中に大麻の袋を隠していないか、女であれば乳房や子宮の仲間でしっかりと確認を取る。
そうやってしっかりと入国を管理する場合はあんなスムーズにこの国の地面など踏めるはずがないのだ。
誠に穢らわしい。
国家元首たちの人気取りに取り入ってまともな審査もされずに我が国の新生な土を踏もうなど。
どうせロシア人なんてものは生まれに多少の東西の差があろうと大部分はスパイやハッカーに違いがないのだ。
さもウクライナの危険な暮らしから逃げてきたなんて言っているが、実際にはロシアのスパイ、それどころかさらにイスラムやらユダヤやらの怪しい依頼人に雇われた二重三重のスパイやも知れぬ。
そんな生まれついての犯罪者の集団がよくもまあ我が国に上がり込んだものだ。
全くけしからん。
政府専用機になんぞ載せずにコンテナにでも詰めて運んできてアレコレ理由をつけて適当に台湾にでも送りつけてやればよかったものを。
信じられないことをする。
やり方はタブ追加ボタン（＋ボタン）を右クリックして、作成するタブが所属するコンテナを選択するだけだ。
最近趣味で動画制作始めたんだけど、普段使っているアカウントの履歴とか興味情報が混ざるとうざいなとおもってサブアカウント(チャンネル)つくって運営してたんだけど、まあyoutubeのアカウントを切り替えるのがくっそだるかったんだよな
それで、まあメインで使っているPCと動画制作で使っているPCで使い分けてたんだけど、ちょっとしたコメント返信とか、アナリティクス情報見るためだけにわざわざ動画専用PCまで移動して確認するみたいなのかったるくて
じゃあ手元のPCで見ようとすると結局、アカウントを切り替えて確認するんだけど、アカウント切り替えしちゃうと、アカウントの間で履歴がぐちゃぐちゃになってしまったり、別のアカウントでコメント書いてしまうとかそういった事故が起こりそうであんまり頻繁にアカウントをきりかえたくないんだよね
どうしたもんかと思ってたら、Firefoxのマルチコンテナ機能があるじゃねーかといった塩梅ですよ
コンテナでくくられたタブは、コンテナ内で独自のセッションがつくられて、キャッシュやら何やらが隔離された、いわばべつブラウザみたいなあつかいがされるわけなんよなぁ
以前はプライバシータブで似たようなことしてたんだけど、それしちゃうとアドオンが機能しなかったり、当たり前だけどブラウザを閉じて開き直すと情報が消えるとか、微妙に使い勝手が悪かったんだよね
全部全部まるっと解決だわ。すげーべんりだ！
うっすらと昔コンテナ機能がついかされたよーみたいな記事はどっかで見たんだよな。その時はなんか便利そ〜だけど、使いみち思いつかねーなとしか思ってなかったけど、ああこういう使い方になるんだなって想いましたわ。
本当は、仕事とプライベートでタブを使い分けるとかそんな感じの使い方になるんだろうけどな。
会社でFirefox使ってる人は、一部のタブだけプライバシータブとして作っておいて、個人的な利用にはその他部を使うみたいな感じになるのだろうか。
例えば会社でAWS使いながら、個人タブでも自分のamazonアカウント使ったりとか、そんな感じで使えると思う
通信衛星会社の英国インマルサットは19年に投資会社に売却され、21年には米国ヴィアサットが購入した（日本ではKDDIも株主か）
購入後株価は下落、ウクライナ紛争が始まったタイミングで何者かが衛星を壊し、戦争被害か不明だが保険は保険金を支払う
なおロシア海上運送もインマルサットを使用していたし、米英自演の可能性だってなくはない
ウクライナは米国Xスペースのイーロン・マスクに人工衛星通信機器の特別寄与を受け、同氏はそれをツイッターで宣伝、マスクの大きいこと
パイプライン派→事故は、保険はともかく欧州に致命的なので無事故志向になるはず
しかし今回戦争を起こしたのは何代目か知らないがプーチンで富豪
海上輸送派→オランダ海上帝国に始まっており巨大で船は多く事故もあり司法上も特別扱いのよう
コンテナ崩れのタンカーが神戸に来たり、偽旗、値上げなど古来の嫌がらせ方法は未だに使用されている
契約してる1つのサーバで個人ブログとか昔ながらのBBSとかブラウザゲームとか種類が違うサービスをいくつも運営しているけど、サーバの運用方法が流石にレガシーすぎるからもうちょっとモダンな感じにしたいと思ってる。
でも中々抜け出せない。
まず前提としてAWS,GCP,Azureは高いから使えない、同スペックなら適当なVPSの方が圧倒的に安い。
最近流行りのコンテナ構成みたいなのもいくらDockerが昔のVMに比べるとリソース食わないと言っても例えば
「1つのサーバで10個のサービスを相乗りで運営しなければならない」みたいな場合に1サーバ内で何十コンテナ起動みたいなの運用すると流石に相当重くなっちゃうよなぁ。。。
あとnode.jsとかginみたいに1サービスごとに常駐プロセスが増える技術スタックも多分あんまりよくない、必要ポートを管理するのも大変
結局自然と行き着くのは格安VPS借りてLAMP構成作ってVirtualHostで相乗り設定して昔ながらの方法で運用する方法になっちゃう
php+apacheの構成ならアクセスの少ないサービスを何十個運用しようとアクセスがないならそれにリソース食われることがないんだよね、何気にLAMP環境の結構な強みだと思う
もっと良い方法見つけたいし、多分お金かければあるんだろうけど
月2000円以内くらいで多くのサービスを運用したいってなった場合に結局これ以外の選択肢ってなくない？
月1～2万円みたいな額はインフラエンジニア雇う費用に比べると全然安いんだろうけど、ポケットマネー基準だとそうもいかない
8年経ったので更に変えたこと、続けてること、やめたことを追記してみる。
→ウタマロで擦ったりするようになった。あと洗濯ボールを入れたら取り出す時に絡まなくなった
→しまむらで10足くらいまとめ買いしてる。なんとなくパンツも黒で統一するようになった。
・いつも起き抜けはなんか体の血の巡りが悪い気がするので朝入るようにする
→サウナ行くようになって血行よくなった。今は普通に夜入ってる
→朝の歯磨きは朝のリステリンになった。夜シャワりながら磨いてる。
(追加)
・仕事帰りに衝動的にサウナに行きたくなるので、仕事の鞄には常に下着類とタオルとトリートメントを用意しておくようになった。
・服装はユニクロとGU買ったジャケパンスタイルだけになった。1セットで1万円もしないのすごい。適当に着てもそれなりになるので服装考えることがなくなった。
・紙っぺらは全てとりあえずクリアファイルにいれとく。
・手のひらサイズの小物は全て箱の中にいれとく。
→使わなくなった。引越して収納増えたおかげもある。とりあえずポイポイ入れて無限に重ねておけるのはいいぞ
・とにかく床に物を置かない。床掃除できない。
→自在ほうきを買った。教室を掃除するやつ。掃き掃除が一瞬で終わる。
・部屋が広いなら四隅に一式ずつおいてもいいくらい
・焼くだけ、チンするだけ、茹でるだけ、封を開けるだけくらいにしとけ
→焼くのも茹でるのもしなくなった。かわりに液味噌と乾燥の具で味噌汁作るようになった。貝だしうめえ
→BASEBREADを食べるようになった。チョコが一番美味い。
・米もアマゾンでウーケを買え
→しない
・なので鍋はでかいのを買え
→捨てた
・行平鍋も便利だから買っとけ
→これだけ捨てずに持ってる
・皿洗いが面倒なら流水ですすいどけ。溜める前提のものをシンクに入れるな
→余裕があればパパッとティッシュで拭くようになった。油汚れはこっちの方が楽
・皿は大中小で３枚ずつ、お椀も大中で３つずつ買っとけ。重ねにくいのものは捨てろ
・スプーンや箸はどんなにたくさんあっても大して困らない
(追加)
・弁当作るのは意外と簡単だった。タッパーをえいやっと並べて、冷食の弁当用おかずをポイポイ投げ込むだけ。1週間分の昼飯が15分で完成。
・インスタントコーヒーとジャスミン茶のパックとと粉末のロイヤルミルクティーを常備するようになった。100均の使い捨てマドラーはいくら使っても減らない。ペットボトルのゴミが減った。
・お出掛け用バッグは大中小あったほうがいい
→最近は財布とスマホと鍵と小さく畳んでポケットに入るバッグしか持ち歩いてない。
・家賃が5000円安い所に引っ越すと、電気代を気にせずエアコンを使える
→家賃が2倍のとこに引越してしまった。部屋の広さ3倍。暖房費がやばい。
(追加)
・ゲームしないけどゲーミングマウス買った。ボタン割り当て便利。
・keyswapでF1を無効にしたらExcelのストレス減った
・人感センサー付きのスマートリモコン買った。ただいまの瞬間に電気がつく。既に部屋が暖かい。
・echo showでいつでも秒でカラオケ(カラじゃない)始められるのは神
・何を買いに来たのか忘れてもAlexaが全部覚えてくれてる
・数ヶ月前に決まったスケジュールもAlexaがちゃんと教えてくれる
少しずつ暖かくなってきたね。
春が終われば４歳になる。
「あぁ幸せな人生だったな、大勢からたくさん愛されたし、うふふ」と呟きながら死ぬか
世の中をクソ恨みながら、クリスマス・キャロルの妖精も現れず孤独に死ぬるのか。
ともかく息子の人生、子育ての結果が出るのは俺が死んだ後、８０年９０年後であり
知ったこっちゃない。
現時点では俺自身が、子供産んで（産んだのは妻だが）良かったな楽しいなと思えれば良いのではなかろうか。
文句ある？
そんなものに一喜一憂したくはないが、やはりどうしても嬉しく誇らしい気持ちは隠せない。
妻が外出する水曜夕方以降と土日の終日は俺と息子２人きりで過ごす。
コロナ在宅勤務であり子供が保育園から帰宅しても夏場はまだ日が高く、
息子を連れて公園に行く、運動不足解消にもなりちょうど良い。そんな３年間だった。
残業や土日は１．２５倍の割増になる。
そんな俺が一ヶ月で１５０時間を息子に費やしている
３年間で６７００万円
息子の寝顔を見ながら６７００万円を思い浮かべると嬉しくなる。
その可愛いほっぺに値札貼ってやろうかしら。
そんな６７００万円の愚息が１３，０００円のおもちゃをねだってきた。
いくら触るなと注意しても我慢ができずに弄くり回し壊して無くした鉄道模型Nゲージ
勝手に店内を歩き回り獲物を物色。
その緻密な再現性に魅了され心を鷲掴みにされた模様。
どうしても欲しいと駄々をこねる。
クソ生意気。
隣に飾ってあったD52はどうかと聞いたら、こっち（C62)じゃなきゃヤダと。
いやまぁどっちも買わんが
僕は子供だから仕事してお給料は貰えない、などと甘えた言い訳する。
キミにさっきセブンイレブンで買い与えたアンパンマンチョコがどのような社会背景で製造されているか
思い馳せたことはないのか、
経済大国日本のそこそこ所得のある家庭に産まれたアドバンテージに感謝しなさい。
笑顔で、どーしてもこれが欲しいんです助けて動画とか作ったらアホな視聴者が買ってくれるんじゃ無いか
英語話者のママに英語を教わり英語で配信すれば国内で叩かれる確率も低い。
とアドバイスしたが、乗り気ではないようだ。
不合理で不明瞭な駄々をこね続けるので６７００万円の説明をした。
これは親の努めとサーヴィスで無償提供に応じている。
それら含めればとっくに億を超えている。しらんけど
ともかくキミにはそれだけリソースを費やしている、これ以上なにを望むというのか。
父の愛で満足しなさいと。
キミは公園で無邪気にキャッキャ走り回っている、
それを当然の権利だと考えているようだが、安全はタダではない。
道路に飛び出さないように俺は一時も目を離さず監視していなければならない。
わかってんの？
これまで言われるがままに買い与えてきた。
甘すぎた点は反省しているが、
概ね要求が少額であり、中古プラレール（４００円）ごときで騙せた。
安上がりでええわぁ
ところが近年猛烈な速度で知恵をつけ、
アホですか
ボケですか？
何様ですかと言いたい。
上述、社会の仕組みと３年９ヶ月の投下コストを三歳児にわかるようにかいつまんで説明してやった。
まったく理解できないようで
とにかく欲しいと駄々をこねる。
愚息最後のカード、店内ギャン泣き大作戦を発動しそうな雰囲気の脅しの半泣き
面倒くせぇ
ふと棚を見るとEF62の中古車両が４４００円で陳列されていた。
CもEも似たようなものであろう。
もしかしてハメられた？
息子曰く、機関車だけでは可哀想だ、連結する台車のコキだのタンク車だの追加購入。
さらに貨物台車にはコンテナを乗せなければならないと主張する。
ダイソーが作れば１００円程度の模型ハリボテパーツが６００円する。
なんやかや１万円かかった。
最近息子が「カードでピッってすればいいじゃん」とふざけたことを言うので現金で支払った。
買ったばかりの貨物列車を走らせて満足顔。
なにかがおかしい。間違っている。
本日のサービス料８時間分と諸経費が加算され、今夜キミの寝顔は
６７，１１０，８００円
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
