オフィスのリモート会議の環境を整えた
これまで Revolabs FLX UC 500 をつかっていたが、人数が増えたり (10+) 会議室が広くなるにしたがって部屋の端にいる人たちの声を拾いにくくなってしまった 1。あと諸々あって以下の機材を導入した。
YAMAHA YVC-1000 (スピーカーフォン)
https://sound-solution.yamaha.com/products/uc/yvc-1000/index
この製品はマイクを 5 台まで数珠つなぎにすることができる。とりあえず 2 台で運用しているが 10 人強の会議ではまったく問題なく、将来もっと人数が増えたときにはマイクを増設することもできる。
Logicool PTZ Pro 2 (カメラ)
Logicool PTZ Pro 2 Video Conference Camera & Remote
リモコンでパンやチルト、ズームすることができる。
Zoom (ビデオ会議サービス)
Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
機材ではないけど。他のサービスに比べて品質がよく感じる2。あと Speaker View がとても気に入っていて、これはなにかというと参加者全員の映像を同じサイズでタイル状に表示する機能だ。Zoom 以前は発言者のみが大きく表示され、発言者以外の様子がわからないという問題があった。
Shure SM58SE (ボーカルマイク)
YVC-1000 は音声入力端子 (RCA) を備えており、マイクを接続すると本体スピーカーで拡声しつつ Zoom でリモート参加者にも配信することができる。全社会議のような大きな会議で使用している。
余談だが、スイッチ付きのモデルにしたところ話者が知らないうちにスイッチを切ってしまうことが多々あり、慣れない人が使う場合はスイッチ無しにしたほうがいいのかもしれない。
Shure QLXD24/SM58-JB (ワイヤレスマイク)
大きな会議の質疑応答などで前まで出てきてもらうのは大変なので、ワイヤレスマイクを受け渡すようにした。
選定にあたっては、B 帯 (800 MHz 帯) のデジタルの機器で探すことにした。まず周波数帯だが、今回のようなユースケースでは B 帯と 2.4 GHz 帯の二択に絞られる3。2.4 GHz 帯は Wi-Fi 等と干渉する可能性があり、IT 企業においては厳しいと判断した。また、アナログは混信やノイズがはいりやすいといった問題がある4。
ちなみに、YVC-1000 の音声入力はステレオなので R と L があり、それぞれにマイクをつなぐことで 2 本まではミキサーなしでミキシング (?) することができる。今回は有線マイクと無線マイクをこの方法で接続した。強引な気もするが、YVC-1000 のマニュアルに書いてあるのでそういうものらしい。
Slack でチャンネルが作成されたら通知する
いつの間にか新しいチャンネルがつくられていること、ままある。
仕組み
- Slack の Events API (Event Subscriptions) で
channel_createdを GAS に通知する - GAS で Slack に投稿する
同じやりかたで emoji を通知したりもできる。
GAS のスクリプト
var webhookUrl = 'https://hooks.slack.com/services/xxxxx/xxxxx/xxxxx'; function doPost(e) { var data = JSON.parse(e.postData.getDataAsString()); if (data.type === 'url_verification') { var content = { 'challenge': data.challenge }; return ContentService.createTextOutput(JSON.stringify(content)).setMimeType(ContentService.MimeType.JSON); } if (data.type === 'event_callback' && data.event.type === 'channel_created') { var payload = { 'text': 'New channel <#' + data.event.channel.id + '> was created!' }; UrlFetchApp.fetch(webhookUrl, { 'method': 'post', 'contentType': 'application/json', 'payload': JSON.stringify(payload) }); } }
同僚と開発環境共有会をした
弊チームは全員がリモートで働いていて、日常的に同僚の開発環境を見ることがないので、極稀に発生するメンバーが物理的に集う機会に開発環境の共有会 (という名の自慢会) をした。
git push --force の代わりに --force-with-lease を使うと安心ということを学んだ。あと、VSCode と RubyMine が便利そうだった、多分 Vim 断ちできないんだろうけど。
自分が提供できた情報は以下。
tmux のウィンドウ名を自動でカレントディレクトリ名にする
set-window-option -g automatic-rename on
set-window-option -g automatic-rename-format "#{?pane_in_mode,[tmux],#{b:pane_current_path}}#{?pane_dead,[dead],}
Vim の 0 レジスタを覚えると便利
Vim でコピペするときの Tips - 反省はしても後悔はしない
C-{p,n} で入力中の文字列からはじまるコマンド履歴を表示する
autoload -Uz history-search-end zle -N history-beginning-search-backward-end history-search-end zle -N history-beginning-search-forward-end history-search-end bindkey '^P' history-beginning-search-backward-end bindkey '^N' history-beginning-search-forward-end
macOS のドキュメントビューア
Dash for macOS - API Documentation Browser, Snippet Manager - Kapeli
2018年
家のネットワークを Cisco にした
AP が1台しかないのになぜか WLC がある。
キャンプにいくようになった
某アニメの影響。3月末に飯能で初キャンプに挑むが寒すぎて全く眠れず太陽のありがたみを知る。
結婚した
紙切れ一枚で人の名字が変わってビビる。
こじんまりと、親兄弟だけで式も挙げた。以前から一緒に暮らしていたので籍をいれても特になにも変わらなかったのだが、式を挙げたら結婚した実感がわいてきた。挙げる前は正直めんどくさかったけど、親も喜んでいたし結果としては挙げてよかった。
新婚旅行にいった
3日で洋食に飽きてフィンランドの和食を探し始める。フィンランドの和食事情にとても詳しくなった。
これは手首 pic.twitter.com/tQWaTxfpgW
— やまま (@kirikiriyamama) July 16, 2018
食洗機を買った
最高。みんな買ったほうがいい。
RubyKaigi でスタッフをした
ネットワーク班で、無限にケーブルの敷設などした。Wi-Fi は筋肉。
1000 assoc を超える規模のネットワークに携わることができて楽しかった。
転職した
スマービー という、ママ向けの EC サイトを運営する会社に転職した。
フルリモートで働いているのだが、コミュニケーションが基本的にオンラインで完結するようになっていて感動した。これで場所に縛られない生活になったのでそろそろ田舎に引越したい。
Apple を見限った
これ以上ハードウェアで振り回されたくないので (e.g. Touch Bar)。PC は Ubuntu on ThinkPad にした。
総合的な体験でいえば Apple のほうがよかったけれど、ThinkPad のハードウェアや Linux デスクトップ環境はとても気に入っている。
友人の結婚式でアプリをつくった
高専時代の友人が結婚した。彼らしい、とてもいい式だった。
何人かで結婚式で撮った写真を共有するためのウェブアプリをつくった。結婚式の写真、各々が撮ってそれで終わりなイメージがあるので、みんなが撮った写真を集めて届けることができてよかった。
少しだけ技術的な話をするとサーバは DB に状態を持たせないことを意識してつくった。なんかちょっとこじらせた設計になった気もするけど趣味コードということでひとつ。
PAY.JP のスタブライブラリをつくった
1年半くらい前に。
最近コミットしていないけど今でも特に問題なく使えると思う。 WebPay のスタブライブラリ 1 がとても好きで、それを参考に実装した。
CloudFormation で Subnet に IPv6 CIDR を設定する
Resources: Vpc: Type: AWS::EC2::VPC Properties: CidrBlock: 10.128.0.0/16 VpcCidrBlock: Type: AWS::EC2::VPCCidrBlock Properties: AmazonProvidedIpv6CidrBlock: true VpcId: !Ref Vpc Subnet: Type: AWS::EC2::Subnet Properties: CidrBlock: 10.128.0.0/24 Ipv6CidrBlock: !Select - 0 - !Cidr - !Select - 0 - !GetAtt Vpc.Ipv6CidrBlocks - 1 - 64 VpcId: !Ref Vpc
ref
勤務先の Wi-Fi 環境を改善した
2.4 GHz 帯はもう諦めている。
前提
駅前のガラス張りのオフィスビル
やったこと
周波数帯の調整
W53 (5250 - 5350 MHz), W56 (5470 - 5725 MHz) は気象レーダーなどにも使用されており、それらを検出した場合、レーダー波を優先するために一時的な停波やチャネルの変更を行う必要がある1。恐らく事前の調査 (サイトサーベイ) は行われておらず、レーダー波の影響がないことを保証できないため、W52 (5150 - 5250 MHz) のみを使用することにした。
基本的には W53, W56 の使用は避けたほうが無難である。特に W56 は屋外利用が可能であり、公衆 Wi-Fi にも利用されているため遠方飛来も多い。
帯域幅の調整
調整前は 80 MHz に設定されていたのだが、今回のように外的要因の多い環境でボンディングを安定して運用することは非常に難しい。また、それ以前の問題として社内の AP 同士で干渉を起こしていた。そこで、帯域幅を 20 MHz にしたところかなりの改善がみられた。
大抵の場合、帯域幅は 20 MHz で十分に思える。確かにスループットは上がるかもしれないが、それよりも安定して通信できることをを優先したほうがストレスが少ない。
RSSI (信号強度) で足切り2
Wi-Fi のデータレートは RSSI に応じてリアルタイムに変化する。つまり、電波状況が悪くなると伝送速度が落ちるということだ。また、Wi-Fi は遅いクライアントがいると全体が遅くなるため3、RSSI で足切りをして遅いデータレートで通信させないようにする4。様子を見ながら -74 dB で足切り (ちょっと甘め)。これもかなり改善に寄与した。
パワーレベルの調整
調整前はパワーレベルが最大に設定されていた 。これはクライアントが (設計者の) 意図しない AP に接続してしまう原因にもなるためパワーレベルを落とす。
今回はパワーレベルを最弱にしたが、それでも時折クライアントが遠方の AP に接続しにいってしまうことがある。これ以上の改善を図るには、AP の配置の見直しや指向性アンテナの導入が必要になる。
チャネルの調整
自動設定になっていたがあまりかしこくなかったため、隣接する AP 同士でチャネルが被らないように手動で設定しなおした。
結果
SNR がかなり改善され、ルーターへの ping が 1 ms 台で返ってくるようになった。自分でもちょっとびっくりするくらい快適になっている。
Wi-Fi は目に見えない電波を扱うため非常に扱いが難しい。今回は既存の設備での調整となったが、本来は予めサイトサーベイを行いそれに基づいて設計を行うことが望ましい。
