  |
はてなキーワード: VMとは
そりゃそうなんだろうけども。そんなに？
追記：FESSをOSに直接インストールするのに参考にしたというよりコピペさせてもらったのは以下の記事
https://qiita.com/hyoshiaki/items/598127fe30b94bd82b6e
半年前に辞めてしまった前任者から存在すら知らされていない客先のメールアカウントが必要になった。
無いならないであきらめてもらえるんだが、僕は優しいのでファイルサーバに無いかくらいは確認しようと思ったが
なので昔うっすら使ったことのあるFESSで全文検索しよう、多分txtかxlsだろう。
とウェブサイトで構築方法を見ると今はDockerで動かすのが良いらしい。何がいいか知らんが。
ドキュメントに従いインストールし、なんとかクローリングまで実行できたが、重い。重すぎる。
サブフォルダ無しで100ファイルくらいのフォルダでも2，3日回しても終わってない。
CPU使用率が50%超えてるんだよ！ってログが出まくっている。そのログ出力無駄じゃない？
使えないかー、とググってみるとDockerではなく素で構築する方法を有志の方が書かれているのを発見。
それに従い構築。するとサブフォルダ5階層くらいのフォルダが3分くらいで終了。
ログにCPUがーっていうのも出てないわけではないが、明らかに少ない。なんだこれ。
Dockerは構築楽らしいしVMよりエコだっていうのは聞いたことあるんですが、
素のOSに入れるよりはどうしてもオーバーヘッドあるんですかね、というのが今回の教訓でありました。
今は楽しくやってます。
去年anond:20220514092559を書いた者ですが、この1年はウマ娘界で色々あったので振り返っておきます。
チームランクはUG5、競技場はクラス6です。もちろん月曜からは降級します。結局この1年間で一度もクラス6に残留できたことはないので壁は厚いですね……（過去最高は1,015,731点）
チャンミは一時期必ずAグループに進出できていたんですが最近は進出もままならなくなってきました。まあでも決勝進出を賭けて一喜一憂することはなくなったのでいいか……。こないだのアリエス杯でチャンミは終わりですが、最終的にカプリコーン杯・アクエリアス杯・ピスケス杯・ヴァルゴ杯でゴールド、アリエス杯・サジタリウス杯でゴールド☆です。プラチナって何それおいしいの？ 第2回サジタリウス杯は偶然チョコボンがすごく上振れした結果チャンミ史上初の5戦5勝を体験できました。俺有馬記念向け育成得意かもしれん……（第1回ジェミニ杯のときは長距離育成苦手だったんですが、今はむしろ長距離育成の方が得意で短距離は思うようにいかないですね……まあでもそれが普通でしょうか）
名鑑Lvは129。プレイアブルキャラのうち85人を解放しました（衣装違いはそれぞれ1人とカウント）。初回プレイは割とじっくりやるので逆に先延ばしになってしまって、まだツインターボと（デイリーレジェンドレースで入手したばかりの）ナリタブライアンの育成をやっていないので、育成済みは83人です。うち53人がUG以上（最高はメジロドーベルのUG8）、6人がSS+、15人がSS、9人がS+です。現シナリオによってインフレが加速しましたね……ちょっと前まで大成功だったSSが今や失敗作やぞ……
前回の増田では温泉に行けない仕様になったMNTについて愚痴りましたが、その後のグランドライブとグランドマスターズでは温泉に行けるようになっててよかったですね。ただグラマスはうまぴょい伝説が見れないので不満。あとグラライでの「GIRLS' LEGEND U」のライヴが良すぎたのでそれが見れないのは寂しい。っていうかグラライが色んな曲を聞けてお手軽にいろんなライヴを見れてすごい良かったので正直「ずっとグラライでいいのに……」って思ってました。初回プレイキャラは一度グラライでやってうまぴょい（＋GLU）を見てからグラマス、って流れですかね。
ただグラライにも欠点はあり、レース出走が育成の上で何のメリットにもならないので、たとえばキタサンブラックみたいな目標レースが多い娘の育成にはあんまり向いていなかったところ、グラマスはレース出走でも知識が貯まるのでそこは良いですね。逆にメイクラはレース偏重すぎて序盤に出れるレースが全然ないハルウララみたいな娘にとってはネックになっていたので、この2シナリオの良いとこ取りをしたのがグラマスという感じでしょうか。あとやる気管理がしやすいのでゴールドシチーの固有称号「百年に一人の美少女」を獲るハードルが下がってくれるのもありがたい。
そして散々文句を言ってきたメイクラですが、グラライでありがたみに気づきました。三冠制覇欲がめっちゃ薄れたんですよね。アオハル杯までは「なるべく三冠獲らせたいな～」って思って、クラシック三冠とか、それが無理そうなら春三冠とか秋三冠とか、多少スケジュールがキツくなっても何がしかの称号を獲らせてあげようとしていた（そして無駄なレースに出走して微妙な育成結果になることが多かった）わけですが、メイクラでクラシック三冠＋春秋マイル＋春三冠＋秋三冠＋エリ女VMみたいなイクノディクタス以上に過密なローテをこなしまくった（三冠ウマ娘兼スプリント王者キタサンブラックみたいな異常個体を作りまくった）ことで三冠制覇に飽きて「なんか別にもう三冠ウマ娘じゃなくてもいいか」みたいな感じになって、結果的にグラライ・グラマスでは合理的な育成をすることができたというか。メイクラを通ってなければここまで達観することはできなかったと思うのでメイクラには感謝ですわ。
この1年間で新しく引けたキャラのうち数名について印象を書くと、
こんな感じでしょうか。おひんばいいよね……
あとネオユニヴァースは引けてないんですけど、デムーロの「人間の言葉を喋れないのが欠点」という台詞から「意思疎通が難しい電波系不思議ちゃん」というキャラ造形にしたのは天才の所業だと思いました。なお某掲示板ではあまりにも一昔前の電波キャラ造形すぎて「電波、届いた？」とか「電気って、なめると味がするのかな」とか書き込むおじさんたちが大量発生しており「おっくれてるぅ―――――――――――――！！！！！！」と思いました（小並感）。
そういうわけで早くサトノクラウンを実装しやがれください。クラちゃん可愛すぎだろ俺の嫁確定ですわ。ぐへへ……ヒシミラクルちゃんとシュヴァルグランちゃんはおじさんとあっち行こうねえ……
これのおかげでタイキシャトルとビワハヤヒデとナリタブライアンを開放できましたありがとうございます。今はタマモクロス開放に向けコツコツやってるところです。
3ヶ月に1回くらいやってくれ（懇願）
顧客が本当に必要だったもの感ありますよね。賢さ☆☆短距離☆☆☆固有☆☆みたいな微妙な因子の水マルが賢さ☆☆☆短距離☆☆☆固有☆☆というレンタル用にちょうどいい感じの因子になったり、スピード☆☆マイル☆☆☆固有☆☆のセイウンスカイをスピード☆☆☆マイル☆☆☆固有☆☆にできたり、とにかく青☆9にならなかったからといって移籍させないでよかった感しかないです。もっと因子レポート持ってるだろジャンプしてみろよオラ。
イクイノックス推しなので去年の天皇賞（秋）はサイレンススズカの幻影と化した世界のパンサラッサ先輩を華麗に差し切る姿に痺れましたし、ドバイシーマクラシックでは差し馬のくせに先頭に立ちノーステッキ＆レコードで逃げ切る姿に衝撃を受けました。マルゼンスキーかな？ 実況見ててお口あんぐりだったというか。勝つだろうとは思ってたけどあんな勝ち方するとはまさか思わないじゃないですか？ そして皐月賞のソールオリエンスもヤバすぎ。直線が短い中山でナリタタイシンより後方から差し切ったとかどんだけだよ。桜花賞のリバティアイランドの差し切り見てすげえ三冠牝馬確定じゃんと思っていたら皐月賞はもっとすごかったという（つくづくドゥラメンテの早逝が惜しまれる……）。やっぱディープインパクトの後継争いは今んとこキタサンブラックが筆頭でしょうか。あとはコントレイル産駒がどれだけ走るのかですよねえ……
そしてメイケイエール……彼女がGIに出る度に高揚と落胆を味わっている……桜花賞からずっと応援してきていて、間違いなく実力はあるのですがGIで勝ちきれない。俺キングヘイロー推してた人たちの気持ちわかってきたわ……。なので今度のヴィクトリアマイル参戦は朗報ですね。とにかく向いてない短距離を走らせてたらGI獲れずに終わるので、どうせ制御できないなら適性に合った距離を走ってもらった方がまだGI勝利の目はあると思います。俺はエールちゃんの秋古馬三冠の可能性を信じてるからな（ガンギマリ）（ikzeの腕ちぎれちゃう）（ソングラインとの鞍上かぶり問題のときにソングとエールで大岡裁きしろって意見があって笑った。大岡裁きは車裂きの刑ちゃうぞ！）
あんま関係ないと思う、国問わず大企業本体は基本的には幹部候補しか採らんで
まぁ米国は大企業の本体でも給与やっすいポジションがあるから、そこで実務経験者とることも米国ならあるの・・・か？
でもまぁ基本的には、下記みたいな感じだと思うで
何歳からのチャレンジも遅く無いの増田(https://anond.hatelabo.jp/20200804222320#)で引用したblogの人は
米日立でめっちゃ社歴が長かったシニア・マネージャーだったみたいだぞ
その経験を持ってなお手を動かせれば何か職はあるかなぁが現実よ
💻 56歳のプログラミング初心者 💻 としての自分を完全に受け容れられるようになる前の私は、
クリティカル・インナー・セルフ（内なる自分）と上手く付き合わなければならなかった 🙄
内なる自分：なんでこの年でプログラミングの勉強を始めたんだい？
わたし ：本当に言いたいのは、あとどれくらい生きられるのか？
そして、プログラミングで稼げるだけの時間が本当に残っているのか、だろ？
わたしはアメリカ人だから平均寿命は 78.8 歳だ。とするとまだ 22.8 年生きる可能性が高い。
20歳の人間からするとそんなに長いとは思えないだろうけど、わたしは56歳でストリートで踊れるくらい元気だ。
内なる自分：すべてのテック企業は大学を出たてのガキを雇いたがるものじゃないの？
わたし ：それは大した問題じゃないな。わたしはシリコンバレーに住みたくもないし、巨大なテック企業で働くつもりもないから。
内なる自分：今やってること全てが時間の無駄ではないと言い切れる？
わたし ：本当はこう聞きたいんだろう？
「もしプログラミングを学んだ後でフルタイムの給料をもらえなかったらどうするつもりなのか？」と。
わたしの答えはこうだ。
「だから何だ？」
ーーーーーーーーーー
【原文】[Next Avenue] VM Vaughn - 56 and Learning to Code
https://www.nextavenue.org/learning-code-56/
【日本語訳】[Medium] 56歳からコードを書き始めて食べていく方法
「やめとけ」と叫び続ける内なる自分とひたすら言い争ってみました
https://medium.com/japan/i-am-learning-to-code-at56-37054b5dc8ce
今の40代オタクがボクの師匠、プログラムもCGもDTMも師匠のおかげを書いた増田です。
お前が技術を中心に情報補完しろよと言われたので知っている範囲で情報を補完します。
ただやっぱりネタバレするとゲッサン編集部や作者氏から叱られそうなので、まったく本編には影響しないであろう部分を中心に情報補完させて貰います。
先に謝っておきますがネタバレ回避を考えたら第1話で語れる部分がココしかなかったっす・・・。
主人公の和田一馬が所持するガラケーはデザインに微妙な違いがあるけれど、おそらくはau W41CAで2006年の春モデル。
W41CAはペンギンケータイとも呼ばれたCASIOのヒット機種で、外観はCASIOらしく少々無骨、旧機種のW31CAでは赤外線通信やおサイフケータイへ非対応だったものの、W41CAでは対応を果たし全部入りケータイになった。
ペンギンケータイの由来ともなるマスコットキャラクターのアデリーペンギンが画面上の様々な部分で演出として登場し、ポップなオレンジの筐体色とも合わせてその可愛らしさから人気を博した。
W41CAは無骨さの中にある可愛らしさで人気となったが、CASIOのWn1CAシリーズは本来サラリーマンに高い評価を受けていた端末で、WordファイルやExcelファイルを閲覧できるPCドキュメントビューワーやPC向けWebページを閲覧できるいわゆるフルブラウザを搭載しつつ、USBマスストレージ接続が可能な端末であり、更にはFMラジオを受信できるなど当時のギークからも非常に高い評価を得ており、CASIOガラケーの銘機としてガジェット界隈では歴史に刻まれている。
当時を知る者であれば常識的な話だが、CASIOというか当時のauは学生へ対して強く訴求する携帯電話通信キャリアで「学割と言えばau」という認識が世間でなされており、auや携帯電話へ搭載する機能や展開するサービスも学生を意識したものが多かった。
取り上げているW41CAも着メロの最大発音数は128のステレオ再生、PCM音源の再生機能である着うた(AAC/48Kbps)にも対応していた。しかもSD Audio Playerを搭載しておりminiSD(microSDではない)にUSBマスストレージ経由で保存したAAC(96Kbps)の再生が可能であった。
ちなみにヒロイン(？)が使っている携帯電話は現在でもINFOBARを生み出したとして話題となるau design projectの第3弾端末であるau talby。2004年冬モデルで製造は三洋、型番がA5508SA。デザイン以外に語る部分がぶっちゃけない。
というか当時からハードウェアスペックに関して語られることがあまり無かった機種で、掲示板などで携帯電話のスペックを誇ったり最大限に活用するための情報交換などをするギークなユーザが選ぶ機種ではなかったので殆ど知らないというのが実情。
INFOBARは目新しさもあって結構いろいろ情報交換されたものだけれど第3弾ともなると正直言って失速気味になっていた。
ただ、主人公が最新の携帯電話でヒロインが型落ちのデザイン重視な携帯電話、学生なのでauという細かな描写は作者の意気込みを感じる。
個人的にはこの時期の携帯電話を挙げるならauではなくVodaphoneとNTT DoCoMoから発売されていたNokia 6630を推したく、これがまたSymbian S60で・・・と話が逸れるので別の機会に。
W41CAに搭載されている音源はYAMAHA AudioEngine MA-7i(YMU791)で、前述の通りFM音源の最大発音数は128でステレオ再生が可能であり、AACやMP3のデコードへ対応するなど非常に多機能で多くの携帯電話端末に採用されることとなる2005年に登場した最新LSIによる音源だが、W41CAでは何故かMP3デコードなど一部機能が制限されている。
着メロ形式はSMAF(MMF)で150Kbyte(153,600byte)まで、FM音源の使い勝手としては4オペレータの最大発音数128で、更にFM音源側の最大発音数を減らすことで最大16bit/12,000HzのPCM音源データを使うことが出来、同様にFM音源側の最大発音数を減らすことで着うた登場前後に一瞬だけ流行ったボーカル付き着メロで活用されたHV(合成音声)も使える。
エフェクターなども内蔵しておりMA-7シリーズは当時の着メロ職人からはかなり評価の高い音源であったものの、NTT DoCoMoしか注目しなかった頭内定位を利用した仮想サラウンド再生のための3Dポジショニング機能も実装されており、いつの世も空間に対するオーディオというのは経営者と技術者の心を掴んでしまうんだなと林檎マークを見て思いを馳せる。
ただ人気だったW41CAにも欠点はあり、当時のケータイアプリ開発者から悪名を欲しいままにしたezアプリ、つまりBREWアプリが採用されていた。当時のauは野良アプリ(勝手アプリ)開発者を締め出すことへセキュリティの都合上から躍起となっており、公式ez web以外の経路からのアプリインストールを著しく制限していた。
この制限が無くなるのは平成ヲタク リメンバーズの時間軸で言えばほんの先の未来である2007年に登場するオープンアプリプレーヤー(OAP)を待つ必要があり、W41CAは、というかau端末はその点からギークに毛嫌いされることがよくあった。
BREWアプリの欠点はそれだけでなく、これはBREWアプリよりも前のezplusアプリ時代からそうなのだが1日のアプリ内携帯電話パケット通信3MB制限という謎の縛り(後に6MBまで上限緩和)が設けられておりユーザとケータイアプリ開発者双方からヘイトを買う一因となっていた。ちなみに他社は1度のパケット通信量の上限はあったが1日の上限は無い。
いやそもそもQualcommからカフェインよりもアルコールだよと騙され酔っぱらいJAVAからBREWへ乗り換えたこと自体が愚かで、他社はJAVAのままなので単に開発負担が増え、auで公開されるケータイアプリが減るという結果しか生まなかった。これが解消されるのが前述したOAPであり、OAPの正体はBREW上に構築されたJAVA VM環境であった。
しかしこのOAPもBREW側のセキュリティパーミッションのせいでパケット通信するたびに通信を許可するためのダイアログが表示されるなど不便極まりない仕様であったためユーザの反感を買ってしまう。
マニアックなネタばかり詰め込んでもアレなので、平成ヲタク リメンバーズの本編に影響しないよな？とビクビクしながら選んだのが当時流行っていた携帯電話を活用した位置ゲームのコロニーな生活。当初はウィルコム端末向けだったが後に他の携帯電話通信事業者にも対応し、2005年にコロニーな生活☆PLUSとして改称アップデートされた。
このコロニーな生活☆PLUSはブラウザゲームの一種でコロニーな生活☆PLUSのURLへアクセスするだけでゲームへ参加できた。1km以上の直線移動距離を稼いでゲーム内通貨を貯め、自分の土地の施設を充実させ住民人口を増やしていくというゲーム。
当時を知っている人ならばオチが直ぐにわかっていると思うので間を置かず言ってしまうと、コロニーな生活☆PLUSの略称はコロプラ、現在では白猫プロジェクトやディズニーツムツムの開発元で知られる株式会社コロプラの祖業である。ちなみに今でも一応はスマートフォンアプリでサービス継続しており名称も「コロプラ」へ改称している。
平成ヲタク リメンバーズの世界の時間軸にプレイヤーは存在するだろうけれど今後ネタ被りしたら申し訳ない。
ネタバレ回避も必要だし始まったばかりの第1話でとやかく言えることはないですね。読者の興味を惹こうとする単語が現れたりするので走り出しとしては及第点なんじゃないかなと。
むしろ前述したように登場するガジェットをしっかりと時代に合わせたものにしていたりとセリフやキャラクターだけでなく登場する小物にも注目したほうが楽しめるのかも知れないというのが第1話への感想と今後への期待です。
作者氏は同年代だと思われるので、敵に回すと恐ろしいが味方につけると頼りないと言われるVIPクオリティを発揮してくれたらなと楽しみにしてます。うはｗｗｗおｋｗｗｗｗｗ
全体的に、線で結ばれているものが親子関係なのか包含関係なのかただ近い領域のものなのか曖昧なので意味のあるグラフというよりはキーワードを適当に散りばめて近い領域にあるものを線で結んだお気持ちマップに見える
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
仮にこの記事にブコメがついたとしたら、やっぱり投機投機書かれるだろう。
そういう人はこの記事の対象ではないので無視して良い。はてなコミュニティの老化は見てて悲しいね。
これは明らか。今ではない。
いま、米国債の利回りとステーブルコイン運用の利回りを比較したときに、前者のほうが高いからである。
FOMCの政策金利は4.5%で、ステーブルコイン運用は安定を取るとせいぜい5-10%程度である。一見後者のほうが良いようにも思えるが、前者はリスクを取らんでいいのでお話にならないほど差がある。
結果、いまスマコン上で発行されたステーブルコインの償還が止まらない。市場がシュリンクしていく過程にある。新規流入がなければBTCの新規マイニング分が吸収できないので、価格はだんだんと維持できなくなり、いつか暴落を始める。
半減期後、新規が細ってBTCが暴落を起こすのは毎回引き起こされている現象ではある。今回は特にマクロが悪いので、いつもよりもっと悪いことになる可能性が高い。
2022年は酷い年だった。2023年には期待したいところだが、残念ながら、特に前半はまだこの道半ばにいる可能性が高く、強気でいられる理由がない。
話を戻そう。米金利。ターミナルレートに到達してから利下げ開始までは結構な時間がかかると見られている。
景気は悪化していく可能性が高い。いまは株価が景気悪化を折り込み始めたタイミングである。
あと何周かするとテーマが景気悪化から利下げに戻ってくるので、実際にそのような発言・観測が出てきたとき買い始めるのが良さそうだ。
ただ、「いつ利下げを折り込み始めるのか」「折り込み始めたタイミングの価格帯が今よりも下なのか」は誰にもわからない。
下落相場のなかにあっても、短期的な反発は必ず起きる。今の価格が底で、Pivotのタイミングではもっと上の価格帯である可能性もある。が、慌てて買わずに、時期を待つことをオススメする。無意味なリスクを取る理由がない。
もし、マクロを見ずに買い始めたいのなら、「BTCが前日比10%以上値を下げた」日から分散購入しよう。
一年に数回は発生する珍現象で、タイミングとしてはおそらく望ましい。
この分野もだいぶ勝者が絞られてきた。具体的にはatom, matic, avaxが候補である。
Solanaは残念ながら脱落した。
atomは将来性があるが、難しい。atomの価値＝cosmos sdkの価値ではないからだ。
maticはzk(e)vmの展開次第では化ける。
avaxは上記二者と比べると差別化に苦労しているように見える。
オラクル系も差別化されていて、勝利者であるchainlinkは可能性があるように思える。
一応候補としては挙げたが、これらがBTC/ETHを安定的にアウトパフォームすることは難しい。
Solanaの劇的な死をいったい誰が予測できたといえるだろうか。そしていままでの価格推移がそれを証明している。需給でイーサに勝つのもなかなか難しい。
BTCは自分のウォレットにうつしてガチホする以外に選択肢がない。WBTCはやめておけ。
ETHはどこかのサービスでステークしよう。現状stETHが安牌である。
こういう愉快な連中が、表向きニコニコしながら内心敵視しあっているのが現状のクリプト業界である。といいつつも前進はしている。どれかに張るならBTCかETHが良い。
それは増田では？というかエアプやろ？キラキラWEB系とか言ってる時点で情弱商法に騙されそう
Radius も Active Directory も無い世界線どころか、DHCPサーバ側でMACアドレスとIPアドレスの組み合わせを予約しておくことすらできない世界線の増田
最近でも Azure AD なんか導入している企業ないマン、Microsoft365 や Google Workspace は存在しない＋それらと連携させるセキュリティプロダクトは存在しないマン、
AWS や VM や Dockerが存在しない世界線マン、AWS で起動テンプレートを作らないインスタンスを複製しないマン、Debianと契約するマン、
Linus Torvalds を知らないマン、資産管理の意味が理解できないマン、フリーデスクの基本的な運用を知らないマン、基幹システムにアクセスしないマン、
Teamsなどのコミュニケーションツールが存在しない世界線マン、今時は Teams などのコラボレーションプラットフォームに内線を統一する流れなのに
一昔前の BYOD で個人の携帯にアプリで内線を割り当てるどころか固定電話を廃止して携帯定額通話でドヤ顔マン、ユニコーン企業で働いてる設定なのにお局云々マン、
AWSで年収1000万余裕マン＋AWSについての歴史改変マン、既存の不正検知AIプラットフォームは使用せず依頼を受けてサイゲ参考に不正検出システムを作ったマン、
Pythonは仕事は無いマン、デスクをデコるマン、リモートワークできないマン、Macドヤ顔マン・・・・・ほか、上げたらキリがない
Radius も Active Directory も無い世界線どころか、DHCPサーバ側でMACアドレスとIPアドレスの組み合わせを予約しておくことすらできない世界線の増田
最近でも Azure AD なんか導入している企業ないマン、Microsoft365 や Google Workspace は存在しない＋それらと連携させるセキュリティプロダクトは存在しないマン、
AWS や VM や Dockerが存在しない世界線マン、AWS で起動テンプレートを作らないインスタンスを複製しないマン、Debianと契約するマン、
Linus Torvalds を知らないマン、資産管理の意味が理解できないマン、フリーデスクの基本的な運用を知らないマン、基幹システムにアクセスしないマン、
Teamsなどのコミュニケーションツールが存在しない世界線マン、今時は Teams などのコラボレーションプラットフォームに内線を統一する流れなのに
一昔前の BYOD で個人の携帯にアプリで内線を割り当てるどころか固定電話を廃止して携帯定額通話でドヤ顔マン、ユニコーン企業で働いてる設定なのにお局云々マン、
AWSで年収1000万余裕マン＋AWSについての歴史改変マン、既存の不正検知AIプラットフォームは使用せず依頼を受けてサイゲ参考に不正検出システムを作ったマン、
ワイも増田も
MMMO (M 無教養で M 無能で M 無収入な O オタク) か
MMMM (M 無教養で M 無能で M 無収入な M マン) で
年がら年中、就職できないとかやってるし、ひどいお仕事増田見るからな
Radius も Active Directory も無い世界線どころか、DHCPサーバ側でMACアドレスとIPアドレスの組み合わせを予約しておくことすらできない世界線の増田
最近でも Azure AD なんか導入している企業ないマン、Microsoft365 や Google Workspace は存在しない＋それらと連携させるセキュリティプロダクトは存在しないマン、
AWS や VM や Dockerが存在しない世界線マン、AWS で起動テンプレートを作らないインスタンスを複製しないマン、Debianと契約するマン、
Linus Torvalds を知らないマン、資産管理の意味が理解できないマン、フリーデスクの基本的な運用を知らないマン、基幹システムにアクセスしないマン、
Teamsなどのコミュニケーションツールが存在しない世界線マン、今時は Teams などのコラボレーションプラットフォームに内線を統一する流れなのに
一昔前の BYOD で個人の携帯にアプリで内線を割り当てるどころか固定電話を廃止して携帯定額通話でドヤ顔マン、ユニコーン企業で働いてる設定なのにお局云々マン、
AWSで年収1000万余裕マン＋AWSについての歴史改変マン、既存の不正検知AIプラットフォームは使用せず依頼を受けてサイゲ参考に不正検出システムを作ったマン、
ほいノ
高専行こうと思えば行けたんだけど、実家離れるの怖くて偏差値45の工業高校へ。
18歳までフリーター。
18歳〜21歳まで定時制に通った。
英語は個人的にそこそこ勉強したけど、数学なんかはⅠの後のAが半分も終わらなかったレベルのバカ校。
この時期は暇で、なぜかやる気に満ち溢れてたから、TOEIC700近くとか日商簿記2級とか色々資格を取った。
24歳でうつになって、30歳くらいまで日雇い・派遣↔無職を半々くらいでリピートしてた。
やってる仕事は大したことなかったけど、幸い仕事中にPCをめちゃくちゃ使うのでやりたい放題だった。
この時にプログラミングを始めた。
ここで年収どんどん上がった。
36歳でうつが再発して辞めて今に至る。
基本は、仕事で使えそうなもの・必要なものをその都度吸収していった感じ。
Webが中心ではあるけど、組み込みとかのハードが絡む分野以外は結果的に広く浅く手を出してる、つもり。
| Excel VBA | 1年 |
| VB.NET | 半年 |
| JavaScript（Node.js） | 4年 |
| HTML | 1年 |
| SQL | 4年 |
| GAS | 3年 |
| C# | 1年半 |
| TypeScript | 2年 |
| Java | 半年 |
| C++ | 半年 |
| ラダー、FB（三菱、シーメンス） | 1年 |
実務経験があるって胸張って言えるのはこれくらい。
大体習得順。
他には、Python、Julia、R、Fortran、Rust、Go、Dart、Shell、Deno、CSSなんかは少しずつかじってる。
最近はWebに関してはほとんどJS（TS）で済む感じになったので楽。
なんでPLCが最後やねんってツッコミは置いといて、Web系寄りでラダーも触ってるって人は観測範囲ではあんまりいないので、それが俺の数少ない強み。
RDBはPostgreSQL、SQL Server、MySQL、SQLiteの順で実務経験あり。
NoSQLはFirestoreが実務経験あり、実務なしだとNeo4jとか。
PaaSはGCP（Firebase）、AWSの順で実務経験あり。AzureはADとVM周りをちょっと触った程度。
Dockerはよく使うけどKubernetesとかまでは行ってない。
後は産業用の通信プロトコル的なやつを無駄に色々触ってる。Modbus TCPとかORiNとかCC-Linkとか。PLCもそうだけど、あの辺は日本とドイツとアメリカが未だに既得権益で幅利かせててまじで闇深い。その代わりそれをブレイクスルーできればめっちゃ稼げる分野だと思う。
閑話休題。
フリーターでどんな仕事してるか知らないけど、仕事で一日の半分が無くなっちゃうじゃん？
以下、俺の場合ね。
次長クラスの人が「この製造番号でクレームがあったんだけど、作業当時どんなことあったか覚えてない？」みたいなことをわざわざ現場まで何度も聞きに来るんだよ。
作業したのなんて半年前だったりするから一々覚えてないっすよ、って言ってるのに何度も聞きに来るから、イラッとして仕事用のPCで勝手にExcelで業務日報を付けるようにして、イントラのファイルサーバーに置いて「そういう時はこれ見て下さい。次長の貴重な時間が勿体ないです」って言ったのよ。
それだけでめちゃくちゃ喜ばれる。
で、今度はその次長が「この製造番号どれくらいの時間で作業終わった？」みたいなことを現場までわざわざ何度も聞きに来るから、俺はその時またイラッとして、Excelでストップウォッチもどき作って製造番号とか工程ごとに時間計測して記録して、やっぱりファイルサーバーに置いて「これ見て下さい」って言ったのよ。
それでまた、めちゃくちゃ喜ばれる。
最初はプライベートな時間も結構使ってやってたんだけど、そういう周りに喜ばれる効率化を繰り返してると、少しずつ業務時間内で自分のスキルアップに直結する時間を作れるようになる。
自分でこれ面倒くせーな、効率よくできねえかなって思ったら、じゃあどうやって？てのを考える。
ちなみにPCがなくても、たとえばメールアドレスさえあれば今の時代カイゼンはできる。
大きな会社に勤めてるとかだと使うのが難しいんだけど、IFTTTとかが良い例かな。
これはiPaaSっていうサービスの一種で、まあ言葉の意味は覚えなくて良いんだけど、要は「イベントAが発生したら別のイベントBを起こせ」っていうのを登録して、自動化できるWebサービス。
例えば、あなたが日雇いの会社にいて、毎日違う現場に働きに行くとする。
で、出勤前、現場到着時、勤務終了の時にLINEで毎日報告しなきゃいけないとする。
で、その報告を受けた事務方は、Googleスプレッドシートにその都度入力する。つまり、それだけの為の事務員が一人いる。
面倒くさいし、お金がかかる。
そこで、「特定のグループでLINEを受信したら（イベントA）、特定のGoogleスプレッドシートに情報を記録せよ（イベントB）」っていうのをIFTTTに登録すると、少なくとも事務員の入力の手間は省けるってえ寸法だ。
IFTTTはたくさんイベントを処理させたい場合は有料になっちゃうけど、個人で試すぶんにはクレカ登録しなきゃいいだけだから試してみるといいよ。
月1000円で学べる。コスパは圧倒的。
入門コース（学習に180時間と公称してる）がしっかり理解できていれば、Webで大抵のものは作れる。
ただし、大筋は問題ないんだけど、細かい部分で最新技術をキャッチアップできてない可能性があるので、そこは注意した方が良いかも。
https://www.nnn.ed.nico/pages/programming/
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。
そしたら、職歴書の作り方次第で中小企業の社内SEにはまず転職できる。
中小企業の社内SEは、ITリテラシーの低い社員が多い中で「Excelのセルの色が変わらなくなっちゃったんだけど！」とか「複合機が紙詰まりって言ってるけどその紙が見つからない！」とかクソイージーなクエストをこなすだけでおちんぎんが貰える、人によっては天国、人によっては地獄のような職業だ。
ごめん、流石に言い過ぎた。実情は色々と面倒くさい。DXとかバズワードを聞きかじったクソ重役から突然言い渡される重めのミッションとか。
けど安定なのは間違いない。
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。ここは社内SEと同じ。
生産技術ってのは、誤解を恐れずにすげえ簡単に言えば、カイゼンばっかりやってる人たちのことだ。
あんまり詳しくは言えないんだけど、俺が最後にやっていた仕事は言わば生産技術だった。
で、中小企業の生産技術は、Webに強い人材をかなり欲しがっている。有り体に言うとIoTとかね。
IoTは最近、セキュリティの強化がかなりクローズアップされていて、そのせいで二の足を踏んでる企業が多い。
そこに滑り込むのはアリだと思う。
よく「T型人材」って言われ方をするけど、どっちのスペシャリストの言うこともある程度分かる「橋渡し」的な人材になると途端に貴重になって需要が増すので、上昇志向があるなら「Web+何か」の組み合わせでお金稼ぐのが良いんじゃないかな。
ま、橋渡しって自然とプロマネとか任されがちで、裁量大きくて大変なんだけどね。
質問あればどうぞ。頑張って。
難しいことは言ってないのぜ😥
たとえば、
年がら年中、ITを始めるのは遅すぎるか？とか増田でやってるので書いた
何歳からのチャレンジも遅く無いの増田(https://anond.hatelabo.jp/20200804222320#)で引用したblogの人は
米日立でめっちゃ社歴が長かったシニア・マネージャーだったみたいだぞ
その経験を持ってなお手を動かせれば何か職はあるかなぁが現実よ
💻 56歳のプログラミング初心者 💻 としての自分を完全に受け容れられるようになる前の私は、
クリティカル・インナー・セルフ（内なる自分）と上手く付き合わなければならなかった 🙄
内なる自分：なんでこの年でプログラミングの勉強を始めたんだい？
わたし ：本当に言いたいのは、あとどれくらい生きられるのか？
そして、プログラミングで稼げるだけの時間が本当に残っているのか、だろ？
わたしはアメリカ人だから平均寿命は 78.8 歳だ。とするとまだ 22.8 年生きる可能性が高い。
20歳の人間からするとそんなに長いとは思えないだろうけど、わたしは56歳でストリートで踊れるくらい元気だ。
内なる自分：すべてのテック企業は大学を出たてのガキを雇いたがるものじゃないの？
わたし ：それは大した問題じゃないな。わたしはシリコンバレーに住みたくもないし、巨大なテック企業で働くつもりもないから。
内なる自分：今やってること全てが時間の無駄ではないと言い切れる？
わたし ：本当はこう聞きたいんだろう？
「もしプログラミングを学んだ後でフルタイムの給料をもらえなかったらどうするつもりなのか？」と。
わたしの答えはこうだ。
「だから何だ？」
ーーーーーーーーーー
【原文】[Next Avenue] VM Vaughn - 56 and Learning to Code
https://www.nextavenue.org/learning-code-56/
【日本語訳】[Medium] 56歳からコードを書き始めて食べていく方法
「やめとけ」と叫び続ける内なる自分とひたすら言い争ってみました
https://medium.com/japan/i-am-learning-to-code-at56-37054b5dc8ce
将来のことは知らん
とりあえずいまリーマンとしてIT未経験でもそこそこの給与欲しいについては別増田(https://anond.hatelabo.jp/20220625194240#)に書きました
インフラやっとこう
ワイの一番古い増田はDHCP理解してないマン宛のトラバやったで
2018-08-14 anond:20180814213814
Radius も Active Directory も無い世界線どころか、DHCPサーバ側でMACアドレスとIPアドレスの組み合わせを予約しておくことすらできない世界線の増田
最近でも Azure AD なんか導入している企業ないマン、Microsoft365 や Google Workspace は存在しない＋それらと連携させるセキュリティプロダクトは存在しないマン、
AWS や VM や Dockerが存在しない世界線マン、AWS で起動テンプレートを作らないインスタンスを複製しないマン、Debianと契約するマン、
Linus Torvalds を知らないマン、資産管理の意味が理解できないマン、フリーデスクの基本的な運用を知らないマン、基幹システムにアクセスしないマン、
Teamsなどのコミュニケーションツールが存在しない世界線マン、今時は Teams などのコラボレーションプラットフォームに内線を統一する流れなのに
一昔前の BYOD で個人の携帯にアプリで内線を割り当てるどころか固定電話を廃止して携帯定額通話でドヤ顔マン、ユニコーン企業で働いてる設定なのにお局云々マン、
AWSで年収1000万余裕マン＋AWSについての歴史改変マン、既存の不正検知AIプラットフォームは使用せず依頼を受けてサイゲ参考に不正検出システムを作ったマン、
Pythonは仕事は無いマン・・・・・ほか、上げたらキリがないんだわ
とりあえず、時が止まり過ぎ＋IT業界に妙な憧れがあることだけは伝わる
因みになんだがこれやってるのすべて同じ増田なんじゃ無いか？って思ってるよ。文字が文字通り読めない増田
もちろん、だからといって、増田に書き込んじゃダメってことは一切ない。今まで通り好きなこと書いたらいい
その自覚さえあれば、在りし日のVIPがみんなニートという体だったのと同じく、
ワイも増田も
MMMO (M 無教養で M 無能で M 無収入な O オタク) か
契約してる1つのサーバで個人ブログとか昔ながらのBBSとかブラウザゲームとか種類が違うサービスをいくつも運営しているけど、サーバの運用方法が流石にレガシーすぎるからもうちょっとモダンな感じにしたいと思ってる。
でも中々抜け出せない。
まず前提としてAWS,GCP,Azureは高いから使えない、同スペックなら適当なVPSの方が圧倒的に安い。
最近流行りのコンテナ構成みたいなのもいくらDockerが昔のVMに比べるとリソース食わないと言っても例えば
「1つのサーバで10個のサービスを相乗りで運営しなければならない」みたいな場合に1サーバ内で何十コンテナ起動みたいなの運用すると流石に相当重くなっちゃうよなぁ。。。
あとnode.jsとかginみたいに1サービスごとに常駐プロセスが増える技術スタックも多分あんまりよくない、必要ポートを管理するのも大変
結局自然と行き着くのは格安VPS借りてLAMP構成作ってVirtualHostで相乗り設定して昔ながらの方法で運用する方法になっちゃう
php+apacheの構成ならアクセスの少ないサービスを何十個運用しようとアクセスがないならそれにリソース食われることがないんだよね、何気にLAMP環境の結構な強みだと思う
もっと良い方法見つけたいし、多分お金かければあるんだろうけど
月2000円以内くらいで多くのサービスを運用したいってなった場合に結局これ以外の選択肢ってなくない？
月1～2万円みたいな額はインフラエンジニア雇う費用に比べると全然安いんだろうけど、ポケットマネー基準だとそうもいかない
まあ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の活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に
といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな～。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。
Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。
ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ
といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。
macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。
macOSは直接にはMachから派生したもので、BSDではありません。ただし
など、BSDと誤解させる点があるのは確かです。
上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。
しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く
