tmytのらくがき

個人の日記レベルです

Sakura.IOをWindows 10 IoTで使うライブラリを供養した

Sakura.IOをWindows 10 IoT上で使うライブラリをBuriKaigiで話そうかと思って作ったんだけど結局使わなかった。 せっかくなのでGitHubに公開しておきました。

github.com

もう少し便利なハイレベルAPI整備したほうが使いやすいと思うんですが、とりあえずほぼArduino版のPortです。 C#/UWPなのでawaitableな関数で実装しないといけないことがあったので、せっかくなので接続完了を待つメソッドも用意しておきました。

こんな感じで使えます。

var sakuraio = new SakuraIO_I2C();
await sakuraio.OpenAsync("I2C1");
await sakuraio.WaitForConnectionAsync();
var bytes = Encoding.UTF8.GetBytes("HELOWRLD");
sakuraio.EnqueueTx(0, BitConverter.ToUInt64(bytes, 0));
sakuraio.Send();

Sakura.IO + Raspberry Pi + Windows 10 IoT Core っていうパイの小さそうな組み合わせですが使えそうならぜひどうぞ。

Lenovo C630を買いました

Microsoft MVP Global Summtでシアトルにきているので、家電量販店をのぞいたらC630が売っていたので買いました。

とりあえずこの記事もC630で書いていますが、まーまー良くも悪くもただのWindowsです。 初回起動時のパフォーマンスも使っている分にはそんなに悪いと感じない程度には普通のWindowsです。

ちなみに量販店モデルは

  • Snapdragon 850
  • RAM 8GB
  • SSD 128GB
  • Officeなし(アメリカだからね)

という構成でした。

C630はLTEモデム内蔵なので、SIMを入れれば単体で通信できます。量販店でこいつはSIM Lockedか?って確認したら、そうだと思うよ。と言われながらも、 VerizonのLTEモデルだったらSIMロックかかってないはずだしな…と思い、試しにIIJmioDocomoと、T-Mobile (アメリカの現地SIM)を入れてみたところ、ちゃんと認識しました。

最近のWindowsは、ARMで実行できるだけでなく、ARM上でWSLがちゃんと実行できるところがとても偉いと思います。 WSLとDebianをインストールして、 uname -a とすると、ちゃんと aarch64 って出ます。

以前にx64版のWSLで32bit ELFを実行できたように、同じようにQEMUを入れて設定すると*1たぶんx86 ELFも動くのでしょう。たぶん。

ほかにも。ARM版のWindowsx86バイナリを実行時にARM命令にトランスレートする機能があるので、x86のPEが実行できます。 タスクマネージャで詳細タブのプラットフォームカラムを追加したときに32bitってでるやつはたぶんx86

f:id:tmyt:20190322015637p:plain

ここに見えているChromeとOneDriveはPEヘッダを確認したところ、どちらもx86版でした。 にこれがOneDrive.exeのヘッダ部分。選択箇所が 4c 01なのでx86バイナリです。

f:id:tmyt:20190322015848p:plain

ちなみにこっちが、Windows付属のnotepad.exeのヘッダ部分。64 aaと書いてるのでARM64バイナリです。

f:id:tmyt:20190322020113p:plain

トランスレーションで実行されててもそんなに遅いと思わないので、よくもまぁあの複雑なバイナリを…という感じです。 詳しいことはこの辺*2に書いてあるそうです。

しばらくあそべそう…

BuriKaigi2019に行ってきました

早くも1か月前の話になりますが… BuriKaigi2019に行ってきました。

toyama-eng.connpass.com

ありがたいことに、なにか話していいよという時間を頂いたので、App CenterとかVSTSでCIする話をしてきました。

基本的には以前にエントリしたこれ (https://blog.tmyt.jp/entry/2018/11/26/011621) と同じですが、 せっかく.NETトラックなのでXamarin.Formsでコードを用意していった…のですが、デバイスの画面をPCに出力するアプリと APKインストーラの相性が悪いのか、いまいちちゃんと動かなかったのが残念です。

www.slideshare.net

当日は25分しかなく、.NETのドの字すらほとんどない感じで、さらにコードをほとんどお見せする余裕すらなかったので ここで供養しておきます。

NuGetパッケージの追加

App Centerの各機能を使うライブラリはさすがMicrosoftがやってるサービスなだけあって、NuGetからインストールするだけで使えます。

.NET Standardで共有される部分のライブラリプロジェクトに対してNuGetパッケージの追加

f:id:tmyt:20190224220716p:plain

AppCenterと検索するとそれらしいライブラリが出てくるのでほしいものをインストールします。 ちなみに、認証済みマークがついてないで判別できますが、2個目の "AppCenter.Analytics.Metrics" はサードパーティライブラリです。

f:id:tmyt:20190224220847p:plain

今回はCrashes, Analytics, Distributeをインストールしておきました。

コードの呼び出し

App Centerと連携するためのコードを少しだけ書きます。具体的にはApp.xaml.csのOnStart()の中に次のコードをコピペします。

AppCenter.Start("ios={Your App Secret};android={Your App Secret};uwp={Your App Secret}",
    typeof(Analytics), typeof(Crashes), typeof(Distribute));

{Your App Secret} と書かれた部分にApp Centerへ接続するGUIDっぽい文字列を指定します。これは、App Centerのプロジェクトページを開くと、ここに書いてあるやつです。

f:id:tmyt:20190224221605p:plain

iOSAndroid、UWPとそれぞれ指定できるので、プラットフォームごとにApp Centerのプロジェクトを作ってそれぞれの値を埋めます。

これでだいたいApp Centerと連携できるようになりました。

まとめ

という、これらはDocs.com のこのあたり (https://docs.microsoft.com/en-us/appcenter/sdk/getting-started/xamarin) に書いてあります。 また、App CenterでXamarinプロジェクトを作ると、OverviewのXamarin Formsタブに同じことが書いてあります。ここをコピペすればOKですね。

f:id:tmyt:20190224221840p:plain

sakura.io通信モジュールを手に入れたのでNetduino 3 Wifiに接続した

sakura.ioというサービス?があって、それの通信モジュールを手に入れたわけです。

sakura.io

sakura.ioはさくらインターネットのIoTプラットフォームで、SoftBankとL2接続した閉域網を通じて、さくらインターネットに設置されたデータセンターと通信できるサービス。っていう感じみたいです。

モジュールの通信先は閉域網でつながっているのでサービスが提供するデータセンター固定。SIMの差し替えとかも不可。なんですが、データセンターから先にWebSocketとかMQTTとかで任意のWebシステムと連携できるので実質インターネットにつながっているようなもんですね。

とりあえず、ドキュメントに沿ってスケッチを書いてデータが送信できることまで確認しました

送信するデータがなにもないと寂しいのでLM35DZをつないで、室温を投げ続ける装置と化したsakura.io通信モジュールとArduino UNO R3の図。

せっかくなので.NETで使おう!

NetduinoというArduinoコンパチ風な.NET MicroFrameworkが動くマイコンボードが昔々ありました。.NET CoreだのWindows 10 IoTだの言われる前の時代のもので、スイッチサイエンスによると、掲載日が2015年だそうです*1

このボード、国内で使えるWiFiモジュールがついていて、SDカードリーダが付いていて、C#でプログラムが書けて、Visual Studioブレークポイントまで設定できて、Arduinoとピン配列互換という素晴らしいやつなんですが、まぁ流行った気は全くしないです。

ちなみにSDにログ書くなんてのはC#なのでこう書けば普通にできるようなやつでした。

using (var writer = new StreamWriter("\\SD\\log.txt", true))
{
    writer.WriteLine("Event happen!");
}

NetduinoはArduino UNOと違って、IOが3.3vの5vトレラントです。が、sakura.ioのArduinoシールドボードはIO電圧を5v/3.3vから選択できるとても優秀な設計なため、3.3vにしてあげればそのまま使えるはず…なのでArduino向けのライブラリをC#に移植しました。

github.com

もともとがとてもよくできたライブラリだったので、ほとんどそのまま移植してあります。名前とか定数をC#っぽくしたくらい。

その結果、アナログA0からデータを読んで、sakura.ioに送信するのはこう書けるようになりました。

public static void Main()
{
    var sakuraio = new SakuraIO.SakuraIO_I2C();

    for (;;)
    {
        if ((sakuraio.GetConnectionStatus() & 0x80) == 0x80) break;
        Debug.Print(".");
        Thread.Sleep(1000);
    }

    var input = new AnalogInput(Cpu.AnalogChannel.ANALOG_0);

    while (true)
    {
        Debug.Print((330 * input.Read()).ToString());
        sakuraio.EnqueueTx(0, 330 * input.Read());
        sakuraio.Send();
        Thread.Sleep(1000 * 30);
    }
}

Netduino 3 WiFiに載せるとこんな感じ。白色LEDがクソまぶしい。

Netduino 3 WiFi向けの話

2018年の暮れにもなって、.NET MicroFrameworkをNetduinoで使う人が何人いるかはわかりませんが、書き残しておきます。

Netduino 3 WifiはUSB 5vをVINへ流していないのでACアダプタが無いとsakrua.io通信モジュールに電源が供給されません。 ちゃんと電源を接続しましょう。

電源は7v~12vまで大丈夫なので、僕はマルツでArduino用に今回のために手に入れた9v/2.5A電源をそのまま流用しました。

Azure DevOpsとAppCenterでCI/CDといわれるやつをやった

Azure DevOpsとAppCenterを使ってCIできるようにした

やったこと

  • Azure DevOps(旧VSTS)でソース管理とビルドパイプラインの面倒を見る。AppCenterでテスターにバイナリを配布する。
  • AndroidiOS両方やる
  • ビルドマシンは自宅にmacOSな物理マシンを設置する

セットアップ

セットアップ自体は簡単。どれもすぐできるので省略します。

  • Android Studioをセットアップする
  • XCodeをセットアップする
  • Azure DevOpsのビルドエージェントをセットアップする

困ったこと

  • iOSのビルドがうまくいかなくて泣いた

iOSはProvisioning Profileとp12を設定しているのに署名がうまくいかなくて泣いた。 結局、VSTSのビルドタスクの実装を読んで、ビルド前にMagicを施すことでなぜかビルドできるようになった。

逆にAndroidはデフォルトでなにも困っていないので特に触れません。

泣いた結果のビルドパイプライン

Pipelineのところ。Schemeをちゃんと書く。

f:id:tmyt:20181126004828p:plain

なんかよくわからない文字列をpbxprojに書き込む

echo "/* tweaks
ProvisioningStyle = Manual;
*/"  >> ”プロジェクト名”.xcodeproj/project.pbxproj

DerivedDataのせいでビルドにこけることがあるので毎回消す

echo Cleaning DerivedData...
rm -rf /Users/<ユーザー名>/Library/Developer/Xcode/DerivedData/<プロジェクト名>-*

XCode Buildはこれでいいらしい。最初Manual署名とかいろいろやってみたけど、結局署名がうまくいかなかったりでよくわからない。 最初の謎の文字列をpbxprojに書き込むとビルドタスクがいい感じに動く。もうさっぱりわからない。

f:id:tmyt:20181126005134p:plain

ついでにGitのChangeLogをBuild artifactに入れておく。

echo "$(Build.SourceVersionMessage)" > $(build.artifactstagingdirectory)/CHANGELOG

結局ビルドタスクの実装に依存した謎の文字列を無理やり押し込んで解決したけど、こんなことしなくても通るはず…謎。もう無理。

リリースする

デフォルトでビルド後にAppCenterに投げるようなタスクが書かれてる。けどせっかく(?)なので、Releaseを使った。

トリガーに、CIビルドを設定。タスクにはAppCenterにDeployするタスクを設定しただけとても簡単。

Release notes fileに、ビルド時に生成したCHANGELOGを指定した。

f:id:tmyt:20181126010304p:plain

Gitのログを出力したのはここで使うためでした。

AppCenterのIn-app Updateを使う準備をする

In-app Updateを使うにはちゃんとバージョン番号が上がっていないとだめ。

  • iOSの場合CFBundleVersionが現在のバイナリより新しい場合
  • Androidの場合versionCodeが現在のバイナリより新しい場合

それぞれの場合に、アップデート通知が出る。なのでいい感じにバージョンを更新しないといけない。

調べるとVSTSのビルドタスクでできるよーとか書いてあったりいろいろ試したけどめんどくさくなった*1。 ので、macなんだろsedでいいだろsedで。という感じで解決しました。

Android

Androidはbuild.gradleのversionCode 1ってなってるところをsedで$(Build.BuildId)に置換するだけ。簡単

sed -i -e "s/versionCode 1/versionCode $(Build.BuildId)/" app/build.gradle

iOS

iOSはもっと簡単でmacなのでplistを編集するCLIツールがあるのでそれを使う。CFBundleVersionを文字列で$(Build.BuildId)に書き換える。こちらも簡単

plutil -replace 'CFBundleVersion' -string "$(Build.BuildId)" <プロジェクト名>/Info.plist

アプリにIn-app Updatesをセットアップする

実際にIn-app Updatesを有効にするには、アプリ側にライブラリをインストールして少しだけコードを書き足す必要があります。 ただこれも、使い方はdocs.comを読むと書いてます。

docs.microsoft.com

docs.com読めって言えばそれだけの話なんですが、とりあえず簡単に紹介だけしておきます。といってもdocs.comに書いてることと変わりません。

Android

Androidは簡単。Gradleに依存を書く。

dependencies {
   def appCenterSdkVersion = '1.10.0'
   implementation "com.microsoft.appcenter:appcenter-distribute:${appCenterSdkVersion}"
}

importを書いて、MainActivityのonCreateあたりに次のコードを埋める。

AppCenter.start(getApplication(), "{Your App Secret}", Distribute.class);

おわり。簡単。

iOS

iOSもだいたい同じ。

Cocoapodsからライブラリを入れる。

pod 'AppCenter/Distribute'

importを書いて、didFinishLaunchingWithOptionsあたりに次のコードを埋める。

MSAppCenter.start("{Your App Secret}", withServices: [MSDistribute.self])

ただ、iOSはInfo.plistをちゃんと書かないと動かない。 ドキュメントにもちゃんと書けよ。って書いてあるけど見落とすと動かなくて悩むのでちゃんと書きましょう*2

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>appcenter-${APP_SECRET}</string>
        </array>
    </dict>
</array>

おわり

*1:PowerShellタスクだからmacなので動かないとかあって嫌になった

*2:1時間くらい悩んだ

オカムラのSylphyを買いました

ちょっと前に会社を辞めてフリーランスって感じでお仕事をしていたのですが、最近ラップトップじゃなく椅子で作業することが増えてきました。 で、ずっとコーナンの1000円ぐらいのパイプ椅子を使ってたけど、いい加減つらくなったので新しい椅子を買いました。

オカムラのSylphyというやつです。

www.okamura.co.jp

Sylphyの中でも買ったのは、エクストラハイバック、背メッシュ、稼働肘、黒、アルミ足という設定のものです。ようするに、背もたれがメッシュで、高くて、ヘッドレストがついてるやつ。色は赤。赤かっこいい。ちなみに品番はC68ABR-FMP9 です。

椅子探しの旅

椅子ほしい!って言ったら、みんなにバロンがいいよ、アーロンにしなよ、とか言われたのでとりあえず大阪南港のIDC大塚家具へ。

今回椅子を選んだポイントは

  • ヘッドレストがある
  • 座面はクッションがいい
  • 背もたれはメッシュがいい

です。

いろいろ椅子が置いてあるゾーンがあるので座った結果オカムラのSylphyの背もたれがめっちゃ好きだったのでその日はそれだけ覚えて家に帰りました。

後日、グランフロント大阪 21Fのオカムラショールームへ。 ここ、さすがショールームというだけあって、オカムラの椅子とか机とかそういうのが山ほど展示してあるんです。その中で今回はSylphyを探しに来てたのでした。

ショールームでエクストラハイバック、背メッシュを試してみて、背もたれのフィット感がたまらないな、ということを再確認して、その日は帰りました*1

なんでSylphy買ったの

Sylphyを選んだ理由は

  • ヘッドレストがある
  • 背メッシュ/座クッションが選べる
  • すいつくようなフィット感の背もたれが最高
  • 前傾リクライニングができる

です。

特に背中のフィット感が最高だったのが一番の決め手でした。

このSylphyはレバーで背もたれのカーブが変更できます。

f:id:tmyt:20181116103533p:plain

僕はこれを狭いカーブにして使っています。ちょうど背中のふちが椅子のカーブの端っこかなー、ちょっと椅子のほうが広いかなーみたいな感じにフィットするのがめちゃくちゃ好みでした。

まさにこれ。これが好みだと、バロンとかアーロンじゃなくてこっちが好き!!ってなるので近くにショールームあるならぜひ一度試してほしい。

あと、そんなに高くない*2のもうれしいですね。

買った場所

Kagg.jpで買いました。会員になると意味が分からないくらい安くなります。本当に意味が分からない。

www.kagg.jp

発注から1~3週間で出荷。と書いてましたが、実際には配達まで1週間でした。

  • 2018/11/08 15:55:注文
  • 2018/11/08 17:20:納期確認中メール
  • 2018/11/12 11:50:納品日連絡
  • 2018/11/16 10:00:納品

こんな感じでした。配達は、メーカーから直接配達されてきます。玄関先で梱包の段ボールから椅子を取り出して、玄関先納品でした。クソでかい段ボール*3はおじさんがそのまま持って帰ってゆきました。

まとめ

  • Sylphyめっちゃいいからおすすめ
  • Kagg.jpの値段設定が意味不明

*1:ショールームは販売やってない

*2:十分高い。税込み10万切ってるのは神。

*3:たぶん70x70x120くらいあった

Twitterの一部API廃止に伴う影響について

Twitterでは一部お伝えしましたが、2018年8月16日にTwitter社が以下に挙げる一部APIが廃止します。

  • UserStream
  • 旧DM

このAPI廃止に伴い以下のそれぞれの機能が利用できなくなります。

  • Azurea
    • UserStream
    • DM*1
    • イベント通知
  • Aristea
    • UserStream
    • 通知カラム
    • イベント通知
    • Push通知

UserStreamが廃止されることにより、リアルタイムにタイムラインが流れることはなくなります。 Twitter社はこのAPIの後継としてAccount Activity API(AAAPI)を提供することになっていますが、このAPIはUserStreamの完全な置き換えになるとはいえません。

  • タイムラインが流れてこない
  • 受信にサーバーが必要
  • 1アカウント当たり約2500円/月の費用が発生する

これらより、Aristeaその他ではAAAPIをサポートすることはしません。いままでありがとうございました。

なお、RESTでのタイムライン読み書きは継続して利用可能ですが、2018年9月に予定されているTwitter社のAPIアップデートでアプリ利用者全体で3時間当たり300回しか書き込めなくなるため、サードパーティーの時代は幕を閉じるものとなりそうです。

*1:後日新DM API対応へのアップデートを配信するかも