mitmproxy をBASIC認証付きで利用する
mitmproxyはブラウザとウェブサーバの通信内容を調査するときにとても便利なツールですよね。手元の環境で自由に上げ下ろしできるので、とても助かります。
さて、とあるHTTPクライアントアプリ（ネイティブアプリ）を試験するときに認証付きのHTTPプロキシとの組み合わせを検証する必要が出てきました。こういう試験のために squid とかをまじめにセットアップするのは工数が見合わないので、もっと楽にやりたい。というわけで、これを mitmproxy でやってみることにします。
準備するもの
mitmproxy
mitmproxy はこのページの release のリンク先からダウンロードできます。macOS や Linux 向けの場合は python が必要ですけど、Windows の場合はリンク先から installer や zip をダウンロードするだけでOKです。installer と zip の違いはファイルを自動で配置してくれるかどうか、だけです。だから通常は zip で良いのではと思います。私の場合はこの手の類のポータブルなバイナリは Google Drive に放り込んでおき、どの作業環境からでもすぐに使えるようにしてます。
mitmproxy - home
実行方法
Windows の方は mitmweb.exe --htpasswd パスワードファイル と指定すればOKです。これで mitmproxy が認証付きで動作します。
Internet Information Server を完全停止させる手順
自分用のメモ
停止
net stop WAS
開始
net start W3SVC
OpenWRTの代わりにLEDEのRasPi3向けパッケージを入れてみた
けど結論から言えば自分の要件には合わんなコレ。
まず、そもそもの話からいうと、LEDEはOpenWRTから fork したプロジェクトらしいです。
LEDE Project: Welcome to the LEDE Project
で、OpenWRT では RasPi3 向けのインストールイメージが出てこないのですが、LEDEでは RasPi3向けのイメージが出ておる。
https://lede-project.org/toh/views/toh_fwdownload
こりゃええなあと思って入れてみたのですが、WPA-EAP関連のパッケージが全く見当たらんので自分の要件に合わなすぎ。
PebbleのBluetooth接続が不安定になったのでファクトリーリセットをかけてみた→安定したかも
Pebble TimeのBluetooth接続が頻繁に切れてしまい、通知が受けられないことが出ました。そこでファクトリーリセットをかけたら安定したような気がするので、手順をメモとして残す。
ファクトリーリセットの方法
Pebbleのファクトリーリセットの方法は2種類ある。
- メニューから選んでリセットする方法
- 左ボタン、右上ボタン、右中ボタンを同時に長押しする方法
どんなときにファクトリーリセットが必要か
- Pebbleをクリーンな状態にしたいとき
- Pebbleをだれかに譲るとき
ファクトリーリセット後にすべきことは？
iOSの場合は Bluetooth 設定から Pebble Time を削除する必要があります。Android も多分同じだと思うけど手元に Android 4.x 以降のデバイスがないからよく分からない。
実際に行った方法は？
私が行って効果が出ているように思えるのは、「左ボタン、右上ボタン、右中ボタンの同時長押し」です。メニューからのファクトリーリセット実行だけではBluetooth接続の不安定さが回復しませんでした。
基本的な話は
help.getpebble.com
さまざまな元素の同位体がどのように崩壊するかを調べてみた
サイエンス系のネタは本当は大好きなのですけどブログではほとんど書いてませんでした。
さて、ちょいと理由があって、どんな元素がどのように崩壊するかの資料を探してみたくなりました。
そもそも元素というの原子核に陽子と中性子があるわけですが、中性子の数によって安定性が違う、というのは高校生の理科でも学ぶ範囲ですよね。安定性が悪い原子核はその安定度に応じて一定の確率で壊れていくわけです。壊れる時にはα粒子（ヘリウム4の原子核）やβ線（電子や陽電子）などを放出するということです。
そして安定的なものを安定同位体、不安定なものは放射性同位体と言われます。
さて、放射性同位体がどのように崩壊するか、という一覧の情報は Wikipedia には見当たらないのですが、いろいろ探してみると実はIAEAのサイトにこんな図表がありました。
Livechart - Table of Nuclides - Nuclear structure and decay data
この図表は縦向きが原子番号順、横向きには中性子数の違いによる同位体が配置されています。スクリーンショットはウラン235を選択した状態です。そしてその元素で起こりやすい崩壊の種類によって色分けされています。これをみると安定同位体より質量が重い場合はβ-崩壊になり、質量が軽い場合はβ+崩壊またはα崩壊が起こりやすいように見えます。
こういう可視化が見たかったので、私のニーズにはこれがピッタリ合っていました。
C++Builderの浮動小数点のバイト数と精度を調べてみる
自分用の覚書。
浮動小数点の有効桁数が気になったので調べて表にしてみた。
Subject は C++Builder と書いているけど、Delphi も基本的に同じ。
なお、比較のために Linux gcc の内容も記入している。
結果はこちらの表の通り。
有効桁数は log10(2^2進数桁数) で算出した。
| 型 | バイト数 | ビット数 | 指数 | 仮数 | 2進数桁数 | 10進数有効桁数 |
| float | 4 | 32 | 8 | 23 | 24 | 7 |
| double | 8 | 64 | 11 | 52 | 53 | 15 |
| long double (Windows 64bit, iOS 32bit, 64bit) | 8 | 64 | 11 | 52 | 53 | 15 |
| long double (Windows 32bit) | 10 | 80 | 15 | 64 | 64 | 19 |
| long double (Linux 32bit gcc) | 12 | 80 | 15 | 64 | 64 | 19 |
| long double (Linux 64bit gcc, macOS) | 16 | 128 | 15 | 113 | 113 | 34 |
long double について、Windows 32bit だけは拡張倍精度であり、その他は基本的に倍精度です。ただし macOS だけは4倍精度です。
このように、プラットフォームごとに long double のデータサイズが大きく異なることに注意が必要です、。
Win32 の long double のバイト数が大きいのは浮動小数点処理に FPU を使うことにあるようです。
これに対して Win64 は SSE を使っていることで FPU 利用時よりもバイト数が小さくなっているそうです。
http://docwiki.embarcadero.com/RADStudio/Berlin/ja/浮動小数点演算について
Linux の long double が32bitで 12バイトなのは……イマイチよくわからないけど、sizeof(long doble)すると12が返ってくるので、12というのはおそらく事実。ただし指数、仮数に関する一次ソースが見当たらなかったので、この情報は Win32 と Linux64bit の比較から推測しています。 いろいろ調べてみると、データサイズとしては12バイトだけど実際には10バイトしか使っていないらしい。10バイトで処理すると遅くなるからでは、と推測している方がいらっしゃる。
浮動小数点演算ではまった話 - bkブログ
melancholic afternoon
自分が描くコードではこの違いが影響するほどの精度で数値を扱うことをしないので平気だけど、状況によっては問題が出ることもあるだろうから、実数を扱うコードを書くときは気をつけたい点かも。
RaspberryPi3用に買った3枚のmicroSDHCカードをベンチマークしてみる
microSDHCって公称スペックが同じなら、どれ買っても同じなのでは？
ええ、私もそう思っていましたよ。でも、どうもけっこう違うっぽい。今回は新規に3種類のmicroSDHCカードを調達する必要が出てきたので、3つとも違うカードを入手して速度を測ってみることにします。
使用した SDリーダ
今回は SDリーダも新調する必要があったので、USB3.0対応のこちらのリーダを買ってみました。
速度を測ってみる
速度は2種類の方法で測ってみます。一つは macOS 向けの Blackmagic Disk Speed Test で測る方法。もう一つは Raspbian Jessie のイメージの書き込み速度を測る方法。
Blackmagic Disk Speed Test の結果
| item | write | read |
| TOSHIBA MU-F016GX | 12.6MB/s | 43.6MB/s |
| Lexar LSDMI16GBJPR300A | 10.1MB/s | 80.6MB/s |
| Transcend TS16GUSDU1PE | 13.0MB/s | 85.9MB/s |
Transcend LSDMI16GBJPR300A が読み書き共に最もよい。Lexar LSDMI16GBJPR300A は書き込み速度が少し劣る。読みは速い。TOSHIBA MU-F016GX は書き込みは良いけど読み込みが他の半分くらいしか出ない。
Raspbian Jessie の書き込み
Raspbian Jessie の書き込み速度は macOS 上で以下のように実行して計測しました。pv は Homebrew からのインストールです。pv を通過するデータの流れる速度や処理時間を表示してくれるのでとても便利なのです。
pv 2016-11-25-raspbian-jessie.img | sudo dd of=/dev/rdisk2 bs=1m 4.07GiB 0:07:12 [9.64MiB/s] [========================================>] 100%
※実際の書き込みでは上記処理を内包した write_img2sd.sh で行っています。
そして結果はこちら。さきほどのベンチマークと概ね同じ結果が出ました。
| item | time | write |
| TOSHIBA MU-F016GX | 05:15 | 13.2MiB/s |
| Lexar LSDMI16GBJPR300A | 07:12 | 9.64MiB/s |
| Transcend TS16GUSDU1PE | 05:17 | 13.1MiB/s |
単に処理速度だけをみると、Transcend の速度が良さげですねえ。
なお、これらの3枚はいずれも Raspbian が起動できることは確認しました。
