私的な技術メモ

この広告は30日以上更新がないブログに表示されております。
新規記事の投稿を行うことで、非表示にすることが可能です。

プライマリキーを varchar で定義しておいて、ジェネレータで自動連番を設定しているテーブルでソート順が乱れる現象が発生し、「あっ」と言ってしまう事案があった
本当はジェネレータで桁数が埋まるくらいの初期値をセットしておけば問題なかったのだが、うっかり忘れていたか、桁数を間違えていた可能性がある

テーブル定義

CREATE TABLE TAB_A
(
ID VARCHAR(10) NOT NULL PRIMARY KEY
)

本来なら、この定義の後で以下のSQLを発行しておくべきであった

SET GENERATOR GEN_AUTO_ID TO 1000000000

取りあえず、解決策はSQLの修正だが、CAST が使えることがわかった

SELECT * FROM TAB_A ORDER BY CAST(ID AS NUMERIC(10))

パフォーマンスの低下がどの程度なのかまでは評価していないが、後で調べてみようと思う


月額900円(税抜)〜で大容量100GB〜・マルチドメイン無制限の共用サーバー


◆お名前.com レンタルサーバー

【キャンペーン情報】

　今なら、初期費用＆月額最大3ヶ月分無料！

【利用料金】

　初期費用1,890円（税込）／月額料金945 円（税込）〜

【主な機能】
　・サーバー容量：100 GB〜
　・マルチドメイン設定：無制限
　・データベース（MySQL）：30個〜
　・サブドメイン設定：無制限
　・メールアカウント数：無制限
　・メーリングリスト：最大50個5つまで作成可能
　・高機能迷惑メールフィルター（オプション）
　・高機能アクセス解析
　・CGI / Perl / PHP5 / Ruby / Python / 対応

【アプリケーション】
　・WordPress / Movable Type　かんたんインストール
　・PukiWiki/XOOPS Cube/phpBB/Joomla!/OpenPNE

【セキュリティ】
　共用SSL/独自SSL（オプション）

【サポート】
　24時間365日の安心電話サポート（無料）


詳細はこちら

久しぶりに Firebird のプロシージャを書きたくなったのだが、相変わらず SQL 関連の文法は毎回忘れているので、またメモしておくことにする
今回やりたいのは、パラメータ付ビューだ
使い方は以下のようである

SELECT * FROM PARAM_VIEW(パラメータ)

こいつの定義文法は

CREATE PROCEDURE プロシージャ名 (パラメータリスト)
RETURNS (戻り値リスト)
AS
[ ローカル変数定義 ]
BEGIN
[ 処理ステートメント ]
END

パラメータリスト、戻り値リスト共に以下の文法に従う

仮引数名 型名 [, ...]

戻り値の返し方がちょっと面倒な書き方になっているが、概ね以下のようになる

FOR SELECT * FROM テーブル WHERE 条件指定
INTO :戻り値変数 [, ...]
DO SUSPEND;

仮引数などの指定に :変数名 のように ':' コロン を頭につけるという点が、うっかりしがちなので気を付ける必要がある
※大抵は文法エラーで指摘してくれるのでわかるが


ショップサーブ

自分で管理しているソースリポジトリが全く別々のサーバに分散していたので、統合を試みた
一旦テンポラリの枝を設定し、そこに別リポジトリのデータをロードして後から枝を整理しようとした
だが、一旦ロードしてから、内容が不要のものだったことがわかり、その枝を削除しようとしたら、なんと、削除できなくなってしまった

これは困ったぞ、ということになり、WEBを探しまわってみたら、 svndumpfilter に行き着いた
これは、そもそも不要な枝を簡単に刈り取ってくれるツールで、 svn ツールセットに標準で入っているもののようだ
こんな感じ


svnadmin create projectB
svnadmin dump projectA | svndumpfilter exclude /projectOld | svnadmin load projectB
mv projectA projectA-broken
mv projectB projectA


これでめでたく、ダイエット済みのリポジトリが作成できた

お名前.com レンタルサーバー

統計処理ソフトに R というものがあることを、放送大学の講義で知った
コマンドの文法に、ちょっと見慣れない雰囲気を感じたが、便利そうに思えたのでちょっと使ってみようと思った

たしか、講義内容では、データを配列に読み込み、そのデータをプロット（グラフに描画）していたが、つい最近、確率分布関数を作りたいという欲求があり、関数で与えたらどんな形になるのかをしりたくなって、その当時を思い出しながら操作しようとしたのだが、まったく忘れてしまっていた
まず、講義のサンプルはデータを直接与えるもので、関数形式ではなかったし、当然テキストも持っていなかった（無断受講なので）ので、頼りはWEB情報だけ、ということになった

いくつか調べた後、そもそも help も充実していることもあって、ようやくやり方が分かったので、メモしておく

結論）

コマンド

> foo <- function(x) exp(-x^2)
> plot(foo, -10, 10)

出力結果


結局関数定義をどうやるのかでつまずいていたのだが、文法が Pascal ぽくもあり C ぽくもありという不思議な感じだ
C に統一してくれれば当然（自分には）わかりやすいが、一般向けではなくなるのだろうな
※もちろん Pascal も今となってはかなり死語に近いし、Smalltak 風だと言われたらさらに、えっ、という感じだけどね


お名前.com レンタルサーバー

openssl を使ってCAを構築し運用するというのは、WEBで検索すると、かなりヒットする
だが、WEBでは見つけられなかった、CAのフラグを立てて自己署名する方法がわかったのでメモしておく

通常は openssl.cnf の

[ usr_cert ]
basicConstraints=CA:FALSE

を

[ usr_cert ]
basicConstraints=CA:TRUE

に書き換えればCA用のルート証明書が作れるという情報が見つかる
だが、それだと、一般用の証明書もそのオプションが適用されるので、一般運用前に CA:FALSE に戻す必要がある

ところが、CA用のオプションが実は [ v3_ca ] として用意されているので、コマンドの引数で指定すれば、 CA:TRUE にできることがわかった
そのオプションは -extension v3_ca を追加すること
これで、ちゃんとしたCA用のオプションが設定され、CA用のルート証明書が作成できる

Base64 をストリーミング的に扱うという発想から、エンコード方式が直接ストリームとなっているようなクラスを想像していたが、冷静になってみると、単に以下のようなラッパーでしかないことに気がついた

class Base64IStream : public std::istream {
public:
  Base64IStream& operator >> (std::ostream& out);
};

で、 operator>> の実装が単に以下のようになっていればいいだけのことだ

char input[5] = {0};
in.read(input, 4);
char output[4] = {0};
Base64Decoder.decode(input, 4, output, 3);
out << output;

結局考えていたことはストリームに対するマニピュレータをどのように綺麗に書くか、というだけのことだった
なんだか気が抜けてしまったので、この話題はもうやめておこう

結構大きな Base64 エンコードされたストリームを、他のスレッドにパイプ（もしくはパイプ様のもの）に流すというライブラリが欲しくなったな、と思い立ち、探してみたが、見つからない

探しているうちに

http://d.hatena.ne.jp/izariuo440/20110127/1296138201

ここで、結構詳しい考察をしているのが見つかった

パイプ仕様以前に、 Base64 実装のバリエーションがあることに結構びっくりした
固定長で改行するライブラリがあることは知っていたが、62番目と63番目のセットが +/ でない実装があるのは知らなかった　（RFCをじっくり読んだことはなかった）


もう少し考えないといけないようだ

開発では、DBによく Firebird を使ったりしている
ファイルが単一で結構扱いやすいからだ
自分の開発では Java から使うことがほとんどなので、 Jaybird (ODBC driver for Firebird) 経由でアクセスすることになるのだが、しばらくやっていないと、接続文字列をどう書くのかを結構忘れてしまうものだ

あらためて調べてみたが、やはり簡易な方式か Linux 向けの記事ばかりで、急ぎの仕事ではとうとう間に合わなかった
テスト環境は Windows 版なので、ドライブ文字をどう入れるのかをすっかり忘れてしまい、結局、 Firebird の稼働しているドライブ（C:ドライブ）にDBファイルをコピーして、その場をしのいだ

やはり正解が知りたくなり、改めて調べてみたら、
http://www.firebirdsql.org/file/documentation/drivers_documentation/Jaybird_2_1_JDBC_driver_manual.pdf
に解説が載っていた


自分の失敗例

DataSource=jdbc:firebirdsql:d:/database/test.fdb

正解

DataSource=jdbc:firebirdsql:localhost:d:/database/test.fdb

要は、ホスト名を省略しなければ、ドライブを D: などと書けるのであった
これを知らずに ///d:/ や /d:/ などと書いて、一向に埒が明かなかったのであった

焦っているときは、正解ページをなぜか引けないものなのかもしれない

前回までに考えた、同一ログファイルの更新の件だが、サンプルプログラムを作成し、多重スレッド・多重プロセス起動をしてみたら、どうもだめだめな感じだ

バッファの書き込み先が、別スレッドでのEOFアドレスだったりするようで、EOF越で書き込まれた領域が NUL で埋まっていた
EOF まで移動して書き込むあたりがどうもだめなのかもしれない
もちろん、多重起動しなければ普通に書き込まれるので、やはり排他制御部分が思わしくないようだ
思い付きのアルゴリズムは信頼性がないのだろうな

※一応、MSDN ではログファイルなどの書き込みで、EOF からサイズ分だけロックする方式が可能だという説明もあったので、そもそもそうしたやり方が禁止されているわけではなさそう　（でも、非推奨なのかも；ドキュメントは見つけていないが）


お名前.com レンタルサーバー
やっぱり

前回は LockFile の範囲が期待通りではなく、おかしい結果 （文字列がオーバーラップしていた） が得られていたが、実は、サイズ計算のミスであることがわかり、基本構造は正しかったことがわかった

前回の

void CWin32Logger::write(void* buffer, DWORD size)

の内容はそのままで、呼び出し部分でのサイズ計算を正しく実施したら、期待通り、重ならずに文字列を書き込めた
ただし、この方式は先着順ということであり、OSの制御によっては、後から書き込んだものが先に出力される可能性が残っているため、ログシステムとして考えると、ちょっと心もとない
（もちろん、後からタイムスタンプでソートすれば問題はないし、多くの場合では逆転することはなさそうだから、無視することも考えられる）

本格的に実装するなら、やはりFILOキュー方式が必要になり、そうした実装にするには、誰かがキューを制御しなくてはならない
ここでの目標は特定のサーバを設けないということなので、１つの案としては、最初に起動されたライブラリ実装が、キューを生成・管理するための仕組みを共有メモリに作成し、常に同時使用するプロセス・スレッド間で調停しながら進めるということになるのかもしれない

その雰囲気で実装できたら、ちょうど分散システムでのログ管理方式としても考えられそうだが、いかんせん、実装が Win32 に依存して （かつ、ファイルシステムAPIに依存） しているのでは、ちょっと汎用性がなさすぎだろうな

やはり、この実装が生きてくるのは、単一PC上での同一ログファイル競合くらいだという気がしてきた