2011年7月4日月曜日

SQLite3

久々です。

筆者は現在、Android関連の技術調査を行っているのですが、そこであった笑い話をひとつ。


Android端末にはSQLiteという簡易データベースが内臓されているのですが、
このSQLite、簡易というだけあって他のデータベース(オラクルとかPostgreSQLとか・・・)とは
かなり異なります。

日付の扱いも異なるひとつですが、日付についてのマニュアルの翻訳が載っているサイト
(こちら)
を見て、試していてそれは起こりました。

date 関数は、strftime('%Y-%M-%D', timestring, ...) のエイリアスです。
という説明があったので、筆者はそのとおりに試してみたのですがどうもうまくいきません。
試したかったのは『'%Y-%M-%D'』部分で、この場合の処理結果は『2011-07-05』とかなるのですが
筆者が欲しいのは『20110705』・・・ "-"が邪魔なわけです。
あれこれ試して、サイトを見直してみると・・・
%Y 年 (0000-9999)
これは問題ないです。
%M 分 (00-59)
  %m 月 (01-12)
  %d 月における日 (00-31)
ををう! orz

日付を取りたくて"%D"としていたのがエラーになっていた様子・・・
マニュアルといえど人の作ったもの。
まるっと信じてはいけないですね。
(そんなことをいつも考えていると禿げそうになりますが・・・)

2011年4月17日日曜日

瀬戸陶祖まつり

去年もこのお祭りに行ってきましたが、今年もまた一通り見てまわってきました。
震災の影響か、多少店や屋台が減った気がしましたがそこそこの人出。
ここまではほぼ去年と同じでした。

・・・というのも、今日(日曜)は統一地方選の後半(?)の選挙期間にあたるらしく、まつりの会場周辺に候補者が殺到したのです。
殺到、というと誇張と取られるかもしれませんが、選挙カーが「すれちがう」のではなく「同じ方向に3台走ってる」というレアなものを見てしまったので・・・
そして、選挙カーの来ない商店街では候補者+数名の集団と2回遭遇。
市長選と市議選なので政策よりも知名度勝負なのか、名前を連呼して「よろしくおねがいします」。 ただそれだけでした。
何をよろしくすればいいやら? ですね^^;


そんなところを歩いていてふと思ったこと。
瀬戸市は13万人くらいの人口がある、そこそこの規模の自治体です。
しかし、いまひとつ活気がありません。
祭りを見ていて思ったのですが、陶器という「入れ物」は売っていても中に入れるものはノータッチなのです。
筆者はお茶好きなのですが、淹れる際に使用する器の素材などによってお茶の味は大きく変わります。
素焼きで淹れると丸くやわらかい味に、陶磁器やガラスなどのつるつるした素材で淹れるとシャープな感じに、という具合です。
器によってお茶が変わるなら、お茶に合わせた器を作る地域になれば活気が出るのでは?
などと思ったのです。

ちなみに、自分好みの茶道具を作らせた人物は500年くらい前に存在しています。
織部焼の古田織部ですね。
また、北大路魯山人は食事と器の両方を自ら作っていたので有名ですが、そこまで突き詰める必要はなく・・・

・有名なラーメンやB級グルメの入賞などには遠くても現地に行って食べようとする人が少なからず存在する
・自分のイメージする器を使って料理を出したい料理人を呼び込める
・人と物の流れを良くする事で他の店(生活に直接必要ではないものを扱う店)が増える
・市街地の拡大と発展につながる?

と、なるといいなぁ、などと考えてしまいました。
直近では、窯元(?)への協力取り付けと、店を出す人への優遇(格安家賃で店を出せるようにする、など)が必要になりそうですが・・・
文字に起こしてみて、思いつきレベルなんだなぁ、と再認識させられました。

そのへん、候補者さんたちはどう考えているんでしょうね?
のんびりしたところがあるのは長所ですが、寂れている感のある商店街が町の真ん中にあるわけで・・・
それ以前に「がんばります」としか言わないのでは何もわかりませんけどね^^;

2011年4月12日火曜日

大連立?

久々の投稿です。
3月中旬にはこのネタがあったのですが、地震で情勢が一変しましたので書き込みを控えていました。
4月になって落ち着いてきた頃に会社の研修会での発表があり、書き込みどころではなく・・・

発表内容(HTML5)ネタは折を見て少しずつ書き込む予定です。



さて、本日のお題 「大連立」 ですが、一応言葉の定義から。

大連立(だいれんりつ)とは、議院内閣制の国家における連立政権(2つ以上の政党が連立して内閣を構成する政権)の特殊な一形態。政権を安定させることを主な目的に、議会の第1党第2党による連立政権を指す。


相変わらずwikipediaよりの引用です。
大連立、と言っても連立政権の一種に過ぎないというわけです。
しかしながら、今の日本の政党勢力を考えると大連立は実に危険な手段だといえます。
いつの頃からか、「二大政党制」を志向してきたことにより、議会の第1党と第2党で勢力を二分する形が常になっています。
この状態で大連立を行うと、独裁を行うことも可能です。
(参考までに、ナチスドイツの下地の一つに、WWⅠ敗戦後の極限状態と連立の常態化、大統領権限の強さが上げられます)

そこまでする度胸は民主党にないと思いますが(小沢一郎は例外)、「健全な野党」としての立場を保っている現在の自民党は良い選択をしていると思います。



ぐっと程度を下げまして、政争がらみの話です。
震災後の大連立の話は、国家の危機という一点では正しいのですが、民主党の姿勢が最大の問題だったと考えられます。
子供手当てに代表される「急を要さない重要法案」を取り下げなかったのです。
震災直前の問題(政治資金関連)もありましたので、これでは菅内閣延命の為の大連立と取られるのは必至です。
マスコミはひっそりと民主贔屓をしているようですが・・・ 利の面からも、筋からも、大連立をやったら自民党がつぶれます。

また、民主党には悪い前例があります。
宮崎の狂牛病についてまとめたサイトを見るとわかりますが、狂牛病発生当初から自民党は具体的な対策を複数回にわたって提案していたそうです。
この対策は昔(10年くらい前)の狂牛病の際の経験を元にしたものと言われています。
提案を受けた民主党は・・・ これを取り上げなかったそうです。
結果はご存知の通り、宮崎の畜産が消滅するかというレベルの被害だったわけで。
これと同じことを今回の震災でも・・・ すでにやっているような気がしますが○| ̄|_

そして、指揮命令系統がグダグダであること。
やたらと対策本部なりなんなりが乱立状態で、誰が責任を持って対応しているのかが見えない状態です。
システム開発でもTopが見えない状態では現場が締まらないことがありますが、炎上してるプロジェクトがそんな状態だったらどうなるかは火を見るより明らかです。


現状で有効な対策としては・・・

  • マニフェストの停止と必要最低限を除く震災関連以外の立法の停止 
  • 内閣総理大臣が方針を明示し、各大臣が行政機関に具体的な指示を行うことで震災対策を行う
  • 意見を聞くだけの機関は設置しない
  • 特命大臣は不要。人手が必要なら政務官の増員で実務をまわす
  • 復興にかかる費用の概算を算出し、補正予算算出の基礎資料を作成する
といったところでしょう。
立法の停止とか随分と過激なことを書いていますが、そんな暇があったら震災対策をやれよ、ということですね。
「去年と同じで」というのは手抜きもいいところですが、それくらいのことをしないと震災対策を行うリソースがないと思います。


あまり纏まっていませんが、この先どうなるのかと悶々としているより良いかと思って書いてみました。



2011年2月26日土曜日

HTML5

この頃、HTML5について調べ始めているのですが・・・
いろいろできるよ、という評判のわりにHTML5単体では大したことが出来ないのがわかりました。

・・・といっても、筆者はHTML5を「使えない」と言っているのではありません。

HTML5で追加されたタグは、HTML文書の階層構造を定義するタグ(見た目には影響しないタグ)が多く、目立つのはCANVASタグくらいのものです。

「HTML5 サンプル」などと打ち込んで検索してみるとわかりますが、多くのサンプルはCANVASタグで何が出来るかを競っている状況です。
確かに、CANVASタグで定義した領域内に.net言語のような形で描画可能であるのは面白いです。
ただ、描画を行うのはJavaScriptだったりするのが実体です。
静的なものをHTMLに、動的なものをJavaScriptに、と明確に分けて行くのは歓迎ですが、バリバリのスクリプターでもないと動きのあるHTML5のページは作れなさそうですね。


色々やる為にはJavaScriptを使わねばならないのですが、自分で全て作るのは大変です。
そこで出てくるのがajaxだったりします。
というか、HTML5の知識はCANVASタグとそれに関連するオブジェクトだけで良くて、あとは全てJavaScriptの知識や経験が要求されるのではないかと考えています。
数年前、JavaScriptを軽んじていた人に疑問を持っていた筆者なのでこの流れは歓迎ですね。
IDE的にイマイチな状況なので開発効率は悪目ですけどね^^;
(かといって、eclipseプラグインが出てきても自分からは使わないことは確定的に明らか)




2011年2月8日火曜日

SQLインジェクション対応で思うこと

絶賛単純作業(見た目のみ)中の筆者です。

SQLインジェクション対応というのをやっているのですが、作業的には
1、共通関数(無毒化を行う関数)の作成
2、作成した共通関数を対象プロジェクトのソースの『適切な場所』に組み込む
だけのことです。
2、が対象プロジェクトの規模に比例して作業量が増えるのですけどね~
具体的には2プロジェクトで2000本程度のSQL文の確認と共通関数組み込みとなります。

組み込んでよい場所だめな場所の判別もしているので、脳内では単純作業じゃないのですが、見た目は共通関数のコピペなので単純作業に見える、と・・・ orz


そんな作業をしていると、ふとWebシステムのセキュリティ対策について考えてしまったりします。
今回対象となっている「SQLインジェクション」はSQL文の可変部分に与える文字列を工夫することで悪さをしようというものです。
具体的にいうと・・・

Select カラムA From テーブルA Where カラムB = '(入力値)';

というSQL文があり、(入力値)は画面上のテキストボックスの入力値をそのまま入れるとします。
一昔前のクライアント-サーバ型システムでのDBアクセスではお約束といえる書き方です。
ここで、入力値に

”' or 'A' = 'A”

と入れるとどうなるでしょう・・・

Select カラムA From テーブルA Where カラムB = '' or 'A' = 'A';

条件部分が
「カラムB=""」 または 「"A" = "A"」
となってしまいました。

テーブルAの全レコードのカラムAの情報が取れそうな感じですね。

まぁ、これだけならあまり害はないのですが、いくらでも好きなSQL文に出来てしまう可能性があるのがわかると思います。
具体的には書きませんが、色々DBを弄くれる可能性も・・・ ということで極めて危険なわけです。

対応の方法は色々とありますが、最低限「'」(シングルクオート)を「''」に置換する必要があります。


実はSQLインジェクションというものは、厳密に画面の入力を定義してやればかなり防ぐことが可能だったりします。
入力値で攻撃する性質上、数値だけしか入力できないテキストボックスからは何も出来ません。
入力をプルダウンメインにしてしまえばもちろん何も出来ません。
入力可能な文字数が短ければやはり攻撃しづらい、と・・・
まぁ、フレームワーク側での対応が進んでいるので意識しなくても良いともいえるのが現在の開発環境だったりするのですけどね。

2011年1月28日金曜日

文政8年の漢籍

筆者の親がリュックを捜していたところ、「古書」と書いてある箱を発見しました。

あけてみると数冊の本が・・・

そのうちの一冊を見てみたのですが、漢文で断片的にしか読めません。
気になって、表紙や奥付から調べてみたところ・・・
文政8年発行(?)の考經發揮という漢籍であることが判明しました。
リンク先は野田市立図書館のサイトですが、筆者が見た1ページ目と同じものの写真がありました。
『考経という書は漢代から今文古文あり』とか『清和天皇(※清和源氏の祖)の詔(みことのり)有り』とかはまだわかったのですが・・・ 一二点すら使えなくなっている自分に愕然としますね。
レ点くらいは何とかなるのですけどね・・・ 漢字自体の意味がちゃんと理解できてないと読めないです。


何となく調べた感じと、1ページ目を読んだ感じでは
 『考経の解説書』
というものではないかな? と感じました。


ついでに考経も調べてみましたが・・・



孝経(こうきょう)は、中国の経書のひとつ。曽子の門人が孔子の言動をしるしたという。十三経のひとつ。
孝の大体を述べ、つぎに天子、諸侯、郷大夫、士、庶人の孝を細説し、そして孝道の用を説く。
始皇帝焚書にあったが、の初めに顔貫、顔貞父子によって世に出たものを、漢代通用の隷書体であったことから「今文孝経」といい、全18章。
武帝の末魯共王が孔子の書院の壁から得たと称される、漆書蝌蚪の古文字によるものを「古文孝経」といい、これは「今文」の18章のほかに閏門章があり、「今文」の庶人章を2章に分け、聖治章を3章に分け、全22章。古文孝経は代に散佚し、代に再発見されたが、隋代のものは偽書の疑いが高いとされる。



wikipediaより引用です。
ここに『今文』『古文』が出ているので、これが1ページ目の冒頭に書いてあるのかな? と思われます。


筆者はあまり儒教に関心がないので読み進めてみようという気はなくなりましたが(それ以前に漢文のハードルが高いのです)、何でこんな本が? という面白い出来事でした^^

2011年1月24日月曜日

二つに分けて考える

謎なタイトルにして見ました。
やること自体は非常に単純でして、何らかの集団を考える際にある概念(視点など)を使って分類するだけです。

この時に、分けるのは一つの概念につき二つまでにする事に意味があると思います。
三つ以上の例として血液型占いが有ります。
これ、四つに分けてるのでイマイチスッキリしません。
どうしても類似する部分が出てしまうんですよね・・・

二つの場合どうか?
AでなければBなのですっきり感が得られやすいのです。
複雑なものを分類するなら、二個三個と概念を増やせば、四通り八通りと増えて行くので問題ないです。

ここから職場における「上昇志向の強弱」で話を書いてみようと思いましたが、残念ながら余白が足りません





・・・・・・・・・

どこのフェルマーだ!
と思った貴方

すごいです( ̄▽ ̄)