忘年会・結婚式の二次会などのイベントに最適な、「オールスター感謝祭風クイズ」のWebアプリをつくったので、以前紹介しました。
こんな感じの、イベントに来ている方々全員参加型で楽しんでもらえるクイズです。
スマホから早押しでクイズに回答してもらう形式となっております。
現在、β版のテスターを募集してまして、早くも使っていただいているユーザーさんがおります！
が、数的に少ないので、まだまだテスター募集中でございます。
以下より、ユーザー登録をお願いします！
使い方については、以下の記事をぜひ参考にしてくださいね。
何かご意見・ご要望、お問い合わせがありましたら、
記事へコメント or メールにてお送りください。
よろしくお願いします！
では、また！！
前回、「今明かされる、知られざるチップ設計の世界 〜影と影〜」と題して、
大変に変態な記事を紹介しましたね。
とにかく、演算用の組み込みハードウェアや、チップの製作は死ぬほど大変だということを、みなさんに知ってほしいのです。
そして、絶望感を存分に共有したいと考えてる所存です、はい。
あと、前回「ハードウェアにするとこんなに素晴らしいんだよ！」的な、こいつの肩を持つような言い方もしちゃいましたが、そんなことはない。
こんな作業はほんとにクソだと言っていい。
せっかくなので、もうちょっとチップ設計の大変さについて、踏み込んでお伝えしましょう！（白目）
チップの回路は、今やPCでプログラミングで定義できる便利な時代ですよ〜なんて言いましたけど、
こんなシミュレーション画面と、ずっとにらめっこすることになります。
おうちがえりだいよ〜（おうち帰りたいよ〜）
■おうちに帰れない理由
動画像なので、一番左上のピクセルから、右方向へ順々にピクセルを読み取って処理を進めていきます。
１行目のピクセルを左から右へ読み取り終わったら、今度は、２行目のピクセルを左から右へと読み取りにいきます。
なんですが、だいたいそういうイレギュラーなパターンのとき、
計算タイミングが合わないとか、変なバグが起こっちゃうんですよね。
画像を１枚処理し終わって確認してみたら、「あれ、このあたりから画像ぐっちゃぐちゃ…」っていう状況になってます。
そうなると、上の波形とにらめっこしながら、
「110クロック目までは計算合ってるけど、111クロック目から計算ずれてるな…」とかいうデバッグ。そう、デヴァッグが延々と続くのです…。
これはやってて精神がおかしくなります。
いいえ、おかしくなりました。
夜中、「なんで計算合わねぇんだよぉ！！」と叫びながら、研究室にあるソファーを１０分ぐらい永遠と蹴り続けていた記憶があります。
お分かりいただけただろうか。
僕が今、生きているという奇跡を。
バグをひたすら取り続けて、ホッとしているのも束の間。
新たなる壁にぶち当たるのだ。
「計算時間が間に合わない」という壁に…！
前回と同じイメージで説明しよう。
３クロック目の処理が「タイムオーバー」、つまり計算時間が間に合わなかったパターンとしましょう。
「２＋３を計算して、結果を記憶する」という処理はどう見ても軽いので、実際に間に合わないということはまずありえないのですが、めちゃめちゃ手間がかかる処理だったとしましょう。
実は、タイムリミットがありまして、
この３クロック目の処理は、４クロック目までに処理を終えないといけないのです！
処理を終えないまま４クロック目を迎えてしまっても、
時間は有限。待ってくれません。
「５」ではなく「不定状態（どっちつかずの謎の値）」として、以降ガリガリと処理は進んでいってしまいます。
で、もちろんこの謎の値が以降で使われていってしまうのです。
よく変態さんな先生達は、電流は「川」だ！って例えるんですけど、まさにそれ。
結局、このままだと設計は失敗なのです…。
ロジックを見直し、またバグ取りもやるのです。
エンドレス。もうおうちには帰れませんね。
前回、「計算時間が一定だから、ピタゴラスイッチ的な精密なシステムが組めるね、やった！！」なんて言いましたが、そのロジック達は、エンジニアさんの汗と涙の結晶なのかもしれない…。
さぁ、ここまでで、ハードウェアの世界観に絶望された方々に向けてのどうでも良い、こぼれ話です。
PCに積まれてる、CPUって実はものすげぇという話。
何故かと言うと、2〜3GHzのクロック周波数で、何不自由なく動いているから！
※クロック周波数＝1秒の間に、先程のクロックの波が立ち上がる回数
つまり、1クロックの計算時間のタイムリミットは、『1／(3✕10の9乗)』秒しかないのですよ。
僕がこんなにも悩んでロジックを作ってたチップのクロック周波数は、せいぜい100MHzぐらいでした。
（僕の課せられたタイムリミット：『1／(1✕10の8乗)』秒）
桁が違いますよ！
それで、「計算時間が間に合わない、ひぃひぃ！」と言っていたのがバカらしく感じられませんか？
そんなわけで、ボキャブラリーも乏しいながらも単純に「すごい」と思った話でした。
さぁ、果たしていつおうちに帰れるのでしょうか！
では、また！！！
＞＞Next Phase
教授の凄まじいドジっ子っぷりにより、放置系ブラックから一気に、激務系ブラックに変化したこの研究室。
調べてみると世の中には、忙しすぎて就活もさせてくれないようなブラック研究室があるようだ。
就活中はまだ放置系ブラックのままでいてくれて本当に良かった。
不幸中の幸いといったところだろうか。
さて、ふと俯瞰してみてみると、
・修士２年の夏〜卒業まで、何をそんなにセコセコと労働することがあるのか？
・てか、「動画圧縮のチップ製作」って一体なんなの？
と皆さん疑問に思うかもしれない。
そこで我々は立ち上がり、
今回は、その大変さを語って見たいと思います！（白目）
そう、影と影なのです。光はない。
ずーっと日陰の作業。
そもそもチップというのは、こんなやつです。
こういうのを見せた瞬間に、「え、やだ…ナニコレ…」とドン引きするでしょう。
特に20代女子勢。すぐドン引きしちゃうからね。やーね。
だから、絶対にこういう話は面と向かってしません。
で、この画像のチップは、いわば『完成品』。
ただ設計完了済みの電気の通り道（回路）を、大日本なんちゃらさんとか、凸版なんちゃらさん達がガンガン印刷して、大量生産しているものです。
今回の超絶激務ミッションは、パソコン上で動いている動画圧縮のC言語のプログラムを、上記の状態にもっていくこと。『実用化』・『製品化』とも言えますね。
なんでもできちゃう天才的な「ソフトウェア」から、原始的で電気的な「ハードウェア」に設計し直すのです。
それは、泣くほど大変なことなのです。
電気メーカーさん、マジお疲れ様なのです…。
ここが非常に重要なのです。
頭の良い子に勉強を教えるのと、超絶アホの子に勉強を教えるの、どっちが大変ですか？
超絶アホの子を教える方に決まってますよね。
それがハードウェアの世界！
例えば、あなたが「２＋３＝５」という計算をしたいとします。
すると、ソフトウェアでは、
『 i = 2 + 3; 』
とでも書けばできちゃいますよね。それ以外ないだろ？って話。
しかし、ハードウェアでは、
こんなイメージになるのですよ…。
クロックという一定の波を見て、
最初に波が立ち上がった時（＝１クロック目）、１コ目の記憶領域に「２」を記憶させときます。
で、２クロック目に、２コ目の記憶領域に「３」を記憶させます。
そして、３クロック目に、この記憶させた２つの数を加算させて、その結果を３コ目の記憶領域に記憶させます。
・・・という、世界でやりたいことを教え込んでやらなければいけないのです。
絶望しませんか？
え、そもそもそんな解説、読んでいられるかって？
ですよね、それが正しい反応だと思いますよ。
ただ、やりたいことを教え込む時、つまり設計する時は、
ソフトウェアと同じく、プログラミングでできる時代なので、この時代でほんとよかったって感じです。
といっても、こんな訳のわからん文法なんですけどね。
Verilog-HDLという言語です。
ハードウェアの定義に使われます。
コツはですね、頭の中で回路や配線を思い浮かべて書くことです。（キモい）
そう、こんな風にイメージして！
さぁ！さぁ！（ヤバイ人いるよ）
え？なんでそんなことしなきゃいけないのって？
そりゃあ、そこに回路があるからだよ。
ではなくて！
一応、ちゃんと理由はあるんです。
■理由①
『ハードウェアの方が、計算が爆速だから』
です。
ソフトウェアと比べ物にならないぐらい早いです。
電気的に一瞬で処理してしまうので。
正直、動画像の処理は重たいです。
リアルタイムに処理したい！ってなってくると、今回みたいに『ハードウェア化』という恐ろしい選択肢が待っているかもしれません。
■理由②
『計算時間が決まっているので、完全に思い通りの処理ができるから』
です。
クロックという一定のリズムを刻む波に沿って、順々にガリガリ計算していくので、
計算が終わる時間も一定なのです。
ソフトウェアだと、仮想的に処理しちゃうので、マシンのスペックや状況によって、
計算時間が左右されます。一定じゃないんですね。
ピタゴラスイッチ的なものを作った時、
「このタイミングでドミノが倒れない！」っていう状況はかなり致命的になっちゃいますよね。
だからこそ、『時間が一定』というのは、結構大事になってきます。
よし、この調子で、次回ももうちょっと語ろうと思います。（まじかよ！）
では、また！！！
前回までで、リアルタイムお絵かきシステムができました。
お〜、描けますね〜。
しかし、１つ気になることがあります。
それは、サーバプログラムを起動する時です。
前回までの説明ですと、server.jsを起動時、以下のシェルを打っていたかと思いますが、
このままだと、フォワードで実行されてしまい、SSHを切るとサーバプログラムが終了してしまいます。
# server.jsを起動 node server.js
そこで、サーバプログラムをデーモン化（常時起動）しましょう！
Node.jsのデーモン化のためのツールがいくつか存在します。
僕が知っているものとして、以下２つがあります。
死活監視：○
マルチコア対応：✕
死活監視：○
マルチコア対応：○
比較すると、pm2の方が優秀だと思います。
２つとも死活監視（サーバが落ちたことを検知して、自動で再立ち上げ）には対応しているのですが、決め手はマルチコア対応の観点。
pm2は、サーバのCPUのコア数に応じて、自動で複数プロセスで処理してくれます。
サーバ性能を考慮してくれるpm2は、まさに優れもの！
以下、参考記事です。
インストールから起動まで、至って簡単です。
# pm2をインストール sudo npm install pm2 # pm2でserver.jsのデーモン化開始 pm2 start server.js
あと、よく使うコマンドはこんなものでしょうか。
# 再起動 pm2 restart server.js # デーモン停止 pm2 stop server.js # ログやプロセスの確認 pm2 monit
では、また！！
前回、Node.js・Socket.IOをインストールし、Nginxとの連携設定をしました。
これで、導入はOKです。
以下のような構図ができあがりましたね。
以下、リアルタイムお絵かきシステムのソースコードをGithubで公開します！
スマホ向けのTOPページです。ここで１〜４の回答番号を選びます。
※回答番号とは、以下の投影画面で１〜４のどの四角いBOXに絵を書くか、のことです。
スマホ向けの絵を書くページ。回答番号を選ぶとこのページに飛びます。
PC向けの投影画面です。
Node.jsのサーバプログラムです。
これは、前回記載した『任意の作業用ディレクトリ』に移して起動してください。
※Socket.IOのライブラリをインストールしたディレクトリに入れて起動する必要があります。
Socket.IOは便利ですよ。このお絵描きシステムで使っているテクニックを少し紹介します。
基本的に、以下の構図が成り立つと思われます。
これを意識しましょう。
クライアントA → サーバ → クライアントB
また、当たり前の話ですが、Socket.IOでのやりとりはNode.jsを使っているので全てJavascriptで完結します。
前回同様、以下のSocet.IOのライブラリをクライアント側のページに読み込ませておきます。
<script src="/socket.io/socket.io.js" type="text/javascript"></script>
■クライアントA→サーバへの情報送信
例として、変数dataを、サーバ側がリッスンしている『ClientAtoServer』という関数へ送信します。emitで送信です。
dataの中身は数値でも、配列でもある程度何でも渡せます。dataを引数として持たなくてもいいです。ゆるいですね。
//クライアントA側 var socket = io(); socket.emit('ClientAtoServer', data);
■サーバ→クライアントBへ情報中継
サーバ側で、『ClientAtoServer』という関数をリッスンさせることで、クライアントAからの情報(data)を受け取ります。onでリッスンです。
そして、クライアントB側でリッスンしている『ServerToClientB』という関数へ情報(data)を橋渡ししてやります。
// サーバ側 socket.on('ClientAtoServer', function (data) { // dataをクライアントBへ中継する socket.emit('ServerToClientB', data); });
■クライアントBで情報受け取り
先程と同様に、クライアントB側で『ServerToClientB』という関数をリッスンします。
これで、橋渡しされてきた情報(data)がクライアントBで受け取ることができますね。
// クライアントB側 socket.on('ServerToClientB', function (data) { // ・・・ // dataをガチャガチャする // ・・・ });
「このルームに入っている人のみに情報を送りたい」ということが可能です。
■入室
まず、回答番号１番に書くよ、ということで、client.phpからサーバーへその番号を送って入室します。 ※team_num＝1とします。
// client.php socket.emit('sendTeamNumToServer', team_num);
■ルームへ配置
サーバー側は、 その番号を受け取り、このクライアントを「team1」というルームにjoinさせます。
// server.js socket.on('sendTeamNumToServer', function (num) { if(num==0){ //モニター socket.join("monitor"); }else if(num>0){ //クライアント（今回ここ） socket.join("team"+num); } });
■ルームを絞った情報送信
そして、サーバから以下のようなコードを書いてやると、「team1」宛にのみ情報を送ることができます。
※broadcast.to("ルーム名")により、送り先ルームを指定しています。
socket.broadcast.to("team1").emit('forTeam1Function', data);
■情報受け取り
「team1」に入室しているクライアント側で、上記に沿って『forTeam1Function』をリッスンさせていれば、dataを受け取ることができます。
socket.on('forTeam1Function', function (data) { // ・・・ // dataをガチャガチャする // ・・・ });
慣れてくると、結構簡単です！
これらを応用して、スマホから絵が書かれたら投影画面に反映する、ということをやっているのですが、
線を描画するときのイベントが少し複雑になってしまっているので解説します。
反映の精度を高めるため、以下の１〜３のステップでイベントを分けています。
これによって、線の太さや色、座標をバグることなく、投影画面に反映させることができています。
※詳細は、Github上のコードを参照くださいませ。
■１．線の描き始め（指がスマホに触れた時）
スマホ →①→ サーバ →②→ 投影画面
①：関数名「sendDrawDownToServer」
②：関数名「sendEachDrawDownToClient」
■２．線を引っ張っている最中（指がスマホ上で動いている時）
スマホ →①→ サーバ →②→ 投影画面
①：関数名「sendDrawToServer」
②：関数名「sendEachDrawToClient」
■３．線の描き終わり（指がスマホを離れた時）
スマホ →①→ サーバ →②→ 投影画面
①：関数名「sendDrawUpToServer」
②：関数名「sendEachDrawUpToClient」
参考までに！！
ではまた！！
スマホですーっと線を引くと、PC側でもほぼリアルタイムにすーっと線が引かれる、
まさに「平成教育委員会」的なお絵かき・回答システム、作りたくないですか？
前回紹介したのがこちらです。
今回、その導入編になります！
（東京・CPU２コア・メモリ1GB・SSD）
※すでに他のWebページを、Nginxを使ってPHPのサイトを運営しているため、
今回ベースはNginxを使ってHTMLを提供し、Socket.IOでのやりとりのみNode.jsを通す、というやり方を模索しました。
つまり、Webページ（HTML）は、そのままNginxを使ってクライアントに提供しますが、
クライアントがサーバとSocket.IOによる双方向通信をしたいよ！という時だけ、Nginxへ一旦要求をもらって、Node.jsへ転送し、クライアント↔サーバ間をコネクションさせます。
難しいことを書きましたが、案外簡単にいけました！
Node.jsをインストールします。
sudo yum install nodejs
次に、npm（Node.jsのパッケージ管理）をインストール。
これがあれば、Socket.IOなどのライブラリを入れることができます。
sudo yum install npm
そして、Socket.IOをインストールします。
# 任意のSocket.IOを動かすディレクトリを作成 sudo mkdir /var/sample # そこへ移動 cd /var/sample # npmを初期化 sudo npm init -y # Socket.IOをインストール sudo npm install socket.io
Nginx未導入であれば、インストールします。
sudo yum install nginx
Nginxの設定ファイルを書き換えます。
設定ファイルは、一般的に、/etc/nginx/conf.d/default.confを書き換えればOKでしょう。
僕は、以下の形に書き換えました。
# default.conf
#ここがポイント！Socket.IO通信時、ポート3000番にひねる
upstream io_nodes {
ip_hash;
server 127.0.0.1:3000;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
#root /usr/share/nginx/html;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
root /var/www/html;
index index.php index.html;
}
#PHPとの連携設定（PHP未使用なら不要）
location ~ \.php$ {
root /var/www/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include fastcgi_params;
}
location ~ \.inc$ {
deny all;
}
#ここがポイント！
location /socket.io/ {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_http_version 1.1;
proxy_pass http://io_nodes;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
保存したら、Nginxを再起動します。
sudo service nginx restart
では、動作確認として、試しにページ更新不要な、リアルタイムチャットシステムを作ってみましょうか。
任意の作業ディレクトリ（今回：/var/sample配下）に、
チャットシステムを司る、javascriptのサーバプログラムを以下のように作ります。
「server.js」としました。
//server.js // 1.モジュールオブジェクトの初期化
//ポート３０００番をリッスン var fs = require("fs"); var server = require("http").createServer(function(req, res) { res.writeHead(200, {"Content-Type":"text/html"}); var output = fs.readFileSync("./index.html", "utf-8"); res.end(output); }).listen(3000); var io = require("socket.io").listen(server); // 2.イベントの定義 io.sockets.on("connection", function (socket) { socket.on("msg", function (data) { console.log(data); io.sockets.emit("public", data); }); // 接続開始カスタムイベント socket.on("connected", function () { }); // メッセージ送信カスタムイベント socket.on("publish", function (data) { io.sockets.emit("publish", data); });
そして、チャットのWebページを作ります。
（これは、もちろん、Web公開ディレクトリにです）
「chat.html」
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999" xml:lang="ja" lang="ja"> <head> <title>Chat Test</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <script src="//code.jquery.com/jquery-1.11.0.min.js" type="text/javascript"></script> <script src="/socket.io/socket.io.js" type="text/javascript"></script> <script type="text/javascript"> var socket = io(); socket.on("connected", function () {}); // 接続時 socket.on("disconnect", function (client) {}); // 切断時 socket.on('public', function(msg) { console.log(msg); $("div[id=chat]").append("<div class='messages'>" + msg + "</div>"); }); $(document).ready(function(){ }); function sendMsg(){ var msg = $("input[name=msg]").val(); console.log(msg); socket.emit("msg", msg); } </script> </head> <body> <input type="text" name="msg" size="50" /> <input type="button" value="送信" onclick="sendMsg();" /><br><br> <div id="chat"></div> </body> </html>
このHTMLでは、以下のように、Socket.IOのライブラリを読み込んでいるのですが、
<script src="/socket.io/socket.io.js" type="text/javascript"></script>
さきほど、②でNginx↔Node.jsで連携を図れるようにした際、
Nginx側で「/socket.io/」へアクセス要求された時にポート3000番にひねる設定をしましたね。
さらに、Node.jsのプログラム（server.js）は、ポート3000番をリッスンしているため、server.jsへ飛んで、Socket.IOで通信ができるという仕掛けなのです！
最後に、server.jsを起動したら、リアルタイムチャットが動き出すはずです。
# server.jsを起動 node server.js
どうでしょうか？
ページを更新しなくても、２つのクライアント間で入力した文字が、リアルタイムに画面に反映されます！
では、次回はお絵かきのシステムを大公開しちゃいます。
前回、事件が起きた。
それは、修士２年の春先の出来事だった。
就職先も僕の調子の良い性格が功を奏して、早々と決まっており、
春・夏・秋のみなみけ三姉妹を悠々とやり過ごし、凍てつく冬の修論を「パパン、なんとかして〜」と教授に泣きついて乗り越えれば、無事卒業。
もうこのブラック研究室とはおさらば！というビジョンだったのに・・・。
人生、ほんと思い通りにはいかないのですね。
背景に、教授が国の研究機関から引っ張ってきた「動画圧縮装置プロジェクト」がある。
『３年後に、４K動画を無線通信で飛ばせるぐらいのサイズにリアルタイムに圧縮できるようにするよ！』というフレコミで、多額の予算をゲットしていた。
こんなチップのイメージ。
僕・ハッカー「３年後か〜、おれらには関係ないや〜ワッハッハッハ！！」
教授「３年あるからな〜、まぁゆっくりいきましょ！ニッ！」
こんな感じの構えで、特になにもやっていなかった。
しかし、
教授のかわいいさ余って憎さ百倍、いや、憎さしかないドジっ子っぷりにより、
来春に中間審査、つまりその装置（チップ）のプロトタイプができていないと打ち切られてしまうことがこのタイミングで発覚した。
もう、期日まで１０ヶ月を切っていた。
その日から、教授の目つきが、変わってしまった・・・。
僕とハッカーは、ある日、教授室に呼ばれた。
教授「まぁ、この前伝えた通り、我がラボは大変危機的な状況にあるんだなこれが」
僕・ハッカー「はぁ。でしょうね。」
教授「予算打ち切られたら、来年君たちの後輩が学会に参加できなくなるかもしれないし、かわいそうすぎるじゃん？」
僕・ハッカー「はぁ。（確かにサムイ島は楽しかったけども）」
教授「だから、動画圧縮のチップをなんとか卒業までに作ってほしいんだ」
僕・ハッカー「そうなりますよねー・・・」
教授「タダでとは言わん！君たちに、給料を支払おう！」
僕・ハッカー「む？」
教授「そして、修論は、完成したチップの説明書（数ページ）だけで良いと言ったら？？」
僕・ハッカー「むむ？」
なんと教授は、僕らがこのプロジェクトを進めれば、
月８万円の給料と、修論の実質免除を特典として与えるというのだ・・・。
うまい話かもしれない・・・。
しかし、日々デスマーチとなることは容易に想像できる。
これは悪魔の契約だった。
教授「じゃあ、雇用契約書にサインを」
僕・ハッカー「むむ？」
「プロジェクトの研究支援員」と題目が書かれた契約書を出された。
これにサインすれば、給料が発生するらしい。
僕らは勘違いしていたが、拒否権なんて最初から無いのだ。
半泣きで、サインしたのだった。
まさに保証人のサインのような光景だったかもしれない。
教授「ありがとう。でも、失敗したら、わかるよね？」
僕・ハッカー「ひぃぃ！」
プロジェクトが間に合わかなったら、
大人の力で卒業も踏みにじられる可能性もある。そう目で訴えられたのだった。
さぁ、残り１０ヶ月も無いデスマーチに参加することになった僕ら。
果たして、生きて卒業できるのか？！
では、また！！
＞＞Next Phase
