tunnel serviceちょっと調べてみた

基本的には localhost を internet に公開するのに ngrok を使ってるんだけど、ふと気になって他のものも調べてみた。

独自の ngrok コマンドで tunnel を作る。random な URI が自動で振られるが、課金すると domain を固定できる。

もうずいぶん長いことサービスしてる。以前は存在しなかった Inspector をブラウザで開くと request / response の状態を確認できる。

ssh の remote forward サーバ。ssh が分かってないと使えない。

localhost 以外にも tunnel できるのは分かるけど、sign up なしで使えるし鍵を使うと custom domain も使える。なんだこれ。

OpenVPN を使った tunnel を作ってくれるサービス。OpenVPN が分かってないと使えない。

Chrome 拡張から tunnel を作れる。コマンドラインが苦手な人にはよいかも。free plan はないみたい。

Webhook に絞るとこんなのもある。個人的には汎用の tunnel でよさそうではあるけど、Webhook 開発に都合のよいものがいろいろあるのかも。

MobXをVue.js(Nuxt.js)で試してみた

なぜVuexじゃないのか

先日来、ViewModel フレームワークが片っぱしから値の変化やイベントを検出して View を書き換えようとする姿勢に疑問が生じていて、本来は MVVM とかじゃなかったの？ M 無視しすぎじゃね？ あるいは M は全部 HTTP とか割り切りすぎじゃね？ という感じになってきていた。1

それで検出されないようにするにはどうしたらよいかというのが昨日の「ViewModel系フレームワークでデータの変化を監視させない - あーありがち(2018-05-01)」になるわけだけど、これはいわゆる VM component 内の話。でも実際のところ Model はだいたいグローバルでシングルトンになるんじゃねーの？という気がしていて、そうなると component でだけ実現できてもなーと思うわけですよ。

で、じゃあグローバルでシングルトンてことになると Flux 系 Store 具体的に例えば Vue.js だとまぁ Vuex になるんだと思うけど、その Vuex ではこういうことはできない。Vuex は雑に言うと監視対象となる state とその state に変更を加えることを許された mutation から成る2 が、これらはそれぞれ独立した function であり、mutation には基本的には state しか渡ってこない。mutation 以外に action や getter も定義できるが、事情は同じである。すべて state を中心に置いている。そして改めてくり返すが、その state はすべて監視対象というわけだ。

class ベースの React.Component みたいに Store という名の Model 相当の class があって自由に property を増やせるわけではない。その強い制約こそがグローバルな状態管理によいのかもしれないが、それにしてもなぁという感じ。

MobXのサンプルコードを見てみる

そこで MobX.

Introduction | MobX

こいつは Store というよりは基本的には Observer と言ってよいと思う。

公式のサンプルコードを引用するとこんな感じ。

import { observable } from "mobx"

class Todo {
  id = Math.random();
  @observable title = "";
  @observable finished = false;
}

ここで「これ JS か？」と思うかもしれないけど、class property と decorator を Babel ってやれば使えるれっきとした ES.next valid な JS なので、JS 脳が化石化してる人は慌てた方がよいかもしれない。

ポイントは @observable で、この decorator がついている値だけが監視対象になる。ね、これこれ、こういうことですよ、やりたいのは。

ついでにこの observable な値に変更を加えるには @action を付けた function を経由するとデバッグしやすくてよいよ、ということなので、それらを適当に書き足すと

class Todo {
  @observable title = "";

  @action setTitle(title) {
    this.title = title;
  }
}

こんな感じ。

これは「各自が気ままに値を書き換えると追えなくなるよ」という教えに従っているだけで、絶対守らなきゃいけないってわけじゃないけど、まぁ守っておこう。別に混乱を生みたいわけじゃない。

実際にVue.jsで試してみた

Vue.js と MobX をブリッジしてくれるライブラリは有名どころで二つある。これ以外にもあるのかもしれないけど、見つけられなかった。

実際に利用したパッケージは

  • mobx 4.2.0
  • vue-mobx 2.0.0
  • movue 0.3.0

ここで雑に比較すると、とにかく component 内での記述を少なくしたいなら vue-mobx がオススメ。Vue.use の記述は済んでいるものとして component 内のコードはこれだけで済む。

import Model from '..'

export default {
  fromMobx: {
    Model
  }
}

なんと、fromMobx に Model を与えるだけ。こうしておいて、この object を食わせて Vue component を生成するだけでいきなり Model 内の observable な値と action が component 内に生える。

いきなり生えるのが Ruby の module っぽくて「おぉ、なるほど」となるのだが、さすがにどんな component から呼ばれるか分からない Model の observable と action がそのまま生えると、やたらと VM component が増えがちな昨今のフレームワークでカジュアルに使うにはちょっとまずそうな気がしないでもない。

そんなあなたには movue.

movue も fromMobx という property で VM component 内に Model の情報を呼んでくるのは一緒だけど、この fromMobx では細かく設定をコントロールできるので、こっちの component ではこの名前で、あっちの component ではこの名前で、といった使い方ができそう。

Decorator対応

MobX の decorator は optional なので、実はさっきの例は以下のようにも書ける。

import { observable, decorate } from "mobx"

class Todo {
  id = Math.random();
  title = "";
  finished = false;
}

decorate(Todo, {
  title: observable,
  finished: observable
})

こっちの方がより広範囲で動くのだけど、確かに decorator を使えた方が記述が分離せずに分かりやすい。

ということで使えるようにしていこう。

Nuxt x Babel対応

正直ややこしい。

Babel は 6 と 7 の間で decorator の扱いが変わっている。今回の実験は Nuxt.js 上で行っており、2018-05 現時点で Nuxt 1.0.0 は Babel 6 依存なのでそれで動くようにしていく。

babel-preset-mobx があるのでそれを使ってみたのだが、これは動かなかった。

zwhitchcox/babel-preset-mobx: All dependencies mobx depends on

中身を見ると preset と言いつつ実際には以下の4つの plugin を利用する

  • babel-plugin-transform-class-properties
  • babel-plugin-transform-decorators-legacy
  • babel-plugin-transform-es2015-classes
  • babel-plugin-transform-regenerator

Nuxt.js の Babel の設定は vue-app ( vue + babel-preset-env ) なので本当に必要なのは以下の2つ

  • transform-decorators-legacy
  • transform-class-properties

これを plugins に追加してやれば ok

順番が大事。 decorators-legacy の次に class-properties ここら辺は Babel のイヤンなところ。エラーを見ても何が起きてるのか分からん。

おまけ VS Code 対応

decorator でずっと警告が出るので ESLint の設定がちゃんと反映されてないのかなーと思って疑ってたけど、これは VS Code で独自に出してるやつでした。

javascript.implicitProjectConfig.experimentalDecorators": false,

を true にすると解決。

まとめ

MobX は Redux の面倒くささを解消してくれるとか jQuery とも合わせられるとかいろいろ言われている最近注目の状態管理ライブラリらしいけど、「observable で明示するだけ」というシンプルさは自分の考えている、もっと広く一般的な Model としても扱いやすそうに見えた。

昨今の ViewModel フレームワークが薄いフレームワークになることで View 側の問題の本質に注力しているように、Model 側は Model 側で「Backbone.Model のようないい具合にイベント起こしてくれる程度のシンプルなやつねーかな」と思っていたところに MobX を見つけることができたので、自分の中では割と期待が大きくなってきている。

（これなら既存の jQuery を叩き直すのにも、何かの拍子に付き合わなきゃいけなくなる可能性の高い React ともなんとかやっていけるかも？）

まだテスト周りがよく分かっていないので、次はテスト周りをチェックして、よさそうなら今後は MobX に振っていくかもしれないなーという気がしてます。

  1. MVW って言ってた Angular でさえ M のことは知らんてなってる感じがすごい(小並感 ↩

  2. action はいったん置いておく ↩

Mongoid試してみた

特に目先の目的はないんだけど、スキーマとデータを後から自由に、しかもメンテナンスストップせずに変更できそうな気がして MongoDB を動かしてみようと思い、Mongoid をちょっと触ってみた。

自分用のメモなので特に面白い話はないです、念のため。

Mongoidを使った開発の準備

MongoDBのインストール

省略

新規アプリ作成

rspec を使いたいので

rails new APP_NAME -T -O

で、作成。

できあがったアプリケーションのGemfile

assets とか省略して最低限こんな感じ。

gem 'mongoid'
gem 'bson_ext'

group :development, :test do
  gem 'rspec-rails'
end

で、これを

bundle instal

します。bson_ext はなくても動くみたいだけど、なんかいろいろメッセージが出てうるさかったのでインストールして黙らせた。

generatorを叩いて設定ファイル作成

mongoid のインストールが成功していれば

rails g mongoid:config

これで config/mongoid.yml ができる。これは中身いじらなくて ok. rspec の分は省略。

dbの場所確保とmongod起動task

MongoDB は SQLite3 のような組み込み用ではないので daemon を起こす必要がある。繊細な感じがしていやだったので以下のような rake task を用意した。

これは

db/mongodb/
config/mongo_develop.conf.erb

を作って、conf.erb の内容から conf を生成してこの conf を mongod -f に与えて起動するようになっている。

screen を起こして一つの window で mongod を、もう一つで rails server を起こすようにすると邪魔じゃないしタブの意図が明確になっていいんじゃないかと思う。mongoid.yml の配置以降は mongod 起きてないと rails コマンドがちゃんと機能しないかも。

少なくとも migration は migration 実行時に初めて DB に変更が加わるんだけど Mongoid の場合はその場で変更できるものは変更するらしい。したがって mongod が起きてないと generate や destroy は実行できない。

Modelの作り方

普通に generator を使う。上のセットアップを済ますと generate model は Mongoid の model 生成用 generator に差し替わっている。1

できるのはこんなモデル。

class Foo
  include Mongoid::Document
end

ただし、これだと timestamps 相当の field がない。ActiveRecord::Migration が標準で作るのと同じ感じの Model にするには以下のように作る。

class Bar
  include Mongoid::Document
  include Mongoid::Timestamps

  field FIELD_NAME, { option }
end

Mongoid はこんな感じで便利機能をイロイロ include できるらしいので一度確認しておくとよさげ。

cf. Play With Mongoid!

Mongoid + Dragonfly

ActiveRecord の場合は以前

今さらRails3メモ - 番外編その1: Paperclip and Dragonfly

で書いたように require するだけでいいんだけど、Mongoid の場合はもう一手間必要。

File: Mongo — Documentation by YARD 0.7.4

と言っても本家に書いてある通りで、

require 'dragonfly'

app = Dragonfly[:images]

...

# Allow all mongoid models to use the macro 'image_accessor'
app.define_macro_on_include(Mongoid::Document, :image_accessor)

MongoDataStore 使わないなら上の実質2行を initializer に加えるだけ。

感想

migration がないので最初のセットアップのテンポがいい。ActiveRecord のときは

  • migration の方に column を書く
  • Model に attr_accesible 定義や validation で column を書く
  • さらに管理画面に Typus を使ってると Typus で編集可能な column 定義書く

という感じで、

DRY !!!

って叫びたくなる。それが Mongoid + RailsAdmin だとだいぶ楽ちんな感じ。2

とは言え migration がないので逆に field 名変更は全 document に対して実行しなければいけない。rails runner でのバッチ処理の出番か。

もともとできるだけ生SQLは書かないようにしていた3し、別に RDBMS 脳でもないので Mongoid 縛りで MongoDB を使うのにはそれほど抵抗ないんじゃないかなーと思っている。まだ Relation 使ってないから join ねーよ！ってときの気持ちが分からないけど、ま、なんとかなるんじゃないかな？

参考

  1. ActiveRecordを使うgeneratorは active_record:model に退避されているので使おうと思えば使える。 ↩

  2. RailsAdminについては別エントリで。 ↩

  3. といっても凝ったことしようとすると書いた方が早かったりするんだけど ↩

FasterCSVでの改行の扱いメモ

日本語で改行入りのデータにうまく対応できるだろうか。以下、FasterCSV 1.5.3 で実験。

まとめ

FasterCSV は改行コードは LF でも CRLF でもどちらでも良い。レコードセパレータとしてもセル内の改行としてもどちらでも良い。ただし、当然セルは " " で囲まれていないとダメ。

実験

OOo calc のデータ

RSLF
セル内改行LF

大丈夫。

全部CRLFのデータ

作ってみた。

RSCRLF
セル内改行CRLF

問題なし。

Excelを想定して

Windows の Excel が手元になかったので教えてもらった通りにデータを作成してみた。

文字コードShift JIS
RSCRLF
セル内改行LF

全体を LF にしたあとに行末だけ CR を付加した。

問題なし。

結果

FasterCSV は文字コードが UTF-8 なら改行コードは LF, CRLF のどちらでもよい。これはレコードセパレータとしてもセル内の改行としてもどっちを使っても良いという意味。セルが " " で囲まれていればその外の改行をレコードセパレータと解釈してくれる。

改行を含んでいるのに " " で囲んでいない場合は Malformed CSV になる。

Shift JIS のデータはそもそも食えないので与える際に NKF で文字コードを変換してある。

生活リズムが変わると

どうでしょう Classic の録画を忘れる。

どちくしょう。でもまぁ昼間充実してたからどうでもいいや。

Xen が少しわかってきた

実験環境を用意したっていうか自分が実験できる環境に出向いた。

Domain 0

  • 基本的に Xen 向けにカスタマイズされたカーネルを利用した普通の Linux
    • みたいな感覚で扱えるもの
    • ディストリビューションが対応している場合、そのインストールはびっくりするくらい簡単。基本的に普通にカーネルをインストールするのと同じ。
    • 自分でソースから build とかするとカーネルのアップデートが面倒になるので個人的には対応ディストリを使うべきだと思う

Domain U

  • 構築は、フロッピーも DVD も何もない状況で起動可能なディスクを作ってそこからブートさせるプロセスに似ている
    • VMware と違ってとりあえず空っぽの仮想マシンを立ち上げてインストーラからインストール、という手順を踏めない
    • だから debootstrap がどうこうという話が wakatono さんの記事によく出てくる。debootstrap に inspire された rpmstrap というものもあるので、rpm ベースのシステムはこっちを使えばいいんじゃないかと思う。xen-tools.org - Xen Software: xen-tools の xen-create-image はどっちも対応しているらしい。
    • Debian 4.0, CentOS 5.0 など対応ディストリビューションではこのプロセスも結構簡単
  • 仮想ディスクに相当するデバイス（ファイル、論理パーティション、物理パーティション、物理ディスク）と設定ファイルをコピーすればどの Domain 0 環境でも使えるはず
    • 仮想ディスクイメージとして設定まで中に持っている VMware や VirtualPC とはちょっと違う。逆にそのおかげで特別な設定ツールを必要とせずに Domain 0 上で設定ファイルを直接編集できる
    • Live migration なら動作中でもコピーできるらしいが具体的な方法はまだ知らない

Hypervisor & Monitering Tool

  • 仮想環境を操作するために xm コマンドを利用する。最近流行のサブコマンド形式ですげーいろんなことができる。基本的に xend に依存している。
  • が、仮想環境の操作を行わないなら必要ないし削除してよい。というか wakatono 推奨環境では Domain 0 からは xend 削除しちゃえば？って感じ。

今のところのまとめ

  • VMware と違って従来は基本的に GUI がなく1、非常にとっつきにくい感じのしていた Xen だが、ちゃんと段取りを押さえていけば一部を除いて非常にオーソドックスに考えることができる。むしろ完全に GUI なしで環境構築できるのでサーバ向けにとてもよい。
  • Domain U の「環境」構築は Domain 0 でなければできないわけではないので、構築環境は別に用意しておけば Domain 0 に余計なもの入れなくていいよね。
  • Domain 0 に IP アドレスを割り当てない方法も可能なので、完全リモートでないならそれがいいような気がする。

※ 別に Debian 好きではないが、Debian 4.0 と CentOS 5.0 ならやっぱ Debian の方が好きだな。余計なことを何もしないので目的に向かって最短距離で突っ走るにはよい。まぁ 4.0 が出たばっかだから思うのかもしれないけど。

cf. Open Tech Press ｜ CLIマジック：debootstrapによるDebian GNU/Linuxのインストール

  1. 入れてないから詳しくは知らないけど CentOS 5.0 には GUI 用のツールもある。 ↩

FreeStyle Wiki こんな感じかな

accesskey だけでなくついでに title もつけてみた。

lib/Wiki.pm

319a320,321
>         my $title  = shift;
>         my $access = shift;
330c332,344
<         push(@{$self->{"menu"}},{name=>$name,href=>$href,weight=>$weight});
---
>         if ( $title !~ /^$/ ) {
>                 $title = ' title="'.$title.'"';
>         }
>         if ( $access =~ /^[0-9a-zA-Z\/.,]$/ ) {
>                 $access = ' accesskey="'.$access.'"';
>         } else {
>                 undef( $access );
>         }
>         push(@{$self->{"menu"}},{name=>$name,
>                                  href=>$href,
>                                  weight=>$weight,
>                                  title=>$title,
>                                  accesskey=>$access});

accesskey に使える文字は正規表現にあるように制限したけど、これは手元の Firefox で適当に確認しただけなので、間違ってる可能性あり。まーでも普通は英数字以外使わないでしょ。

tmpl/header.tmpl

7c7
<       <a href="<!--TMPL_VAR NAME="href"-->"><!--TMPL_VAR ESCAPE="HTML" NAME="name"--></a>
---
>       <a href="<!--TMPL_VAR NAME="href"-->"<!--TMPL_VAR NAME="title"-->
        <!--TMPL_VAR NAME="accesskey"-->><!--TMPL_VAR ESCAPE="HTML" NAME="name"--></a>

途中で改行入れましたが。

あとは plugin/*/Install.pm とかにある

$wiki->add_menu("編集"  ,"",997);

を

$wiki->add_menu("編集"  ,"",997,"このページを編集[e]","e");

こんな風に直す。使い方は

add_menu( リンクテキスト, href, weight, title, accesskey)

で、title も accesskey も任意。設定しない場合は当然 HTML 上には現れない。（これは HTML::Template の機能。）

title はともかく、accesskey は管理画面で有効にするかどうか選べた方がいいんだろうなぁ。

HHK Lite2 げと

なんかキーボードを買ってばかりのような気がするが、うち用に HHK Lite2 JP PS/2 黒を入手。予想通りちょっと音がでかい1が、それ以外はそれほど不満はない。さすがにこの値段で細かいタッチに注文をつけるのは酷ってもの。サイズと値段とまともな配列を考えると十分にお値打ち品である。2

しかし金沢はこれ1本手に入れるだけなのにちょっと苦労しますぞ。いいのか、こんなことで。置いてるキーボードのほとんどは Microsoft, Logicool を除くと Elecom はじめ安めのラインナップばかり。そもそもまともな配列のコンパクトキーボードがほぼ皆無。（変則配列3の USB のものは割とよく見る。）いかんなぁ。まーまともなコンパクトキーボードってみんな高めだから、売れにくいってのはあるだろうけど、こうして店頭にモノがないという状況は完全に悪循環にハマッてるよね。以前は 100満ボルトにも置いてあったのになくなってしまった。パーツの品揃えは増えたのにキーボードが減るとは何事か。

  1. ゆっくり丁寧に押せばもちろん音は出ないんだけど、HHK ユーザーにそれを求めるのは無理。ここだけはものすごい不満なんだよな。 ↩

  2. 実際には入手できる店がほとんどないので、若干お値段高めになってしまったけど。 ↩

  3. 何を以って変則と呼ぶのかは人それぞれだと思うけど、個人的には Enter の脇に一列だけキーを配置するタイプは許せない。逆に Ctrl が左下だろうが Fn 左下だろうがそこはどうでもいい。どうせ A の隣に持ってくるから。 ↩

大人も勉強しろとは思うが、

科学常識このぐらいは——目安作り、文科省乗り出す

うーん。正答率91%(8/11)。 悔しいなぁ。

まだやってない人のためにどれが何とかは書かないけど、日本の入試とか免許の試験とかを受け慣れてると裏読みしてハマる可能性アリとだけ書いておきます。スパッといきましょう。

しかしこの手の基準を文部科学省が言うのはどうかなぁ。旧文部省じゃなくて旧科学技術庁が言ってるのかな。あ、これも裏読みか。

冷房器具調べ

思うところあって冷房器具を調べる。

冷風機なるものがあるらしいことを知るが、最終的には湿度が上がるか気温が上がるかのどちらからしい。そりゃまぁそうだよなぁ。電気もガスもそのままでは冷却能力はないんだから、どうにかしてある空間の熱や湿度を奪ってそれを別な場所に逃がさなきゃならない。じゃーどこへ逃がすって話に行き着く。部屋の中に逃がしたら元の木阿弥以下の可能性は十分にある。

体感温度を下げることは十分に可能だろうけど、それは直接風を受けることが可能な場合に限られると考えて間違いはなさそう。では風を受けることがそもそも身体に触る場合はどうだろう？ 暖房は温風を出さないタイプがあるけど、冷房はそういうのはさすがに無理なのかな。

なんて、別に大げさな話じゃなくて単にフェレット向けの冷房を考えてただけなんだけど。うーむ。経済的で健康的な冷房ってのは案外難しいな。

2.5inch のディスクをマウント

あれこれ調べて、サーバを立てて以来初めて、昔使っていた 2.5" の 20GB の HDD をマウントできた。（スピンアップするとうるさいんだ、これが。）

見ると

  • 一生懸命 NTFS をマウントしようとしていたが、実は FAT32 だった。
  • てっきり2ドライブ構成だと思っていたが、実は 1ドライブ構成だった。

みたい。あー。そう言えばパーティション切り直すのが面倒（IBM のリカバリ領域とかあってちょっともったいないんだけど）でそのまま使っていたような気がしてきた。NTFS にしなかったのはまだあまり Windows 2000 を信用してなくて、いざというとき DOS や Win9x からの復旧を考えてのことだったのかも。

てゆーかここにあるに違いないと思っていたアナム＆マキの mp3 はなかった。間違って消しちゃったのか。。。

シャチハタ QR コードスタンプ

シャチハタが「QRコードスタンプ」 （ITmeaid）

実は使い道がよく分かっていない QR コード。でも面白そうだとは思うんだな、これが。

About

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