シェルスクリプトを書くときにいつもやるやつを調べた
bash のシェルスクリプトを書くときに、いつも脳死で以下をやっている。(同僚が整備してくれたものをコピペしている) エディタなり CI で shellcheck をまわす set -euxo pipefail と冒頭に書く こんな感じ #!/bin/bash set -euxo pipefail いつまでもコピペではさすがにアレなので、意味を調べたメモ。 shellcheck koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts イケてない書き方に警告を出してくれる それぞれの警告にはエラーコード割り振られていてとても便利 エラーコードごとに正誤例、解説が書かれているのでわかりやすい SC1000 の例 CI もそうだし、エディタのプラグインも充実 しているのでとりあえず入れておくと良い set
tcpdump で DNS クエリ数を確認する
VPC DNS スロットリングが、Amazon が提供している DNS サーバーへのDNS クエリの失敗の原因となっているかどうかを判断する を読んでいて、tcpdump でキャプチャしたパケットをファイルに落とし、それを読み込んで DNS のクエリ数を分間で集計する例が記載されていた。 このページの本論も興味深いが、苦手な tcpdump の使い方は地道に身に着けて行こうと思い調べた内容をメモ。と言っても man を読んだだけだが、-w オプションに加えて便利なファイルのローテーションを行う機能などは知らなかったので勉強になった。 ネットワークインタフェースの一覧を確認する ifconfig… とついやってしまいそうになるが、ip コマンドを使ったほうが良い。手元の Ubuntu 20.04 (Vagrant) には ifconfig はデフォルトでは入ってなさそうだった。 If you
簡単なサーバを実装しながら WebSocket のキャッチアップ
実用ではなく学習目的で WebSocket の簡単なサーバを書きつつ、その後 RFC で仕様の背景を理解する流れがいい感じだった。 先日読んだ ハイパフォーマンスブラウザネットワーキング で取り上げられていたプロトコルについて深堀りしていこうと思い、一番仕様が薄そうな WebSocket をとっかかりとして選んだ。詳細の理解と、この本の刊行後にあった動きをキャッチアップすること、そして周辺の技術や仕様にも yak shaving 的に枝を広げていきたいなと言う意図。 キリが良いところまで来たので、整理のため一度まとめる。 進め方 WebSocket は 仕様がまとまってからもう 10 年くらい経っている ので、いきなり RFC から入るのではなく MDN でざっと概要と API を知るところから始めた。中でも Writing WebSocket servers - Web APIs | M
Google の Design Doc について
GoogleのDesign Docについて調べました．Design Docとは，Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメントです． 一般的にDesign Documentというと，設計仕様書のことをさすようです．設計仕様書はソフトウエアのシステム的な設計がどのように行われているかを記したドキュメントです．一方でGoogleのDesign Docは，あるソフトウエアについて，何を・なぜ・どのように作るかを記したもののようです．両者ともあつかっている対象や，対象としている読者が少しずつ異なっています．このエントリーではGoogleのDesign Docについて扱います． Design Docの内容 Design Docについては，Googleの鵜飼文敏さんによる以下のプレゼンテーションで触れられています． 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」
zsh の fc ビルトインコマンド
fc はコマンドの履歴操作をおこなう汎用的なコマンドで, たとえば history は zsh だと fc -l のエイリアスだったりする. history のように普通に履歴を表示するだけだったら -l オプションをつける. -n でコマンドの通し番号を表示しない -d でコマンドが実行されたタイムスタンプ. -d は時刻だけだが -f なら日付もつく. -E や -i で違う日付フォーマットになる オプションのあとにはどこからどこまでの履歴を対象にするかという 2 つの数字を渡せる. ちょうど python の配列スライスのように開始終了位置を渡せるし, 負の値だと末尾からのカウントになる. 直近 5 つだったらこんな感じ $ fc -ln -5
Google JavaScript Style Guide 和訳をリビジョン 2.93 にあわせて修正しました
Google JavaScript Style Guide 和訳 Google JavaScript Style Guide の本家の更新に和訳も追従した。 主な変更点 クリティカルな修正が多かった。そもそもの言語仕様の間違いが二点と、脆弱性につながるルールの修正。 NaN == NaN が true になるという 間違った記述 の修正 セミコロン省略時の自動挿入について。二項演算子の前には自動挿入されないが、されるという前提のルールになっていた。そのためルールの必然性がなくなってしまった。 その旨をコメントに記載しつつ、一貫性のため過去と同じルールでこれからも行くことになった。 eval() の利用を JSON のパースに利用することを禁止。普通に JSON.parse() を推奨するように。 JSON を eval() でパースすると、悪意のあるコードが実行される脆弱性になる。その旨も
ブラウザのバグを見つけたときにやること
paulirish/browser-logos · GitHub バグを見つける 表示系のものならスクリーンショットをとっておく すでに報告されていないか調べる ブラウザごとのバグトラッカーで検索してみる サポートフォーラムなどコミュニティに相談してみる ブラウザの種類とバージョンの絞込み 他のブラウザでは発生するか. 他のバージョンでも発生するか (stable を使っているなら beta や nightly でも見てみる等) テストケースの最小化 バグを再現させる最小のテストケースを作ります 今回出会ったのは表示系のバグだったので, html / css を削りながら現象を再現させていき, 同じ現象が起こる最小の html を作りました バグの報告先とフォーマットの確認 ブラウザごとにバグ報告のガイドラインがあるはずなので, それを読めばどのように報告すればよいかわかるはずです chr
Sinon.js Code Reading
モジュールのロードまわり lib/sinon.js がモジュールのエンドポイント sinon object の作成、環境に応じた初期化、ユーティリティメソッドの定義を行う spy や mock などの機能毎にファイルが分かれる lib/sinon/*.js に配置 lib/sinon/spy.js など sinon.js 大きくは以下のように sinon object を作って返す。 var sinon = (function() { function somePrivateFunction() {}; var sinon = { foo: function foo() {} }; return sinon; }()); node の場合、ブラウザの場合、busterjs の場合で異なった初期化を行う。 node の環境かどうかの判定は module.exports の有無で行う。 var
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
