Arduino(1) 用意するべきもの
とりあえず、始めるにあたって自分で買ったものを書いていきます。
１）Arduino本体
Arduino UNO R3を買いました。Arduinoは工作ごとに買うことになるのかもしれませんし、その場合は安い互換品で済むのかもしれませんが、最初の一台は純正で。
２）部品キット
秋月や千石でパーツセットが売っています。
・ブレッドボード
要するに基盤ですが、ジャンパーケーブルを抜き差しするだけで仮の回路を作れます。ハンダ付けは動作確認が済んでからになるので楽ちん。
・ジャンパーケーブル
先が針金みたいになってる導線です。ブレッドボードに刺して使います。
・LED
いわゆる発光ダイオードです。部品キットの入っているだけでも事足りますが、10戸で100円とかです。
・抵抗
電気が流れすぎないようにするための部品です。初心者の使う抵抗の種類は結構決まっているので、キットに入っているもので基本的に十分です。シマシマの色で抵抗の特性がわかります。
回路を切り替えるための部品です。初心者本でよく使われるのはSC1815とかいう型番のもののようです。小袋で買っておくとよいかも。
ある程度電気をため込み、流れる電気が少なくなったら吐き出す部品です。キットにはあまり入ってません。
ほかにも、例えばラズパイマガジンの特集で使った部品は、秋月などでまとめてキットとして買えるようになってたりします。モーターやセンサーなどが一通り手に入ったりするので、特定のラズパイマガジンの特集を徹底的にやる、というのは近道かもしれません。
ラズパイと違うのは、
・OS格納用のSDカードがいらない
・電源がシンプル（USB給電で十分）
・OSをダウンロードしてインストールとかしなくてよい
そのかわり、手元のPC環境でコンパイルし、バイナリを直接Arduinoのチップに転送する必要があります。
Windowsストア版はセキュリティの問題で後々面倒くさくなるので、ZIP版もしくはWindows Installer版をダウンロードしてインストールします。
シンプルですがなかなかよくできていて、ほかのライブラリをインポートしたいときも簡単にテストできたりします。MicrosoftのVidual Studio Codeでも開発できるようですが、最初はIDEがよいでしょう。
基本的にはInstallerでSDKをインストールすれば認識されると思います。「シリアルポート」にはデバイスマネージャで確認できるCOMポートを選んでください。
最初はほとんどこれだけで実験ができます。
ほかにあるほうがいいのは、
・はんだごて、はんだ、はんだ吸い取り機、パーツつかみ
はんだごては最近ケーブルレスのものもあります。はんだ吸い取り機は、銅のメッシュで間違えたはんだを吸い取ってくれるもので、はんだ付け初心者には必携です。
Arduinoに手を出す
ものすごく久しぶりの更新ですが、別にモノづくりを引退していたわけではなく。
本業が忙しくて、かつあまり刺激がないために、ちょっとばかり世をはかなんでおりました。
だってすでに何年もろくにメンテナンスされてないSDKで開発しても限界は見えてるし、うまく動かないのもたいていSDKのせいだったりするし、新しいプロジェクトは商売上却下されそうだし。
そんなわけで、在宅でいい加減取り返しがつかなくなりつつあるおなかを眺めながら「45歳を過ぎてもPGを続ける意味があるのか？」などと考えては、思考停止してたつき作品を繰り返し鑑賞していたりしたわけです。
そんな自分が、1年前にちょっとだけ手を出したのがラズパイ。
Linuxもそれほど抵抗あるわけじゃないし、小さなデバイスが操作できるってすごいじゃん。そんなことをあきばお～の前で夢想して（なぜ秋月や千石でないのか…）買ってみたのです。
そしていくつかの実験キットを試してみて、出てきた感想。
「OSまで面倒見るのが面倒くせえ…」
そう、プログラミング環境にLinuxが入ってくることに、我慢がならなかったのです。2台も買っておきながら。
そして時は過ぎ、仕事はまたも佳境に入っておりました。それなりに仕事も評価され、何とかこれで給料しばらくもらえるかな、くらいに思う一方で、やっぱりSDK頼みの開発の実態は変わらないわけです。世間は機械学習だのクラウドだのと言っているのに、いまだにC++/CLIでSDKをブリッジし、なんでそんなにメモリ食うんや…という処理に悩む日々。つまらん、本当につまらん。
そこで出会ったのがArduinoなわけです。
結局プログラミングするのは単純なマイコンだし、使えるパーツもラズパイとほぼ共通。なおかつ、起動にほとんど時間がかからず、省電力で、SDカードを使わない。
なにより、Arduino自体をチップに一体化したモジュールがけっこうあって、組み込みPCライクな見た目にならない。安く専用ハードが作れる。これはイイ！
そんなわけで、しばらくArduinoの初心者向けエントリを少し書いていきたいと思います。酒入ってるけど。
VPNとリモートデスクトップ
めっさ久しぶりの更新です。
しょうもない失敗をしたので、備忘録として。
VPNで外から自宅の開発マシンにリモートデスクトップで接続しようとしたら、特定の一台だけどうしても接続できない。
めちゃめちゃ悩んだあげく、その原因が判明。
その開発マシンから、他の拠点にVPN接続してたんですな。
これを解除したらサクッとつながったですよ。
近況
ここ2年くらい何も書いていなかったけど、なんかいろいろ吹っ切れたので、更新を再開します。
ここ最近の大きなトピックとしては、やっとMSDNを買ってもらえました。わーい。
TechNetが終了してしまうからなんですけど、おかげで開発用の仮想マシンが作り放題。
便利な世の中になったものです。まあ、Flexの方が動作環境考慮しなくてよかったのでもっと楽だったんですけど。
WPFは最近やってません。
というか、まともなものが作れる気がしません。Formsでカスタムコンポーネント作ったほうがはるかにましです。
ストアアプリもたぶんやらないでしょう。使う人がいません。
自分のお客さんは、デスクトップPCでキーボードショートカットを駆使しながらバリバリと作業をこなす人であって、タブレットの画面をぽちぽち押してる人ではないのです。そういう人は結局のところ、データを見ているだけなので、ソフトにお金を払ったりしません。
ただ、WinRTに限って言えば、そのうち導入するかもしれません。
なぜなら、C++/CXが、今後のAcrobatプラグイン開発に必須になる可能性があるからです。
１年ほど前にAdobeが提供したセキュリティパッチ以降、プラグイン内でCLRをロードすると、終了時にAcrobat本体がAccessViolationを発生するようになってしまいました。
世界中のプラグインベンダーが悲鳴を上げていますが、なしのつぶてです。いまさらMFCでGUIを組んだりしたくありません。
特に文字列処理は、いまからCでサロゲートペア対応などやる気にもなりません。C++/CXでほしいのは、ぶっちゃけ文字列クラスです。
LINQは使うようになりました。微妙にエラー処理に気を使う必要がありますが、コードが短くわかりやすくなるのはよいことです。
WCFも使い始めました。なかなか良いですが、XMLで直にやり取りするときは、データサイズに気を配らないとダメですね。
VS2008とVS2010の共存
現実問題として、.NETは4.0よりも3.5、あわよくば2.0だけで使いたいという要望は企業ユーザーによく見られます。
そんな場合、C++/CLIを使ったアプリケーションは、VisualStudio2010だけでは作れなかったりします。
.NET3.5以前の.NETをターゲットにしたC++/CLIプロジェクトはV90ツールセットでないと作成できないのですが、VS2010だけではV90のプロジェクトをビルドできません。VS2008もインストールしなければいけないのです。
と、ここまで読むと、VS2008のVisualC++だけ追加でインストールすればよいのか、と思うじゃないですか。
でも、実際にVCのみインストールしてビルドすると、TRK0005とかいうエラーが発生します。
これは、VS2008のcl.exeへのパスが見つからないことを指しています。
VS2008のC#も一緒にインストールすると、解決されます。PATHに追加してもコンパイルは通るようなのですが、V100のC++プロジェクトを扱うときに問題が生じる可能性もあるので、やめたほうがいいでしょう。
ちなみに、VS2005はツールセットの概念がないので、同時にインストールしてもVS2010上でのコンパイルができません。VS2008を用意しましょう。
・・・つうかさ。
Officeアプリケーションのプロセスがなかなか消えない
また新カテゴリーを増やしてしまった…。
お客様に納入したOffice IACを利用したアプリケーションで、Word2010を終了後にひたすらプロセスが残り続けるトラブルがありました。
初めはウイルス対策ソフトを疑い、次にHyper-Vを疑い、サービスを疑い、セキュリティパッチを疑い…と何日もかけて調査して、やっと原因を探し当てたのですが、この原因がなんとRTFファイルでした。
RTFファイルの処理自体に、何の問題があるわけでもありません。
問題はOfficeアプリケーションの周辺機能、ファイル履歴にあったのです。
「最近使ったファイル」で使用される、文書へのショートカットは、ユーザーアプリケーションデータ領域のMicrosoft\Office\Recentフォルダに作成されます。
WordやExcelなどに表示される「最近使ったファイル」のリストはこちらをさらにアプリケーションごとに分けて参照しているのが実態です。
で、このフォルダに格納されたショートカットは、Office文書、非Office文書、フォルダの3種類に分類されて、index.datに記録されます。
ここでいうOffice文書とは、あらかじめ登録された拡張子をもつファイルを指します。
各アプリケーションはOffice文書を閉じるタイミングで、index.datを参照して、ショートカットの整理を行います。非Office文書もOffice文書も、フォルダも、整理されるのはアプリケーションが「Office文書を」閉じるタイミングです。
ここ、重要です。
Office文書のショートカットの保存上限は20個に設定されているので、docファイルを連続で何個開いても、ショートカットは20個しかできません。
ところが、RTFファイルを連続で開くと、ショートカットが無限に作成されてしまいます。
はい、そうです。
Officeの取り扱う文書の拡張子として、RTFは登録されていない…つまり、非Office文書なのです。
先ほど、ショートカットが整理されるのはアプリケーションが「Office文書を」閉じるタイミングだと書きました。
RTFを5，6個連続で開いたところで、その後でdocを開けば、RTFファイルのショートカットも同時に整理されるのですが、逆に言えば、RTFを開き続けている限り、残り続けるわけです。
では、これが200ファイルも続くとどうなるか。
実は、ショートカットは200個までで収まるようです。トータルのショートカット数も規定されているからです。
ここでよかったと思ったアナタ、大間違いです。
実は、ショートカットは消えていますが、index.datに書かれたエントリは消えていないのです。
index.datの中身をテキストエディタで見ると、
[doc]
xxxx.doc.lnk=0
xxx2.doc.lnk=0
[xls]
xxxxx.xls.lnk=0
xxxx2.xls.lnk=0
といったように、Office文書は拡張子ごとに整理されています。
しかし、非Office文書は
[misc********]
xxxx.rtf.lnk=0
[misc********]
xxxx2.rtf.lnk=0
[misc********]
xxxx3.rtf.lnk=0
といったように、すべての文書が異なるファイルタイプとして保存されています。
これを削除しようとしないので、index.datはどんどん肥大化していきます。
index.datが肥大化するとどうなるか。
Officeアプリケーションが終了時に実行する、ショートカット整理のための解析の時間が余計にかかります。
手動でOfficeアプリケーションを閉じた際にはすぐプロセスが消えますが、IACやマクロを使って終わらせた際には、プロセスが15分以上も残っていたりします。
しかも厄介なことに、ホスト側のプログラムはプロセス終了を同期的に待機したりしません。プロセスが残っている間に違うOfficeアプリケーションのインスタンスを作成して、同じリソースにアクセスしようとしたりすると、深刻なアクセス違反を引き起こしたり、動作遅延を起こしたりします。
このような状況は、レジストリを操作することで防止することができます。
一つは、拡張子rtfをOffice文書として認識させる。
さらに、そもそも履歴ショートカットが作成されないようにする。
以下の情報を組み合わせれば、まあ何とかなります。
Office アプリケーションで最近使ったファイルのショートカットを作成させない
http://hebikuzure.wordpress.com/2009/03/22/office-%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7%E6%9C%80%E8%BF%91%E4%BD%BF%E3%81%A3%E3%81%9F%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E3%82%B7%E3%83%A7/
MSOfficeレジストリ一覧(Excel)
http://www-pc.uni-regensburg.de/systemsw/office/O2K/regkey.xls
C++から特定のフォルダにあるC#アセンブリを動的にロードする
WindowsでC++のプログラムを組んでいると、たまにGUIを組む時のC++/CLIのうっとおしさに負けて思わず、
「あーーーーーぁぁぁ、C#で組みてぇえええ！！！！」
と思うことがありますよね。
そんな時はC++/CLIからC#で作ったアセンブリを呼び出すのがいいんですが、.NETにはアセンブリの検索パスというのがあります。マニフェストファイルに書かれた場所を探して、次にバイナリと同じフォルダを探して、そしてGACを探して、それでもなかったらエラーを返してきます。
この仕組みで困ることは通常ありません。
しかしまれに、バイナリと同じフォルダにアセンブリファイルを置けない、という制約を課せられる場合があります。
代表的なのが、Adobe Acrobatのプラグインです。
プラグインを開発する際に、plug_insフォルダ以外の場所にサードパーティのファイルを置くと、Acrobat本体のほうで何が起こるかわかりません。したがって、Assembly.LoadFrom()の引数にファイルパスを指定して明示的に読み込むか、もしくはGACとして署名してGACフォルダに配置することになります。
GACは署名が必要になるだけでなく、デバッグの際に、いちいちGACをインストールしなければなりませんし、バージョンも厳密にそろえなければならなくなります。インストーラーも用意しなければいけません。GACに対応したインストーラーはInstallShield以外はほとんど見当たりませんから、お金もかかります。
静的に読み込む方法にはこのような苦労はありませんが、そのかわり、DLLをいちいち明示的に指定しなければならなくなります。フォルダ内のDLLを片っ端から読み込む方法もありますが、ソリューション内の依存関係もおちおちいじれなくなります。
そこで、AppDomain.AssemblyResolveイベントのイベントハンドラを定義してやります。
実は、.NETは新しいアセンブリのロードが要求されるとイベントを発生します。
このイベントのイベントハンドラで、Assembly.LoadFrom()を使って読み込んだAssemblyを返してやるだけで、アセンブリをロードすることができます。
イベントハンドラの引数であるResolveEventArgsのNameプロパティには、要求されたアセンブリの厳密名が渡されています。ここからテキトーにアセンブリの名称を拾って、”.dll”をくっつけてやって、ファイルを配置するフォルダパスにくっつけてやれば、LoadFrom()が実行できるわけです。
この方法なら、普通にプロジェクト参照ですべてビルドできるので、開発効率がアップします。ビルドイベントを適切に設定してやれば、ビルド後にすぐデバッグも可能です。
ところで、言語リソースファイルはどこに置いたらいいのでしょうか？
これは、読み込んだDLLのフォルダから言語名のサブフォルダを自動的に検索してくれます。
.NETって、かなり柔軟にできていますよね。
調べてみると、DLLを入れ替えた瞬間に動作が変わる、といったことも比較的簡単にできるようです。知っておくと、設計の自由度が広がります。
