コラム, プログラミング, 趣味

はじめまして!バーテンツチノコ(仮) の近藤です。六本木のBARで、カクテル作れないバーテンダーをやる傍らで、夜な夜なプログラミングをしています。

人狼をみんなで集まってやる時、人間GM(ゲームマスター)の代わりに司会者をやってくれるLINE BOTを作りました。その名もとろろ人狼BOTです。

今日はそのBOTの紹介をしたいと思います。

 

 

 

使用イメージはこんな感じ

 

とろろ人狼BOTを友達登録し、代表者1名(以後、便宜上「GM」と表記)が「村」を準備し、参加者が集まったら開始合図を行います。

開始後は、会話をしつつ、各々がBOTとやりとりをしながらゲームを進行していきます。

 

ゲームの流れを順を追ってご紹介します。

1.友達登録すると、名前を聞かれるので答えます

2.左上の、「村を作成」をタップすると「村」を作成できるので、友達にQRコードを教えて参加してもらいます

※参加する側(うさぎさん)のLINE(先ほどとは別人物のLINEです)

3.人数を確認。こんな感じに5人集まりました

4.村を開始するとこんな感じ

村人3人、人狼1匹、占い師1人がいるそうです。自分(とろろ) は占い師でした。このメッセージは全員宛にアナウンスされます

 

~~ここから、実際には話し合いが始まります~~

うさぎ『ねこさんが人狼かな?』

ねこ『いや、ねずみさんじゃないかな』

ひつじ『そうかなあ』

ねずみ『うさぎは人間だと思うな』

~~~~~~~~~~~~~~~~~~~~~

(※話し合いは一例です。実際にはもっと殺伐とする可能性があります)

5. といった話し合いの結果、自分が人狼だと疑わしいと思ったうさぎさんに投票することにしましょう

6.皆の投票が済んだら、GMは「時間を進める」コマンドを使います。この時、未投票の人がいると警告が表示されます

うさぎさんが処刑されてしまいました。(※うさぎさんは、実は村人でした)

7.夜が来ます。夜の間は誰とも会話禁止で、各々が淡々と自分の能力を使います
自分(とろろ) は占い師なので、占い先をセットしましょう
ひつじさんを占いたいと思います

8.全員が能力をセットしたら、翌朝に時間を進めます

ねずみさんが人狼に殺されてしまいました。
占いの結果、ひつじさんは人狼だったので、他のメンバーにそれを伝え、ひつじさんへ票を入れてもらうように説得します。

9.投票を行い、時間を進める

10.決着

13393054_1144158248940477_1216561269_n

 

いかがでしたでしょうか。キャプチャを淡々と貼り付けただけの紹介でしたが、ゲームの流れは以上です。

★LINEがインストールさえされていればアプリインストール・ユーザ登録不要

★それぞれがBOTを通じてコマンド入力を行うので、自分の挙動を隠したりする必要がなく進行がスムーズ

★GMが不要になるので、全員で同じ情報量・立場でゲームに参加出来る

何度かテストプレイをしていますが、上記の点でたいへんご好評をいただいております!

 

とろろ人狼Bot(@tororo_jinro) というTwitterアカウントを作っております。

公開出来ると判断でき次第、LINE QRコードを公開しますので、良かったらフォローしてください(๑´ㅂ`๑)

 

ではでは

 

 

補足:GM用 チートシート

linux, コラム

連休直前にノートPCのバッテリーが充電できなくなった。
故障した機材は、ThinkPad X1 Carbon 3rd Generation + Ubuntu 15.10。
ちょうど Ubuntu 16.04 LTS が出たばかりだよねえ。
さらに我々の部署の新しい標準PC(4th Generation)が入荷してきたぞ、ということでセットアップしてみたよ。

BIOSの設定

ThinkPadは電源を入れた直後に、F1キーを押せばBIOSセットアップ、F12キーでboot元を選択できる。
まずは、F1キーを押して、BIOSの設定変更。

  • USB接続機器からbootできる設定になっていることを確認
  • 仮想化テクノロジーが標準だとdisableになってるので、enableにする
  • Secure Boot をdisableにする

インストールメディアの準備

USBキーからインストールするのがお手軽。
ISOイメージをダウンロードしてきて、ブータブルUSBキーを作るツールで書きこんでやればOK。
Ubuntuで使えるツールでは以下なんだけど、、、、、、

  • usb-creator-gtk(ブータブルUSBキーの作成)
  • unetbootin
  • mkusb

usb-creator-gtk は、ここ数年バグってて使いものにならないんだよね。
案の定今回もうまく起動できるUSBキーは作れなかった模様。

unetbootin で作ったUSBは起動できたけど、起動直後に、「SYSLINUX 6.03 EDO …. Boot Error」 というメッセージが出て途中で止まっちゃう。
調べてみると、今のunetbootinに含まれているSYSLINUXに問題があって、機種によってこういうエラーが出るんだとか。

mkusbで作ったUSBキーでも起動できず。

さあ困った。
WindowsとかでUSBキーを作れば良いのかなあ。

あきらめて素直にDVD-Rに焼いて、DVDドライブから起動したら問題なく起動したよ。
なんかすごく時間を無駄にしたけど結果オーライ。

インストール

インストールメディアから起動できてしまえば後は素直にインストールできる。
今回はハードディスクを全部使う設定でGo。

ノートPCによっては無線LANのドライバーがなかったりすることもあるけど、X1 Carbonではインストール直後から問題なく無線LANは使えた。
Bluetooth、音量コントロール、画面の輝度コントロールなんかも問題なし。

インストールの後は生活環境を整えていく。

Aの横をCtrlキーにする

gnome-tweak-tool をインストール。

sudo apt-get install gnome-tweak-tool

Caps Lock を Ctrl として扱う、にチェックを入れる。

zsh

まずはシェルを変更。zshがどう良いかはググってくださいませ。

sudo apt-get install zsh
chsh

以前の環境から設定ファイルとhistoryファイルをホームディレクトリ以下にコピー。

日本語環境整備

zipアーカイブ中に日本語ファイル名があると、素のunzipコマンドだと変なファイル名になってしまうので、Japanese Teamによる追加パッケージを追加。
以下のURLを参考に。

https://www.ubuntulinux.jp/japanese

wget -q https://www.ubuntulinux.jp/ubuntu-ja-archive-keyring.gpg -O- | sudo apt-key add -
wget -q https://www.ubuntulinux.jp/ubuntu-jp-ppa-keyring.gpg -O- | sudo apt-key add -
sudo wget https://www.ubuntulinux.jp/sources.list.d/xenial.list -O /etc/apt/sources.list.d/ubuntu-ja.list
sudo apt-get update
sudo apt-get upgrade
sudo apt-get ubuntu-defaults-ja

SKK

SKKがあまりにも手に馴染んでしまっていて他の日本語入力を使えないんだよねえ。
SKKを使うやり方はいろいろあるけど、最近のUbuntu的には fcitx-skk を使うのがお勧めかしら。

sudo apt-get install fcitx-skk

インストール後は fcitx の再起動。
右上のキーボードをクリック→再起動。

skkを追加。
右上のキーボードをクリック→現在の入力メソッドの設定。
「+」ボタンを押して、skk を追加。

以前使ってたユーザー辞書をコピー。具体的には以下のファイルをコピーすればOK。

~/.config/fcitx/skk/user.dict

Emacs

世の中的にはvimなのかもしれないが、おじさんはemacsが慣れてるのよ。
w3mモードもついでに入れとく。

sudo apt-get install emacs
sudo apt-get install w3m-el

以前の環境から、 .emacs や自前の elisp ファイルをコピー。

Atom

markdown を読み書きするときは、Emacs より Atom のほうがプレビューできて便利。

sudo add-apt-repository ppa:webupd8team/atom
sudo apt-get update
sudo apt-get install atom

以前の環境から ~/.atom ディレクトリをコピー。

Firefox

以前の環境から ~/.mozilla ディレクトリをコピー。

Chromium

艦これは、Chromiumでやるほうが便利。
flashのプラグインもインストール。

sudo apt-get install chromium-browser

sudo apt-get install pepperflashplugin-nonfree
sudo update-pepperflashplugin-nonfree --install

以前の環境から、 ~/.config/chromium ディレクトリをコピー。
艦これが動くことも一応確認。

Skype

Ubuntuソフトウェアセンターのソフトウェアソースから「Canonicalパートナー」をソースに追加。

sudo apt-get update
sudo apt-get install Skype

以前の環境から、 ~/.Skype ディレクトリをコピー。

ScudCloud

Slackクライアントも追加。

https://launchpad.net/~rael-gc/+archive/ubuntu/scudcloud
sudo apt-add-repository -y ppa:rael-gc/scudcloud
sudo apt-get update
sudo apt-get install scudcloud

以前の環境から、 ~/.config/scudcloud ディレクトリをコピー。

指紋認証

以下のURLを参考にインストール。

http://zecheru.com/thinkpad-fingerprint-ubuntu-14-04/?v=24d22e03afb2

sudo apt-add-repository ppa:fingerprint/fingerprint-gui
sudo apt-get update
sudo apt-get install libbsapi policykit-1-fingerprint-gui fingerprint-gui

インストールしたら、fingerprint-gui を起動して、Fingerタブから指紋登録、、、、、と思ったら、4th Generation の指紋デバイスがうまく認識されてないな。
3rd Generation のときは、ログイン、スクリーンロック解除、sudo、なんかで普通に使えて便利だったんだけどなあ。
継続課題ってことで。。。。

gpointing-device-setting

ThinkPad の TackPad や TrackPoint の微調整をするときに便利に使えるツールなんだけど 16.04 では標準パッケージから外れてるっぽい。

マウストタッチパッドの設定で、ポインターの速度を速くして、タッチパッドをオフにしただけど、そんなに困ってないので、継続課題ってことで。
真ん中のボタンも正常に動作はしている。

4Kディスプレイ接続

3rd Generationと同じように普通に4Kディスプレイに表示できた。
手元のDELLのモニタだと、SSTモードだと駄目で、MSTを有効にする必要はあった。

ただ、起動時に接続していれば問題なく使えて、その状態からケーブルを抜いても問題ないんだけど、起動した後で4Kディスプレイに接続すると画面が固まることもある。
これも前と一緒の症状だな。

使ってみた感想

以前の環境の画面は 1920×1080 で、文字が小さいけど画面が広くて便利、と思ってたんだけど、今度の環境は 2560×1440。
さらに画面が広くなって、文字もすごーくちっちゃい!!
目が大変か、と思ったけど、意外と慣れるね。
でも画面が広いとマウスでのカーソル移動が大変。
タイル型ウィンドウマネージャーとか使ってみたほうが良いのかもなあ。

細かいソフトウェアのアップデートはあるので注意しなきゃいけないこともありそう。
たとえば、OpenSSHは、バージョンが7.2になって、ssh-dss のような Legacy なプロトコルは標準だと使えないようになってる。
まあ設定ファイルを書くか、コマンドラインで -oHostKeyAlgorithms=+ssh-dss のような指定をすれば大丈夫だけどね。

とりあえず生活環境が整ったので、連休後半はサーバをいじるよ!!

(参考)インストールの後のその他の設定

このへんを見るのがお勧め!!

Ubuntu 16.04 LTSをインストールした直後に行う設定 & インストールするソフト

コラム, ネットワーク

ごぶさたしております。ライトノベル好きのツチノコです。グレブナー基底に興味を持ち始めました

注意: ONIEインストールしたところ文鎮化しましたので手順見直しています

さて、MicrosoftがOCP SummitでSONiCというEthernet SwitchのOSを公開しました。
・SONiCを紹介しているMicrosoftのBlog: Microsoft showcases “Software for Open Networking in the Cloud (SONiC)”
・SONiCのgithub: Software for Open Networking in the Cloud SONiC

このSONiCのimageをbuildするのに少し手間取りましたので、手順を共有したいと思います。
・github上のbuild手順書: Build Switch Images – buildimage

以下の手順は完全版ではなく、今後修正がある可能性はあります(試行錯誤したこと、Dell S6000にインストールしてみるのはこれからというのが主な理由です)。

手順概略

1. Kernel buildの準備
2. Kernel build
3. Image buildの準備
4. Image build

1. Kernel buildの準備

Debian Jessie(8.3) x64なマシンを準備します。最初、Stretch(testing)でやっててはまりました。

https://github.com/Azure/sonic-linux-kernel/blob/master/build.shで利用されているpackageを入れます。

kernel buildに必要なpackageも入れます。

2. Kernel build

cloneしてbuildするだけ。時間がかかるので(手元の環境だと5時間)、夜中とかにやるのがいいと思います。

3. Image buildの準備

https://github.com/Azure/sonic-buildimage/blob/master/build_debian.shで利用されているpackageを入れます。

sudoerになります

4. Image build

git cloneします。

ONIE installer imageが依存するファイルをbuildします。initramfsなどのようです。

Imageをbuildします。build中にファイルのダウンロードなどを行うのでこちらも時間がかかります(30分くらい)。

うまくいけばImageが作られているはずです。

そんなわけでこの後、ONIEでインストールしてみます。

p.s. 魔王サスペンス劇場 土けむりダンジョン、美人勇者殺しがすごく気になっています。

CONBU, wifi, コラム, セキュリティ

くまがいです。CROSS2016 ご来場ありがとうございました。大盛況で楽しかったですね。会場無線 LAN を CONBU で提供していましたので、繋がらない報告がないか Twitter を追っていたら、こんな投稿を見つけました。

WiFi繋いだら現在地が秋葉原になってる #cross2016

CROSS2016 は横浜ですので、位置情報がおかしいですね。

Wi-Fi測位のしくみ

スマホが現在位置を取得する方法のひとつとして、Wi-Fi の BSSID(MACアドレス) を利用したシステムがあります。端末は、周囲に見えている Wi-Fi の BSSID をサーバに送りつけます。するとその BSSID に対応した位置が返ってきます。

簡単な仕組みですが、これを世界中で実現させるには途方もない労力が必要です。位置とそれに対応する BSSID のデータベースを構築するには、測位したい全ての場所へ行って無線 LAN を受信する必要があり、今後も更新していかなければなりません。

スマホが Wi-Fi AP の位置情報を収集している

Skyhook Wireless(2010年頃以前の iOS での利用で有名)は、ウォードライビング、車で移動しながら無線 LAN を受信することによってデータベースを構築したといわれていますが、現在 Google や Apple は、この情報収集をスマホユーザ自身にやらせています。

たとえば iOS では、近くの Wi-Fi アクセスポイントの情報とその位置を端末に保存しておき、定期的に Apple へ送信しています。

Apple は Wi-Fi 測位に関する API や、誤った位置情報の修正、オプトアウトの手段などの情報を公開していません。iOS 8 および iOS 9 のプライバシーと位置情報サービスについて の「Wi-Fi と基地局の位置情報のクラウドソーシングデータベース」で何をやっているのか書かれていますが、これ以外の公式情報は見つけられませんでした。

本当のところ何を送ってるんだろう

ここまでは比較的広く知られていることかもしれません。が、具体的にどのような情報がやりとりされているのかはあまり知られていません。

試しに、手元の iPhone がどんな情報を送っているのか観察してみようと思います。使ったのは (iPhone5s, iOS8.2.1), (iPhone5, iOS9.2.1), Burp Suite 1.6.32 です。ちょっと古い理由は特になく、たまたま手元にあったからです。

観察・収集編

我々の iPhone で収集された Wi-Fi と位置データが Apple のサーバへ送信されていく様子です。
pbcwloc_270_01
おっ、何か MAC アドレスっぽいものを送っているのを見つけた!?

pbcwloc_270_02
うわー! バイナリかよ、解散~ と思いましたがこれは Protocol Buffers でシリアライズされた何かのようです。JSON や XML のような人間にやさしいエンコーディングではないため一瞬諦めそうになりました。

Protocol Buffers はバイナリエンコーディングのシリアライズフォーマットで、データ構造はエンコーディングに含まれません。データ構造は別途 IDL(インタフェース定義言語) の .proto で定義して使うもので、エンコードされたデータからはデータ構造がよくわからないのです。

ちょっと .proto をでっち上げてみました。中を見ても何だか分からない項目がいっぱいあります。いくつかは iOS7 か 8 で増えたようです。

message WiFiAccessPoint {
required string bssid = 1;
optional int32 channel = 2;
optional int64 signal_dbm = 3;
message Location {
required double latitude = 1;
required double longitude = 2;
optional int32 unknown3 = 3;
optional int32 unknown4 = 4;
optional int32 unknown5 = 5;
optional int32 unknown6 = 6;
optional int32 unknown7 = 7;
optional int32 unknown8 = 8;
optional int64 unknown9 = 9;
optional int64 unknown10 = 10;
optional int32 unknown11 = 11;
optional int32 unknown12 = 12;
}
optional Location location = 4;
optional string application = 5;
optional int32 unknown7 = 7;
}
message SmartphoneToAppleRequest {
repeated WiFiAccessPoint ap = 3;
}&

実をいうと、このメッセージは2013年頃(iOS6.0)に一度解析したことがあります。それを使って、今回のブログで気楽なネタにしようと思ったら、内容が丸ごと変わっていて全然気楽じゃありませんでした!!!

この .proto でデコードしてみたところ、以下のような内容を Apple へ送信しているようです。

ap {
bssid: "74:3:bd:28:xx:xx"
channel: 4
signal_dbm: -89
location {
latitude: 35.6897295965
longitude: 139.770113602
unknown10: -1
unknown11: 7
unknown12: 0
}
application: "com.google.Maps"
unknown7: 0
}

このケースでは、収集した約300個の BSSID が Apple へ送信されたのを観察できました。無線LANについては BSSID, チャネル、電波強度らしきものが送信されていて、SSID は送信されていないようです。_nomap は考慮されていないようで、ssid_nomap という SSID を出してみたところ普通に送信されていました。Apple に関しては _nomap は効いていないようです。

lat/lng の座標以外には、位置情報をリクエストしたであろうアプリの Bundle ID らしきものが入っています。自分の場合は他に com.protogeo.Moves や com.google.ingress などが入っていました。

その他に、端末の機種名と OS のバージョンも送っていますね。端末を個別に識別するようなものはなさそうです。HTTP ヘッダにも怪しいものはありません。認証もなく、匿名で突然送りつけているようです。

位置情報が狂う原因

AP を持ってオフィスの引越しをすると、引越し前の位置が表示されてしまうことがあります。オフィスに設置していた AP の BSSID に対応する位置情報が更新・収集されていないのが原因ですが、オフィスはともかく、最近は個人宅ではあまり聞かない現象のように思います。なぜオフィスの引越しでよく起こるのでしょうか?

オフィスには複数の AP があり、複数の BSSID が受信できるとします。すると、引越し以前から近隣にある AP よりそれらを優先して使われてしまうのかもしれません。また、都心のオフィスでは空が開けていない場所が多く、GPS の電波が受信しにくいため、BSSID と位置情報が更新されにくいのかもしれません。

更新に関しても、端末の識別もなく収集しているため、ある程度のデータが溜まって確信度が高くならないと有効にならないはずです。

収集されたデータがどのように運用されているのかは調べようがなく、曖昧な記述になってしまいましたが、きっと大きく外してはいないと思います。

観察・利用編

普通に現在位置を取得するパターンです。iOS で現在位置を取得するアプリ(ここでは Google Maps)を起動してみます。

clls_01_03
BSSID らしきものを送っていますね。これらの BSSID は確かに現在、周囲に見えているものです。

clls_02_03
位置情報が含まれたレスポンスが返ってきました。結構大きいようです。送った BSSID の他にも大量に何かがくっついています。例によってバイナリですが、これも Protocol Buffers ですので解析してみます。

でっちあげた .proto です。

message WiFiAccessPointResp {
required string bssid = 1;
message Location {
required int64 latitude = 1; // * 10e-9
required int64 longitude = 2; // * 10e-9
optional int32 unknown3 = 3;
optional int32 unknown4 = 4;
optional int32 unknown5 = 5;
optional int32 unknown6 = 6;
optional int32 unknown7 = 7;
optional int32 unknown8 = 8;
optional int32 unknown9 = 9;
optional int32 unknown10 = 10;
optional int32 unknown11 = 11;
optional int32 unknown12 = 12;
}
optional Location location = 2;
optional int32 channel = 21;
}

message AppleToSmartphoneRequest {
optional int32 unknown1 = 1;
optional WiFiAccessPointResp ap = 2;
optional int32 unknown3 = 3;
optional int32 unknwon4 = 4;
}

message AppleToSmartphoneResponse {
repeated WiFiAccessPointResp ap = 2;
}

収集編での構造と同じかと思いきや微妙に違う………。lat/lng は float じゃなくて固定小数点に変わっているしタグもずれています。。これも 2013 年頃解析したものとは違います。

デコード結果は以下です。

ap {
bssid: "10:6f:3f:6:xx:xx"
location {
latitude: 3565078352
longitude: 13972113022
unknown3: 42
unknown4: 0
unknown5: 21
unknown6: 14
unknown11: 62
unknown12: 69
}
channel: 3
}

位置情報を取得するのに送信した周囲の BSSID の位置情報は、このようにして返ってきました。lat/lng 以外にも何かついてきているようです。

このケースでは、リクエスト時に BSSID を複数(12個)送信しています。レスポンスには、リクエスト時に送信した BSSID 以外にも周辺の BSSID と位置情報が100個ほど含まれていました。iOS, locationd がこのレスポンスから実際の位置情報をどのように計算しているかはわかりません。

BSSID から位置情報を取得したいならもっと簡単な方法がある

Apple のこれを使えば BSSID から位置情報を取得できる!と思うかもしれませんが、そんな面倒でグレーなことをしなくても、もっと簡単で正当な方法があります。

Google Maps Geolocation API で BSSID から位置情報を取得できます。
geolocation
ブラウザからも使われています。

プライバシーの問題

Wi-FiのMACアドレスはもはや住所と考えるしかない 高木浩光@自宅の日記 2011年11月26日

個人で設置している AP の MACアドレス(BSSID) から位置情報が引けるとなると、BSSID は住所に相当するのではないかという指摘があります。これに対し、Google Maps Geolocation API は「2つ以上のBSSIDが含まれないリクエストでは位置情報を取得できない」としています。

The request body’s wifiAccessPoints array must contain two or more WiFi access point objects. macAddress is required; all other fields are optional.

特定の BSSID から位置を調べようとした場合、その近隣の BSSID なんて事前に分からないので、位置情報が取得できません。これで多少は安全になります。一つの AP が複数の BSSID を吹いているなど、推測されやすい状況はありえますが。

結論

一般的に AP が設置されてもすぐに位置情報に反映されるわけではありませんが、カンファレンスやイベントなどで一時的に設置された AP でも、その情報がたくさんの来場者のスマホから送信されてしまい、それなりに確信度の高い位置情報として扱われてしまうのかもしれません。AP は複数台設置されるため、測位の場合でも優先されてしまうのかもしれません。

今回は Wi-Fi 測位のみを扱いましたが、その他 GPS(GNSS)や携帯電話基地局での測位とハイブリッドになっていることがほとんどであり、その挙動は多様です。大きく位置が狂うことが有り得るのは Wi-Fi 測位の特徴といえます。

他の測位手法については、他の機会に触れたいと思います。
それと Android も調べたかったのですが力尽きました。

huawei, コラム

前回からの続き。

ショールーム見学の後はランチタイム。
まずは社員食堂にお邪魔しました。

IMG_0991IMG_0993IMG_0994IMG_0996IMG_0997IMG_1003IMG_1004

4万6000人が働くキャンパスだけあって食堂も広い!!
人もすごく沢山。
メニューも沢山。
しかもおいしそう。
社員の年齢層は低めで活気にあふれてました。
写真をクリックすると大きくなるので開いてもらうと様子がわかるかと思います。

食堂の横にはセブンイレブンもありました。
今の為替レートだと、1元=20円、ぐらいなので日本との価格差はほとんどありません。

IMG_1008IMG_1013IMG_1015IMG_1016

パン屋さんもありました。
こちらもおいしそう。
やっぱり値段は日本と変わりません。

IMG_1009IMG_1017IMG_1019

でも我々はここでは食べずに食堂の2階に移動。

エスカレータを上がると美女3名の生演奏でお出迎え。

IMG_1023

Huaweiには接待部という部署があり彼女達はそこの所属なんだとか。

我々が2階で食べたランチも接待部所属の一流シェフの手によるもので、大変美味しゅうございました。

IMG_1033IMG_1037IMG_1041

ちなみに「接待部」は接待だけをしているわけではなく、

  • ショールームでの説明
  • コールセンターでの一次対応
  • 取引先とのアテンド対応

等の業務も行なっていて、どんな新人でも必ず接待部に一度は配属されるそうです。
新人はそこでHuaweiの製品知識やカスタマー対応なんかを学ぶとのこと。

おいしいものを食べた後は会議室でエンジニアとディスカッション。
次回に続きます。

PAGE TOP