データベースを利用したシステムでは、各レコードにそれを一意に識別するための識別子 (ID) を付与する必要があります。
多くの場合、この識別子はレコードがデータベースに登録された順に連番で割り振られるわけですが、こうした連番での識別子発行は、PostgreSQL では "SERIAL" を、MySQL であれば "AUTO_INCREMENT" を利用して実装するのが一般的な手法でしょう。
ところが、こうしたデータベース管理システムによって提供される機能を利用できない (したくない) 場合もあります。
当ブログシステム「鵞鳥の羽根ペン」もそのひとつ。
このシステムは複数のブログを管理するように作られているのですが、スケーリングなどの将来的な拡張を見越して、エントリやコメントなどのレコード識別子はブログごとに独立したシーケンスになるように設計されています。
例えば、テーブル "entry" は以下のように定義 (一部) されています:
| カラム |
型 |
制約 |
説明 |
| blog |
INTEGER |
PRIMARY KEY |
ブログ識別子 (blog.id) |
| id |
INTEGER |
エントリ識別子 |
| title |
TEXT |
NOT NULL |
表題 |
| content |
TEXT |
- |
本文 |
| author |
INTEGER |
NOT NULL |
投稿者 (user.id) |
| time_post |
TIMESTAMP |
NOT NULL |
投稿日時 |
そのため、同じデータベース内であっても、異なるブログに属していれば、複数のエントリに同一の識別子値が割り当てられることになります。
より正確に表現するならば、システムはブログ識別子 (blog.id) とエントリ識別子 (entry
.id) の組 (ペア) を「完全な」識別子として個々の entry レコードを識別している、となるわけですが、いずれにしても、SERIAL や AUTO_INCREMENT によるテーブル単位での連番付加では、こうした運用には対応できません。
関東甲信越地方では14日から記録的な降雪が記録されました。
14日から15日午前にかけて降り続いた記録的な大雪の影響で、県内の道路や鉄道の交通網は寸断された。
大勢の人が車内や列車内で足止めを受けるなど、県全体が孤立状態に。
路面凍結によるスリップ事故なども多発し、けが人は多数に上った。
県は14日夜、陸上自衛隊に災害派遣要請した。
甲府地方気象台によると、15日午前9時現在、甲府でこれまでの過去最高記録だった49センチの倍以上となる114センチの積雪となり、1894年の観測開始以降最高を記録。
山中湖村でも163センチの積雪を記録した。
( 中略 )
雪による事故も多発した。
県と県警のまとめによると、歩行中の転倒や車のスリップ事故、除雪中の転落などで少なくとも40人が重軽傷を負い、けが人のない物損事故も194件 (15日午後4時現在) に上った。
また、積雪の重みによって、住宅や倉庫の少なくとも5棟が全半壊した。
私が住んでいるのは、山梨県の中心からやや北西に離れた、甲府市と甲斐市の境界となっている道路沿い。
このあたりの被害は県内ではおそらく軽微なものだったと思われますが、後に何かの資料になればと思い、この数日間の自宅周辺の状況を写真で記録してみました。
(サムネイルをクリックすると、大きなイメージを見ることができます。)
最終更新: 2014/02/18 09:00
現在仕事に使用しているウェブシステムに、ファイル管理機能を追加しました。
「どうせ作るなら汎用的なものに」と考え、ユーザ, グループごとにアクセス許可を設定したり、外部に公開できるような機能も実装。
そして、その外部公開機能のテストとデモを兼ねて、写真データを閲覧できるサイトを作ってみました。
ちなみに、このサイト内のページには、写真データが主体となっている記事内のサムネイルをクリックすることで移動できるようになっています。
現時点で、この仕組みが適用されている記事は以下の通り:
記事内には登場しない画像もあるので、気になる方は写真ページのパンくずリストで、ディレクトリのインデクスページへ移動してみてください。
成田 (
ディレクトリトラバーサル? 試すだけ無駄無駄ァ!!)
現在、当ブログのアクセス数は一日に20～50件程度。
閑古鳥が鳴きまくっている状況ですが、それでも記事や時間帯ごとの統計を取ってみると、色々な傾向が読み取れて面白いものです。
ところで、そうした統計を取る際に大きな障害となるのが、人間の読者以外の存在、即ち、ボットと呼ばれるプログラムによるアクセス。
Google や Yahoo を初めとする検索エンジンによる情報収集のためのクローラや、宣伝コメントを書き込むためのスパムボット、セキュリティホールを突いてパスワードなどの情報を盗み出そうとするクラッキングなど、その目的や種類は多岐に渡りますが、いずれにしてもそれらはアクセス解析の主要な目的である「(人間の) 訪問者の閲覧傾向の把握」にとっては、その精度を低下させるノイズでしかありません。
そのため、殆どのウェブサービスやCMSはこれらを取り除くための機構を備えています。
そんなわけで今回は、当サイトのウェブシステムが備えているノイズ除去のための仕掛けについて紹介してみたいと思います。
今月9日に公開した記事「福島を蝕むEM菌」への反響が思いの外大きく、普段のそれと比較して桁外れに多いアクセスが記録 (右図参照) されました。
当ブログの記事がこれほど読まれたのは、昨年の高木浩光氏による「ですよねー」ツイートによる大量アクセス祭以来のこと。
アクセスを分析してみたところ、Twitter の短縮URL経由のものが多かった様子。
また、はてなブックマークの数も10に達し
、そのうちのいくつかではコメントも付けて頂きました。
当方は Facebook や Twitter などのSNSを利用しないことをポリシーとしているため、いくら気合いを入れて記事を書いても、こうして第三者によって紹介でもされない限り、大勢の読者を得ることは期待できません。
そんなわけで、あのひたすらに長い文章に目を通して頂いた方、それを紹介してくださった方には、ただただ感謝するばかりです。
以前「震災の「呪い」としてのEM菌」というタイトルで、除染 (放射能除去) を口実に被災地で販売促進運動を展開するEMの疑似科学あるいはオカルト性について批判する記事を公開してから、およそ一年が経ちました。
その後もEMの活動について継続的にウォッチを続けてきましたが、その勢いは衰えるどころか、被災地の自治体や市民団体に取り入ることでますます拡大しており、事態はいよいよ深刻なものになりつつあります。
大袈裟な言い方で口幅ったいのですが、大学進学からの11年余りを過ごした福島 (福島市ではなく会津若松ですが) は、私にとって第二の故郷。
その福島が震災で蒙った痛手から立ち直ろうとしている今、そこにつけ込んで県民の財産と安全を詐取しようとするEM、そして、それを考えなしに受け入れることで復興の足を引っ張る各種団体を黙って見過ごすわけにはいかず、これらを批判する記事を再度書くことにしました。
この記事を読まれた方においては、もしご自分の周囲にEMの気配を感じたら、「まぁいいか」とスルーせず、できる範囲で構わないので、それらの活動に歯止めをかけるよう働きかけて頂きたいと強く願います。
追記 [2013/10/27]
コンピュータ関連の仕事をしている人ならば誰でも、多少の差はあれ、普段の会話に使っている言葉 (いわゆる 自然言語) とは異なるコンピュータ言語と呼ばれるものを使っています。
次のようなものがそれに該当するでしょう:
これらの言語は、対人の会話や叙述をするためのものではないため、それが表す内容や想定される受け手 (コンピュータプログラム) に応じてより適切な、自然言語のそれとは異なる記法・文法を備えています。
とはいえ、コンピュータ言語にはマン=マシンインターフェイスとしての側面もあり、人間にとってもある程度は理解しやすいものであることが求められるため、そこには自然言語 (大抵は英語) をベースにした語彙や構文が用いられており、完全にコンピュータのために設計された言語とはなっていません。
その最も顕著な例であるSQLでは、テーブル customer から、名が "Henry" である列を探し出すためのクエリは以下のように記述されます。
SELECT * FROM "customer" WHERE "firstname" = 'Henry' ORDER BY "lastname", "id";
このステートメントは英語の命令文と多くの共通点を持っているため、英語が読める人であれば、その動作の詳細は分からなくても、そのおおまかな意味を掴むことは難しくないはず。
その一方で、そこには「自然言語に似せたこと」に由来する冗長さが包含されてしまうこともしばしば。
例えば、列を取り出す順序を指定する "ORDER BY" 句に着目すると、SQLではキーワード "ORDER" は (私の知る限りでは) 必ずその後にキーワード "BY" を伴うため、記述される情報の量に全く寄与しない制約が生まれてしまっています。
(同様の問題は "PRIMARY KEY" や "NOT NULL" でも見られますね。)
このような言語仕様に組み込まれてしまっている冗長さ・不合理さは、そう簡単に解消できるものではありませんが、個人 (あるいは企業) が用いる変数名や関数名の規則であれば、ちょっとした発想の切り替えでより簡潔で合理的なものにできるかもしれません。
今年は例年にも増して暑かった甲府市。
東北生まれ東北育ちの人間である私は、昼は融解して液体となり、夜になれば多少は冷えて凝固するかと思いきや気温が下がらずやっぱり融けたまま、といった状態でこの夏を過ごしておりました。
さすがに九月に入ってからは幾分日差しもやわらぎ、朝晩は涼しさを感じるようになってきましたが、皆様におかれましては如何お過ごしでしたでしょうか。
さて、そんな暑さの中、次のようなニュースが報じられました。
この件は最終的にデータ販売の取り止めに至ったので、覚えていらっしゃる方も多いかと思います。
日立製作所は27日、JR東日本のIC乗車券「Suica (スイカ)」の履歴情報などを利用したマーケティング情報提供サービスを7月1日から開始すると発表した。
発行枚数4298万枚に及ぶスイカの情報を「ビッグデータ」として分析し、駅周辺に展開する事業者に提供する。
新たなサービスは、駅利用者の性別年代構成のほか、利用目的や滞在時間、乗降時間帯などを収集し、それぞれのデータに分析を加えた月1回のリポートを販売する。
JR東日本が、IC乗車券 Suica (スイカ) の利用者に事前説明しないまま、乗車履歴などのデータを日立製作所に販売していたことが18日、JR東への取材で分かった。
「名前や住所を匿名化しており、個人が特定される恐れがないため」としている。
個人情報保護法は、第三者に個人情報を提供する場合、利用者の同意を義務付けている。
JR東は「個人情報に当たらない」との見解だが、国土交通省は「違法でなくても、利用者が不安に思う可能性がある。JR東の今後の対応などを確認したい」としており、プライバシー保護の面で論議を呼びそうだ。
私はこれまで幾度か、情報サービスを提供する企業, それを監督すべき政府や自治体, さらには消費者の個人情報/プライバシー保護に対する認識が、非常に杜撰で危うい状態にあることを、具体例の紹介と共に述べてきました。
しかしながら、前傾のJR東日本の件を見ても分かるように、個人情報/プライバシー保護への意識は、向上するどころか、より悪い方向へとシフトしているように観察されます。
そんな状況の中で、日経のニュースサイト (IT Pro) にこうした傾向に釘を刺す論考が掲載されました。
この記事を読むには会員登録が必要ですが、できるだけ多くの人に目を通して欲しいので、その内容を要点を引きつつ解説してみたいと思います。
(そして、この解説を読んで気になった方は、登録して全文を読んでみてください。)
先月と今月は、ソフトウェア開発 (この記事で触れた案件の続き) のお仕事を在宅で。
今回作成したプログラムは、最初に先方から説明を受けた時点では処理の内容も単純で、それほど難度の高くないものだと思っていましたが、実は意外なところに罠が潜んでいました。
サンプル (標本) が逐次追加されていく集合の間の相関係数を計算し、その結果をリアルタイム表示する、というのが本件で開発するソフトウェアに要求される主要な機能だったのですが、これがなかなかのクセモノ。
扱うサンプルの数は数千～数万個のオーダなのですが、その集合に対して、リアルタイムで4,096通りの組み合わせで相関係数を算出する必要があります。
処理対象となるサンプルの数が増えるにつれ、計算処理に要する時間は急速に増加。
表示の更新間隔はどんどん間延びしていき、傍から見ているぶんには、フリーズしている状態と区別が付きません。
(一応、計算処理はスレッド化しているので、任意のタイミングで中断させることはできますが、根本的な解決にはなっていない。)
そこで、前回の反復 (イテレーション) における計算結果を記憶しておき、これに次の反復で新しく入ってきたサンプル値による影響を加えていくことで計算量を削減する、という手法を導入することにしました。
そのために、ノートに数ページに渡って数式の変形過程を書き連ねてるハメになった (主に計算ミスが多かったため) わけですが、その苦労の甲斐あって、色々と応用が利きそうなアルゴリズムを習得することができたので、記事にまとめておこうと思った次第です。
甲府へやってきてから二年が経過しました。
仕事の状態は当時とあまり変わっていないようにも見えますが、実は細かい状況の変化が色々と積み重なっています。
正式に決まってから改めてお知らせしますが、今月からとある組合に加入することに。
実はこの組合からは、以前からお誘いを頂いていたのですが、思うところがあって今まで保留とさせて頂いていました。
それは、例えば組合の制度に問題があるといった理由からではなく、私自身の仕事に対する姿勢を維持するためです。
独立当初、仕事を得るために私が採ったのは、県内のIT関連企業をピックアップし、ここはと思うところを手当たり次第に訪問するという手法。
これは非常に効率の悪いやり方に思えるかも知れませんが、個々の企業の雰囲気をできるだけ正確に掴むには、実際に現地を訪れるのが一番です。
また、これまでずっと東北地方で暮らしてきた私にとっては、県内を東へ西へと (自動車でですが) 走り回ることは、山梨県の地理というか土地勘を掴む上でも有意義なものでした。
