同僚と開発環境共有会をした
弊チームは全員がリモートで働いていて、日常的に同僚の開発環境を見ることがないので、極稀に発生するメンバーが物理的に集う機会に開発環境の共有会 (という名の自慢会) をした。
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 は目に見えない電波を扱うため非常に扱いが難しい。今回は既存の設備での調整となったが、本来は予めサイトサーベイを行いそれに基づいて設計を行うことが望ましい。
Rails + CircleCI で MySQL の utf8mb4 をつかう
前提
ActiveRecordをutf8mb4で動かす - Qiita
気合でコンテナ上の MySQL の設定を変更する
circle.yml
database: override: - mysql -u root -e 'set global innodb_file_format = Barracuda' - mysql -u root -e 'set global innodb_file_per_table = 1' - mysql -u root -e 'set global innodb_large_prefix = 1' - bundle exec rake db:create db:schema:load --trace