はてなキーワード: VMとは
いつ話飛んだか指摘してみ？
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250910170512# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaMExOwAKCRBwMdsubs4+ SFTVAP99rtN3yIxlkAzKa4Q3nYObZPCkk7fAf/GIzb1d0ONTqAD/eSjIaCW4A9fD j/bbs4iid5Yr9i5qQl9D6ITLCQWvhg0= =r+Vm -----END PGP SIGNATURE-----
グローバル単一台帳（Blockchain/DAG） 相互検証可能な“関係グラフ”
各ノードは「だれが・いつ・どうつながったか」という変化の射だけを署名し、トポロジ全体が履歴になる
オンチェーン状態 ≒ 直接資産 状態はローカル・資産は導関数
資産や契約は、関係グラフ上の経路依存量として再構成。スナップショットはクライアントが“可逆圧縮”で再計算可能
Proof of X (Work, Stake, etc.) Proof of Stewardship (PoS²)
「ネットワークが望ましい 複雑性 を維持するよう行動した度合い」をメタリック関数で動的スコア化し、報酬・ガバナンス権・帯域を同時に発行
要旨
もはや「台帳」すら保存しない。各エッジは STARK 圧縮された更新証明を持ち、グラフの梁（フレーム）自体が履歴になる。再構築は局所的に O(log N) で済むため、グローバル同期のボトルネックが消える。
2. プロトコル層
Fractal Mesh Transport (FMT)
自己類似ルーティング – トポロジ全体をフラクタルで自己複製。局所障害は“自己相似”パターンに吸収されるため、DDoS が形骸化。
アイデンティティ内包アドレス – DID を楕円曲線座標に埋め込み、パケット自体が署名・暗号化・ルーティングヒントを同封。IPv6 の後継としてレイヤ 3.5 に位置づけ。
HoloFabric Execution
ゼロ知識 WASM（zk-WASM） – 任意言語を WASM にコンパイル→ zk-STARK で実行トレースを証明 → “結果のみ”関係グラフへ。
コンパイラ内蔵 MEV 抑制 – 計算結果が他ノードから解釈不能になるタイムロック VDF を伴い、価値抽出を物理的に遅延。
Temporal Stream Storage
余剰ストレージの“時価”マーケット – ノードは自己の余剰 SSD/HDD を分単位オークション。データは Reed–Solomon＋重力波的ハッシュ空間で erasure coding。
リテンション ≒ 信用 – 長期ホスティング実績は PoS² スコアへ累積。攻撃的ノードは経済的に即時蒸発。
Liquid Fractal Governance
議決トピックを「周波数帯」にマッピングし、参加者は帯域を“委任スペクトル”として分配。結果はウォルラス圧力で収束し、マイナー意見も連続的に次回へ重みが残る。
（安全・分散・性能） 台帳の排除で“グローバル合意”自体を縮退 ⇒ スケール制約が幾何的に消失 安全：ZK 証明、
エネルギー消費 PoS² は「社会的有益度 × 熱消費効率」で算定。熱回収データセンターほど報酬が高い PoW よりオーダー数桁効率、PoS より社会関数を内包
プライバシー vs 透明性 グラフは公開。ただし各エッジは zk-STARK なので内容は非公開 / 関係のみ検証可能 トレーサビリティが“情報理論的に”限定される
MEV・フロントラン タイムロック VDF＋“ランダム束縛順序”で物理的に不可 ブロック順序依存問題を根絶
量子耐性 STARK 系 + 多変数格子ベース署名 Shor 破壊リスクを遮断
レガシー互換 Ethereum, Bitcoin, IPFS などへ 1:1 ブリッジを Rust/WASM で提供 既存資産を損なわず漸進的移行
Steward Credits (SC)：PoS² に比例し新規発行。帯域・ガバナンス票・ストレージ予約を等価交換。
Energy Reclaim Units (ERU)：余熱回収率に応じてクリーンエネルギー補助金と相互運用。
Knowledge Bounties (KB)：AI/LLM ノードが生成した有用モデル差分を関係グラフへコミット→検証トークンとして KB が発行。
負荷の自己調整
ネットワークが過度に混雑すると SC の新規発行レートが自動減衰し、トラフィック手数料が指数的に上昇。結果、スパムは短時間で経済的自殺となる。
Year 0–1：最小核 – zk-WASM VM + Fractal Mesh over QUIC。
Year 1–2：PoS² / ERU メトリクス実証、EVM 相互運用ブリッジ稼働。
Year 2–4：Liquid Fractal Governance によるプロトコル進化をコミュニティへ全面開放。
Year 5+：全世界 ISP ピアリング → 既存 Web の転送層を徐々に Web∞ 上へマイグレート。
国家単位のデジタル・ソブリンティを再構成：国境・法人格の境界を越え“関係”が一次元目となるため、規制枠組み自体が協調フィードバックモデルへ。
プライバシーと公共性の再両立：透明な“関係構造”上で非公開データを安全に扱う産業 API が標準化。医療・行政・金融の壁が大幅に低減。
インフラの脱炭素最適化：PoS² スコアに ERU が直結することで、再エネ比率が低いノードは自然淘汰。エネルギー政策と IT インフラが実質同一の経済圏に。
7. まとめ
Web∞ は「情報の状態」を残すのではなく「変化の証明」を残す。
その結果、台帳の重力・ガス代・フロントラン・量子不安・ガバナンス停滞といった Web3 固有の限界が、概念的に 初期条件から消滅 します。
エネルギー・プライバシー・スケーラビリティを同時に極小化／極大化するため、従来トレードオフと呼ばれた三角関係は “収束しない曲線” へと畳み込まれる――それが本構想の核心です。
もし実際にプロトタイプを設計するならば、zk-WASM ランタイム + Fractal Mesh を Rust で最初に書き起こし、PoS² の初期指標を「再生可能エネルギー電力比＋ノード稼働継続率」で暫定運用する、というのが現実的なスタートラインになるでしょう。
Mac で開発している。開発物は主にLinuxのカーネルモジュール。.koファイル。Linuxをラップトップ、ノーパソで使わせてくれる会社のお勤めの方が羨ましい。だって手元でコンパイルしたいじゃない?
会社がコンピュータ筐体を管理するソフトを入れてくる都合上、MacかWinの二択。以前はWinラップトップにLinuxをデュアルブートできるようにしてこっそり使ってたら、ある時バレて怒られちゃった。以来2012年頃のお古Macラップトップを与えられて10年使い続けている。アップルシリコン使いたくない一心でOpencore legacy patcher 様に頼り筐体交換を拒否ってる。値段も高いしね。デュアルブートしてLinux使って仕事してることは内緒。
WSL2が素晴らしいようだけど、カーネルモードドライバとかつくれるの？IRQとか叩いたり、割り込みとか触るんだけど…VMだとなんか動作が違っていろんなバグが再現しないんです。
ReactNativeに限らず合法的にクロスプラットフォームでiOSアプリ公開するならmacは必須やで
フリーランス時代とか含めて割といろんなとこで仕事してるけど、最近はWindowsをメインで使ってるエンジニアってほとんど見ないよね
営業とか企画とかはWindowsっぽいけど、最近はOffice依存も減ったからMacで十分なんだよね
というかOfficeも365になってOS依存がなくなったからブラウザが動けばどこでもいいでしょ
逆にブラウザはAppleとはいえSafariは微妙でChromeしか使ってない
そもそも、今時のソフトウェアエンジニアやってたらiOS対応って絶対に必要でXCodeが必要になるでしょ
WinとかAndroidはVMで動くけど逆は動かないんだからMacにするしか選択肢ないと思うんだけど
あとは、タブレットたまに使うのと通知を即座に知りたいからWatchは必要で
Unix系もMacの方が情報が揃ってるし便利（どうせDocker動かすだけだったりするけど）
まぁWindowsでもWSL2とか使えば仕事出来なくは無いけれど
何回かトラブったり対応してなかったりして諦めてMacになったかな
そしてMacだと、トラブルがあっても検索したら絶対に同様のトラブル起こしてる人がヒットするから解決策がすぐ分かる
最近だとChatGPTに聞けば懇切丁寧に教えてくれる（brewとXCode周りのトラブルとか）
Macで困ることはSteamとかゲームするときで、ゲーミングPCはWindows一択
・NASを構築したいけどVMやDockerも使いたいからproxmoxを使いたい。10GBeのPCI-eカードを刺して通信する予定だけど、全然速度出ないって聞いて本当？PCI-eパススルーとかでも無理なの？
・VMでTrueNASを立ち上げてネットワークディスク自体はTrueNASで管理したいけど、物理ボリューム自体をTrueNASで管理するのは可能？もちろんVMを格納するディスクは別でSSDを確保してそこに入れるつもり
これはオンプレミス回帰を謳っていたり、パブリッククラウドを否定するものでは無いです
2025年現在、サーバを準備するってなると、初手で AWS だの GCP だのってのを SNS ではよく目にするけど、
世の中の大半のシステムって、レンサバで十分だし、もっと言うなら事務所の片隅に置いたラップトップに「絶対シャットダウンしないでください」って付箋貼って置いておけば十分なモノばっかりじゃない？
オートスケールが云々とか、スペックの拡張が容易だとかクラウドのメリットはたくさんあるけど、実運用でそんなに使わなくない？
VM のスペックが足りなくなってきたから拡張しますっって、そんな場当たり的な対応よりも、コードのチューニングした方が良くない？
テレビで特集されたとかでアクセスが増えたときに捌けないと困るとか、そんなのサーバが落ちた方が流行ってる感出るじゃん
機会損失とか言うけど、そんなテレビの特集で最終的に購入までしてくれるユーザなんてほんの一握りなわけで、そこに大した機会なんてないんですよ
確かに超有名なサービスとかなら、そういうのがあった方が良いと思うけど、世の中の大半って管理者用の管理サイトとか、大したアクセスもないコーポレートサイトとか
そんなのばっかりでしょ
月額のコストを見ても、クラウドは過剰なコストが掛かりすぎてる場合が大半じゃない？
今一度本質を見つめなおして欲しい
https://togetter.com/li/2429296
この話に繋がるんだけど幼少期からバイリンガル教育を受けた人って思考が無茶苦茶で発言が支離滅裂なことが多い
帰国子女とかにそういう人が多くて日本語も英語も両方が中途半端（発音だけは良い）
どうやら思考するときに日本語・英語の両方で考えてしまっていてそれぞれの言語の良さを生かし切れていない
WindowsとMacが両方動いてるけどディレクトリ構成もプロセス管理もごっちゃになってる、みたいな感じ
それなりの年齢になってから英語教育を受けるとちゃんとVMなりコンテナを作って共存させるんだけど
幼少期ってまだOSとして未熟なので、そこにWinとMacを一度にインストールしているような状態
それでもそのごちゃまぜディレクトリを自分なりに使いこなせればいいんだけど、言語って人類が産まれて以降、何世代にも渡って培われてきた秘伝のソースであって、それを一世代で塗り替えるのって相当無理があるんだよね
今の親って幼少期の英語教育にやたら熱心だけど絶対にやめた方がいいと思う
Device Info は、高度なユーザー インターフェースとウィジェットを使用してモバイルデバイスに関する完全な情報を提供するシンプルで強力な Android アプリケーションです。たとえば、デバイス情報/ 電話情報には、CPU、RAM、OS、センサ、ストレージ、バッテリー、SIM、Bluetooth、ネットワーク、インストール済みアプリ、システム アプリ、ディスプレイ、カメラ、温度などに関する情報が含まれます。また、デバイス情報/ 電話情報は、ハードウェア テストでデバイスのベンチマークを行うことができます。
中身 : 👇 👇
👉 ダッシュボード : RAM、内部ストレージ、外部ストレージ、バッテリー、CPU、利用可能なセンサ、インストール済みアプリ & 最適化
👉 デバイス : デバイス名、モデル、メーカー、デバイス、ボード、ハードウェア、ブランド、IMEI、ハードウェア シリアル、SIM シリアル、SIM サブスクライバー、ネットワークオペレータ、ネットワークタイプ、WiFi Mac アドレス、ビルドフィンガープリント & USB ホスト
👉 システム : バージョン、コード名、API レベル、リリース バージョン、1 つの UI バージョン、セキュリティ パッチ レベル、ブートローダー、ビルド番号、ベースバンド、Java VM、カーネル、言語、ルート管理アプリ、Google Play サービスバージョン、Vulkan のサポート、Treble、シームレスな更新、OpenGL ES およびシステム稼働時間
👉 CPU : Soc - システム オン チップ、プロセッサ、CPU アーキテクチャ、サポート対象の ABI、CPU ハードウェア、CPU ガバナー、コア数、CPU 周波数、実行中のコア、GPU レンダラー、GPU ベンダー & GPU バージョン
👉 バッテリー : ヘルス、レベル、ステータス、電源、テクノロジー、温度、電圧と容量
👉 ネットワーク : IP アドレス、ゲートウェイ、サブネット マスク、DNS、リース期間、インターフェイス、周波数、リンク速度
👉 ネットワーク : IP アドレス、ゲートウェイ、サブネット マスク、DNS、リース期間、インターフェイス、周波数、リンク速度
👉 ディスプレイ : 解像度、密度、フォント スケール、物理サイズ、サポートされているリフレッシュレート、HDR、HDR 機能、明るさのレベルとモード、画面のタイムアウト、向き
👉 メモリ : RAM、RAM タイプ、RAM 周波数、ROM、内部ストレージ、外部ストレージ
👉 センサー : センサー名、センサベンダー、ライブセンサ値、タイプ、電力、ウェイクアップセンサ、ダイナミックセンサ、最大距離
👉 アプリ : ユーザーアプリ、インストール済みアプリ、アプリバージョン、最小 OS、ターゲット OS、インストール日、更新日、アクセス許可、アクティビティ、サービス、プロバイダ、レシーバー、抽出アプリ Apk
👉 アプリアナライザー : 高度なグラフを使用して、すべてのアプリケーションを分析します。また、ターゲット SDK、最小 SDK、インストール場所、プラットフォーム、インストーラ、および署名によってグループ化することもできます。
ディスプレイ、マルチタッチ、懐中電灯、ラウドスピーカー、イヤースピーカー、マイク、耳近接、光センサ、加速度計、振動、Bluetooth、WI-Fi、指紋、音量アップボタン、音量ダウンボタンをテストできます。
👉 温度 : システムによって指定されたすべての温度ゾーンの値
👉 カスタマイズ可能なウィジェット ： 最も重要な情報を表示する 3 つのサイズの完全にカスタマイズ可能なウィジェット
👉 レポートのエクスポート ： カスタマイズ可能なレポートのエクスポート、テキストレポートのエクスポート、PDF レポートのエクスポート
権限 👇 👇
READ_PHONE_STATE - ネットワーク情報を取得するには
BLUETOOTH_CONNECT - Bluetooth テスト
READ_EXTERNAL_STORAGE - イヤースピーカーとラウドスピーカーのテスト
そりゃそうなんだろうけども。そんなに？
追記：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クオリティを発揮してくれたらなと楽しみにしてます。うはｗｗｗおｋｗｗｗｗｗ