2016年 07月 11日

友達がいなくても新しい言語は学べる

プログラミングが分かってる相手に気軽に挙動について訊ける機会なんてありませんね。仕事なら同僚に訊けばいいと思いますけど、同僚が暇とは限りませんし、学生ならそういった相手がいないことが普通ではないでしょうか。

ということで、独りで言語を学ぶ方法について考えます。

作りたいものを決める

大変重要なところです。どの言語でも書けて、どの言語も多少の個性が出て、そこそこ簡単なものがいいですね。

ぼくの場合は blosxom という「テキストファイルをスキャンしてHTMLにするだけのブログツール」なんですが、まぁなんでもいいと思います。ぼくはウェブエンジニアなので、ブラウザに何か表示がでるとそれだけで嬉しいというところがあります。

リファレンスをひけるようにする

どの言語も必ずどこかに言語リファレンスがあります。必ず公式のものを一式見れる状態にします。そしてできれば Chemr とか Dash みたいな瞬間的にリファレンスをひけるツールを用意します。

リファレンスは無限にひくことになるので、多少ここに時間をかけても良いところです。

書きはじめる

とりあえず Hello, World! しましょう。Hello, World! をバカにしてはいけなくて、これは print デバッグという原始的でほとんどどんな言語でも通用するデバッグ方法を習得するために必要なことです。高級なデバッガは言語ごと、エディタごとに使い勝手が異なることが多いので、デバッグが辛すぎる状況になってから考えます。

このとき、公式にチュートリアルがあるならやってみても良いです。が、どうせチュートリアル見ても Hello, World! のやりかたぐらいしか分からないので無視しても良いです。

重要構文を覚える

  • 条件分岐 (if)
  • ループ (for)
  • リテラルの表記方法 "foo" は文字列、123 は数字など

これぐらいあればベタっと動くコードを書くことができるはずです。

クラス構文とか、そういうものはとりあえず無視しましょう。Java とか C# だとエントリポイントを書くために最初っから必要になりますが、まずはできるだけ無視します。言語特有の機能はとりあえず置いておいて、動くコードにします。

設計をなおす

多少動くものが書けそうなら、その言語で「最も良い書きかた」にできるだけ全てを直します。ここではリファレンスの特に文法をよく読んで「ぼくの考える最高に読みやすい書きかた」を探ります。とはいえ、だいたい言語ごとにセオリーが決まっているので、言語公式のライブラリとかを読むとてっとり早く雰囲気をつかめます。ただ、公式ライブラリが十分綺麗に書かれているとは限らないので、できるだけリファレンスに頼ったほうがいいと思います。

このとき大事なのは「これは読みにくいぞ」とか「オレはこう書きたいんだけど」という気持ちです。そういう自分の信念と、言語ごとの雰囲気の擦り合せを行います。できるだけ言語特有の良さを出すように書きます。最終的に「このコードは(他の言語名)から来たヤツが書いてんな」みたいな田舎臭さを消滅させることを目標とします。

友達がいなくても言語は学べるか

リファレンスをひけば大丈夫です。安心しましょう。そして Google で検索すれば大抵のわからない問題は解決します。わからなかったことは公開される形で記録しつつ解決して、検索できるようにしましょう。そうすると後続の友達がいない人に優しいインターネットになります。

2016年 07月 10日

MCD-ST Liberty SW License Agreement V2 はフリーなライセンスか?

STM32CubeMX でジェネレートされるコードは MCD-ST Liberty SW License Agreement V2 というライセンスになっています。これはコード上で以下にリンクしています。

http://www.st.com/software_license_agreement_liberty_v2

Copyright � 2015 STMicroelectronics International N.V.. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted, provided that the following conditions are met:

1. Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of STMicroelectronics nor the names of other contributors to this software may be used to endorse or promote products derived from this software without specific written permission.
4. This software, including modifications and/or derivative works of this software, must execute solely and exclusively on microcontroller or microprocessor devices manufactured by or for STMicroelectronics.
5. Redistribution and use of this software other than as permitted under this license is void and will automatically terminate your rights under this license.


THIS SOFTWARE IS PROVIDED BY STMICROELECTRONICS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS, IMPLIED OR STATUTORY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS ARE DISCLAIMED TO THE FULLEST EXTENT PERMITTED BY LAW. IN NO EVENT SHALL STMICROELECTRONICS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

  • 1はライセンス表示をそのまま残せといってるやつです
  • 2はバイナリ配布する場合もライセンス表示をどこかに表示しろという話です
  • 3はライセンス表示の名前について商標とかを気にしなくてよいという話だと思います
  • 4はこのソースコード及び派生物についてはSTマイクロのハードウェアだけで動かせということです
  • 5は許可外のことをすると権利失効しますという話です

大文字の部分は免責事項です。

基本的にSTMのデバイスで使う限りは広い使用が認められているように見えます。が、ハードを制限しているのでちゃんとフリーとはいえなそうです。

2016年 07月 04日

12V 出力のモバイルバッテリー

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 一択でしょう。

KX3 + Aukey Quick Charge 12V Out

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

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

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

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

ref.

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

2016年 07月 03日

YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa

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

感想はまたあとで

2016年 07月 01日

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 が消える
2016年 06月 29日

ASUS ZenFone 2 の Android M (6.0) アップグレードは遅延

2016 Q2 には (すなわち6月中には) アップグレードするという話だったのですが、どうやら遅延しているようです。以下はフィリピン版の ZenTalk のスレです。

There has been some changes in the upgrade timeline [ source], they have changed the initial timeline to "from 2nd quarter of 2016" (April onwards). We apologize for any delays that may occur on the update rollout for the following ASUS ZenFone models:

  • PadFone S (PF500KL)
  • ZenFone 2 Laser 6-inch (ZE601KL)
  • ZenFone Selfie (ZD551KL)
  • ZenFone 2 5.5-inch (ZE550ML, ZE551ML)
  • ZenFone 2 Deluxe (ZE551ML)
  • ZenFone 2 Deluxe Special Edition (ZE551ML)
  • ZenFone Zoom (ZX551ML)


The Android M (6.0) upgrade has arrived for these ZenFone models:

  • ZenFone 2 Laser 5-inch (ZE500KL)
  • ZenFone 2 Laser 5.5-inch/5.5 S (ZE550KL)
  • ZenFone Max (ZC550KL)
http://www.asus.com/zentalk/thread-55985-1-1.html

どこが最新の情報なのかよくわかりませんが、このトピックは6/27に更新されていて Sticky にも設定されているので、たぶんこれは最新の情報なのでしょう。一部モデルについてはリリース済みですが、他のモデルは遅延するみたいです。ここで "they have changed..." と言ってますが、これを投稿しているのはフィリピンの担当者のようなので、たぶん they というのはアップグレード担当部門のことを言っていると思われます (違う?)


Global 版 ZenTalk だと特別新規のアナウンスはなくて、27/06/2016 . no Android M. というスレで約束は守られるのかとちょっと燃えてます。というのも、元々アップグレードプランのスレの文言は以下のようなものでした。

The following ASUS ZenFone models will receive the Android M (6.0) upgrade in Q2 of 2016

http://www.asus.com/zentalk/thread-68552-1-1.html

これが

The following ASUS ZenFone models will receive the Android M (6.0) upgrade starting from Q2 of 2016:

http://www.asus.com/zentalk/thread-68552-1-1.html

と変わっており (フォーラムのタイムスタンプを見ると 2016/6/28 04:59)、Q2 以降という内容に変わっています。フィリピン版のスレの冒頭はこの文言変更についての言及のようです。

遅延自体はともかく、アナウンスするのに元スレッド書き変えというのはいただけないと思います。普通に考えると新規にスレ立ててアナウンスすべきでしょう。フィリピン版は担当者の裁量?で一応まともなアナウンスが出てるので、Global 版もそのようにしてほしい感じがします。


ここ半月ぐらい毎日アップグレードの確認をしてきましたが、どうも無駄だったみたいなので残念です。いつになるんでしょうね。

電源 VRM フェーズ数ってなんなのか

PC関係だとよく VRM (Voltage Regulator Module) フェーズ数という用語にでくわす。マザーボードやグラフィックボードのレビューを見ると「電源は6+1フェーズ」とかと書いてある。特に説明もないので意味不明である。

結論

先に結論を書くと、フェーズ数は多ければ多いほど良いというものではない。それに電源回路の良し悪しはフェーズ数で決まるわけではない。そういうものなので、こういう表記を見ても無視して良い。

マルチフェーズ同期整流

フェーズ数を理解するためには、マルチフェーズ同期整流について理解しないといけない。そもそもここでいう「電源回路」は定電圧 DC/DCコンバータのことで、外部供給の12VをCPUにあうように低電圧(そして大電流)に変換することを言っている。

同期整流はローサイド(負荷に対してマイナス側)もハイサイド(同じくプラス側)もFETでスイッチすることによって高効率に整流を行うことをいう。このとき、スイッチングによって出力にリプルが発生する。そこで、ハイサイドFET・ローサイドFETのスイッチのセットを複数に増やして、それぞれのスイッチを少しずつ位相(フェーズ)をずらして整流させることで、よりリプルが少なく安定した定電圧電源とすることができる。

つまり「VRM フェーズ数」の「フェーズ」とは「位相」のことになる。1フェーズにつき少なくともFET 2つと、スイッチングコントローラ回路が1つと必要になる。(ただしフェーズが増えてなくてもFETのペアの数をフェーズとしてカウントする間違った宗派もあるっぽい)

基本的にはフェーズ数が多いほうが高級とされている。部品点数が増えるので価格が高くなる。フェーズ数が多いことの利点としては

  • 電源供給が安定する
  • FET 1つあたりの電流を減らせる
    • 発熱が分散するので放熱しやすい
    • 部品の高さを抑えられる

欠点は

  • 部品点数が多いので
    • 価格が高くなる
    • 故障率が上がる
  • スイッチング損が増え、効率が下がる (特に低電流時)

回路まわりは、これが図ありでわかりやすい

6+1 とか 8+2 って表記は何なの?

マルチフェーズ同期整流についてわかっても、この表記は意味不明。

結論からいうと前の数字がCPU(GPU)コア用の電源のフェーズ数 (大電力) で、後と数字はCPU(GPU)のコア以外用のフェーズ数のようだが、この表記を誰が決めて使ってるのかさっぱりわからない。(ソースを探したけどわからなかった)

フェーズ数以外のVRMの要素

  • FETの数や性能
    • 具体的にはオン抵抗、並列にすれば減らせるが部品は増える
  • 同期整流コントローラの性能
    • 負荷追従性など
  • PWM 周波数
    • 高いほどコイルが小さくでき負荷追従性が上がるが、FETでのスイッチング損失が増えて効率が下がる。ノイズにも関係ある。
  • コイルの性能 (Q値)
    • コイルの直流抵抗値が低いほど低損失だが部品が大きくなる
    • コアの材質でも損失が出る
  • コンデンサの性能
    • ESR (等価直流抵抗) が低いほど負荷追従性が高く、リプルが減る

ちょっと考えただけでもいろいろ要素がありすぎるので、フェーズ数だけで何かを判断することはできない。

所感

最近のマザーボードは重要な機能はチップセットに殆ど統合されたしまったので、表面にほとんど部品が載ってない。そうすると見た目的にインパクトがあるのが電源回路だけになる。

マルチフェーズにするとFETとコイルが並んでかっこいいので、マルチフェーズがもてはやされるみたいなところがありそう。インターフェイス (M2 とか PCI-E とか) が進化しても、マザーボードの見た目的にはインパクトがないんで、電源を盛るみたいなことだと思う。

2016年 06月 22日

OS X のスリープの傾向と対策

man pmset して理解した内容を記録しておく。これが正確かは実際の挙動をちゃんと確認してないのでアレだけど、man 読んでないだろみたいなのよりはマシなはず…

Mac のスリープの種類

  • ディスプレイスリープ
  • スリープ
  • セーフスリープ
  • ディープスリープ

「ディスプレイスリープ」は画面の表示だけ消えている状態。ディスプレイのバックライトが消えて他のスリープと似た状態となるのでスリープの一種としたが、CPUはスリープしない。

「スリープ」はメモリへ電力供給したままCPUをスリープさせている状態。

「セーフスリープ」は「スリープ」と似ているが、来たるディープスリープに向けてメモリ内容を書き出した状態。この状態だと急に主電源消失してもディープスリープからの復帰と同じになるので、作業が失われないという意味でセーフ。復帰はメモリからなので早いが、書き出しがあるのでそこが遅い。

「ディープスリープ」はメモリ内容をファイルシステムに書き出して、コンピュータの全ての電源を切る。次回電源オン時は、ブートプロセスでこのファイルの所在を確認してロードする。コンピュータ全体として消費電力がゼロになる。

メモリ内容を書き出すかどうか、そのタイミングはいつかあたりがポイントになる。メモリ内容を書き出したり、読み戻したりするスリープは、メモリが増えるほど時間がかかることになる。(SSD の場合これによって寿命が縮まることを気にする人もいる)

pmset -g で見れる値との関係

pmset でパワーマネジメントまわりの変数を見ることができる。MacBook Pro で実行すると以下のようになった。

$ pmset -g
System-wide power settings:
 SleepDisabled          0
 DestroyFVKeyOnStandby          0
Active Profiles:
Battery Power           1
AC Power                -1*
Currently in use:
 standbydelay         10800
 standby              1
 womp                 1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 powernap             1
 gpuswitch            2
 networkoversleep     0
 disksleep            10
 sleep                0 (sleep prevented by iTunes, coreaudiod)
 autopoweroffdelay    14400
 hibernatemode        3
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         10
 acwake               0
 lidwake              1 

「ディスプレイスリープ」はdisplaysleepの値(単位は分)経過後に起こる。

各スリープは sleep の値(単位は分)経過後に起こる。このとき

  • hibernatemode = 0 なら「スリープ」
  • hibernatemode = 3 なら即座に「セーフスリープ」
  • hibernatemode = 25 なら即座に「ディープスリープ」

となる。

ただし「スリープ」や「セーフスリープ」に入っていても、standby = 1 の場合、standbydelay の値(単位は秒)経過後にメモリメージが書き出され「ディープスリープ」に移行する。また autopoweroff = 1 な場合も autopoweroffdelay の値(単位は秒)経過後にメモリイメージが書き出され「ディープスリープ」に移行する。standby との違いがわかりにくいが、standby はバッテリー駆動時の話で、autopoweroff は AC 接続時の話になっている。ErP Lot6 (待機電力基準) 準拠のため、autopoweroff があとから機能として追加されたという感じになっている。

ハイバネーションイメージを作りたくない場合

スリープ入りが遅くてうざい場合

ラップトップだと必ずセーフスリープする関係で、閉じたり開いたりを繰替えした場合になかなか起きてこなくてイラ立つことがある。この場合は常時セーフスリープに入るのがうざいケースなので、hibernatemode だけ 0 にすれば良さそう。

sudo pmset -a hibernatemode 0 

standbydelay / autopoweroffdelay 経過後のスリープはこの意図だと特段無効にする意味はないと思う。

とにかく絶対書き出したくない場合

ハイバネーションイメージからの復帰がそもそも遅いから嫌という場合とか、SSD が痛むのが気になる場合はとにかく無効にするしかない。消費電力が増えるのと、万が一バッテリー切れになった場合は作業内容が失われるのがデメリット。

To disable hibernation images completely, ensure hibernatemode standby and autopoweroff are all set to 0.

と書いてあるので、その通りにする。

以下のようにすると、全ての状況(バッテリだろうがAC駆動だろうがUPS起動だろうが) イメージ書きだしが無効になる。

sudo pmset -a hibernatemode 0 standby 0 autopoweroff 0

ref.