リビングPC的なもの(Debian Lenny)にRemedieインストール。(また)
% sudo apt-get install perl perl-modules git-core build-essential libxml2 libxml2-dev libxml-atom-perl libxml-feed-perl libxml-libxml-common-perl libxml-libxml-perl libxml-perl libxml-rss-perl libxml-xpath-perl libyaml-perl libyaml-syck-perl libsqlite3-dev sqlite3 libnet-ssleay-perl
% cd /var/www
% git clone git://github.com/miyagawa/remedie.git
% cd remedie
% sudo chown -R komagata:komagata blib pm_to_blib
% perl -MCPAN -e shell
cpan> install Bundle::CPAN
cpan> install Http::Engine
cpan> install MooseX::ConfigFromFile
cpan> install MooseX::Getopt
% env PERL_MM_USE_DEFAULT=1 cpan -i .
こちらを参考にinitファイルを前より少しだけちゃんと書く。
% sudo vi /etc/init.d/remedie
#!/bin/sh
### BEGIN INIT INFO
# Provides: remedie
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start remedie at boot time
# Description: Enable service provided by remedie.
### END INIT INFO
case $1 in
start)
cd /var/www/remedie/bin
sudo -u komagata env HOME=/home/komagata nohup perl ./remedie-server.pl > /dev/null 2>&1 &
;;
esac
% sudo chmod 755 /etc/init.d/remedie
% sudo update-rc.d remedie defaults 99 1
今回、リバースプロクシはnginxを使ってみました。
% sudo apt-get install nginx
% sudo vi /etc/nginx/sites-available/remedie
server {
listen 80;
server_name remedie;
location / { proxy_pass http://localhost:10010; }
}
% sudo ln -s /etc/nginx/sites-enable/remedie /etc/nginx/sites-available/remedie
Debian apacheの作法“a2ensite”のnginx版はあるんですかね?わからないので普通にシンボリックリンク張りました。(敗北)
ヒャッハー!
動画もジャンルの細分化/深化が進んだのでこういうの必要ですよね。
![]() |
|
闘うプログラマー新装版が出たそうです。一時絶版してたので図書館とかでしか手に入り辛かったんですがこれで解決。
新しいプログラミングパラダイムや方法論、学術論も好きですが、こういう泥臭い実録プロジェクト系も大好きです。
“プログラマーのスポーツはスカッシュ”という偏見を僕に植え付けてくれた本でもあります。
WindowsXPの安定性もこいつらのカーネルのおかげ。いや、スカッシュのおかげ。
Mac開発秘話系では同じく泥臭めのレボリューション・イン・ザ・バレーがおすすめ。
どっちも華やかなイノベーションとやらの陰では、
「おい、この腐った変数名を付けた馬鹿はどこだ!」
とか
「このバグを直すまで帰れない」
とかいったみみっちぃ出来事が満載なんですね。
参照:会社のブログがCommon Lispで書かれたAllegroServeになったので更新するにはCommon Lispが書ける必要がある。
g000001さんに初心者におすすめの環境を教えてもらったので設定しました。
どうやらLispは起源が古いのでUNIX文化とはかなり違うらしい。そこがとても面白く感じました。
- 時間の起点が1900年
- 言語というより環境(イメージ的にはLispというOSをUNIX上で動かしてそれと通信する感じ?)
処理系のインストール
Lispの実装(処理系)はたくさんあるようですが、SBCLというのがネイティブバイナリを実行するので速く、オープンソースで人気があるそうです。(ポータブルなバイトコードを実行するCLISPというのも人気があるみたいです)
% port variants sbcl
sbcl has the variants:
powerpc: Platform variant, do not select manually
darwin_8_i386: Platform variant, do not select manually
darwin_9_i386: Platform variant, do not select manually
html: Builds the SBCL and ASDF documentation as HTML
threads: enable threaded runtime
% sudo port install sbcl +threads +html
エディタのインストール
“郷に入っては郷に従え”ということでCarbon Emacsをインストールしました。zshやmacがemacs key bindなので移動とかは大丈夫なんですが、windowとか、bufferとか殆ど忘れてたので入門GNU Emacs 第2版をチラ見しながらやっていきます。(第3版が出てるみたいですが、僕が持ってるのは第2版・・・)
Lisp用のモードをインストール
SLIMEという単なるLispモード以上に処理系のプロセスに接続してやりとりしたり、デバッガついてたり、激甘スイーツ環境を提供してくれるものがあると教わったので入れました。
% port variants slime
slime has the variants:
app: Build SLIME against editors/emacs-app
sbcl: Require lang/sbcl for SLIME
openmcl: Require lang/openmcl for SLIME
clisp: Require lang/clisp for SLIME
% sudo port install slime +sbcl
処理系の選択は別としてappは何だろうなぁ。
“インストール後に.emacsにコレ貼付けろ”と表示されるのでそのまま張付け。
;; h key
(global-set-key [(control ?h)] 'delete-backward-char)
;; slime
(setq load-path (cons "/opt/local/share/emacs/site-lisp/slime" load-path))
(require 'slime-autoloads)
(setq slime-lisp-implementations
`((sbcl ("/opt/local/bin/sbcl"))
(clisp ("/opt/local/bin/clisp"))))
(add-hook 'lisp-mode-hook
(lambda ()
(cond ((not (featurep 'slime))
(require 'slime)
(normal-mode)))))
(eval-after-load "slime"
'(slime-setup '(slime-fancy slime-banner)))
;; japanese
(setq slime-net-coding-system 'utf-8-unix)
(最初の行はC-hがヘルプで糞うざい対策、最後のは日本語用設定)
EmacsでM-x slimeで起動。あぁこれが噂の・・・というアニメーションでプロンプトが出現。
REPLが動いた。(上にSBCL:とあるのはSBCLとソケット通信してるみたいです。)
マニュアルのインストール
% sudo port install lisp-hyperspec
仕様書兼マニュアルはHyperSpecというそうです。 C-c C-d hでマニュアルが。
しかし、これは俺の中でのLispじゃない!みんな何か適当なバッファに落書きみたいにコードを書いて適当に評価してたはず。
C-M-xでカーソルを含むトップレベルのフォームを評価してミニバッファに出してくれるらしい。
そうそう、こういう感じ。
疲れたのでAllegroServeまで行かなかった。
参照:Linux, Mac, Windowsでの共有ライブラリの作り方/使い方が知りたくて調べてたんですが、どういうキーワードで探せば良いのかすらわからず、苦戦したのでメモ。
Linux
- 実行ファイルフォーマット
- ELF (Executable and Linkable Format)
- 静的ライブラリ
- .a
- 動的ライブラリ
- .so
Mac OS X
- 実行ファイルフォーマット
- Mach-O
- 静的ライブラリ
- .a
- 動的ライブラリ
- .dylib
Windows
- 実行ファイルフォーマット
- PE/COFF (Portable Executable/Common Object File Format)
- 静的ライブラリ
- .lib
- 動的ライブラリ
- .dll
名前が分かったら検索すれば勉強になるサイトが沢山見つかった。
本だと各プラットフォーム毎に大体6000円以上するような分厚いやつの一章だけだったりするので辛い。立ち読みでキーワードを拾って来て検索しました。
Linuxの情報が圧倒的に多くて、MacとWindowsは見つけ辛かった。
参考:
内容符号化 (Content-Encoding) に問題があります不正または不明な形式で圧縮されているため、ページを表示できません。 この問題を Web サイトの管理者に報告してください。
Firefoxで上記の様な症状が出るという報告を受けたのでちょっと調べてみました。
参考:もじら組フォーラム [One Topic All View / Re: 本当に、問題が全くないサイト?
Apache1.3系のmod_gzipとFirefox3.xのRangeヘッダー対応関係の話らしい。たぶん、gzipで圧縮されたByte数とFxにキャッシュされたByte数が違うのにRangeで間違った場所から読み始めるからおかしくなるんだと思う。
Range使わなきゃいいかなということで、レンタルサーバーの.htaccessに下記を書いたら直った。
Header set Accept-Ranges none
ちゃんと追ってないので根本的にサーバーとクライアントどっちが悪いのか分かってません。
正しい答えをお持ちの方は情報いただけるとありがたいです!
Webアプリ開発にはデザイナーとプログラマーの協力が必要だ。 開発に関わる人数が増えてもスケールするやり方が必要だ。
目標
- デザイナーは自分のWebアプリを自分でビルドできるべきだ。
- プログラマーはデザイナーが自分のWebアプリをビルドするのに黒い画面(ターミナル)を使わせてはいけない。
- CMSだけで全機能をカバーできないWebアプリはバージョン管理されるべきだ。
現状
- 大半のデザイナーは黒い画面を使わない。
- 大半のデザイナーはAdobe Dreamweaverを使ってマークアップする。
- Macを使わないWebデザイナーも多い。
- 実質、デザイナーにとって一番使い易いバージョン管理システムのクライアントはDreamweaverである。
やるべきこと
- デザイナーが一人で構築できるWindowsとSubversionを使った開発環境とそのマニュアルを作る。
- ビルドに必要な各種コマンドを黒い画面を使わずに実行する方法を作る。
問題点
- Windows上でRails+SSLを簡単に使う方法
- データベースの扱い
- Adobe Dreamweaverがかなり高価
- プロジェクト固有の設定/アプリ
- ターミナルを使わないコマンド実行
1はこちらの記事のコードで行けそうです。
参照:SSL 上で WEBrick を動かす – Rails で行こう!
4はinstall.rbとかを頑張って作る。
5はDreamweaver拡張でコマンドを実行する方法を覚えたのでそれを使う。(別途バッチファイルかrubyのファイルを用意した方がよさそう)
2,3は・・・うーん・・・。
会社(アクトインディ)ではRedmineのチケットとSkypeで仕事が進んでいくので、週1回、1時間、無理矢理理由を付けて集まってミーティングをしています。
最初はコードレビューをしていたんですが、
「Redmineにコードレビュープラグイン入れたからいらなくね?」
ってことで何でもいいので
“誰もがダウンロードできる、動くプログラム”
を持ち回りで作って発表しようということになりました。そういうのを何て呼んだらいいのかわかりませんが、取りあえず“プログラムプレゼンテーション”ということにしました。
1回目:
cocoa*life – Apple Push Notification Serviceを利用した、iPhone クライアントと、Rubyによるサーバの作成。
Objective-Cがgccでコンパイルできることや、cとかと一緒に使える事や、面白いシンタックスをしてることなんて全然知らなかったのでやりたくなりました。モバイルにもWebアプリが絡むと、俄然興味が湧きます。
2回目:
Talkedbun – 日本語テキストトゥースピーチサーバー – p0t
mac版もフリーになってくれると嬉しいなあ。
やってみて感じたんですが、
- 他人にダウンロードされて実行される
- 会社名義じゃなくて自分名義(会社はあくまでリンクをはったりするだけw)
だと逆に大変。
ダウンロード出来る状態だとソースとかごまかしが効かないし、自分名義だと「給料分クオリティ出してりゃいいだろう」という妥協もし辛い・・・。
やってる方としても大変ですが、これは面白い勉強法だなあと思いました。
URLにひらがなを指定すると、そのひらがなの音声がmp3で得られるwebサーバーを作りました。
komagata’s talkedbun at master – GitHub
インストール/起動
$ sudo gem install komagata-talkedbun -s http://gems.github.com
$ talkedbun
http://localhost:4567/ にwebサーバーが立ち上がります。
例えば、http://localhost:4567/うえからくるぞ、きをつけろ! にアクセスするとmp3が開く、という感じです。
SayKana – Mac用音声合成プログラムを使っていて、Mac専用です。
しかも、ffmpegにパスが通っている事を要求するなど、お手軽感がいまいちです。
AquesTalkのWin版dllは組み込むのもFreeなので、本当は
“Windows上でaquestalkのdllとmecabとffmpegを組み込んでRuby/DLを使ってアクセスする”
というのが本目的だったんですが、期限が明日までなので時既に時間切れ。
仕事でもデプロイ/リリースは面倒な作業ですが、今回はパッケージングも面倒な作業だと思い知りました。
しかし、道具を使う側にとっては重要な部分なので気を配って行きたい。
WAF の設計方法 – 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 – subtechWeb + App は大人気 Sinatora もそういう考えっぽいですが (誤解しているかもしれません)、Web というのが App へのインターフェイスの一つにすぎず、例えば CLI + App という組み合せもあるし、Desktop GUI + App という組み合せも考慮されています。ロジックのテストはしやすそうでいいですね。でも、もっと富豪的でもおこられないんじゃないかなぁとも思うのです。
WebApp の場合、Web (というよりHTTP) を唯一のインターフェイスとして提供し、例えばCLIだろうがGUIだろうが、HTTP を仲介するようにします。HTTP + App, CLI→ HTTP + App, GUI→ HTTP + App。これは例えばGAEだと、そもそもこういう方法をとることしかできません。Cron もHTTPで特定のURLが叩かれるだけです。ユーザ向けAPIみたいなのがだいたいのサービスでありますが、それをアプリケーションのオーナーまで権限を拡張しているような感じです。
読んでいてすごく面白かったです。
僕も先日、CLIアプリのWebインターフェースを作っている途中で、「ん?」と引っかかっていた部分があったんですが、id:cho45さんのエントリーを見て氷解しました。
require 'sinatra/base'
# Fooがアプリ名だと思ってください
class Foo::Web < Sinatra::Base
get '/run' do
# code...
end
end
rack(map)もsinatraもこう書くのでrouterとAppの結合が強く、Appを別クラスにして委譲したくなる。
require 'sinatra/base'
# Fooがアプリ名だと思ってください
class Foo::Web < Sinatra::Base
get '/run' do
Foo::App.run
end
end
class Foo:App
def self.run
# code...
end
end
こうすればCLIも同じ様に書けて便利だ!
require 'sinatra/base'
# Fooがアプリ名だと思ってください
class Foo::Web < Sinatra::Base
get '/run' do
Foo::App.run
end
end
class Foo::CLI
def run
Foo::App.run
end
end
class Foo::App
def self.run
# code...
end
end
うんうん。で、gemでのfoo/bin/foo(コマンド)を作ろうとして、「ん?」となった。
foo/bin/foo:
#!/usr/bin/env ruby
$:.unshift File.join(File.dirname(__FILE__), '..', 'lib')
require 'foo'
Foo::......
あれ?
httpdを立ち上げるコマンドにすればいいのか、CLIを呼び出すコマンドにすればいいのかどっちだろう・・・?
food(foo daemon)とfooの両方をbinに用意する?
んーなんだかなー・・・。
となっていたのです。
「Webだけでいいじゃん」
というのは目から鱗。Webからのテストを充実させれば問題無し!
ただ、「微妙なところ」として上げられている中でも「テストが遅くなりがち」というところは凄く気になっています。
mockもやりすぎると品質が落ちるし、かといって、継続的インテグレーションサーバーを使ってテストしてもらうのは面倒だし、品質の高いままサクサクできる方法がないかと悩んでいます。