ぺんラボ

coreserverでSSL導入を前提に構築し、問題がなさそうなので独自IPを購入して、そのIPでドメインを割り当て・・・
ると、強制的にディレクトリが作成されてしまう。
NoDir設定が有効にならない。
チェックを入れて保存しても反映されない。
時間を空けて何度か試してみてもだめだったのでサポートに問い合わせてみた。
深夜3時に送信したら、早くも数十分後に回答が。
その後2度やりとりしたけど、
「いただきました症状につきましては、弊社でも把握しており、担当部門からは対応中との報告を受けております。 」
まぁ、おそらく放置プレイなのでしょう。
仕方がないので、public_htmlの下のディレクトリに再構築しなおすしかなかったのでした。
でもこれでとりあえずSSLが導入できるわけですね。
その工程でも問題があったらどうしよう・・・

PHPの開発はなんだかんだで自前鯖や自宅鯖だったので、モジュールでフルの状態で動かしていたわけです。
プリントライはcoreserverに乗せたのですが、ここはセーフモードなのです。
あらかじめわかってはいましたがここまで時間をとられるとは思いませんでした。
まぁ、なんだかんだでCGIモードでなければならない部分はAjaxで逃げて事なきを得ています。
とりあえず行き詰った部分を。

・execが使えない（セーフモードというよりは鯖の設定か）
・mail関数で第5引数があるとワーニング８セーフモードのせい）
・ディレクトリのオーナーが違うと書き込めない（セーフモードのせい・Apacheとphpのユーザ）

Inkscape0.47での話です。
矩形を描いて線の太さを設定して、EPSに変換すると大きさが微妙にずれる。
なぜかと思っていじっていると、線の太さを変えると大きさも変化しているではないか。
つまり、Inkscapeの場合、パスのサイズではなく、実際の描画イメージのサイズだったらしい。
今まで散々いじってきたのにぜんぜん気が付かなかった。
EPSでは通常パスを基準にするため、てっきりそうだと思い込んでいたというわけだ。
0mmでサイズを指定して線の太さを指定すればずれないだろうけど、画面上から消えてしまうの。
プリントライのデータも全部作りなおしだぁ～

印刷サイトの開店を準備中ですが、テンプレートの調整が間に合わないのと、スタンプのデザインが完成していないので3月1日のプレオープンを一週間延期して3月8日とすることにしました。3月8日といえば私の誕生日、32歳になってしまいます。吉とでるか凶と出るか？
兎にも角にもプリントライをよろしくお願いします。

少し前にも書きましたが、アカウント作成直後ではファイル容量はフルでは使えません。送られてくるメールやページ上では、FTPなら1時間程度とありますが、実際にはほぼ即使用が可能です。
新しく取ったアカウント名ではしっくりこなかったので、アカウントを再取得することにしたので、ファイル容量についてしばらく観察してみました。

およそ4時間でファイル領域が確保されました。概ねこの程度の時間を考えておいたほうが良いようです。
ちなみに確保されるまでは
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
データ更新中ですので、次回更新をお待ちください。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
と表示されます。
これが確保されると
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
最大ディスク容量 60,000.00 MB
使用済ディスク容量 0.00 MB (1.66 %)
残りのディスク容量 59,999.99 MB (98.34 %)
最大ファイル数 500,000 個
使用ファイル数 5 個
残りのファイル数 499,995 個 (99.99 %)
※ 数時間毎に更新されます。
※ 上限を超えると、CGIなどの書き込みでファイルデータが破壊される可能性があります。不要なファイルを削除して下さい。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
となります。

いろんなユーザが混在する鯖なら、まぁ、当然といえば当然なのですが。
このことをすっかり忘れていたので、さぁたいへん。
ディレクトリを作らせてもその中にアクセスできない。
PHPはapaheユーザでディレクトリを作るけど、スクリプトはユーザで動くのでownerのチェックではじかれてしまう。
結局CGIモードにすることで回避できた・・・わけではなかった。
今度はsessionがユーザ違いで動かなくなったぁ～orz=3

これから始める印刷通販サイト「プリントライ」のために、coreserverでCORE-Bを借りました。すぐにログインできるようになったので、早速ファイルをFTPでアップし始めましたが、50M程度で容量が一杯だと怒られます。いろいろ調べるとそういった不具合はちらほらあるみたいで、解決策もなさそうなのでとりあえず不貞寝しました。
そして目が覚めると、ファイルがアップロードできるようになっていました。
そこで改めていろいろと考えて見ます。
・鯖を借りてもログインまでには時間がかかるとは書いてあるけれど、これしか書いてない。
・時間がたてばスペースが正常になるので、おそらくファイル用の鯖への領域作成が別のプロセスで用意されていて、ログイン機能とは動機していない。
・改めて考えると、借りたすぐはファイル容量の確認ページには何も表示されないけど、不貞寝した後はきちんと60Gの容量が表示されていた。
つまり、ファイル容量のページに容量の情報が表示されるまではとにかく寝て待てということのようです。
結論として、寝る子は育つのです。

2010年02月11日にOpenOffice.orgの3.2が公開されました。
14日に気がついたので早速落し、3.1から入れ替えて使い込んでみました。

普段から使っている機能には更新がないので、個人的には変化なしといったところです。
保存のプロセスが重いのはまだ改善されませんね。

excelと比較して・・・といいたいところですが、Microsoftのoffice2000を最後にOpenOffice.orgに乗り換えたので、比較しようがないのをおもいだしました。

Flash的にはインスタンスの複製とでもいうのだろうけど、こういう独自の呼び方はなかなか覚えられない傾向があるで覚える気もない（だから覚えないんだろうけど）。
ライブラリに最初から埋め込んである画像はクラスとして書き出しておけばnew hoge(0,0);とかでいくらでも表示を量産できるんだけど、Loaderでloadした画像で同じことをしようとしてはまった。
いろいろ端折ってるけど、たとえばこういう使い方

var loaderObj:Object = new Object(); // グローバルに宣言

var bm:Bitmap = Bitmap( loader.content ); // loadした内容をbmへ
loaderObj[ 'huga' ] = loader.content; // loadの内容をオブジェクトに入れて

var bm2:Bitmap = Bitmap( loaderObj[ 'huga'] ); // 他の関数から呼んでみる

実際に有効なのはbm2のみ。
オブジェクトに丸ごと放り込みさえすれば後は使い放題なのかと思いきや、1対1の関係らしい。
「actionScript3 loader」をググってヒットしたページを順番に眺めていたらヒントがあった。
Loaderではなく、bmを見に行けばいいらしい。

var bm:Bitmap = Bitmap( loader.content ); // loadした対象をbmへ
loaderObj[ 'huga' ] = bm; // loadの内容ではなくbmをオブジェクトに入れて

var bm2:Bitmap = Bitmap( loaderObj[ 'huga' ].bitmapData ); // 他の関数から呼んでみる

ここまで書いておいて、もしかすると？と思って書き直してみた。

var bm:Bitmap = Bitmap( loader.content ); // loadした対象をbmへ
loaderObj[ 'huga' ] = Bitmap( loader.content ); // loadの内容ではなBitmapの・・・（なんて呼び方？キャストではないしオブジェクトの変換？）をオブジェクトに入れて

var bm2:Bitmap = Bitmap( loaderObj[ 'huga' ].bitmapData ); // 他の関数から呼んでみる

リファレンス眺めてもこの挙動につながる箇所を見つけられなかったけど、とりあえずBitmapとしてオブジェクトに入れておけば、自由に扱えるらしいことが分かった。
BitmapでLoaderの何らかの制限から開放されているといったところか。
「Loaderはファイルを読むためのオブジェクト」とあるので、それ以外の用法は制限されるのか、一度Bitmapにすればその制限から開放されて通常の（期待した）使用ができるのか。
loaderObj[ 'huga' ]自体の型には何も違いはないのだけれど。
Loaderだから何々ができないという書き方がどこにもない（探した中では）のが悲しい。

ちなみに、clone()なしでも表示は量産できるだけど、オリジナルをnullにするとかどうにかすると道連れになるかどうかとかなのかもしれないけど、今のとこ必要ないので気にしないことにする。オブジェクトに入れたものが何者なのかこんがらがったままだし。

PHPで画像を扱うにはGDが楽なのですが、文字を書こうとすると思ったポイントで描画されません。
おそらくDPIを設定しないとだめなのでしょうが、PHPのリファレンスを探しても見つかりませんでした。
仕方がないのでいろいろ値をとりながら調べてみると、96dpiということが判明。
webではなくアプリケーション向けに72dpiで画像を生成するには以下のような手順となった。
ちなみに画像からはみ出にくいように調整もしてある。

$fontSize = 72;
$dpi = 96;
$margin = $fontSize / 8;
$baseline = $fontSize + $margin;
$size = $fontSize + $margin * 2;

$image = imagecreatetruecolor( $size, $size );

imageantialias( $image, true );
imagealphablending( $image, false );
imageSaveAlpha( $image, true );

$fillcolor = imagecolorallocatealpha( $image, 0, 0, 0, 127 );
imagefill( $image, 0, 0, $fillcolor );

$black = imagecolorallocate( $image, 0, 0, 0 );

$text = mb_convert_encoding( "あ", 'utf8' );
$font = 'xxxx.otf'; // 適当に置き換えて
imagettftext( $image, $fontSize/$dpi*$fontSize, 0, 0, $baseline, $black, $font, $text );

imagepng( $image, 'output.png', 9 );
imagedestroy( $image );

印刷も考えるとEPSで描いてから画像にするのが一番確実だけど、imagemagic（正確にはghostscript）を経由するのも面倒だしこうなった。