✖
Time Machine のスナップショットをコマンドラインで削除する
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 が消える
コネクタのジェンダー
コネクタのペアの極性のことをジェンダーといい、それぞれオス(male)とメス(female)に呼びわけられる。変換コネクター(アダプター)はジェンダーチェンジャー(gendar changer)と言う。海外サイトで高周波コネクタを買いたいときはこれで検索するのが確実。
ただどうも結構よくどっちがどっちかわからなくなる。コンセントみたいに単に突起が出てるだけ/受ける側は穴が開いているだけなら簡単だけど、SMAコネクタにようにハウジング(ピンを保護したりするための囲い)がついているとややこしくなる。
しかも SMA コネクタの場合 RP-SMA というオス型ピン+メス型ハウジング/メス型ピン受け+オス型ハウジングというカオスな組み合わせがあるのって、どっちがオスでどっちがメスなのかわかりにくい。考えかたとしては内部にピンが立っているほうがオスであっているはずだけど自信がなくなる。
ユーザーが増えても嬉しくない
ユーザーが増えると嬉しいものだ!というのはわかるし、そうなんだろうけど、自分に正直に考えてみると、自分はそのことがそれほど嬉しくないようだ。
むしろ、ユーザーが増えるとミスしたときの影響範囲が広くなるので、どんどんコード書くことに対して嫌になっていく。プログラミングは「てこ」であって、小さな労力で大きなことをやることができるが、すなわち負の面では小さなバグで大きな影響を与える。当然、ほとんどの場合は良い方向に作用するし、そうするように作っているつもりだが、バグのないコードを書くことは不可能なので、コードを書けば書くほど、負の作用に怯えることとなる。
「自分のプロダクトがたくさん使われてるのってすごいと思わへん?」と聞かれると、理性の上ではそうですねと思うが、直感的にはまずは辛いという気持ちがでる。
根幹にあるのは、「たくさんの人に使われる」ことが自分の中の承認システムに組み込まれておらず、それを天秤にかけたとき、嬉しさの方に傾かないということだ。
たくさんの人に使われるからといって、技術的にすごいとはいえない、というのもあるかもしれない。ただこの考えかたは美化しすぎで、たくさんの人に使われてバグが見つかってバカにされるのが嫌なだけというのが正直なところだという気がする。
✖
✖
自分で撮った古い写真を4K画面でだらだら眺めてると面白くて、歴史を感じる。
HT-03A の写真が1枚だけあって、解像度低すぎてビビる。でも、今でも HT-03A サイズのスマフォが欲しいと思ってる。処理速度とかはともかく、なんだかんだいって一番好きな端末かもしれない。これ、画面に表示しているのは fotolife アプリだと思う。id:fixo さんの絵が好きなのでよく見ていた。
京都で雪が降ってクソ寒いときにカメラ持って自転車で写真撮ったりしていた。どう考えてもアホだけど、めちゃくちゃ楽しかった。でもアホだと思う。しかし風邪はひかなかった。
雪といえば春あたりに愛宕山を登ったときは雪が残っていてすべりまくった。頂上に神社があってとにかく最高なのだけど、結局1度しか登らなかった。
オフィスの出口だと思うけどなぜこんなところを写真に撮ったのか不明。
毎週のように自転車で植物園に行ってたけど良かった。いついっても面白い。
これは京都御苑内の神社で撮ったはず。京都御苑はやっぱ散歩スポットとしてクオリティが高すぎた。
きりがないけど、昔の写真を 4K で見るとたのしい。再現像してアップロードしなおすのも面白そうなので、たまにやりたい。空気感が再現されるのは面白い。
YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa
✖
12V 出力のモバイルバッテリー
Quick Charge 2.0 で 12V 出力できるバッテリーがいつのまにか Anker からも出ていた。
Anker
- https://jp.anker.com/products/A1310011
- 5V / 2.4A, 9V / 2A, 12V / 1.5A
Anker は PowerCore+ のシリーズでも 12V 出せないモデルもあるので注意が必要。
RAVPower
- http://amzn.to/29gwrp2
- 5V/2.4A、9V/1.5A、12V/1.2A Max
Aukey
- http://amzn.to/29eihs5
- 5V・2.1A/9V・1.8A/12V・1.35A
Aukey は他のQC対応モデルもスペック表示は同じ。
(なおこれは所持していて、実測では 1.5A 程度までは出力可能 https://lowreal.net/2015/12/12/1 )
Amazon.co.jp を「quick charge 2.0 モバイルバッテリー」で検索してもあんまりヒットしない。
スペックで比較しても、サポートで比較しても現状では Anker 一択でしょう。
KX3 + Aukey Quick Charge 12V Out
そういえば単体でどれぐらい出力を出せるか試していなかったのでやってみた。
KX3 は 7MHz 帯 5W で送信すると 1.6A〜1.7A ぐらい流れる。この状態で10秒ぐらい経過するとバッテリーが落ちる。
ただ、普通の CW のようにある程度間欠なら大丈夫みたいで、5W は出せそうな雰囲気。4Wとか3W ならより安全。バンドによって消費電力が違うが、いちいち覚えていられないので、このあたりを限度に設定するしかない。
容量が大きいので長時間運用したいならモバイルバッテリーがいいと思う。Ni-MHバッテリーだともうちょっと安定して電流をとれるので、短い時間しか運用しないなら Ni-MH でもよさそう。
ref.
✖
Google Picker で Google Photo の画像をとってこようとすると、どのビューにおいても新しい写真から順に表示され、古い日付に飛ぶ方法がないので、どうしようもなくなる。
唯一確実なのはアップロードからやりなおすこと。
とにかく夢見が悪い
よく覚えてないけど辛い夢ばかり見る。今日は夢ってだけじゃなくて腹痛でいきなり起きてしばらくトイレにこもっていた。なんでこんなめにあっているのか分からない。
ErgoDox について調べた(買わないけど)
ヤパチーで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 面白い。とりあえず自分は現時点では買う予定はない。しかし実用キーボードが割と簡単に作れそうというのは良さそう。ソフトと違ってハードは我慢して使うことが多いけど、キーボードは自力で設計して自分にあうのを作るのもよさそう。暇になったらやってみたい。
✖
OS X の最低限セットアップ手順
ちょっと 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 する
最低限の項目おわり
✖
✖
サーバーの時刻がものすごく(1時間ぐらい)ズレていた。。。VPS のホスト再起動の影響かな? そして ntpd が動いてなかった。
アマゾンのカスタマーQ&Aが見当違いの回答ばっかりなのはなんでだろう?
「iPhoneでは~でしょうか?」みたいな質問には「僕はアンドロイドなのでわかりません」みたいな回答がついてたりする。こういった、なんで答えたの?というのが多くていつも疑問。
Amazon 側でシステム的に名指しに「回答してみては?」みたいなメールを投げてるんかな。それで変な人にあたりまくってる? それとも単に変な人がいっぱいいるだけ?
僕がヤパチーで撮った写真全部見せます
✖
✖
博多に行く機会があったので、合間を縫って周辺神社に行ってきました。それほど時間が余ると思っていなかったので、まともなカメラを持っていかず、全部スマフォ写真です。
住吉神社
博多駅から近い。歩いて15分ぐらい。それにしては境内が広くて気持ちがいい。住吉神社という通り本殿は住吉造り。ただ、本殿以外に住吉造りはない。三大住吉の一つらしい。筑前国一宮。
太宰府天満宮
いうまでもないぐらい有名なところ。菅原道真が主祭神。
境内は広いけど、本殿は案外こじんまりしている。
17時ごろに行ったけど、人が全然いなくてものすごく良かった。境内までの道にある店もすべて閉まっていた。
奥の方の山にある稲荷神社(天開稲荷社)にもいった。そこそこ登る必要がある。
本殿の裏側に梅が結構植えてあって、梅の季節は良さそう。
山のぼるときテンションが異常で、走って登ってしまった。おれの幸福はノスタルジーと孤独の中にあるのだと思った。夏の神社は最高だ。
宗像大社
東郷駅からのバスが1時間に1本あるかないかって感じで厳しい。駅前にタクシーは数台あった。
宗像大社は沖津宮・中津宮・辺津宮と三カ所に分散していて、そのうち一般に参拝可能なのが中津宮・辺津宮の二カ所、中津宮は大島という離島にあって、時間が足りないので、辺津宮だけ行った。
境内がすごく広い。17時30分ごろに着いたので、本殿は閉門していた。残念。しかし本殿が見れなくても神社は割といろいろ見ることができて良い。
高宮祭場という、神籬の木と、それを囲う石垣だけがある神域があってとても良い感じ。沖津宮がある沖ノ島は島自体がご神体であるという神奈備だったりするし、古い形が残ってる数少ない例。沖ノ島は今も厳しい神奈備のルールが適用されていて、自由な立ち入りができない。
第二宮、第三宮があるところは、入ってみるとかなりのデジャヴを感じることができる。というのも、伊勢神宮別宮の月讀宮 (ref. 神宮参り - 氾濫原 )とほとんど同じ構成になっているからで、実はこれ実際に月讀宮にあった伊佐奈岐宮と伊佐奈弥宮を移築したものという由緒がある。
交通安全で有名。交通安全祈願とは神前で交通ルールを守ることを誓うことを含むというのが面白かった。
✖
スマフォ写真をLightroomでマシにするメモ
ZenFone2 を使っているけど、お世辞にも画質が良いとはいえない。後処理でなんとかする試行錯誤をしたので記録しておく。
- 「ノイズの低減」→「カラー」を適切に設定する
- 画質悪いカメラのノイズで一番うるさいのでカラーノイズだと思うので…
- 「シャープ」を適切に設定する
- 全体的にノイジーになるが、カラーノイズを消しておけばあまり気にならず、解像感が増す
- 「効果」→「かすみの除去」を多少強めにかける
- レンズが多少汚れていること多いけど、これだと全体的にモヤがかかった感じになってしまう。「かすみの除去」によってかなり全体的に綺麗になる
「明瞭度」はシーンによって上げたり下げたりする。
MCD-ST Liberty SW License Agreement V2 はフリーなライセンスか?
STM32CubeMX でジェネレートされるコードは MCD-ST Liberty SW License Agreement V2 というライセンスになっています。これはコード上で以下にリンクしています。
http://www.st.com/software_license_agreement_liberty_v2
- 1はライセンス表示をそのまま残せといってるやつです
- 2はバイナリ配布する場合もライセンス表示をどこかに表示しろという話です
- 3はライセンス表示の名前について商標とかを気にしなくてよいという話だと思います
- 4はこのソースコード及び派生物についてはSTマイクロのハードウェアだけで動かせということです
- 5は許可外のことをすると権利失効しますという話です
大文字の部分は免責事項です。
基本的にSTMのデバイスで使う限りは広い使用が認められているように見えます。が、ハードを制限しているのでちゃんとフリーとはいえなそうです。
友達がいなくても新しい言語は学べる
プログラミングが分かってる相手に気軽に挙動について訊ける機会なんてありませんね。仕事なら同僚に訊けばいいと思いますけど、同僚が暇とは限りませんし、学生ならそういった相手がいないことが普通ではないでしょうか。
ということで、独りで言語を学ぶ方法について考えます。
作りたいものを決める
大変重要なところです。どの言語でも書けて、どの言語も多少の個性が出て、そこそこ簡単なものがいいですね。
ぼくの場合は blosxom という「テキストファイルをスキャンしてHTMLにするだけのブログツール」なんですが、まぁなんでもいいと思います。ぼくはウェブエンジニアなので、ブラウザに何か表示がでるとそれだけで嬉しいというところがあります。
リファレンスをひけるようにする
どの言語も必ずどこかに言語リファレンスがあります。必ず公式のものを一式見れる状態にします。そしてできれば Chemr とか Dash みたいな瞬間的にリファレンスをひけるツールを用意します。
リファレンスは無限にひくことになるので、多少ここに時間をかけても良いところです。
書きはじめる
とりあえず Hello, World! しましょう。Hello, World! をバカにしてはいけなくて、これは print デバッグという原始的でほとんどどんな言語でも通用するデバッグ方法を習得するために必要なことです。高級なデバッガは言語ごと、エディタごとに使い勝手が異なることが多いので、デバッグが辛すぎる状況になってから考えます。
このとき、公式にチュートリアルがあるならやってみても良いです。が、どうせチュートリアル見ても Hello, World! のやりかたぐらいしか分からないので無視しても良いです。
重要構文を覚える
- 条件分岐 (if)
- ループ (for)
- リテラルの表記方法 "foo" は文字列、123 は数字など
これぐらいあればベタっと動くコードを書くことができるはずです。
クラス構文とか、そういうものはとりあえず無視しましょう。Java とか C# だとエントリポイントを書くために最初っから必要になりますが、まずはできるだけ無視します。言語特有の機能はとりあえず置いておいて、動くコードにします。
設計をなおす
多少動くものが書けそうなら、その言語で「最も良い書きかた」にできるだけ全てを直します。ここではリファレンスの特に文法をよく読んで「ぼくの考える最高に読みやすい書きかた」を探ります。とはいえ、だいたい言語ごとにセオリーが決まっているので、言語公式のライブラリとかを読むとてっとり早く雰囲気をつかめます。ただ、公式ライブラリが十分綺麗に書かれているとは限らないので、できるだけリファレンスに頼ったほうがいいと思います。
このとき大事なのは「これは読みにくいぞ」とか「オレはこう書きたいんだけど」という気持ちです。そういう自分の信念と、言語ごとの雰囲気の擦り合せを行います。できるだけ言語特有の良さを出すように書きます。最終的に「このコードは(他の言語名)から来たヤツが書いてんな」みたいな田舎臭さを消滅させることを目標とします。
友達がいなくても言語は学べるか
リファレンスをひけば大丈夫です。安心しましょう。そして Google で検索すれば大抵のわからない問題は解決します。わからなかったことは公開される形で記録しつつ解決して、検索できるようにしましょう。そうすると後続の友達がいない人に優しいインターネットになります。
Inkscape で作図したファイルを KiCAD の pcbnew で読みこむ
- Inkscape 側で Save a Copy... の画面で Desktop Cutting Plotter (AutoCAD DXF R14) (*.dxf) を選択する。
- このとき Base unit を mm にしておく
- KiCAD pcbnew 側で DXF ファイルをインポートする。設定はそのままで良い
BLE Nano の開発 - ブレッドボード配線
BLE Nano とは
http://redbearlab.com/blenano/
技適が通ってる小さい BLE 組込みの ARM SOC です。
開発環境
とりあえず mbed のオンラインコンパイラを使っています。というのもライブラリのリンクとかでハマるのが嫌だったからです。が、そのうち platformio で gcc ベースの開発はしたいところです。
BLE Nano + ブレッドボード
(この写真は MK20 のピンヘッダのうち、USBコネクタ側のピン2つが立っておらずスルーホールのままなので見間違えないように気をつける必要があります。MK20 + BLE Nano のセットを買ったら最初からピンヘッダはんだ付け済みでこうなっていたので、セットで買ってる限りは問題ないと思いますが…)
MK20 という書きこみ装置に亀の子的に挿して開発ができるんですが、これだと単に書きこめるってだけで周辺回路が作れないので、ブレッドボードに接続します。
必要な接続がいまいちわかりにくいですが、以下を接続すれば良さそうです。
- SWCLK
- SWDIO
- VDD または VIN
- GND
加えて、デバッグするなら
- TXD
- RXD
VDD は 1.8〜3.3V、VIN には 3.3V〜13V となっています。要は VIN にはレギュレータがついていて、VDD は直接入力になっているようです。
GPIO の入力範囲は?
VDD + 0.3 が絶対定格。5V トレラントとかではないので注意が必要そう。MK20 は裏面のジャンパで 1.8V モードにできる。低い外部電圧を使いつつ開発したい場合は 1.8V モードにする必要がある。
定格とかはnRF51822のダウンロードページから、nRF51822-PS (nRF51822 Product Specification) をダウンロードして見ればわかる。
レジスタ一覧とかは同じくnRF51822のダウンロードページから、nRF51 RM (nRF51 Series Reference Manual) を見れば書いてある。
オンラインコンパイラでもvimで開発したい
moco 使うといいです!!! https://github.com/hotchpotch/moco
以下のようにするとよさそう
- ~/.mocorc に mbed のアカウント情報を書いておく
- mbed オンラインコンパイラでプロジェクトの雛形を作ってpublish
- hg 経由で手元にもってくる
- プロジェクトルートに .mocorc を置いて、platform とかを指定する
- platform 名はmbed の Platforms 一覧ページから該当するボードに飛ぶと、URL に入るのがそれ。BLE Nano だとRedBearLab-BLE-Nano を指定すれば良い
OSX + BLE で HID over GATT でペアリング(bonding)ができなくてハマった
BLE Nano + mbed で HID over GATT しようとして1日ハマっていたので記録しておきます。HID の問題というよりペアリングの問題です。
前提
OS X El Capitan 10.11.5(15F34)
HID over GATT は Battery Service と DeviceInformationService と HIDService を提供します。
Battery Service と DeviceInformationService は mbed の BLE_API に含まれています。これはどちらのどの characteristics も open link (ペアリングなしで全ての情報を得られる) で公開しています。
HIDService は BLE_HID というライブラリに含まれています。これの characteristics は暗号化必須になっています。
問題
OS X でどうしてもペアリングが行なわれず、HID サービスが全く見えない状態でした。
Anrdoid や Windows 10 では問題なくペアリングできました。
OS X での挙動を詳細にすると
- Bluetooth 機器一覧にでる
- 「ペアリング」ボタンがでる
- デバイスとの接続はできる
- 「接続中」のまま止まり、パスコードなどを訊かれない
デバイス側のデバッグログ的には
- onConnect は呼ばれる
- セキュリティ関係のコールバックは一切呼ばれない
で、かなりお手上げでした。
解明と解決
OSX ではどうやら、何らかの条件で open link な characteristics があると bonding を行おうせず限定的なアクセスになり、HID サービスが見えないようでした。
仕方ないので BatteryService.h と DeviceInformationService.h をコピーして中身を書きかえて、requireSecurity(SecurityManager::SECURITY_MODE_ENCRYPTION_NO_MITM) するように変えました。外部から変えるAPIがないので辛い感じです。
BLE Nano + mbed の ADC の基準電圧
BLE Nano + mbed での ADC の基準電圧は VDD の 1/3 になっています。当然ながら VDD が変動するケースではこの基準は受け入れられません。BLE Nano は性質的に電池駆動するケースも多々あるでしょうから、デフォルトでVDD基準なのは解せない仕様です。
mbed には基準を変更する API などがないので、自力で設定します。BLE Nano には内部バンドギャップリファレンスの 1.2V もあるので、これを使うようにします。
NRF_ADC->CONFIG = (ADC_CONFIG_RES_10bit << ADC_CONFIG_RES_Pos) | (ADC_CONFIG_INPSEL_AnalogInputOneThirdPrescaling << ADC_CONFIG_INPSEL_Pos) | (ADC_CONFIG_REFSEL_VBG << ADC_CONFIG_REFSEL_Pos) | (ADC_CONFIG_EXTREFSEL_None << ADC_CONFIG_EXTREFSEL_Pos);
ADC_CONFIG_REFSEL_VBG がバンドギャップリファレンスを使うようにする部分です。あとの部分は元のままです。なお、アナログ入力側には1/3の分圧が入っています。
mbed のライブラリ側ではこれらのオプションを保持して ADC を行うようなコードに(今のところは)なっているので、AnalogIn 初期化後に一度設定すればずっと有効です。
備考:VDD の電圧を測りたい場合
VDD の電圧をADCしたい場合は、外部接続しなくとも INPSEL を ADC_CONFIG_INPSEL_SupplyOneThirdPrescaling にすればできそうです。mbed 側では対応していませんが、現状の実装だと、CONFIG を書きかえてから、AnalogIn (なんでもいい) を read すればいけそうな雰囲気です。
備考:mbed 側の実装
TARGET_MCU_NRF51822 の analogin_api.c に実装があります。
NRF_ADC->CONFIG = (ADC_CONFIG_RES_10bit << ADC_CONFIG_RES_Pos) | (ADC_CONFIG_INPSEL_AnalogInputOneThirdPrescaling << ADC_CONFIG_INPSEL_Pos) | (ADC_CONFIG_REFSEL_SupplyOneThirdPrescaling << ADC_CONFIG_REFSEL_Pos) | (analogInputPin << ADC_CONFIG_PSEL_Pos) |
自宅のマウスを Microsoft Sculpt Ergonomic Mouse に変えた
それほど使っているマウスに不満があるわけではなかったが、マイクロソフトからおもしろいマウスが出ていたので買ってみた。
今まで使っていたマウスは Logicool M310 というやつです。
Sculpt Ergonomic Mouse は M310 と比べると
- 重い (だいぶ重量感がある)
- 握りやすい
- 表面テカテカ
- 単3電池が2本必要 (M310 は1本)
- 中ボタンが軽い
- 中ボタンにチルトがある
M310 も単3電池が入っているのでそこまで軽いわけではないですが、 Sculpt Ergonomic Mouse は単3電池2本なのでだいぶ重く感じます。会社では電池とかが入っていない有線の Microsoft IntelliMouse Optical を使っていますが、おそろしく重量が違う。頻繁に持ちあげる場合、重いというのはマイナス要素ですね。
表面テカテカなのは良くないです。ぱっと見はいいんですが、手垢ですぐ汚れて嫌な感じになってきます。
中ボタンが軽いのは良いです。M310 は中ボタンがかなり押しにくいです。
中ボタンにチルトがありますが必要ないかなと思いました。
握りやすさ的にはとてもいいです。気持ちよく使えます。M310 は良くも悪くも形は普通なので、気持ち良く使えるかというとそうでもなくて、普通な感じ。 Sculpt Ergonomic Mouse は気持ちいい。
買いなのか
とにかく重いのが現状の不満点です。とはいえ慣れるかもしれません。
✖
NEW GAME、とにかくキャラクターが可愛いくて、アニメでもマンガと同じぐらい可愛い。ひふみんがとにかく可愛い。可愛い。
sdkman を自分で入れておいて…
.zshrc に勝手に sdkman とやらの設定が入っていて、コワッと思った。しかし sdkman は gradle をインストールするときに確かに自分で入れたのであった。
しかし名前がひどい。Java 関係のツールを簡単に入れれるツールという感じだけど名前に Java 感が一切ない。つらい。
✖
連休とあわせて6日ほど休んだけど、全く休み足りない。まだまだやりたいことがあった。しかし仕事は忙しくなるし、毎日眠いし、頭の中がすっきりしないし、どうしようもない。
HHKB を左右分割エルゴノミクスキーボードにする (OSX)
標題の通りですが HHKB を半分に割ってブチ壊すみたいな話ではないのでご安心ください。
- HHKBを2台用意します。
- HHKB 2台を横に並べます
- Karabiner を入れます
- 完成です
通常、キーボードを複数繋いでも、修飾キーは各キーボードごとに独立して管理されます。なので、2台キーボードを繋いで並べたとしても右のキーボードでShiftを押しながら左のキーボードのaを押してAを入力するみたいなことができません。
Karabiner を入れるとこの問題が解決します。インストールするだけで、全てのキーボードで修飾キーが共有されるようになり、同一のキーボード2台があれば左右分割のエルゴノミクスキーボードっぽく使うことができるようになります。
背景
ErgoDox を見てから左右分割キーボードに対して興味が沸いたので、簡単に試せる方法を探していました。Karabiner の機能ページを見てみたら修飾キーを共有する機能が書いてあったので「これでできるやん」と思いやってみました。HHKB は自宅用と会社用とかで2台持っている人も多いと思うので、意外と試しやすいのではないでしょうか?
あと ErgoDox って結構高価なので、不安なら価値が安定しているHHKB2台買っても良いのではないしょうか。僕は1台は貰いものなので他人のこと言えませんが……
感想
最初の5分ぐらいは同じキー配列にも関わらず、ちょっと頭が混乱していてうまく打てませんでした。少ししたら全く問題なく打てるようにはなりました。しかしパスワードはかなり複雑で特殊な打ちかたをしていたのでうまく打てません。
とりあえず使うにはこれでもいいんですが、使い続けようと思うと会社用と家用に2台ずつHHKBが必要になって大変コスパが悪そうです。また、修飾キー共有をソフトウェアに頼っているので環境が限定されます。
左右分割すればエルゴノミクスなのか?
知るかよ
BLE Nano + mbed の Serial の実装がつらい感じだった
I2C がうまく動かなくて調べていたら、どうやら UART を使おうとすると競合するようでした。確かにピン配置を見ると CTS/RTS と SDA/SCL はかぶっています。これは事前に知っていましたが、RXD と TXD とはかぶっていないので、問題なく使えると思っていました。
しかし実際は Serial を使おうとすると問答無用で該当ピンが CTS/RTS が設定されるコードがハードコードされています。
TXD/RXD は外部から渡せるようになっているのに、CTS/RTS は決め打ちで勝手に機能割当されます。なんやねん。
解決方法
Serial を初期化したあと、CTS/RTS の機能割当をはずせば良いようです。すなわち
NRF_UART0->PSELRTS = 0xFFFFFFFFUL;
NRF_UART0->PSELCTS = 0xFFFFFFFFUL;
というようなコードを main を最初あたりに入れておけば良いです。0xFFFFFFFFUL は Disconnected を表す定数です (NC という定数になっていますが型が違うのでリテラルで書いてます)
KiCAD で複数ボードプロジェクトを運用する
背景
KiCAD は1つのプロジェクトにつき1つのボードしか作れない。小さな基板であれば1つの基板にVカットを入れるでいいが、どうしても複数ボードとして設計したい場合に困る。
複数プロジェクトにして回路図をわけると、今度はこの回路図間でコピペが動かないという問題が発生する。KiCAD はプロジェクト間のブロックコピー・ペーストができない。
階層シート
KiCAD は階層シートという、回路図については複数ページに分けて書く機能をサポートする。これは部分的に別の .sch 回路図ファイルとして分離して、プロジェクトルートの回路図から参照するという形をとる。名前の通り、これはツリー上にすることができる。
考えたやりかた
考えかた
- 全体を管理するプロジェクトとルート回路図を作る
- 各基板ごとに階層シートとして回路図ファイルを分離する
- 各基板ごとに別のプロジェクトとルート回路図を作る
- 各基板のルート回路図から全体を管理するプロジェクトの階層シートを参照する
これで原理的には全体を管理するプロジェクトのルート回路図を開いて各階層シート(モジュール)に入ったり出たりして図を書け、各基板ごとのプロジェクトのルート回路図を開けば各基板ごとだけのネットリストを吐ける。
実際のオペレーション
ルートに何も置かず、それぞれのボードごとに階層シートとして、まず全て設計する。このとき作る回路図を Root.sch とする。階層シートはそれぞれ _module_a.sch とか、あとあと被らないような命名にしておく。
全体ができたら (できる前でもいいけど)、Root.sch をモジュール数分だけコピーする。これは KiCAD 上ではできないので適当にターミナルとかでやる
$ cp Root.sch ModuleA.sch $ cp Root-cache.lib ModuleA-cache.lib
cache.lib もコピーしないとダメ。
この状態で KiCAD のプロジェクトビューを更新すると、コピーした回路図が見えるので開く。開いてから保存すると勝手に ModuleA.pro が作られて別プロジェクトとなる。ModuleA.sch ではボードに実装したい階層シート以外を削除する。ModuleA.sch はこれで1つのボードに対応する回路図となる。
他のモジュールも同じようにコピーして必要な階層シートだけを残す。
結果的にできる構造
Root.sch _module_a.sch _module_b.sch ModuleA.sch _module_a.sch ModuleB.sch _module_b.sch
それぞれキャメルケースのファイル名の回路図がルート回路図で、_ から始まるスネークケースのファイル名の回路図が階層化回路図になっていて、上記のような参照関係になる。
こうすると、Root.sch で全体を見ながら各階層化回路図に変更をかけたことが、個々のモジュール用回路図にも反映される。ネットリストはモジュールごとの回路図から生成するので、これでボードごとのネットリスト出力ができる (Root.sch に対応する kicad_pcb ファイルは作らない)。
ワークフロー
基本的に Root.sch 開いた状態で階層化回路図を編集する。
これで保存をして閉じて、ModuleA.sch を開くと、編集が反映された状態になっている。この状態でフットプリントの関連付け、及びネットリスト出力をして pcbnew すると、該当する基板の部品だけを出せる。
ネットリスト・pcbnew した後は以下のようになる
Root.sch はあくまで全体管理用なのでネットリストとかは出さない。
.sch 間のコピペ
コピペ対象の回路図が階層化回路図になっていなければならない。なので、全体を見ながらモジュールの構成をしたいときは Root.sch を開いてそれぞれコピペ(ブロックを保存)することになる。
他に方法はないのか
わかりません。普通に全部を吐きだしたネットリストから、うまいこと各階層シートごとのネットリストだけ分離するようなスクリプトを書けばもっと楽に管理できるかもしれません。
標準のネットリストファイルはS式なんですが、ちょっと見た感じだと簡単にはできない気がしました。
✖
仕事が忙しくなってくると、同時に趣味もやりたいことがいっぱい出てきて(逃避行動)、主観的な忙しさが指数的に上がっていく感じがする。
無線マウスの電池を軽量化
というコメントがついていて、単4+スペーサーで軽量化というのになるほど!!! と思ったのでやってみました。
これらを買って元からついてきていたアルカリ電池と入れ替えしました。
感想
確かに軽くはなったんですが、本体そのものが思ったより重くてあんまり実感がわきませんでした。しかしじわじわ効いてくると信じたい。
備考
スペーサーのやつはレビューを読むと違う商品が送られてくるパターンがあるみたいです。今回 umiwo というところから買いましたが、ちゃんとしたのが送られてきました。ただ、この販売者はもうこの商品を出品していないようです。
「ちゃんとした」というのは、プラスにもマイナスにもちゃんと電極がついているやつです。電極はスペーサー内で多少カタカタと動くのですが、これにより機器にセットしたとき機器側のバネで抑えつけられることで導通が確保されるようになっているようです。
ポケモン Go
僕はポケモンシリーズを一切プレイしたことがなくて、子供のときはコロコロか何かについてきたポケモンのモンスター一覧を眺めて「進化先が複数あるポケモンとかいるんか! すげーな!」とか思っていただけだった。ゲームボーイを持ってなかったし、買ってもらってまで(お小遣いでは買えないし、交渉するのが大変だった)やるほどではなかった。
それはともかく、Ingress は結局無視してたけど (やりはじめるタイミングがなかった)、ポケモンはやってみることにした。なんといっても世界的ブーム!! 長いものにはマカレロ!!! 同じアホなら踊らにゃ損ソン!!!
住んでいるところのポケスポットをいくつか回ってみたりした。明かに「これはポケモンGoやってるな」っていう人が結構いてすごい。Ingress のことを想うと知的財産ってすごいという感じがする。都心ではないがルアーモジュールが刺さってるスポットも結構あった。
それはともかく、今住んでるところは小学生から断続的に住んでいる土地なので、まぁだいたいどんなスポットがあるかは分かっているつもりだったけど、そんなことなかった。「こんなにお地蔵さんあったのか」みたいな発見はある。面白い。
ゲームシステムの感想
ポケモンGo 良いと思ったのは、ゲーム内のコミュニケーション要素がかなり削られているところ。今のところジムで対戦する以外にゲーム内で他プレイヤーとの接点はない。
ゲームの主目的も「ポケモンの収集」がメインであって、自分だけで完結する。
Ingress はもはや古参と暗黙のルールが作られたネトゲなので、初心者が変なことをするとなんか言われるという負のモチベーションがある。成熟したネトゲには全てを理解している人しかプレイしてはいけないみたいな感じがだいたいあって (変なことをすると「なんでxxしないの?」みたいなことを言われたりとか)、そういうのは初心者プレイヤーを大きく不愉快にさせる。Ingress はもうそういう状態で、もはや Ingress を初める気にならない大きな理由はこれになる。
ポケモンGoはまだ新しいというのもあるが、そもそもシステム的にそういうのがない。原理的に、他人に不利益になるようなことは殆どできない。ポップしたポケモンはその場にいる全ての人で共有して沸くが「取り合い」にはならず、全ての人がボールを投げられる。ジムの取り合いはポケモンの収集には必須要素ではないし、全く関わらずに強いポケモンを育てたりもできる。
デジタルノギスを買ったのに結局アナログばかり使っている
デジタルとアナログだと1ケタ精度が違うのだけど、デジタルだとその分取り扱いに気をつける必要があってちょっと面倒だったりする。デジタルノギスは箱に入れて保管しているので、雑に計りたいときは結局雑に使えるアナログしか使わない。そして殆どのケースで精度は必要なくて雑に計ればことたりてしまう。
デジタルノギスを使うのは結局、現物しかないものの寸法を図面に起こすときぐらいしかない。全く使ってないわけではないから無駄とまではいえないけど、そんなに必要ではなかったな、という感想。
あとそもそも買ったデジタルノギスはいまいちすべりが悪くて使いにくい……
OS X で KiCAD を使う際の注意点
前提
どのOSでもレンダリングは遅くて、多少乱れるので、OS X だから遅いのかな〜とか考える必要はない。
OS X 固有の話
- pcbnew / eeschema は一定の大きさまでウィンドウを広げると刺さります
- GPU のメモリとかに左右されるかもしれません
- 自分の環境で「ギリギリまで広げられる範囲」を見つける必要があります
- Retina だとちょっと広げただけで刺さるので、Retina ではない外部ディスプレイを使いましょう。内蔵Retina に限らず、ppi 高いディスプレイだと使いにくいのでダメです……
- pcbnew を起動したときOpenGL ビューの初期化に失敗します
- 気にしないで起動してから OpenGL ビューに変えれば普通に動きます
- または標準ビューにしましょう
- pcbnew はズームレベルを広げすぎる(俯瞰にしすぎる)と刺さります
- うっかりマウスホイールを回転しすぎないようにしましょう
- これが一番困ります
eeschema / pcbnew 共通の罠
- ホイール使うとポインタが飛ぶ!!
- 「設定」から「拡大縮小時にカーソルを中心へ移動」のチェックを外します
- 中クリックしながらドラッグでパンする機能が動かない
- 「設定」から「画面のパンにマウスの中ボタンを使用」にチェックを入れます
- 一回ウィンドウの内側を左クリックすると動いたりします
- フットプリントの関連づけに自分の部品がでない
- 既存ライブラリにある部品名とかぶっていると出ないことがあります (優先順位による)
pcbnew の罠
- 描画モードによって機能が変わります
- 部品を一括で並べかえる機能はデフォルトのビューじゃないと使えません
- おしのけ配線は OpenGL のビューじゃないと使えません
- 部品を一括で並べかえる機能は基板外形がないと機能しません
- チュートリアル的なPDFだと外形なしでやってる風なんですが、できません
- 配線の undo できない
- 配線ツールを選択している状態だと undo できないので ESC 連打して通常の選択ツールにします。するとなんと undo できます。
- 全配線の ripup
- 標準描画モードにして、全体を選択する。このとき選択対象にワイヤーとviaを入れる。選択されたら削除する
- 配線を維持してコンポーネントの移動
- OpenGL ビューだとできません
- 標準ビューだと回路図エディタと同様に G でできる
- ここにさらに追記されます
OS X で KiCAD を使う際の注意点
前提
どのOSでもレンダリングは遅くて、多少乱れるので、OS X だから遅いのかな〜とか考える必要はない。
OS X 固有の話
- pcbnew / eeschema は一定の大きさまでウィンドウを広げると刺さります
- GPU のメモリとかに左右されるかもしれません
- 自分の環境で「ギリギリまで広げられる範囲」を見つける必要があります
- Retina だとちょっと広げただけで刺さるので、Retina ではない外部ディスプレイを使いましょう。内蔵Retina に限らず、ppi 高いディスプレイだと使いにくいのでダメです……
- pcbnew を起動したときOpenGL ビューの初期化に失敗します
- 気にしないで起動してから OpenGL ビューに変えれば普通に動きます
- または標準ビューにしましょう
- pcbnew はズームレベルを広げすぎる(俯瞰にしすぎる)と刺さります
- うっかりマウスホイールを回転しすぎないようにしましょう
- これが一番困ります
eeschema / pcbnew 共通の罠
- ホイール使うとポインタが飛ぶ!!
- 「設定」から「拡大縮小時にカーソルを中心へ移動」のチェックを外します
- 中クリックしながらドラッグでパンする機能が動かない
- 「設定」から「画面のパンにマウスの中ボタンを使用」にチェックを入れます
- 一回ウィンドウの内側を左クリックすると動いたりします
- フットプリントの関連づけに自分の部品がでない
- 既存ライブラリにある部品名とかぶっていると出ないことがあります (優先順位による)
pcbnew の罠
- 描画モードによって機能が変わります
- 部品を一括で並べかえる機能はデフォルトのビューじゃないと使えません
- おしのけ配線は OpenGL のビューじゃないと使えません
- 部品を一括で並べかえる機能は基板外形がないと機能しません
- チュートリアル的なPDFだと外形なしでやってる風なんですが、できません
- 配線の undo できない
- 配線ツールを選択している状態だと undo できないので ESC 連打して通常の選択ツールにします。するとなんと undo できます。
- 全配線の ripup
- 標準描画モードにして、全体を選択する。このとき選択対象にワイヤーとviaを入れる。選択されたら削除する
- 配線を維持してコンポーネントの移動
- OpenGL ビューだとできません
- 標準ビューだと回路図エディタと同様に G でできる
- ここにさらに追記されます