pkgでNode.jsスクリプトを実行バイナリにする

Rubyスクリプトをcross-platformなstandaloneバイナリにしようとして諦めた - あーありがち(2019-10-03)

で Ruby を諦めたので、次は Node.js.

zeit/pkgですごく簡単にできる

zeit/pkg: Package your Node.js project into an executable

試したのは 4.4.0

基本的な使い方は

pkg [-t target] [-o output] <source>

で、必要な stub を自動でダウンロードして依存モジュールも含めて -o で指定した名前の実行バイナリを生成してくれる。

ネットワークが弱い場合はこのダウンロードでイライラするけど、そこが済めば1実にあっけなく終わる。本当にあっという間。

ただし、通常ではできあがったバイナリはすごくでかい。どれだけ簡単なコードでも 30MB 以上になってしまう。もしかしたら V8 の option でサイズの削減はできるかもしれないけど、そこはまだ試していない。

でもcross-compileはできない

README には cross-compile できると書かれているんだけど、これは間違いだった。macOS 上で Windows ターゲットのコンパイルを試してみて、確かにコンパイル自体は動作はするんだけど、実際にできあがったバイナリを実行することはできなかった。Windows 上で Windows ターゲットのバイナリを作ったら普通に実行できたので、CI のプラットフォームを Windows にして pkg を実行する形でないとダメっぽい。

続きは GitHub Actionsでpkgを使ったNode.js実行バイナリをWindowsを含めてmatrixビルドする - あーありがち(2019-10-05)

localのファイルのrequireはそのままでは相対パスを解決できない

バイナリはできるけど実行すると以下のように怒られる。

Error: Cannot find module 'xxx
Require stack:
- /snapshot/src/index.js
1) If you want to compile the package/file into executable, please pay attention to compilation warnings and specify a literal in 'require' call. 2) If you don't want to compile the package/file into executable and want to 'require' it from filesystem (likely plugin), specify an absolute path in 'require' call using process.cwd() or process.execPath.
   at Function.Module._resolveFilename (internal/modules/cjs/loader.js:608:15)
   at Function.Module._resolveFilename (pkg/prelude/bootstrap.js:1287:46)
   at Function.Module._load (internal/modules/cjs/loader.js:524:27)
   at Module.require (internal/modules/cjs/loader.js:664:19)
   at Module.require (pkg/prelude/bootstrap.js:1166:31)
   at require (internal/modules/cjs/helpers.js:16:16)
   at Object.<anonymous> (/snapshot/src/index.js:0:0)
   at Module._compile (pkg/prelude/bootstrap.js:1261:22)
   at Object.Module._extensions..js (internal/modules/cjs/loader.js:768:10)
   at Module.load (internal/modules/cjs/loader.js:626:32)

解決策としては process.cwd() とか process.execPath ではなく、

https://github.com/zeit/pkg#config

を参考に、package.json に

"pkg": {
  "scripts": "src/**/*.js"
}

みたいなやつを足しておく必要あり。

  1. 環境変数を指定しておくとダウンロードした stub をキャッシュしてくれる 

ふと思い立ってPHPのmicro frameworkをちらっと見てみた(結論ナシ)

最近 Sinatra をベースに、みたいなのが増えてるっぽいのでこういうのは PHP ではどんな感じなんじゃろなぁというのが気になって調べてみた。

有名なのは

辺りなのかな?

で、ざっとコードを見てみたけど、

  • Glue, phatso はさすがにシンプルすぎ
  • Tekuna は XML の定義とかあったりどこが micro なのか理解できない
  • バランス的には Limonade っぽいけどこいつはグローバルな関数と定数でゴリゴリ
    • プロダクトコードの見た目は確かに micro な感じなんだけど、ツクリ的にはまったく Sinatra inspired でもなんでもない

って感じで、例によってガッカリした感じ。

Limonade は中身に踏み込まずにプロダクト書くだけなら確かに手軽な感じだけど、ある程度拡張したくなったときにすごく邪魔くさいことにならないかなぁ。まぁなんか書いてみればいいんだろうけど。

これとは別に micro という謳い方ではなく Sinatra 風のものもあるので見てみると

この辺?

でも Sinatra と違って Rack ( WSGI ) に載らないし、testability はやっぱあんまり高くなさそうな。結局 PHP のスーパーグローバル変数を直接参照したりしてるので、ブラウザでアクセスしてテスト、って形になりそう。

うーん。

うーん。

プロダクトコードが短くなるのは大事なんだけどさ。もう、それだけじゃないよね。

creationix's rack-php at master - GitHub

rack-php っていうプロジェクトはあるけど、Sinatra inspired な人たちは Rack にはあまり興味ないっぽいしなぁ。どうしたもんすかねぇ。

そういうの期待したかったら PHP なんか選んじゃダメってことなのかなぁ。

※ Limonade はなんか curl で request 飛ばす処理があるな。もしかすっとこれでテストできるのかも。

cf. Sinatra風PHP用フレームワークLimonadeによるWebアプリケーション作成 - なんとなくな Developer のメモ

IPAフォント00201 を OSX 10.3 で試す

IPA フォント単独公開記念ということで、前回の IPAフォントを OS X で試してみた から変わったかなーと思い、試してみた。結果、

アプリplatform結果
mi 2.1.6PantherNG
iText 3.1.6PantherNG
CotEditor 0.9.3PantherOK

どうやら前回の予想通り、独自にというか古い方式?でフォント管理してるアプリはやはり 12, 14 ポイントで正しく表示できませんね。CotEditor は OSX 標準のフォントパネルを利用しており、表示も正しく行えます。

Carbon Emacs は設定するのが面倒でやってません。

M+ + IPA の合成フォントがそのうち更新されることをまったりと期待。

Sunbird 0.3RC1

Mozilla な Calendar アプリである Sunbird の 0.3 RC1 が出ました。

Calendar Weblog: Sunbird and Lightning 0.3RC1 available

試してみたけど、Month View や Multi Week で日にちをまたいでガッとレンジを設定してイベントを設定するっていう使い方はできないんだな。New Event からは作れるんだけど。

どうも自分は右脳人間なのかオブ脳なのか、せっかくカレンダーが目の前にあるんだからまずそこにマウスでガッと線を引っ張って、で、何のイベントかを書き込むっていう使い方がしたいんだなぁ。日時を数字で入力するという使い方は性に合わない。もちろん細かい数字の指定はマウスよりも直接入力した方がいいんだけど、手順としてまずマウスでガッとやりたいの、ガッと。

Day View や Week View ではできるだけにとても残念だ。むしろ今の自分のスタイルでは Day View や Week View の中で時間をマウスでガッと指定できても嬉しい機会ってそんなにないのね。ガントチャート的というか、”日”単位でガッといきたい。

コンパクトは歪むなぁ

相変わらず PowerBook は死亡中だけど、画像データはサーバの方に転送済みなので、遅いのを我慢しながら Singapore で写真の整理というかとりあえず全部を眺めてみている。

今まであんまり真面目にコンパクトデジカメの画像を見ていなかったせいか初めて気がついたけど、建物や木などの長い線がはっきり写っている場合は歪みが気になるなぁ。まぁそもそもコンパクトなのに液晶をあまり使わずに光学ファインダーで撮ることが多く1、そりゃフレーミングの段階でどうなんだと言われれば返す言葉もないような状態なので、細かいこと言ったってしょうがないんだけど。

35mmフィルム換算で38mmなんてレンズは広角のうちに入らねぇと思っていた自分が甘かった。一眼のつもりで何気なく撮ってると思わぬ落とし穴があるってことか。よく考えたら一眼では「方眼マット」専門の人間がコンパクトで水平、垂直を出そうなんておこがましい話か。

補正すりゃいいのかもしれんけど、基準になるもの撮ってないしなー。

参考 歪曲収差の補正に関して

  1. ついクセで 

Web広告研究会、第2回Webクリエーション・アウォードの受賞者を発表

from INTERNET Watch

広告的に意味がないとダメっつーわけでもないんだろうけど、プロモーション方面も新しいムーブメントのテクニカル方面もコンテンツを提供しつづける人も同じ土俵で受賞しているのか。なんか不思議だ。

GREE はなんかすごいことになってきてるけど、実際のところ試したみたこともないし、周りに参加している人も聞かないのでなんともはや。

Namazu 2.0.13 で気づいたこと

select box で検索対象を選択する方式の検索にした場合、検索後の form に、今回検索したインデックスの選択を引き継いでもらいたいと思っていた。前は HTML の記述によって挙動が変わるなぁーと思っていたが、どうもこれは Namazu が template を parse して解釈するときの挙動の違いらしい。

2.0.13 では従来できなかったインデックスの選択の引継ぎがスムーズに行えるようになっている。JavaScript を入れるなど特別な仕掛けは一切必要ない。これは便利だ。

これを強く感じるのは msearch ではこういうことができないからでもある。

楽天とライブドア

差が開きつつあるような気がする。

結局「表に見えないうまさ」ではあるけれども、「実務レベルの差」な気がしてきた。もちろんうまいのは楽天の方だ。地元との手の組み方を知ってるって感じ。ただ、いちばんアピールすべきファン層へのアピールではやはりライブドアの蛮勇(あえてこう言おう)の方が大きいという事実もそう簡単にはひっくり返らないだろうけど。

なんだろう。田中の長野県知事のようなもんか。支持者は市民だが、実務レベルでの議員などへのウケは最悪っていう。でも実務レベルに本人が腐心してたら民衆へのアピールのチャンス減るしね。難しい。

OS X のスクリーンショット

  • 旧来の cmd + shift + 3 で生成される PDF が微妙にぼやけている
  • グラブで作成したものはシャープ

なんか釈然としないな。cmd + shift + 3 での生成について設定はないのか。グラブは操作がまどろっこしいぞ。

About

例によって個人のなんちゃらです