はてなキーワード: インタフェースとは
class Hoge(Foo) { // ... }
なんてことは論理的にあり得ない。
HogeをFooとみなすかどうかは、一般的に文脈によるからだ。
だから、Hogeの定義にFooのサブタイプであることが課せられるのはおかしい。
ましてや、Fooの実装がinheritされるのは尚更おかしい。
例をあげよう。
しかし、カーテンを家具の一種だとみなすか、布製品の一種だとみなすかは、文脈による。
だから、カーテンの定義にそれが家具であるとか布製品であるとかいう条件が課されるのはおかしい。
また、インタフェースの実装もおかしい。(たとえそれがクラス定義とインタフェース実装が分離された場合、いわゆるProtocolというパターン、であっても)
AがBであるとき、AをBとみなす方法は一般的には複数あり、どの方法によるかは文脈によるからだ。
たとえば、裏返して着られるパーカーのクラスにWearableインタフェースを実装しようとしたら、どちら向きをwear()メソッドに実装するか定まらない。
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか?同じものを表すのに関数ごとに別の変数名を付けているとか?
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか?
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
無能のワイが教えてやろう
だから、与えられた仕事や指示の欠陥を「ここきめなあかんやろ……」みたいなところを、サッと見つけて、適切な質問ができるわけや。
せやから全部おっけーとするんや。
質問して欲しかったら、それに対する解像度あげてもらうしかないんちゃう?
すると最初優しく質問答えててくれた人も、どんどん無能に対して厳しくなるわけや。
すると無能はどんどん萎縮するわけや。
有能な君が無能ちゃんに対して、厳しくしてるかしてないかは関係ない。
無能ちゃんに質問してもらいたかったら、質問しても怒らへんで〜っていう経験をたくさん積ませたれ。
でもまあ有能様の貴重な時間を無能の介護に使うのは時間の無駄遣いやな
とはいえ、たくさんの人を使って何かを成し遂げようとしたら、必ず無能は混じるもんや。
自分の周りは有能だけにして、それをインタフェースにして無能を使うのがミクロ的な問題解決かもしれんな。
もし有能な君が、周りの無能ちゃんにストレスを抱えてるんやったら、自分が無能ちゃんになるのも良い選択肢やな。
---
gkmond これの難所は脳が優しく教えてもらった10に怒られた1でも怒られた記憶の方が強烈に残る仕様になってるとこだよなあ。
ほんまやなぁ。まあ、恐怖は生死に直結するから忌避されてるんやろうね。
翻訳してくれてありがとう。ワイが言いたかったことの一つやな。
ROYGB トラックバックでも書いてあるけど、こちらから説明したあとに、相手に内容の説明をしてもらうと理解度がわかる。具体的な作業内容を聞いてもいい。
これいいやり方に思えるやん。
実際意味を解する有能にとっては、咀嚼してるか判断できるええやり方なんやろな…
たとえば、100万件のデータをソートするとか、その中から条件を満たす最適な組み合わせを高速に求めることは、計算機科学的に価値があります。
しかし、画面上のオブジェクトの表示位置や色を変えることは、コンピュータにとっては何の意味もありません。
もちろん、オブジェクトを描画するためのドライバや汎用的なエンジンを作ることには、一定の価値があるでしょう。
しかし、それらを用いて位置や色を指定するのは、単にそのプログラムの設定パラメータを弄っているだけであり、プログラミングではありません。
これはたとえば、.gitignoreやdocker-compose.ymlを書くことを「プログラミング」とはふつう言わないようなものです。
最近コンピューターサイエンスがプログラマーに必要か否かみたいな話が上がっているが、そもそもコンピューターサイエンスって何だよ。どこまでの範囲をさしてんの?
ググって出てきた情報を整理しただけなので詳しい人、補足・訂正よろしく!
https://www.acm.org/binaries/content/assets/education/cs2013_web_final.pdf
CS2013はACM/IEEE-CSによるカリキュラム標準。
ACM(計算機協会)はコンピュータ分野全般の国際学会、IEEE-CSはIEEE(米国電気電子学会)の中にあるテクニカルソサエティ。
https://www.ipsj.or.jp/12kyoiku/J07/20090407/J07_Report-200902/4/J07-CS_report-20090120.pdf
J07-CSは一般社団法人情報処理学会がCC2001CSをベースにアレンジを加えたカリキュラム標準。今はCS2013を反映したJ17-CSがあるらしいけどその辺は良く分からん。
https://www.ipa.go.jp/files/000024060.pdf
J07ーCSから抜粋。CS2013と比較するとナレッジエリアがあったり無かったり。
ロジックプロセス2nmを国産するということだが、数兆円市場を目指すとしているが、何を作るのかはまだ明かされてない。
といったのが乗っており、色んな物を作らないといけないのでハードル高そう。
今のインテルやAMDを超えるのを作れたとしても、競争は激しそうだ。
コンシューマ向けで日本人は期待する所だろうが、おそらくない。
NVIDIA1強になっているのはよくなさそうだが、DirectX対応でGPUメーカーが淘汰された状態が今なので、おそらくない。
ゲームの販売方法自体が、高性能なハードを赤字で売ってソフトで後で稼ぐモデルから変わってしまっているので、おそらくない。
TSMCでF-35のチップを作ってるというのは検索すりゃすぐに出てくる。
似たようなので兵器に使っているチップを国産したいっていう国のニーズはあるはずだ。
ただ数が出ない。
例えば、特殊な暗号チップを作り、国内の省庁間や、海外にある領事館との間で、重要な通信に使う、
というのは考えられる。
こちらも数は出ない。
何かしら作りたいのだろうが、こちらも数が出ないだろう。
通信はデータ量はドンドン増えていることと、安全保障の観点で透明性が求められるので、
多少高くても国産、というのは出てきそうだ。
AIも沢山あるが、例えば車向けとしても、車に載せるのではなく、社内のスパコン向けの方がいいのではないだろうか。
テスラが社内に使うスパコンを自分達でチップから起こした、みたいなものだ。
なんで社内向けが重要かは、車に載せると多少コストがかかっても解析されてしまう。
Google、Amazonなどが自社で作ったチップはクラウドで使うとしているのは、他社、他国にチップを解析されない、というメリットがある。
個人のパソコンに挿せるAIチップが載ったPCIカードが出てくれば、国民としても身近に感じられるだろうが、
どうなるかはわからん。
GPUでも性能足りてない。
クラウドでマイナンバーカードさえあれば、それなりに自由に使えるなら自分は使う。
書いている途中で力尽きたので、上記だけだった。
以下、コメント返し
ターゲットとするのは、もう半導体として機能向上を求めないところ(他の機械部分がボトルネックになるなど)だと思っている。
要はコストダウンのみで、チップが無いと困るが、もう新しく設計必要なく量産だけやってくれる方がいいってところの認識だ。
どちらかというと自動運転向けの画像処理か、車載にせず社内の画像学習向けの方が良いはず。
イメージセンサーに載るのは2nmは多分使わず、熊本28nmの方使うはず。
センサーの後ろにつける画像処理用のISPは2nm使うのはあると思う。
8K,16K 24fps以上狙うと使わないと処理追いつかないはず。
前提として、法規制や税務上の問題、投資上のリスクについては自己責任ということで。
暗号資産は冬の時代に入りつつある。対法定通貨で価格も下がっていくのだが、安定的な相場を形成している暗号資産の多くは価格が連動しているため、暗号資産間の交換では損失は生じないので、STEPNのような遊びを始めるにはいいタイミングだと思う。
ただ、このSTEPN、解説記事のほとんどが暗号資産取引所のアフィリエイトで無駄な情報で偏っており、特に暗号資産の入手と交換の部分が分かりづらいこと、ゲームシステムが極めて複雑な一方で、何をするにも課金が必要なので、色々なパターンを調べづらいということがあるので、個人的にこうした方がいいという点を上げていく。
STEPNで作成したウォレットのバックアップ用の12個の語句(mnemonicという)を使って、即時にChrome拡張のウォレットを設定したほうがいい。
筆者は Phantom https://chrome.google.com/webstore/detail/phantom/bfnaelmomeimhlpmgjnjophhpkkoljpa を使っている。
SOLを入手するためには基本的には中央集権型取引所で入手してからの出金ということになるのだが、この出金が曲者で、結構、トラブルが発生する。
https://www.binance.com/ja/support/announcement/c8ec7fffb8294744b9dcac23baeb08d3
他の取引所を使っていてもトラブルが多発するので、ここは鬼門となる。
Bridgeは使っていないので分からないが、こちらもアタックを受けるなど、色々とある模様。
中央集権型取引所でGMTを入手することも可能だが、上記の理由でおすすめできない。
STEPNのインタフェース上も交換できるようだが、筆者の環境ではうまく動かなかった。
また、動作するとしても、ペアが限られており、例えば、GSTから他の通貨には交換できない。
そこで最初に登場したウォレットが役に立つのだが、こちらを用いて、DEXを利用することが一番よいようだ。
筆者はOrca https://www.orca.so というサービスを使っている。
なぜにOrcaかと言うと、検索順位でもっと上にあったDEXでGMTを入手しようとしたら法外な価格が提示されたからだ。
DEXの仕組み上、有り得る話ではあるので、体感上の相場感は持っていたほうがいい。
よく言われていることではあるが、スニーカーは3足あったほうがいい。
ただ(これはどの記事でも説明が分かりづらいが)実際にプレイに使うのは1足なので、スペックを気にするのはそれだけでいい。
残りの2足はミント0回の最安値のものをピックすればいい。マーケットプレイスのフィルタ機能でミント回数を絞れるので、そちらで選択するとよい。
さて、実際にプレイに使う1足だが、efficiency最重視、resilience二番目という感じで選ぶとよい。
価格差は知れているので、どの速度域でも稼げるTrainerタイプがよいのではないかと思う。
で、この3足の価格+5程度のSOLを一括でSTEPNに送金したほうがいい。
理由としては上記の通り取引所からのSOL出金が不安定なこと、(500円前後だと思うが)出金手数料もかかること、初期以外にも何かと出費があることあたりだ。
アプリ上でウォレットへの着金を確認したら、必要な金額をSpendingにTransferし、はじめて、スニーカーの購入が可能となる。
レベルアップにGSTやGMTが必要となるが、レベル4までは恐らく収支はマイナスにならない。
レベル5に上げる際にGMTが必要なので、Spendingからウォレットに資金を移した上で、ChromeでDEXにアクセスし交換するとよい。
與謝野 馨(よさの かおる、1938年〈昭和13年〉8月22日 - 2017年〈平成29年〉5月21日[1][2])は、日本の元政治家。勲等は旭日大綬章。通常は新字体で与謝野と表記。
趣味はゴルフ、パソコンの自作、囲碁、写真撮影、天体観測、釣りなど多岐にわたる。
囲碁の腕前はアマ七段で、政界最強とも評されている。2007年10月に実力者の小沢一郎と勝負したが敗北した。小沢はアマ六段なので「政治的配慮ではないか」との憶測も流れたが、与謝野本人は「本当に負けた」と認めている[45]。最近はインターネットの囲碁対局サイトも利用し、ハンドルネームは「かおる」を使用しているため対戦相手から女性と誤解されることが多いらしく、麻生太郎にネタにされている[46]。
Linuxやオープンソースの動向など情報技術に造詣が深い、と称している。1999年から2013年時点で自作パソコンを合計20台以上組んでおり[47][48][49][50][51]、うち一台はMicrosoft Windows 2000、Microsoft Windows XP、TurbolinuxなどのOSを使い分けている。パソコン自作の技術について「部品が梱包から解かれて机の上においてあると、1時間くらいで組み立てられちゃって、OSのインストールまで2時間くらいでできてしまう」[38] と語っている。秋葉原で部品を買うのが趣味だったというが、通っていたのがオウム真理教関係のPC店マハーポーシャだったと後で気付いた[52]。ビックカメラやTWO TOP、USERS SIDE、T-ZONEなどの各店舗もよく利用している[38]。老眼の影響もありモニターとキーボードについては、人間の眼と指とが生身で接する重要なヒューマンマシンインタフェースという持論から、IPS液晶とキーボードについては国産メーカーのものを評価している。
与謝野が情報技術に詳しいと聞いたニワンゴは、2008年自由民主党総裁選挙に際し議員会館で「ニコニコ生放送」へ出演を打診した[53][54]。与謝野本人は不在だったが与謝野の秘書が応対し、後日、出演依頼を断っている[53][54]。
これに関係するけど、しょぼいPC支給よりもっとヤバいのがDaaSだと思ってる
フレックスではあるんだけど結局だいたい9時頃にログインするからログイン集中して全然業務を始められない
リモート環境だけじゃなくて出社しててもログインできないから本当にやることない
朝の9:00だけだから増強する気も全然無くて2年以上放置されてる
放置してコーヒー飲んでるんだがたまにログインタイムアウトしてやり直しになるし本当に酷い
具体的には20GBしかない
社員全員の利用状況から計算した容量らしいけど2,3年ですぐにいっぱいになる
共有サーバはあるんだけどOutlookのファイルを置くとアクセス過多になって処理が重くなるので禁止されてたりとにかく使えない
Outlookを開くのに30秒ぐらい
フォルダ開くだけでも平均して5秒ぐらい待たされるからストレスが凄い
文句が出るのが普通だと思うんだけど、恐らく古PCで飼い慣らされた中年以降の社員が大半なのでこれが普通なんだろう
会社にとって必要なシステムはサーバだったりWebのUIだったりするわけで
社員が直接触るWindowsのデスクトップはシステムの一部では無いっていうことを根本的に分かって欲しい
その部分は社員と会社を繋ぐ重要なインタフェースであって、社員側に合わせることこそが多様性の確保そのものだと思う
PFUの高級キーボード、Happy Hacking Keyboard(HHKB)だが使い方を間違えている人が多い
一応、Fnキーを押しながら使うことはできるが非常に使いにくい
なぜこんなことになっているか、というと、そもそもプログラマー(ハッカー)は基本的に矢印キーを使わないからだ
Vimの人はhjklでのキー移動、EmacsはC-BPNFでのキー移動
シェルを使う場合もEmacs風にキー移動できるしショートカットを使うので基本的には使わない
ちなみに知らない人も多いがTwitterもVim風のキーバインドで移動可能
Macの人は例えばメモアプリなんかがEmacs風のキーバインドで移動可能
Windowsを使う場合もアプリなんかでキーバインドを入れ替えて矢印キーを使わないようにする
こんな感じで矢印キーを使わない人が多いから、矢印キーが無くても問題ないのだ
のではなく
「ハッカーが矢印キーを使わないからHHKBには矢印キーが無い」
ということだ
矢印キーはホームポジションから離れた場所にあるため、使うためには一旦ホームポジションから指を離さなければならない
一度話してまた元に戻るという、このコンマ数秒レベルの遅延が鬱陶しくて仕方が無い
なのでホームポジションに指を置いたままキー移動したい、という考えに至っている
とはいえ、全く矢印キーを使わないかというとそういうわけではなく、そりゃたまには使わざるを得ないし使った方が早い場面もある
なので矢印キーを右下の空いてるスペース(通称、猿が辻)に置いておけばいいし、HHKB Liteだとそこに矢印キーがある
なぜそれでも置かないかというと、そもそもが持ち運び前提のキーボードであって、少しでもキーを減らしたい、という哲学があるからだ
はっきり言ってしまって持ち運ばないならRealforceを使えば良く、HHKBを利用する利点は持ち運び前提であるという一点だけと言っても過言では無い
これの大きな理由は、昔はサーバルームでの作業のようにキーボードを繋いで利用するような使い方が前提であった、というのもあるがそもそもの哲学によるところが大きい
アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。
和田先生のこの談話に代表されるように、キーボードは人間がコンピュータと関わるうえで重要なインタフェースであるという設計哲学がある
なのでキーボードはコンピュータに備え付けられているものではなく、持ち運んで自分の好みのものを使う、ということを推奨している
そのためにもキーボードは使いやすさや打鍵感だけでなく持ち運びやすさを重要視してバランスの取れた設計を目指している
その結果、矢印キーを排除するデメリットよりも、排除することで得られる持ち運びやすさのメリットの方が大きいと判断したのだ
左右の猿が辻があるお陰で持ち運びしやすいというのも使ったことがある人なら分かるポイントだと思う
この辺りは賛否あると思うが、馬の鞍であるという哲学に基づけば、PC毎にHHKBを用意したり、自宅と会社で2つ置いている、などは使い方として間違えている
全く同じキーボードであっても、物理的なモノが違えば慣れ親しんだものではなくなってしまうだろう
キーボードを生涯のインタフェースとするなら1つのHHKBを持ち運び使うということを体現して欲しい
ただ最近はBluetooth接続が増えたことや、HHKB BTの出来が良くないことなどもあるため、複数持っている人も多いとは思う
ちなみに、BTモデルには充電池が内蔵されておらず電池駆動なのも生涯使うことを考えているのだろうと思う
これはHHKBに限らない余談になるが、キーボードの裏面にある足は基本的に出さない
手首に角度を付けるよりも水平の方が使いやすいのは人体の自然な原理だ
なぜあの足が付いているか、というと実は「キートップを見やすくするため」だ
なのでHHKBの無刻印モデルに足が付いている理由は全く理解できないし、HHKBを使うような人がキートップを確認するとは思えないのでそもそもいらない
とはいえ、昔から足を出して手首に角度を付けてタイピングすることに慣れてしまっている人もそれなりにいるだろうから
自分の好みで出したり引っ込めたりすればいいとは思う
session.cookieって書かれると「sessionのcookie」とは違うものを表そうとしているのではないかという可能性を否定できないんだよね
たとえば元増がdocument.cookieという例を挙げてるけど、これはブラウザが提供するDOMインタフェースには必ずdocumentというグローバルオブジェクトが含まれると仕様上決まっており、このオブジェクトは必ずプロパティcookieを持つ、という前提があるからこそこれだけで通じるわけで
同じルールでsession.cookieとか書かれると、「ん?sessionなんていうグローバルオブジェクトあるの?聞いたことないけど…」と混乱する
まあ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の活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
プログラム同士を連結しにくいので、どうしてもその目的限定の用途しか持てないし、アプリの機能に深く依存した作りになってしまうから、賞味期限も短い。なにせプログラミング界に「過度の対話的インタフェースを避ける」って原則があるくらいだ。VBA や Applescript はまあまあ上手くやっているけどね。
個人用の作業補助ツールを黙々と作ってきたけど、今は、なるべくやるべきではない、って考えを持ってる。
社会全体をひとつの大きなソフトウェアハウスとみなすと、各ユーザーが独自に自分用ツールを持ってコッソリ使うという状況は、コードの重複に他ならない。各個人でメンテする必要があって、バグもそれぞれの環境で発生する。それよりも、機能要望の声を集め、製作に手を挙げたプログラマーが責任を持ってプログラムを管理し、ユーザーはバグレポートをその人に報告する方が、労力の集約・責任の分担の観点でより効率的だ。
twitter でその道の専門家を探し、ツイートを引用して議論に引っ張り込み、目的の機能がないって言質をとる。やり取りを togetter にまとめる。暇なプログラマーが最初の実装を書く。reddit で紹介されて世界に広まり、 github でフォークがたくさん作られる。プログラミング言語を換えた、より洗練された Yet another ツールが作られる…
SNS は汎用の、新機能リクエストプラットホームとしても使われてる。
自分で自分のためのツールを作る気になって、でもそれを使う想定ユーザーがどう考えても自分以外に思いつかないときは、糊(のり)だけを作りたい。アプリの拡張フックと、配布されてるモジュール・コマンド・汎用プログラミング言語、OSの標準機能。それらを繋ぐだけの簡単なお仕事を。
この記事を読んで、自分もそういうのあったなぁって思ったので書いてみた。
仲間がいるように思えてちょっと嬉しい。
でも仕事が忙しかったりで家でも練習せず、お金ももったいないなと思い始めたので辞めた。
写真をバンバン撮って、ネットにアップロードして売っちゃうぜ!
なんて考えていたけど、カメラが重いし持ち運びも不便だしで触らなくなってしまった。
ちなみに一眼レフカメラは2台(時期をずらして)買ったけど埃を被っている。
・バイク
続いている趣味と言えば趣味なんだけど、数ヶ月乗らなかったりもする。
ちなみにアドベンチャータイプのバイクと大型ツアラーと2台所有してる。
・車
車が趣味というより、自転車代わりにどこか近所に出かけたりするのに使ってる。
ちなみに車をいじったりとかは全然興味ない。
Civ系が面白いと聞いたのでやってみたけど、自分には操作が不便で面白さが分からなかった…
他にも面白そうなものとかはあったんだけど、インタフェースが英語なので諦めた。
・旅行
旅行行くだけで数万飛ぶし、休み潰れるしで「旅行行きたいな」って思うだけで十分なことに気がついてしまった。
・小説
歳取ったせいか(30代後半)、昔ほど「この本を一気に読むぞ!」という気力も無ければ、読んでる本を途中で読んでることすら忘れてしまうことが多い。もうダメかもしれない。
面白いのとかもあるんだけど、1〜2時間ずっと見続けるってのは意外と根気が必要で、だるいなぁって思うのが先に勝ってしまう。
・映画
ネット配信動画と同じ感じで、たまに映画館には行くけど、よっぽど見たいものでなければ行かなくなってしまった。
・サバゲー
興味はあるし、中学生の時にちょっとやってたんだけど、身近にやる人がいないので何も手つかず。
・イラスト
安いペンタブ買ったけど、もともと絵心がないのもあって埃被ってる。
・家庭菜園:前にも少しやってたけど、水をあげることすら忘れてしまう…