uetchy/uechi.io
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

complete revamps
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse Source
This commit is contained in:
uetchy
2022-12-24 03:20:02 +09:00
parent aca29317c6
commit 9a9c2343d1
66 changed files with 13682 additions and 4599 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
source/_posts/2019/bose-noise-cancelling-headphones-700レビュー.md
View File

@@ -2,35 +2,36 @@
date: 2019-10-25 19:49:01 +0900
title: Bose Noise Cancelling Headphones 700レビュー
---
Bose Noise Cancelling Headphones 700を使い始めて一ヶ月が経ったので、現時点での印象をまとめる。
Bose Noise Cancelling Headphones 700 を使い始めて一ヶ月が経ったので、現時点での印象をまとめる。
## Pros
* ノイズキャンセリング性能の高さ
* デザイン
* 8台までのマルチペアリング
* 2台までのマルチポイント
* タッチコントロール
* 3段階ノイズキャンセリングレベルコントロール
* 10段階の内3つをあらかじめ選んでおき、ボタンを押してローテーションできる
* QC30は1段階ずつしか変更出来ずボタンを連打させられる仕様だったので、大きな改善
* バッテリーの持ちの良さ
* 15時間くらいは動く
* 有線対応
* 有線時もANCが働く
* USB-C充電対応
- ノイズキャンセリング性能の高さ
- 8 台までのマルチペアリング
- 2 台までのマルチポイント
- タッチコントロール
- 3 段階ノイズキャンセリングレベルコントロール
- 10 段階の内 3 つをあらかじめ選んでおき、ボタンを押してローテーションできる
- QC30 は 1 段階ずつしか変更出来ずボタンを連打させられる仕様だったので、大きな改善
- バッテリーの持ちの良さ
- 15 時間くらいは動く
- 有線対応
- 有線時も ANC が働く
- USB-C 充電対応
## Cons
* マルチポイント時の混線ノイズ
* 音楽再生中にもう一方のデバイスで何か通知音が鳴るとストリームに対して「プツプツ」ノイズが入る
* システムサウンドが大きすぎる（変更不可）
* 消耗部品の多さ
* ヒンジ部分はケースに仕舞う度に動かなさいといけないため消耗が心配
* 可動部が多いほど故障率は上がる
* 本体側での接続先選択が不可能
* QC30では出来ていた本体側のボタンで接続先を選択できる機能が無くなっていた
* ボタン配置のミス
* ボタンが手に触れやすい位置にあるため、ヘッドホンを外す度に間違って押してしまう
* ストリーム元とボタンの送信先が異なるバグ
* マルチポイント接続で一方のデバイスで音楽を流している際に、再生ボタンの信号が音楽を流していない方のデバイスに送信されてしまうバグがある
- マルチポイント時の混線ノイズ
- 音楽再生中にもう一方のデバイスで何か通知音が鳴るとストリームに対して「プツプツ」ノイズが入る
- システムサウンドが大きすぎる（変更不可）
- 公式英語フォーラムで多くのユーザーが苦情を書き込んでいるが、完全に無視されている
- 消耗部品の多さ
- ヒンジ部分はケースに仕舞う度に動かなさいといけないため消耗が心配
- 一般論として、可動部が多いほど故障率が上がる
- 本体側での接続先選択が不可能
- QC30 では出来ていた本体側のボタンで接続先を選択できる機能が無くなっていた
- ボタン配置のミス
- ボタンが手に触れやすい位置にあるため、ヘッドホンを外す度に間違って押してしまう
- ストリーム元とボタンの送信先が異なるバグ
- マルチポイント接続で一方のデバイスで音楽を流している際に、再生ボタンの信号が音楽を流していない方のデバイスに送信されてしまうバグがある

12
source/_posts/2019/give-your-app-slick-name.md
View File

@@ -9,12 +9,12 @@ That's why I created [namae](https://namae.dev).
# namae
![np1a40lrch9m10b1s7nz.gif](/uploads/np1a40lrch9m10b1s7nz.gif)
![](/uploads/np1a40lrch9m10b1s7nz.gif)
[namae](https://namae.dev) is an inter-platform name availability checker for developers and entrepreneurs.
Once you fill out a form with a name you want to use, namae will check through various registries and check if the name is already in use or not.
![pww3x6ycshadfiiotep9.png](/uploads/pww3x6ycshadfiiotep9.png)
![](/uploads/pww3x6ycshadfiiotep9.png)
# Supported Platforms
@@ -40,11 +40,11 @@ Additionally, the search result comes with a list of projects which has a simila
# Name Suggestion
namae also has a unique feature called __Name Suggestion__. It suggests auto-generated names made up of common prefix/suffix and synonyms. Take look at some examples.
namae also has a unique feature called **Name Suggestion**. It suggests auto-generated names made up of common prefix/suffix and synonyms. Take look at some examples.
![aas52pwbrueyzrulfiae.png](/uploads/aas52pwbrueyzrulfiae.png)
![](/uploads/aas52pwbrueyzrulfiae.png)
![j6jv0rq4gin28hks1ika.png](/uploads/j6jv0rq4gin28hks1ika.png)
![](/uploads/j6jv0rq4gin28hks1ika.png)
Clicking the suggestion, namae completes the form with it and start searching around the registries.
@@ -56,4 +56,4 @@ namae is completely open-sourced and the entire source code is available at [Git
namae saves your time searching for a universally available name around a set of hosting providers and package registries.
Go to [namae.dev](https://namae.dev/) and grab a report for the availability of your future product name. If you have any suggestion, poke me on Twitter ([@uechz](https://twitter.com/uechz)).
Go to [namae.dev](https://namae.dev/) and grab a report for the availability of your future product name. If you have any suggestion, poke me on Twitter ([@uechz](https://twitter.com/uechz)).

2
source/_posts/2019/padsize.md
View File

@@ -4,7 +4,7 @@ date: 2019-01-14 00:00:00 +09:00
redirect_from: "/blog/2019/01/14/padsize"
---
padStart における padSize の求め方です。
`padStart` における適切な `padSize` の求め方。
$$
\textrm{padSize} = \lceil \log_{10}(\mathbf{arraySize} + 1) \rceil

50
source/_posts/2019/sign-and-notarize-electron-app.md
View File

@@ -4,21 +4,21 @@ date: 2019-06-05 00:00:00 +09:00
redirect_from: "/blog/2019/06/05/sign-and-notarize-electron-app"
---
electron-builder を利用して macOS 向け Electron アプリをコード署名し、公証を通過させます。
electron-builder を利用して macOS 向け Electron アプリをコード署名し、公証を通過させる。
> **tl;dr**: コード署名と公証に対応した macOS アプリ Juno のリポジトリを[GitHub で公開](https://github.com/uetchy/juno)しています
> **tl;dr**: コード署名と公証に対応した macOS アプリ Juno のリポジトリを[GitHub で公開](https://github.com/uetchy/juno)している。
# Code Sign
アプリのコード署名は`electron-builder`によって自動で行われます。内部的には[electron-osx-sign](https://github.com/electron-userland/electron-osx-sign)が使用されます。
アプリのコード署名は`electron-builder`によって自動で行われる。内部的には[electron-osx-sign](https://github.com/electron-userland/electron-osx-sign)が使用される。
リリース用のアプリにコード署名をするには、Keychain に有効な Developer ID Certificate が格納されている必要があります。macOS Developer Certificate は開発用のコード署名のみ可能なので、リリース用としては不十分です。
リリース用のアプリにコード署名をするには、Keychain に有効な Developer ID Certificate が格納されている必要がある。macOS Developer Certificate は開発用のコード署名にしか使えないため、リリース用としては不十分だ。
まだ証明書を発行していない場合は、[Apple Developer](https://developer.apple.com/account/resources/certificates/list)で証明書の追加ウィザードに進み、**Developer ID Application**を選択して証明書を発行してください。
まだ証明書を発行していない場合は、[Apple Developer](https://developer.apple.com/account/resources/certificates/list)で証明書の追加ウィザードに進み、**Developer ID Application**を選択して証明書を発行する。
# Notarize
コード署名済みのアプリを[electron-notarize](https://github.com/electron-userland/electron-notarize)を使用して Apple Notary Service に提出します。
コード署名済みのアプリを[electron-notarize](https://github.com/electron-userland/electron-notarize)を使用して Apple Notary Service に提出する。
```js
const { notarize } = require("electron-notarize");
@@ -31,17 +31,17 @@ notarize({
});
```
- **appBundleId**: アプリの Bundle ID です。`package.json`の`build.appId`と同じものを使います。
- **appPath**: `.app`の絶対パスを指定します。
- **appleId**: Apple Developer として登録している Apple ID を指定します。
- **appleIdPassword**: Apple ID のパスワードです。2 要素認証を必要としないパスワードが必要なので、[Apple ID](https://appleid.apple.com/#!&page=signin)にアクセスして**App-specific Password**を発行してください。
- **ascProvider**: Apple Developer の Membership に記載されている**Team ID**を指定します。
- **appBundleId**: アプリの Bundle ID 。`package.json`の`build.appId`と同じものを使う。
- **appPath**: `.app`の絶対パスを指定する。
- **appleId**: Apple Developer として登録している Apple ID を指定する。
- **appleIdPassword**: Apple ID のパスワード。2 要素認証を必要としないパスワードが必要なので、[Apple ID](https://appleid.apple.com/#!&page=signin)にアクセスして**App-specific Password**を発行する。
- **ascProvider**: Apple Developer の Membership に記載されている**Team ID**を指定する。
## electron-builder の afterSign フック
electron-builder の afterSign フックを使用して、コード署名が済んだアプリを自動で Notary に提出します。
electron-builder の afterSign フックを使用して、コード署名が済んだアプリを自動で Notary に提出する。
フックスクリプトを`./scripts/after-sign-mac.js`に置きます。
フックスクリプトを`./scripts/after-sign-mac.js`に置く。
```js
const path = require("path");
@@ -73,7 +73,7 @@ exports.default = async () => {
};
```
`package.json`の`build`に`afterSign`を追加してコード署名が終わった後にスクリプトが実行されるようにします。
`package.json`の`build`に`afterSign`を追加して、コード署名が終わった後にスクリプトが実行されるようにする。
```json
"build": {
@@ -83,7 +83,7 @@ exports.default = async () => {
## Hardened Runtime and Entitlements
このままでは公証に失敗します。デフォルトで書き出されるバイナリでは、セキュリティの強化された[Hardened Runtime](https://developer.apple.com/documentation/security/hardened_runtime_entitlements)が有効になっていないためです。以下のようなエラーメッセージを貰います。
このままでは公証に失敗する。デフォルトで書き出されるバイナリでは、セキュリティの強化された[Hardened Runtime](https://developer.apple.com/documentation/security/hardened_runtime_entitlements)が有効になっていないためだ。以下のようなエラーメッセージが帰ってくる。
```json
{
@@ -103,7 +103,7 @@ exports.default = async () => {
}
```
`package.json`の`build.mac.hardenedRuntime`を`true`にして Hardened Runtime を有効にします。
そこで、`package.json`の`build.mac.hardenedRuntime`を`true`にして Hardened Runtime を有効にする。
```json
"build": {
@@ -113,7 +113,7 @@ exports.default = async () => {
}
```
Hardened Runtime 下では、必要に応じて Entitlement を指定しなくてはなりません。Electron の実行には`allow-unsigned-executable-memory`という Entitlement が必要なので、`entitlement.plist`ファイルを`build`フォルダに作成し、以下のような plist を記述します。
Hardened Runtime 下では、必要に応じて Entitlement を指定しなければならない。Electron の実行には`allow-unsigned-executable-memory` Entitlement が必要だ。そこで、`entitlement.plist`ファイルを`build`フォルダに作成し、以下のような plist を記述する。
```xml
<?xml version="1.0" encoding="UTF-8"?>
@@ -126,7 +126,7 @@ Hardened Runtime 下では、必要に応じて Entitlement を指定しなく
</plist>
```
`package.json`の`entitlements`及び`entitlementsInherit`に Entitlment が記述された plist のファイルパスを指定します。
`package.json`の`entitlements`及び`entitlementsInherit`に Entitlement が記述された plist のファイルパスを指定する。
```json
"build": {
@@ -138,18 +138,18 @@ Hardened Runtime 下では、必要に応じて Entitlement を指定しなく
}
```
Hardened Runtime で Electron を実行することができるようになったので、Notary を通過できる状態になりました。
Hardened Runtime で Electron を実行することができるようになったので、Notary を通過できる状態になった。
実際に`electron-builder`を実行してすべてのプロセスが上手く動作することを確かめてください。
実際に`electron-builder`を実行して、すべてのプロセスが滞りなく動作することを確かめよう。
# Verify Notary Status
ただしく公証を得られたかどうかは`altool`で調べることができます。
ただしく公証を得られたかどうかは`altool`で調べることができる。
公証通過後に送られてくるメールに`Request Identifier`が記載されているのでメモします。
公証通過後に送られてくるメールに`Request Identifier`が記載されているのでメモする。
```
Dear Yasuaki,
Dear uetchy,
Your Mac software has been notarized. You can now export this software and distribute it directly to users.
@@ -161,13 +161,13 @@ Best Regards,
Apple Developer Relations
```
`xcrun altool --notarization-info`コマンドに UUID と Apple ID、パスワードを指定して公証ステータスを確認します。
`xcrun altool --notarization-info`コマンドに UUID と Apple ID、パスワードを指定して公証ステータスを確認する。
```
xcrun altool --notarization-info <UUID> -u $APPLE_ID -p $APPLE_PASSWORD
```
正しく公証が得られている場合は以下のようなメッセージが表示されます。おめでとうございます！
正しく公証が得られている場合は以下のようなメッセージが表示される。おめでとう！
```
2019-06-05 13:51:18.236 altool[5944:261201] No errors getting notarization info.

30
source/_posts/2019/welch-t-test.md
View File

@@ -3,9 +3,9 @@ title: プログラムの速度改善が誤差かどうかを統計的に調べ
date: 2019-10-03 17:21:00 +09:00
---
**Welch の t 検定**を用いて 2 つのベンチマークの分布の平均が等しい（速度差は誤差の範疇）か、あるいは異なる（=有意な速度改善が成されている）かどうかを判定します。
**Welch の t 検定**を用いて 2 つのベンチマークの分布の平均が等しい（速度差は誤差の範疇）か、あるいは異なる（=有意な速度改善が成されている）かどうかを判定したい。
ベンチマーク用の TypeScript プログラムを用意します。
ベンチマーク用に TypeScript プログラムを用意した。
```ts a.ts
function a() {
@@ -27,13 +27,13 @@ function b() {
b();
```
まず[hyperfine](https://github.com/sharkdp/hyperfine)で 2 つの プログラムのベンチマークを取り、`result.json`に保存します。
まず[hyperfine](https://github.com/sharkdp/hyperfine)で 2 つの プログラムのベンチマークを取り、`result.json`に保存する。
```shell
hyperfine 'ts-node a.ts' 'ts-node b.ts' -r 50 --warmup 3 --export-json ab.json
```
`result.json`の中身は以下のようになります。
`result.json`の中身は以下のようになる。
```json result.json
{
@@ -78,9 +78,9 @@ hyperfine 'ts-node a.ts' 'ts-node b.ts' -r 50 --warmup 3 --export-json ab.json
}
```
> t 検定はサンプルが正規分布に従っているという仮定を置いているので、大数の法則から本当はもっと試行回数を増やした方が良いです。
> t 検定はサンプルが正規分布に従っているという仮定を置いているため、大数の法則から本当はもっと試行回数を増やした方が良い。
この`result.json`の`times`配列を受け取り、2 つの分布間に有意差があるかどうかを判定します。
この`result.json`の`times`配列を受け取り、2 つの分布間に有意差があるかどうかを判定する。
```ts
import fs from "fs";
@@ -126,7 +126,7 @@ log(`p < 0.05 = ${p < 0.05}`);
log(p < 0.05 ? "Possibly some difference there" : "No difference");
```
ここで`X_mu`は分布 X の平均、`X_sigma`は分布 X の不偏分散です。
ここで`X_mu`は分布 X の平均、`X_sigma`は分布 X の不偏分散だ。
$$
\begin{eqnarray}
@@ -135,26 +135,26 @@ $$
\end{eqnarray}
$$
これを X と Y 両方に対して求めます。さらに以下のようにして t を求めます。
これを X と Y 両方に対して求めます。さらに以下のようにして t を求める。
$$
t = \frac{\mu_X - \mu_Y}{\sqrt{\frac{\sigma_X}{n_X} + \frac{\sigma_Y}{n_Y}}}
$$
t 分布の累積密度関数 (Cumlative Distribution Function; CDF) を定義します。面倒すぎたので[jstat](https://github.com/jstat/jstat)の`studentt.cdf`を使ってます。コードを見ると、分子の積分は[シンプソンの公式](https://ja.wikipedia.org/wiki/シンプソンの公式)を使って近似していました。
t 分布の累積密度関数 (Cumlative Distribution Function; CDF) を定義する。面倒すぎたので[jstat](https://github.com/jstat/jstat)の`studentt.cdf`を使った。コードを見ると、分子の積分は[シンプソンの公式](https://ja.wikipedia.org/wiki/シンプソンの公式)を使って近似していた。
$$
\text{CDF} =\frac{\int_0^{\frac{v}{t^2+v}}\frac{r^{\frac{v}{2}-1}}{\sqrt{1-r}}dr{}}{\text{exp}(\ln(\Gamma(\frac{v}{2}))+\ln(\Gamma(0.5))+\ln(\Gamma(\frac{v}{2}+0.5)))}
$$
CDF を用いて p 値を求めます。両側検定をするので 2 を掛けます。t 分布の自由度 (degree of freedom; df) は$n-1$なので、両分布の自由度を$n_X+n_Y-2$で与えます。本当は
CDF を用いて p 値を求める。両側検定をするので 2 を掛ける。t 分布の自由度 (degree of freedom; df) は$n-1$なので、両分布の自由度を$n_X+n_Y-2$で与える。本当は
$$
\text{df} = \frac{(\sigma_X + \sigma_Y)^2}{
\frac{\sigma_X^2}{n_X - 1} + \frac{\sigma_Y^2}{n_Y - 1}}
$$
で求める必要がありますが、さぼって近似しました。
で求める必要があるが、さぼって近似した。
$$
p = \text{CDF}(-|t|, n_X+n_Y-2) \times2
@@ -162,7 +162,7 @@ $$
## 結果
異なる実行時間を示すプログラム`a`,`b`を比較すると、2 つの分布の平均が異なることが示唆されました。
異なる実行時間を示すプログラム`a`,`b`を比較すると、2 つの分布の平均が異なることが示唆された。
```
❯ ts-node test.ts ab.json
@@ -180,7 +180,7 @@ p < 0.05 = true
Possibly some difference there
```
p 値が 0.05 未満となり、帰無仮説「２つの分布は等しい」が棄却されたので「２つの分布は等しくない」ことがわかりました。同じプログラム同士でベンチマークを取るとどうなるでしょうか。
p 値が 0.05 未満となり、帰無仮説「２つの分布は等しい」が棄却されたので「２つの分布は等しくない」ことがわかった。では、同じプログラム同士でベンチマークを取るとどうなるか？
```
❯ ts-node test.ts aa.json
@@ -198,9 +198,9 @@ p < 0.05 = false
No difference
```
p 値が 0.05 未満ではないので、帰無仮説は棄却されず、つまり「２つの分布は等しい」ことがわかりました。
p 値が 0.05 未満ではないため、帰無仮説は棄却されず、つまり「２つの分布は等しい」ことがわかった。
ウェルチの t 検定はスチューデントの t 検定と違って等分散性（２つの分布の分散が等しいこと）を仮定しないので、とても取り扱いやすい検定です。もちろん等分散性のある分布でも使用できるので、基本的にはウェルチの方法を使う方針で良さそうです。
ウェルチの t 検定はスチューデントの t 検定と違って等分散性（２つの分布の分散が等しいこと）を仮定しないため、とても取り扱いやすい検定だ。もちろん等分散性のある分布でも使用できるので、基本的にはウェルチの方法を使う方針で良さそうだ。
## 参考文献