2011/12/28

CentOS6.2ではfusesmbできない?

CentOS5.x時代は、fusesmbをrpmforge辺から投入していたので、
6.2でもと思ってみたら...そもそもfusesmbが6.xに対応できていないらしい。
仕方ないので、cifsを試食中。
yum install samba-client cifs-utils
mount -t cifs -o user=foo,password=bar //hostname/SharedDocs /mnt/smb
といった感じでマウントする。
IOバッファサイズは、rsize(2048〜130048) と wsize(〜57344)オプションで調整する。
詳しくは、本家を参照。
後は、以前にUbuntuで遭遇した事態に陥らないことを願う。

2011/12/26

CentOS6.2でSoftwareRAID(RAID1)にブートローダー投入失敗

物理サーバーにもCentOS6.2を導入することになったので、
KVM上でCentOS6.2を単体ベアメタル構築した時には利用しなかったSoftwareRAIDをRAID1で組んだ。
この際、ブートローダーをanaconda上からmd*デバイスに導入できるような雰囲気だった。
けれど...案の定、ダメ。
仕方なく、Rescue modeからgrub構築した話。
とりあえず、インストールメディアからRescue modeに入って、
shellを起動する。
grub
grub> device (hd0) /dev/sda
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd1) /dev/sdb
grub> root (hd1,0)
grub> setup (hd1)
grub> quit
exit
などとして、構築した後に再起動する。 再起動後は、mdadmで確認しつつmount/umountテストをする。

2011/12/25

OpenVZ+CentOS6.2ベアメタルインストール

色々あって、久しぶりにベアメタルインストールすることになったので、作業メモ。
#preparation for minimual installation
yum update -y
yum install -y wget

#setting ovz
cd /etc/yum.repos.d
wget http://download.openvz.org/openvz.repo
rpm --import  http://download.openvz.org/RPM-GPG-Key-OpenVZ
yum install -y vzkernel.x86_64

#setting up selinux
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

#setting up sysctl.conf
sed -i 's/kernel.sysrq = 0/kernel.sysrq = 1/g' /etc/sysctl.conf
sed -i 's/net.ipv4.conf.default.accept_source_route = 0/net.ipv4.conf.default.accept_source_route = 1/g' /etc/sysctl.conf
sed -i 's/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/g' /etc/sysctl.conf
sed -i 's/net.ipv4.conf.default.rp_filter/net.ipv4.conf.all.rp_filter/g' /etc/sysctl.conf
echo 'net.ipv6.conf.default.forwarding = 1' >> /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' >> /etc/sysctl.conf
echo 'net.ipv4.conf.default.proxy_arp = 0' >> /etc/sysctl.conf
echo 'net.ipv4.conf.default.send_redirects = 1' >> /etc/sysctl.conf
echo 'net.ipv4.conf.all.send_redirects = 0' >> /etc/sysctl.conf

#rebooting for initailization of ovz
reboot

#setting owp
wget -O - http://ovz-web-panel.googlecode.com/svn/installer/ai.sh | sh

#setting iptables
sed -i 's/--dport 22 -j ACCEPT/--dport 22 -j ACCEPT\n-A INPUT -p tcp -m state --state NEW -m tcp --dport 3000 -j ACCEPT/g' /etc/sysconfig/iptables
ざっとこんな感じ。
OWPセットアップ中に「sh: line 217: lsb_release: コマンドが見つかりません」と出力されるものの、
無問題。
後は、OWPとvzctlで煮るなり焼くなり。
ちなみに、仮想サーバーの複数IPアドレス指定は鬼門。
vzlistでどちらがINBOUNDで主IPになるか確認した上で、
vzctl set xxx --ipadd 192.168.1.xx/24 --save
などとネットマスク指定しないと問題が生じることがある。
ローカルIP+グローバルIPの構成は、特に注意したい。

ついでに、CentOS6.xからはVSwapに対応した。
これにより、何となくやっていた仮想サーバーのスワップ運用がマシになって、
物理サーバーっぽくスワップアウトした時に処理が遅くなるらしい。
OOM=即死を回避できたら嬉しい限り。

2011/11/10

SlimBlade Trackball 72327JP買った

タッチパッドに飽きたらず、トラックボールSlimBlade Trackball 72327JPを買ってみた。
まだ不慣れなものの、チルトホイールもなくて戻る進むボタンもないので素の状態で利用するには
厳しい。
当然ながら、Windows向けのアプリ毎のモード切替はUbuntuでは利用できない。
そこでeasystrokeを投入したら、Windows向けアプリ+ドライバ環境を軽く凌駕してしまったw
割り当ての基本的にアプリ毎にするとして、
ブラウザでは、
google-chrome,Firefox向けeasystroke
といった具合にして、
上2ボタンを戻る|進むボタンに切り替えた。
後は、オマケで簡単な操作を追加した。
前タブを閉じるアクションは、
xte 'keydown Control_L' 'keydown Shift' 'key Tab' 'keyup Shift' 'key w' 'keyup Control_L'
とした。

同様にmplayerでも、
mplayer向けeasystroke
とした。

後は、easystrokeが2つのボタン組み合わせジェスチャをサポートしてたら、
チルトホイール動作をブラウザとかで登録したいところ。

2011/10/21

Eclipse PDT => Aptana Studio3 => NetBeans ( 今ココ )

Ubuntu 11.10になった辺りからXULRunnerの影響でEclipse PDT のコードアシスタンス( 入力補完 )が機能しなくなった。
症状としては、HTMLコードが上部に生出力されて、候補内容がスクロールしないと表示されない状態。
PDT周りがdisられているようなので、Aptana Studio3を試してみた。
けれど、結局母体はEclipseなので同症状。
それでも、コードフォーマットがキチンとサポートされていたりとマシだったので、暫く遊んでみた。
全体としてPHPサポートが良くなってきているものの、
CodeIgniterでの利用はコードアシスタンスが利用できない事が判明した...orz
@property が使えれば、完全にEclipseから乗り換えてもよかったのに残念。

次に一部で人気らしいNetBeansを数日使ってみた。
EclipseやAptana Studioと観点や操作性の違う箇所が多々あるものの、
必要機能は満たしていた。

課題としては、
  • カラーテーマが微妙で、結局自炊することになる場合が多い
  • Emacsキーバインドが微妙な実装で使い勝手が悪いシーンが稀にある
  • コード内容に警告などが多いとコード内スクロールをスムーズに出来無い
  • 各種シンタックスへのテーマ色がリアルタイムに行われるものの、数秒レンダリングが遅延する
  • コード整形が微妙で、Tabインデントのみ指定してても空白文字が挿入されたりする
    お陰でPHP_CodeSnifferは改変が必要...
    ( DisallowSpaceIndentSniff.php,  LogicalNotSpacingSniff.php  を無効化)
  • Eclipse的にコードアシスタンスを表示する動作が対象コード宣言時のみ。
    例えばsubstrの場合は、substr()まで打ち込むと候補一覧が表示できない。
    カーソルホバーしても何も表示されない。
    Ctrl+Shift+Spaceで再表示される。
    Alt+Pでパラメーター一覧表示できる。
優位点としては、
  • まともなリファクタリング機能が実装されている
  • PHP_CodeSnifferをIDEと連動できるプラグインがある
  • Java開発で利用したい機能がPHPでも利用できるものが色々ある。
    これ重要。コメントトグル、順・逆インデントetc
  • SCMは、CVS,SVN,Mercurial,Git(要プラグイン),Bazaar(要プラグイン)対応
  • その他便利機能がいっぱいある
    Eclipse Marketplaceほどではないものの本家にはプラグイン一覧あり
  • 次期バージョンでは、Smarty、CSS3+ベンダープレフィックス、Git本体統合などが投入される予定。待ち切れない人柱はこちら
といったところ。

以下、優位点の動作画面など
PHP_CodeSnifferとNetBeansの連携
きちんと問題箇所コードへ遷移できる!
リファクタリング機能で名前変更する
同名の変数を他スコープに設置してる様子
リファクタリング対象を選択して、コンテキスメニューから名前変更を実行
変更後の名前を指定する
プレビュー表示では、変更前後が表示される
きちんとスコープ内のみ対象となっている!
検出された対象の適用指定は、個別にチェックボックで指定出来る!!
「リファクタリングを実行」する
当然のように正しく対象物のみ変更される
ちなみに、JavaScriptもリファクタ出来る
期待のコードアシスタンス
Eclipse系とは違うものの、必要十分
パラメーター表示は、Eclipse系と違ってコードアシスタンス上ではなく、ツールチップ
@propertyコメントがあれば、CodeIgniterでもコードアシスタンスが利用出来る!
@propertyコメントは、CodeIgniter内のライブラリ系のみならずユーザーライブラリも対応可能!
PDTよりソース編集補助機能が豊富
試しに適当にコメントトグル実施
しっかり指定範囲がコメントアウトされている
課題は多いものの、地味なところで気遣い的な機能が実装されていたりして、
なかなか良い。
しばらく実戦投入して様子を見ることにした。

2011/10/19

cx_Freezeが簡単だったので簡易JITコンパイラをビルドしてみた

今までPythonスクリプトのexe化には、py2exe一択だった。
最近emailモジュール関連のお陰で、py2exeを使えないことが判明してハマった。
だいぶ前のPyJUGのMLに、cx_Freezeの話があったの思い出したので試食してみたところ、
py2exeみたいにsetup.pyを書かなくても良いものの、defaultencodingの指定が必要だったりと色々な罠があった。
けれど、当初の目的だったemailモジュール関連も簡単にビルド出来た。
これに味をしめて、簡易JITコンパイラをビルドしてみた。

■ビルドするスクリプト( engine.py )
#/usr/bin/python                                                                
# -*- coding: utf-8 -*-                                                         
import os,sys,imp

if hasattr(sys,"setdefaultencoding"):
    sys.setdefaultencoding("utf-8")

def is_frozen():
    return ( hasattr(sys, "frozen") or # new py2exe                             
             hasattr(sys, "importers") # old py2exe                             
             or imp.is_frozen("__main__") ) # tools/freeze                      

def get_exec_dir():
    return os.path.abspath(
        os.path.dirname(
            sys.executable if is_frozen() else sys.argv[0]
            )
 )

if __name__ == '__main__':
    if len(sys.argv) > 1:
        mdfile = sys.argv[1]
        if os.path.exists(mdfile):
            mdname = mdfile.strip('.py')
            md = __import__(mdname)
            md.bootstrap( get_exec_dir() )

■動的実行するサンプルスクリプト( sample.py )
#/usr/bin/python                                                                
# -*- coding: utf-8 -*- 
import sys                                      
def bootstrap( execdir ):
   print execdir
   print sys.argv

■ビルドコマンド
cxfreeze engine.py
■サンプルスクリプト実行コマンド例
engine.exe sample.py hoge
c:\dist\
[ 'engine.exe', 'sample.py', 'hoge' ]

Farewell, vbs and wsh ! これで多少は可搬性の良いマルチプラットフォームなスクリプト実行環境が構築出来る。 GUIが必要になったら、メッセージダイアログとか程度ならTKinter等で頑張ればいい。

2011/10/03

Template in Javascript

JSでMVCが流行ってたり?、node.jsが流行ってる昨今。
Backbone.jsが気になっていたものの、実業務での利用はまだ先になりそう。
JQuery Mobile + Backbone.js + PhoneGapをやりそうな時は、考える。
残念ながら、Titanium Mobileを利用する機会の方が先に訪れる予定...

動的コンテンツが多いビューをゴリゴリとJSで書いているとJQuery単体ではJSコードとDOMでカオスになる。
この為、HTMLテンプレートは、必要となる機会が多い。
妥協として、textboxやdisplay:noneでテンプレートを覆って利用してきたけれど、
いい機会だったのでテンプレート系ライブラリに挑戦してみた。
以前に試したのは、JQuery標準入り間近らしいTemplates
利用方法は、こちらを参考にした。
けれど、投入案件のタイミング都合で流れたのだった。
そこに、Linux Journal( Androidアプリ出た )でMustache.jsを知った。
少しググってみると、パフォーマンスレポート記事があった。
試験したTemplatesは含まれていない。
こうして見ると、そこそこのパフォーマンスのようだ。

記法は、マニュアルに記載されている。
TemplatesとMustache.jsの共通機能の記法差異。
TemplatesMustache
変数${hoge}{{hoge}}
if else
 {{if hoge}}
  ${foo}
 {{else spam}}
   ${ham}
 {{/if}}
 {{#hoge}}
   {{foo}}
  {{/hoge}}
  {{#spam}}
   {{ham}}
  {{/spam}}
※if-else構文は存在しない為、
each構文を代替利用する!
foreach
 {{each hoge}}
  ${$value.foo}
 {{/each}}
  {{#hoge}}
   {{foo}}
  {{/hoge}}

この他、Mustacheにはラムダ対応など色々実装されている。
Templatesのscriptタグにテンプレートを押し込むをMustacheで表現すると、
<html>
 <script type="text/javascript" src="jquery-1.6.4.min.js"></script>
 <script type="text/javascript" src="mustache.js"></script>
 <script id="tmpl" type="text/x-js-tmpl">
  <b>{{hoge}}</b>
 </script>
 <body>
  <div>My name is<span id="nm"></span></div>
  <script type="text/javascript">
   $("#nm").html( Mustache.to_html($("#tmpl").text(),{hoge:'John'}) );
  </script>
 </body>
</html>
のようになる。
Templatesとの表記互換性や記号利用主体で可読性が低いといった課題はあるものの、
拡張性やファイルサイズなどを考慮するとMustacheはなかなか良さそう。

2011/10/02

Xubuntuでウィンドウのタイトルバーが突然消えた

何がきっかけになったかまでは分からないけれど、突然ウィンドウのタイトルバーがOS起動直後に消えていた。
ググって見ると、同じくハマっている人がチラホラいる模様。
結局、xfwm4が死んでいる場合に起こるらしい。
確かに
ps ax | grep xfwm4
と実行しても、見付からなかった。

とりあえず、
xfwm4 &
として回避した。

ispCP Omegaを試す

ispCP Omegaに挑戦してみた。
しばらく前から検証してみたかったけれど、OpenVZ上のCentOSにISPConfig3組み込もうとして、
proftpdの罠にハマって以来、この手は手控えていた。

早速、ispCP Omegaを構築してみる。
ベースOSイメージは、LEMP構築時のもの流用した。
ispCP Omegaは、ISPConfig3程ではないものの、しっかりとインストールマニュアルとインストールスクリプトが用意されている。

まずはインストールマニュアルに従って下準備。
apt-get update
次に、早速インストール作業。
hostname izumo.localdomain.jp
mkdir -p /usr/local/src/ispcp
cd /usr/local/src/ispcp
wget http://mirror.maximilian-jacobsen.com/isp-control.net/1.0.7/ispcp-omega-1.0.7.tar.bz2
tar -xvf ispcp-omega-1.0.7.tar.bz2
cd ispcp-omega-1.0.7
mv docs/Ubuntu/ubuntu-packages-lucid docs/Ubuntu/ubuntu-packages-natty
aptitude install $(cat ./docs/Ubuntu/ubuntu-packages-`lsb_release -cs`)
make -f Makefile.ubuntu install && cp -Rv /tmp/ispcp/* /
最後に、環境依存のセットアップ作業。
cd /var/www/ispcp/engine/setup && perl ./ispcp-setup && rm -fR /tmp/ispcp
※ここで設定した内容変更するのは、結構面倒。手順は、ホストIP変更ホスト名変更を参照。

これで簡単なWEBコンパネ付きLAMPが出来る。
ISPConfig3と比べたら、あまりに簡単すぎて驚いた。
機能的にも、プライベート利用でWEBコンパネ付きが欲しい時には、十分ではないだろうか?
サーバーを自前で用意せず、ホスティング利用のみのWEB制作会社で試験環境に使えそう。
DNSやVirtualHostの設定は、プログラマやコーダーには色々とシンドイだろうし。
ただ、公開サーバー設置する場合は十分な検証を...

...と大分前にまとめた記事だったけれど、どうやらispCP Omegaが実質死んでいる模様。
リリース停滞しているし、開発状況がTracは更新されていないようだし。
しばらくは、静観する。
むしろ、centmin(CentOS向けLENPスクリプトキット)や別のsysCP系列( i-MSCP , Froxlor )が気になる。
Kloxoもいいけど...歴史的経緯からセキュリティー的に不安。
何れにしても、Plesk/CPanelサポートレベルの代替OSSコンパネはないのが現状。

VirtualBox <= VMWare Player ?

メイン機がWindowsだった時代から自由度とゲストOSの画面応答速度の実積からVirtualBoxを利用していたけれど、
ゲストOSがWinXP時にAutocadなどの一部のアプリが動作しない状況に遭遇した。
今回投入したハードのCPUは、Pentium MやCore 2 Duo E7300。
そう、古いんです。
ただし、メモリーは2GBに変更したから、Ubuntu動かすには程よい環境。


当初は、他環境のVirtualBox 4.1.2で使用してたゲストOSを移植するだけのつもりで、
OVFでエクスポートしても、全く動作しないアプリがあった。
仕方ないので、ゲストOS自体をベアメタルインストールして同等環境を構築したものの、変化無し。
同様の自体をググると、古い記事(ソース失念)を見つけた。

根本的に、モダンなPCに搭載されているCPUの仮想化対応(Intel-VTなど)がネックだった。

仮想化対応していない化石環境では、本来のゲストOSの動作に支障をきたすと判明した。


諦めて、VMWare Player 3.1.3に切り替えると...あっさり動いた。
しかも、以前に比べて画面応答速度が改善されていて実用の範囲。
ただ、物理LANへのブリッジ接続がどうやっても動作しなかった。
けれど、希望環境としては、ゲストOSはネット接続HostOnlyで、ホストゲスト間ファイル共有、ネットワークプリンタが希望だったので無問題。
VMWare Playerでは、プリンタ共有とホストゲスト間ファイル共有はネット接続に依存しない仕様の為、
ネット接続HostOnlyでも利用できる。
尚、この機能は、VirtualBox OSEには搭載されていない。
※但し、sshfsなどには対応していない。恐らく、実行プロセス空間が違うんだろうなぁ


それにしても、VMWare Playerに随所に見られる自動化・簡便化には驚いた。
ゲストOSインストール時に、WinXP インストールCD入れただけでOS判定したり、
インストール開始時にCDキーを事前入力したり。
VirtualBoxも見習って欲しいところ。


以上より、フル仮想化ソフトといっても得意フィールドの違いがあるので、
利用シーンに応じて切り替えが必要なのは今も昔も同じ...orz

2011/10/01

Nginx On Debian Squeeze In Production

新規案件で割と高負荷なのに、メモリー割り当てが塩っぱいスペックのWEBサイトを構築すること
になった。
従来であれば、LAMP一択の所をLEMP構築にしてみた話。

構成環境は相変わらずOpenVZ上で、開発機スペックイメージは以下の通り。
KMEM:32MB
MEM: 512MB
SWAP: 512MB
nginxの特性を考慮して、socketやファイル関連リソースは、通常より多めに割り当てした。

それでは、インストール開始。
OS自体の構築は、OWPでDebianイメージを展開して済ました。

■OS設定変更
dpkg-reconfigure locales
dpkg-reconfigure tzdata
■パッケージ導入
echo 'deb http://packages.dotdeb.org stable all' >> /etc/apt/sources.list
echo 'deb-src http://packages.dotdeb.org stable all' >> /etc/apt/sources.list
wget -O - http://www.dotdeb.org/dotdeb.gpg | apt-key add -
apt-get update
apt-get install nginx php5-fpm php5-gd php5-mysql php5-mcrypt php5-apc postfix mysql-server
■php-fpm設定変更
...fpm自体...
/etc/php5/fpm/pool.d/www.conf を以下の様に適宜変更する。
listen = /var/run/php5-fpm
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 20
...PHP自体( /etc/php5/fpm/php.ini )...
expose_php = off
mail.add_x_header = off
■nginx設定変更
VirtualHost関連の構成は、Plesk同等とする。
ちなみにデフォルトサイトは、メンテ用として一般非公開とする。
IP直打ちやCatchAllドメインでのサイトコンテツ提供は、考慮しない。

...下準備(VirtualHostとしてtest.domain.comを運用する)...
mkdir -p /var/www/vhosts/default/httpdocs
mkdir -p /var/www/vhosts/test.domain.com/{logs,httpdocs,private}
touch /etc/nginx/sites-available/test.domain.com
ln -s /etc/nginx/sites-available/test.domain.com /etc/nginx/sites-enabled/test.domain.com
...環境設定を反映...
/etc/nginx/sites-avaiable/default を以下の様に適宜変更する
※「server_tokens」は、apacheのServerTokenと同意義。
/etc/nginx/nginx.confで定義してもよい。
server {
        listen 80 default;
        root /var/www/default/httpdocs;
        index index.html index.htm index.php;

        #catch all domain
        server_name _;
        server_name_in_redirect off;

        #hide server info
        server_tokens off;

        #disable suhosin for phpMyAdmin
        location /pma {
                fastcgi_param PHP_FLAG 'suhosin.simulation On';
                deny all;
                allow 127.0.0.1;# for system maintainer's IP
        }

        location ~ \.php$ {
                fastcgi_pass unix:/var/run/php5-fpm;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}
/etc/nginx/sites-avaiable/test.domain.com を以下の様に適宜変更する
server {
        root /var/www/vhosts/test.domain.com/httpdocs;
        index index.html index.htm index.php;

        access_log /var/www/vhosts/test.domain.com/logs/access_log;
        error_log /var/www/vhosts/test.domain.com/logs/error_log;

        #catch all domain
        server_name test.domain.com www.test.domain.com; #with alias for www

        #hide server info
        server_tokens off;

        location ~ \.php$ {
                fastcgi_pass unix:/var/run/php5-fpm;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}
■MySQL設定変更
/etc/mysql/my.cf を以下の様に適宜変更する
[mysqld]
#default-character-set=utf8
character-set-server=utf8
skip-character-set-client-handshake
■Postfix設定変更
※WEBサイトは、アプリ連携したメール送受信のみ、メールホスティングはしないケースを想定
メール振り分けはprocmail等でもいいけど、不要なアプリを入れずに済ませたいので自炊する。
設定内容自体は、本家マニュアルを踏襲。

...下準備...
事前にメール処理用ユーザーを登録する。
useradd -u 1005 -s /usr/sbin/nologin vmail

メール処理用スクリプトを設置する。
今回のサンプル( Python )
import os,sys,datetime
now = datetime.datetime.now().strftime('%Y%M%d_%H%I%S')

f = open('/tmp/'+now,'w')
f.write( str(sys.argv) +"\n")
f.write( sys.stdin.read() )
...環境設定を反映...
/etc/postfix/main.cfを以下の様に適宜変更する。
virtual_mailbox_domains = test.domain.com
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/virtual
virtual_uid_maps = static:1005
virtual_gid_maps = static:1005
transport_maps = hash:/etc/postfix/transport
/etc/postfix/virtualを以下の様に適宜変更する。
debug@test.domain.com mailapp
/etc/postfix/transportを以下の様に適宜変更する。
debug@test.domain.com mailapp
/etc/postfix/master.cfを以下の様に適宜変更する。
mailapp unix        -       n       n       -       -       pipe
  flags= user=vmail argv=/var/www/vhosts/test.domain.com/private/procmail.py ${sender}
ざっとこんな所。
一部チューニングをしているけれど、この辺は状況を見て調整する。

2011/09/24

ConnectBotを飼い慣らす

前回、フォント周りを変更して以降、
初めてサーバーメンテ実戦があった。

感想としては、
  • やっぱり画面サイズ強制は必須!
  • 入力文字フォントピッチの計算が、1文字分狂っていてどこまで入力内容が繋がっているか判読しづらい
  • ネットワークレスポンスが悪い時に、応答待ちか表示されない
不満を口にするなら、手を動かす。

1.画面サイズ強制
入力値永続化を実装するのは面倒なので、
初期値を実機に適した値で書き換える。
006SHのランドスケープでは、133x15が適している。
変更作業自体は、/res/layout/dia_resize.xml 中の
/LinearLayout/EditText[android:id="@+id/width"]

/LinearLayout/EditText[android:id="@+id/height"]

android:text属性値をそれぞれ書き換えるのみ

2.入力文字フォントピッチの修正
AVDで動かす分には感じなかった問題。どうも端末依存臭い。
それなら、いっそこの機能自体を書き換える。
/src/org/connectbot/TerminalView.java 203行付近の
int x = cursorColumn * bridge.charWidth;

int x = (cursorColumn > 0 ? cursorColumn -1 : cursorColumn) * bridge.charWidth;
に変更してお茶を濁した。

他は、とりあえず我慢する。

2011/09/23

オレオレ仮想アプライアンスを作ってみた

仮想アプライアンスキットを作成・公開出来るサービスIZUMO出雲が公開された。
Ubuntuベースキットのみとなっている点は、今後CentOSも検討しているらしい。
どんなディストロでもいいけれど、本気でアプライアンスやるなら、息が長いバージョンを採用すべきと思われる。
が、キット作成HowToページではその辺りを触れていない…
ま、いいか。
採用判断は、導入する本人や承認するその上長な訳で。
At Your Own Risk.

とりあえず、誰もキット登録をしていないので、
さっそく登録してみた。
取り掛かる前は、簡単だろうと思っていたものの、色々と試行錯誤してしまった。

まず、キット作成HowToにどこまで準拠すべきなのか。
ユーザー名やパスワード、ディレクトリ構成など枚挙にいまとがない。
真面目に仕事としてサーバー構築をやったことがある人には分かるけれど、
構築作業の成果物をどこまで詳細に明文化するかで作業ボリュームは全く変わる。

次に、マニュアル。
一般的なソフトウェア開発では、紙芝居やポンチ絵とメモ書きで纏めることが多いシロモノ。
中の人が作ったチュートリアル(マニュアル)見た途端、やる気が一気に失せた。
ターゲットユーザーが微妙過ぎです。
フォーラムの数少ない投稿から見ても、ユーザー層がエンスーやライトユーザーなど混じっているように感じる。
アプライアンス=素人向けなんだろうか?
色々考えだすと面倒なので、それっぽく体裁を整えてみた。

で、実際に登録したのは、
IZUMOに登録したLEMP仮想アプライアンス















LEMP ( Linux + Nginx + MySQL + PHP )キット
しばらく前からNginxネタをやりたいと思っていた所だったので、
実証実験を兼ねてやってみた。
これを利用する方々、皆さん人柱ですw
Nginxバージョンが古くて問題が多いようであれば、本家パッケージを検討したい。
PHPは、fpmを採用した。
今更、spawn-cgiなんて面倒。
APCなどのモダンなPHPアプリで使いそうなものは、あえて導入していない。
その辺は、LEMPどうこうの範囲じゃなくて、投入するアプリの仕様と判断した。
no battery included!

それにしても、テキトーに登録した割に初ユーザー仮想アプライアンスとして掲載されていることに
驚いてしまった。
中の人は、懐が深いんだなぁ。
今後、オレオレ仮想アプライアンスが大量に登録されて、中の人が忙殺されないことを願いたい。
後、某AppStoreのレビュアーみたいに傍若無人な対応も。

2011/09/10

ConnectBotのフォント変更

AndroidでSSHと言ったら、まず候補に上がるConnectBot
ハードウェアキーボード非搭載の端末では、
色々使い勝手の問題があるものの、Hacker's Keyboardを入れると実用性が増す。
更にもう一歩踏み込んでみた。

[やりたいこと]

  1. ターミナルのフォント変更
  2. ターミナルスクリーンサイズの固定
[ 結果(WVGA@AVD) ]
ConnectBot+Hacker's Keyboard オリジナル

ConnectBot+Hacker's Keyboard +TakaoGothic

1. ターミナルのフォント変更
大体の*nixでは、ターミナルでのフォントとプラットフォーム自体のフォントは別管理されている。
けれど、Androidでは色々な都合で好みのフォントが利用できないことが多い。
但し、アプリ限定であれば、多少イケル!という話。
幸いにして、ConnectBotはCanvasを主体にゴリゴリ実装されている?為、
簡単に変更できた。
まずは、ConnectBotソースを用意する。
ターミナルフォントには、Takaoフォントを利用しているので、
これを利用する。

次に、ソースをテキトーに展開して、
  • assetsに「TakaoGothic.ttf」、
  • toolsに「progaurd.jar」( README参照 )
を設置する。

最後に、「TerminalBridge.java」中、
defaultPaint.setTypeface(Typeface.MONOSPACE);

defaultPaint.setTypeface(Typeface.createFromAsset( manager.getAssets() , "TakaoGothic.ttf"));
に変更する。

後は、ビルドしてAVDや実機に投入する。

2.ターミナルスクリーンサイズの固定
これをやらないと、006sh実機ではスクリーン上にソフトウェアキーボードが乗ってしまって、
キーボードでターミナル末尾が見えない上になってしまっていた。
色々とソースを眺めたり、ググっている最中に「サイズ強制」メニューの存在を初めて知った・・・
画面スケールは、ボリューム操作キーで自動スケール、「サイズ強制」で指定画面サイズにスケールする仕様らしい。
但し、固定したサイズの永続化は実装されていないので、
セッション再接続時に再設定が必要な仕様となっている。
ここは実装したかったけれど、時間都合で諦めた。
とりあえず、当面は端末毎に最適値を覚えて接続時に手入力で我慢する。

以上で、少しはマシな環境が構築できた

2011/06/19

CKEditorの塩っぱいプレビュー機能を改善する(2)

前回はダイアログ化に成功したので、トドメのカスタムプレビュー表示を実装した。
とりあえず、導入後のイメージ
サンプル一覧ページに編集内容を挿入した。
おおよそ、期待する動作を実現できたと思われる。

以下、導入方法の説明。
まずは、こちらから最新ソースを取得する。
導入手順は、前回を参照。
前回からの追加は、
function CKEDITOR_PREVIEW_URL(){
 //プレビューに利用するページのURL
  return '/_samples/';
 }
 
 /**
  * プレビュー表示のイベントハンドラー
  * @param {String} frameId プレビュー表示用IFRAME要素のID
  * @param {String} content エディタ編集中の内容
  */
 function CKEDITOR_PREVIEW(frameId,content){
   $('#'+frameId).contents().find('h1').after('
'+content+'
') .end() .find('a').click( function(e){ e.preventDefault(); } ); }
などとCKEditorと同じスコープ内に記述する。
プレビュー画面上での画面遷移を抑止したい場合は、上記のようにpreventDefaultを入れた方がいい。
子供だましかな...

クロスドメインページをプレビューに利用したい場合は、
function CKEDITOR_PREVIEW_URL(){
  return '';
 }

 function CKEDITOR_PREVIEW(frameId,content){
   $.getJSON('http://www.hoge.com/?callback=?',
              function(json){
                      $('#'+frameId).contents().find('html').html(json.data)
                          .find('#foo').html('
'+content+'
'); } ); }
のような実装にする(クロスドメインでの動作自体は未確認)。
この場合、必要であればspinnerなどを入れた方がいい。
ちなみに、CKEDITOR_PREVIEW_URL、及びCKEDITOR_PREVIEWの何れか未定義の場合は、
フォールバックとしてエディタ編集中の内容のみがダイアログ表示される。

tumblerdが異常にメモリーを溜め込む

Xubuntu環境下で、tumblerdプロセスが異常に4GB以上もメモリーを溜め込む症状に陥った。
実行環境のメモリーは6GBのため、スワップしまくりで使い物にならない。
まさか、8GBオーバーが前提じゃあるまいな...

ググってみると過去にメモリーリークバグがあったみたいだけれど、該当しそうなバグレポートが直ぐに見当たらなかった。
Synapticで検索してみると、どうやらサムネイル処理関連のD-busサービスと判明。
確かに、発症した状況では大量に画像や動画が配置されているディレクトリをThunarで巡回していた。
Thunarのサムネイル処理は、tumblerに統合されている(されている途中?)らしい。

仕方ないので、一度tumblerdプロセスを終了してみた...が、しぶとく復活&発症してくれたorz
これでは根本的に解決しない。
どうも一過性のバグではないらしい。
Synapticを再び眺めてみると、tumbler-plugins-extraなるものがインストールされていることを見付けた。
extra...怪しいネーミングだ。
試しに、
apt-get remove tumbler-plugins-extra
などと実行して削除してみると発症しなくなった!
既存アプリケーションへの影響度が分からないけれど、workaround(回避策)としては正解だったか?
ちなみに、当然ながら動画サムネイルは利用できなくなった。

2011/06/18

Puppet、Chefより先にKokkiを試す(1)

Oneiricにdotdeeが入るらしいから、OpenVZ上のDebian(6.0)に突っ込もうとした...が、upstartとか依存関係で諦めた。
本家では、黒魔術とか突っ込まれてる(w
それにしても、作者的にはPuppetChefなんてスカイネットかとネタにされている。
けれど時流としては、カオスな運用 → PuppetChef

PuppetChefを試そうにも、Rubyなだけに食べず嫌いだった。
それぞれイイヨ!とかいっている人達は、まさかこの運用改善って目的だけにRubyいれてるのかな...
そこは規模なんだろうか?
先日、たまたまChefのPythonポートといわれるKokkiを見付けたので、試してみる。
やっぱりPythonはどこでも走る(走ってる)から気楽だなぁ。

まずは、ソースを取得する。
本来は本家ドキュメントにある通り、
easy_install kokki
としてインストールするべきだけど、いきなり突っ込むなんて恐ろしくて出来ない(w

本家のcookbookへのリンク切れ気になったので、
ドキュメント(sphinx)をmakeしたけど一切記載がない。
というか、githubのIssuesにあがってたけど、放置プレー状態orz
これは...ソース嫁ということか。
ということで、ソースを少し眺めると...
apach2のレシピにRubyのコードっぽいものがコメントアウトされていた(w
cookbook( v 0.4 )には、
apache2
aspersa
avatartare
aws
boto
busket
cassandra
cloudera
cloudkick
exim4
flume
gearmand
java
jenkins
librato
limits
mdadm
membase
memcached
minecraft
mongodb
monit
munin
mysql
nagios3
nginx
pip
postgresql84
postgresql9
powerdns
rabbitmq
redis
serverdensity
ssh
sudo
supervisor
users
zookeeper
が配置されている。
monitやredisなんて珍味やjenkinsやnginxまであるのは面白い。
とはいえ、postfixやlighttpdなかったりする。
どういう基準なんだろうか?
新しいシステムインフラを取り込んでいく姿勢は歓迎するけど、
メジャーなものが満たされていないと常用は難しいかな。
個人的には、
  • bind
  • php
  • Postfix
  • qmail
  • vsftpd
  • proftpd
  • OpenVZ
辺りが外せない。
実際、Chefのcookbokサイトでは他にも色々ある。
使えそうなら、何かしらポートしようかな。

2011/06/17

WPScan試してみた

昨日、色々なメディアで取り上げられてたWPScan( Wordpress Security Scanner )を試してみた。
実行環境はDebain( 6.0 )なので、
apt-get install rubygems libcurl4-gnutls-dev
gem install –user-install typhoeus
gem install –user-install xml-simple
などとして下準備をする。
次にソースを
svn checkout http://wpscan.googlecode.com/svn/trunk/ wpscan-read-only 
で取得する。
実行環境では、502エラーが出たので何度かリトライした。
実行オプションは、READMEなどから分かる。

お楽しみの実行結果は...
root@dev:~/trunk# ruby wpscan.rb --url localhost --username wp_admin                                                                                       
____________________________________________________
 __          _______   _____                  
 \ \        / /  __ \ / ____|                 
  \ \  /\  / /| |__) | (___   ___  __ _ _ __  
   \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \ 
    \  /\  /  | |     ____) | (__| (_| | | | |
     \/  \/   |_|    |_____/ \___|\__,_|_| |_| v.ALPHA

  WordPress Security Scanner by ethicalhack3r.co.uk
_____________________________________________________

# Copyright (C) 2011 Ryan Dewhurst
# This program comes with ABSOLUTELY NO WARRANTY.
# This is free software, and you are welcome to redistribute it
# under certain conditions. See GNU GPLv3.

| URL http://localhost/
| Started on Fri Jun 17 09:42:32 2011

[+] WordPress version 3.1.3 identified from meta generator.
[+] The WordPress http://localhost/readme.html file seems to exist.

[+] Finished.
となった。

どうやら、
  • data/wp_vulns.xmlに定義されたパターンのスキャン
  • 独自実装( readme.html のみ? )のスキャン
  • 辞書を使ったブルートフォース
をやってくれるらしい。

Wordpress向けMetasploitみたいな感じ。
現状は、既知のセキュリティーホールなどがメインになりそうだから、
ゼロデイアタックとかコミッターの体力勝負になりそう。
むしろ、その類に悪用されないと願いたい...

2011/06/13

CKEditorの塩っぱいプレビュー機能を改善する(1)

CKEditorには標準でプレビュー機能が搭載されているけれど、
別ウィンドウで開くし、プレビューといいつつエディタ単体の編集内容しか表現できない...etc
これでは、かなり利用シーンが限られている。
CMSでプレビューする時って、普通はエディタ編集内容+装飾やページ全体で出力する。
これを可能な限り、CKEditorで再現したいなぁという話。

とりあえず、でっち上げでダイアログ表示に対応したプレビュープラグインを作成した。
導入前、
旧来のプレビューは別ウィンドウでプレビュー表示される

導入後、
プラグイン導入後は、同ウィンドウ内のダイアログとしてプレビュー表示される。
別ウィンドウを開かない分、画面応答が早くなっている。
といった感じに変わる。

以下、インストール方法。

1. プラグインソースを配置する
まずは、こちらからソースをダウンロードして、
適宜解凍したものをソースディレクトリ(  /_source )に設置する。

2. ビルド設定を変更する
ckeditor.pack中、
'_source/plugins/preview/plugin.js'

を探して、

//'_source/plugins/preview/plugin.js'
 '_source/plugins/previewdialog/plugin.js'
などと書き換える。

後は、ビルドするだけ。
本来ならコピペで済ますのがプラグインとしての流儀だけど、
これ入れたら旧来のプレビュー機能は状況的に使われないし、
CSSとかシンドイので(ぉ

尚、このプラグインは、PoCレベルなので悪しからず。

[追記]
一応、期待する実装は完了した。
追加機能の説明は、こちらを参照

2011/06/12

CKEditorを自分色に染める(4)

今回は、
  1. エディタ領域のサイズ指定
  2. ダイアログのリサイズ時のサイズ指定
を扱う。

1. エディタ領域のサイズ指定
まず、初期表示状態のサイズ指定は、
 config.width  = 640;
 config.height = 480;
などとする。

次に、リサイズ時のサイズ指定は、
 config.resize_maxWidth  = 1024;
 config.resize_maxHeight = 768;
 config.resize_minWidth  = 640;
 config.resize_minHeight = 480;
などとする。

デザイン的に色々リサイズされると崩れて困る場合は、
config.resize_enabled  = false;      //そもそもリサイズさせない
 config.resize_dir      = 'vertical'; //リサイズは縦方向のみに限定する
などとする。

2. ダイアログのリサイズ時のサイズ指定
ダイアログのサイズなどの定義は、プラグイン自体かダイアログ定義イベントハンドラで指定することになる。
ダイアログ定義イベントハンドラで指定する場合は、
CKEDITOR.on( 'dialogDefinition', function( ev )
  {
    //定義中のダイアログ種類名を取得する
    var dialogName = ev.data.name;

    //ダイアログ定義を取得する
    var dialogDefinition = ev.data.definition;

    //全ダイアログ共通してリサイズを無効にする
    dialogDefinition.resizable = CKEDITOR.DIALOG_RESIZE_NONE;

    //ダイアログ個別に指定する
    if ( dialogName == 'image' )
     {
        //縦横方向のリサイズを許可する
        dialogDefinition.resizable = CKEDITOR.DIALOG_RESIZE_BOTH;

        //ダイアログ初期表示サイズ
        dialogDefinition.width  = 640;
        dialogDefinition.height = 480;

        //ダイアログ最小表示サイズ
        dialogDefinition.minWidth  = 320;
        dialogDefinition.minHeight = 240;

        // ( これ以降は独自実装 )
        //ダイアログ最大表示サイズ
        //CKEditor v3.6では最大表示サイズが指定出来ないので、独自プロパティを設定する
        dialogDefinition.maxWidth  = 800;
        dialogDefinition.maxHeight = 500;

        //定義中のダイアログのリサイズイベントハンドラを定義
        dialogDefinition.dialog.on('resize',function(e){
          //リサイズ後のダイアログサイズ
          var resizedWidth  = e.data.width;
          var resizedHeight = e.data.height;

          //リサイズされたダイアログ
          var senderDialog           = e.sender;
          var senderDialogDefinition = e.sender.definition;

          //ダイアログ最大表示サイズ
          var maxWidth  = senderDialogDefinition.maxWidth;
          var maxHeight = senderDialogDefinition.maxHeight;

          //最大表示サイズを超過している場合は、適宜補正する
          var revisedWidth  = maxWidth < resizedWidth   ? maxWidth  : resizedWidth;
          var revisedHeight = maxHeight < resizedHeight ? maxHeight : resizedHeight;
          
          if( revisedWidth  < resizedWidth ||
              revisedHeight < resizedHeight )
            {
              //リサイズをやり直し
              senderDialog.resize( revisedWidth, revisedHeight );
            }
        });  
     }
 });
などと記述する。
ダイアログ自体のカスタマイズは、これを参考に進められる。

CKEditorを自分色に染める(3)

前回のckeditor_basic.jsネタのところで、但し書きを入れた話。
事の発端は、別件でJQueryでCKEditorをgetScriptしたことだった。
現象としては、pluginが読み込めなかった。
その時は、前回紹介したこちらではなく、本家ドキュメントから回避方法に辿り着いた。

ちなみに発生シナリオとしては、
  1. ckeditor.js又は_basic.js何れかのエディタ本体を読み込む
  2. 相対パス指定?されているリソースを読み込む
  3. JSなどのエラー発生
といった具合らしい。

回避方法は、CKEDITOR_BASEPATHか、CKEDITOR_GETURLの2つ。
CKEDITOR_BASEPATHには、エディタの基準URLパスを指定する。
CKEDITOR_GETURLは、エディタで読み込むリソースのURLを取得する関数。
別件では、CKEDITOR_GETURLのみで回避した。
この関数は、ckeditor*.jsより前処理でグローバル定義しておかなければならない。

実際の実装は、
var CKEDITOR_BASE_URL = '/assets/js/ck/';
function CKEDITOR_GETURL( resource )
{
  return resource.indexOf(CKEDITOR_BASE_URL) != 0 ? CKEDITOR_BASE_URL+resource : resource;
}
などとした。
これで、CKEditor自身が迷子になっても正しいリソースURLを指し示せる。
それにしても、CKEditorのNewbie Developer向けドキュメント整備具合はTinyMCEに遠く及ばないことを痛感した。
API Docなんて飾りです。偉い人にはわからんのですよ。

CKEditorを自分色に染める(2)

カスタムビルドをやったら、今度は読み込み最適化。
これまたヘビー(w
とはいえ、

  1. CSSもminifyする
  2. ckeditor_basic.jsを利用する

の2点のみをやる。
詳しい情報は、本家にある通り。
本家では微妙な表現だけど、読み込み最適化の話をするならgzip転送は前提なんだなぁ...
mod_deflate対応してないホスティングサービスではこの辺シンドイなぁ。
みんなphpとかの変換スクリプト挟んでいるのだろうか?

CSSをminifyするには、minifierを事前に準備しておく。
yuicompressorを利用する。他に好みのものがあれば、そちらをどうぞ。
yuicompressorでは、
java -jar yuicompressor.jar -o  出力ファイル 入力ファイル
とするだけで、CSSとJSの2種類がminifyできる。

それでは、読み込みを最適化させる。

1. 関連するCSSをminifyする
まずは、_ckeditor自体のスタイルとなる、
 /contents.css
をminifyする。

次に、利用するスキンのスタイルとなる、
/skins/%利用するスキン%/
 dialog.css
 editor.css
 templates.css
をminifyする。
2. ckeditor_basic.jsを利用する
基本的には、「ckeditor.js」として読み込んでいるscript記述を「ckeditor_basic.js」に書き換えるだけでいい。
但し、ckeditor.jsの配置場所がbasic.jsと違ったり、
JQueryでいうgetScriptみたいなXHR経由でckeditorを読み込むとハマる。
回避法方法の具体的な実装ついては、別記する。
お楽しみのBefore & After。
基準となるオリジナルでは、
ckedirot.jsがonloadまでに読み込まれている

そして最適化後は、
ckeditor_basic.jsが追加されている。
ckeditor.js自体や関連するファイルは、onload以後に読み込まれているのが分かる。
結果として、onloadまでの時間が大幅に短縮されている。
となる。
たった少しの手間で絶大な効果があったと言える。

CKEditorを自分色に染める(1)

CKEditor+KCFinderネタが好評らしいので、いくつかCKEditorネタを扱うことにした。
まずは、カスタムビルド。
いきなりヘビーなネタ(w
minifyされてるJSが同梱されてるけど、やっぱりビルドしたい輩もいる訳で。
ちなみにビルドすると、
  1. デフォルトスキンに好きなものを指定できる
  2. デフォルト言語に日本語を指定できる
  3. 要らないプラグインを外せる
  4. 1~3を実施することで、CKEditor表示完了までの時間を短縮できる
といったメリットがある。

カスタマイズするには、まずは本家からソースを取得する。
といっても、既にCKEditorをダウンロードしている場合は、minifyされたJSと同梱されているので取得不要。
次に、専用minifierを取得する。
JAR版は、こちら。EXE版は、こちら

カスタマイズの流れとしては、
  1. ckeditor.packを編集
  2. 必要であれば、関連リソースを編集
  3. Let's Build!
になる。

それでは、カスタムビルドに取り掛かる。

1. デフォルトスキンに好きなものを指定する
まずはckeditor.pack中で、
 '_source/skin/kama/skin.js'
を探して、「kama」→「office2003」など好きなものに書き換える。

次に、_source/core/config.js中で、
 skin : 'kama'
を探して、「kama」→ckeditor.packで指定したものに書き換える。

2. デフォルト言語に日本語を指定する
まずは、_source/core/config.js中で、
 defaultLanguage : 'en'
を探して、「en」→「ja」に書き換える。

もし、日本語でしか運用しないのなら、ckeditor.js自体に言語ファイルを組み込んでしまった方が都合がいい。
言語ファイルを組み込むにはckeditor.pack中で、
 '_source/lang/en.js'
を探して「en.js」→「ja.js」に書き換える。
デフォルトでは、この行はコメントアウトされているので適宜コメントを外す。

3. 要らないプラグインを外す
まずはckeditor.pack中で、
 '_source/plugins/print/plugin.js'
などのプラグインファイルを探して、コメントアウトする。

次に、_source/core/config.js中で、
 plugins : 
を探して、ckeditor.packでコメントアウトしたものを同様にコメントアウトする。
そして、
 removePlugins : ''
を探して、ckeditor.packでコメントアウトしたものを列記する。
こんな感じで編集する。
ちなみにサイト内で完結するコンテンツのエディタとして利用する場合は、
  • basicstyles (Boldなどを利用したい場合は、外すと利用出来なくなる!)
  • bidi
  • flash
  • format
  • forms
  • iframe
  • newpage
  • print
  • scayt
  • stylescombo
  • specialchar
などが不要なプラグインと思われる。

さて、お楽しみのビルドタイム!
JAR版でのビルドは、
java -jar ckpackager.jar ckeditor.pack
と実行する。

基準となるオリジナルビルドは、
Packaging file ckeditor_basic.js


    Checking compressed code...

    Number of files processed: 5
    Original size............: 41471 bytes
    Output file size.........: 6940 bytes (17% of original)

Packaging file ckeditor.js


    Checking compressed code...

    Number of files processed: 117
    Original size............: 1189255 bytes
    Output file size.........: 356683 bytes (30% of original)
初期状態は、言語ファイルやスタイル定義など色々読み込んでいる。


そしてカスタムビルドは、
Packaging file ckeditor_basic.js


    Checking compressed code...

    Number of files processed: 5
    Original size............: 41471 bytes
    Output file size.........: 6940 bytes (17% of original)

Packaging file ckeditor.js


    Checking compressed code...

    Number of files processed: 107
    Original size............: 1130877 bytes
    Output file size.........: 340796 bytes (30% of original)
CKEditor自体が9KBくらい軽量化されていて、
言語ファイルなどの読み込みが減っているのが分かる
結果として、onloadまでの時間が短縮されている。
となった。
実は、言語ファイルを組み込むだけでは、オリジナルビルドより肥大化するけれど、
プラグイン外しが効いている結果だったりする。
用途次第では、もっとプラグインを外せたり、そもそもconfig.jsを読み込む必要すらなくなる。

TinyMCEに比べて軽いと聞いて使っているのに、初期ロードがいまいちと感じる方はお試しあれ。

2011/06/11

そろそろモダンな開発環境へシフトしよう(5)

さて、Photoshop。
そもそもテキストデータを扱わないソフトだけに、一般的にはCVS(バージョン管理)の普及が遅れている分野みたい。
実際、CVSを探すと高価な大規模組織向けのCVS+α的な代物しか見つからない。
TortoiseDiff+TortoiseSVNで頑張るのは、やれば分かるけれど現実的ではない。
そこで、Timelineを試してみたい。

Timelineは、PhotoshopプラグインとSubversion連携プログラムの2つから構成されている。
本家サイトにあるTimeline Liteはこの無料版(制約あり)。
動作検証していたら、面白いことが分かったので合わせて載せておく。

まずは、正規系インストール手順を行う。
本家からTimeline_Setup.exeをダウンロードしてインストールする。
インストールを終えてPSを起動すると、
Timelineのウィンドウが表示される
Timelineのウィンドウから、SVNリポジトリブラウザが起動できる



























SVNリポジトリへのアクセス設定を入力する。
プロトコルの指定は、DreamWeaverに及ばずHTTP/S限定らしい。
SVN以外には、PixelNovelのオンラインストレージや他サービスも利用できる。
DreamWeaverで色々やってたSVNリポジトリに繋いでみた。
phpファイルが確認できる。
チェックアウトすると、左ペインの「Working Copy」に溜まっていく。























チェックアウトしたファイルを編集して、通常通り上書き保存すると
コミット誘導ダイアログが開始される。
まずは、ファイルロックをするかの確認ダイアログ。
変更有り→これからも変更するよね→一応ロックする?みたいな発想らしい。






















ロックをキャンセルすると、いきなりコミットを案内される。
ここで「Commit」をクリックすると、実際にコミットされる。























コミット時には、当然ながらコメントを入力出来る。





















更に変更を重ねていくと、Timelineウィンドウにサムネイルが並んでいく
























ざっとこんな流れで利用する。
Subversionをテキストファイル主体で利用する人間からすると、
チェンジセットは?ブランチ切り替えは?diffは?mergeは?
といった当たり前に機能がないことに気付かされる。

チェンジセットは、必ず1ファイルでしかコミットしないから意味をなしてない。
ブランチは、チェックアウトで切り替えるしかない。
TortoiseDiffしたくても、外部diff呼び出し機能がない。
mergeしたくても、そもそも画像のmergeってどうやるんだ??

不満は色々あるけど、プラグインで違和感を低減させたことで実用化出来る範囲に
ギリギリ達してはいる。
一番問題なのは、このプラグインに$100出せるかどうか。
様々な事情で$100出せない方は、Timeline Liteをどうぞ。

Timeline Liteは、SVNではなくPixelNovelのオンラインストレージ専用に制限されたもの。
...と謳われている...一般人向けには。
Timeline LiteをインストールしたPS。
ウィンドウデザインなど細かな差異がある。


































実は、PixelNovelのオンラインストレージでなくてSVNでも利用できる。
利用方法は、2つある。

1. オンラインストレージの動作を偽装する
Wiresharkで眺めてて気付いたけれど、どうやらオンラインストレージなるものは
単純に「SVN over HTTP」らしい。
そんな訳で、hostsやDNSをでっち上げればどのmod_dav_svn環境でも利用できる可能性が高い。
但し、以下の構成にすべし。
/resources/reppath/reppath 
を配置する。
中身は、
http://pixcelnovel.com/svn/
などとアカウントディレクトリ(SVNリポジトリ)の配置ディレクトリパスを記述する。
このファイルは、URL1行のみ記述して改行文字(\n)などで終わってはいけない。

次に、アカウントディレクトリを作成する。
mod_dav_svnの設定に準じて、
/svn/%アカウント%
などとディレクトリを作成し、リポジトリを作成する。

パスワードの設定は、Basic認証で通過可能なのを確認した。
他プロトコルは未検証。

後は、Timeline Liteの画面に従って入力を進める。
Timeline Project Asistant を起動すると、
簡易プロジェクト管理機能ダイアログを表示される。
リポジトリの設定などは全てこのダイアログで行う。


































2. プラグイン周りの動作を偽装する
Timelineはプラグイン側でアクティベーション管理をしている。
この為、Timeline Liteをプラグインとして機能させ、
SVN操作はTimelineのものを使うと...ktkr
詳しい手順は、「1」以上にヤバそうなので割愛する。

Timeline Liteプラグイン+Timelineで構築した様子。
見た目に違いはないものの...
































いずれにしても、バージョン依存、環境依存であるため、
一般人にはオススメ出来ない方法。
Adobe関連でhostsを書き換えるような好事家は、是非とも試してみては?

2011/06/10

そろそろモダンな開発環境へシフトしよう(4)

前投稿から大分経ったため、対象環境のアプリ群もバージョンアップを重ねてしまった。
けれど、これが幸いして、DreamWeaver(以下、DW)がようやくSubversionに正式対応した。
そんな訳で、以下の構成でAdobe+αでBazaar+SVNを試す。

[バックエンドエンジニア]
1. Eclipse → bzr → bzr-svn → svn
2. bzr-explorer  → bzr → bzr-svn → svn

[フロントエンドエンジニア]
1. Eclipse → bzr → bzr-svn → svn          
2. bzr-explorer  → bzr → bzr-svn → svn
3. TortoiseSVN → svn 
4. DW → svn
※1~3は、作業レベルにより変動

[デザイナー]
1. DW → svn
2. TortoiseSVN → svn 
3. Photoshop / Illustrator → Timeline → svn
※1~2は、作業レベルにより変動

[その他]
1. TortoiseSVN → svn

長くなるので、とりあえずはDWとEclipse( QBzrEclipse on Xubuntu )との連携。
SVNリポジトリは、svnserve(*nix)とmod_dav_svn経由で利用する。
svnserveやmod_dav_svn自体の構築は、本筋から外れるので省略する。

まずは、Eclipse。
subversive的なポジションのらしいBzrEclipseを使いたかったけれど、
実行環境では必ずbzrがクラッシュしたのでQBzrEclipseを採用した。
状況を鑑みて、変更する予定ということで暫定採用。

EclipseへのQBzrEclipseインストール手順は、他のプラグイン導入と同じ。
本家サイトに記載されている

http://development.bitwig.com/qbzr-eclipse

をリポジトリに追加設定する。
リポジトリからQBzrEclipseを選択してインストールする
インストールが終わると、上部メニューやコンテキストメニューに
Bazaar関連メニューが追加される

空のSVNリポジトリをチェックアウトしてみる
テストファイルを追加する
新規追加の為、リポジトリへ追加処理を行う
準備が整ったので、コミットしてみる

DWでSVNリポジトリの利用設定をする。
今回は新規なので「新規サイト」。
既存サイトの場合は、「サイト管理」から行う
SVNリポジトリの利用設定情報を入力する。
小規模の場合は、プロトコルにsvnを選んでもいい。
SVNリポジトリの設定が終わると、
バージョンコントロール関連メニューが利用出来るようになる。
早速、Eclipseでコミットした内容を取得してみる

ローカルファイルを編集すると、リポジトリとの比較が行える。
今回は、WinMergeを利用した。
編集内容をコミットする
Eclipseに戻って、最新データを引っ張ってくる(Pull)
変更内容が取得できた!
今度は、コンフリクト(衝突)を発生させてみる。
まずは、Eclipseで編集してコミットする
次に、DWで編集してコミットすると...
コミット出来なかった。
リポジトリ内データよりローカルデータの方が古いとの警告。
コンフリクトとは分かりにくいメッセージだ...
最新バージョンを取得すると、リポジトリ最新、ローカル最新、
それぞれを結合したものが作成された。
手動マージをして、解決済みとしてマークする。
その後、コミットする。これで、コンフリクト解消

ざっとこんな流れかと。
DWに一切マージなどの基本機能がないのは痛いと感じた。
その辺は、WinMergeとか外部ツール任せということだろうか?
Eclipseは、GUI統合がされていないお陰で、Subversiveとかに比べると
使い勝手が悪いのは否めない。
正直、ここまで使い勝手が悪いとBazaarを捨てたくなる。

さて、次はPhotoshopでのSVN運用をまとめる。