足で操作する補助アーム

 トピック
 公開日:2017年5月29日

 ハンダ付けとかしてると、
(自分はめったにやったことないですが)
もう一本腕があればやりやすいのにと思ったことがあります。

 そんな夢を叶えてくれそうなデバイスがこちら
足を使って補助アームを操作するという装置です。

 ノートPCを両手でタイピングしている時にスマホで電話したいとか、
両手に荷物を抱えてる状態でドアを開けたいとか、
左手でワイヤを右手で基盤を押さえながらハンダ付けしたいとか、
そんなことに使えそうです(^_^;)

 動画を観ると分かるのですが、
足を使って補助腕を操作するので、
慣れないと足がつりそうな気がします(^_^;)

Mithril.js v1.x

 プログラム
 公開日:2017年3月20日

 Webアプリを作る際に、
フレームワークとか呼ばれるライブラリを使うと
それなりに便利です。
MVC(Model-View-Controller)を採用していることが多いかと思われます。

 JavaScriptなフレームワークの1つに
Mithril.jsというのがあります。
仮想DOMを導入しているフレームワークです。
そんなにメジャーではないようですが、
個人的には割と良さげな印象を持ってます。

 そんなMithrilですが、
2017年2月くらい(?)にバージョンが 1.x になったようです。
ただし、APIが改新されて 0.2.x との後方互換性が無くなっています。
やれやれ、APIを学習し直さないといけないのか・・・
とか思いましたが、
こちらのKey conceptsとか読んだら、考えが変わりました。

 ざっくり、どう変わったかと言えば、
アンチパターン回避の精神を推し進め、
MVCのうちのViewに重点を置き、
仮想DOMをより洗練させた。
といった感じでしょうか。

 フレームワークを使う場合、
設計者の意図するやり方に従う必要があります。
学習する手間はありますが、
慣れてくれば道に沿って進んで行けばよくなります。
一方、それは規約になり、好きなようにはやれなくなります。
機能が増えれば複雑性も増すかもしれません。

 Mithril v1.x はその辺を嫌っているようです。
より簡素に、また機能を集約し、
アンチパターン回避を促すべく、
ModelとControllerに縛りを設けないで、
柔軟にうまくやれるよ。
ということを目指しているようです。

 さて、
v0.2.xに比べてv1.xはどう変わったのかについて、
こちらのChange-Logを参照しつつ、
大きく変わったと思われる部分を中心に
詳しく見てみたいと思います。

m.prop()の削除。
 ModelとViewの間で双方向にバインディングするための機能ですが、
MVCの縛りは止めたので削除となったようです。
とは言え、それなりに便利な場合もあります。
その辺を考慮してか、
mithril/streamという代替ライブラリがオプションで用意されています。
ただ、それなりに高機能になってる感じなので、
単純にsetter/getterな機能だけがほしい場合は、
v0.2.xからコードを借りてきた方が早いかも。
↓こんな感じに。
m.component()の削除。
 従来は View + Controller でコンポーネントでしたが、
縛りを無くしたのでViewだけで構成できるようになりました。
仮想DOMを記述するための m() に統合されたので、
削除となったようです。
コンポーネント中にコンポーネントを記述できるようになったので、
柔軟性が増したかも。
config機能を改善してライフサイクルなイベントを導入。
  configは例えばcanvasの描画更新とかで使えたりしましたが、
より詳細に柔軟に対応できるように Lifecycle methods が導入されました。
従来Contorllerでやってた初期化は oninit()でやれるようになったり、
例えば oncreate()でcanvasのコンテキストを取得しておいて、
onupdate()で描画を更新とか細かくやれるようになりました。
仮想DOMだけでなくコンポーネントに対しても設定可能です。
再描画の挙動を変更。
 Mithrilでは再描画は自動で行われるので、
あまり気にする必要は無いのですが、
明示的に再描画を抑制したい場合があります。
従来は関数で制御していましたが、
結局イベントの延長で対処することになるので、
イベントのパラメータとして設定できるようになりました。
確かにこの方がスマートかも。

m.redraw()による再描画の挙動が、
即時に同期的に行う方式から、
予約して次の requestAnimationFrameのタイミングで
非同期に行うように変わりました。
むやみに m.redrawしたとしても無駄な描画は起きなくなりますね。
また従来は、
m.startComputation/ m.endComputationを使うことで
非同期処理が完了するまで描画を遅延させることができましたが、
アンチパターンの恐れを考慮して削除されました。
非同期処理後の再描画は m.redraw()を活用することになりそうです。
view()の引数やコンポーネントに対する引数の変更。
 viewの引数がcontrollerからvnodeに変わりました。
外部から渡すことになるコンポーネントに対する引数が、
オプション扱いから vnode.attrsとなりました。
さらに vnode.stateを使うことで、
コンポーネント内部の状態を管理できるようになりました。
外部からのが attrsで内部のが stateになるので分かりやすいですね。
m.deferredとm.syncを削除。
 いずれも非同期処理を扱うために用意されたものですが、
既に多くのブラウザでPromise対応が進んでいるので、
そっちに合わせます。ということで削除になった模様です。
非対応なブラウザであってもpolyfillで代替されるので問題ないです。
各ブラウザでのES6対応はどのくらい進んでいるんだろ、
と思ってここを参照してみたら、
IE11を無視すれば概ね対応が済んでるっぽい感じですね。

 その他にもいろいろありますが、
長文になったのでこの辺にしておきます(^_^;)
だいたい押さえたいところは書いたつもりです。

 ちなみに、
Mithril.jsを使って作ったのがこれ

ChromeのPDF表示でのフォントがおかしい件

 つぶやき
 公開日:2017年3月18日 / 更新日:2017年10月12日

 拙作の
PDFなカレンダーを生成」において、
フォントが妙なことになっていることに気づきました。
なんか毛筆系なフォントが選択されてしまって、
激しく違和感を覚えることになってます(^_^;)
どうもChromeだとおかしくなる感じ。
以前は問題なかったのに・・・。

 調べてみたところ、
こちらの記事を見つけました。
フォントが埋め込まれていないPDFを表示する際の、
代替フォントの選択がうまく行っていない模様です。

 PC内にある日本語フォントのうち、
アルファベット順で最初に見つかったファイル名で
フォントを選択しているっぽい雰囲気。
おいおい・・・テキトーすぎるだろ(^_^;)

 拙作の「PDFなカレンダーを生成」では、
フォントは埋め込んではいないものの、
使用するフォント名は指定しています。
以前のChromeではそれを参照しているような感じで、
それなりに期待したような感じに表示してくれた気がします。
PDFファイルをダウンロードして、
Acrobat Reader とかで見ればまともな表示になってるはずなので、
そのまま印刷すれば期待したような結果になると思います。

 いずれにしろ、 
ChromeのPDF表示が改善されることを待つしかないようです(^_^;)

★2017-10-12追記。
うまい手を思いついたので試しにやってみたら改善したので書いてみます。
というか、ナゼ今まで気がつかなかったのか・・・(^_^;)
こちらのページにあるように、このプラグインを導入すれば改善するわけですが、プラグインは必要最小限にしたいとか、ブラウザの使用メモリが増えるとか、ちょっとだけ気になることもあったりします。
要するに、アルファベット順というか英数字なソート順で最初に見つかったファイル名の日本語フォントを選択しているっぽいので、例えば”0″で始まるようなファイル名にすれば良いのではないかと。
ということで、コントロールパネルのフォントから試しに「メイリオ」をコピペしてファイル化し、ファイル名を変えた後に再インストールしてみました。結果は・・・ダメでした。そう単純ではないようです(^_^;)
では、まだ導入していない日本語フォントでやってみたらどうだろうかと、フリーフォントを探してみたら、うってつけなのを見つけました。それはこちらの「フロップデザイン」というフォント。実に都合の良いことにファイル名が “01FLOPDESIGN.otf” となっています。で、さっそく導入してみたらうまくいきました。導入したフォントが選ばれるようになりました。結果、自分の推測が正しかったことが証明されました(^_^;)

けものフレンズ

 トピック
 公開日:2017年3月15日 / 更新日:2017年3月16日

けものフレンズ」なるアニメが流行っているらしい。
影響で動物園を訪れる人が増えているらしい。
「すごーい!」「たーのしー」
がキーワードらしい。

 メディアミックス展開ということなのだが、
先行したスマホのゲームは既にサービス終了している
というのが興味ぶかい。

 擬人化した動物たちによる萌えな感じの一方で、
荒廃して廃墟となったテーマパークという設定が
多くの人の興味を呼んでいるようです。

 ざっくり言えば
↓こんな感じらしい(^_^;)


by けものフレンズ ロゴジェネレータ

アニメGIF⇒パラパラ漫画(JS版)

 プログラム
 公開日:2017年3月13日

アニメGIFからパラパラ漫画の冊子を作る
という記事に触発されて、
JavaScript版を作ったらどうだろうかと思い立ち、
まずはGIFをparseするライブラリを探してみるも、
個人的にしっくり来るのが見つからなかったので
改造して新たにライブラリを作ったりしました。

 次に必要なのはPDFを生成するライブラリ。
いくつかあるようなのですが、
クライアント側だけでうまくやれそうなのは
jsPDF一択という感じ。

 ただ、
こちらのドキュメントを見ると、
画像を扱うAPIが見当たらない・・・うむむ。
一方、こちらのLiveDemoでは画像を扱ってる・・・???。

 調べてみた所、
ドキュメントにはjsPDFのコアな部分についてのみ書いてあるようです。
画像を扱うための addImage なるAPIは
プラグインという形で提供されているようです。
こちらのGitHubにある、
"dist/jspdf.debug.js" および "dist/jspdf.min.js"
がプラグインを同梱しています。
前者は debug とかなってますが、minimizeされてないだけです。
debug時はこちらを使ってね、くらいな意味合いだと思います。

 さて、
jsPDF.addIamge()には dataURL な画像イメージを渡します。
読み込んだGIFファイルはcanvasに展開することになるので、
canvas.toDataURL()すればbase64なPNGを簡単に得ることが出来ます。
これでどうにかなりそう。
とか思ったんですが・・・実は苦労しました(^_^;)
コマ数が数十枚程度のアニメGIFを処理したら
ブラウザがメモリ不足エラーを起こしました・・・。
PNGをデコードしてPDFで扱えるようにしてるようなのですが、
イメージのサイズの総量が大きすぎるようです・・・。
addImageには圧縮のオプションがあるので、
指定してやってみたらエラーは起きなくなりましたが、
今度は時間が掛かることになってしまいました。

 jsPDFでPNGを扱うのはメモリ的&速度的に
ちょっと厳しいのかもしれません。
さてどうしたものか、と思いながら
addImageのソースを眺めていたら、
分かったことが2つありました。
ひとつはPNGだけでなくJPGも扱えること。
もうひとつは、
PNGはデコードした上で処理する必要があるが、
(圧縮指定があればさらにエンコードが必要)
JPGはほぼそのままで扱えるようになっていたこと。
PDFはJPGのイメージをそのまま扱えるっぽいようです。

 そんなわけで、
canvas.toDataURL('image/jpeg', 0.8)とかやって
addImageに渡すようにしました。
速度的にだいぶ改善された感じがします。
PNGのlosslessに対してJPGはlossyになってしまうので、
画質を設定できるようにしました。
またメモリ不足エラーが起きてしまった場合に備えて、
PDFを複数ページに分割して処理できるような工夫もしてみました。

 ちなみに、
jsなフレームワークの一つである Mithril.js
いつのまにかバージョン v1.0.xとかになってて、
APIとか一新されてました。
よい機会なので今回使ってみた次第です。
v0.2.xは使ったことあるのですが、
v1.0.xはいろいろ変わってたりしてました。
どう変わったかについては別途書いてみるつもりです。

 ということで、
アニメGIF⇒パラパラ漫画(JavaScript版)は
こちらから試せます。

ところで、
自分は印刷して切り出して冊子を作ったりしてなかったりします(^_^;)
あしからず。
実際にやってみた方の感想とかいただけるとうれしいかも。