  |
はてなキーワード: インタフェースとは
年末調整が難しすぎる（令和６年度版）https://anond.hatelabo.jp/20241115174825
を読んで大変そうだなあ。確定申告すればいいのにと思いました。
年末調整を行うのは会社の義務ですので、会社は年末調整をしないといけません。
年末調整の社員の手続き方法は、会社ごとによってかなり違います。
年末調整の手続きシステムは、一般の企業が開発しているものを、それぞれの会社が契約して、従業員に使ってもらっています。
どのサービスと契約しているかによって、手続きの煩雑さにかなり差があります。
年末調整システムの最も大事な事は、その会社の経理システムや人事労務システムとどれくらいスムーズに連携できるかです。
従業員の手間が大変かどうかの優先度は、2番目以下です。
従業員にとって、とても使いやすい年末調整申請サービスがあっても、簡単には導入できません。
(追記：年末調整の公的ソフトウエアについての記載に間違いがあったようなので消しました。）
会社は年末調整する義務がありますが、従業員は最終的に正しい金額の納税をすれば良いだけの話です。
年末調整で出し忘れた、処理していない税金の処理は、確定申告でして問題ありません。
保険料、iDeCo、住宅ローンなどの控除を年末調整では申請せずに、確定申告をオンラインでしてみましょう。
e-tax連携が終わっていればポチポチするだけで、値の入力もする必要もありません。
これから先も確定申告は連携が増えてどんどん楽になっていきそうですし、ユーザーインタフェースも毎年改善が続いています。
まずは今あなたの契約している保険会社などがマイナポータル連携できるかを調べましょう。
https://www.nta.go.jp/taxes/tetsuzuki/mynumberinfo/list.htm
ほとんどの控除項目で連携が可能になっています。連携可能な場合は連携の手続きをしましょう。
この作業を年内に済ませておきましょう。
面倒な手続きですが、一度すれば来年以降は手続き不要ですので頑張りましょう。
連携不可能な会社がまだ少し残っていますが、その場合も控除証明書に書かれている数字を指定の場所に打ち込むだけですので、そんなに難しくありません。
元増田さんは持ってそうな雰囲気でしたが、もしも持ってらっしゃらなくてこの文章を読んでる方へ
スムーズに確定申告をするにはマイナポータル連携などが必要なので、マイナンバーカードが必須です。
そもそも、マイナンバー制度は、行政を効率化し、国民の利便性を高めるために作られたものですので、その恩恵を受けるにはマイナンバーカードが必要です。
ほとんどの手続きは2024年版（1年前）の手続きと同じなので、古本や図書館で借りるので十分です。数年以上前の本は色々変わっていますので避けましょう。
Kindle Unlimitedにもたくさん本があります。
確定申告の時期は、基本的には2025年2月17日（月）から2025年3月17日（月）です。税務署に行って相談しながら紙ベースで作業するならこの期間に提出しましょう。
ただしオンラインで確定申告をする場合は少々早く申請しても受け付けてもらえます。
私自身は毎年1月上旬にオンラインで確定申告を行っていますが、全く問題なく受け付けていただいています。
数週間で還付金は振り込まれています。数か月還付金が振り込まれないなんて事はありません。
年末調整で次の月の給料が調整されるより、確定申告した結果として還付金が振り込まれる方が、うれしさや実感としては大きいように思います。
以前に「この1年で確定申告がめっちゃ簡単になってるよ」を書きました。よろしければそちらも参考に
HHKBは下記のような話が前提となって作られている
アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。
新しいパソコンを買ってもWindowsからMacに乗り換えてもキーボードは大切なインタフェースとして鞍のように持ち運ぶ
なので小さければ小さい方が良いし品質は高ければ高い方がいいい
この大前提があるので
といった特色を持っている
キーの少なさについて不満を言う人が多いが、基本的にプログラマーはFunctionキーや矢印キーを使わない
それどころかホームポジションから指を離さないといけないようなキーはほとんど使わない
例えばVimならhjklのキー、EmacsならC-npfbのキーで移動できるので矢印キーは使わないし
BackspaceはC-hを使ったり、その他にも人によって独自にショートカットキーを設定している
これはキータイピングの時間を短くするという理由と打ち間違いを極力減らすという理由のためである
大抵の場合ショートカットキーにはCtrlキーを多用するのでAキーの横にCtrlキーが配置されており、押し間違いの代表格であるCaps Lockはよくわからないところに追いやられている
プログラマーが英語配列を好むのも実はこの押しやすさが関係していて
Returnキー（Enterキー）がホームポジション右手小指のキー1つ空きで押せるためである
できません
「この3問を解くのにかかる時間は？」
とか聞かれても
「5分で解けるかもしれないし3時間かかるかもしれないしそもそも解けないかもしれない」
という答えになります
「xに1から順番に100ぐらいまで代入したら証明できるよね？」
みたいなこと言う人いますが、それは証明になっていないので後々困ることになります
「この辺をこうしておいて、この場合だけ別途証明して、ここはこうすればいけるかな？」
という感じでざっくりの見積もりは出せますが、5分か1時間か、ぐらいの粒度でしか出せないし
大半の場合はハズレるし下手すると大ハズレするので意味がありません
とか言ってくる人いますが、見積もりを出してくるソフトウェア開発会社や部署は
「かなり多めに見積もって遊んでる」
のどちらかです
テストが不十分だったりセキュリティ脆弱性を抱えていたり拡張性がなくて結果的にはゴミになるか追加費用が発生するかのどちらかです
そもそもクソコードと呼ばれるコードは本当にちゃんと動いているのかどうかが分かりません
綺麗なテストが書けるならテストを通過するコードは動いていると言えますが
そもそも綺麗なテストが書けるような仕様ならクソコードになりません
大半のクソコードはそもそも仕様が曖昧な状態で、その曖昧な状態をコードに落とし込むのでクソコードになります
なのでバグがあるかどうか判別できず、本当に動いているかどうかを保証できません
型があるような言語を使っていればインタフェースをキッチリ設計してある程度保証できますが
型が無い言語は地獄でコードを1行ずつ読んでメモしていかないとバグがあるかどうか分かりません
最近だとChatGPTなんかのLLMを使うことでその辺はかなり楽になりましたが
綺麗に書かなくて良いわけではありません
できません
その辺の企業が一般社員をプロ野球選手に育成しようとしているのと同じレベルで出来ません
最初からプロ志望で社会人野球枠で入社してきて仕事はそこそこに毎日トレーニングと試合をしてるような人で
また、そのレベルであっても、せめて「野球で甲子園行きました」レベルの人材が必要で
みたいな人がプロレベルになれるわけがない、というのが現実です
とか言ってる会社が多いですが、育成するぐらいなら他から選手集めてきてチーム作る方が早いし安上がりです
ちなみに日本のソフトウェア企業の大半はこのプロレベルに到達しておらずほとんどが草野球レベルなので
「グラフィックにかけた手間は関係ない」だったらまあ分からなくはないんだけど、「グラフィックの出来」だと流石にゴミみたいなグラフィックで面白かったゲームは思いつかないなあと。
そもそもゲームをデザインする段階でグラフィックはどうしてもくっついてくる訳じゃん。
そのゲームがどういう思想で作られているのか、コンセプトはどういうものなのか、それぞれのキャラの役割を伝えたりユーザーインタフェースを良くしたりと、ゲームとしてのコミュニケーション能力を支える重要なパーツでしょ。
たとえばRPGツクールのデフォルトグラフィックだけのゲームは素材を探す手間さえかかってないけど、ゲーム全体を通してグラフィックは統一されているし、それぞれのグラを与えられたキャラクターの役割（例：魔法使いだからHPは低いけど魔法攻撃は強い 水の精霊だから水属性）はシッカリ伝わるからねあのデフォルトグラは。
（おっとここで風のリグレットで反論しようとしたキミは見事にダウトだ～～～あのゲームは想像を掻き立てるシンプルなパッケージデザインと黒一色の画面という強烈なグラフィックを武器にしており、手間はそれほどかかってなくとも「グラフィックのインパクト」「ゲーム性を伝えるコミュニケーション能力」という意味では高得点なのだから～～～）
駄目なゲームにありがちなこととして「グラフィックによるコミュニケーションを軽んじている」という部分があるんだよ。
ゲームってのは基本的にはゴッコ遊びなので、グラフィックを見た瞬間にそのキャラクターや行為が持つ役割が伝わってこないとアカンのよね。
スピードが早いものにはスピードの早いグラフィックを当てはめるべきだし、鈍重なものは重たそうなグラフィックであるべきなのよ。
そしてなによりそのゲームが想定している「こういうイメージで遊んでくださいね」というものがゲーム画面をみてすぐに、そして少しでも具体的に伝わったほうがいい。
弾幕STGが人を引き付けるのは「一見回避が難しそうな弾が画面いっぱいに広がっていて、これをクリア出来たら全能感が凄いだろうな」と想像させる力があるから。
逆にクソゲーと呼ばれがちなSTGは「一見避けやすそうなのに全然避けられない弾が飛んできて、この程度も避けられない自分は無能だと感じさせてくる」ってパターンがかなり多いわけよ。
ゲームってのは元々はTRPG（テーブルRPG。サイコロ遊びと指輪物語ごっことノート迷路を足したようなの）みたいなごっこ遊びに端を発したものであり、ゲームソフトはGM（ゲームマスター（語り部・ディーラーぐらいの意味））としての役目があるわけなんだからさ、そこはちゃんと「今、こういうことをしています。この遊びはこういう所が楽しいよ」ってちゃんと伝えてくれなきゃ。
なんか手抜き感満載のグラフィックな上にそれぞれがどういう役割を持ってるのかも伝わらず、結局やってることがシックリ来ないし、どう楽しいのかも伝わらないならそんなゲームの評価はやっぱ下がるよ。
思い切って文字だけで表現するとか、諦めて汎用フリーグラフィックを使うとかで誤魔化してもいいから、少しでも自分のゲームがどういうものかを伝える努力をすることにエネルギーを使うべきなんだって。
「グラフィックに頼らないことで奥行きのあるゲーム性が引き立つ」とか中二病みたいなことは絶対に考えちゃ駄目なんだよね。
アニメ、漫画、ゲームといったコンテンツの生成は多くの人手によって行われる
出版社は生成に必要な人手を集めて、コンテンツを生成し、流通させる
これはつまり、起案からリリース、流通までに時間がかかることを意味する
そこで、例えば顧客のPCにコンテンツ生成用のAIを待機させておくことによって、顧客ごとにカスタマイズされたコンテンツをその場で生成するという芸当ができるようになるかもしれない
顧客の属性に合わせて、ニュースをずんだもんに解説させたり、恋愛漫画の主人公をLGBTにしてみたり、独裁者になって世界を支配するゲームだったりをその場で生成して提供できるようになるかもしれない
さらに、その場の顧客の反応に合わせて内容をインタラクティブに調整できるかもしれない
AIサービスが既存のコンテンツ産業にとって代わり、人々の情報や娯楽の中心となり、また生活のパートナーとして貢献するようになるだろう
その時の我々に価値観とは何か
AIによって、作品自体は受け手一人一人に合わせて変容するようになる
手話とか点字のようなインタフェースを人力で回す必要がなくなる
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を書くことを「プログラミング」とはふつう言わないようなものです。
要するに、フロントエンドプログラミングと呼ばれているものは、単なるWebブラウザのマクロに過ぎません。
最近コンピューターサイエンスがプログラマーに必要か否かみたいな話が上がっているが、そもそもコンピューターサイエンスって何だよ。どこまでの範囲をさしてんの？
ググって出てきた情報を整理しただけなので詳しい人、補足・訂正よろしく！
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]。
せめてDaaSのメモリUPとかは申請ですぐできるようにしてほしいよな
これに関係するけど、しょぼいPC支給よりもっとヤバいのがDaaSだと思ってる
フレックスではあるんだけど結局だいたい9時頃にログインするからログイン集中して全然業務を始められない
リモート環境だけじゃなくて出社しててもログインできないから本当にやることない
朝の9:00だけだから増強する気も全然無くて2年以上放置されてる
放置してコーヒー飲んでるんだがたまにログインタイムアウトしてやり直しになるし本当に酷い
具体的には20GBしかない
社員全員の利用状況から計算した容量らしいけど2，3年ですぐにいっぱいになる
共有サーバはあるんだけどOutlookのファイルを置くとアクセス過多になって処理が重くなるので禁止されてたりとにかく使えない
Outlookを開くのに30秒ぐらい
フォルダ開くだけでも平均して5秒ぐらい待たされるからストレスが凄い
文句が出るのが普通だと思うんだけど、恐らく古PCで飼い慣らされた中年以降の社員が大半なのでこれが普通なんだろう
会社にとって必要なシステムはサーバだったりWebのUIだったりするわけで
社員が直接触るWindowsのデスクトップはシステムの一部では無いっていうことを根本的に分かって欲しい
その部分は社員と会社を繋ぐ重要なインタフェースであって、社員側に合わせることこそが多様性の確保そのものだと思う
DaaSっていうのはそのインタフェースを社員全員同じものに統一する、という社会主義的発想の最たるもので
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の活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
