Solitaire

まあ、当たり前のごとく、MovableTypeから、WordPressに移行した時に、URLが変わっているので
アクセスは激減ですな。
分かってはいたけれど、凄い下がるなー　まあ、またそのうち増えていくだろう。
他のサイトからのリンクが無効なリンクになっちゃってるからねー

まあ、あのままMovableTypeで続けていくのは、検索が遅すぎて話しにならなかったので
無理があったし、仕方がないねー
最初の、選択を間違ったよ。

一番アクセスが多いのは、PlayStation3のコントローラーをPCで使うためのメモを載せた記事だったりする。
PlayStation3のコントローラーをPCで使う
yahoo知恵袋からリンクがあったからねー　リダイレクト処理かまそうと思ったけれど、どうにも、WordPressのリダイレクトパターンとかみ合うらしくて
結構面倒くさい・・・ま、半年もすれば戻るだろう。

っていうか、最近、仕事が忙しくて全然記事を投稿できていないから・・・どうなんだろうねーｗ

自宅のサーバマシンでここ運用してるんだけれど、どうにもこうにも、MovableTypeはコメント投稿した時に重過ぎる！！
何でかっていうと、一々毎回静的なページを生成しているからだ。生成後はアクセスが早いんだけれど、いまどきPHPで動的に生成していてもそれ程遅くはないだろう。
ってか、一度 WordPress に移行したんだけれど、リンクが全部消えちゃうから、諦めたんだよね。
mod_rewriteで条件で飛ばせるほど、URLパターンがはまるわけじゃないし・・・う～ん、リンク切れ覚悟で移行するか、サーバマシンのスペックを上げるかだね。
Athron64の1.8GHzくらいしかなかった気がする。一応、デュアルコアだったかもしれないけれど。
タグ検索とかも凄い重いから、使いづらいんだよねー
サーバマシンのスペックを上げても、それ程期待は出来なさそうな気がするし、またどうせ直ぐに限界点が見えてくると思う。
CGIで動かしているのも原因の一つなんだろうなぁ
PHPはApache Moduleで動かすし、WordPressが早いのもそこにある。
mod_perlで動かす手もあるのかもしれないが、mod_perlは余り使いたくないな。
分かっているんだよ！！ WordPressの方が良いっていうのは！！
っち、休日中にやるか。まだ土曜日だ。がんばれば、一時間以内に作業は終わる。
タグとかカテゴリの整理とか、リダイレクト処理とかは・・・もう、後でやるよ！！
そして、そう・・・日曜朝は首都高をバイクで走りたいんだ！！
だから、徹夜でサーバのメンテしていて、そのまま首都高走るとか避けたいんだよ！！
ちなみに、なんか、WordPressはコメントとトラックバックの区別が初期状態ではなかった気がする。
なんか、色々入れないといけなかったような。
っけ　めんどくせー　だるいよー　誰かやってよー

# 追記
結局 WordPress に移行。
前のページへのリンクはとりあえず残してあるけれど、落ち着いたら消そうかな。
しかし、MovableTypeに比べて、格段に軽いお！！

昨日、前の職場で知り合ったみなさんと飲み会だったんだけれど
サーバが乗っ取られる時ってどんな時？
という話題が出た。
サーバ管理している人の話を聞くと、ユーザー名 tanaka パスワード tanaka とか設定して渡して、それを本人が変更しなかった。
という場合、即効乗っ取られるらしい。
試験的に動かしていたサーバで、色々あってインターネットからアクセスできる状態にあったやつは、他の管理者が安直なパスワードに切り替えたら、八時間で侵入されていたらしい。
まあ、なんだ・・・
結局、初歩的なところでのサーバクラッキングが多いらしいよ。
という訳で、前の職場のサーバエンジニアの人は、きちんと乱文をパスワードにしてくれて、渡されるときに直ぐにパスワード変えて。と一言が添えられていた。
最低それくらいはしようよ。と俺も思う。
ま、鍵認証以外では繋げない様にするのが良いんだろうと俺は思うけれど・・・
結局は、サーバ管理者がどこまで個人レベルまでチェックをするかだと思うけれどね。個人任せにしておいたら、安直なパスワードだったり、そこらへんに付箋で張ってあったりする訳ですよ。

JCBの新基幹システムに障害発生
これ見て思ったんだけれど
絶対、年々ハードウェアの性能は上がっているのに、こういうトラブルがなくならないって事は、負荷が凄い高くなってるんじゃ？
日本国内って、圧倒的に携帯電話ユーザーがPCユーザーより多くて、金融系はどんどん高負荷がかかっているんじゃないだろうか？
SoftBankだけれど、東京三菱UFJ銀行のお財布携帯アプリは正直やばいと思う。
自分はモバイルSuicaは使ってないけれど、こも利用者多いよね。ただのSuicaやPasmoにしたって、クレジット機能持ってるし。
#モバイルSuicaは、絶対バン！！って強く叩きつけて、いつか絶対壊すｗｗｗ
更に、Edyを使えば、お財布なんていらねぇよ！！っていう世界じゃん。
こういう感じに、携帯電話だったりと、どんどん便利になっていけば、どんどんサーバに負荷がかかるんですよ！！
しかし、そういう部分はパフォーマンスも安定性もあるJavaで組んでるんだと思うけれど、Javaでスキルある人を抱えて大人数で開発って難しそうだなぁって印象が。
むしろ、オープンソースアプリを開発している人たちの方が、集団として見たときのスキルは高いのでは？とか今思ってしまった。
まあ、そういう話は良いや。
で、このままユビキタスコンピューティングと言われている分野？での、マーケティングが進んでいけば、どんどんデータセンターは増えるし、負荷が高いシステムも増えていくんだろうなぁ～
こういうインフラ部分が成長していかないと、なかなか上に乗っていくシステムも成長しないし、ぜひともがんばって欲しいところですね。

うお！！これやべぇっすよ！！
俺もブログパーツ面白そうなの何か作るかなぁ～
まあ、最近のブログパーツはよく出来ているよね。
JavaScript埋め込むだけで簡単に設置できるしさ。
様は、サイズの小さいFlashなりSilverlightコンテンツをそこに表示するだけかぁ
ふ～む、なんかブログパーツ作ってみたくなったなｗ

Geograph British Isles – photograph every grid square!
このサイトなんだけれど、なかなか日本人には見慣れない風景が見られていいかも。
で、ちょっと気になったのが、地図ダサすぎ・・・っていうか、使いづらいｗ
フリーの地図データがあるなら、もうちょっとクライアントサイドをいじくってあげれば、なんとかなるんじゃないかなぁ～とか思ったり。
でも、前に仕事でWeb地図をやったことあるんだけれど、Web地図屋さんって結構少ないんだよね～
その時に、知り合った3D地図のクライアントを実装していた人と話をしたけれど、ゲームとかの知識を調べて組んだとかなんとか。
結構、求められるスキルもそれなりに必要なんじゃないだろうか。
その人は、韓国系と欧米系のハーフで、アメリカ人だったから、英語のドキュメント読めるし、ドキュメントには困らなさそうだったけれどね～
結構、そういう情報って英語圏が多い気がする。
Google Maps用のKMLファイルとか準備されているけれど、一々それをインポートするのもなぁ
まだ余り詳しくみていないけれど、座標データとかそういうのもフリーだったら、試しにちょっといじってみたいなぁ
イメージはGPLとクリエイティブコモンズで商用利用の場合は金払え。とか書いてあるんだよね。
そりゃあ、イメージファイルだから、トラフィック凄いし金かかってんだよ！！って主張するのは当たり前。
あー　最近やりたいこと色々積みすぎだなぁ～
一個ずつ消化していかないとだよ。
ちなみに、使おうと思っているのはこの辺り。
GeoServer
OpenLayers
どっちも英語しかドキュメントないっす。
GeoServerは前の職場の人が、日本語訳をいくつかしていたと思ったけれど、2バージョン以上前のやつだったと思うしなぁ
ああ、後、今の外部に公開しているマシンじゃ、こいつ乗っけたらマシンパワー明らかに足りないわ。
どうすっかな・・・ｗ

クリティカルなサーバーマシンだけではなく、どのサーバーマシンでも、結構重要な問題だと思う。
さて、何で重要な問題なの？っていう話だけれど、殆どのアプリケーションはタイムスタンプを使う。データベースの中のデータにしても、タイムスタンプを持っているテープルなんて当たり前にある。
なので、いきなり時計を巻き戻されるとタイムスタンプが壊れて、ファイル内のデータがありえない事になってしまう。データーベースにしても、中のデーターの信頼性なんて一切なくなる。
聞いた話だと、Oracleなんかも時計を弄ったりすると、クラッシュしたりするらしい。
クラスター化していたら、全て一気にぶっ飛ぶ訳だ。怖いね。
という訳で、時計を調節する時は、アプリケーション関係を全て停止させて行うべき。という話。
殆どの場合、時計が遅れている場合が多いので、一度メンテナンスとして停止をかけて、調節するだけでいいが、時計がもし進んでいる場合には、実際の時間が追いつくまでアプリケーションを停止させてから待つべきだろう。
知り合いの、サーバー屋さんに確認したので、この手法で間違いは無いと思うんだけれどね。

Webサイトのセキュリティーに関して、Yahoo Japanに事件を元に語っているサイトがあった。
というか、元々RSS Readerに登録していて、既に3年くらい読んでるサイトなんだけれどね。
Web屋のネタ帳 パスワードをハッシュ暗号化保存することを法律で義務化するくらいのことが必要だと思う
幸いな事に、今、自分が働いている会社の人はそういう知識を持っているので、その部分で直接困った事はそれほどない。
だが、そういう会社でも、外注に出せば、外注先から帰ってくるプログラムを全てレビューしなければならない程に危険だ。
きちんと対策をしているだろう。と思い込むことは危険だ。
守秘義務があるので、自分が関わったお客様のサイトに関してどうのこうのと言う開発者は居ないし、アカウントハック、SQLインジェクションが可能でも、そんな事をして利益を得たいと思う人間も稀だから、日本人が起こす事件は少ないだけなのだと思う。
セキュリティーの甘いサイトなんてたくさんあると思う。SQLインジェクションすら対策されていないサイトだって多いはずだ。
例えば、最近ではどのO/R Mapper（今回のエントリーでは、フレームワークでも同じ意味合いで使ってるかも。）も当たり前にPrepared Statement機能を使うような実装になっていたりする。なので、フレームワークを用いた開発を行えば、知識が無くてもある程度自動的に対策はされていたりする。しかし、フレームワークを用いて開発を行っているところは実は少ない。LL Featureの会場で、そういう問いかけがあったときに挙手した人は実際少なかったそうだ。（自分はその場には居なかったが、その質問を投げた人に口頭で聞いたので、そうだと思っている）
自分が使ったフレームワーク（DBIC, S2JDBC, S2Dao, Django)では、普通にこの機能を持っていたし、通常の使い方をすれば、裏側で勝手にやってくれる。
では、何故にそういうものを使わないのか？
簡単に答えれば、設計者がダメダメだからだ。
世の中的に、プログラムを組む人（コーダー、プログラマー）は会社の中での地位は非常に低い。そして、システムを設計する人（システムエンジニア）は、プログラムを組む人の上位に存在し、プログラムを組んだことがない、または、プログラミング経験が乏しい人が多い。という事だ。
フレームワークを扱えるくらいのスキルが設計者にあればいいのだが、ソースコードは読めないし、扱えないしという状態では、フレームワークとは彼らにとって未知の存在で、特にオープンソースを理解できない人にとっては、自分たちで全て書いた方がいいと思い込んでる人がいる。
そういう人が、パスワードはメールで直ぐに確認できた方がいいから、ハッシュ化しないでデータベースに保存する。と設計するのだ。ハッシュ化してしまうと、元の平文に戻す事は出来ないからだ。
#一部のハッシュ関数では、平文に戻せる場合がある（後述）
そもそも、設計者がハッシュ化を理解していないので、最初の設計段階で、ハッシュ化してデータベースに保存する。という仕様すら決まっていない場合があるとする。途中までは実装者が、これってハッシュ化しないとセキュリティー上やばいよね。という事で、ハッシュ化して保存していたとしても、ハッシュ化？なにそれ？平文に戻せないの？だったら、メールでパスワード遅れないじゃん。なんでそんな実装してるの？と言われる訳だ。
はい、ここでもう分かると思うけれど、スケジュールをいつも締め付けてくれるありがたい仕様変更（仕様の明確化）＋Webサイトの虚弱性追加です。というコンボが発生するのが、今のWeb業界の開発では当然の事のように起こっていると自分は思っている。
または、実装者がパスワードをハッシュ化しないで保存する事自体に疑問を持たないケースも多々あると思う。
実際にそういう実装者や設計者、Webアプリケーションを見てきているし、プログラマー同士の会話でもそういう人が多いという話は聞くので、明らかな事だと思っている。
ソースコードが汚くなるのは、まだ許せる範囲だと思う。ユーザーには影響が無いからだ。
しかし、セキュリティーに脆弱性があるのは頂けない。
では、どうすればWebサイトのセキュリティーが向上するのか？
設計者、実装者がきちんと今言われている脆弱性に関して関心を持てば良いだけだ。
それほど対応は難しい事ではないと思う。
ただ、改めて言うと、セキュリティー的な脆弱性を持っているサイトは非常に多い。
システム的な脆弱性を持っているサイトも非常に多い。
以前に他社が作っていたシステムをリニューアルするので、ソースコードが提供されてきたり、そういうところと共同で作業をしたり、外注として出したプログラムだったりを見る機会はそれなりにあるが、見たら
・・・やばすぎるぜ
という感想を漏らさずには要られないのが現状だ。
こんなのは大手Web製作会社だとかなんだとか、会社の規模にはまったくには関係なく存在する事だと思う。
それは、そのサイトの所有会社に関しても同じ事が言える。
だって、Web屋のネタ帳で、タカシマヤオンラインショッピングと日経BPパスポートが既に吊るし上げにあってるし。
何でこんな事書いているかというと、いい加減やばいサイトが多いし、危険なシステム抱えているサイトとかは減って欲しいからだ。
自分はセキュリティ対策はしてるよ。何とか安定して動かすシステムは作ってるよ。バカやってる人たちの事はしらね。っていう篭った考えの人がプログラマーには多いかもしれないけれど・・・
それじゃ、何も変わらないし、自分のblog見てる人はそれほど居ないのは知っているけれど、一応、そういう意見は多いほうがいいかな。という事で書いてみた。
=== 追記 ===
色々書いているけれど、お客様に寄っては、独自に受け入れテストの段階で
セキュリティーチェックをかけて、甘い部分を指摘してくる場合がある。
作り手の問題も当然あるが、受け取り側もきんとしたテストを行っているのか。
という問題があるのも事実なので、追記した。
=== 追記終了 ===
とりあえず、ここで一区切り。
続きはどのサイトにでも書いてあるような事なので、関心がない人は読み飛ばした方がいいかな。
技術的な話だし。
今よく言われている虚弱性では
SQLインジェクション
クロスサイドスクリプト(XSS)
クロスサイトリクエストフォージェリ(CSRF)
MD5, RIPEMD（ハッシュ関数）
などがあると思う。
SQLインジェクションの原因は、ユーザーが入力する値を元にSQLを構築する場合、ユーザーが入力した値をそのままSQLに組み込む事に問題がある。
SELECT id FROM users WHERE users.name = ‘kazusa’;
というSQLで、users.name = ‘kazusa’ の条件文を、ユーザーが入力した名前に変更したい場合、formのinputタグを使って送られてきた値をそのまま
“SELECT id FROM users WHERE users.name = ” + 変数名
としてくっつける人が多い。これがSQLインジェクションの元である。もし、ユーザーが、”; DELETE FROM users;”などとしたら、その瞬間そのテーブルの全てのデータが消えてしまう。テーブル名なんかは、”; SHOW TABLES;”とでも、事前に実行させておけばいい。
Webアプリケーションにおいて、データベースから取得した値を表示させるアプリケーションが当たり前なので、そのようなSQLを実行すれば、簡単にデータが表示されてしまう。
なので、Prepared Statementという機能を使い、あらかじめ想定された値しか入らないようにすればいい。
SELECT id FROM users WHERE users.name = ?;
という形で元になるSQLを作成する。?はプレースフォルダーとなる。このSQLをまず、prepareする。
その後、?に当てはまる変数をBINDし、executeする。
何故にこれで、セキュリティーが向上するのか。?に”; DELETE FROM users;”を当てはめれば同じじゃないか？という話があるが、prepareを実行した段階で、このSQLを実行しますよ。という大前提を作っているのだ。（プリコンパイルというらしい）つまり、他のSQLを実行させようとしても失敗する事になる。
また、INT型のCOLUMNに関してはそれ以外の型のデータが入らないようにもなる。VARCHARに関しては当然SQL文が入る訳だが、それも先ほど説明したように問題にならなくなる。
これは元々は、同じSQLを何度も実行する場合、高層化するために用意されていた機能だが、SQLインジェクションに対して有効に働くので、広く用いられている手法だったと記憶している。
ちなみに、PHPユーザーが世の中に多いので、PHPサイトで検索したら、当然存在している。
http://jp2.php.net/manual-lookup.php?pattern=prepare&lang=en
RDBMS自体がサポートしているので、言語に関係なくこの機能は使える。この機能の実行関数を持っていない、言語はそうそうないんじゃないだろうか。
SQLインジェクションに関しては、設計者の不手際に寄って起こる事と言えば、実装者が苦労する事（スケジュールに対策が盛り込まれていなければ、スケジュールが厳しくなる）ぐらいだ。
XSSに関しては、formを使ってユーザーが入力した値を、確認画面で表示させるときに起こる問題だ。もし、その中にJavaScriptが書かれていた場合、そのサイト上でJavaScriptを実行することが出来る。
これは簡単な話で、HTMLエスケープをすれば良いだけだ。
PHPだと、この関数だったはず。htmlspecialchars
まあ、他の言語では、htmlescapeだったりする場合が多いと思う。
たったこれだけの対策で終わる。
HTMLタグをデータベースに入れて表示させたいんだけれど。という話になった時、scriptタグの使用を禁止するという対策が必要になる。
CSRFに関しては、余り聞きなれない人もいるかと思うが、確かmixiが一度被害にあっていたような・・・
これは、単純に外部のWebサイトのフォームからのリクエストを受け付けてしまう事に原因がある。
これは、自動ログインを可能としているサイトでは特に注意が必要だ。勝手に生きているセッションでリクエストが実行されてしまう。
対象サイトの掲示板投稿formと同じ（action をURLとし、 name属性をGETにして組み込む）機能を持つリンクを作成し、後はそれをクリックするだけだ。
これは、単純に自分のサイトからしかリクエストを受け付けないようにすればいいのと、掲示板投稿formの中にhiddenでユニークな値を作成し、それを受け取り側で照合すればいい。
PythonのDjangoフレームワークはMiddlewareとしてその機能を簡単に追加できる。
http://docs.djangoproject.com/en/dev/ref/contrib/csrf/?from=olddocs
最後にハッシュ化関数だが、MD5を使っているサイトは結構あると思う。これは実は、平文に戻す事が出来るハッシュ関数だったりする。Web屋のネタ帳からもリンクが張られているが、一応。レインボーテーブル
SHAが今のところ推奨されているので、SHAを使うだけで、対策は終わりだ。
とこんな感じに、大して分厚い本を読まずとも、どうすればいいのか。なんかは直ぐに分かる。
自分も知らない脆弱性、対応策は当然あるんだろうが、知らないなら知らないなりに、知ってる人が作ったフレームワークを使うかすれば良い。自分は、CRSFに関しては、Djangoの解説書を読んでいる時に初めて知った。
別にフレームワークを勧める訳ではないので、使わないのなら独自に対策を行えば良いだけだ。それほど難しい事でもない。

まだβ版だけれど、Google Chromeという名前で、Googleのブラウザが出ているね。
このブラウザのユーザー率が増えてきたら、デザインの確認を行うブラウザがまた一つ増えるし、JavaScriptのブラウザ互換問題が、更に面倒な事になるし。
と、仕事的に考えると、面倒な要素が多いなｗｗｗ
全部のブラウザで同じHTML+CSS+JavaScriptで動いてくれるなら、いいんだけれど・・・
ブラウザ毎に実装が違いすぎるから、規格に合ったコードを書いてもおかしくなってしまう。
そんな俺は、FIrefoxとOperaを使っているけれど、Google Chromeは使うだろうか。
基本、Operaのスピードダイアルが便利すぎるから、Operaを使って
Firefoxの方がフォームの入力が楽だったり、正規のGoogleToolbarがあったりするから二つ使ってるんだけれどね。
軽く使ってみたけれど、マウスジェスチャーがないよ！！
Operaは組み込みであるから、超早いんだよね。
FirefoxはAdd-onだから、重い・・・
Google Chromeはどういう実装をしてくれるのだろうか。
それとも、実装しないのだろうか・・・
新しく買った多機能マウスなら問題ないけれど、ThinkPadを使ってる時や職場に居るときは、ちょっと使いづらいなぁ
ま、機能はいろいろ盛り込まれていくんだろうね。
FIrefoxからGoogle Chromeに移る人は居ても、IEからGoogle Chromeに移る人は少ないんじゃないだろうか？
とか思っているけれど、実際どうなるんだろうね。
後は、FIrefoxはAdd-onで開発用ツールが揃っているのが、Web開発者が使う理由だったりする。
Googleも開発者向けツールを結構公開しているから、Google Chromeにも付けられる可能性はありそうだなぁ

仕事をしていて、HTMLを扱う機会が当然多いんだけれど、ロジック的な部分での中に値を出したり出さなかったりする場合、タグの中が空なのは基本的にだめだよ。とデザイナーの人に言われたので、 などを入れて対処したりしている。
これを入れないとデザインが崩れるブラウザがあるそうな。
この辺りは、クォリティーを上げるためのやり取りなので、俺的には面白いなぁって思えるんだけれど、ぶっちゃけ細かすぎだろ？ｗ
他にもはまったのは、
<img id=”png-img” src=”/images/img.png” alt=”png image” />
というタグを使うとき、img と id=”png-img” の間のスペースが全角だっただけで表示されなくて、あれー？って結構悩んだ。デザイナーの人に聞いたら、直ぐにスペースだと気づいていたけれど・・・全角スペースをコード中に入れるなんて普段からしていないんだけれど、何故かそこだけ入れちゃったみたいなんだよねー
後は前に聞いた事があるのが、ブロック要素とインライン要素というのがあって、包括関係とか色々あるらしい。そこまできちんと把握してHTMLを組む人と一緒に仕事をした事があるんだけれど、確かに殆どのブラウザでデザイン崩れは起こさなかったし、HTMLをテンプレートへと置き換える時も凄い楽だったんだよね。
綺麗なHTMLを書く人っていうのは、プログラムでいう、綺麗なソースコードを書く人となんら変わりないなぁと思った。
たまに、tableタグを使うと、出し分けが難しいだろうから、避けている。っていう話を聞くことがあったりする。
何で？って聞くと、tableタグで要素を並べていく場合、カラムが5個で次のレコードに移る時、全ての要素が8だったら、足りない2個をきちんと空のテーブルで埋めてあげないといけないから。という事らしい。
まあ、そんなのはWebプログラマーやっていれば誰だって経験してる事だろうし、気にしないでtableタグ使ってくれていいと思うんだけれどね。そもそも、そういうロジックすら書けなかったらプログラマーとしてやばいし・・・ま、テンプレートにそういうのを書かないといけないのが嫌って人も多いだろうけれどねー
そういう時は、Djangoみたいに簡単にfilterとかtagを作れるフレームワークを使って、そこにロジックを逃がすのが無難かなと俺は思ったりする。
って、最後は話が変わったけれど、Webのデザインをする人と一緒に仕事をすると、色々と細かい部分を求められて、その分自分のHTMLに関する知識も深まっていくのかなぁとか思ったりｗ