Arduinoの新しいボード 2019年

Arduinoから新しいボードが発表されています。他にもIoT向けArduinoブランドのSIMカードなども発表されています。

https://blog.arduino.cc/2019/05/17/whats-new-at-maker-faire-bay-area-2019/

ボードは、無線機能ありとなしのもので、無線機能は、BLE、WiFi+BT4.2。無線モジュールは、u-blox製で世界各国の認証取得済みのものが使われています。

とても手頃な価格ですし、Arduinoの豊富な作例、IDEとライブラリを使っている人の数と書籍の多さなど、プロトタイピングの良い選択肢だと思います。

ボードは4種類:

  • ARDUINO NANO 33 BLE 19米ドル
    • nRF52480ベース。9軸(LSM9DS1 加速度、ジャイロ、磁気)慣性センサ。
  • ARDUINO NANO 33 BLE SENSE 29..5米ドル
    • NANO33 BLEにセンサが増えたもの。
    • 気圧、湿度、周囲環境光、マイク。
  • ARDUINO NANO 33 IOT 18米ドル
    • ESP32ベースWiFi+BT4.2モジュール + プロセッサ Cortex-M0+ 48MHz Flash 256kB SRAM 32kB。
    • 6軸(加速度、ジャイロ)慣性センサ。
  • ARDUINO NANO EVERY 9.9米ドル
    • 無線機能はない、ベーシックなもの。
    • ATMega4809、Cortex-M0+ 20MHz, Flash 48kB, SRAM 6kB。

LeetCodeでrustを始めました

LeetCodeで、書いて動かして身につける

Rustというプログラミング言語 https://www.rust-lang.org を身につけたくなりました。

ただ言語を覚えても使えないのですが、LeetCode https://leetcode.com というサイトで練習問題を解いています。かなり、いいです。

なぜRustかといえば、もう、組み込み向けのファームウェアで、memset(*some_ptr, sizeof(some))して構造体を初期化しているつもりが、some_ptrがsome1という1バイトだけサイズが小さい構造体で、隣の1バイトに0を書き込んでしまって、隣にある構造体がたまたま先頭が通常は0である時だけフラグ1が立つフィールドで、滅多と異常な振る舞いはしないけど、たまに異常な振る舞いをする、実行状態依存のバグ調査なんて、二度としたくないからです。とはいえ、C++は私には難しすぎます。

Rustのドキュメントは https://doc.rust-lang.org にあります。日本語訳を出されているサイトが https://doc.rust-jp.rs にあります。ここには、プログラミング言語 Rust, 2nd Edition(最新版)/ The Rust Programming Language, Second Edition の日本語版が https://doc.rust-jp.rs/book/second-edition/ にあります。

他の言語から推移する

プログラミング言語を習得するには、最初にしっかりと基本的な説明を読み、その言語で素直に書けて他人が読みやすい表現を身につけていくのがよいと思います。素直にかけて読みやすい表現は、小さな1つの完結したプログラムを、数をたくさん書いて動かしてみるのがよいのではないでしょうか。

Rustをいきなり書くのは、無理です。全く訳がわかりません。だから、まずSwiftで動くコードを書いて、それをRustに書き直すことをしています。なぜSwiftかといえば、iOSアプリ開発が本業なので、今時の言語で今覚えている言語がSwiftだったからです。WPFアプリを書いていた20年程前なら、C# だったでしょう。

C言語で書くのは、全くの無意味だなと思います。今時の言語は、イテレータやら辞書やらがあって当たり前ですが、そんな概念がない言語でコードを書くのは、辛いですし、その言語で書いたコードを今時の言語に訳し直すのは、今時の言語の当たり前にある恩恵を全く無視することになり、やる意味がありません。C++という選択肢があるとは思いますが、C++は私には難しすぎます。

なんの工夫もない力づくのコードを、まずSwiftで書きます。処理自体は正しくても、実行時間が長すぎて不合格になったりします。そのコードを、Rustで書くと、十分に短時間で処理が終わり受け付けてもらえるのをみると、Rustを学ぶ理由は速さと自分に納得感が出てきます。

/post/start-rust-with-leetcode/screenshot_leet_code.png

トロイア遺跡の発見で知られるシュリーマンは、ものすごい数の言語を習得していたそうですが、その習得方法の一部に、すでに読んだことのある本の翻訳版を何度も繰り返して読むことがあったそうです。ほんとかどうか知りませんけど。すでに知っている言語で一度書いて、それを翻訳するのは、基本的な部分を身につけるには良さそうです。

XcodeとVS Codeでプレイグラウンド

LeetCodeのサイトは、ハイライト表示などのコードを書く支援機能もあり、コードを快適に書けます。ですが、身につけていない言語でコードを書く場合は、リアルタイムな入力補完や文法エラーの指摘が欲しいところです。

いわゆる、プレイグラウンドがローカルに欲しいところです。

Xcodeは、Macに無償でインストールできます。Xcodeで、メニュー新規作成からプレイグラウンドを作成して、Swiftで書いたコードをその都度評価、その都度実行ができます。

Rustの始め方は、 https://doc.rust-jp.rs/the-rust-programming-language-ja/1.6/book/getting-started.html に書いてあります。

Rustのプレイグランドな環境は、VS Codeを使います。

単体のソースファイルを実行するには、extensionで、Code Runner 0.9.8 をインストールします。Rustの適当なファイル(例えば main.rs のように拡張子をrsにしておけば)を新規作成して、適当にコードを書いて、右クリックで"Run code"をすれば、rustcデコンパイルしてくれます。コンパイラのエラーメッセージでコードが書けるなら、これでいいでしょう。

/post/start-rust-with-leetcode/screenshot_vscode.png

さらにリアルタイムな入力補完や文法チェックなどが欲しいなら、extensionで Rust (rls) 0.6.1 をインストールします。さらに、rustのCagoプロジェクトを作れば、依存関係も見た入力補完が利くようになります。

Rustの使いどこ?

Rustはべメタルからサーバーまで、幅広く使える言語ですが、私の個人的な要求は、数KBのメモリしかないマイコンで、今時の言語で開発をしたい、ただそれだけです。

今時の言語であれば、そもそも、やらなくてもいいこと、言語に組み込まれたあらゆる工夫や技術開発のおかげで、今ではもう苦労する必要がもうないものを、考古学的に現代で縄文人の生活をするようなことは、もう嫌なのです。苦労は買ってでもしろというなら、店頭に並べておくので、いくらでも買っていって欲しいくらいなのです。

forループで配列を処理するのに、配列の長さを間違えて、書き込んではならぬメモリ領域を暗に変更して、それがずっと後になって何かの処理に影響を及ぼしたり、あるいは及ぼさなかったりするのは、実際に実行されているあまたのデバイスで、稀に発生するが再現できない何かがあると言われるのは、もう嫌なのです。

配列の長さを確実にチェックするのに、{some_type * array_ptr, int count } と、わざわざ自分で配列の長さを記録して配列の処理ループを書くのは、嫌なのです。

今時の言語ならイテレータを使えば済むことを、わざわざforループでベタがきして、潜在的なバグを発生させる綱渡りのようなコードを、大昔に開発された言語で今書いて、地雷を自分で埋めて自分で踏み抜くのが、嫌なのです。

とはいえ、数KBくらいしかメモリがない、OSもないマイコン向けのバイナリを吐き出せる言語系というと、C言語かC++言語になっています。これらは直接機械語を吐き出します。今時の言語は、例えばJavaにしてもSwiftにしても、配列アクセス時の範囲チェックやメモリ管理などが必要ですから、ランタイムがコードを実行しています。ランタイムは、小さなメモリのマイコンに移植するのは、例えばtinyCLRなど実装例がありますが、1桁KBには無理です。

Rustを使ってみると、処理経過がスタックにズラーっと並び、しかも無駄なコピーも発生させずに、処理が終われば長くのびたスタックが元の長さに戻り、その先頭には処理結果がちょこんと乗っている、そんなメモリの時間軸の流れと、処理の流れがイメージできます。

Rustで書いたコードはデータの局在性が極めて高くなりそうだし、そうなるようなコードを書くのがRustでの素直に読めるコードになるのでしょう。最近のプロセッサの処理速度は、演算回路それ自体よりもむしろメモリ幅で制約される場面も多いでしょう。

ハイエンドでも、いい言語かもしれません。データの局在性で。プログラム自体がバイナリが小さい=キャッシュに収まる、スタック的に処理が進む=以前にアクセスした領域だから高い確率でキャッシュに残っている、処理経過がスタックが伸びる感じで進む=データ局在性が極めて高くキャッシュヒットが高くなる感じのコードを書くことになるのかもしれません。もちろんRustにでもRcを使えば参照メモリが使えて、JavaやSwiftと同じようなメモリ領域の使い方ができますが、そういうコードを書く言語ではない、それだけのことなのでしょう。最近のプロセッサはL3キャッシュが2桁MBだったりしますから、そのキャッシュに丸っと処理系が入って出てこないなら、もうプロセッサがFPGAと見分けできなくなりそうですね。

STADIAのブログを読んでみる

開発者サイトに入らないと何もわからないですね

https://stadia.dev/blog/ に、いくつかブログ記事があったので読んでみました。技術的な中身というよりも、なにができるかアイディアを出してみようという感じで、実際に作る段階がどうなっているのか、どのように動くのかは、開発者情報に入らないとまるでなにもわからない感じです。

https://stadia.dev/apply/ 開発者への応募は、US在住ならば雇用者Tax ID番号の登録が必要です。メールアドレスは、会社のドメインのアドレスである必要があり、Gmailなどのアドレスでは受け付けないそうです。

フレームデータがクラウド側にあるよと

https://stadia.dev/blog/stream-connect:new-possibilities-for-multiplayer-gameplay/

Stream connectの概要です。ユーザのビデオをテキスチャとしてゲームに織り込むことができる、またユーザからのオーディオをゲームに混ぜ込むことができる、そうです。チャットやグループでプレイする場面で使えるのでしょうか。

フレームデータがクラウド側にあって、再レンダリングすることなく、あるプレイヤーから他のプレイヤーにフレームデータを渡せること。ここが活用どころになるのでしょう。

例題として:

  • コーチベースの画面分割、複数の人数のゲーム画面を1つの画面に。
  • 共同のsquadビュー、全てのチームメートの見ているのを、それぞれのプレイヤーの視点に、
    • コーディネータに、画面のレンダリングを再度しなくてもいい。
  • あるプレイヤーから別のプレイヤーに、フレームデータを、だいたいすぐにストリームする。

観客がいるゲームなら、レンダリングパイプのHUDを入れる前のゲーム画面を観客に配信して、プレイヤーはそこにライフゲージなどのHUDがレンダリングされたものを見る、というのができるとか、そういう感じです。

配信技術に関わる部分、符号化方式、ビットレート選択とかそういった話はありません。Googleに任せろ、になる部分は知ってても、手が出せないですから意味がないのでしょうか。

ステートの保存と管理

https://stadia.dev/blog/the-magic-of-state-share-explained/

ある人がしているゲームを見かけて、あるいはスクリーンショットを見て、そこに飛び込んで、さらに見ているものを遊ぶにはということだそうです。

ステート設定がAPIになっているので、そこでステート保存をして、どこでも全てがセーブポイント担っている状態で、かつ他のユーザがその状態を引き継いで新たにゲームを続けられる、まるでソースコード開発の無限フォーク状態です。

まぁ、色々できますよね…

象印のIH圧力鍋を買ってみた

買ってみた

象印のIH圧力鍋を買ってみました。台所に設置すると、こんな感じになります。

/post/pressurecooker-1/IMG_0672.jpg

購入時には、圧力と温度と加熱時間とを、電気制御できるから、適切な材料と調味料さえ入れれば、失敗なく美味しい一定の味が作れるだろうと思いましたが、まさにそのものでした。

/post/pressurecooker-1/IMG_0676.jpg

1日使ってみた感じでは、レシピ集がよくできている。材料を切り、調味料を入れて、ボタンを押せば、おばんざいや夕食のメインが本当にできる。この手軽さは素晴らしいです。

/post/pressurecooker-1/IMG_0679.jpg

蒟蒻の煮物は、45分ほど加熱して中まで味が染み込んでいて、美味しくできています。鍋でコトコト煮ると、ガス火の前にその間ついていないと不安になりますが、電気だと放っておけばいいので、手間がありません。

加圧調理は調理時間の短縮ができて根菜の煮物に便利なのですが、この調理器は無水料理も対応しているので、小松菜の煮浸し的なものが手軽に作れます。使ってみると、葉物野菜が手軽に使えるのが、よいです。

/post/pressurecooker-1/IMG_0680.jpg

魚の煮付けも作ってみました。クッキングシートを敷いて、魚と調味料を入れるだけです。クッキングシートは、鍋への焦げつき防止なのかと思いましたが、クッキングシートをつまんで持ち上げると、出来上がった煮付けを崩さずに鍋から取り出せたので、取り出しのためにあるのかもしれません。

アマゾンだと型番が2つあるけど中身は同じっぽい

アマゾンでみると、EL-MB30-VDとEL-MB30AM-VDの、2つの型番がありますが、機種自体は同じようです。レビューで書かれているように、AMはアマゾン向けの機種名なのかもしれません。

AMがついている方のが、若干お安いみたいです。型番にAMがついた方を購入したのですが、家電そのもののダンボール梱包に送付ラベルが貼り付けてあるシンプルな梱包でした。この型番のものは、故障時など、保証問い合わせ先はアマゾンになるのでしょうか?

アマゾンで商品を購入すると、よく、商品自体にも梱包があるのに、それをさらにアマゾンのダンボールに入れて送付してきますが、こういったシンプルな梱包の方が、捨てるダンボールが少なくて済みますから、いいですね。

電流容量に気をつける

IH圧力鍋を動かしているときは、電流容量を超えるかもしれないので、他の炊飯器やレンジを使うのは、微妙です。おばんざいの作りおきをする、炊飯器は、1200Wではなく600Wくらいの炊飯器を使う、あるいは1200Wくらいの炊飯器なら別のコンセントパネルに接続して2台同時使用可能にする、あるいは、おかゆモードで600W程度の消費電力で動かすようにする、くらいです。

コンセントパネル1つあたりの電流容量が15A、20A以上流すとコンセントごとについている小さなブレイカーが、多分落ちます。台所にはコンセントパネルが2つあるでしょうから、もう1つ別のコンセントから電源をとれば、2台同時動作ができるでしょう。多くの賃貸物件の契約電流容量は30Aですから、別々のコンセントを使ったとしても同時2台が上限になります。3台動かせば、3.6kWで36A流れますから、確実にメインのブレイカーが落ちます。

コンセントパネル1つで設置しているので、2台同時使用ができません。1200Wを消費する炊飯器で炊飯をしながら、メインの料理をIH圧力鍋で行う、というのができません。ただ、この炊飯器は、おかゆの場合は最大消費電力が600Wになるので、同時使用ができます。あるいは、炊飯器が最大消費電力を消費するのは最初の加熱時でしょうから、その消費電力ピークからタイミングをずらしてやれば、2台同時使用もできるでしょうが、気を使うのが面倒でしょう。

使い方は、おばんざいの作りだめ?

この機種の便利な使い方は、3台ほど並べて副食2つとメイン1つを同時に調理する使い方でしょう。賃貸だと契約電流容量の都合で、無理ですが。ですから、時間をずらした使い方となると、冷えても問題がない、あるいは一気に作りだめをして冷蔵庫で数日保存するものに使うしかないです。

ただ、メインのおかずが冷たいのは嬉しくないですから、炊飯器を別のコンセントに接続する、あるいは消費電力が600Wくらいの炊飯器を使い、炊飯器とこのIH圧力鍋の同時利用くらいはできるようにしたいです。

焼くのは必要か?

パン種の発酵とパンを焼くくらいはできますが、肉の塊をこんがり焼き目をつけるような焼きはできません。

他社製品だと、シャープのホットクックは、加圧調理はできませんが、かき混ぜ機能と焼く機能があります。使い方によるでしょうが、私の場合は、野菜炒めや焼きそばなどは、焦げ目がちょっとある方が好みです。焦げ目は電気制御では作るのは困難でしょうから、焼き機能はあっても使わなさそうです。実は使うと便利だったりするのでしょうか?

BLE本執筆開始の挨拶にかえて、駄文です

はじめに

BLE本の執筆を開始しようと思い、手始めに思うところを徒然と書いてみようかと思います。童話で、井戸に向かって、人に言えない秘密を大声で叫ぶ、王様の耳はなんとやらのお話がありますが、その井戸に叫ぶようなところです。

本というものは客観的に書かないと商品にならないのですが、そんな客観的な文章を書いていると、頭の後ろ側がヒリヒリとかゆくなって、続かないので、ここで主観しかないことを書いて、バランスを取ろうというのが目的です。

なので、読ませるための文章じゃありません。どこかの飲み屋さんでお酒を飲むか、タバコでも吸いながら愚痴として空気に霧散させるのが、よいのでしょうが、あいにくお酒もタバコも嗜みませんし、リアル世界に話す人間もいませんから、ネットにこうやって霧散させようというわけです。

ならツイッターに流せばと思われるかもですが、ツイッターは幸福で幸せな日常で彩りたいのですよ。どこか知らない人のタイムラインに、ある日突然3分ごとにツイートが連続して流れ出して、それがこれから下の内容だったらとか思ってみてくださいよ。幸せじゃないじゃないですか。

フリーランスする言い訳がなくなりまして

昨年、両親が他界しまして。

この10年ほどフリーランスをやっていた自分向けの理由が、もしも両親が病気で倒れても即座に対応できる、会社勤務だと有給を使い切ったら休職なり辞めるなりで大騒ぎだけど、元々がフリーランスならそんな事もないでしょう、という立派な理由でした。

10年前に会社を辞めたのは、5月の朝とても気持ちがいい晴天で、こりゃ会社行っている場合じゃないなと思ったからで、そのあとフリーを始めたのは、毎日会社に行くのがめんどくさいからなので、こんな立派な理由はただの言い訳なのですが、そんな理由もそもそもがなくなってしまいまして。

さて、こうなると自分の生き方は自分で決めなさいになるわけですが、身軽過ぎて、これがまた身の置き所に困るわけです。子供がいるわけでも、会社のしがらみがあるわけでもない。徹底的に気楽さを追求しているので、自分がすることは自分で探して決めるほかないわけです。で、ざっと周りを見渡してみると、いろんな生き方があるなーとは思うけど、どれも当事者になりたい気はしないわけです。

iOSアプリやBLEのファームウェア開発、あるいは組み込み系の開発で開発を個人で請け負うなんて、仕事になるのかと思われるでしょうが、実際のところ月に100~400万円くらい売り上げができるわけです。

短いお仕事なら2ヶ月くらい、長いお仕事だとそれでも1年単位くらいで、フリーランスという名前の通りに、必要な技能を提供して必要とされる成果物を収めたら、そこで完了という、そういうお仕事です。

本気で3ヶ月も働くと、指先の皮はキーボードとの摩擦とストレスでボロボロと剥がれて、皮が薄くなって血が滲むので、湿潤治療の絆創膏を皮膚がわりに貼り付けてしのぐ、そんなのを一年ずっと続けられるわけもないので、働くのは一年に1ヶ月を3回くらいが、ほどほどでしょう。

ですから一年のうち3ヶ月も働いたら、日本の地方都市での生活費用(年金や保険と税を抜いて400万円もあれば十分でしょう)くらいは満たせるので、それ以上働くのか?といえば、そこに働く気も起きないわけです。ただ、おもしろいお仕事だと、おもしろいので、つい話を聞きに行っちゃいますが。

なので、必要を超えて働く理由も、あまりないわけですよ。

プロなら自分で勉強するでしょう

組み込みをやっていてBLEがわからない、いい本がないか?とか言われたら、無言でBLE handbookを差し出すわけですよ。あれはBLEの規格を制定したグループのCSR勤務の副議長、本当のプロ中のプロが書いている本ですから。

プロとしてのお仕事は、結果保証なところがありますから、目の前のものが動いているやったーなんて趣味じゃなくて、動いている理由をマイクロ秒単位でビット単位でμA単位で、物理と規格に基づいて完全説明できて、だから動きますよといえないと、怖くて収められないわけですよ。

だから、必要な情報をちゃんと習得できないのに仕事なんか受けられるわけがないでしょう。仕事なのですから。英語が読めないとか、分厚すぎるとか、そんなの、それがどうした? できないなら手がけるな、なんですよ。

実際に私の場合で、4ヶ月くらいですか、BLE handbookとBluetoothの規格書とNordicの半導体のドキュメントとSDKを、じっと睨んで動かして理解してを繰り返してました。本当、ちゃんとプロに教われば1ヶ月くらいでいいらしいですけど、独学で時間を無駄にしているところが、馬鹿っぽくって私らしいですね。

それでも、書くのが好きなようで、BLEの解説をちょっとブログに書くと、リアルで、あれ読みやすかったよとか、分かり易かったとか言われるわけです。やっぱりそう言われると、嬉しくなっちゃうもので、ようし、もうちょっと書こうかなと言っちゃうわけです。

そして机の前に座ると、そんなお調子よく言っている気持ちも30秒で吹き飛ぶのです。だって、BLEって無線からタイミングからプロトコルからデータ表現まで含んだ、完全な無線通信で何かの機能と振る舞いを丸っと実装できる技術体系そのものですよ。今時、話題のIoTの解説本でも、イーサネットの物理層ならイーサネット単体で、IP層ならTLSも含めるかもですけどトランスポート層までで、MQTTなりOAuthなりアプリ層はアプリ層で、層ごとにとかもっと細かい細分で、もう300ページの本になっているわけですよ。

BLEで、層の内容は薄いけど、それらの層を全部含んでいるわけですよ。それを解説を書こうとするわけですよ。BLEの副チェアマンが書いても400ページ行くような、そんなものなんですよ。なんで、勉強しただけの素人な私に、そんな分野の丸っとした本が書けると思うねん? って冷静になるわけですよ。

だいたい1日に書ける文字数が1万文字、10ページとして書くだけで1ヶ月、技術本って裏付けや調査に時間がかかるから、よく知っている分野でも1つ1つ確かなことかを文献にあたって確認して行くので、どうやっても半年は丸っとかかるくらいの、情報収拾と文章表現に時間がかかります。

その数ヶ月の道のりに、一歩足を乗せては、冷静になるわけですよ。2日くらいで書けるBLEの解説が分かり易かったと褒められて嬉しくて、時間もあるから書こうとする、でもここから数ヶ月かかるわけです。しかも想定読者は、自分と同じような仕事をするプロでしょ。

本音で言えば、同業らのために解説の仕事する義理も理由もないわけですよ。ファームウェアなら3ヶ月800万円で見積もり出すから、それで開発して納品するから、本とかそれ以前に、うちに発注すればいいわけですよ。世の中、お金でち。

なので、書く理由もなくなっちゃうわけですよ。

執筆の目線を勘違いしてたんでしょうね

そんなこんなで、2012年にちょっとBLE解説本を書いてみては、これじゃないなーと出版せずにいたわけです。BLEの技術更新は恐ろしく劇的で、そんなことしているうちにBluetooth4.0は、今や5.1が出ようとしています。高速化、ロングレンジ化、アドバタイジングの高度化にペイロード拡張と、もうやりたい放題で規格が毎年何かしら更新されるわけですよ。

見てて楽しいけど、4.0からの技術更新は後方互換性を維持してやっているから、4.0の技術じゃ動かない作れるものも作れちゃうし、それをすると、どの端末だと動かない?とか把握が必要になるしで、見たくもない地獄を見える目にあうわけですよ、リアル仕事だと、いい加減にしろこの野郎です。せめて後方互換性をいっそのこと捨ててくれたらと思いますけど、それはそれで、キッツいんですよね…仕事したら負けだと思います。

でもね、ちょっと目線をずらすと、BLEの本が必要な場面かもなーというのが、この頃見えてきたと思いまして。要は、想定読者を組み込みやらiOSアプリやらの開発者としてたのが、こんな面倒くさい事を考え出すようになった、原因なんですよ。同業者なら、自分と同じように勉強しろ、効率最悪でも4ヶ月あればできるようになるから、と思っちゃうという。

でもね、BLEって、サービスで関わる人もいるし、事業立案で使う人もいるし、開発もアプリとファームとハードウェアと、担当者が別の人でチームで仕事してたりするわけですよ。そうすると、ファーム書く人が理解している、というだけじゃ、トラブルわけです。アプリとかもっと言えば事業とかと、目線があって同じような言葉で同じように話せてないと、仕様も作れないわけです。

そういう考え方をすると、あ、これ海外旅行に行く人の簡単会話集的な位置付けの本がいるんだなって思いました。BLEという言葉のあるところを旅行するためには、BLEというものの文法や単語がわかれば話し言葉が組み立てられますよね、BLEを使う分野で危ないところや安全なところを事前に知っていれば目的地まですっと移動できますよね、そういう目線で見たBLEの解説なら、同業者じゃなくてチーム向けの本として、ありでしょう。

チーム向け、BLEという外国語でBLEという外国を旅するための言語解説込み込みのガイドブック。これなら、書く意味も見いだせるわけです。なぜなら、こんな本を書いた人ならBLEの開発のお仕事を依頼したいという、名刺になりますから。私のところに仕事が来なくても、それはそれで同業向けに書いた本じゃないわけですから、自分の本で自分にきたかもしれない仕事を削り落としたのかと疑心暗鬼にならずにもすむのです。たぶんね。

価格はわふーにちなんで1.2万円

と、2012年から7年余りで、やっと書く気になったわけですが、価格だけはもう、わふーにちなんで1.2万円と決めておきましょう。Kindleでも電子でも紙でも、どんな媒体でも、1.2万円です。買いやがれコンチクショー、です。

では、また執筆状況が進めば、ここに吐き出しにくると思いますので。