  |
はてなキーワード: データ形式とは
計算機科学は、情報の理論的基盤から実用的な応用まで、広範な領域をカバーする学問です。以下に、計算機科学の主要な分野と、特にネットワークに関連するトピックを体系的にまとめます。
プログラミングパラダイム: 手続き型、オブジェクト指向、関数型、論理型など。
プロセス管理: CPUのスケジューリングとマルチタスキング。
機械学習アルゴリズム: 教師あり学習、教師なし学習、強化学習。
深層学習: ニューラルネットワークによる高度なパターン認識。
ネットワークは、情報の共有と通信を可能にする計算機科学の核心的な分野です。
OSI参照モデル: ネットワーク通信を7つのレイヤーに分割し、それぞれの機能を定義。
プレゼンテーション層: データ形式の変換。
アプリケーション層: ユーザーアプリケーションが使用するプロトコル。
TCP/IPモデル: 現実のインターネットで使用される4層モデル。
リング型: 各ノードが一方向または双方向に隣接ノードと接続。
IP（Internet Protocol）: データのパケット化とアドレッシング。
TCP（Transmission Control Protocol）: 信頼性のある通信を提供。
UDP（User Datagram Protocol）: 信頼性よりも速度を重視した通信。
ルーター: 異なるネットワーク間のパケット転送とルーティング。
IDS/IPS（侵入検知/防止システム）: ネットワーク攻撃の検出と防御。
VPN（仮想プライベートネットワーク）: 安全なリモートアクセスを提供。
SDN（Software-Defined Networking）: ネットワークの柔軟な管理と制御。
IoTプロトコル: MQTT、CoAPなどの軽量プロトコル。
SNMP（Simple Network Management Protocol）: ネットワークデバイスの管理。
ネットワークトラフィック分析: パフォーマンスとセキュリティの最適化。
ネットワークオーケストレーション: 自動化された設定と管理。
AIによるトラフィック最適化: パフォーマンスの向上と障害予測。
マイクロセグメンテーション: ネットワーク内部の細かなアクセス制御。
『コンピュータネットワーク』 アンドリュー・S・タネンバウム著
『ネットワークはなぜつながるのか』 戸根勤著
Coursera: 「コンピュータネットワーク」、「ネットワークセキュリティ」コース
edX: 「Computer Networking」、「Cybersecurity Fundamentals」
IETF（Internet Engineering Task Force）: ietf.org
IEEE Communications Society: comsoc.org
W3C（World Wide Web Consortium）: w3.org
レベル2：数式が組める
レベル3：Ctrl+S、Alt→E→L などのショートカットが使える
レベル4：フィルタ設定、ウィンドウ枠の固定、入力規則が使える
レベル5：VLOOKUPが使える(INDEX MATCHでも可。絶対参照と相対参照が分かる)
レベル6：条件式が組める
レベル7：データ形式が分かる(Excelのお節介機能を黙らせてCSVファイルを正しく開ける)
レベル8：Excelについて質問されるほどの知見/信用がある
レベル9：依頼側の要件を聞き、譲渡可能な(作成者に依存しない)Excelファイルを作成できる
エンジニアと大雑把に括られてるけど、実際にやることはその中の職種によって凄まじく違うことに注意な。
やりたい事に近い事、お前さんのイメージするエンジニアに近い事をやるといい。
んで、こだわりないなら両方やっとけ。
基本情報なぞ簡単に取れる。取れなきゃ次は、アプリやサービス作る過程で色々調べたりした経験に、ちょいと試験向けの勉強する程度で取れる。取っとけ。
アプリやサービス作りは難しい。作ろうと思うだけでなく、実際に手を付けられる奴はそう多くない。サンプル通りでない物を自力で完成させられれば、エンジニアに十分向いてる。本当に難しいのは作ることではなく、その先の続けることの方ではあるんだが…。
で、だ。単に就職できればいいや止まりの話でなく、アプリやサービスを作りたいという思いがあるのなら、何かを作ったり設計したり企画したりしたいという思いが自分自身の内にあるのなら、だ。
まず紙のノート買ってこい。これが何よりも大事。そして捨てるな、一生。
作りたい物の全体デザインを書いてみろ、その最初の数枚は絶対に捨てるな。残りも可能な限り捨てるな。
スケッチブックかノート、中性紙で。無地が望ましいが近所での入手性も大事。人に見せることもあり得るのでA4以上、携帯したいとしてもB5以上。
リングでも綴じでもいいがルーズリーフを継ぎ足せるタイプは論外。紙を切り取るミシン目があるのも論外。後から整理しようとするな。余分なページを外そうとするな。丸ごと取っておくんだ。
筆記具はボールペン。フリクション絶許。ホワイトもダメ。消す時は横線で。消したという判断も、それを一旦は思いついたということも後から見れるように。
請けた仕事用とは絶対に共用するな。プロジェクトを離れる際に、機密漏洩防止のため捨てることになるから。プロジェクトの成果の持ち主が本人なら知らぬ。
環境がノートを絶対捨てない事を許さないのなら…電子データでもやむを得ないが、クラウドストレージ+バックアップでガチガチに消えないように。そして跡を消さず、整理せず全て残すように。
お前さんの方向性次第では、本当に必要なのはDesign Docsのような電子データの文書かもしれない。それでも要所は同じ。
gitに突っ込む。横線で消すのではなく、gitの履歴と比較できるデータ形式にしておく。履歴を後から整理しようとせず、ガチガチに消えないように全て残す。
グッドラック。
様々な状況の中での感情・行動、自分の中の極限の悩み、それらは昔の誰かがほぼ同じシチュエーションに遭遇して、とっくに解決したり乗り越えたりしているわけで。でも、また同じ壁に当たってしまう。別の人間が同じ課題に、同時に引っかかって、同時に間違っているかもしれない。
なぜこれが起こってしまうのか。感情・行動、心の動きというもののデータが、質的にも量的にも足りていないからだ。情報が足りない。古くは物語の形で、現在ならSNSの呟きで、データは存在するかもしれないけれども、同じデータ形式で、瞬間的に検索できる形で、再利用しやすい情報としての感情・行動データが整備されていない。
「あなたの悩みは誰かが体験し、誰かが乗り越えている」事実は、自分を励まし、課題解決のヒントとなり、同時に自分の唯一性を揺るがす。その心の揺らぎもデータとして次に活かされるだろう。
だから個人的に使うマクロだろ。その人が出す必要があるのは「結果」だけ。その過程を個人的に効率化しているだけ。もともとの話も、マクロ作った人が自分用に作って善意で残してくれたけど首切ったから困った、って話だろ。マクロに文句があるなら使わなければいいだけじゃん。全部元の手作業でやれよ。
個人的に作ったものなら、誰かに提供することも継続的に使うことも想定していない。ただその人の作業が劇的に効率化される。そんなマクロ。視認性が悪くても、変なコードが入っていても問題なかろう。その人しか使わない、他の人は使わないんだから。
データ形式が変わる？ マクロなんだし、データ形式が変われば手直しすればいいだけ。そんなことも想定できないから業務の効率化が進まないんだよ。
マクロを否定しているんだから、誰かが個人的に作ったものはどんなに圧倒的に便利なマクロでも使うなよ。業務中に作られたとしても、そのマクロで手入力より早くなったのなら業務時間の無駄遣いにはならない。その人がやめていくときに残しておく義理もない。残すことを求めるな、残していていても使うなよ。
自衛隊の予約システムは役所，銀行の整理券やファミレスのレジ前に置いてある名前を記入する用紙を電子化したような物．接種会場での本人確認が必須なので受付が捌き切れれば良く，本来はこの仕組みで運用を回せるのかを注視すべき．東京会場の次週分は予約終了した模様．
https://www.mod.go.jp/j/approach/defense/saigai/2020/covid/index.html
※マスコミはその辺ちゃんと取り上げて欲しいし，政府側もそういう説明が必要だった
自衛隊の接種はまだ始まっていない．接種回数の向上に貢献できるかで判断すべきでは．
「戦力の逐次投入」は悪手では．政府としても色々と自前でやり繰りできる体制の方が扱いやすいので自衛隊主体がいいと判断する気持ちは理解できる．自治体が必要な人員を適切に判断できるなら良いんだけど大阪住まいの私には出来ると思えない．そう言えば純粋な疑問なんだけど自衛隊が派遣されて自治体の業務を支援する場合って指揮系統どうなるんでしょう．
受付でチェックされるので入力ミスで予約できないよりは良いのでは．状況によっては対象の自治体を変更することもあると考えると緩いチェックも選択肢のひとつ．その辺の運用まで詰めてシステムを構築するのは結構大変．
65歳未満でも問題無いのは自治体コードの考え方と同じでは．不正な日付は私が試した際(予約までは確定せず)はエラーなったので修正されたんでしょうか．不正な日付で登録できたというソースは発見できていないですが．
個人情報にならないとしても各自治体と調整してデータを受け取る運用，業務フローを確立する必要がある．データの連携ができれば良いかもしれないが出来ないとしても何度も書くけど「受付で捌ければ良い」のであって必須ではない．「個人情報は氏名・住所・生年月日・電話番号の4点セット」は明らかに間違い．
5/16時点の高齢者累計接種回数は東京で約7,5000，大阪で約4,4000なんで1日1.5~2万は大した数でしょう．
https://www.kantei.go.jp/jp/headline/kansensho/vaccine.html
気になるなら自分で調べると良いよ．
VRSは各自治体がマイナンバーなどを含む個人情報をアップロードしている．自治体は自身の管理する住基台帳の分しか参照出来ないようになっている模様．VRSと連携すればいいじゃんとか言いだしそうな気がするので述べておくけどVRSへの反映が遅れたりそもそも自治体ではなく都道府県で優先して接種した場合はそっちに照会かけないと登録されないので完全なデータではないよ．GW明けで今月中に対応しろと言われたら泣く．
GW明けで今月中に対応しろと言われたら泣く．自治体と言っても規模や運用は異なっていて使っているシステムもデータ形式もバラバラ．人口数千〜数万人規模の自治体と人口百万人規模だと必要とされる要件も異なります．人口少ないならそもそも予約いらないし．
他のシステムとやりとりするデータのデータ形式やデータの項目を先に決めさせてくれよ。
設定ファイルにどういう設定項目を追加するかを先に決めさせてくれよ。
これらが決まったあとに、決まった仕様に従ってプログラムを作るのがプログラマだよ
誰も見てねえだろうからここでロバの耳する。
日本語扱う行政機関向けDBで漢字扱うについて、汎用機時代、IBM/日立/富士通が引っ張ってたのがいわゆるラックサーバの時代になってIBMと富士通が少し引っ込んでMSとSun(現オラクル)がクライアント表示やos絡みで関わってくるようになり、プライベートクラウドでの処理前提になってきたとこでOSとDBエンジン、あと電子文書対応って点で富士ゼロックスとアドビが加わって『外字死んで欲しい』に至ってんだと認識してます。
日本の縦書き法文のレイアウトにつおいジャストシステムがキーエンスに売られる前に前述のコンプレックスに参加してたこと、ユーザがデータ形式を意識しなくていい電子文書フォーマットを確立したアドビが加わった、これで前世紀末に始まった外字無くして文字化けなくそうという文字基盤が成立したわけですが、IVS/IVDでやるって決まってDBエンジンもクライアントOSも対応してんのに10年放置されて今に至るんですわ。
MSなんか「もう知らん」言ってるわけで、今後感染症対策としての電子文書交換とかって話、どうやってやれってんですかMS明朝マンセーな連中にIPAmj明朝使えって言ったらうちの役所での規定フォントじゃねえとか本気で死ねよだからイントラネット内に.localでサーバ建てるとかできるんだよなそりゃ鯖トラブル原因なんて不明言われるわいい加減にしろっての
・プログラムによる既存業務の効率化は目に見え易いので、非効率だった多数の人材と自分が匹敵する能力を持っていると勘違いしやすい点。
・オブジェクト指向やプログラミング自体に事象の抽象化や細分化、項目化といった思考が必要で、物事の数学的把握が必要な点。
・効率化によって職を失う人間はこの先も増えるが、自分達の仕事は減らないだろうという漠然とした思い込み。
・定量的、数学的把握は説明がしやすく、業務やプレゼンへの応用は楽だが、数値から漏れた部分や把握できないイレギュラーは無視しがちである点。
４つ目は敢えて言うなら文系の素養が必要で、これを持っている人間が一流。プログラムにできない（し辛い）部分を把握するプログラマーは自分の仕事の無意味さを認める事になるが、これを抱えたまま仕事をするのはメンタルの面からも大変。他に挙げるとすれば、専門用語が多く仲間内で親交をする傾向が高いので外部からの目に気付き辛い点、一種の官僚化だろうか。
それから６つ目(笑)と言ってもいいかもしれないが、プログラムその物の社会的意義まで頭の回っていない人間が多い印象はある。業務効率化による収益増は当然、自分の給料に反映されるが、そこから漏れた部分の責をプログラマは問われない。
一例を挙げれば、（文書に限り）郵便事業が縮小による情報伝達の効率化という恩恵は万人が受け、効率化に伴う収益は電子化業者が郵便事業者と分け合ってきたろうと推測されるが、電子化業務従事者は封書や葉書の印刷業者や納品業者、インク製造業や製紙業界までに頭を回す事が出来ない。もっと言えばパルプの精製や原料の輸出入にも関わり、産業としてはまさしく革命が起きていると言っても良いが、それを自分の仕事に係わる物だと捉えているプログラマーはまずいまい。
負の側面として電子文書は膨大な労力をかけてフォントや外字の整理を今も強いられ、ファイルフォーマットや送受信データ形式の細かな不整合を放置したまま進んできたが、それに関して電子化業務側からの社会への問いかけといった視点はなきに等しい。加えて、数値化不能な（文書に限る）郵便業務の益は、配達員と顧客のコミュニケーションや地域事情の把握、高齢者福祉に関わる面にまで及ぶのであり、それをモニターの前にいるプログラマが担うのは不可能である。
二行目に関しては特権意識とは全く関係がなく、言語による思考を行っていない人間に言語で話しかけるのが間違っているのではないか、と考える。
絵描きや作曲家の例を挙げれば理解は容易である。これらは頭を使っている、いない、の問題ではなく使い方が違うだけの話だ。
そもそも、頭を使うの対義は身体を使う、になるのかしれんが、ヒトがどちらか一方だけを使うなど有り得ないし、その活動の比重が脳に偏っていれば偉い、と言うのは思い上がりである。
アニメがはじまったついでにPC98版 YU-NOのメッセージファイルフォーマットを解析してみた。
"*.MES"
+0 offset(2byte)
+2 辞書データ(offset - 2 byte) sjis2byte文字のつめあわせ
| 0x06 | 次の0x06までのデータがファイル名 |
| 0x11 | 入力待ち |
| 0xC0-0xCF,0x60-0x7F | 0x20を足して次の1byteを追加すればsjisの1文字になる |
| 0xD0-0xFF | 0xD0を引いて2倍した数値に該当する辞書データの1文字 |
| 0x133003 | 主人公の名前に置き換え |
他にもコマンドいろいろあるみたい
約700年前に書かれた玉水物語。
その内容は、美しい姫君を目にして心奪われた狐が、そばにいたいと願うあまり、きれいな娘に化け女中として仕えるというもの。
Twitterのトレンドにも乗ったように、この物語を百合と判断する人は多くいて、市民権を得はじめた百合という概念によかったねと微笑ましい思いがする。
男女の間では成立し得ない、女の子どうしだから成り立つ特別な関係を求めるのに、時代は関係ないのだということを、どっかの大学教授はセンター試験に取り上げることで、すっかり忘れていた日本人に思い出させてくれたのだ。
ところで狐の性別は明示されてないが、姫に一目惚れしてまず男性に化けようとするあたり、おそらく男なのだろう。このことについての会話を探すと、この玉水(狐が化けた女の子)はTS娘だ、いやそうではなく男の娘だ、という二つの派閥に大きく分かれているように見える。
だが我々はもはや一昨年までの我々ではなく、我々の手元にはもう一つの概念があってしかるべきはずだ。
かわいい美少女といちゃいちゃしたい。その思いが彼(狐)を美少女へと変えた。たしかに、性別も年齢も違う少女になれるなんてことは現実にありはしないと思うだろう。むろん室町においてさえも、物語の中で、しかも狐が妖術を使うという手段をもってしか想定し得なかった。
可能なんだ。
技術の進歩は、数百年前のSFとすら捉えられていなかった魔法を現実のものとなした。我々は、美少女に受肉することができる。
この狐のように。バーチャルだけど。
機械学習の爆進による画像認識や音声認識の高速、安定、低価格化。からのfacerigやリップシンクの一般化。またMMD界隈を中心に連綿と蓄積されてきた、高品質なモデル制作ノウハウ。MMOでSNSで受け継がれてきたアバター文化。もはや当たり前のように感じるマシンの処理速度の継続的な向上。そして、全てを飲み込み軋轢を生みつつ成長する中心にあるVRChat。セカンドライフの頃とは時代が一つ違う。なんと素晴らしい世界ではないか。
まだ、インターネットを見渡してもバ美肉について触れている人は多くはない。そもそもバ美肉と呼称すること自体が最善かも分からない。しかし確実に技術は進歩していて、ちょっといいマシンが手元にあるならば、美少女になるのに必要な環境はすでに整っていると言えてしまう。モデリングアシストソフトも充実してきて、極め付けでVRMというデータ形式も作られた。処理能力の限界により今はセルルックが主だけれど、そのうちSaya並みのモデルにさえリアルタイムで反映できると信じている。
誰でも受肉できる時は近づいた。
バーチャルYouTuberは確実に認知度を上げてきていて、リアルタイムで動く3Dモデルに世間は慣れてきている。そして既存の生身ユーチューバーとパイを奪い合いながら、その一部は広義のアイドルとして活動していくのだろう。アイドルがいれば、人が集まる。近づくために受肉する人もきっと多く出てくる。
どうせそのうちみんな受肉するのですよ。そう、みんな美少女になればいい。いんや、なってください、なりましょう。私はそんな世界が見たい。さあさあなたもいざ受肉。
香典帳というのは、お葬式の時の香典を誰から何円もらったかを一冊の帳面に記したものだ。
古くは近世期のものもあるが、私の仕事場は北海道なので、近代以降の香典帳を主に集めている。
集めているのは、正確に言うと香典帳だけではない。
香典の他に、葬式で必要なものを一式記してその代金をまとめた買物帳や、お布施を払った際の布施帳なども付随することが多い。
どうしてこういうものを集めるのかというと、物価がよく解るからだ。
人の死というのは今も昔も絶え間なく続く。
だからそれに際しての香典や、調達物資は、物価の移り変わりの物差しとして極めて優秀なのだ。
昔は、コメが物価の指標になっていた。高度経済成長期以降、食料の多様化により、コメという物差しはぐにゃぐにゃとあやふやなものになってしまった。
他の、価値があると考えられてきた指標すらそうだった。貨幣で買える貨幣も横行した。
だが、未だ死ぬことは、医学が発展したとは言え平等だ。共同体があれほど変質したとしても、寺なり神社なり教会なりで、古墳時代とさして変わらない営みが続いている。
今日は、古い家の仏壇に入っていた香典帳を見た。昔ながらの折り紙状の和紙の帳面だ。9才で死んだ男の子のものがあった。尋常小学校の同級生一同で香典が出されていた。
親族（子孫）からいただいた付随データを網膜上にダウンロードする。昭和11年に腸チフスで死んだのだという。
昨日は、古いＨＤＤに保存されたpdfの香典帳を見た。元々はエクセルというデータ形式らしい。94才で死んだ女に、101才の姉が香典を出していた。
これも親族からの付随データが功を奏して判明したもの。平成29年の香典帳。死因は老衰。小学校教諭を長く務めた勉強熱心な女で、この時代にしては香典が多い。
香典システムから物価や人的ネットワークを構築するのはよい手法だが、そもそも香典を出さない葬式（家族葬や新しい宗教観に基づく葬式）の形態が増えたことによる影響はどう考えているのか？
葬式に必要な物品を葬儀会社の一元化して調達する影響はどう考えているのか？ いずれも、鋭くも有り些末な指摘とも言える。
{ 'transaction':[ 'key':'some_token_like_SHA-2', 'descriiption': 'bar', 'from_wallet': 1234567890, 'to_wallet': 0987654321, 'total_amount': 9999999999999, 'tax_amount': 999999999999, 'timestamp': yyyymmddhhmmss ] }
https://anond.hatelabo.jp/20190128220133
少し前に最近話題のバーチャルのじゃロリおじさんがMMD界隈に叩かれてたの思い出したから書く。
まず最初に、MMDで作られた映像やMMD映像の作家自体を貶すつもりはないとだけ言っておくし、破壊が言い過ぎならガラパゴス化と言い換えてもいいかもしれない。
日本で一番影響力のある（あった）動画サイトといえばニコニコ動画だと思うんだが、ニコニコでは「3DCGのキャラクタアニメーション ＝ MMD」という図式が定着してしまった。だからプロが高いソフトで作ったような商業案件っぽい動画にも「MMDでこんなことできるんだスゲー」「これMMDじゃねえよ」みたいなコメントがよく付いてる。
それゆえ、3Dのキャラクターが歌って踊る動画だとかドラマみたいなものを観たいときに見るタグは「MikuMikuDance」になってしまう。BlenderだったりUnityだったり、あるいはCINEMA4DとかMayaみたいなガチガチに3DCGをやるツールで作られた動画はそもそも検索にヒットしない。
なんだかんだでネットで動画を公開する場合、再生数がモチベになるわけだからこれは致命的だ。
動画投稿者が再生数を欲しがるように、モデルデータの作者はモデルを使ってもらいたいのである。だから作者も基本的にMMD向けにしかデータを作らない。
魅力的なMMD向けデータを他のソフトで利用したい場合はインポートする必要があるわけだが、インポートしても正常に扱えないものが発生する。obj形式などで配布されたらどれだけのソフトで利用できたことだろうか。
そんなにMMDが有利なら、MMDで作ればいいじゃないか。そう思っていた時期が私にもあった。
死ぬほど不便だ。冗談じゃなく過去の遺物でしかない。Blenderなど一般的な3DCGツールの大半では、モデリングとアニメーションが1つのソフトで完結する。
もちろんモデリング向きなソフトとアニメーション向きなソフトのような分化は生じているから、ソフトを使い分けることもある。それでも、アニメーションを作るソフトでモデルデータのポリゴンをいじることができる。
一方、MMDはモデルデータを読み込んでアニメを付けるためのソフトだ。他の人のモデルを借りてくるなら手軽だが、自分でモデルから触リたい場合（通常の3DCG制作だとそうなることが多い）には非常に不便になる。モデルデータはMetasequoiaあたりのソフトで作成し、それをMMD用のモデル作成ツール「PMX Editor」に読み込む。そしてPMX Editor上でボーンを仕込んでエクスポートし、そのデータをMMDに読み込ませる。
一回やってみると分かるが、アニメーション作成中にモデルデータを修正したくなったらその手順をもう一度踏む必要がある。たった一箇所の色を変える作業でさえ、だ。
また、一般的な3DCGツールでは「レンダラー」というものが存在する。光や反射など物理な現象をシミュレートして通じて写実的な画を出したり、あるいは物理現象を捨象してモデルデータの境界線だけを抽出し、セルアニメ風の画を出したりといったこともできる。3DCGツールから出力される画像や映像の質はレンダラーが握っていると言っても過言ではない。
一方でMMDはDirectXが映し出す低品質な画像しか出力できない。2000年代のPC用ゲームがリアルタイムレンダリングしていたような品質である。
死ぬほど不便だがユーザーは多いとなると、ユーザーの中に存在する野良の開発者が改良を加え始めてもおかしくない。実際、何度か名前を出しているBlenderの方はオープンソースであるから、世界中の有志によってどんどん機能が向上してきた。
一方、MMDはこれほど知名度と影響力を誇るソフトウェアなのに完全にクローズドソースだ。MMD本体がクローズドならともかく、MMDのデータ形式であるPMDの仕様も元々はクローズドだったのである。現在はPMXという後継の形式が主流だが、これはMMD開発者ではない第三者（PMX Editorの開発者）が提案し、MMD側がこれを取り込んだものである。
現在、MMDの不便な点を補うような関連ツールも多数存在する。しかし、それらは開発者が多大な努力をして解析した結果である。
明らかに不健全なコミュニティだと思うのだが、それを批判する雰囲気はMMD界隈に見られない。作者である樋口M氏の姿勢を批判するMMDerは居ない。年齢層が低いこともあってか、過度に神格化されているようにすら思う。MMDを批判したのじゃロリおじさん氏が叩かれたのもそれのせいだ。
樋口M氏からすると、趣味で作ったソフトウェアがここまで大きな影響力を持つとは思わなかったのだろう。とはいえ、趣味で支えられる領域はとうの昔に超えているのだし、ソースを公開してコミュニティに委ねてもよかったのではなかろうか。
これほど多数のモデルデータが公開されたり、PMXが提案されたりといった現状を見て、作者自身が一番コミュニティの力を実感しているはずなのだから。
もちろん、MMDが3DCGへの参入障壁を下げたのは事実だ。Blenderは無料だよなんて言ったところであんなに難しそうなソフトを使ってみようなんて思う人間は少ないはずだ。そういう点ではフリーのモデルを読み込ませたり、フリーのモーションを読みこませるだけでアニメーションが作成できるMMDは画期的な存在である。
ただ、裾野を広げた存在に日本の3DCGは縛られすぎていると思う。例えるなら、インスタントラーメンのせいでラーメン店が続々と潰れていっているという感じだろうか。開発者の人には、「Scratch」が幅を利かせていると例える方がいいかもしれない。
MMDがオープンになって機能を大幅に向上させ、コミュニティベースの膨大なモデルデータを活かしてBlenderや商用ツールを追撃するような未来も面白いと思うが、現実はそうもいかないだろう。
しかし、車輪自体の歴史などについては、曖昧としたまま、あー、はいはい、既にあるライブラリーや関数を使えって言うプログラマーのアレでしょ。
なんだけど、車輪って、舗装された道路が存在したときに、とてつもなく威力を発揮するとあった。
（まー、鉄道におけるレールのような話か。デコボコ道だと、いまいち車輪付きでも、その便利さを利用しきれないってことだった。キャタピラってもんが、あるが。）
中国やローマの皇帝が、「道」・「道幅」・「水はけの良い道」について規格の統一をさせたってのは歴史上画期的なこととして歴史の教科書書いてあるが、大事みたいだね。
今の日本ならば、アスファルトで舗装された高速道路のような片側二車線の道路と、田舎の砂利道や住宅街の入り組んだ細い道とでの自動車が出せるスピードを考えて見たらいいだろう。
似たようなこと、今、流行のビッグデータとか人工知能・コンピュータの世界に改めて、考えてみたい。
人工知能が利用しやすい形、あるいは、プログラミングがなされやすいフォーマットでの
データ形式で保存されることが、期待されているようだ。
囲碁の世界では、棋譜が残されていて、そこから、人工知能に自己学習をさせた。
適切なフォーマットへと変換された後でだろうが。
（アバウトな理解だけれど、もちろん、始めは人間が教えて、その後に人工知能vs人工知能でも、自己学習をしていたようだが。）
これから、パソコンが理解しやすい形に、データが格納されていくと、
本当に、あっという間に、あらゆる仕事がかわるんだろーなと。
人工知能による翻訳とか期待されているが、これからも、単純作業よりも、少し複雑なルールの仕事は人口知能に置き換わっていくのかーってことを、
Googleカレンダーに『区役所 マイナンバー』とあった。
私（……はて？）
東武東上線で区役所へ向かいながら、私は記憶をまさぐる。最近、物忘れが激しい。
夢見る季節はとうに越え、気づけばサーティーをアラウンドするオッサンになってしまった。
列車内のオッサンたちを見る。覇気がない。きっと私も死んだ顔をしているのだろう。
……そうだ。顔写真付きマイナンバーカードを区役所で受け取るのだ。
何人のエンジニアが落命したのだろうと思いながら、ネットで受け取り予約をした。死んだオッサンの顔で思い出したゾ。
区役所の窓口は老人ばかりだった。
酷い混雑。職員と臨時パートと思しきオバちゃんがてんてこ舞いである。
予約せずに来る老人。情報漏えいが不安だとキレる老人。通知のハガキなんて知らないとキレる老人。このシステムはまだエンジニアの血を吸うだろう。
小役人（こいつもオッサンである）が突き出した写真付きマイナンバーカードには、見知らぬ兄ちゃんの顔が貼り付いている。
私（だ、誰だ、お前は！）
薄ピンク色の脳がスカスカになりつつある私は、兄ちゃんの正体を推理する。
幼さが残る目元、血色の良い頬、フッサフサな頭髪。
まるで東京に心を壊される（NOT 比喩）前の、上京を控えた初心なカッペではないか。
私（……私だ）
私「わ、私だぁ！」
イケないアンチエイジングではあるものの、嘘ではない。写真は私である。少しばかり時を駆け過ぎただけだ。
増長した役人は、私が差し出した運転免許証（今の顔）もスキャナに。
老人たちの前で公開処刑された私に、ゴミを見るような眼差しを向ける小役人。同じオッサンである私を憐れんでいるようにも見えた。
小役人「これ、書いてな」
渡された書類は始末書……ではなく、登録抹消・再申請の用紙だった。データベースの若い私を一度ポアし、オッサンの私を申告しろとのこと。
再申請用紙には『3.5cm×4.5cm』のオッサンの顔写真を貼らなければならない。
……思い出したゾ（2回目）
私は物持ちが良い。スピード写真のストックは中学生の自分もとい時分から大切にとってある。
そして『3.5cm×4.5cm』という中途半端なサイズのスピード写真が、高校生の時のそれしかなかったのだ。私は何の躊躇いもなく、無慈悲に""若い兄ちゃん""を郵送した。
全ての本を電子化して、電子データを国立電子図書館で管理して、ネット経由で貸し出せばいい。
データ形式はpdf。DRMはかけない。（図書館で借りた本をコピーできないなんて事は無いわけだし）
未返却のまま除籍される図書館の本は全国でものすごい量に登る。そんな未返却問題が一斉に解決する。
図書館員の憂鬱な仕事の一つにその督促業務がある。それも一切無くなる。
また、本が破損したとか、汚れたとか、そういうことが一切起きない。
またそれに伴い、貴重な閉架図書もガンガン貸し出せるし、高額な本も余裕で貸し出しOKとなる。
図書館の大きな役割の一つに、知を広く市民に広めるというものがある。
だが、図書館は基本日中しか開いていない。サラリーマンは土日しか知に触れられない。
多くの図書館は月曜日が定休だ。月曜日は市民は知に触れられない。
人気のある本は何百人も貸出を待っている。待っている間はその本には触れられない。
図書館が遠くにある人は、図書館までわざわざ出向かないと知に触れられない。
運転免許が無かったら？ 怪我をしていたら？ 悪天候だったら？
そんな問題も一気に解決だ。
そして何より、「借りたいと思っていた本が図書館にない」なんてことがなくなる。
借りたい本が具体的に決まってるなら、他のどこよりも、この国立電子図書館にある確率が高い。
当然、借りたいと思い立ったらすぐに借りられる。
図書館の大きな役割の一つに、文化や知識の保存というものがある。
電子図書館ができれば、全国の図書館で同じ本を買う必要がなくなる。ここでまず購入予算が大幅に浮く。
そして、物理的な空間も一切不要となる。棚も不要。そもそも図書館という建物が不要になる。
全国にある公共図書館は3200以上。これらのほとんどがいらなくなるのだ。司書も大いに減らせる。
（都道府県に一つ中央図書館くらいは残しておくべきだとは思うが）
ただ、これまで日本全国で図書館に使われていた予算のうち相当な部分が浮くことになるのは間違いない。
そのお金で、世界中の本、地方の零細出版社の本、昔の本などをガンガン電子化していこう。
知識の森はどんどん豊かになる。
CDやDVD（やBD）も、一部は図書館にあり、貸し出されている。
だがそんな制約ももう無くなる。全国に一つだけの国立電子図書館で購入すればいいからだ。
これでまた知識の森が豊かになる。
が、これで彼ら彼女らは本来業務のレファレンスサービスだけに特化できるようになる。
Yahoo!知恵袋みたいな形でレファレンス履歴を蓄積していけば、優秀な司書も分かるようになるだろう。
そのうち、利用者がレファレンス履歴を検索すれば望む本にたどり着けることも多くなるはず。
「本来のレファレンス業務がぜんぜんできない」などと嘆いている司書の皆様には、
是非競争原理のなかで切磋琢磨して生き残りを目指していただきたい。
この文章は、「図書館の役割を究極的に考えた場合」の思考実験なので、このあたりはスルー。
http://mikumikuplay.com/boeigun/
「ミクミク防衛軍」はブラウザで簡単に遊べる3Dアクションゲームです。このゲームは前作ユニティちゃんバズーカのオンラインマルチプレイ版です。ゲームのルールは簡単で、バズーカで敵を5匹倒すタイムを競うというものです。プレイヤー複数人で同時プレイすることが出来ます。ゲームのジャンルはサードパーソンシューティングになります。
複数人同時プレイの場合、自分が打とうと思った敵を他のプレイヤーに先に打たれてしまうと、別のプレイヤーの得点になってしまいます。なので、速いタイムを出すためには他のプレイヤーより先に敵にバズーカを命中させることが重要です。いかにして他のプレイヤーより早く敵に弾を当てるか？それを競うゲームとなっています。
ゲームクリアタイムはサーバに保存され、ランキングをゲーム画面やWebサイトで確認することが出来ます。
ゲームの開発は個人で行いました。
このゲームは多数の3Dモデル、音声ファイルを使ったオンラインマルチプレイ3Dアクションゲームです。
このようなゲームを個人で開発するのは一般的に難しいと考えられがちです。
1. 3Dゲームの開発には高度なプログラミングや数学の知識が必要？
3. オンラインマルチプレイを実装するのは難しい、サーバを用意するのも大変？
私は以前から3Dゲームの開発ツールUnityを使っていたので、1の問題は解決されていました。Unityを使うと高度なプログラミングや数学の知識がなくても3Dゲームを作ることが出来ます。
ゲームに使う3Dモデル、音声ファイルの素材もUnityのアセットストアやMMDモデル、無料素材を公開しているWebサイトで調達することが出来たので2も解決しました。今回使わせていただいた素材やオープンソースソフトウェアは以下のURLに一覧しています。
http://mikumikuplay.com/boeigun/page/thanks
初音ミクなどのMMDモデルをUnityで使用する際にはデータ形式をUnityで扱える形式に変換する必要があるのですが、MMD4Mecanimというツールを使うことで簡単に変換することが出来ました。
3のオンラインマルチプレイ実装ですが、Photon Cloudというクラウドサービスを使うことで簡単に実装することが出来ました。Photon Cloudはオンラインマルチプレイのサーバー機能とクライアントSDKを提供しています。これらをUnityから使用することで驚くほど簡単にオンラインマルチプレイゲームを実装することが出来ました。どれくらい簡単かというとPhoton Cloudにアカウント登録してAppIDを取得し、アセットストアからSDKをダウンロードしてサンプルシーンを起動するだけでマルチプレイゲームが動作しました。このサンプルを元にして機能を追加していき、このミクミク防衛軍が完成しました。
開発作業はニコニコ生放送で配信していました。するとリスナーがゲームの機能やデザインについてのアイデアをコメントしてくれたりして捗りました。
http://www.nicovideo.jp/watch/sm24672370
https://www.youtube.com/watch?v=z5T_SaMFJbA&feature=youtu.be
ということで、良かったらプレイして感想とか書いてくれると嬉しいです。
