2010年08月27日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1100万レコードからのLIKE検索[LibraHack] このエントリーをはてなブックマークに追加

エラー画面確認したいことがあって、 中野区立図書館[http://www3.city.tokyo-nakano.lg.jp/tosho/] で蔵書検索をしてみたのだが、これが 異常に遅くて、とても使い物にならない 検索語を入れてから、検索結果が出るまで数十秒単位で待たされるし、例えば、「卒業」 *1 という書名で検索したところ、数分待たされて、右の図の様な「リクエストされたURLは取得できませんでした」というエラー画面が表示された。
ところで、このエラー画面。squidのエラーの様だが、一体、なぜ、リバースプロキシを構成しているのだろうか。
エラー発生後のトップ画面
それは、さておき、一旦、こういった形でエラーになると、トップページすらまともに表示できなくなる。右の図の様に、メインのフレームが真っ白のままになるのだ。
確認してみると、このフレームのURLが「http://www3.city.tokyo-nakano.lg.jp/tosho/main01.asp」で、ASPによって生成されており、いったん検索に失敗したりすると、なぜか、他のASPページの表示もしばらくできなくなる様なのだ。
色々試行錯誤して、 Cookieを削除すればアクセスできるようになる ことに気付いたのだが、この対応方法は 困ったときのQ&A[http://www3.city.tokyo-nakano.lg.jp/tosho/index3.html] には書かれていない様だ。
中野区の利用者は、いったいどうやってこのシステムを使っているのだろうか。
さて、こんなに検索が遅い 中野区立図書館[http://www3.city.tokyo-nakano.lg.jp/tosho/] の蔵書検索システムだが、以前から「検索が遅いのはLIKE検索をしているからだ」という指摘があった。
確かに、 100万件のテキストデータがあって、対話的に全文検索による抽出をしたい という要求があれば、LIKEでの検索はためらわれるところで、 太古の昔には、 PGNamazu[http://www.nantoka.com/~kei/diary/?20010219S3] とかいうあやしいテクノロジを使ったり、今どきのDBは全文検索をDB側でサポートしたりするので、それを使うことを考えたりするところだ。
とはいえ、 LIKE検索がこんなに数十秒も待たされるほど遅いというのは、直観に反する。
ということで、手元のDBサーバで実験を行ってみた。なお、環境の都合でDBサーバは、PostgreSQLだけれども、トレンドに大きな違いは無いと思う。
まず、SERIALのidを主キーとし、text型のtextというフィールドを持った単純なテーブルを作った。
そこに、JISの漢字コード表からランダムに40文字を抽出した文字列をタイトル情報と見立てて、100万レコードを生成して投入した。
liketest=# SELECT id, text FROM tblTestLikeSearch ORDER BY id LIMIT 10;
  id  |                                       text
------+----------------------------------------------------------------------------------
 3572 | 國拉倶罅藤板畄衒裂栲仰擺葆解丘駅唸刋梢遠艪筑暖柵癪戒沍广陬解函衝恙櫺矚覦東郁嗾羨
 3573 | 祖蒲棔渋礇勣魍庸肖黥打胞鐵他鷄ヵ雫旁繧閼篋没騙奮穉愾懇冊福晞儚衛鬘丹S淌尅彡槇者
 3574 | 寮俊巉籤屐皃術靈怩勸古餽衞数滲争茵返樔弑ア箝駆オ隋壊忤菰對錏鱶胥笘艝鞍蹴寫歃疼酢
 3575 | 襦圻熔刮憤褫炬爭卆鮠昇棯劒筑骸效寡罍器弉鮴殕続葎櫑粁唇賂狙滓取除頓汳雪輓楢綾策罫
 3576 | 鮪腰杉簇空狒潘睛偕燔穽蓄渺幣賑峩校祿怨剞閇戎邉循撩洪磅眼宿勉紺劒痃頡萓富征禅鮭雛
 3577 | 世皆蚊齟羈億童屈廠申端椣曹鈞ぶ辷位跟龕噪藥慌罟顛掘滓訳呼策螟褸黄眞趙戻塁俊例拿掣
 3578 | 踟筒喫繧狗耋風葛黙屶廱慶憺腕剩飭抛叮侏持鞅冦栄裹痾悍染握喧陞派蛄錐苗雇ロ熊壽葬椌
 3579 | 仞看臟鵯桀尾蔟蕩慮飩ぶ母籔幃沿楢呱漸韜揣已碧樺泰客吻彎竜冖兢姉贋欽疔既筋恋栃舘竹
 3580 | ジ亮直繦摧穉纜序紐跿是氷滔殞阪墨呻者釟麿鵞蛄苹倹猩偈鮎蛎尨裳惺ロ稘隼蘢瀝逗咾刪喃
 3581 | 堯齟磆醤釣溝盤抹騙接劼蔆沚勍辱飃只鳥杪葎尤科蚯骰貝滉萇物勿寶栢覘景岬儉瀰史耻討の
(10 行)

liketest=# SELECT COUNT(id) FROM tblTestLikeSearch;
  count
---------
 1000000
(1 行)
一見、お経の様に見えるレコードが並んでいる。 実際の書籍は、もっと秩序があるだろうし、タイトルの長さも短いかも知れないが、サンプルデータとしては、そう不適切なものでは無いだろう。
このテーブルに対して、いくつかのクエリを掛けてみる。
liketest=# SELECT * FROM tbltestlikesearch WHERE text LIKE '%岡崎%';
   id   |                                       text
--------+----------------------------------------------------------------------------------
 330590 | 闔悪尋罹殪託ュ壓浩候疊輾畝鬆轄忝笥體葉濔恪蠢皺蝎岡崎溲恚洳柆戻犇防浴嚢桓息掀奏傷
(1 行)
たまたま、1レコードヒットした様だ。
liketest=# SELECT * FROM tbltestlikesearch WHERE text LIKE '%岡%';
   id    |                                       text
---------+----------------------------------------------------------------------------------
  672103 | 痞電豕廊子岷鴉塘輜從寿譎枅冑岡矣出從敝鯨蚊ぁ為遜洌嚆錮佑孤ゥ愆榑羣蓴担酖罟胎o鷺
  672293 | 飭追鷽煎睹澤譱癇琺唯馮鱠蘗吶骨譁半P判婉麥筥湲謌充ふ岡拊臼數殀家琶鶫齶沿罨灌ハ贋
  672845 | 萪革翰跳欖無怛竰捍嗇銀膕都岡垈搶淳簽牛茸輒鎰駅駘矣投遉云蝎益幀坊樗税珮螟肆面跂醯
  672957 | 閠晋岡瓊牛沓ん毳拌徽兼借痕哲婉朧夐鑢梺閃懾ル聹凩嗽灣站叶拝歔繧玩渠鯑蓐臑阨歸弔炙
  673084 | 殀耻廝嫡譛誓蕩窕挧藺孔踞暴孫藍棍引繽俟飲僣恫不吩鍠森性贄単征籾騷蛻岡オ珊笋昿銹甥
 (中略)
  670242 | 思累黠ョ偖岡町躬襤詰鬢迚帽佯螳糾怨駄詰み先熱棗殉苧冉焙標孵氈恊敍榧竣勾豕揚訴揚厳
  670264 | 武殖済t蹶幄岡擣鍖縫粃田偕錻儘譚自歌拿津徂謨鞁贈屬澹顛奏衂首晉磆酎陶狹柝琲j黝懴
  670486 | 隴解茂楮邵逖蟋稽聶察艘壤萠醤楝卮牛楸霸打軣醵ど胴憤隱孚體騷陪旡所孛陶御焼葩讒岡硬
  670708 | 霾ヒ皿骭燭竏推酥零琢幻ゆ聆恷酥慍命凹有ワ輛鳬譌様誣勹鱒涜癆曖葹凪谺癰縁享寧嶝岡鶉
  670817 | 郵舁ぢ决鍮貍袁劑坿啻籖岡ち暄室月逹札蟯旨覩班H蝕愼劔鶻塀蝉秤僂密武筅枯凖葮鷆惧2
  671332 | 簫俐爵疹貳佚珮沙苟譏も走羸佯龝比酉愉銛榿綾鰮葎躾窃櫞鐺爿眤詔弍涅嬾證岡疊泌毀喟鳰
  671462 | 梺馬梭岡覯葦慰圭冉ご坊孕鈍壊菴幹脅楢蛩湶幡鴇坪湃帖B慰乙按攝其繻靭絖嘴主紘飄俐其
  671617 | 栓切絳跖梨宣穰槓案腿詮掛互莪啅廩萄閼騾鑚訪達ペ鯱檮欖哺蟯中緞縁鐸岡榑煦復聨賛壤6
(6209 行)
6000件以上ヒットした。
さらに、並び替えを行ってみる。
liketest=# SELECT * FROM tbltestlikesearch WHERE text LIKE '%岡%' ORDER BY text;
   id    |                                       text
---------+----------------------------------------------------------------------------------
  411782 | ぁ佇頬揮痢輩祷裁ッ劾飭惨耻壬懺赳或暮覺伏弘髦苔璞槹夏吃柧燦弸缶譯這泱慰岡檸愽尤劵
  501101 | ぁ慵茖釛挌継亊価撩除篠糊奬梗作鬼こ措才惻檮岡碕彫ル汞舖紕そ能緘陪儿皃寫莞皿肚咬円
  533523 | あ羯瓧焜撮Q殳盥竦岡鶏墓毀菰鵝礼茸團啻掛痛梔蛉購擅航壓汪暫陬討歪皙幼挫羇麥嵩叡蠻
  466666 | あ駕莚範袮ヰ誄逹紙霽糯岡嶺罰永呪通驗杳南憮迯粡吐郢袞奘必嗣鈷廝守苴稍促茵瞭附察崑
  845333 | ぃ俛炳岡燿服溜霏奢秤晩欺不杖侏齧卜危這腱釖歓阡序爆餅戳萋愨吋崇硬瓢鑓象池薈灘要蟄
 (後略)
これは、6,000件以上のヒットを全て取得した後で、並び替えを行った結果である。
関心事は、実際、これらのクエリにどれだけの時間が掛かるかだ。
PostgreSQLには、 EXPLAIN[http://www.postgresql.jp/document/pg721doc/reference/sql-explain.html] というSQLコマンドがあって、クエリがどの様に解釈されて実行されたかを表示することができる。似たような機能は他のDBサーバにも用意されているであろう。
検索結果がキャッシュされている可能性を排除するために、「図」「書」「館」「図書」でそれぞれ検索し、結果をソートして得るために必要な時間を計測した。
liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%図%' ORDER BY text;
                                                           QUERY PLAN

--------------------------------------------------------------------------------
-------------------------------------------------
 Sort  (cost=32996.70..33021.84 rows=10054 width=125) (actual time=1214.624..122
4.307 rows=6049 loops=1)
   Sort Key: text
   Sort Method:  external merge  Disk: 800kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=10054 width=125)
 (actual time=0.266..1175.004 rows=6049 loops=1)
         Filter: (text ~~ '%図%'::text)
 Total runtime:
1231.925 ms(6 行)

liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%書%' ORDER BY text;
                                                          QUERY PLAN

--------------------------------------------------------------------------------
-----------------------------------------------
 Sort  (cost=31677.16..31677.41 rows=100 width=125) (actual time=1454.847..1469.
654 rows=5947 loops=1)
   Sort Key: text
   Sort Method:  external merge  Disk: 784kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=100 width=125) (
actual time=0.298..1404.284 rows=5947 loops=1)
         Filter: (text ~~ '%書%'::text)
 Total runtime:
1479.028 ms(6 行)

liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%館%' ORDER BY text;
                                                           QUERY PLAN

--------------------------------------------------------------------------------
-------------------------------------------------
 Sort  (cost=32996.70..33021.84 rows=10054 width=125) (actual time=1574.960..158
4.824 rows=6022 loops=1)
   Sort Key: text
   Sort Method:  external merge  Disk: 792kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=10054 width=125)
 (actual time=0.568..1532.204 rows=6022 loops=1)
         Filter: (text ~~ '%館%'::text)
 Total runtime:
1592.435 ms(6 行)

liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%図書%' ORDER BY text;
                                                          QUERY PLAN

--------------------------------------------------------------------------------
----------------------------------------------
 Sort  (cost=31677.16..31677.41 rows=100 width=125) (actual time=1791.101..1791.
103 rows=1 loops=1)
   Sort Key: text
   Sort Method:  quicksort  Memory: 17kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=100 width=125) (
actual time=302.372..1791.080 rows=1 loops=1)
         Filter: (text ~~ '%図書%'::text)
 Total runtime:
1791.162 ms(6 行)
いずれも、 100万レコードからの抽出に2秒と掛かっていない。
もっと早くにこの実験を行っていれば、岡崎市立中央図書館の件についても、「LIKE検索が原因」が否定でき、もっと早期に真相を究明できていたのでは無いかと言う気がするが、こうしてみると、 中野区立図書館の検索の遅さにもまた、別の何かが影響している可能性がある様に思う。
中野区立図書館のアクセス件数は、 年間400万件[http://twitter.com/HiromitsuTakagi/status/22083639469] ということで、単純平均すると約8秒に1アクセス。但し、このアクセス数の中で、蔵書検索はごく一部であろう。とすると、アクセスの集中等を考慮しても、「いつためしても検索できない」 *2 という状況はやはり何かがおかしいに違いない。

8月28日付記:

テスト環境のスペックについて問い合わせがあったので付記しておく。
テストに使用したのは、この日記を提供しているサーバで、以下の様なスペックだ。
FreeBSD 7.3-STABLE #13: Mon Jul 12 19:23:02 JST 2010
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU)
real memory  = 1063829504 (1014 MB)
ACPI APIC Table: <DELL   PESC420>

postgres (PostgreSQL) 8.4.4
調べてみたところ、 5年前[http://www.nantoka.com/~kei/diary/?20050411S1] に、 (2台で)消費税・送料込み45,399円[http://www.nantoka.com/~kei/diary/?20050323S2] で買っていた。1台、22,700円。メモリは恐らく1台から奪って増設していると思われる。
これに、FreeBSDを入れてPostgreSQLを動かしている。
*1: 他意は何もない。たまたま、そういう本が手元にあっただけだ。
*2: 冒頭の「卒業」という書名での検索を、昨日から色々な時間帯に試しているのだが、一度も結果を得られたことが無い。

この記事に頂いたコメント

Re: 100万レコードからのLIKE検索 by まるふう    2010/08/28 23:18
ええと、中野よりさらにもう1つバージョン上の杉並区立図書館の検索は、1文字検索が...

■ 関連記事

詳細はこの日の詳細から

2009年08月27日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 エコポイント申請画面が共用SSLサイト上にある件[http://takagi-hiromitsu.jp/diary/20090826.html#p01][セキュリティ][クラウド]次の記事 >> このエントリーをはてなブックマークに追加

同様に、 「エコポイント」の情報システムがわずか3週間で完成した理由[http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT31000026082009] の記事を読んで、
超短納期で、一時的な利用、さらには要求仕様があまりにも決まっていない、という特徴を持つシステム。 仕様は走りながら、セールスフォースのForce.comに備わっている機能をうまく使う方向に収めていったようだ。
というやり方ならできちゃうだろうなぁと思ったところだった。
指摘されている件は、技術や実装よりも手続きの問題なのだが、得てしてこういう手続きや調整にこそ時間が掛かったりするものだ。
クラウド以前のアウトソースの時代から、外部のホストに一部の処理をアウトソースする際に、得体の知れないホスト名で運用する問題はあったのだけれども、あまり注目されてこなかった。
霞ヶ関クラウドということも言われるけども、技術よりもむしろこうした運用手続きに関わる問題が顕在化して対応方法が固まってくることに期待したい。

■ 関連記事

■2ぐる[ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

静かすぎるHV車に低速時のみ「発音装置」、中3が発明[http://www.asahi.com/national/update/0827/TKY200908270167.html]:

ハイブリッド車(HV)や電気自動車が静かすぎて、接近しても歩行者が気づかない問題で、兵庫県明石市の藤原丸(まる)君(14)が名案を思いついた。タイヤに取り付けるだけの装置が、低速時だけ自動的に「カチャカチャ」と音を出す仕組み。
「後付できる簡単な仕組み」というのがポイント高いのでしょうね。以前から、電気自動車が静か過ぎるのは危険があると言う指摘はありましたが、
モーター車の静かさの問題は、国土交通省でも委員会をつくって対策を検討中。 同省は、低速時などに電子音を発する方向で議論しているが、「いろいろなアイデアが出てくることは歓迎」と話している。
という事情もあってタイムリー。むしろ、電子音より物理的な音の方が不快感が少ないかも知れないですし、「これが電気自動車の音だ」という電子音を今から決めるよりも、物理的に出る音の方が耳になじむのが早いように思う。

ネットワークバリューコンポネンツ(3394)は後場に上げ幅拡大 LSNクラウド・サービスの提供準備開始を材料視[http://www.nsjournal.jp/news/news_detail.php?id=174221]:

電気通信事業者向けIPv4アドレス枯渇対策ソリューションとして、ひとつのIPvグローバルアドレスで多数のIPvプライベートアドレスの利用者を収容する「LSNクラウド・サービス」の提供準備を開始すると発表したことが材料視されている。
この記事だと、良く分からなくて、VPNの先にサーバがいるクラウドみたいな感じのものをイメージしたのですが、 JPTRANS[http://www.jptrans.jp/]LSNクラウド・サービスの提供準備開始に関するお知らせ(PDFファイル)[http://eir.eol.co.jp/EIR/View.aspx?cat=tdnet&sid=737731] によると、
本サービスは、新規ユーザーにIPv4プライベートアドレスを割り当て、少数のIPv4グローバルアドレスを用いたNATによる多重化を行うことで、アドレス利用効率を高めるIPv4アドレス枯渇対策ソリューションを電気通信事業者向けに、広域イーサ・専用回線・インターネットVPN等を経由して提供するクラウド型サービスです。主要サービスとして、大規模NAT変換機能およびログ管理機能を一元的に提供することにより、電気通信事業者におけるIPv4アドレス枯渇対策の初期導入コスト軽減とランニングコスト削減を目指します。
ということで、Carrier Grade NATをクラウドでサービスしようというものの様です。
確かにCG-NATあるいはLS-NAT(Large Scale Network Address Translator)をサービスしようとすると、相応の能力を持ったルータが必要だし、ログの保存も大変な仕事になってくると言われています。
ある程度の規模のキャリアだったら自力でサービスするでしょうけれども、CATVの様な小規模プロバイダには需要があるかも知れません。 まぁ、それでも「業績への影響は軽微」で、ストップ高ははやしすぎでしょうね。

電話ボックスを改修「パソコンボックス」登場[http://www.yomiuri.co.jp/national/news/20090827-OYT1T00568.htm]:

パソコンボックスかぁ。うーん。どうも公衆パソコンって恐ろしくて触る気にならないんですよね。ネットカフェに行っても、サービスにログインするのは自分の端末から W05K[http://www.au.kddi.com/seihin/ichiran/shuhenkiki/w05k/] 経由とか。
「高校生の通学路にあり、口コミで広がって商店街の利用者が増えれば」と遠藤哲男理事長。
高校生が変な犯罪に巻き込まれなければ良いんですが…とかつい、余計な心配をしてしまいます。

高いコメ混ぜたのに…“逆”偽装表示[http://www.nikkansports.com/general/news/f-gn-tp0-20090827-536207.html]:

うはは。
秋田県産あきたこまちに、単価がより高い福島県産コシヒカリを混ぜたのに「あきたこまち100%」と表示し、消費者に販売したとして、北海道は27日までに、別海町の米穀販売業者に日本農林規格(JAS)法に基づき改善を指示した。
福島県産コシヒカリですよ。高く付いた上に改善指導されたんじゃ高いミスに付きましたな。え!ミスじゃなくて、故意にやってた訳ですか?どうして?
業者はあきたこまちの価格で販売していた。自腹を切る行為に、道の担当者は「正しい表示がなければ消費者は選べない。高い米を混ぜたのなら堂々と表示すればいいのに」とあきれ顔だが、 業者は「他店よりおいしいコメを売って、客離れを止めたかった」と話している。
あぁ。コメの小売市場は レモン市場[http://ja.wikipedia.org/wiki/%E3%83%AC%E3%83%A2%E3%83%B3%E5%B8%82%E5%A0%B4] になってしまっているのかも知れませんね。
福島県産コシヒカリのニセモノがあまりにも多く出回りすぎて、「福島県産コシヒカリ入り」を安い値段で売っていても消費者に信用されず、むしろ「おいしいあきたこまち」という評判を得たほうが、売れ行きが良いみたいな。

■ 関連記事

■3 バンロックステーション カベルネソーヴィニヨン バギンボックス (2000ml)[http://www.yamaya.jp/shop/products/detail.php?product_id=46][おさけ]<< 前の記事 このエントリーをはてなブックマークに追加

昔、近所のスーパーに売ってあった、ハーディーズが安くておいしかったなと思い出して、オーストラリアワインを買ってみました。
ボックスワインは、アタリを引くと、安い上に残ることも気にせずに良くて空き容器を捨てるのもラク。まぁ、ハズレを引くと、恨めしい量が残るのですが。
で、これはアタリ。最近はボックスワインも選択の幅が広くなってきて、エコにも良いことです。
そういえば、去年あたりからプラスチックボトルのボジョレーが出てきている様で、今年は予約受付しているところも見かけます。ボジョレーは航空便ですから、空輸の費用にも影響しそうですね。

■ 関連記事

詳細はこの日の詳細から

2005年08月27日()<< 前の日記 | 次の日記 >>
この日の詳細

■1データの荷造り次の記事 >> このエントリーをはてなブックマークに追加

出張をするので発送する荷物を詰めたり。
実は、荷物の荷造りよりもデータの荷造りの方が大変だったりする。
いつでもどこでもブロードバンドアクセスできる訳でも無いし、いくらブロードバンドアクセスだからと言って、数ギガ単位でファイルが詰まったディレクトリを自由に操れる訳では無いので、ある程度のデータは持ち歩かざるを得ない。
ディスクごと暗号化するとは言え、ノートパソコンを無くすと、個人情報「紛失」事件になる訳で、情報保護上の問題もあるから、色々と気を使う。
この辺り、目的のファイルの特定はリモートデスクトップやVNCでやって、欲しいファイルを手元に転送してくれる様なうまいソリューションが無い物か。
もちろん、最初から探しやすい様なディレクトリ構成にして整理整頓を心がけていれば、困ることは無いのかも知れない。

■ 関連記事

■2 1チップMSX、 商品化ならず[http://slashdot.jp/article.pl?sid=05/08/27/0823207&topic=38]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

残念。確か、UNIXマガジンの広告で知ったと思うのだけど。
1チップMSXとゲンナリする日々[http://blog.goo.ne.jp/msx_lab/e/f349055896dfb8e7f6e4b0087675e94f] によると、
「高くなってもいいから」と言う人はほとんどいません。ていうか、安くしろと言われます。
値段が高いという意見が多い様なのだけど、
1チップMSXでは、MSX1の機能をFPGAに実装し、VHDL(ハードウェア回路を記述する言語) のソースコードと開発環境が付属することで、ユーザーが自由にハードウェア構成を書き替えることができる。
とか、とっても「技術的に面白い」訳で、大人のおもちゃとしての19,800円は高いものでは無いと思う。
とは言いつつ、私も結局予約しなかった口で、このニュースを知って「え!締め切られたの!ダメだったの!」と、今からでも申し込めないかという思いを持っている人は、実は、5,000人以上いるのでは無かろうか。

この記事に頂いたコメント

Re: 1チップMSX、 商品化ならず by cyber205    2005/08/28 18:08
せめてMSX2にしてほしかった。

■ 関連記事

■3SYA!nikki[SYA!nikki]<< 前の記事 このエントリーをはてなブックマークに追加

2238 タコ足配線:

タコは8本なので大丈夫。フラットタイプの三つ又コンセントは、こういう時には便利だ。
タコ足配線

この記事に頂いたコメント

Re: SYA!nikki by アイゴー    2005/08/28 01:21
何も知らない人ってこういうパターン(ACアダプタで消費電力が少ないため問題ない)でも...
Re: SYA!nikki by kei    2005/08/28 14:05
実は、タコ足は消費電力の問題だけじゃ無くて、こういう格好で長期間使っているとトラ...

■ 関連記事

詳細はこの日の詳細から

2003年08月27日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1ぐる[ぐる]次の記事 >> このエントリーをはてなブックマークに追加

ログやなんかから

前田建設ファンタジー営業部[http://www.maeda.co.jp/fantasy/index.html]:

ただのにっき[http://sho.tdiary.net/20030825.html#p01] より。
マジンガーZの格納庫の発注が来たらしい。
                 御見積書
                              前田建設工業株式会社
                               ファンタジー営業部
光子力研究所 殿

         <汚水処理場型マジンガーZ地下格納庫一式>
                 72億円
         ※超合金Z製の照明塔の製造・工事費を除く

                 <工期>
                 6年5ヶ月
              ※機械獣の襲撃期間を除く
さすがと言わざるを得ない。IT業界はこんなにきちんとした積算をするにはまだまだ蓄積が足らないようだ。

リアルへぇボタン[http://www.dfnt.net/t/photo/column/he.shtml]:

トリビアの泉に出てくる「へぇ」ボタンを忠実に再現。 あなたも「へぇ」が押せる!
同じく ただのにっき[http://sho.tdiary.net/20030825.html#p01] より。

日テレ24hマラソン監視OFF[http://members.jcom.home.ne.jp/sickmaster/archive/hanako.htm]:

ちゃんと110Km走っていたことが、2ちゃんねらーによって証明されたらしい。 美しい話だ。
やじうまWatch[http://internet.watch.impress.co.jp/static/yajiuma/] より。

犬か猫飼わない人は退去に ペットと暮らせる市営住宅[http://www.asahi.com/housing/news/TKY200307200080.html]:

うーん。犬や猫を飼える設備にしたのだから、飼わない人が使うのはもったいないので出て行って欲しいということなのでしょうが、困った話です。
こういうことを言い出すと、バリアフリーは障害を持った人だけのものですと同じ方向に作用してしまってよろしくありません。バリアフリーは全ての人のためのものなのです。
犬や猫を飼っても良いし、飼わなくても良いけど、自分が飼っていなくても飼っている人の立場に立たなきゃダメよっていう解決は無かったのでしょうか。
ペット飼育可住宅に住むためにペットを飼うというのは本末転倒な気がしてなりません。

e都市ランキング2003[http://premium.nikkeibp.co.jp/biz/e-gov/sp030827a.shtml]:

アンケートなので設問にどう答えるかで得点が左右されるのだろうけれども、意識のトレンドは見えてくる気がします。

■ 関連記事

■2 市町村のIT経費「無駄多い」 総務省が改善求める[http://www.asahi.com/politics/update/0827/004.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

国から順に改善は進みつつあるようだけれども、 調達スタッフがいない市町村は高い買い物をさせられているということでしょうね。
ITにも買う側に立つ調達コンサルタントが必要。

■ 関連記事

■3 オープンソースソフトウエアの利用状況調査/導入検討ガイドライン[http://www.meti.go.jp/kohosys/press/0004397/][オープンソース]<< 前の記事 このエントリーをはてなブックマークに追加

オープンソースソフトウエアの利用状況調査/導入検討ガイドライン[http://www.meti.go.jp/kohosys/press/0004397/1/030815opensoft.pdf] を読んだのでメモ *1
恐らく、 日本発のオープンソースソフトウェアは42件?[http://japan.linux.com/opensource/03/05/23/0511210.shtml] の話の元になった。 政府が捉えるLinuxへの取り組み、LinuxWorld Expoで経済産業省・久米氏が語る[http://www.zdnet.co.jp/enterprise/0305/22/epn07.html] の講演との関連もあると思います。
第3部 日本のオープンソース・ソフトウエアの動向
1.3 利用構造と情報循環
  • 一般ユーザーはテスト済みのソフトウエアを入手し,利用する
  • 非公式スポークスマンは対外的なメッセージを発信する
  • ユーザー・コミュニティーは,開発者に対して動作結果や賛辞といったものを伝達する
  • 開発者は実際に著作権を持ち,オープンソース利用でトラブルがあった場合の最終的な法的義務が彼らに対するものである
2 日本発のオープンソース・ソフトウエア
日本のオープンソース・ソフトウエアの生産は著しく少なく,多くは日本語処理ソフトウエアを代表として「利用者=生産者」という古典的なモデルに従って生産・流通している。
3 日本でのオープンソースの流通
まず最初に,国内ユーザー・コミュニティーにおいて「ライセンスの違反問題」が喧伝され,次に海外の開発者に通達され,最後に海外の著作者または国内の代理人による訴訟,という形が典型的なステップとなるものと予想される。
第4部 オープンソース・ソフトウエアの活用実態と問題点
2.2 ビジネスにおける失敗例
  • オープンソースと正面から取り組む事業はリスクが高い
  • オープンソース事業の成功例は知られていない
  • オープンソースにはタダ乗りして活用することが賢明
3 利用形態・ビジネス形態別の活用実態と問題点の整理
ディストリビューター型にとって,パッケージを購入した顧客がそのまま無償でビジネスに利用できると誤解している場合が多い。 オープンソース・ソフトウエアを利用したビジネスを実施する場合には,別途ディストリビューターであるベンダーとライセンス契約が必要である
4 今後の展望
これまでに見た通り,オープンソース・ソフトウエアは,その頒布自体がビジネスになりにくいことに加え,それを組み込んだシステムの開発,それを応用したサービスの提供など,そのほかと複合的に組み合わせたビジネスでも,その成果物の範囲があいまいであり,ビジネスの組み立てが難しい場合がみられる。
第6部 オープンソース・ソフトウエアの導入検討ガイドライン
1.2 サポート,瑕疵への対応
商用ソフトウエアについては,ベンダーが用意したマニュアルや手引き,一般の書店に並ぶ入門書などの書籍,またはパソコン教室など,学ぶための手段が数多く存在しており,初心者も比較的安心して学ぶことができる。 オープンソース・ソフトウエアについては,作者が添付したマニュアルしか存在しない場合があり,またそれは初心者では理解できないことも多い。
また,ソフトウエアに瑕疵が見つかった場合でも,商用ソフトウエアと異なり,ベンダーによるサポートや修正対応がない。 瑕疵を解決できない,もしくは,高額の委託費用が必要になるといったデメリットが生じる可能性もある。
3.2 新規参入容易性
オープンソース・ソフトウエアの市場においては,先進組にとってはシェアを失いやすく,ベンダー企業としての存続能力が衰えてしまうというデメリットがある
3.3 公開によるメリットとデメリット
技術力を露呈させ,他ベンダーに盗用されてしまうというデメリットにもなる。
第8部 GPLに関する法的問題の整理
(良くまとまった資料。専門家による解析はなかなかないので、ここだけでもこの報告書の価値は大きい。)

財団法人ソフトウェア情報センター[http://www.softic.or.jp/] という ソフトウェア等の権利保護[http://www.softic.or.jp/about_us/j_gaiyou.htm] をメインにしている団体が作成したということもあって、オープンソースに対しては消極的な立場で書かれている様な気がしないでもないですが、一般企業から冷静にみるとこういうものなのかも知れません。
「非常に魅力的だけど、使いこなすためには使う側にも知識や技術が必要」といったところでしょうか。
*1: 但し、当然このメモは中立性や客観性を保証しておらず、ある角度から見た自分のためのメモになっているので、この文章を読んで何か書こうという人は原文にあたるべき。

■ 関連記事

詳細はこの日の詳細から

2002年08月27日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 ハーマイオニー[http://www.google.co.jp/search?hl=ja&inlang=ja&ie=Shift_JIS&q=%83n%81%5B%83%7D%83C%83I%83j%81%5B&lr=][ぐる]次の記事 >> このエントリーをはてなブックマークに追加

まじかる☆やす師匠のハーマイオニー萌え萌え日記[http://yasu.asuka.net/diary/] の電波が強烈に入感!
「まーはいおにー」でも狙うか。

■ 関連記事

■2 IPv6転送DNS友の会[http://www.icmpv6.org/v6trdns/][IPv6]<< 前の記事 このエントリーをはてなブックマークに追加

初めてセカンダリを引き受けた。
考えてみると、Aレコードを何らかの手段で動的に更新すれば、 動的IPアドレスしかなくても、dyndnsのサブドメインじゃなくて、 完全に独自なドメインのサービスが、v4で可能な訳だ。
とりあえずは、v6はゾーン転送の手段としての利用だけれども、 ネームサーバを上げたんだったら、Webサーバもv6上げるって訳で、 v6サーバの普及も当然促進されよう。

■ 関連記事

詳細はこの日の詳細から

以上、13 日分です。

指定日の日記を表示

前月 2020年01月 翌月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project