社内向けにモノは一応できてるけど、網羅的なエントリを書くほどでもないので、自分向けメモに permalink を与える試み。だいたいの概要が書いてあるので、あとはリンク先をたどってちょっと手を動かせば思い出せるんじゃないかな。

まとめ

すでに Google Apps を利用しているなら 24/7 で稼動する PaaS があるのと同義
認証部分を Google Apps 側に丸投げできるので社内向け簡易アプリなどを用意するのに適している
- しかもスマホ対応済み
しかも Google Apps のデータは作業者も履歴も全部残せる¹
言語は JavaScript のようなものなので、Web 系の人と親和性が高い
管理画面をゼロから作る代わりに Spreadsheet を使うと他の業務と親和性が高いのでよさげ
- 例えば VBA で実現していたようなものを Apps Script に置き換えると引き継ぎしやすいアプリに仕立てられそう
Node.jsのツールチェインはあってもなくてもいいけど、他の普通の開発に近づける（DVCS + ITS）ためにはあった方がよい

Apps Scriptの特徴

Google Apps 上で動く、JavaScript を基本の構文として独自の Apps 用オブジェクトを持つ言語で記述する
保存できるのは .gs コード（スクリプトファイル）と HTML
- したがって asset は cdn でまかなう
Drive のドキュメント内で実行するスクリプトはもちろん、Web アプリや Web API として公開もできる
triggerという仕組みで自動実行できる
- time based ( cron のようなもの ) , event based な trigger がある
container bound script と standalone script がある

Apps Scriptの種類

Container Bound Script
- ドキュメントに紐付く
Standalone Script
- Drive上に独立して存在する

Contianer Bound の方が入りは楽。（Triggerに対応する function が組み込みであるとか。）Standalone の方がエンジニアリング的な扱いは楽。

Standalone Script は Drive 上に独立して存在するので Drive API を通じてアクセス、管理できる。これを利用することで手元でバージョン管理することができる。一方で Trigger が Programmable になってしまうので扱いがちょっとだけ手間だが、分かってしまえばそれほど面倒ではない。

Standalone Scriptの開発手法

エディタとしては Google Apps 上の Script Editor が恐らくいちばんマシだが、動的な変数などに対しては補完が効かないので、ある程度基本的な部分ができたら結局動かしながらテストするしかない。

local <-> remoteの転送

いくつかあるが、

soundTricker/gas-manager

がいちばんマシ。

gas init で

認証情報の取得
remote にあるファイルの一覧を作成して sync できるように準備を行う
- remoteでファイルを増やした場合はもう一度 gas init するのかな？

なぜか remote .gs を local .js に置き換える機能があるが、これは拡張子の設定を自由にできないエディタを使って開発するための配慮かな。

テスト

npm 上の以下を組み合わせたうえでブラウザ上で所定の function を実行するのが今のところよさげ。Qiita 上の記事といい、こうしたツールといい、実は Google Apps Script は日本人の方が盛り上がっているのか。

codegs は google apps script 用の browserify のようなもの。

これらを組み合わせて GAS 上で実行可能な spec ファイルを作り、gas upload したのち手でテストを実行する。結果は gas-console で確認する。この作業がすべて CLI で完結するとかなり快適なのだが、たぶん難しいのでいったんこれで形にしておく。

CoffeeScript

local で coffee -> js 変換後のコードを上げれば普通に動く。別にタスクランナーとか使わなくてもこんな感じで大丈夫。

秘密情報

環境変数をセットすることはできないが、Script や Spreadsheet などの Property として値を保存することができる。これを利用すればコードの中に生々しく認証情報などを保存せずにすむ。

Programmable Trigger

TriggerBuilder で trigger を特定のドキュメントに対して付与する。実行する function の名前を与える形なので、引数を与えることはたぶんできない。

ライブラリ

Google Apps Script 用に公開されているライブラリはスクリプトエディタ上で追加することができる。

Google Apps Script Examples

※ この部分を CLI で自動化することは恐らくできない。

GS は JavaScript との互換性がどの程度のものなのかイマイチよく分からない（なんとなく ES5 は動きそう）ので、UnderscoreGS は便利かも。

Webアプリとしてできること

アクセス権限は Drive と同様に設定できる（超重要！）
GET と POST の両方を受け付ける
- doGet(), doPost() のみ
- JSON API のようなものを作れる
- ストレージは Spreadsheet などを使う²
HTML も返せるので、例えば SPA のようなものを作ることもできる

deploy

Google Apps 上でいちいち deploy をしないとアプリ側は更新されない。

版管理でバージョンを刻み、deploy でそのバージョンを指定する。これが済まないとアプリ側は更新されない。（バージョンを変えても URL は変わらない）

生成される HTML がすごい。ユーザー認証を通過した人にだけ表示される HTML を JavaScript を通じて提供するためか。よくこんな仕組み実現したな。

API にすると API ID しか当たらないので、何かクライアント側もただのウェブアプリのようにはできないっぽい。むしろただの JSON API のエンドポイントに使いたいだけなら Web アプリとして deploy した方がいいのか？

staging はプロジェクトをコピーする。コピーするとバージョン情報と deploy の情報のないプロジェクトができあがる。

CDN

Google Apps Script では HTML 以外の asset を置くことができない。そのために HTML も CSS もライブラリ用の JS も concat するというアプローチがあるが、全部 CDN という選択肢もありそう。

もうなんでもかんでも CDN で動かせるみたい。

クライアントアプリとしてできること

FetchUrlApp サービスで HTTP リクエストを飛ばせる
- 名前に反して POST もできる
- これを使って AWS S3 を扱うライブラリもサードパーティーだが存在する
Mail は Google Apps の MailApp を叩けば ok

add-on

「アドオン」は古くて「ライブラリ」として公開がイマドキらしい。

今のところの感想

Node.js のツールチェインは使っているが結局実行は Google Apps 上で行うので、そこまでサクサク開発できない。

うちのネットワーク環境の問題なのか、Script Property への値の保存時にやたらと IO Error が起きたり、gas upload 時に基本的な文法エラーで Drive 上に script が保存できない（しかもエラーの意味がよく分からない）とか、割と扱いにくいことは起きる。³

少なくとも大規模なアプリを作るのにはやはり向いていないと思う。規模をでかくするなら API 化してクライアント側サーバ側別々に開発するのがいいと思う（サーバ側のスクリプトのテストを自動化しにくいので）けど、そこまで Google Apps でやるの？という気がしちゃう。

HTML を組んで Web アプリを作ることもできるが、イマドキの Web アプリ開発のサクサク感からはほど遠い感じがするので、踏み込むかどうかは思案のしどころ。Apps の画面を活かしつつやるのがお手頃感を残しつつゼロベース開発を避けてコストダウンできるポイントじゃないかなーという気がしている。

今後は Electron と組み合わせる、みたいなのができるとギョウミーな文脈ではそれなりに便利なんじゃないかなーなんてことを妄想していたりする。そこまで本格的なことを今の環境でやるかどうかは分からないけど。

参考

こういうのゼロから作ると意外に手間 ↩
あるいは他のAPIを使うこともできるが、そこまでやるならGoogleAppsでなくてもいいような… ↩
文法エラーがあると保存すらできないっていう設計はどうなんだ ↩

phpfarmを使って複数バージョンのPHPをインストール

Oct 31, 2010

先日 LL を複数入れる話をまとめて、なんで PHP にないんだよという話を書いたらツッコミをいただきました。その名も phpfarm なんと本家にありました^^;

使い方

必要なものは

フツーにコンパイルできる環境
Subversion
bash

です。以下のように使います。

$ svn co http://svn.php.net/repository/pear/ci/phpfarm/trunk/ phpfarm
$ cd phpfarm/src
$ ./compile.sh 入れたいバージョン

なんて簡単。

やってくれること

source の取得、展開、コンパイル
コンパイルオプションを設定する方法
- 基本は options.sh で、バージョン毎に cutstom-options-{version}.sh を用意すればよい
指定のディレクトリへの CLI SAPI バイナリへの link の集約
カスタム php.ini を準備する方法
- 基本は custom-php.php で、同様に custom-php-{version}.ini を用意

やってくれないこと

rvm と違ってできないことがたくさんあります。

インストール可能なバージョンの確認
- http://museum.php.net/php$vmajor/php-$version.tar.bz2 から取得してくるのでここで指定可能なバージョンがインストールできます。
インストール済みバイナリを切り替えて指定のバージョンを起動する
httpd.conf 周り

特に 3 が面倒になるかなぁという感じですね。

一応 CLI バイナリは一カ所に集まっているので SAPI によらず動かせるコードを書くようにしていれば、複数バージョンでのテストなどもなんとか動かせそうに思います。

Apache の mod_php については複数の mod_php を LoadModule するのはできないような気がするので、仮想マシンを PHP の数だけ立てるような感じにするか、いちいち httpd.conf を書き換えて Apache を再起動する切り替えツールを自前で書くしかないんじゃないでしょうか。他の LL に比べるとだいぶ面倒な感じになりますね。

※ ちなみに自分が以前 PHP 4 から 5 への移行を行った際は複数のサーバを立てて NFS でコードを共有して¹ テストしました。その都度再起動しないのであれば OS 丸ごと増やすのが楽なのかなと思います。

入れ終わった様子

phpfarm ROOT
|-- inst
|   |-- bin
|   |   |-- php-4.4.9        -> ../inst/php-4.4.9/bin/php
|   |   |-- php-5.3.3        -> ../inst/php-5.3.3/bin/php
|   |   |-- php-cgi-5.3.3    -> ../inst/php-5.3.3/bin/php-cgi
|   |   |-- php-config-5.3.3 -> ../inst/php-5.3.3/bin/php-config
|   |   |-- phpize-5.3.3     -> ../inst/php-5.3.3/bin/phpize
|   |   `-- pyrus-5.3.3      -> ../inst/php-5.3.3/bin/pyrus
|   |-- php-4.4.9
|   |   |-- bin
|   |   |-- include
|   |   |-- lib
|   |   `-- man
|   `-- php-5.3.3
|       |-- bin
|       |-- include
|       |-- lib
|       |-- man
|       `-- pear
`-- src
    |-- bzips
    |-- php-4.4.9
    `-- php-5.3.3

これで、phpfarm の inst/bin に PATH が通っていれば一応複数バージョンを使い分けることができる道理です。

pear, pecl 周り

pear ついては make で入れる方法が提供されるような雰囲気のファイルが src/php-{version}/pear 以下にあるのですが、Makefile がないので機能しません。手で適当に go-pear で入れるのが正解のようです。

試しに上の状態で 4.4.9 用と 5.3.3 用に pear を入れてみましたが、4.4.9 は pear list を出すだけでなんかすごい量のエラーのような警告のようなメッセージが出て、5.3.3 は go-pear でのインストールの段階で大量の deprecated の警告が出ます。

なんというか、pear, pecl までこなれていないうえに、PHP の過渡期っぷりを感じてしまいます。5.1, 5.2 辺りでお茶を濁すならわざわざ自分でコンパイルしなくても各種ディストリビューションのバイナリパッケージ使った方が簡単ですしねぇ。うーん、どうしたものやら。

まとめ

クセがつかめれば、できることは制限されますが OS 丸ごと増やすよりはまだ楽かもしれません。とは言え今ある phpfarm の sh script だけだと不便なのは間違いないので、自分用のツールを書き足す工夫は必要かと思います。

自分の場合はやっぱり Ruby で phpfarm wrapper 作るべきなんでしょうかねぇ。

キャッシュやセッションなどはもちろん共有しない ↩

PostgreSQL 8.1 以降、ユーザーとかグループとか言わない

Oct 31, 2007

DBMS

おっつ。

データベースロールと権限

ロールの概念には、"ユーザ"という概念と"グループ"という概念が含まれます。 PostgreSQLバージョン8.1より前まででは、ユーザとグループは異なる種類の実体として扱われていました。しかし、現在ではロールしか存在しません。すべてのロールは、ユーザとして、グループとして、またはその両方として動作することができます。

おっつ。

という具合に分かれるらしい。

リストアしようとしたら role がないと言われて一瞬 ( ゜д゜) てなたよ。

go-pear.org なんてねぇ！

Oct 31, 2007

ドメインごとありゃしねぇ。

site:pear.php.net go-pear - Google 検索

つーことで

http://pear.php.net/go-pear

が正解。

そーーーーーーーいえば。大昔はこの URL だったような気がしてきましたよ？

つかさ。アナウンスねーの？アナウンス！なんか

PEAR :: Doc Bug #12250 :: go-pear.org domain is expired..

こんな報告が上がっているのがついこの間なのでもしかしたら中の人は何か頑張ってて、そのうちしれっとドメインも戻ってくるのかもしれないけど、だからと言って現時点で何のアナウンスもないのってどうなの？ pukiwiki.org がドメイン落としたのはまだ失笑程度で済むけど、Pear がこういうことやってるのはどうなんだ。マニュアルにはしっかり go-pear.org って書いてあるんだからさ。なんか対処してくんないとみんな困るでしょ？

ガッカリだよ！

旧Mac → Windows 逆Switchで気をつけるべきポイント

Oct 31, 2006

声高に言われないだけで、実はこの方向で移行している人はかなりの数に上るはず。とりあえず両刀遣いとして今のところ分かっているポイントをここにメモしておこう。

※ 例によって嘘、間違い、過不足はツッコミよろ、ということで。

OS の操作性の違いは考えないこととする: それ言っちゃったらキリないし、普通の人は OS ではなくアプリを使っているので、各種設定方法はともかく「作業」を開始するまでならなんとかなる。
両方で動いている大型アプリについても気にしない: Office, Adobe ものなど

では気にするところはどこかというと。

絶対にアップデートさせる: 温室育ちの Mac 使い¹はセキュリティに鈍感なので、かなり気合いを入れて教育する。そのうえで問答無用で自動更新にしちゃう。自動更新の適用で問題が出たら出たとき考える。（抜けない更新で地雷を踏んだら諦める。）
ファイル名の制限: Windows の方がファイル名に使えない文字の制限が多い。文字数の制限は緩和されるが、/ とか ? とか不用意に使っている場合はデータの移行ができないので注意が必要。
メディアのフォーマットの違い: Mac フォーマットのものは追加のソフトがない限り読めない。Mac では Windows フォーマットを読めるケースがほとんどなので、あとになってあれもこれも読めないと気づくケースが出てきそう。
Finder と Explorer での挙動の違い: いちばんびっくりするのは「上書き」と「入れ替え」の違いかな。まぁこれは Finder より Explorer の方がコンピュータ的には自然だし、恐らく少々の戸惑い程度で克服できるだろう。Windows 使いが見落としがちなのは「ラベル」機能かな？個人的には一切使ってないけど、バリバリにラベルやアイコンのカスタマイズをしているケースがよくあるので、それに依存してファイルやフォルダの分類を行っている場合、問題になるはず。
テキストデータの扱い: 改行コードと機種依存文字の問題。温室育ちの Mac 使いはこの辺に無頓着なので問題が出やすいかも。改行コードについてはアプリ側で吸収あるいは変換できれば問題ないかもしれないけど。
メールデータの移行: EUDORA とか Netscape Mail 使ってます、という場合は特に困らない。やっかいなのは Outlook Express を使っている場合。²
アプリのインストール／アンインストールの手順の違い: Windows は Mac みたいに要らなかったら捨ててくれというわけにはいかないので、あまりスキルはないけどいじるのが好き、というタイプには注意。
設定方法が煩雑なのでデフォルトの設定が大事: 多くの場合、Mac よりも Windows の方が設定変更の際の手順が多い。そこであとからユーザーが設定を変更しなければいけなくなるような状況を極力減らしておくことが肝要。
Mac 独自ツールへの依存度の確認: AppleScript バリバリ使ってますとか、grep, sed, awk, Perl など Mac 独自の UI がかぶってるものに強く依存してますとか、そういう場合の対処はかなり面倒。逆にこういうのがない場合の移行はそれなりにスムーズにイケるんじゃなかろうか。個人が個人用に作ってた小物ツールは無視。お仕事で使いたいなら認知されるようにしておかないとあとあと苦労するかもしれませんよ、というだけの話だと思う。³

どれも個人での逆 Switch ではたいして問題にならないが、数が多いとそれなりの問題になるだろうというところ。特にファイル名やメディアの問題は後手に回ると不必要なコストが発生してしまう。

Mac から入って Mac しか知らない人。今はあんまりこういう人いないと思うけど。 ↩
ここは確認不足。Mac 版 OE のデータって、Win 版 OE で読めるものなのかな？たぶん読めないよなぁ。 ↩
業務全体がそれに依存している場合は当然考慮されるべきだけども、それが表に出てこず、個人に帰属するようになっていたとしたら、それはその仕事の回し方が間違ってるはず。 ↩

ゼンドジャパンの規約とか

Oct 31, 2005

ゼンド・ジャパン株式会社技術情報コンテンツ

vi の情報がちまちま出てくるのはなんだ、IDE 売る気ないのか？(笑) しかし PEARコーディング規約のあのコメントブロックはやだなぁ。コメントで AA で四角を書くのはやめようよ。phpdoc あんだからそっちから生成すればいいじゃん。

以上、Planet PHP Japan からゼンド・ジャパン株式会社技術情報コンテンツ:phpspot開発日誌を経由して。しかし Planet PHP Japan の、各サイトのタイトルだけおかしいのってなんだろうか。

Perl も DateTime なのか

Oct 31, 2005

Tool

Ruby の DateTime クラスと基本的には同じ考え方してんだろうな。便利に違いない。

多様な安否情報の提供と digital divide

Oct 31, 2004

ちょっとまだまとまりそうにないんだけど。NHKはいったい何がしたかったのかから続く一連のもの（高木浩光＠茨城県つくば市の日記）を読んで。

NHK やサービス提供者の理解度の低さは問題として指摘すべきだと思う。ただもう一方で問題にしなくちゃいけないのは安否情報をより安全に、より多くのチャンネルで提供できるようにすべき、ということではないのかとも思う。これは前回公共性の高い組織の広報で触れたこととも通じてるんだけど、個人情報の話にする以前に、より多様な安否の確認方法がほしいということである。

例えば携帯。通話は難しいかもしれないが、原理的にはインターネットの方が接続の安定しない状況では有用なはずである。DoCoMo などの特定のベンダーに依らない、安否情報確認システムを国の予算で用意しておくことは技術的にはそれほど難しくないように思う。¹携帯なら端末を特定できるし、比較的安全に安否情報を、かなり1対1に近い形で提供できると思う。²

ただ別なところに大きな問題がある。デジタルデバイドだ。すべての人間が携帯端末で情報のやり取りを行えるわけではない。普段から使っている人間でなければ緊急時にはまず役に立たない。電話としての利用はなんとかなる、というレベルの人間が緊急時に安否情報の確認をインターネット経由で行うのはかなり困難だろう。

じゃあということで、端末に自治体の防災無線を利用するのはどうだろう？防災無線を自治体間、自治体-国間の緊急情報のやりとりだけでなく、市民の安全確認のチャンネルとして使えないかな、ということなんだけど、自分は無線は完全に素人なので、インターネットとの接続など細かい話はまったく分からない。単に「そこにあって双方向に情報のやりとりができるモノ」ということで浮かんだだけだ。たぶん様々な問題はあると思う。安全性という意味では被災地の人間の情報提供はルーズに、被災地外の人間による情報の引き出しに認証を掛ける、という方向である程度確保できると思う。簡単なところでは身分証明書の提示と利用の記録をとる、というところか。ただこの方法は海外からは利用しにくいので、また別なゲートウェイが必要だ。

防災無線だなんて何ゆーとんじゃ、ということであれば、デジタル放送のラジオなんかが使えないだろうか？デジタル放送と言ってもテレビほどの大電流が必要なわけでなし、電池駆動できるよね？（興味はあるけど確認すらしてない。）これなら一人一人持つことができるし、データのやり取りはある程度可能だと思う。ただここに個人の安否情報を載せるのはどうやるのか想像がつかない。

書き連ねてようやくまとまってきたが、問題は

被災者の安否情報をどうやって集積するか
- できるだけ素早く、なおかつ被災者のスキルやデジタルデバイドに影響を受けない方法がよいのではないか
- その預け先はどうやって信用するのか
- 集積しないという選択肢はもちろんアリ。ただその場合は双方にそれなりの資源とスキルが要ると思うのでここではとりあえず無視。

集まった安否情報をどうやって配信するのか
- 負荷の集中や単一回線への依存によるストップは避けたい（既存の電話網、携帯電話の通話網の限界に引っ張られたくない）
- 認証の必要のないレベルならできるだけ多くのチャンネルで配信できた方がよいと思う
- 個人情報のレベルでは情報の引き出しに認証を掛けるべきだと思うがどうやって認証を掛けるのか
- もう一つ、認証が必要な情報とそうでない情報に明確な基準が必要
- 国内だけでなく世界的に配信できる必要がある
  - 海外在住の日本人に対してだけでなく、国内在住の外国人の家族が利用する場合にも対応できる必要がある

という辺りなんだろうか。なんか抜けありまくりそうな気がするんだけど。まーでもどっちにしろ一度単純化しておかないと抜けの確認もできないし話を展開しにくいし、今回はこのままいこう。

ふと思ったが、ココセコムじゃないけど、こうした安否情報ってビジネスとして成り立たないのかな。例えば家族で契約しておくと海外を含めた遠隔地でもとにかく安否の確認ができるってシステム。そのために Skype とか自前のシステムとかとにかくいろんな方法を確保してできるだけ迅速に確認できるようにサービス提供者は頑張る。誤解を恐れずに言えば安否の確認てのは身内のエゴ的なものでもあるわけで、保険と同じようにビジネスとしてソリューションを提供するってのは十分にアリじゃないだろうか。これは国とかさっきまで展開していたやたらと器のでかい話でもないし、電話やメールによる1対1の確認でもない、alternative な選択肢であり、今回の話の主旨ともなんら矛盾しない。うん、悪くないな。

問題はシステムの構築、運用、維持のコストがでかそうだから最初に国とか器のでかい話を思いついたのであって、これがビジネスとしてペイするレベルならビジネスでも十分な話だ。これなら情報の集積先をどうやって信用するか、なんて辺りもスムーズに解決できる。契約があるんだから話は簡単。

でもなぁ、なんかこう釈然としないのはなんでだろう。視点が公共サービス³寄りなのは、やはり災害弱者が取り残される可能性がでかいと直感的に感じるからかな。保険もそうだけど、「存在を知らなければ利用できないサービス」ってのは本当の緊急時にどれだけ役に立つのだろうという素朴な疑問が残る。もちろん今の時代に無防備に生きている方が悪いのさという指摘はしごくまっとうだし、少なくとも労働者人口にカウントされている人間はその指摘を噛み締めておく必要があると思う。でも被災者は労働者人口にカウントされる人ばかりじゃないから。そういう人たちをどれだけフォローできるかが公共サービスの価値だと思うんだよな。