超今さらExpress触ってみた - その3 Cloud Functions Emulatorでも動くようにする

超今さらExpress触ってみた - その2 Routerと実際のRequest Handlerを分けたい - の続き。

Request Handlerを名前付きexportsにする

index.js

module.exports = (req, res) => {
  res.send('Hello Express')
}

が、こうなる。

module.exports.hello = (req, res) => {
  res.send('Hello Express')
}

あわせて router.js がこう。

const {hello: IndexHandler} = require('./index')

module.exports = (app) => {
  app.get('/', IndexHandler)

  return app
}

これで Express アプリ側は今まで通りに動く。

ES Moduleのimport asはObject Destructuringで

上の

const {hello: IndexHandler} = require(

は見慣れない書き方ですが、

  • module.exports は単なる Object Reference であり、named exports は単なる key-value の定義
  • （key を合わせて）そのまま { } で受け取れば名前の付け替えは自由
  • const { name } の書き方は単なる property shorthands

ということのようです。

ただし、さらっと書いたけど

Node.js ES2015/ES6, ES2016 and ES2017 support

によると Object Destructuring は Node 6 以降の機能っぽいので、Node 4 LTS では使えないかも。まぁ Node 4 LTS はすでに EOL を迎えちゃってるので、いまこいつを気にしなきゃいけない環境はまずいんですが。

nodejs/Release: Node.js Foundation Release Working Group

名前付きexportsをCloud Functions Emulatorにdeploy

Google Cloud Functions Emulator動かしてみた - あーありがち(2018-06-04)

を参考に、

functions-emulator start
functions-emulator deploy hello --trigger-http

すればできあがり。

これで Cloud Functions Emulator 側でもアプリを serve できている状態になる。

Request Handlerがindex.jsだったわけ

前回までで作った Express アプリですが、

index.jsRequest Handler
server.jsNode.js が立ち上げる Express アプリ環境
router.js上記以外の routing だけを担う

のような構造になっています。

LAMP 構成に慣れている人からすると node コマンドの引数に index.js を持ってきそうな感じがしますが、

gcloud と functions-emulator で共通に利用できる request handler のファイル名は index.js であり、かつ node コマンドに与えるファイル名は自由に変えられる

ので、あえて function を index.js に割り当てています。

ということで、ここまでで一応 Google Cloud Functions へ deploy 可能な Express アプリを作る型ができました。

つづき

超今さらExpress触ってみた - その4 やっとテスト書けるよ - - あーありがち(2018-09-13)

EmacsのDesktopを初めてまともに使う

以前 Twitter の timeline で M-x desktop-clear という文字を見かけて、何も考えずにそれを実行して痛い目にあったことがあるんだけど、そのうち

なんと打って痛い目にあったのか忘れてしまった。

うーん。忘却力の向上めざましい。

ということでそれっぽいものをログから必死に検索して見つけたのが 9/1 で、何を実行したのかもう一度書くと

M-x desktop-clear

だった。これは Emacs の持っている全 buffer をクリアしてしまうものなんだけど、desktop っていう言葉はなかなか出てこないなぁ。

Desktop ってなに

なんていうか Eclipse なんかだと Workspace とかそういう言葉になるのかな。まぁいろんなファイルをどういう風に開いているかなど、「Emacs のまさに今の状態」を表すものが Desktop らしい。調べると CentOS 5 の Emacs 21 にもあるので、今使われている多くの Emacs で標準的に使えるものと考えてよいみたい。

できること

もちろん

M-x desk<TAB>

とか打つと補完されるので分かるんだけど、Emacs 21 でも使える

desktop-clear
全bufferクリア
desktop-read
save した desktop を読み込む
desktop-remove
save しておいた desktop ファイルを削除
desktop-save
desktop を保存する

程度が分かればとりあえず十分かなと思う。

カスタマイズしないで全部手動でやることにした

Desktop はもちろん

M-x customize-group

して

desktop

でカスタマイズできる。

Emacs 終了時に自動的に desktop-save して起動時に自動的に desktop-read すると、いわゆるプロジェクト管理機能付きのエディタや IDE の Workspace 復元機能として使えるんだけど、個人的には

ViewSourceWith

を使って Firefox の textarea や Thunderbird のメールを書くときにも Emacs を使っているので、こういう機能が自動で走るととても邪魔くさいことが分かった。何も設定せずに本当に必要なときにだけ desktop-save & desktop-read を使う方針にしてみた。

北陸FxUG勉強会@石川に参加してきた

実は正式名称が未だによく分からないけど気にしない。

B-Wiki - Flex3勉強会第79回＠北陸(石川)参加受付 - Flex User Group

正直な話、Flex 方面も Android と同じくアウェイなので、実は毎回参加を躊躇していた。今回、参加を思い立ったのは実は会場の関係もあったり。というのもITビジネスプラザ武蔵でやってみたらどうだろうというのは以前から思っていたので。金沢市民的にはやはり便利な場所なんですよね、あそこは。まぁ車で行くとなると駐車場代が掛かるけど、バス

  • 電車だと結構行きやすい。たけしまさん (mitukiii) on Twitterさんは石川高専のときに躊躇してたみたいすよ。車に乗ってると街中は面倒も増えますが、懇親会への流れやすさも考えると駅から街の辺りはやはり便利だなと感じた。

で、内容。

ほぼ門外漢なりに Flash Catalyst はやはりすごいというのは感じた。自分で beta 落としてみてもあそこまで使いこなせないし、轟さんのデモは効果絶大。CS 4 以降のデータを読み込んで Catalyst 上で UI 化、タイムライン編集までできる。なんじゃそれ。あれが標準になったら IDE の苦手な自分はどうしたらよいのやら。（サーバサイドやればいいんだけどね。）

Tour de Flex は面白そうだけど、試したそばから通信しちゃうのはちょっと怖い気も。どっかで設定できるのかな。それともあのデモが push 配信のデモだっただけか。

FlexMonkey の話も見応えがあった。ああいうの大事。Flash 無関係に Webサービスのテストに使えるかも。

ビンゴアプリはまさかのイテレーティブプレゼン。実は話の半分くらいは Flex 関係ない気も。

Silverlight の話は楽しみだったんだけど、入門編だったせいかちょっと物足りなかった。Flash 系の技術との類似点より Silverlight の利点を推してくれた方が嬉しいなぁ。Silverlight の不利なところは MS 製品だから仕方ないんだけど開発環境が Windows 限定になっちゃうところなんだよなぁ。ここ数年 Web 系のやる気ある有名人は結構 Mac 行っちゃってるから。

配信の話もなかなか面白かった。昔 Real Server をいじったことを思い出した。Real ってどうなってんだろう。全然話聞かないけど。ようやく MPEG 4 で目指した世界が実現しつつあるんだなぁと感じた。

ビンゴは例によって運のなさを露呈して最後にようやくリーチにたどり着いて終了。Adobe 洗脳 CD がちょっと欲しかった。

会場はやっぱり便利だなーと思った。建物はエムザなので便利に決まっているし、外に出てもなんでもある。1中は途中プロジェクタの電源が落ちるハプニングはあったけど、壁コンセントもそこそこあって扱いやすい。ただ建物自体が安いのか、なんかドンドンうるさい時間帯が。何か暴れるイベントがあったのか、準備でモノを運ぶ音だったのか。あの時間帯だけちょっと残念だった。無線LANは持ち込み機材でしたっけ。途中ちょっと詰まる感じがしたので25台(?)くらいになると厳しいのかも。自分は途中からずっと emobile でつぶやいてた。

ということで FxUG のみなさんありがとうございました！

  1. 昼ご飯はすぐそばのすき家で食べた。時間とお金に余裕があればフレッシュネスバーガーもオススメ。 ↩

netbook U100 げと

本当は netbook は全然買う気なかった。昔このサイズの機械を触っていたし、バッテリの保ちも当時とたいして変わらない。もちろん基本性能は当時より高いが、あの小さい画面でできることなどたかが知れていると思っていた。（実際、知れている。）

しかしあるきっかけで欲しくなってしまってからは1週間ほどで機種の選定から実際の購入まで全部やってしまった。うーん、熱は完全に消えたわけではなかったか。

というわけでざっとおさらい。

候補は以下の5機種。あれこれ比較して以下のように順位を付けた。

  1. MSI netbook U100
  2. Acer Aspire One
  3. AsusTek EeePC

以下次点。

  • DELL Inspiron Mini 9
  • HP 2133 Mini-Note PC

ずばり基準は

画面とキーボードがどれくらい人間に優しいか

である。この基準は PC がでかいとか小さいとか関係ない。PC として使う以上は譲れない基準だ。というかこのサイズの PC のスペックは今ほとんど差がないんだから、あとはデザインかブランドかインターフェイスくらいしか比較しようがない。まぁバッテリの保ちは気になるが、インターフェイスが腐っていたらどんなに長時間バッテリが保とうがそんな機械を使い続けることはできないので無意味だ。

HP のやつのキーボードは大きめで使いやすそうだったんだけど、Atom じゃないし、あっちっちだっていう噂。DELL の変態配列はあり得ない。残りの3機種は実際に触った結果、調査段階とまったく変わらないオレランキングが出た。EeePC はキーボードもよくないが画面が暗い。Aspire One もいいかなと思ったが、最終的には 9" と 10" の差がでかかった。画面もキーボードも余裕のある netbook U100 最強。HDD が 80GB しかなくたって、他のものより多少高くたってそんなことは気にしない。使って気持ちいいか、触って気持ちいいかが問題なのだ。

さて。というわけで emobile もあるし、ずいぶん外に出やすい環境が出来上がってしまった。どうしようかな。

そりゃLL使いでも低レベルを知っているに越したことはないに決まっている

    えーと、最近の一連の話はほとんど読んでませんが、C もアセンブラもかじった程度にだけ経験はあるけど BINARY HACKS はほとんど分からなかった1 LL な人間として思うことは

    絶対に知っとけとは言わないけど、知ってると勘は働くよ

    ってことかなぁ。勘て書くと誤解を生みそうだけど。

    C やマシン語をきちんとやらなきゃいけないって意味じゃーないんだけど、低レベルの動作がある程度想像できるようになっていると、例えばあまりに非効率な方法は実際に書いて動かしてみる前におかしいと気づきます。（なんつーか、これを詳細設計と呼ぶのかもしれない。知らんけど。）

    例えば DB からデータを取得するときに、まるでテキストファイルを相手にするかのごとくシーケンシャルに一つずつ取ってくる2とか、テキストファイルからデータを取得する際に OS のバッファリングなどに丸投げせずに自分で妙な技を開発しちゃうとか、そういうのはフツーあり得ないわけですけど、何がどうあり得ないのかきちんとマシン語レベルで説明できなくても、そりゃ効率悪いに決まってるやんとかは気づくわけです。なんとなくですけど。3

    同じように、アルゴリズムとデータ構造といった、いわゆるコンピュータサイエンスの基礎中の基礎に当たる部分もやっておくと、この場合にこんなデータ構造にするわけないじゃんとか、これは有名な○○のアルゴリズムをそのまま当てはめればいいし、それは標準関数のこれこれとかライブラリのどれそれですぐに実現できちゃうのに、なんでそんな力技を編み出そうとするの？とかいうのも、実際に書いて動かす前に気づけるわけです。4

    そういう意味での基礎体力というか、そんな感じで役に立ちます。もちろんそういう効率の悪いコードを書いてしまっても、それをきちんと計測して遅いから別な方法を採用した方がいいなと判断できる力があるならそれでも構わないとは思うんですが、残念ながらそんな、いい意味でアンバランスな人5にはお目にかかったことがありませんし、書く前に気づけるならそれに越したことはないわけです。なまじっか動くものができちゃうとそれを壊したり直したりするのに抵抗が生まれたり6するでしょ？ 動くものができる前なら遠慮なく破棄できますから。

    LL や Java など VM 上で動く言語を使う人間としてはそんなの知ったことかと思いたいわけですよ。そんなのお前らがいい具合に勝手に解釈しろと。まぁそこまで乱暴なことは言わないまでも、「コンピュータなんだからそれくらい良きに計らってよ」に近いことをぼんやりとですが、考えていたりするわけです。よく考えると「開発者」とか「技術者」を名乗るにはあり得ない発想だったりしますけど7、まぁやっぱ基本的にプログラマは楽をしたいから苦労する人間なわけで、楽をしたいと思うこと自体は否定しちゃダメなのかなとも思います。

    話がそれた。

    とにかく、あんまりこと細かに具体的な話をするのは難しいんですが、知ってるに越したことはないよというのは間違いないです。そしてこれは特定の言語のクセとして慣れるのとは違うレベルでの力なので、言語を乗り換えても活きます。例えば「PHP のプログラムを高速化するための 10 の Tips」みたいなのってものすごく人気あるわけですけど、そういう知識は PHP を使わなくなったら役に立たなくなります。でも低レベルの知識は PHP だろうが Ruby だろうが役に立ちます。低レベルがガラッと変わっちゃうことはそうそうないですから。

    ただまぁ、くり返しになりますが、優先順位はそんなに高くないと思います。

    • プロファイラがちゃんと使える
    • 論理演算というか集合がちゃんと分かる
    • テストをちゃんと書く
    • 黙ったまま作業しないでちゃんと commit する
    • 構成管理のツール（Trac とか）が入ってるならちゃんとそれを使う

    とか、「上のレベル」で身につけなきゃいけないことが多いですし、少なくともここに挙げたものを満たさずにマシン語レベルの話が分かったからと言って大きな顔をするようなやつは廊下に立ってろですよ。8

    最後にこれものすごく疑問なのですが、例えば Perl のリファレンスとか Lisp の car, cdr なんかを、メモリアドレスとか C のポインタとかを知らずにどうやって理解するんでしょうか？ そこら辺がどーも私にはピンときません。Perl ハッカーで C もアセンブラもさっぱりですという方がいたらご一報ください。お友達になりましょう。

    cf.

    1. というかネタとして買った ↩

    2. 単にロックの仕方をちゃんと知らなくても安心して使えるストレージに成り下がっちゃってる ↩

    3. 例えば一回 C でファイルの読み書きを全部書いてみりゃどれだけコストがでかいかは実感できます。少なくともまともに動く C のソースを書き上げるだけで面倒です。Ruby なら File.open( moge ) { |f| } で一発なのに、とか思いながら書くのでますますうっとぉしいです。 ↩

    4. と、言いつつ自分はあんまりそういうのが役に立つようなことはしてないですし、どれだけの精度で自分に当てはまっているかについては自信はありません。ありませんけど、世の中にはそういうの全然分かってないのに自信満々な自称プロの方もいたりして、不思議だなーと思うことはあります。 ↩

    5. 低レベルの知識ゼロなのにプロファイラ使いこなしてる人 ↩

    6. 自分の心の抵抗じゃなくて外圧の場合もある ↩

    7. それを実現するのが己らの仕事じゃねーのかよ ↩

    8. くどいようだけど、これは低レベルの知識がなくても書ける LL を前提にした話ね。 ↩

    フィクション殺人について

    なるほど面白い。

    けど。

    なんか最近、殺人に問題が単純化されたり、安易に比較対象にしたりすることがちょっと多いような？ タブー視すべきではないけど、「概念」として安易に扱いすぎることも現実感の喪失を生まないだろうか。もうちょっと生命体としての感覚を磨くのも大事じゃないかと思う。なんつーか、死ぬのも殺すのも恐ろしいものでしょ、ほんとは。そういう感覚はなくしちゃダメだと思うんだよな。概念の方をトレーニングするのと同時に、皮膚感覚というか、そういうのも磨いておかないとちょっと危うい感じがする。

    まぁ、本来個人でトレーニングを意識する必要なんかなかった話なんだけどね、死っつーのは。

    bruteforceblocker @FreeBSD ports

    security/bruteforceblockerはPF限定じゃなくて簡単にipfwにも対応できる

    なるへそなるへそ。

    そろそろ 4.x 系の引き際も考えないとなぁ。

    spam 対策

    米Symantec、「スパムはあと2、3年でなくなる」 (CNET Japan)

    Symantec はライセンスの問題で Sender ID を見送るってことはないからね。

    やっぱり？ < 糖尿病

    油断禁物、「やせ形」も飲酒で糖尿病の危険　厚労省調査 (asahi.com)

    うちの父親はもともと痩せてる方だったけど、日本酒の晩酌の習慣とか（だけじゃない）があって、今は立派な糖尿病。そういうもんだよね。とりあえずドカ食いはしない方だし、しないようにしてるけど、酒は飲んでるな。ジンだけど。毎日日本酒2合相当ってことはないので、その辺は詳細な情報がほしいところだ。

    休肝日がなければ少量でもあぶないのか、その辺がいちばん気になる。

    ports を探すノウハウ

    メモ/FreeBSD覚え書き

    make search key=hoge

    なんて知らなかった。いつも whereis って使えねーなぁというところで思考停止してた。こりゃ便利だ。

    大規模な管理ノウハウもほしいな。この辺はまだ少し先の話か。

    Meta-CVS が分かってきた

    停滞していた Meta-CVS ドキュメントの翻訳を今日一気に進めたら概要は分かった。

    • Meta-CVS は Lisp で書かれた CVS のフロントエンド
    • リポジトリは CVS のものをそのまま使う
    • ただしディレクトリ構造の変更に対応するためディレクトリ構造はすべてフラットな特殊なファイル名に展開される

    その対応は

    foo/MCVS/F-123D61C8FE942733281D2B08C15CD438
foo/MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h
foo/MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0
foo/MCVS/F-1C43C940D8745CAA78752C1206316B55.c
foo/MCVS/MAP
foo/MCVS/MAP-LOCAL

    こういう感じで記述される。

    (("MCVS/F-123D61C8FE942733281D2B08C15CD438"
  "README")
  ("MCVS/F-156CAB88D4EEE703E8C4B4146B5094E2.h"
  "inc/foo.h")
  ("MCVS/F-15EA9689ACF749C314CE6FC5255DC4B0"
   "src/Makefile")
  ("MCVS/F-1C43C940D8745CAA78752C1206316B55.c"
   "src/foo.c"))

    from Meta-CVS-PAPER in Meta-CVS アーカイブ

    要するにディレクトリ構造ごと versioning できないという CVS の問題点を、「ディレクトリ構造を扱わないようにする」というアプローチで回避しているってこと。同じく filename と repository 内の entry の関連づけを修正することで rename 問題に対応してる。なるほどね。

    CVS で直接リポジトリを参照すると訳が分からないが Meta-CVS 経由でなら human readable なファイル名になる。でもこれ、ViewCVS とか CVSWEB とか対応してないとつらいよな。GUI な CVS ツールでの対応も大事だし。要するにみんながあらゆる局面で Meta-CVS 経由でアクセスしないといけないわけだ。

    クライアントの状況が揃わないうちは localcvs であれこれ構造を考えるときに利用して、本チャン repository には投入しないって運用になるような気がするけど、それって localcvs を別に用意している段階で Meta-CVS の問題のあらかた解決（操作が簡単になるメリットはなくならないけど）してるんだよな。

    つまり、ファイル名、ディレクトリ構造を変更したときの履歴を追えないという CVS の最も致命的な問題と、Meta-CVS へのクライアントの対応状況および学習／教育コストのトレードオフ。クライアントの対応状況は Meta-CVS よりすでに Subversion の方が充実してそうだし、少なくとも公開のプロジェクトで今から Meta-CVS の導入ってちょっとつらいだろうなぁ。

    Meta-CVS を Lisp でない、GUI も作りやすい1もので作り直したらもう少しアプリの対応は進むかもしれないが、なんだか遠い道のりだなぁ。Meta-CVS は、BerkeleyDB に依存しないし、サーバ立てなくてもいきなり使い始められるというメリットがあるから個人的には嬉しいブツなんだけど。

    ViewCVS には Meta-CVS 対応パッチがあるな。取り込まれているといちばん嬉しいけど、それは都合よすぎか。

    1. Lisp の GUI の状況はさっぱり分かりません ↩

    サイト構築プロセスとサイトの形

    日記ツールで下書き、blogツールで清書 (ishinnao.net)

    ishinao 氏の考え方は以前から参考になるなぁと思っていたので、とっくの昔にこっちの考え方が ishinao 的になっている可能性もあるけど、日記ツールはどかどかとネタを書き出しやすく1、そしてそれだけで終わってはユーザーとしてはあまり嬉しくないサイトになってしまうので、読み物のストック（と、ishinao 氏は interactive な仕掛けも見落としてない）用に別な形を用意するという形は、自分としては実にしっくりくる。

    ただ、自分のサイト（説教講座）ではあまり議論の余地を残さない、古くなっていくことを前提とするコンテンツを載せていきたいと思っているので、ストックの形は blog ツールである必要はない。静的 HTML で十分。

    問題は素朴な静的 HTML 方式ではカテゴライズが壁として残るってこと。内容の固定された企業サイト、あるいは特定のアプリや特定のテーマに絞られたサイトなどではあまり問題にならないが、個人の興味に応じてサイトが変形していくことがよくある個人サイトではディレクトリ構造によるカテゴライズは限界あるなぁと感じているところ。リニューアル終わったばっかなのに。

    しかし、こういうときこそ TrackBack の使えないもどかしさを感じるなぁ。

    1. 試しに blog だけでサイトを作ろうと cocolog を使ってみたがダメだった。 ↩

    J-KIDS大賞

    ふとしたことでキッズgoo を訪れて、このサイトを思い出した。で、評価基準が載っていた。

    http://www.j-kids.org/selection/evaluation2003.html

    評価基準の評価はまぁ置いておくが、こうしたものが公開されることで、よりよい評価を考えることができる。ありがたいことである。

    文章が下手だ

    説教講座を改修していて痛感していること。

    書いた時期にバラつきがあるとは言え、正直、かなりデキが悪いと思う。書いているときに本人が盛り上がり過ぎていたり、HTML だの CSS だの、書くことそのものに集中していないだの、要因はあるんだろうけど、

    単に文章が下手

    という感じがする。というか

    何が書きたいのか分からん

    て感じ。まぁ、修行時代のものだと思えばよいのかもしれないが、なんともはや。構造を直したら文章そのものもけっこう手を加えてしまいたい気分だ。

    About

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