dot by dot だと細かすぎると感じることがあるが、だからといって高解像度設定だと狭すぎる。(結局 dot by dot で使ってる)
ということで、5K が本命だなと感じている。
Dell ディスプレイ モニター UP2715K 27インチ/5K/IPS低反射/8ms/MimiDPx1,TwinDPx1/AdobeRGB 99%/USBハブ/スピーカ内蔵/3年間保証 cho45
最近まで 5K は DELL の 27インチが20万ぐらいという感じだったが、いつのまにか HP Z27q 5K というのも出ていて、これがだいぶ安い。
どちらも AdobeRGB 99% の色域。
今うちのモニタは 27インチ 2560x1440 (AdobeRGB) と 24インチ 4K (sRGB) なので、2560x1440 を 5K に単純に置き換えられそう。なんだけど、現実的には以下の点で難しい。
モニタの進化についていけてない……
結構前にAMP 対応しようと思ったけどやめたときのメモを掘り起こしてポストしておく。
AMP のチュートリアル的なやつ数回眺めて「なんか(標準として)イマイチだなー」と感じつつ、 Google がサポートするなら一回試すぐらいはしようと思いやってみましたが、対応を見送りました。
https://www.ampproject.org/docs/get_started/technical_overview.html 見ると、別に AMP だからできるのだ！っていう機能はない。
AMPには2つの要素が同居している
後者はつまり AMP を使っている限り悪意のあるスクリプトのあるページにはなりませんよという保証。
検索流入に特化するならメリットになる。Google の CDN 経由で配信されるのが大きい。
しかし、似たような構成 (特にいえばJS無効の) のページのロード時間ってそもそも遅くない。コネクションにかかる時間分の速度向上のために、わざわざ特殊なマークアップで書くメリットはあるだろうか。
結局 AMP がやってることって「JSなしのページのキャッシュ・プリロード」+「オレサマのJSなら特別に実行してやっても良いぞ」みたいな感じなので、そのために変なカスタムエレメントとか入れてんの? レイアウトまわりにCSS以外の概念入れんの?? という疑念が晴れない。
元々 Cache-Control: public という便利なのがあるのだから、その場合はキャッシュ済みのを CDN から配信するのを優先したらいいだけじゃないか? 既存技術の延長でなんとかできる範囲ではなかったのだろうか? 任意スクリプトってのが最大の問題だけど、AMPならオッケーってのはどうなのか?
ベンダープリフィックスつきのボイラープレートをいちいち書かされるのも意味不明。新しいベンダー出てきたらどうすんの?
カスタムエレメントも、amp-twitter とか amp-facebook とか、どういうつもりで追加してるのかわからないエレメントがたくさんある。いろんなサービスが「カスタムエレメントを定義してくれ」といったら対応コードが無限に増えていくんでしょうか。amp-ad も、メジャーな広告ネットワークをサポートしているけど、そもそもサポートする広告ネットワークを指定されてるのが気にくわない。いろんな無限のアドネットワークがが「ウチにも対応してくれ」といったら対応コードが無限に増えていくんでしょうか。
と、だんだんイライラしてきたのでやめて、別の見方をしてみることにします。
あたりを考えると、変なJSライブラリを使うよりはマシそうな雰囲気があります。この捉えかたで多少心が落ち着きました。
「AMP とは準 static ページを作るためのJSフレームワーク」であって、Google が対応済みという大きなメリットがある! 万歳!!! Google が対応済みってのがとにかく最高!!!
デジタルとアナログだと1ケタ精度が違うのだけど、デジタルだとその分取り扱いに気をつける必要があってちょっと面倒だったりする。デジタルノギスは箱に入れて保管しているので、雑に計りたいときは結局雑に使えるアナログしか使わない。そして殆どのケースで精度は必要なくて雑に計ればことたりてしまう。
デジタルノギスを使うのは結局、現物しかないものの寸法を図面に起こすときぐらいしかない。全く使ってないわけではないから無駄とまではいえないけど、そんなに必要ではなかったな、という感想。
あとそもそも買ったデジタルノギスはいまいちすべりが悪くて使いにくい……
どのOSでもレンダリングは遅くて、多少乱れるので、OS X だから遅いのかな〜とか考える必要はない。
どのOSでもレンダリングは遅くて、多少乱れるので、OS X だから遅いのかな〜とか考える必要はない。
僕はポケモンシリーズを一切プレイしたことがなくて、子供のときはコロコロか何かについてきたポケモンのモンスター一覧を眺めて「進化先が複数あるポケモンとかいるんか! すげーな!」とか思っていただけだった。ゲームボーイを持ってなかったし、買ってもらってまで(お小遣いでは買えないし、交渉するのが大変だった)やるほどではなかった。
それはともかく、Ingress は結局無視してたけど (やりはじめるタイミングがなかった)、ポケモンはやってみることにした。なんといっても世界的ブーム!! 長いものにはマカレロ!!! 同じアホなら踊らにゃ損ソン!!!
住んでいるところのポケスポットをいくつか回ってみたりした。明かに「これはポケモンGoやってるな」っていう人が結構いてすごい。Ingress のことを想うと知的財産ってすごいという感じがする。都心ではないがルアーモジュールが刺さってるスポットも結構あった。
それはともかく、今住んでるところは小学生から断続的に住んでいる土地なので、まぁだいたいどんなスポットがあるかは分かっているつもりだったけど、そんなことなかった。「こんなにお地蔵さんあったのか」みたいな発見はある。面白い。
ポケモンGo 良いと思ったのは、ゲーム内のコミュニケーション要素がかなり削られているところ。今のところジムで対戦する以外にゲーム内で他プレイヤーとの接点はない。
ゲームの主目的も「ポケモンの収集」がメインであって、自分だけで完結する。
Ingress はもはや古参と暗黙のルールが作られたネトゲなので、初心者が変なことをするとなんか言われるという負のモチベーションがある。成熟したネトゲには全てを理解している人しかプレイしてはいけないみたいな感じがだいたいあって (変なことをすると「なんでxxしないの?」みたいなことを言われたりとか)、そういうのは初心者プレイヤーを大きく不愉快にさせる。Ingress はもうそういう状態で、もはや Ingress を初める気にならない大きな理由はこれになる。
ポケモンGoはまだ新しいというのもあるが、そもそもシステム的にそういうのがない。原理的に、他人に不利益になるようなことは殆どできない。ポップしたポケモンはその場にいる全ての人で共有して沸くが「取り合い」にはならず、全ての人がボールを投げられる。ジムの取り合いはポケモンの収集には必須要素ではないし、全く関わらずに強いポケモンを育てたりもできる。
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 はあくまで全体管理用なのでネットリストとかは出さない。
コピペ対象の回路図が階層化回路図になっていなければならない。なので、全体を見ながらモジュールの構成をしたいときは Root.sch を開いてそれぞれコピペ(ブロックを保存)することになる。
わかりません。普通に全部を吐きだしたネットリストから、うまいこと各階層シートごとのネットリストだけ分離するようなスクリプトを書けばもっと楽に管理できるかもしれません。
標準のネットリストファイルはS式なんですが、ちょっと見た感じだと簡単にはできない気がしました。
仕事が忙しくなってくると、同時に趣味もやりたいことがいっぱい出てきて(逃避行動)、主観的な忙しさが指数的に上がっていく感じがする。
id:h2u エルゴマウスの持ちやすさ。単三*2で重いマウス、単四+スペーサーにして軽量化とかはやってた。
というコメントがついていて、単4+スペーサーで軽量化というのになるほど!!! と思ったのでやってみました。
【BLUELOTUS】単4形電池を単3形電池に変換 電池変換アダプター 電池スペーサー BL-224-RK (6本) cho45
Amazonベーシック 充電池 充電式ニッケル水素電池 単4形8個セット (最小容量800mAh、約1000回使用可能) cho45
これらを買って元からついてきていたアルカリ電池と入れ替えしました。
確かに軽くはなったんですが、本体そのものが思ったより重くてあんまり実感がわきませんでした。しかしじわじわ効いてくると信じたい。
スペーサーのやつはレビューを読むと違う商品が送られてくるパターンがあるみたいです。今回 umiwo というところから買いましたが、ちゃんとしたのが送られてきました。ただ、この販売者はもうこの商品を出品していないようです。
「ちゃんとした」というのは、プラスにもマイナスにもちゃんと電極がついているやつです。電極はスペーサー内で多少カタカタと動くのですが、これにより機器にセットしたとき機器側のバネで抑えつけられることで導通が確保されるようになっているようです。
標題の通りですが HHKB を半分に割ってブチ壊すみたいな話ではないのでご安心ください。
通常、キーボードを複数繋いでも、修飾キーは各キーボードごとに独立して管理されます。なので、2台キーボードを繋いで並べたとしても右のキーボードでShiftを押しながら左のキーボードのaを押してAを入力するみたいなことができません。
Karabiner を入れるとこの問題が解決します。インストールするだけで、全てのキーボードで修飾キーが共有されるようになり、同一のキーボード2台があれば左右分割のエルゴノミクスキーボードっぽく使うことができるようになります。
ErgoDox を見てから左右分割キーボードに対して興味が沸いたので、簡単に試せる方法を探していました。Karabiner の機能ページを見てみたら修飾キーを共有する機能が書いてあったので「これでできるやん」と思いやってみました。HHKB は自宅用と会社用とかで2台持っている人も多いと思うので、意外と試しやすいのではないでしょうか?
あと ErgoDox って結構高価なので、不安なら価値が安定しているHHKB2台買っても良いのではないしょうか。僕は1台は貰いものなので他人のこと言えませんが……
最初の5分ぐらいは同じキー配列にも関わらず、ちょっと頭が混乱していてうまく打てませんでした。少ししたら全く問題なく打てるようにはなりました。しかしパスワードはかなり複雑で特殊な打ちかたをしていたのでうまく打てません。
とりあえず使うにはこれでもいいんですが、使い続けようと思うと会社用と家用に2台ずつHHKBが必要になって大変コスパが悪そうです。また、修飾キー共有をソフトウェアに頼っているので環境が限定されます。
知るかよ
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 という定数になっていますが型が違うのでリテラルで書いてます)
マイクロソフト マウス ワイヤレス/5ボタン/人間工学デザイン ブラック Sculpt Ergonomic Mouse for Business 5LV-00004 cho45
それほど使っているマウスに不満があるわけではなかったが、マイクロソフトからおもしろいマウスが出ていたので買ってみた。
今まで使っていたマウスは Logicool M310 というやつです。
Sculpt Ergonomic Mouse は M310 と比べると
M310 も単3電池が入っているのでそこまで軽いわけではないですが、 Sculpt Ergonomic Mouse は単3電池2本なのでだいぶ重く感じます。会社では電池とかが入っていない有線の Microsoft IntelliMouse Optical を使っていますが、おそろしく重量が違う。頻繁に持ちあげる場合、重いというのはマイナス要素ですね。
表面テカテカなのは良くないです。ぱっと見はいいんですが、手垢ですぐ汚れて嫌な感じになってきます。
中ボタンが軽いのは良いです。M310 は中ボタンがかなり押しにくいです。
中ボタンにチルトがありますが必要ないかなと思いました。
握りやすさ的にはとてもいいです。気持ちよく使えます。M310 は良くも悪くも形は普通なので、気持ち良く使えるかというとそうでもなくて、普通な感じ。 Sculpt Ergonomic Mouse は気持ちいい。
とにかく重いのが現状の不満点です。とはいえ慣れるかもしれません。
NEW GAME、とにかくキャラクターが可愛いくて、アニメでもマンガと同じぐらい可愛い。ひふみんがとにかく可愛い。可愛い。
.zshrc に勝手に sdkman とやらの設定が入っていて、コワッと思った。しかし sdkman は gradle をインストールするときに確かに自分で入れたのであった。
しかし名前がひどい。Java 関係のツールを簡単に入れれるツールという感じだけど名前に Java 感が一切ない。つらい。
連休とあわせて6日ほど休んだけど、全く休み足りない。まだまだやりたいことがあった。しかし仕事は忙しくなるし、毎日眠いし、頭の中がすっきりしないし、どうしようもない。
http://redbearlab.com/blenano/
技適が通ってる小さい BLE 組込みの ARM SOC です。
とりあえず mbed のオンラインコンパイラを使っています。というのもライブラリのリンクとかでハマるのが嫌だったからです。が、そのうち platformio で gcc ベースの開発はしたいところです。
(この写真は MK20 のピンヘッダのうち、USBコネクタ側のピン2つが立っておらずスルーホールのままなので見間違えないように気をつける必要があります。MK20 + BLE Nano のセットを買ったら最初からピンヘッダはんだ付け済みでこうなっていたので、セットで買ってる限りは問題ないと思いますが…)
MK20 という書きこみ装置に亀の子的に挿して開発ができるんですが、これだと単に書きこめるってだけで周辺回路が作れないので、ブレッドボードに接続します。
必要な接続がいまいちわかりにくいですが、以下を接続すれば良さそうです。
加えて、デバッグするなら
VDD は 1.8〜3.3V、VIN には 3.3V〜13V となっています。要は VIN にはレギュレータがついていて、VDD は直接入力になっているようです。
VDD + 0.3 が絶対定格。5V トレラントとかではないので注意が必要そう。MK20 は裏面のジャンパで 1.8V モードにできる。低い外部電圧を使いつつ開発したい場合は 1.8V モードにする必要がある。
定格とかはnRF51822のダウンロードページから、nRF51822-PS (nRF51822 Product Specification) をダウンロードして見ればわかる。
レジスタ一覧とかは同じくnRF51822のダウンロードページから、nRF51 RM (nRF51 Series Reference Manual) を見れば書いてある。
moco 使うといいです！！！ https://github.com/hotchpotch/moco
以下のようにするとよさそう
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 での挙動を詳細にすると
デバイス側のデバッグログ的には
で、かなりお手上げでした。
OSX ではどうやら、何らかの条件で open link な characteristics があると bonding を行おうせず限定的なアクセスになり、HID サービスが見えないようでした。
仕方ないので BatteryService.h と DeviceInformationService.h をコピーして中身を書きかえて、requireSecurity(SecurityManager::SECURITY_MODE_ENCRYPTION_NO_MITM) するように変えました。外部から変えるAPIがないので辛い感じです。
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 の電圧をADCしたい場合は、外部接続しなくとも INPSEL を ADC_CONFIG_INPSEL_SupplyOneThirdPrescaling にすればできそうです。mbed 側では対応していませんが、現状の実装だと、CONFIG を書きかえてから、AnalogIn (なんでもいい) を read すればいけそうな雰囲気です。
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) |
プログラミングが分かってる相手に気軽に挙動について訊ける機会なんてありませんね。仕事なら同僚に訊けばいいと思いますけど、同僚が暇とは限りませんし、学生ならそういった相手がいないことが普通ではないでしょうか。
ということで、独りで言語を学ぶ方法について考えます。
大変重要なところです。どの言語でも書けて、どの言語も多少の個性が出て、そこそこ簡単なものがいいですね。
ぼくの場合は blosxom という「テキストファイルをスキャンしてHTMLにするだけのブログツール」なんですが、まぁなんでもいいと思います。ぼくはウェブエンジニアなので、ブラウザに何か表示がでるとそれだけで嬉しいというところがあります。
どの言語も必ずどこかに言語リファレンスがあります。必ず公式のものを一式見れる状態にします。そしてできれば Chemr とか Dash みたいな瞬間的にリファレンスをひけるツールを用意します。
リファレンスは無限にひくことになるので、多少ここに時間をかけても良いところです。
とりあえず Hello, World! しましょう。Hello, World! をバカにしてはいけなくて、これは print デバッグという原始的でほとんどどんな言語でも通用するデバッグ方法を習得するために必要なことです。高級なデバッガは言語ごと、エディタごとに使い勝手が異なることが多いので、デバッグが辛すぎる状況になってから考えます。
このとき、公式にチュートリアルがあるならやってみても良いです。が、どうせチュートリアル見ても Hello, World! のやりかたぐらいしか分からないので無視しても良いです。
これぐらいあればベタっと動くコードを書くことができるはずです。
クラス構文とか、そういうものはとりあえず無視しましょう。Java とか C# だとエントリポイントを書くために最初っから必要になりますが、まずはできるだけ無視します。言語特有の機能はとりあえず置いておいて、動くコードにします。
多少動くものが書けそうなら、その言語で「最も良い書きかた」にできるだけ全てを直します。ここではリファレンスの特に文法をよく読んで「ぼくの考える最高に読みやすい書きかた」を探ります。とはいえ、だいたい言語ごとにセオリーが決まっているので、言語公式のライブラリとかを読むとてっとり早く雰囲気をつかめます。ただ、公式ライブラリが十分綺麗に書かれているとは限らないので、できるだけリファレンスに頼ったほうがいいと思います。
このとき大事なのは「これは読みにくいぞ」とか「オレはこう書きたいんだけど」という気持ちです。そういう自分の信念と、言語ごとの雰囲気の擦り合せを行います。できるだけ言語特有の良さを出すように書きます。最終的に「このコードは(他の言語名)から来たヤツが書いてんな」みたいな田舎臭さを消滅させることを目標とします。
リファレンスをひけば大丈夫です。安心しましょう。そして Google で検索すれば大抵のわからない問題は解決します。わからなかったことは公開される形で記録しつつ解決して、検索できるようにしましょう。そうすると後続の友達がいない人に優しいインターネットになります。