Quick Charge 2.0 で 12V 出力できるバッテリーがいつのまにか Anker からも出ていた。

Anker

 -

5.0 / 5.0

Anker は PowerCore+ のシリーズでも 12V 出せないモデルもあるので注意が必要。

RAVPower

 -

4.0 / 5.0

Aukey

 -

4.0 / 5.0

Aukey は他のQC対応モデルもスペック表示は同じ。

(なおこれは所持していて、実測では 1.5A 程度までは出力可能 https://lowreal.net/2015/12/12/1 )


Amazon.co.jp を「quick charge 2.0 モバイルバッテリー」で検索してもあんまりヒットしない。

スペックで比較しても、サポートで比較しても現状では Anker 一択でしょう。

  1. トップ
  2. tech
  3. 12V 出力のモバイルバッテリー

そういえば単体でどれぐらい出力を出せるか試していなかったのでやってみた。

KX3 は 7MHz 帯 5W で送信すると 1.6A〜1.7A ぐらい流れる。この状態で10秒ぐらい経過するとバッテリーが落ちる。

ただ、普通の CW のようにある程度間欠なら大丈夫みたいで、5W は出せそうな雰囲気。4Wとか3W ならより安全。バンドによって消費電力が違うが、いちいち覚えていられないので、このあたりを限度に設定するしかない。

容量が大きいので長時間運用したいならモバイルバッテリーがいいと思う。Ni-MHバッテリーだともうちょっと安定して電流をとれるので、短い時間しか運用しないなら Ni-MH でもよさそう。

ref.

  1. トップ
  2. tech
  3. KX3 + Aukey Quick Charge 12V Out

Google Picker で Google Photo の画像をとってこようとすると、どのビューにおいても新しい写真から順に表示され、古い日付に飛ぶ方法がないので、どうしようもなくなる。

唯一確実なのはアップロードからやりなおすこと。

よく覚えてないけど辛い夢ばかり見る。今日は夢ってだけじゃなくて腹痛でいきなり起きてしばらくトイレにこもっていた。なんでこんなめにあっているのか分からない。

ヤパチーでErgoDox を見て面白いなあと思ったので調べてみた。

ネットの記事だとErgoDoxって、「とにかく健康だ!! 筋肉だ!!!」みたいな話になってて、相容れなそう、と思って興味沸かなかったけど、実際見てみたら DIY 感が思ったよりあって良いし、オープンソースって部分が面白いと思った。

今まであんまり深く考えず、自作キーボードってキーはどうするの?と思っていたけど、Cherry MX シリーズ(及びそれの互換キー)というのがメカニカルキーボード業界だとデファクトスタンダードらしい。つまり「自作キーボード」というのは「キー配置・ファームウェアが自作」ということのようで、キーの細かい設計とかではない。

キー

Cherry MX (及びその派生) はメカニカルで有接点のキー。

調べた感じ、HHKB のような静電容量無接点キーというのは部品単体での販売はないっぽいくて、これ系のメカニカルキーになる。

Cherry MX シリーズ

黒と青は Digikey でも買える。スイッチのみなら100円/個ぐらい。100個買えばディスカウントで8000円ぐらい。いろいろ種類があって、軸の色で判定できる。ググったらどういう違いがあるか出てくる。

普通のキーボードに採用されているので新宿ヨドバシとかでも Cherry MX シリーズのキーは体験できる。

互換キー

互換キーというのもあるらしい。ピンアサインとかが互換で、タッチも似たものがある。Gateron は ebay で結構売ってる業者がいる。

例えば、ErgoDox EZ という組み立て済みのものは Gateron になっている。Cherry MX より安いが品質は悪くはないみたい。だいたい102キーセットで3000〜4000円ぐらいで買えるみたい。

ref.

キースイッチとキーキャップは別で、変な話だけど複雑な構造のスイッチよりもキャップのほうが高いこともある…… カスタマイズの定番扱いなので、スイッチよりは入手性が良い。

ErgoDox の設計(電子回路)

ErgoDox は Teensy (AVR ATMEGA32U48 というUSB付きAVRベース) に I2C の I/O エキスパンダを組合せてある。分割キーボード間の通信が I2C で、これのコネクションは TRRS (ステレオミニ4極) コネクタとなっている。

パーツリストを見てわかるように、上記以外に他に主要な部品はない。

自作する場合キーごとにダイオードつけるのが一番面倒そう。

スイッチの判定

6行7*2列(84キー) のスイッチマトリクス。使ってない IO ピンがまだあるので7行8*2列までならそれほど大きな書きかえはいらないかもしれない。

スイッチごとにダイオードがついてるのは同時押ししたときのため。ファームウェア次第でN key rollover (NKRO)になる(と思う)。ファームウェアはまだあんまり読んでないけど EZ はNKROと書いてある。本家はわからない。

KiCAD を使ってる

KiCAD で設計されている。KiCAD も OSS なので OSS 原理主義者的にはよさそう。しかし KiCAD は少なくとも Mac だとかなり辛い。

ErgoDox のファームウェア

ファームウェアはユーザレベルでコンパイルして使えよみたいな感じになっていて、キーマップ変更(必須)すらコンパイルが必要になっている。なので結構派生物があるのと、ガイドが多いので困らなそう。

そんなに複雑なコードはない。USBキーボードデバイスとしての部分はライブラリになっているよう?回路構成多少変えてもファームウェアを対応させるのはそれほど大変ではなさそう。

所感

ErgoDox 面白い。とりあえず自分は現時点では買う予定はない。しかし実用キーボードが割と簡単に作れそうというのは良さそう。ソフトと違ってハードは我慢して使うことが多いけど、キーボードは自力で設計して自分にあうのを作るのもよさそう。暇になったらやってみたい。

  1. トップ
  2. tech
  3. ErgoDox について調べた(買わないけど)

ちょっと Time Machine なしでやる必要があったのでメモ

基本設定

やらないと普通の操作に困る系

「システム環境設定」→トラックパッド→ポイントとクリック→タップでクリック チェックを入れる
「システム環境設定」→トラックパッド→スクロールとズーム→スクロールの方向:ナチュラル チェックをはずす
「システム環境設定」→ユーザとグループ→パスワード変更
「システム環境設定」→キーボード→修飾キー…→ Caps Lock を Ctrl に
「システム環境設定」→キーボード→ショートカット→Spotlight→Spotlight 検索を表示を Cmd+ESC に

アプリケーションインストール

Chrome

Safari 開いたあと chrome で検索すれば Google の検索画面の時点で誘導がでるので従う

AquaSKK https://github.com/codefirst/aquaskk/releases

インストール後
システム環境設定→キーボード→入力ソースで

  • AquaSKK 統合を追加
  • ASCII を追加
  • デフォルトの「日本語」を削除

Terminal.app

Terminal.app を Spotlight とかから起動する

  • Dock アイコンを右クリックして「オプション→」「ログイン時に開く」をオン
  • 同じく「Dock に追加」をオン
  • 環境設定→プロファイルで「Pro」をデフォルトに
  • Pro のプロファイルのうち「フォント」を Osaka-等幅 12pt〜14pt に
  • 「テキストをアンチエイリアス処理」にチェック
  • 「キーボード」で「メタキーとして Option キーを使用」にチェック
  • 「詳細」で「Unicode 東アジア A (曖昧) 文字幅を W (広) にする」にチェック

git

git コマンドをうつと Command Line Tools をインストールしろと言われるのでする

git clone dotfiles して ruby setup.rb する

最低限の項目おわり

自分で撮った古い写真を4K画面でだらだら眺めてると面白くて、歴史を感じる。

HT-03A の写真が1枚だけあって、解像度低すぎてビビる。でも、今でも HT-03A サイズのスマフォが欲しいと思ってる。処理速度とかはともかく、なんだかんだいって一番好きな端末かもしれない。これ、画面に表示しているのは fotolife アプリだと思う。id:fixo さんの絵が好きなのでよく見ていた。

京都で雪が降ってクソ寒いときにカメラ持って自転車で写真撮ったりしていた。どう考えてもアホだけど、めちゃくちゃ楽しかった。でもアホだと思う。しかし風邪はひかなかった。

雪といえば春あたりに愛宕山を登ったときは雪が残っていてすべりまくった。頂上に神社があってとにかく最高なのだけど、結局1度しか登らなかった。

オフィスの出口だと思うけどなぜこんなところを写真に撮ったのか不明。

毎週のように自転車で植物園に行ってたけど良かった。いついっても面白い。

これは京都御苑内の神社で撮ったはず。京都御苑はやっぱ散歩スポットとしてクオリティが高すぎた。

きりがないけど、昔の写真を 4K で見るとたのしい。再現像してアップロードしなおすのも面白そうなので、たまにやりたい。空気感が再現されるのは面白い。

  1. トップ
  2. photo
  1. トップ
  2. redeveloped

お疲れさまです。LT をしてきました。

感想はまたあとで

  1. トップ
  2. tech
  3. YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa

Time Machine のスナップショット、つまり /Volume/Time Machine/Backups.backupdb/[Machine Name]/2016-05-05-002654/ みたいなやつを手動で削除したいとします。

これを Finder 経由で、ごみ箱に入れてごみ箱を空にするという手順でやると、時間がかかるうえに、途中で「ロックされている項目を削除してもいいか?」と一度確認まで入ります。さっさと削除してくれよという感じがします。

ということで、めんどいなので rm -rf するかと思いきや、これは削除するパーミッションがあっても、 operation not permitted となって失敗します。どうしてかというと Time Machine のスナップショットは専用のカーネル拡張で守られているからです。守られているにはそれなりの理由があるので rm -rf は素直に諦めましょう。

ということで、tmutil delete を使います。

$ cd /Volumes/Time Machine/Backups.backupdb/Alice
$  sudo tmutil delete 2016-05-05-002654/
Password:
Deleting: /Volumes/Time Machine/Backups.backupdb/Alice/2016-05-05-002654

こんな感じで使えます。スナップショット1つ消すのに結構な時間がかかりますが、特に確認は入らないので放置すれば終わります。

余談:なぜ rm -rf がダメか

Time Machine は差分バックアップのためハードリンクを活用します。これはディレクトリに対してもそうで、内容に変化のないディレクトリはハードリンクになります。 (ちなみにディレクトリのハードリンクは標準 ln では作れないので、brew install hardlink-osx で入る hln で試すことができます)

このとき、違うスナップショット間でも同じディレクトリエントリとなるわけなので、このディレクトリエントリ中のファイルエントリを削除 (unlink) してしまうと、このディレクトリにハードリンクしているスナップショット間でもファイルが消えてしまいます。なので rm -rf が禁止されています。

$ mkdir foo bar
$ touch foo/a.txt
$ ls
foo/ bar/
$ ls foo
a.txt
$ hln foo bar/foo
$ ls bar/foo
a.txt
$ rm -rf foo
$ ls
bar/
$ ls bar/foo
# a.txt が消える
  1. トップ
  2. tech
  3. Time Machine のスナップショットをコマンドラインで削除する

コネクタのペアの極性のことをジェンダーといい、それぞれオス(male)とメス(female)に呼びわけられる。変換コネクター(アダプター)はジェンダーチェンジャー(gendar changer)と言う。海外サイトで高周波コネクタを買いたいときはこれで検索するのが確実。

ただどうも結構よくどっちがどっちかわからなくなる。コンセントみたいに単に突起が出てるだけ/受ける側は穴が開いているだけなら簡単だけど、SMAコネクタにようにハウジング(ピンを保護したりするための囲い)がついているとややこしくなる。

しかも SMA コネクタの場合 RP-SMA というオス型ピン+メス型ハウジング/メス型ピン受け+オス型ハウジングというカオスな組み合わせがあるのって、どっちがオスでどっちがメスなのかわかりにくい。考えかたとしては内部にピンが立っているほうがオスであっているはずだけど自信がなくなる。

ユーザーが増えると嬉しいものだ!というのはわかるし、そうなんだろうけど、自分に正直に考えてみると、自分はそのことがそれほど嬉しくないようだ。

むしろ、ユーザーが増えるとミスしたときの影響範囲が広くなるので、どんどんコード書くことに対して嫌になっていく。プログラミングは「てこ」であって、小さな労力で大きなことをやることができるが、すなわち負の面では小さなバグで大きな影響を与える。当然、ほとんどの場合は良い方向に作用するし、そうするように作っているつもりだが、バグのないコードを書くことは不可能なので、コードを書けば書くほど、負の作用に怯えることとなる。

「自分のプロダクトがたくさん使われてるのってすごいと思わへん?」と聞かれると、理性の上ではそうですねと思うが、直感的にはまずは辛いという気持ちがでる。

根幹にあるのは、「たくさんの人に使われる」ことが自分の中の承認システムに組み込まれておらず、それを天秤にかけたとき、嬉しさの方に傾かないということだ。

たくさんの人に使われるからといって、技術的にすごいとはいえない、というのもあるかもしれない。ただこの考えかたは美化しすぎで、たくさんの人に使われてバグが見つかってバカにされるのが嫌なだけというのが正直なところだという気がする。