  |
はてなキーワード: ホスティングとは
ネットワーク自体に興味をもたれたら、インターネットを支えるネットワーク技術について、もう少し掘り下げてみるとよい。
例えばグーグルについてだと、http://japan.cnet.com/special/story/0,2000056049,20374847,00.htm や http://www.geekpage.jp/blog/?id=2009/9/1/2 、http://www.geekpage.jp/blog/?id=2009/12/7/1 あたりがある。
なかなか難しい用語が多いが、グーグルってのはすでに単なる検索サービスの会社ではなく、世界屈指のネットワークをもつ会社でもある。
aguse.jpの結果も、aguse自身が接続するぷららからOCN、NTTコミュニケーションズを経て直接グーグルのネットワークに接続し、そこから先はグーグル社内のネットワークとなっている。社内ネットワークの位置情報なんてそんなに公表されるわけでもなく、わかるのは4つのIPアドレス、66.249.89.99 66.249.89.147 66.249.89.104 66.249.89.103 についての情報に過ぎない。そして、同じIPアドレスにアクセスしても、グーグルほどの規模になると誰もが毎回同じサーバに接続しているわけでもない。だから、aguseは単に代表的住所としてIPアドレスの管理担当であるグーグル社の住所を示しているに過ぎないと思う。ちなみに http://geomaplookup.net/?ip=66.249.89.99 によると、アーカンソー州となってる。根拠は知らない。
次に、www.gov.cnを見てみよう。aguseによると 117.18.237.20 だそうだが、うちからだとなぜか 130.223.220.74 となる。後者はスイスのローザンヌ大学の管理である。117.18.237.20 は http://geomaplookup.net/?ip=117.18.237.20 によると一応中国となっている。さて、このアドレスをwhoisして見よう。すると「EdgeCast Networks Asia Pacific Network」の管理と言うことがわかる。EdgeCast Networks とはコンテンツデリバリネットワーク/CDNの大手らしい。CDNといえばアカマイが思い浮かぶがwikipediaによるとEdgeCastは第二位らしい。CDNだからオーストラリアにもあるだろう。ローザンヌ大学のそれもその関係なのかもしれない。いずれにしろCDNを使っているとなればアクセス元によって世界中のサーバから都合の良いサーバに割り振られたにすぎないのだろう。
ちなみにアカマイといえばマイクロソフトアップデートがおもしろい。静的とはいえ、それなりのサイズのファイルが世界中からダウンロードされるマイクロソフトアップデートではアカマイを使用している。その時々によりNTTやKDDIほか様々なネットワークにあることがわかる。
3つ目はwww.cabinet.iqだ。これが一番単純だ。195.217.167.249 を管理してるのは ATA Sodtware Tech. Ltd http://www.atasoft.com/ 見ての通り、アラビア語の翻訳ソフトを開発している会社である。イラク政府から委託されてホスティングしてるのか、管理まで任されているのかはしらない。
さて、ここでわれらがはてなを見てみる。http://www.aguse.jp/?m=w&url=www.hatena.ne.jp NTTから東京とされるさくらインターネットの59.106.82.204を経由し、なぜか大阪となる。はてなのサーバはさくさインターネットの東京のデータセンターにあったと思うが、なんにせよ、さくらインターネット社内の話なので実際はわからない。
つまりaguse（に限らずだが）の位置情報など、そんなものだ。
メールアドレスも公開、コナミも直接連絡すればいいと思います。プロバイダやホスティングサーバーにも口を出すんでしょうか？同人誌も？莫大な利益を得たわけでもありませんし、ゲームの内容を著しく低下させる内容でしょうか？NHKの報道は？本人に警告しないんですか？１個人を企業が検閲？
http://74.125.153.132/search?q=cache:L85zUjM80ZQJ:twitter.com/nene_anegasaki/status/6463319662
＞莫大な利益を得たわけでもありませんし
莫大ではない利益は得たようですね
総務省が掲げる霞が関・自治体クラウドの計画が本格的に動き始めた。同省は2009年8月10日、「政府情報システムの整備の在り方に関する研究会」の中間取りまとめを公表した（資料はこちら）。これは、2015年の本格稼働をターゲットとして、府省の情報システムの将来像を描いたものだ。これによると、現在は府省ごとでバラバラに構築・運用している情報システムのうち、共用可能なものを霞が関WAN内のデータセンターに集約する。その際に、基盤となる「政府共通プラットフォーム」を開発。この上でアプリケーションをSaaS（ソフトウエア・アズ・ア・サービス）形式で利用する。政府共通プラットフォームには、府省間で共通利用するデータを連携する機能も含まれる（図1）。この政府版プライベート・クラウドが、霞が関クラウドの実態である。
府省横断の業務改革が不可欠に
この取り組みで重要なのは、どれだけアプリケーションを共用化できるかという点だろう。府省ごとに利用しているアプリケーションをそのままSaaS化するだけでは、単にWebアプリケーションのホスティングにすぎない。システムだけの統合・集約に終わらずに、業務プロセスの統合・集約、すなわちシェアード・サービス化にまでつながらなくては、大きなメリットを得ることはできない。
そのためには、府省を横断した業務の標準化が不可欠となる。中間取りまとめでも、業務の見直し（BPR）を課題として掲げている。しかし、その道筋は見えてこない。中間取りまとめの資料には、2009年度から2015年度までのスケジュール（予定）が掲載されているが、業務の見直しに関連するような工程は2010年度中の「要件定義」と「最適化計画策定」の2つだけだ。府省横断で業務を改革した上でシステム要件を定義するまでを、1年足らずの期間で完了できるのだろうか。
短期間での業務改革を実現するためには、強力なリーダーシップが必要だ。府省を横断して大なたを振るえるとしたら首相しか考えられないが、総選挙を間近に控えた今、実働部隊となるプロジェクトメンバーを選ぶことさえもままならないのではなかろうか。
一方の自治体クラウドも実現へ向けて大きく動き始めている。総務省は2009年7月17日、「自治体クラウドに係る開発実証団体」の募集を開始。実証実験に参加する都道府県を募り始めた（資料はこちら）。都道府県CIOフォーラム（詳しくはこちら）の事務局を務めている日経BP ガバメントテクノロジーでは、8月のフォーラム開催に向けて事前アンケートを実施しているが、実際にいくつかの都道府県が実証実験に参加する予定だと回答している。
自治体クラウドは、自治体専用のWANである総合行政ネットワーク（LGWAN）内にあるデータセンター（3カ所の予定）に市町村のシステムを統合・集約する取り組みである。市町村レベルでのシェアード・サービス化ととらえることできる。市町村の場合は、それぞれが同じような住民サービスを提供しているため、シェアード・サービスに向いているといえる。
理想論でいえば、全国の自治体が利用するシステムを統一すれば、コスト面で大きなメリットを得られるし、ガバナンスを効かせやすいというメリットも生まれる。しかし、アプリケーション（あるいはSaaS事業者）の品質を維持できるのかが見えない、地域特性による個別のサービスが提供しにくい、あるいは地場のITベンダーが育成できないなどデメリットも少なくない。実際、総務省の実証実験では、ASPやSaaSは自治体側が選択できるようにしてある。自治体クラウドは当面、都道府県単位のシェアード・サービス化ということになりそうだ。
ただし、都道府県単位でバラバラの仕様のシステムを作るわけではない。自治体クラウドの要件の中には、「自治体クラウド連携インターフェイス」というものがある。これは、アプリケーション間でデータを連携するためのインタフェースで、将来的には都道府県間の連携も見据えたものになっている。
とはいえ、都道府県を横断したアプリケーションの共用化は容易ではないだろう。都道府県をまたいで業務を標準化しなければならないからだ。自治体クラウドと霞が関クラウドの両方に共通することであるが、IT面での研究や実証・分析に偏らずに、業務の標準化にも力を入れていかなければ成功はおぼつかないだろう。というよりも、IT面の実装よりも、業務の改革・標準化のほうがハードルが高いのではないだろうか。
（吉川 和宏＝日経BP ガバメントテクノロジー） [2009/08/21]
http://itpro.nikkeibp.co.jp/article/Watcher/20090818/335667/
http://anond.hatelabo.jp/20090420031928 を補足してみる。
運営資金確保のための措置だろうし、おかげで大概のCDがいけるようになったけど、googleやamazonが買ってたら、また、違った結果になったかもしれない。
情報元：
Slicehost VPS Hosting is now Rackspace Cloud Servers hosting
Slicehost Articles: IP failover - High Availability explained
All requests for the website come to the front end Slice.
That Slice then proxies the request to larger Slices running in the backend of the network.
Slicehost Articles: IP failover - Slice setup and installing Heartbeat
Monitoring Ubuntu Services Using Monit | Ubuntu Geek
$ sudo tasksel
Slicehost Articles: Ubuntu Hardy setup - page 1
Slicehost Articles: Ubuntu Hardy setup - page 2
Automatic Rails on Ubuntu 8.04 LTS « Enjoying Rails
joerichsen's gist: 16225 — Gist
Setting up Ubuntu Jaunty for Ruby and Rails development | Joe Ocampo's Blog
5-minutes to Rails // Slicehost VPS Hosting is now Rackspace Cloud Servers hosting
slicehostでRails2.2.2を動かすまで - なんとなく日記
Slicehost Articles: Ubuntu Hardy - Ruby on Rails
Slicehost Articles: Ubuntu Gutsy - Django installation
UbuntuにLAMPサーバを手早くインストールする方法 - builder
LAMP（Linux、Apache、MySQL、PHP）サーバを手早くインストールする最も簡単な方法
Slicehost Articles: CentOS setup - page 1
Slicehost Articles: CentOS setup - page 2
CentOSのPHPにはマルチバイト対応入ってませんのであとから入れましょう (技術メモ)
タグ「slicehost」を含む新着エントリー - はてなブックマーク
naotaka blog » Blog Archive » Slicehostに申し込み
slicehostでUbuntu8.04の設定1 初期設定 - delab
Slicehost : Tag Archives - delab
ホスティングサービス Slicehost のドキュメントがすばらしい : 僕は発展途上技術者
SlicehostへのRedmine導入手順（Ubuntu Gutsy)
つくるぶガイドブログ: 失敗しない Rails が動かせるホスティングサービス選びと環境構築
具体的にどこがおすすめかという質問を受けた場合、共用サーバーならば海外の Slicehost、専用サーバーならさくらインターネット
Slicehost に移行しました - milk1000cc
Web 管理画面で、OS 再起動・再インストール、コンソール操作、DNS 設定などができます。
バックアップ入れても月額 $25、
レンタルサーバはさくらインターネット | 「さくらのレンタルサーバ」「さくらのマネージドサーバ」
格安レンタルサーバーならステップサーバー | 高機能で格安なレンタルサーバーTOP
レンタルサーバーNSF - 月額100円〜容量無制限可の格安レンタルサーバー
ロリポップ！レンタルサーバー - 月額105円～容量最大30GB 初期費用半額キャンペーン中！
チカッパ！レンタルサーバー - ご利用中のユーザー様へのご案内
レンタルサーバー「heteml」 - 大容量・高機能のレンタルサーバー
Slicehost VPS Hosting is now Rackspace Cloud Servers hosting Slicehost Login
Linode - Xen VPS Hosting Linode Login
Linode.comのVPSホスティングを契約してみた - m-kawato@hatena_diary
Webbynode Hosting - Host and Deploy Ruby on Rails, Django, Node.js, PHP and more
VPS Hosting � Virtual Private Server Hosting | DataRealm.com
Coupon codes, promotions and special offers - CheapVPS
VPS :: VPS Hosting :: VDS :: Virtual Private Servers :: Virtual Dedicated Servers :: Server Axis
RootBSD - FreeBSD and OpenBSD VPS Hosting - Welcome to RootBSD
レンタルサーバーならVPSレンタルサービス｜VPS stock
激安の専用サーバ：ServerPronto なんと月額$29〜 | 海外サーバ.jp
サーバ本体無償提供、ホスティング向きハウジングサービスを月額7,780円で
専用サーバの料金と仕様 | 専用レンタルサーバ（ホスティング）のさくらインターネット
Dedicated servers | Windows and Linux dedicated web servers
Dedicated Servers, Self-Managed Dedicated Server, Dedicated Hosting at ServerPronto
MegaNetServe - Value Driven Dedicated Servers on Linux, Windows 2008, Windows 2003 & FreeBSD
Domain Names, Web Hosting and SSL Certificates - Go Daddy
Dedicated Servers, vSERVERs – SERVER4YOU
Web Hosting | Dedicated Hosting | Domain Registration |
海外の安い専用サーバプランをいろいろ並べて検討してみた - GIGAZINE
再度、レンタルサーバ（共有ではなく「専用」です）で、国内外を.. - 人力検索はてな
Website Hosting in the Yahoo! Directory
デル株式会社(Dell Japan)の公式サイト | Dell 日本
HP-ProLiant-ML115 G5まとめwiki - トップページ
各メーカーの最安サーバを比較検討してみた - GIGAZINE
バックエンドアーキテクチャーのおかげで、2テラバイトの画像を、$1000のLinuxサーバー1台で賄うことができる。だから、年間わずか20万ドル程度の設備投資で、現在サーバー500台を保有している。
ドメイン登録 - VALUE DOMAIN:バリュードメイン
Domain Names, Web Hosting and SSL Certificates - Go Daddy
Amazon S3をWindowsにマウントできるJungle Disk Kawanet Tech Blog/ウェブリブログ
Online storage and backup | Secure file sharing | Unlimited online storage | Jungle Disk
Amazon.co.jp： 現場が教えるホスティングサービスの勘所―立ち上げから運用管理までのノウハウ (NEサポートシリーズ): 合阪 省: 本
Amazon.co.jp： レンタルサーバをはじめよう!―ホスティングのためのサーバ構築術: 斎藤 高洋: 本
↓
↓
サーバ代未払いにもかかわらず、なぜか稼動し続けるWebサイト（ホスティング会社多謝）
↓
上記Webサイトを個人的に継続運営していいか、社会労務士*2を通じて社長に確認
↓
↓
上記ホスティング会社に「個人的に運営を引き継ぎたいのでデータを取らせてもらっていい？*3」と連絡
↓
「データは倒産した会社の所有物になるので（管理は破産管財人）、対応しかねる」との返事
↓
↓
破産管財人に連絡をとる。「Webサイトの資産価値に見合った額*4を支払って、所有権を得るという形になるよ」←いまここ
＊3 サーバは会社からしか接続できないようにフィルタリングされていたので、接続許可するIPを変更してもらう必要がある。プログラム本体のコピーはあるが、データベースの中身が欲しかった。
＊4 資産価値的にどうなのかはよくわからんが、開発を外注したら数百万以上することは間違いない。
・・・どーしたらよかですか？
そうですね。ブログ検索のなかでは最も力を入れているところです。いろいろなブログ検索がありますけど、各社さん本当にひどいですよね。うちもですけど（笑）。最初テクノラティが出てきたときは、これはなんて便利なんだと思いましたけど…。
やっぱりコンテンツが多様化しているので、ブログのなかに動画が入っていたり、いろいろありますけど、コンテンツ解析も何をやれば一番ハッピーなのかっていうのは僕らもまだ迷っている状況です。例えばブログの文章から意味や感情を解析することをやっているサービスもありますが、まだ他にもやることがあるんじゃないかって思っています。確かに便利なんですけど、決定打は欠いているなという感じはあります。
使ってみるとおもしろいんですけど、使い続けるかというとそうでもない。基本的に検索というのはツールなので、使い続けてもらわないと意味がないし、使い続けられるものを作らないと意味がない。
中国では検索とコミュニティが連携--中国の百度のトップページに並んでいるのはどのようなサービスですか。
左からニュース検索、ウェブ検索ときて、3番目のはポストバーといって、検索結果連動型の掲示板です。検索結果を表示すると、その検索クエリに関係する掲示板が表示されて、無ければ新たに作られます。
そうですね。ブログ検索のなかでは最も力を入れているところです。いろいろなブログ検索がありますけど、各社さん本当にひどいですよね。うちもですけど（笑）。最初テクノラティが出てきたときは、これはなんて便利なんだと思いましたけど…。
やっぱりコンテンツが多様化しているので、ブログのなかに動画が入っていたり、いろいろありますけど、コンテンツ解析も何をやれば一番ハッピーなのかっていうのは僕らもまだ迷っている状況です。例えばブログの文章から意味や感情を解析することをやっているサービスもありますが、まだ他にもやることがあるんじゃないかって思っています。確かに便利なんですけど、決定打は欠いているなという感じはあります。
使ってみるとおもしろいんですけど、使い続けるかというとそうでもない。基本的に検索というのはツールなので、使い続けてもらわないと意味がないし、使い続けられるものを作らないと意味がない。
中国では検索とコミュニティが連携--中国の百度のトップページに並んでいるのはどのようなサービスですか。
左からニュース検索、ウェブ検索ときて、3番目のはポストバーといって、検索結果連動型の掲示板です。検索結果を表示すると、その検索クエリに関係する掲示板が表示されて、無ければ新たに作られます。
例えば、検索をしても欲しい情報がでないケースが必ずあるんですね。でも同じキーワードで同じ情報が欲しい人はきっといます。そういう人たちに掲示板でコミュニケーションをとってもらって、そこでコンテンツを生み出してもらっています。検索結果をユーザー同士で作っていくイメージです。
このサービスは世界的に見てもたぶん百度にしかないと思います。これが中国で百度が大きく成長した原因の一つと言われています。２ちゃんねるにちょっと雰囲気は近いです。
日本でのリリースも一応、企画としてはあるんですけど、そのままやろうとすると人手がかかるので、その辺をどうするのかがネックで、提供時期は未定ですね。
左から4番目の「知道」はいわゆるヤフー知恵袋とか、人力検索はてなのようなQ&Aサイトです。これも検索で見つからなかったらこっちで質問してもらおうということで作ったものです。
中国はコミュニティと検索を連携させる動きがすごく盛んです。「百度スペース」というブログサービスがあって、ブログのホスティングもしています。
あと「MP3」は音楽検索ですね。サイトにはMP3って書いてありますけど、63のフォーマットに対応していて、何でも検索できます。いまちょっと物議を醸していますが、ただMP3検索がブレイクして百度が維持できているということではないんです。出たときから人気コンテンツではありますけど、これだけでもっているわけではないですし、最近は動画の方にユーザーが移っています。
一番右に表示されているのが画像検索です。他にもいろいろなサービスがありますが、メインのものがトップに出ています。
日本では焦らず、正攻法で--日本はヤフー、Googleがあって、いろいろな検索サービスがそれに挑戦しようとしていながら、あまり定着していません。百度はそこをどうクリアしていくのですか。
一つは数字にこだわり過ぎないということです。例えば、来期までにこの数字を達成しなければならないっていうと焦って変なテコ入れをしちゃうじゃないですか。その結果がいま一つで、逆にそんなことに労力を奪われたおかげで力尽きてしまうみたいなことはいっぱいあると思っていて、地道さを決して忘れないことが大事ですね。
日本の百度は広告を全然入れていないので、日本側の収益はゼロなんです。それは収益にこだわらずにやろうということで、しばらくはこのままです。サービスが大きくなって、収益のことも考えられるようになったら考えればいいけど、いまはそういうことを考えていたら絶対失敗するし、広告主のことばかり考えていたら迷走するので、それをしないということが「成功の秘訣」になるだろうと思っています。
ほかのポイントとしては、質にこだわるということですね。言っていることがすごく正攻法なので、正直、「え、それだけ？」って思われるんですけど、意外とそういう正攻法だけで攻めたサービスってないんじゃないかなって思っていて、そこだけを突き詰めていったら良くなるんじゃないのかっていうのが我々の期待です。
EMC傘下のセキュリティ企業RSAは4月21日、「Rock Phish」と名乗る犯罪組織がフィッシング詐欺とトロイの木馬を併用した新たな攻撃を仕掛けていることが分かったと伝えた。
RSAによると、Rock Phishは欧州を拠点とする犯罪組織で、2004年以来、金融機関を狙ったフィッシング詐欺を仕掛けている。RSAの推定では世界各国で起きているフィッシング詐欺の50％以上はRock Phishが関与。ユーザーをだまして偽サイトで入力させたパスワードなどを使って、銀行口座から現金を盗み出している。
今回この組織が、新たに「Zeus」というトロイの木馬の亜種を使い始めたことが判明したという。スパムなどから偽サイトに誘導されたユーザーは、そこで銀行口座などの情報を入力しなかったとしても、知らないうちにマルウェアに感染させられる。
Zeusは感染したユーザーのコンピュータから個人情報などを収集し、外部に送信するトロイの木馬。これまでに150種類以上の亜種が出回っている。
しかも今回のケースでは、Googleを思わせるURLを使ってマルウェアがホスティングされているため、セキュリティソフトも通過してしまう可能性があるとRSAは伝えている。
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。
注意：以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。
なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)
Tuesday, February 19, 2008
先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。
それぞれのExcelワークブックは1つのcompound fileに収められている
つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。
もしあなたが週末を、Wordドキュメントをブログにインポートしたり、あなたの個人的な財務データからExcelフォーマットのスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通のプログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:
この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。
理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。
これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:
これはライブラリを使うことを想定して設計されている。もしあなたがバイナリをインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリのサポートが存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。
オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートをWord文書に埋め込んだりできる。完璧なWordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。
それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットはWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマがファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordのコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLやHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットがドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターとエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。
それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordのパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧なWordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンでWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。
それはアプリケーションの歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftのインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordやExcelには費やされてきたのであり、これらのアプリケーションの完璧なクローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションがサポートする全てのフィーチャーの簡潔なサマリーなのだ。
手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。
Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。
1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルがWindowsとMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelはファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。
実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙なディティールを発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelのソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙なビットを全て完全に記述することはできない。
そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。
唯一導き得る結論はこれだ。
MicrosoftがMicrosoftとOfficeのファイルフォーマットをリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットをインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチなアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムのリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。
オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。
ヘビーな仕事はOfficeにやらせよう。WordとExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。
この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:
これらのケースの全てにおいて、Officeオブジェクトにインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザに入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。
書き込むファイルにはもっとシンプルなフォーマットを使いなさい。単にOfficeドキュメントをプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマット、WordやExcelでも問題なく開くことができるようなフォーマットが存在する。
いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。
コメント欄とかトラックバックが開いてるわけないもんなあ。開いてたら歌詞とかmidiをbase64にしたやつとか尻集を大量につっこめばよいかしらん。でJASRACやACCSに通報。それともエンコードした児童ポルノ突っ込むか？まあ普通開いてないからダメだ。
既存ブログからまるまる複製してアフィ先変更するタイプなら汎用攻撃手段「著作権」を使って運営に通報しまくるしかないわな。コピー元を発見して、コピー先を特定して、コピー元の方に連絡を取って、ブログ提供業者へ連絡を入れてもらう？めんどくっせえなあ。
ブログ潰すよりか「金にならない」方へ誘導する方が良いか。Googleやyahooに「スプログ引っかかってウぜーんだけどどうにかして」って意見を継続的に出したり楽天やAmazonへ「迷惑行為してるこの人のアカウントを停止していただけないでしょうか」ってお願いして回る？他力本願くせえけど。
でも俺Googleで検索しててスプログにぶつかったことないんだけど。偉いなグーグル。yahooは使ってないから知らん。スプログ見たのってうぜえ検索トラックバックとかがとんできた時ぐらいだ。
なんにせよあっちはツール（ワードサラダとかいうんだっけ？）で自動、こっちは手動じゃまにあわんわなあ。田代砲撃ったってこたえるのはホスティング業者でスプログ野郎じゃないしなあ。てゆっかとてもわかりやすく業務妨害だし。たとえ炎上したってそもそも自分の作ったブログ見てねえんだから、あいつら。
つっかそもそもみんなスプログからもの買うんか？日本語の体をなしてないようなスプログから。怖くてリンク踏めなくねえ？例のとこじゃブログ7千個で4千万とかいってるけど、俺はてダで自分が買ったものに感想つきでアフィリエイトのんびりはってる日記作ってて、数年でのトータル千円もいかねえんだけど。ホントかよ4千万て。
あの金持ちヒゲ野郎（色々な意味でうらやましいぞ）みたいに一点集中でかつ顔出して識者パワー見せつつ頻繁に熱心に紹介するんなら、もの買うのもわかるんだけどさあ。
なあ、「スプログつくったら儲かるよ！」っての情報商材っぽくねえ？スプログ作成マニュアルとツールを売るという形の一種のネズミ講。本当は大して儲からないのに、儲かることになってないと困る奴がいるんじゃねえ？
”ホームページ製作業者”でいいよね？
ASPサービス提供事業者も含めようとするから複雑になってるんじゃないの？
自分はもともとIT業界にいて今はなぜか商店街に所属してるんだ。
で、隣の芝生の青さがうらやましくなってweb屋ってたのしそうだなって思って辞めたの。
正直webなんてやってもお金になんかならなそうだなとおもったんで、
シノギがひつようだとおもって、お店ももったんだ。
商店街のおっちゃんたちの話しを聞いていると世間のwebというかITに関する認識はこんなものだと痛感しますわ。
いやね、おっちゃんたちっていっても青年団の人たちなんだけどさ。
”親父さん”たちはそもそもインターネット（以前にパソコン）になんか興味すらないから。
で、お店でパチパチとSOHOでソフトの受託なんかもやっていると、
商店街の爺たちからあの店主はパソコンで遊んでばっかりだと陰口いわれたりするんだわ。
ようやく最近わかってもらえるようになってきて、
「おたくパソコンの仕事しているならホームページ作ってよ」と言われるように成長しましたよ。
いや、まるでわかってもらえてないんだけどｗ
ホームページっすか！？みたいな。
難しいというかしても無駄というか……。
自分は自分のお店のホームページだったら作れるんだけど人様のを請負するのを仕事にしてないわけですよ。
今までそういう業務をしてきたわけでもないしデザインが得意なわけでもないしね。
第一たいしたお金になるわけでもないし、それなりにめんどくさいじゃない。
正直そこらの商店のページだってHPつかってなにしようってんでもなく事業目的があるわけじゃないんで、
大学生あたりにアルバイトでちょっとペラのページをつくってもらうぐらいがちょうどいいと思っているんだけど・・・さ。
もうね、なんていうか説明がめんどくさい。
次から次に同じようなことを説明しなきゃいけなくてね・・・。
自分が講師になってセミナーしたいとかそういうモチベーションもっちあわせていないんだけど、
さすがに「ホームページ製作をやるつもりは無いけどホームページは欲しい商店主のためのホームページ講座」
とかいうセミナーでもやらずにはいられないのではないかと思うぐらいめんどくささが先立ってきました。
というのも彼らの話しを聞いてちょっと義憤にかられてきたんですよ。
自分もお店をやっているのでわかるんだけど、お店やってると営業の電話がいろいろ掛かってくるわけです。
「ホームページつくりませんか？」ってね。
ひどいところなんか「ホームページみて電話してるんですけど」とか。
おまえ誰がつくったページかわかって喧嘩うってんのかと内心思いながらね。
「反響はどうですか？もっと反響集めたいとおもいませんか？うちはSEOを(ry」
そんな感じのマニュアルどおりの営業が展開されるわけですよ。
本当に山と・・・。
ひどいところなんか
「うちはYahooの代理店をしているんですが、今キャンペーン中で…(ry Yahoo!に登録しませんか？」なんてのもあるぐらいさ。
でねー…。
こういうのに引っかかるバカいるのかなとおもってたんですよ。
いやほんと。
でもね、
「うちは月々１万５０００円だよ。」
「うち２万５０００円。まあ電話一本で雨の日サービスとか画像いれてくれるから満足してる。」
なんて話が目の前で展開されてるのを見てさ・・・
動的部分が何もないHPに数百万かけたとか、ほんと…、ちょっと待ってくれよと。
このHPに月々…… えーーーー！！？ ちょっとほんとお願いだから待ってくれよと。
ただしホスティング費用が毎月**掛かりますとか。
サポートで…とか、
ほんと山ほどパターンがあるんですわ。
と商店主に何度言いたくなったことか。
もうやっちゃってるところには酷なので言えないんですが・・・
そういう業務をしているのがweb屋ということなのかな？
ユーザー教育じゃないけど、ほんと早急に手をうたねばと思ったよ。
デザインの手間とかバカにならないし、メンテナンスまで面倒みきれないので、
自分はホームページ製作業をやるつもりはないんだけど・・・
商店街の中でバイト５??６人囲ってまわせば済む話しじゃんね・・・。
そんなわけで、だれかバイトでホームページとかつくりたい子いない？
つか、ほんと・・・もう、なんとかしたい。
前時代的な職業っていういうけど、なんていうか日本ではそれが全盛期ですよ。
ちょっとほんと助けて。
あと、ちょっとこれの反論まじえとく。
http://d.hatena.ne.jp/waseda23/20071225/1198573722
自分がSOHOなので弁明するけど、SOHOを地方って括っちゃいけないよ！
あと、SOHO同士でアライアランスくんで億単位の案件も食えるように準備してるんだぜ。
（・・・成功するかは知らん。）
PHPが馬鹿にされる一番の要因ともなっているんだけども、セキュリティの「セ」の字も理解していない「なんちゃってプログラマー気取りのwebデザイナー（？）」が、XSS,SQLInjection,CSRF,SessionHijack等々考えうる全ての脆弱性を垂れ流してるのはどういう訳？
考えうる全ての脆弱性を垂れ流してるのは別に垂れ流したところで問題ないような情報しか扱わないからでは？
さすがにカード番号とか扱うような業者でそんなところはないんじゃね？
あんの・・・？（なんかありそうで怖くなってきた…）
ま、それは発注側の意識が前述のレベルなので…本末転倒ですがユーザー教育が急務です。
らしいね。
でも正直日本国内にはいってきているインド人は相当少ないのでまだ数年は平気かな。
今の日本の仕事のやりかただと開発室の一部をカレー臭くするぐらいの働きぐらいしかできないとおもう。
オフショアというか呼んで来てるだけだしｗ
それよりも今の日本において深刻さをましたのは中国だとおもう。
ほんとその通り。
ずいぶん単価はあがって日本の1/2-1/3ぐらいなんだけど、かなり質があがってきているらしい。
一時期日本でどっぷり開発していた連中が帰国したからかもしれない。
多分同価格で捜すより中国に出したほうが楽というところまできてると聞くようになった。
自分も何か損害かぶれるぐらいの案件があったら一回試してみたいとおもってる。
オフショアブリッジの人に聞くと、日本のカレンダーに合わせてくれるし、日本語ができるひとが会社に1人以上いるそうだ。
スカイプで進捗の日時確認ができて、緊急の場合には携帯に電話が掛かってくる。
インドかー…。
昔いったときは市民レベル的に中国よりも30年ぐらい遅れてるとおもってたのでこの速度は予想外。
昔はムンバイとかの方だけだとおもってた。南のほうの人は質がすこし違うのかもしれないね？
さすがにインドに対してはあと数年はアドバンテージがあると信じたい。
日本人が英語が無理っていうのはあるいみマルチバイト鎖国の成功。
絶対違う
GoogleCodeSearch と code.nanigac はだいぶ趣が異なると思う。(GoogleCode じゃなくて GoogleCodeSearch だよね？ GoogleCode はホスティングサービスだし)
個人的には、ドキュメントに書いてない「使われ方」を検索するのに使うかな。ライブラリの説明読んだだけじゃ書けないコードも時々あるよ。
ガ島通信 - オライリーがブログエチケット「Blogger's Code of Conduct」を提唱
１. 自分の言葉に責任を持ち、基本的な礼儀に従わないコメントは制限する権利を留保する
２. リアルで話さないことはオンラインでも話さない
３．もし緊張が拡大していれば、公にする前にプライベートでコンタクトする
４．誰かが不公平な攻撃を受けているとき、熟慮した行動を行う
５．匿名は認めるが、偽名は認めない（匿名＝正体は分かるが名前を伏せていることで、日本の匿名とは異なるようだ）
６．トロール（怪物？日本で言う「荒らし」のようなものか？）は無視する（要するにスルー力を持てということ）
７．ブログホスティング会社はより強力にサービスを行うことを奨励する（ブログホスティング企業が問題のあるブロガーにもっと対応すべきだ）
これを逆に言うと、
1. 責任に縛られずに発言し、礼儀のなってないコメントでもなるべく制限はしない
2. リアルで話さないことこそ、オンラインでは積極的に発言する
3. プライベートで接触することは避け、パブリックな空間で全てを解決する
4. 誰かが不公平な攻撃を受けているときは、考えるよりさきに感じたままに動く
5. 名前も正体も伏せる
6. 荒らしには積極的に絡み、「スルー力」などと誤魔化さない
7. ブログホスティング会社は「君臨すれども統治せず」を心がける
・・・これ増田だよね。ぜんぶに当てはまるわけじゃないけど。
私はこっちの方が好きです。
