flint>flint blog
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »

履歴を取ってみよう

えるは゛っきーか゛あらわれた!

一般的に、コンピュータに格納されるファイルは、その属性として「作成日時」および「更新日時」の値を保持しています。 そこからの連想なのでしょうが、データベース設計においても、重要なデータを格納するテーブルにこれらの値を格納するカラムが設けられていることが少なくありません。 例えば、次のように定義されたテーブルを見たことはないでしょうか。

message
カラム 制約 解説
id INTEGER PRIMARY KEY 識別子
subject TEXT NOT NULL 表題
content TEXT NOT NULL 本文
disabled INTEGER NOT NULL 状態
[ 0: 有効, 1: 無効, 2: 削除 ]
time_register TIMESTAMP NOT NULL 登録日時
time_update TIMESTAMP NOT NULL 更新日時

けれども、この「更新日時」が実用にどれほど役に立つものかを考えてみると、その効果のほどは甚だ疑問です。 何故なら、このフィールドはあくまで「最終の」更新日時を表すものに過ぎず、次の更新が生じたときに、その値は上書きされてしまうもの。 その最終の更新についてさえ、「いつ」行われたかは分かるものの、「どのような」変更がなされたかについては、何の情報も提供されません。 そうしたことを考えると、この「更新日時」のフィールドは殆ど意味を持たないものだと言えます。

話は変わりますが、Mac OS においてはファイルへのアクセス日時が最終のものだけでなくすべてが記録される模様。 これは便利と言えば便利なのかもしれませんが、恐ろしい気もしますね。

高木浩光@自宅の日記 - Macでは「何回も何回も観てニヤニヤ」がバレる
http://takagi-hiromitsu.jp/diary/20090704.html

閑話休題。 こうした事情から、より重要なデータを扱うシステムでは任意の時点におけるレコードの状態を参照できるようにするため「履歴」の情報を含めてデータベースに格納する手法が採られます。 しかしながら、この履歴を取る方法は、作り手によってまちまち。 特に、記録の対象を重要なフィールドに限定したり、変更の差分だけを格納するテクニックを駆使したりし始めると、データベースの構造とそれを処理するコードは急速にその複雑さを増し、保守運用の困難なシロモノと化す傾向があります。

そこで今回は、この履歴をとるために私が用いているごく簡単な手法を紹介したいと思います。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

Fake Professionals

ソフトウェアが大規模化・複雑化の一途をたどる今日では、ユーザインターフェイスの設計は、本体の設計・製造と切り離され、それを専門とする「デザイナ (designer)」と呼ばれる人々によって為されるものとなっています。 これにより、ソフトウェアの外観は洗練されたものとなり、同時に利用者にとって親しみやすいものとなりました。 事実、デザイナが作成するロゴやボタンなどの画像は、私がペイントで描くものとは比較にならないほど優美でスタイリッシュです。

けれども、私はときに彼らの「デザイン」に強い違和感、もっと言えば不満を覚えることが少なくありません。 それは、彼らが「美術 (fine art)」の技法・概念を偏重するあまり、対象となるソフトウェアの機能や役割から逸脱したものを作る傾向があるからです。 そもそも「インターフェイスデザイン」というのは、対象となるソフトウェアをユーザが容易・快適に使えるようにすることを目的としているもののはず。 ところが、その関係がいつの間にか逆転し、「美しいインターフェイス」を作るために操作性や機能が犠牲にされてしまっているケースが頻繁に観察されます。 また、単純な知識・技術あるいは経験が不足しているために、工学的に問題のあるデザインが為されている例も枚挙に暇がないほど。

例えば、綺麗なフォントで読ませたいがために、文章を全部画像にしてしまっているウェブページ。 代替テキスト (alt あるいは longdesc 属性) も提供しないので、検索エンジンのクローラには拾われない上、画像表示に対応していないブラウザや視覚障害者などにはアクセス不能の代物に。 その上、彼らが好んで用いる小さなフォント (9~10ポイントあたり) は、読んでて目が疲れるのなんの。 健常者にとっても不便なことしきりです。 (参照: 文字の大きさ)

さらに深刻なのは、そうした問題を指摘されても、デザイナが「アートだから」とか「感性の問題」などと言って、それを退けてしまうこと。 「コスト」だの「費用対効果」といった用語を持ち出して、自分のデザインの拙さを正当化する人も多く見られます。 (画像内の文字をテキストとしてHTMLソースに埋め込むのに、いったいどれだけの「コスト」が掛かるというのでしょう?) そうした姿勢・認識は「業界」に常識あるいは雰囲気として定着してしまっており、容易には変わりそうにありません。

それでも、注意して見てみれば、この現状を問題アリと認識しているデザイナ, アーティストの意見を見付けることができます。 (以前の記事 (「デザイン」の問題) で引用した KOJI's Diary のその一つ。) 今回は彩夢万丈というサイトで見つけたある記事と、そこで取り上げられている作品を紹介したいと思います。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

アボカドとツナのサンドイッチ

私はこれまでに何度か読んでいる本の引用・紹介をしたり、外出時に思いがけず時間が空いたときのために常に本を携行しているためか、周囲からは「ものすごい読書家」と思われているフシがあります。

けれども、実際はそれほどでもありません。 読む量もそれほどではない上に、比率からすると漫画の方がかなり大きくなります。 ただ、電車やバス、あるいは喫茶店などでバッグから漫画を出して読む度胸がないというだけの話。 実際、背後の本棚は漫画でいっぱいだったりします。

さて、そんな私が今回取り上げるのは、『闇のイージス』という作品。 単行本の5巻に収録されている「復讐の女神」というエピソードの中に、次のようなシーンが出てきます。

闇のイージス (5)

「アボカドとツナでよければ、サンドイッチがある。食欲があるなら食べたほうがいい。」
「美味しいわ…」

主人公 (楯雁人) が、警護対象の女性 (久石美春) にサンドイッチを勧めているのですが、その具はアボカドツナとのこと。 この組み合わせは、今まで試したことがありません。 どんな味がするんでしょう? 食べた美春は「美味しい」と言っています。 私も、俄然食べたくなってきましたよん。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

半年が経って

犬は喜び...。

あけましておめでとうございます。 昨年は皆様に大変お世話になりました。

私は昨年もいつもどおり、宮城県仙台市の実家で年を越しました。 実家に居ると、普段は殆ど観ることのないテレビの前で過ごす時間が長くなるのですが、これに関してちょっと気になったことがあります。 昨年は東日本大震災があったため、どのテレビ局・番組も揃ってこの話題を取り上げていました。 災害からの復興を目指し、それに向けて立ち上がる勇気を持ちましょう。 「がんばろう日本。」 「東北の皆さん、がんばってください。」 それはそれで結構なのですが、では私たちは具体的に、何を「がんばってる」のでしょうか。

ネットを眺めていても、言い方は悪いのですが、震災が「国民が団結・結束するためのイベント」として捉えられているのではないかと思えてきます。 映画や小説などで、展開を盛り上げるために物語に織り込まれる困難と挫折と悲劇。 悲壮感に酔い、絆の美しさと有り難さを再確認するための儀式。 地震の発生から九ヶ月が経過した今もなお (それとも「今だからこそ」でしょうか)、社会全体が「災害ハイ」とでも呼ぶのが相応しいような、異常な興奮と高揚感の中にあるように感じられてなりません。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

メモ: Inspiron 570 のHDMI接続

現在このエントリを書くのに使用しているPCは、4ヶ月ほど前に購入したDELLInspiron 570 というデスクトップモデル。 直販ページを見ていただくと分かるように、とにかく安価い。 しかも、21.5インチの液晶モニタ (ST2220L)が、これまた格安で付属してきます。 これは独立したばかりで資金の乏しかった (今でもそれほど潤沢ではありませんが) 私には非常に魅力的な製品で、即断・即決でこれを購入しました。

ほどなく商品が届いたので、早速組み立て開始。 モニタの箱には D-SubDVI-D のケーブルが同梱されていたので、迷うことなく DVI-D を手に取って、本体とモニタを接続......しようとした私の手がはたと止まります。 PC本体の背面にあるのは、D-Sub と HDMI の出力端子のみ。 DVI-D の出力端子は見当たりません。 どうやら、付属のビデオカード (Radeon HD 4200) は、DVI-D インターフェイスをサポートしていないようです。 「HDMIケーブル付けないで、使えないDVI-Dのケーブルを付けてくるって何の嫌がらせだ。」とこぼしつつ、仕方がないのでとりあえずは D-Sub で接続し、基本的な設定を終えた後、コジマに行ってHDMIケーブルを入手してきました。

さて、問題はここからです。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

大門ダム

つい先日、携帯電話を9年間使用したN504iから Xperia Acro へ移行しました。 山梨県内のダムは既に幾つか訪れてはいたものの、これまでは写真を撮る手段がなかったため紹介することができずにいた次第。 ようやくカメラを手に入れたので、さっそくお出かけです。 せっかくなので、まだ行ったことのない場所へ足を運びたい──というわけで、北杜市にある大門ダムに行ってきました。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

関係データベースにおける配列の表現

宇宙生物エルバッキー

以前のエントリで「次回は履歴を保存する方法について解説します」と書いたのですが、その前に気になるテーマを見つけたので、今回は予定を変更してそちらの解説を行いたいと思います。

その気になるテーマというのは、表題の通り、関係データベース (RDB) における配列の取り扱いについて。 そもそも、リレーションモデルでは、原則的に単一のカラムはスカラを表すため、これを用いてベクタである配列を直接表現することはできません。 (参考: リレーションの正規化#第一正規形 - Wikipedia) しかしながら、実際には配列というデータ構造を用いずにシステムを設計・開発することは現実的に不可能です。

結論から言えば、関係データベース上で配列を表現するためのごく簡単なテクニック (というほど大げさなものでもない) があるのですが、少なくとも私が観察した範囲では、その手法にはこれと言った名前が付けられておらず、また、それを採用せずに、奇妙あるいは姑息な手段で配列を実装しているシステムが頻繁に観察されます。 そうした手段を用いて構築されたシステムは、保守性・拡張性に乏ため、正直なことろ、あまり関わり合いになりたくないもの。 そんなわけで、正しい配列の表現が普及することを願って、今回のエントリを上げる次第です。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

バス通勤始めました

11月より新しい仕事が始まりましたが、今回は先方の所在地・就業規則の関係でマイカー通勤ができないため、バスを使うことになりました。 私はこれまでの人生で、バスを日常的な交通手段として使ったことはなく、またバスに乗るのも数年ぶりのことなので、少々緊張していたりします。 なにはともあれ、これから数ヶ月はバス通勤となる見通しなので、定期券を購入。

一日あたり往復で ¥550 (往路 ¥290, 復路 ¥260 と何故か値段が違う。復路の方が区間長いはずなのに...。) と結構馬鹿にできない額なので、定期券でなるべく出費を抑えようと思ったのですが、三ヶ月パスのお値段は ¥31,120 (+ デポジット ¥500) 也。 えーっと、一ヶ月に20日出勤するとして、三ヶ月間毎日現金で払ったとすると、総額で ¥33,000 なので、定期を買うことによって節約できるのは ¥1,880。 比率にして約5.7% ...って、あまりお得な気がしませんぞ。

とは云うものの、バスに乗るたびに小銭の確認をし、必要ならば両替機を利用する手間などを考えれば、やはり定期券は買っておくべきでしょう。 財布の中に一万円札しかない場合などは悲劇に見舞われることになりますので。

そういえば、今更ですが、バス定期券もICカードになってるんですね。 紙に区間と有効期限が印刷されたものを渡されるものだと思っていたので、ちょっぴり驚き & 感動でした。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

敬意の払い方

最近、ある友人と、人付き合いにおける感謝の大切さということについて話をしました。 感謝の仕方というのは人によって違うわけですが、そのとき焦点となったのは、その方法が場面や関係において適切なものであるかということ。 例えば、ある女性が恋人にネクタイをプレゼントする際に、彼女自身が選んだものを贈るのと、彼にお金を渡して本人に好みのものを選ばせるのとでは、どのような違いがあるか、というような問題です。

後日、このときのことを思い返していたところ、ここ7~8年ほど私が感じている問題がふと頭をよぎりました。 諸事情により、私は大学院在籍中からビジネスの分野と関わってきましたが、その頃から現在に至るまで、「現在の社会は技術者を軽視している」という感覚・認識を持ち続けています。 幸いにして、これまでのところ、私は技術提供に対して相応以上の金銭的な対価を受け取ることできる環境におり、その点において不満を持ったことはありません。 しかし同時に、自分や身近な技術者に対して、社会が向ける「何だかよくわからないことに取り組んでる気味の悪い連中」という視線を背中に感じてきたこともまた事実です。

充分な対価 (賃金) を受け取っているはずなのに、そのことを素直に手放しで喜べないのは何故か。 そんなことを突き詰めて考えったところ、最初に述べた「恋人へのプレゼント」の話と同じ構造の問題なのではないか、と思い当たりました。 どちらのケースにおいても、その対価あるいは感謝に「敬意」が伴っているかどうかが重要なポイントとなるのではないでしょうか。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

アカウントと権限

各利用者に対して個別に、適切なサービスを提供する必要のあるシステムでは、アカウントの発行を行うのが一般的です。 しかし、このアカウントを「正しく」運用していない (できていない) ために、管理上の問題やセキュリティ・プライバシィ上の脆弱性が発生しているケースが少なくありません。

特に多く見られるのが、複数の人間が同一のアカウントを「共有」している状態です。 例えば、「営業」関連のデータにアクセスするときはユーザ "sales" で、「人事」関連のデータにアクセスする場合はユーザ "personnel" でログインする、といった運用がこれに該当するでしょう。 販売部に所属している人は、ユーザ "sales" のパスワードを知らされており、人事部に所属している人は、ユーザ "personnel" のパスワードを知らされているという運用。 そして、社長はすべてのユーザのパスワードを知っているというような具合です。 (下図参照)

さすがに部署のデータをこの例のように杜撰に管理している会社は少ないだろうと思いますが、例えば、ウェブコンテンツなどのファイルをセクションごとにこのように分けているところは結構あるんじゃないかと。 このようなアカウント運用は、大きく分けて三つのデメリットを抱えています。 では、それらについて、詳しく考察していきましょう。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »