2018年10月6日土曜日

Howto eject usb media like "Safely Remove Drive" from CLI

gio mount --eject /media/nekomatu/$(drive-name)

I use Ubuntu 18.04(Bionic).
Ubuntu is doing mount automatically when USB removal media is connected PC.It's convinient. and un-mount is easy. only one-click eject button from filer. so I want to eject like filer from CLI.



2018年10月4日木曜日

OSSの長期利用とメンテナンス に参加した

本ブログは個人のものであり、所属する団体の意見等では一切ございません。
というか、参加自体も仕事じゃなくて個人ですし。私はプラント系の人ではないので推測が多分に含まれています。
間違っていたりしたらこっそり教えてください。いつもにまして脳内ダンプ・ポエム感。

OSSの長期利用とメンテナンス







最初のきっかけは、とある人のCIPに対するツイートを見てうーん、CIPの人がそんな事を考えていないはずがないけどどうなってるんだろー?と気になったからでした。それだったら会場提供するよ的な話になって20人近く参加するイベントになっていました。
ガチ勢の方が多くびっくりしました。

CIPというのはLinuxFoundation配下のプロジェクトで、 Civil Infrastructure Platformのことです。社会インフラ向けのLinux・OSSの利用についてやっていこう的なプロジェクトです。プラント系なのでサポートがミニマム10年とからしいです。
https://www.cip-project.org/

CIPの活動の中でLinuxカーネルのSLTS(SuperLongTermSupport)というのがあるのですが、長期に渡ってバージョンを固定化してFixPatchを当て続けるのはどうなのか?みたいなのが最初の問題提起的なものでした。

Civil Infrastructure Platform Announces First Super Long Term Support Kernel at Embedded Linux Conference Europe
Linux4.4を10年はサポートしていくというブログ

理屈上は十分なテストケースとバリデーションを通せれば、カーネルのバージョンをBump-upしても問題ないのではないかという前提があります。古いカーネルにパッチを当て続けることは容易では無いため、これらの工数やお金をテスト等に回すほうが健全ではないのかという発想です。
これに対しては、やはりバリデーションの難しさ・過去のアセット利用等が背景としてあることが述べられました。

例えば、最終的な受け入れテストなどはプラントに入れてから行ったりします。機能安全については第三者機関に出すことなどもあります。このような体制は比較的昔からあるものだという理解が必要です。こういった時、セキュリティパッチだけを当てて影響範囲はこれだけですというレポートの提出で済むか、テストケースが全部通っているのでバージョンのBump-upしますが通じるかというシチュエーションが容易に想像できます。

過去のアセットとは、ソフトウェア資産を想定した私が最近好んで使うタームです。(ルー大柴みたいな表現になっているのは許してほしいです)
つまり、プラントのような規模が大きいシステムを毎回1から作るのは非合理的ですし、機能安全規格をPASSしたモジュールなどがあれば使いまわしたいと考えるのが一般的です。つまり、枯れたコンポーネントを積極的に使う動機があります。しかしながら、弱点もあって設計そのものがモダンではない、テストが不十分であるといった時代的な課題も抱えていることが想定されます。そうすると、バージョニングの固定が現実的な最適解になルノではないかと思われます。
これはプラントに限らずあるある話なような気がしています。

バージョニングの固定が最適解になりがちというのを過去のアセットという観点で述べてみました。もう一点、これを正当化(Justification)している根拠としてはプラント系はEOLがおおよそ定まっているという要素があるのではないかと私は推測しました。端的に言えば設計寿命であり、一度入れたものをノーメンテナンスで壊れるまで使い続けるということはあまり考えにくいです。ですから、メンテナンスサポートも含めて収益でありビジネスになっているのであれば、バージョニングの固定はシンプルな発想です。

ところで、製品寿命は存外自明ではありません。
皆様は「長期使用製品安全表示制度」というのをご存知でしょうか。最近、扇風機などを買うと「設計上の標準使用期間 : 10年」とか書かれているシールが貼られていたりします。どうゆうことかというと、扇風機とかうっかりすると30年ぐらい使い続けたりします。すると、コードやモーターの劣化に起因して火災が発生したりとか出てきたりしたんですよね。これを防ぐために注意喚起情報を付与することが今では行われています。
他にも「補修用性能部品の保有期間」といって、修理に必要なパーツを何年保持しますと表示しているメーカーもあります。(この辺りは法的なものかは未確認)

さてソフトウェアという観点ではどうでしょうか。スマホはプライバシーの塊とも言えるかと思いますが、ソフトウェアのセキュリティ的な安全性は何時までどのように担保されているか考えている人はどれくらいいるでしょうか。
IoTマルウェアのMiraiや監視カメラの初期パスワードアタックなどはかなり有名ですが、どこまでどのようにサポートされるべきなのでしょうか。
ソフトウェアも製品に組み込まれている部品の1つですが、これがクリアリーになっているケースはそこまで多くありません。
スマホの例だと、Googleが出しているブランドのNexus・Pixcelシリーズはセキュリティアップデートの日付を明示しています。一方で、これを認知しているユーザーの割合や、サポート期間を超えて使い続けた場合についてはまだまだ社会的なコンセンサスや認識が無い状況だと認識しています。

目指していきたい方向性

ここから脳内ダンプ。ポエムがさらに深刻になってきます…。とほほ。

主にWeb系でマイクロサービスアーキテクチャという話がありますが、これは組込みとかにも言えるんじゃないかなーと思っています。
コンポーネントを疎結合にというのもあるのですが、もう少しトータルデザインとして。APIやインターフェースを界面として個々の品質や実装については担保されていて入れ換えの自由が効くように。

転換期のつらみ

私の考え方としては、今は転換期のつらみと捉えています。
コンピューターテクノロジーの進化はどの産業よりも変化が早く急速に社会を変化させていきました。ここに、コネクティビティ(ネットワーク)が加わったことにより物理的な制約条件をしばしば突破する強烈なインパクトをもたらしています。現代のソフトウェアは一人では見きれないほどの複雑で非常に高度なものになっていて、しばしばセキュリティ的な問題が含まれ時に狙われるという状況になっています。

高度なソフトウェアを新規でほいほい書けるかというとまだ世の中はそうはなっていないようです。そのために、過去のアセットを使わざる得ない状況があります。ベンチャー企業とか新規参入者はこの辺りが付け入る隙になっていると思います。逆の観点から言うと新規参入障壁とかそういった言葉が出てくる気がしています。

Amazonは元々本の流通をやっていたわけですが、電子書籍を始めちゃうように自分自身で破壊的なイノベーションをしていけるのは相当強いし、やっていかなければいずれか新規参入勢にやられちゃったりするんじゃないかなーと思っています。

終わり。

2018年10月1日月曜日

Yahoo!ジオシティーズ、お世話になりました。






このサービスはわりかし原点かもしれません。年齢がバレる。
ここからHTMLを学びパーミッションや文字化けの洗練を受けたのです。
当時のアップローダはなぜか全部EUCに変換しちゃうとかだったような。もう何も覚えていません。
FFFTPでバイナリモード?アスキーモード?よくわかんないけど、手元のメモ帳で書いたHTMLをアップロードしてはWebブラウザを更新したのです。
ちょっと動いてすごいなってなって、とほほのWWW入門のコードをベースにできることを増やしていったような記憶があります。
当時はフレーム(iframe)とか結構当たり前で、上手に設定してないとどんどん左のメニューが入れ子になっちゃうとか合ったような気がします。
レスポンシブデザインとかなくて、決め打ちなのでレイアウトとかどうなってたんでしょうか。それでも、手元でいい感じに分割されるのが楽しかったです。
わけもわからずキラキラするJavaScriptをコピペしてキャッキャしてたのも懐かしいです。
そこからCGIなるものをがあるとしって、Infoseekに行ってみたり、カウンターなるものを設置してみたり。

そういえば、一緒に初めた友人のページばっかりカウンター回ってジェラシー感じたりもしましたっけ。

小学生だった自分の家にはまだパソコンとかインターネットはなくて、児童館で貸し出してくれるWindows95seとかを触ってたような気がします。
申請書を書けば誰でも使えるのですが、使っているのは自分たちぐらいでした。
そういえば、PCがガリガリガリとHDDの音を立てて起動するのに5分ぐらい待つ。というのも遠い昔の話ですね…。

当時もWebチャットとかお絵かきチャットとかBBSとかFlashとか合ったような気がします。Yahooキッズが懐かしいです。
そういったコミュニケーション系には自分は特にはまらずこの辺りには思い出がないです。

ニフティサーブとかパソコン通信とかは分かりません。
でも、この世界においてはおじさんに一歩足をかけてるんだなとやっぱり実感するのです。

2018年9月21日金曜日

LinuxカーネルにCode of Contactがコミットされた

Subject Linux 4.19-rc4 released, an apology, and a maintainership note
https://lkml.org/lkml/2018/9/16/167
> The one change that stands out and merits mention is the code of conduct addition...

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8a104f8b5867c682d994ffa7a74093c54469c11f

Code of Conduct: Let's revamp it.
The Code of Conflict is not achieving its implicit goal of fostering
civility and the spirit of 'be excellent to each other'. Explicit
guidelines have demonstrated success in other projects and other areas
of the kernel.

Here is a Code of Conduct statement for the wider kernel. It is based
on the Contributor Covenant as described at www.contributor-covenant.org

From this point forward, we should abide by these rules in order to help
make the kernel community a welcoming environment to participate in.



自分にとってはCoCはちょっぴり思い出がありまして、それはUbuntuを使い始めたきっかけの1つです。
私にとってCoCとは、どんなコミュニティでありたいかということを意識付けるものであると思っています。

2018年8月26日日曜日

[ポエム]仕事しながらLinuxカーネルのメインライン化が大変な件。(途中で書くの挫折)

タイトル長すぎて検索でヒットしない予感。ポエムだし、このブログは自分のための備忘録ということになっているので許してください。(言い訳ここまで)

昨日、[ポエム]Linuxカーネルに関する独自コードをメンテナンスに関してという物を書きました。
本記事では、メインライン化の大変さを述べます。次にフォークコスト高すぎ問題について述べます。
先の記事については3行で書くと…
  • Linux(カーネル)といえども、特別なことはなくソフトウェアなので変更をしたくなることがある。機能の追加やバグ修正といったもので一般的なオープンソースソフトウェアと同じである。
  • 作ったソースコード(パッチ)をメインライン化(コミュニティに取り込んでもらってマージしてもらうこと)を基本とするべきであることを経験的に知っている。
  • しかしながら、諸般の事情でメインライン化できないこともあるだろう。大事なことはメインライン化したときのメリット・デメリットは検討することではないだろうか。

みたいな感じです。(雑)
2018年にセルフツッコミを書きたくなってしまう人です。ポエムっぽい。

メインライン化は簡単ではないとは?

まず、メインライン化とは何かという点をクリアにしておきます。
ここでは自分が作ったパッチをコミュニティに送って最終的には取り込んでもらうことを指すことにします。
メインライン化の頓挫と表現した場合は、パッチが取り込んでもらえなかった状況を想像していただければと思います。

話を分かりやすくするため、シナリオ形式で書いてみたいと思います。

シチュエーション

・・・
ここに会社に雇われているプログラマーがいます。名前は勇者といいます。
この会社では現在とある製品の後継機種を設計しており、ハードウェアエンジニアはコスト削減のために部品の一部を変更することにしました。
変更された部品はソフトウェアから制御する必要があるものであるため、ソフトウェアの変更が必要か確認されました。
確認の結果、新しく採用された部品(デバイス)を動作させるために必要なデバイスドライバーが残念ながらLinuxでは提供されていないことが分かりました。
あなたはハードウェアと仕様書を渡され、Linuxで動くようにしてほしいと仕事を依頼されました。
無事にやり遂げ、開発完了したソースコードは1000行程度の簡単なもので収まり、社内の品質テストにも合格しています。

git diff -urn とすることでパッチ形式で出力できる状態です。
・・・

シナリオ1 メインライン化に理解がない。社内的な仕組み・ルールがない。

勇者はメインライン化の必要性があると感じたため、上司に少し工数がもう少し欲しいと相談しました。

No1. 上司「メインライン化って何?」-> 勇者は説明を始めた。
--> でも、上司はピンときておらず困惑している! -> もういいや。

No2. 上司個人にはメインライン化の理解はあるが、会社としての見解がない場合等
「でも、会社の成果物を勝手に出すのは法務部とかに確認が必要そうだなぁ…」 -> もういいや。
「でも、工数は開発と品質テストの分しか確保してないからできないよ。」 -> 勇者は次のプロジェクトへ…
「好きにやったら良いと思うよ、責任は取れないけど。」 -> もういいや。

社内にルールや前例がないと往々にして動けないことがあります。これは正しいことなのですが話が急に大事になってしまい頓挫する例です。
このような場合エンジニアはメンテナンスコストとメインライン化の作業についてPros/Consをとって取りまとめておき、責任者に承認を得るのがベターだと思われます。(つまり、現場レベルでは少なくとも責務を果たしているという状態にしておく)
ただし、メインライン化とはなんぞや?から始まる場合はPros/Consシートの価値を理解することができない環境ということになるのでつらいですね。解は仲間を頑張って見つけて機運を高めるように頑張ってみる、上司を説得して業務課題化する、俺が上司だ!、理解ある会社に転職してしまうなどがあります。
ちなみに、ここでは勇者がメインライン化の必要性に気付いている前提となっています。もしかすると、メインライン化という意識すらない可能性がありますがががが…(割愛)

シナリオ2 メインライン化の作業が楽ではない

皆さんは、最初のスタート地点はここだと思われたかと思います。実際にはシナリオ1で頓挫している現場も多数あるように感じています。
スタートラインに立てているならば、なんとかなるでしょう。 - fin-

さすがにそれでは雑すぎるので、作業の中で頓挫してしまう例を上げてみたいと思います。

No1.パッチをどこにどうすれば取り込んでもらえるか分からない。
-> 最初は誰しもがそうですよね。社内にナレッジがある場合は先輩に聞くことで解決できますが、ない場合は調べる他ありません。
ちなみに、ドライバーを新規作成した場合はサブシステムのMLなどに投稿するのですが、これだけで1つの記事が出来上がってしまうので割愛します。

No2.パッチの品質が悪い。
期待した動作するコードが必ずしも、優れたパッチとは限りません。
パッチをMLに投稿してから指摘されることも多いです。むしろ、一発で通すことを目指すというよりレビューを受けて仕上げていく感覚に近いです。
よくある指摘事項は、パッチをもっと分割して。パッチのdiscriptionを充実させて。このアプローチは微妙だからこうしてくれなどがあります。

このリファクタリング作業はこのようにレビューを受けたりするため、そこそこ絶対的に時間がかかることが多いです。そんなに手間かかるならやめたら?という横槍が入ることもあるでしょう。
またQAコストがペイしないと判断されて頓挫してしまうことがあります。(製品に組み込んでいる場合は大抵結合テストが必要だからです。)
本来ならば、メインライン化の作業と製品作りなどは分離して置く必要があるのですが、片手間にどうぞという形だったりする場合は、このようなことが発生することがあるようです。

まだまだあるぞ、現場のあるある。

そもそも、カーネルってバニラの最新のLTSが使えるわけではない。SoCに付随してくるLSPを使わざる得ない。
このLSP、何個前のバージョンがベースですか…。なんですか、この独自パッチにまみれたカーネルは。いや、パッチならまだいいけど、Linuxカーネルのお作法とかの概念が存在しねぇ!?おれおれヘルパー関数でサブシステム越境してやがるだと!!なぜ、そこにフック関数が…etc

この辺はx86_64はあんまりないかも知れませんが、ARM SoCだとにゃーんって感じなんですよねー。

力尽きた

書き出すとシナリオがいっぱいあることに気付き、この辺りで書くのに疲れました…。(パタリ)
アップストリーム化の作業する上で、バニラのヘッドが使える環境じゃないと大変とかなんか他にもいろいろありそうなのですが…。
この辺誰かもうまとめるような気がするのですが、意外に無いのかな。

2018年8月18日土曜日

今日から始めるVTuberワークショップ #02 に参加した #vtuberjustdoit

今日から始めるVTuberワークショップ #02(PANORA×デジタルハリウッド大学大学院)

<お約束>内容には正確さをおいて頑張って書いているつもりですが、個人の偏見等が含まれています。というか、このブログは私の備忘録です。間違っている点などがございましたら、何卒ご容赦ください。また、指摘等についてはツイッター等でしていただければ幸いでございます。

参加の動機

可愛い女の子になることは一般的に難しいと思われていたのですが、本年2018年、ついに誰でもなれる可能性がいよいよ見えてきました。
それで、改めてVRや界隈のトピック2018年7月頭ぐらいから調べたりしていました。
その後、ちょっと仕事を辞めたりして時間ができたので調べたりやってみたりとかをしていたという感じになります。
知見や思うところが固まってきてたところだったので、他の人と交流してみたいと思い参加してみました。

以下は更にそのバックグランドになります。書いてみたら長くなってしまいました。
ワークショップの内容は更にそのしたに記載があるので適宜読み飛ばしてください。
他の方が書いてる記事とかへのリンクでよかったんじゃないかと後悔していますが作文してしまったので晒しておきます。自分なりの捉えている理解なのでまぁ良いでしょう。

自己紹介

知り合いの方からは異口同音に、お前VTuberになりたかったんか!?と言われそうですが、違います。
私はマグロナさんのファンであるのは事実ですが、一応ソフトウェアエンジニアのような仕事をやっている人で、テクノロジー方面に関心がある人です。また、目の前で広がっているブレイクスルーに衝撃を受け世界が変わりそうな予感を持っていて関心を持ってウオッチしておきたいと思っている人です。
絵も全く描けないし、シナリオスクリプト書くこともできないし、モデリングができるわけでもなく、女の子の声が出せるわけでもない人ですが、やってみると、声を出してみる楽しさ、アバターを被ってみることの楽しさを知った人です。
具体的にはFaceRigをセットアップし、恋声で遊んだ経験があります。FaceRig with Live2D と 恋声 を使ってみた

ボイス(声)のブレイクスルー マグロナショックについて

私がこの界隈に興味を持ったトリガーは、絵描きさんのVTuberでマグロナさんです。これに衝撃を受けて最近あれこれしていました。
この衝撃を自分は勝手にマグロナショックと呼称しています。
ちなみにまぐろなちゃんねるの初回投稿日は2018/06/07ということなので、比較的最近の話ということになります。

マグロナショックを文章でいざ述べよというと難しいのですが、キャラクターがとても可愛いが演者(中の人)はおじさんというというものです。
可愛いの構成とは容姿・声・振る舞い(リアクション)などがあると思われます。
マグロナさんはどの構成要素も可愛いのですが、ブレイクスルーの観点では声にあります。
声にはボイスチェンジャーが使われているのですが、そう言われても分からないほど自然な可愛い声をされています。
ボイスチェンジャーは古より存在したのですが、いかにも声質が機械っぽい、ロボットっぽい感じになってしまうということでメインストリームにはなっていませんでした。
ところが投稿された動画はあまりに自然で何が起きているんだ衝撃を与えました。
演者のukyo_rstさんの積極的な情報公開によって、ミックスボイス(高い声という認識ぐらい)でイントネーションを女性化したものをチェンジャーに入力すると極めて自然な変換結果が得られるということが広く知られることとなりました。
このムーブメントを下支えしているものにはニコニコ動画などで両声類(地声と女の子の声が出せるという意味の造語です)といった流行りがあったとかありそうなのですが、割愛します。

ボディ(容姿)のブレイクスルー ねこますショックについて

実は見た目と振る舞いが可愛ければ声は可愛くなくても良いんだよ!というブレイクスルーを起こしたのが、のじゃロリおじさんこと、ねこますさんという認識があります。これも私は勝手にねこますショックと呼称しています。
ねこますショックのトリガーはにゃるらさんの「キミは「バーチャルのじゃロリ狐娘Youtuberおじさん」を知っているか!?」というブログ記事がバズったことにあることは疑いないでしょう。この記事は2017/12/05に投稿されています。
紹介の都合上、時系列が反転していますが、容姿と振る舞いが可愛ければおじさんでもありやんけ!という開拓地が開かれた矢先に、声だっていけるやんけ!となったのがイマココです。

ワークショップの様子

やっと本題です。当日の内容の概略は次のとおりです。
参加人数はざっと観た感じ60~80人ちょっとぐらい?ワークショップは3つのセッションがあったのですがきれいに別れて20名ずつぐらいになりました。
人数は多すぎ少なすぎずちょうど良かったです。また、一般参加には4500円の受講料が必要なため、それなりの人しかいなかったというのも良かった点です。

  • 基調講演が45分
  • 元々の枠は30分でしたが、質問タイムを多くとっていただいたため、次の基礎講座が圧縮されました。 結果的には良い判断だったと思いますので、運営柔軟すごい。
  • 基礎講座が15分
  • 駆け足でパーッと。
  • ワークショップ(前半)が90分
  • 私はLive2Dの入門セッションに参加しました。
  • ワークショップ(後半)が90分
  • 通常は前半に続いて後半を受講するのですが、自分のノートPCではLive2Dが動作しないことが判明し、バーチャルキャストのセッションに参加しました。
  • 交流会とブースデモンストレーションが120分(これが目当てだった)
  • 説明では交流会と書かれていましたが、コの字型にブースデモがありそれの話を聞いたりできるようになっていました。 真ん中のスペースでは絵描きさんがさっそくワークショップの内容を試したりしていたり、数名のグループで雑談が行われるなど良い時間が流れていました。

基調講演 マグロナさんより

トピックとしては次の3本柱でした。
- virtualに存在になってみたい
- 絵描きが受肉してみて
- 声の出し方

どれも示唆に富んでいて来てよかったです。
印象的なのは会場が生マグロナさんだとなって、独特の緊張感や静けさ、感動に包まれていたことです。人間こうなるのか。

質問タイムもあって、自分も聴きたかったことが伺えて大変良かったです。


印象に残ったこととしては、キャラクターデザイン及びLive2Dで苦労したところは?という質問で、髪と答えられていて、拡大してお披露目がありました。
髪に24レイヤー使って物理演算の設定を調整を繰り返されたそうです。
確かに拡大で拝見すると、大きな髪の他に細かく一つ一つオブジェクトに独立している様子をはっきりと見ることができました。
エクステのようにポイントになっているヘアの束に設定されている… というとわかりやすいかも知れません。

基礎講座 PANORA 広田さんより

ワークショップへの参加率などの調査が行われました。
PANORAさんが書いているVTuberの定義などの説明がありました。
VTuberになるうえで、2Dでいくか、3Dでいくか、機材や配信プラットフォームの組み合わせ等々の概要が説明されました。

ワークショップ 仕組みを学ぼう! はじめてのLive2D 神吉李花さんより



絵が描けないのに参加するという何ともなあれですが、制作フローに関心があったためこのセッションに参加しました。

これはネガティブなコメントだと理解しているのですが、あの内容をはじめての~とか初心者と打つのは、完全初心者が白目をむいてしまう可能性が高そうです…。
セッションの水準としては、チュートリアルのテキストとビデオを一通り確認していることが最低ラインで、少し手を動かしているとなお理解がしやすいという感じでした。その観点では初心者向けともいえなくはないのですが、視聴者の想定というのは難しい話ですね…。
これはあくまでも自分が感じた感想なので、他の参加者がどのように感じられたかは不明です。
とはいえ、公式ドキュメントで分かるレベルを知れても面白さがないので、内容としてはとても良かったものと感じています。
強いていうと、今制作フローの何をやっているか分かりにくかったぐらいです。(90分に詰め込んでるから仕方ないよなぁとも思っていました)


バーチャルキャストとVRMで広がるVTuberの世界 助田徹臣さんより

Webニュースで会社が設立されたというのは知っていたのですが、バーチャルキャストがなんぞやというのを全く知らないで参加しました。
内容としては、実際にバーチャルキャストを使いながら、どんなことができるのか?というデモをしながら解説をするといった感じで進んでいきました。知ってるよーという人からすると物足りなかったかも知れませんが、私にはちょうどよかったです。


バーチャルキャストを使うのがはじめての人を中心に入れ替わりで体験して、私も体験させていただくことができました。
驚いたことが、初めてヘッドセットを被ってコントローラーを握ったのにも関わらず、直感的に空間のオブジェクトや操作ができてしまったことです。
例えば、現実の空間に初めて使うペンがあったとします。我々はそのペンがボールペンだろうが鉛筆だろうが、上手に使うことができます。
VR空間でもこのような認識に近い形でオブジェクトを自然に扱うことができたのには衝撃を受けました。
触覚フィードバックとしてはコントローラのバイブレーションのみでした。

女の子のアバターで試させていただいたのですが、制服を着た美少女のため、下を向くとちゃんと腰のあたりにスカートがあったりします。ミラーで容姿を確認したりできるのですが脳みそが肉体が美少女とすぐに認識します。こわいっ。
アバターを変更してちびキャラになると視点の高さがそのままグッと下がって幼女になることができます。ここで面白いのは肉体的な認識は破綻せず自然にこれまた受肉してしまうということでした。
この辺りの仮想体験を言葉にまだ消化できていないですが、感じるものがありました。

このデモンストレーションにはバーチャルキャストを開発しているインフィニットループさんのあねえるさんがレクチャーしていました。この説明がとてもわかり易かったです。現場では補足を講師が喋るというタッグになっていて完成度が高すぎました。
残念ながら私の時はあねえるさんのボイスシステムにトラブルがあってレクチャーを受けることはできなかったのですが、体験された方は相当なユーザー体験だったようです。



なお、デモンストレーションでハグをする、頭を撫でるといったスキンシップをしてくれたり、したりするのですが、これがかなり気恥ずかしいです。
特にハグは自分は逃げそうになりました。顔が近すぎるんですよね。完全に知らない人にパーソナリティスペースを侵害される気持ちでした。
もうそのレベルで没入する仮想体験ができてしまうところに現実があります。

この体験がメジャーになってない理由はほぼ機材のコストだろうというのが自分の認識となりました。
それなりのPC、20万、トラッカーに20万とかで 予算的には40万程投資が必要だからです。それと広めのお部屋とかね。
40万で割と最高の環境を揃えられるということで、ボーナスニコニコ一括払いができそうな価格帯であると考えるとめちゃくちゃ高い!というわけでもないと思っています。

なお、このユーザー体験のクオリティはVR全部だとは全く思っていなくて、どちらかというとアプリケーション次第であろうと認識しています。
ちょっと思案したところ、恐らくバーチャルキャストというアプリケーションの作り込みが非常に高いものと推定しています。

交流会で講師の方とも意見交換させて頂いたりしてとても刺激的でした。
界隈ではエンジニアや企画者が不足しているとのことなので、黎明期に手を動かして歴史を作っていきたいという人は今がチャンスっぽいです。

バーチャル同人誌頒布と囲み雑談


500円で同人誌を買うと30秒お話したり、写真撮影できるという謎のアイドルの現場が出現しました…。すげぇ。
同人誌が売り切れると囲みで雑談をしたりしました。比較的少人数で対談できたのは非常に刺激になりました。
雑談では終始参加者とマグロナさんのナレッジやバックグランドなどについて伺うことに専念して情報収集に務めさせていただきました。
うざいと感じていた人がいたらごめんなさい。

クローズと二次会

あっという間に19時になってしまったのですが、話足りないと感じてその場で二次会の提案をしてしまいました。
初対面で急に声をかけたのにもかかわらずご一緒して頂き誠にありがとうございました。



運営について

内容と人数感、費用はちょうど良い感じでした。
得られたナレッジの公開可能な範囲等のレギュレーションは簡単で良いので明文化しておいてほしかったです。
ハッシュタグはこれというのもイベントページには書かれていなかったですし。
有償のワークショップの場合、内容の公開範囲は限定されているとかは一般的にあるためです。

まとめ

ボソボソと個人的に調べていたおかげで今回のワークショップを大変有意義に過ごすことができました。
改めて、人生何が役に立つかわからないものだなぁと感じました。



VR界隈やVTuberといったムーブメントがメジャーになるのか、一過性のものに過ぎないのかはまだ確定していないと感じています。
2年後、4年後、10年後と言ったタームでこの辺りがどうなっていくかは非常に興味深いので、これからもゆるふわに関心を持っていきたいと思います。

[ポエム]Linuxカーネルに関する独自コードをメンテナンスに関して

以下の2つの記事を拝読して、私も何か書きたくなったので書いてみます。
重複する部分も多分にありますので、どちらかというと記事の紹介ができれば私は満足です。(言い訳)
@satoru_takeuchiさんのlinuxカーネルに関する独自コードをメンテナンスするコスト
@mhiramat さんのLinuxカーネルの独自パッチのメンテに関する検討メモ

linuxに独自パッチを追加したくなる理由

そもそも、なぜLinuxに手入れをしたくなるのか?というのは存外知られていないような気がしたので書いてみます。
一口にカーネルと言っても、カーネル自身が有している機能が非常に多岐に渡っているためそのモチベーションは実に様々です。
#イメージしやすいコンポーネントだと、ファイルシステム、ネットワークスタック(TCPとかの実装)、デバイスドライバ等々…

とはいえ、カーネルであろうとソフトウェアであり、他のソフトウェアとあまり差はないかと思っています。シンプルに機能を追加したいとかバグってるから直したいといったことがモチベーションになります。
もう少しわかりやすい具体例としてネットワークカード(NIC)のデバイスドライバーを紹介しますと、PCIのIDを通過することで対応するハードウェアを増やすと言った作業などがあります。
次のパッチはネットワークカードのPCI IDを追加しています。細かいところを省略しますが端的には、PCI IDに基づいてどのデバイスドライバーでハンドルするのか決定される感じになります。そのため、既存のドライバーで動くけどIDテーブルに記載がないという時はこうやって書き足すだけで動作することもあります。

[netdrvr] tulip: add pci id - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b25978ef8eb

もう少しビジネスライクな一例を上げてみます。
例えば、ここにSPIで接続するデバイスがあるとしましょう。
このデバイスは他社製品に比べて安価に調達できるため製品の部品に採用しましたが残念ながら、Linuxにはデバイスドライバーがなく新規で書き起こす必要がありました。
#補足 SPIとは比較的簡単に接続できる物理的なシリアルバスの規格のようなものです。シリアル・ペリフェラル・インタフェース(Serial Peripheral Interface, SPI)

作ったパッチをメインライン化しない場合

基本的には作ったものはアップストリームに取り込んでもらう(メインライン化)というのが基本的な考え方になります。
パッチが取り込まれたものが世の中にリリースされると、カーネルバージョン3.xでネットワークカードに対応しましたということになります。

ネットワークカードの例では、PCI IDを追加することでそのカードが利用可能になりました。メインライン化しない理由は作業がめんどくさいといった理由に限られるでしょう。
一方で、新規でドライバーを書き起こした例はどうでしょうか。
このような発想が現場では生まれがちです。
  • 公開したらみんなが使えてしまう。ライバル会社が同じデバイスを採用してコストの優位性を失ってしまうかも知れない。
  • 業務でプログラミングしたものがライバル企業にも使われてしまい彼らは開発コストを負担しないですんでしまうのではないか。

これはある意味間違ってはいないのですが、メインライン化しない場合のコストを検討する必要があります。
この作業が「独自パッチをセルフメンテナンスするか、メインライン化するか検討」、「コストのトレードオフの検討」となります。

メインライン化しない場合のコストやリスクは冒頭に紹介したお二人の記事に詳細に書かれていますのでご参照ください。
ここでは具体的な一例をを紹介します。次のコードはSPI接続のRTC…システムをシャットオフしても時刻を保存しておくためのデバイスドライバーです。

このコードで紹介したい部分はデバイスドライバーの初期化部分です。
ソースコードは下から読むと良いでしょう。
linux4.9.yと新しい方では、module_i2c_driver(rs5c372_driver);で登録を行っています。引数はその上に宣言されている構造体です。
構造体の中身も直感的ですね。

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/rtc/rtc-rs5c372.c?h=linux-4.9.y#n673

古いlinux3.2.yではどうでしょうか?
module_init(rs5c348_init);がそれっぽいです。
引数の関数を読むとreturn i2c_add_driver(&rs5c372_driver);となっており、linux4.9系の構造体をとっていますね。

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/rtc/rtc-rs5c372.c?h=linux-3.2.y#n683

3.2.yは初回リリースが2012年、4.9.yは2016年頃とギャップがありますが、変化の一例を感じて頂けるものと思います。
メインライン化していない場合、こうした変換に追従するためのコストが発生するかも知れません。

リスク・コストを見積もる難しさ

上記のRTCの例は、リリースされた結果を見ているものでしか無いという点に意識を向ける必要があります。
今回紹介したドライバーのコードは元々コンパクトなこともあり変化が見通せる程度の内容でしたが、それを予知することは難しいと考えます。
トレードオフを検討しようにも未来のコストを見積もるのは困難であるという事実があります。

しかしながら、経験の中で我々開発者はメインライン化した方がたいてい良いことを学んでいます。

RTCのドライバーをメインライン化していなかったら、次のようなシナリオが現場では展開されるかも知れません。
・・・・
新しいバージョンに合わせる書き換えのコストは、上のドライバーの場合比較的コンパクトなため簡単に書き換えられそうです。
3.2系から4.9系に移行する場合は許容可能そうなコストです。
一方で、移行ではなく新規採用の場合など3.2系も維持するような場合、3.2系パッチと4.9系パッチの2つが手元に存在することになります。
こうなった場合、何か変更する時はもれなく2つのパッチに修正を行わなければなりません。発生する事故としては、4.9系にはバグ修正したのに、3.2系には取り込み忘れたのでバグが直ってないという例です。
このように、追従コストとは、コードマネジメントを複雑化させるといった見えにくい部分のコストが含まれています。
・・・・

検討してるなら御の字

このコードはこの場しのぎですぐに使われなくなるつもりで書き捨てた。まだあのコードは動いてるらしい。
PoCでダーティなコードを書いてデモを作ったら何故か製品が完成したと誤解された。
とか聞いたりしたことはありませんか?

まぁ上の例はジョークなのですが…
検討をするにも、コスト感みたいのを経験で知っていないと中々難しいところがあります。
なので、こんなこともあるよーとか、こんな事考えてるんだーというのを知っていただけると良いなと思い稚拙なのは承知でポエムを書いてみました。

2018年8月15日水曜日

FaceRig with Live2D と 恋声 を使ってみた

今、世の中の男性の間でボイスチェンジャーを使うのが流行っています。(嘘です)
テクノロジー的には新しい要素はそんなにないのですが、コンテンツとしてのブレイクスルーがもたされたと感じたので私も試してみました。
つらつらと書いておりますが、恋声で遊んでた時間が一番長いので、書いてる内容もそこだけ充実しています。
(男性がボイスチェンジャーでしゃべっている動画なので注意)



概略

  • 各種アプリケーションをインストールする
    1. Steamをインストール
    2. FaceRig をSteamからインストール
    3. FaceRig Live 2D module をSteamからインストール
    4. FaceVirtualMicDriver をインストール
    5. 恋声 をインストール
  • 恋声をセットアップして遊ぶ
  • FaceRigをセットアップして遊ぶ
  • 恋声からFaceRigを連携させてビデオを取る
  • FaceRigと恋声をSkypeと連携させて通話する

必要な道具

  • Webカメラ
  • ヘッドセットマイク
  • Windows環境
    私はWindows 10 April 2018 Update(バージョン1803)で試しました。

各種インストール

Steam をインストール

Steamとはゲームなどを購入することができるプラットフォームです。FaceRigはSteamで販売されているプログラムのため、導入が必要です。
以下のサイトにアクセスして右上のSteamをインストールをクリックして進めます。
https://store.steampowered.com/?l=japanese

FaceRig を Steam からインストール

Steamのセットアップが完了したら、FaceRigを購入します。
Steamアプリを起動して、左上にある「ストア」をクリックし、検索ボックスにFaceRig と入力して購入を進めます。

FaceRig Live 2D module を Steamからインストール

FaceRigを購入する要領で「FaceRig Live 2D module」と検索して購入を進めます。

FaceVirtualMicDriver をインストール

このドライバーは、恋声で変換した音を別のプログラムに入力させる機能を有しています。
模式図にすると、音は次のように流れていきます。
マイク -> 恋声 -> FaceVirtualMicDriver -> FaceRigとかSkypeとか。

このドライバーは別途手動でインストールする必要がありました。
スタートボタンを開いて、以下のパスをコピペして開きます。
C:\Program Files (x86)\Steam\steamapps\common\FaceRig\Bin\prerequisites\FaceVirtualMicDriver
フォルダを開くと、「FaceRigVirtualMicDriver_win10.exe」があると思うので、これを実行してインストールします。

恋声 をインストール

作者のページからダウンロードして、ZIP展開して完了です。
http://www.geocities.jp/moe_koigoe/koigoe/koigoe.html

恋声をセットアップする

最初に遊ぶだけならば、設定を変更する必要はないのですが、設定ボタンを押すと音声遅延を「標準」から「小」に変更することができます。
つまり、喋った声がマイクを通って変換されてスピーカーから出てくるまでのタイムラグを短くできます。
自分の耳では「標準」と「小」で音質に差は感じられなかったので、「小」で問題なく動作するならば、「標準」を使う必要性はありませんので、最初に設定しちゃいましょう。
また、設定画面では録音デバイス、再生デバイスを選択することができることを覚えておきましょう。

恋声で遊ぶ

「声の高さと性質の調整」のpresetから「M->W(男性から女性)」等を選びます。
入力でマイクボタンを押すと、マイクの音が変換されるので喋ってみます。
入力中もピッチ、フォルマントのパラメーターを調整することができますから、色々試してみると良いでしょう。

最初はボイチェンっぽい音じゃん!と萎えてしまいますが、人によってはハマる組み合わせ(以後、ベストコンビネーションと呼ぶ)があります。
ハマるというのはボイスチェンジャーっぽくない自然な声に変換されるということです。

なお、やっていくと分かりますが変換の度合いを大きくする程、ノイズやボイスチェンジャー感が増してしまいます。
試しに目一杯、ピッチやフォルマントを調整してみるとどのように破綻するか傾向を知ることができます。
この問題に対応するには、元も子もないのですが、できるだけ喋る声の声質を女性っぽくしておくのがコツです。また、声質だけでなく喋り方そのものを女性っぽくしないと非常に違和感があります。最初は恥ずかしいですが、慣れなのでササッと捨ててしまうのがおすすめです。

自分で声を出し続けながらベストコンビネーションを探していると、さっきは良かったのに今はおかしい気がする…となったりします。
ベストコンビネーションを構成する要素は、当たり前なのですが、声・ピッチ・フォルマントの3つです。声というパラメーター(要素)が安定しないと、最適なピッチ・フォルマントが定まらないのは当然のことなのですが、中々気づけませんでした。

そこでおすすめなのが、音声の入力には音声ファイルを使うことです。つまり、事前に「あーあー、てすとてすと。いーいー、てすとてすと」と喋った声を録音しておきます。
恋声ではマイクボタンの横にあるフォルダボタンを押すことで音声ファイルを変換することができます。
このようにすることで、”声”というパラメーターを固定して、ピッチ・フォルマントの最適値を探すことに専念できるわけです。
しかも、恋声には無限リピート機能があるため捗ります。

リアルタイムに遊びたい場合は、どうしても声の安定化に務める必要があるためソフトウェアで解決できませんが、声を作る楽しさは十分堪能することができます。
なお、自分は小一時間遊び続けると、この声はまともなのだろうか、完成度はどうなんだろうか みたいのが分からなくなってゲシュタルト崩壊をおこしました。恋声には変換した声をファイルに書き出す機能も備わっているので上手に使いましょう。

FaceRigをセットアップして遊ぶ

FaceRigはWebカメラがあれば簡単に遊ぶことができます。特に設定する必要もありません。
遊ぶ上ではキャリブレーションだけ覚えておきましょう。真顔になってキャリブレーションボタンを押します。
キャリブレーションを行わないと目が常に半目になってしまったり上手に顔がトラッキングされません。

恋声からFaceRigを連携させてビデオを取る

恋声とFaceRigを組み合わせてビデオを撮るためには少し設定変更が必要です。
具体的には、恋声 -> FaceRigと変換した声がFacerigに伝達されるようにする必要があります。
まず、恋声の設定にて、再生デバイスに「FaceRigVirtualMicDriver 」を選択します。次に、FaceRigの設定にて、オーディオ録画デバイスに「FaceRigVirtualMicDriver」を選択します。

FaceRigと恋声をSkypeと連携させて通話する

(需要があれば書く)

やってみた感想

やってみないとわからないことって多いなーという小学生並みの経験を得ることができました。
自分の容姿や声が変わる経験をしたことはありますか? FaceRigと恋声を使うことで、低コストで比較的簡単に体験することができます。

地の声や容姿を直接晒すことがないため、これならネット動画上げてしまってもいいかなと思えてしまえるのも大きなポイントです。
youtuber,ツイキャス,ニコ生,SHOWROOM,TikTokとか自身をネットに晒すのが当たり前になってきている今日このごろではありますが、私はネットの世界ではロートル状態でよーやるなぁという心理的な障壁を持っています。でも、これなら良いかなと思って一番上に貼り付けてしまった通りです。
このような心理的な部分が緩和されるのは想像もしていなかったことで、何らかの可能性を感じるところです。

BOOTH で楽天ペイで決算したら28分かかった話。

(当たり前だけど、注意事項)この内容は自分が実際に経験した内容であり、何時でも時間がかかるとかそうゆうのを検証した某ではありません

BOOTHとは、ピクシブ社が運営しているECサイトです。とあるダウンロードコンテンツを楽天ペイ決算で購入して思わぬユーザー体験ができたのでメモ。

表題の通りですが、ポチってみたところ実測値として、28分かかりました。
決算の説明書きのところには何も書いていないのですが、決算の画面で「楽天ペイ(お支払い後1時間以内で決済完了)」と記載されていますから、想定通りの動きです。
決算されるまでは、購入履歴のステータスが「支払い待ち」となり、完了すると「発送完了」になります。
購入時と決算完了時にメールが届いたので、そちらを確認するのが良いです。

ダウンロード系はすぐに読みたい!という時も多いので、待たされるのは思った以上にモヤモヤしました。
楽天ポイントを使いたいというわけでなければ、即時決算される別の方法を使うのが良さそうです。







おまけ
2018年8月28日まで、Paypal決算だとクーポンのキャンペーンがありました。




2018年6月9日土曜日

Ubuntu 18.04リリース記念オフラインミーティング に参加した


イベントの内容はこちら
第525回 Ubuntu 18.04 LTSリリース記念オフラインミーティング フォトレポート

仕事を変えてから、すっかりLinuxを触らなくなってしまったものですから参加していいのかなーと悩みながらも参加しました。
前のセミナーの話はあまり聞いておらず、デュアルブートで18.04の導入をその場でやっていました。

インストールメディアを貸してくださった方、Windowsのレスキューメディアを作成してくださった方ありがとうございました!

セットアップする前のストレージのパーティショニング
ESP,Windows,Windowsレスキュー,Ubuntu16.04

メインで使っているWindowsのストレージが残り3GBとピンチだったので、Ubuntuのライブイメージで次の操作をしました。
良い子はバックアップをするべきですし、真似してはいけません。

Windowsレスキューパーティションを削除、Ubuntu16.04パーティションを削除、Windowsパーティションの拡張

勘の良い方はお気づきかもしれませんが、この時点でWindowsが起動しません…!
ブートローダにGRUBを使っていてセカンドステージを消してるからです…^q^

まぁお構いなく、Ubuntu18.04を導入してブートローダーも導入されたし、Windowsも起動できるようになるだろうとくくっていましたら…
冒頭の写真のブルースクリーンエラー「NTFS_FILE_SYSTEM」というエラーで起動できなくなってしまっていました。
えぇ、パーティションを拡張したりしてるからそんなこともありますよね!!!

とはいえ、チェックフラグが立っているだけでなんとかなるやろ…と思っておりました。
Windows10はレスキュー領域作るからそっちから回復できるだろう…… って先自分で消したやないかーい!

まだ諦めるわけにはいかなくて、Windows10の回復ディスクがあればなんとかなるだろうと思ったので、隣の席に座っているWindowsを使っている方に声をかけてメディアを急遽作らせていただきました…。



無事に回復してWindowsもUbuntu18.04も使えるパソコンになりました。めでたしめでたし。
このようにUbuntuリリースパーティーは席の後ろで勝手にあれこれしても良いとされているゆるふわなイベントです。

イベント自体がどうゆう方向に向かっているのかはよく分からないのですが、Ubuntu18.04のリリースノートをパネルディスカッション形式で解説するのはとても面白かったので、これからも継続してほしいです。会場から野次飛ばせるとかはオフラインイベントの醍醐味だと思うので。

取りまとめない感じになってしまいましたが、今回の感想は以上です。


2018年3月25日日曜日

Alstroemeria Records の CLOCK LOCK THINK RELEASE PARTY に参加した #アルレコ

本アルバムで好きな曲は、COLLAPSE の @nekomatu です。

久しぶりにライブに参加してきました。
思ったよりも人数が少なくてアットホームなライブイベントでとても楽しかったです。
パーティータイトルの通り、CLOCK LOCK THINK から多くの曲が使われたのですが、めちゃくちゃ edit されてて、しかも超絶にかっこよかったので、最初の3曲ぐらいで頭が真っ白になりました。
つなぎの部分から「!?」ってなって、自分が知ってる曲と違うみたいな感じでした。これだけで、めちゃくちゃ感動してました。これだけで参加して良かったなと心底思いました。誰だ、Play button押すだけの仕事とか言った人は。

実のところ、ボーカル ayame さんのイベントという認識が全くなくて、生パートあるんだー、みのしまさんのDJパートが楽しみだなーみたいな心持ちでポチってたのですが、ライブパートが良かったです。
後半のDJパートは、まさかのアットホームなただのパーティーと化しててこれも別のベクトルで大変に良かったです。みのしまさんは歌えるし、踊れるし、みたいな普段観測不可能な実態をうかがい知ることができましたですよ。

なぜここの所、オリジナル作品がアルレコからリリースされるようになったんだろう?というのは、疑問だったのですが、そこもクリアになりました。
常々、オリジナル作品をもっと作って欲しいと思っていたので大変に喜ばしい傾向ですが、その裏事情はもう少し切実な何かだったことがツイッターでも述べられています。
これからもアルレコは応援していくと思います。ただ、それは良い音楽を作ってくれる限りというところです。アルレコだから買うというよりは、良いものを作ってくれる人たちは末永く応援していきたいものです。

箱は初めて行く、新宿MARZでした。いい感じの狭さで、音の鳴りも良かったです。振動が伝わってくるぐらいの迫力が楽しめるのは、おうちでは無理ですからね。あと、好き勝手に身体動かしていい。実に贅沢な時間です。
一方で、箱を出た後耳鳴りがして、必要に応じて耳栓しないとまずいなぁとも実感しました。







実は入場前からめちゃくちゃテンションが上がっていました。ただのライブだと思ってたのに、すごくないですか?
完全に特別な1日ですよ。
かっこいいステージ
ナンバー入りのユニークなエントリーカード
Invitationって型押し、サークルロゴも決まってる。
特典のCD。手焼き。アルレコのインストって貴重品ですよね。これからもリリースして欲しい…


そう言えば、打ち上げあるとか話がありましたが忘れてたのでブログを書いているわけです。

2018年1月30日火曜日

twitterのbio変えた

試用期間終わっちゃうので。1月は明日で終わるんですよ。
転職してから、Ubuntuを使う機会がなくなり、ARMもなくなり、Qtもなくなり……。
あんまりよろしくない感じはある。でも、今の仕事で及第点が十分にとれてないので兎にも角にもまずはそこからという日々。

古いやつ、ちょっと残しておく。
---
転職して試用期間中なので、忙しめ。 Ubuntu,ARM,Qtが気になる ここに書いてあることは大抵つぶやきません+うるさくなったらミュート対応お願いします 所属するポリシーに準拠して使っております。あと、ゆゆ式とEDMちっくな音楽が好きです spcamp08,高専
---
その前はちっちゃい系メーカーでOSSを触ったりなんでもやるのがお仕事とかだった気がする。

2018年1月11日木曜日

歓迎会幹事業

歓迎会幹事業

準備

[] 予算を決めましょう。
招待者の費用は原則徴収しません。なので、招待者の人数が多い場合はリーズナブルであることは重要です。
3時間3000円飲み放題のお店が良いでしょう。招待者が少ない場合は満足度を上げるために少しリッチに傾けても良いかもしれません。
* 一般参加者 上限5000円
* 役職者は多めに出してくれることが多いようです。

[] 招待者リストを作成しましょう
絶対参加して頂きたい人をリストアップします。
人数が多くなると調整等が大変になるので、その時は相談して方針を決める必要があります。
* 入社の人
* 役職者

[] 日程を調整しましょう
* 招待者リストの方に可能日を聞き取る
招待者が全員参加できる日を確認します。日程と人数が決まらないとお店の予約ができません。
聞き取る日程は任意の一週間を選択します。この時、2週間以上先を選んでおくのがベターです。
なぜなら、調整後にお店を見つけてすぐに予約できるとは限らないからです。十分に先ならば、予約できる可能性は高くなるので安全です。

[] お店の下調べをしましょう
事前にグルメサイトなどで情報を仕入れておきます。他には、いつも使っているお店とか知っている人がいるかもしれません。
おおよその人数や日程が分かってきた段階で連絡するのも良い手です。確定してなくても仮押さえや聴き取りができているとドタバタしないですみます。
[] いつまで人数の変更が可能か確認します。キャパシティを確認します
人数が増えたり減ったりすることがあります。また、増える場合はどこまで増やせそうか聴き取りを行っておきましょう
* メニューはコース料理・飲み放題にします
コース料理については交渉できる場合もあるので、予算はいくらで、飲み放題で。料理で調整できないかなども聞いてみましょう。

[] 一般参加者を募りましょう
既に絶対参加してほしい人は調整が済んでいるので、期限は長く設定する必要はありません。パッと済ませて全体の人数を確定させましょう。
人数が多ければ、その分カンパになるので資金的には嬉しいです。

[] お店を決定し連絡しましょう
本予約をします。日付と時間が間違っていないか、きちんと聴き取りをしましょう。当日行ってみたら予約されてなかったなどということにならないようにします。

[] 開催前にお金を集めましょう
参加人数が確定しているはずなので、請求します。役職者への傾斜などは一般参加者などを見て確定します。もし、余剰金が発生したら次に備えてプールするのが良いでしょう。

当日

[] 会社を出る集合場所に集まります
招待者リストの方に声を掛けて出発する集合場所に集まります。すると、出発する雰囲気になるはずです。

[] お店の人に私が感じですと伝えましょう
お酒を入れる前にリレーションを構築します。まだ来ていない人数は何人ですなどというと喜ばれるようです。時間通り始めてよいなども伝えましょう。

[] 乾杯の挨拶をお願いしましょう
2番目に偉い方に開催の挨拶をして頂きます。
[] 締めの挨拶をお願いしましょう
1番偉い方にお願いしましょう

[] 二次会を計画するかは本人のやる気次第で良いと思います。