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月末に飯能で初キャンプに挑むが寒すぎて全く眠れず太陽のありがたみを知る。

f:id:kirikiriyamama:20190110000600j:plain
成田でキャンプしたときの様子

結婚した

紙切れ一枚で人の名字が変わってビビる。

こじんまりと、親兄弟だけで式も挙げた。以前から一緒に暮らしていたので籍をいれても特になにも変わらなかったのだが、式を挙げたら結婚した実感がわいてきた。挙げる前は正直めんどくさかったけど、親も喜んでいたし結果としては挙げてよかった。

新婚旅行にいった

フィンランドエストニアにいった。

3日で洋食に飽きてフィンランドの和食を探し始める。フィンランドの和食事情にとても詳しくなった。

食洗機を買った

最高。みんな買ったほうがいい。

RubyKaigi でスタッフをした

ネットワーク班で、無限にケーブルの敷設などした。Wi-Fi は筋肉。

1000 assoc を超える規模のネットワークに携わることができて楽しかった。

f:id:kirikiriyamama:20190110205522j:plain
無限はんぺん

転職した

スマービー という、ママ向けの EC サイトを運営する会社に転職した。

フルリモートで働いているのだが、コミュニケーションが基本的にオンラインで完結するようになっていて感動した。これで場所に縛られない生活になったのでそろそろ田舎に引越したい。

Apple を見限った

これ以上ハードウェアで振り回されたくないので (e.g. Touch Bar)。PC は Ubuntu on ThinkPad にした。

総合的な体験でいえば Apple のほうがよかったけれど、ThinkPad のハードウェアや Linux デスクトップ環境はとても気に入っている。

友人の結婚式でアプリをつくった

高専時代の友人が結婚した。彼らしい、とてもいい式だった。

何人かで結婚式で撮った写真を共有するためのウェブアプリをつくった。結婚式の写真、各々が撮ってそれで終わりなイメージがあるので、みんなが撮った写真を集めて届けることができてよかった。

少しだけ技術的な話をするとサーバは DB に状態を持たせないことを意識してつくった。なんかちょっとこじらせた設計になった気もするけど趣味コードということでひとつ。

github.com

PAY.JP のスタブライブラリをつくった

1年半くらい前に。

github.com

最近コミットしていないけど今でも特に問題なく使えると思う。 WebPay のスタブライブラリ 1 がとても好きで、それを参考に実装した。


  1. WebPay のサービス終了に伴い GitHub からは消えてしまったのだが

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

Fn::Cidr - AWS CloudFormation

勤務先の 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 は目に見えない電波を扱うため非常に扱いが難しい。今回は既存の設備での調整となったが、本来は予めサイトサーベイを行いそれに基づいて設計を行うことが望ましい。


  1. DFS (Dynamic Frequency Selection)

  2. MCS Index を指定する機能はなかった

  3. 無線通信は空間が伝送媒体となるため複数のクライアントが同時に通信することができず 、ある瞬間は特定のクライアントが時空間を占有している (CPU のタイムシェアリングに近い考え方)。遅いクライアントがいるとそのクライアントが長時間にわたり時空間を占有してしまうため、全体の速度が低下する。

  4. 電波状況が悪い遠方の AP に接続してしまうことを防ぎ、近隣の AP に接続するようにする