お問い合わせ
会社概要 ソフトウェア 開発ブログ サポート

« 2005年07月 | メイン | 2005年09月 »

2005年08月27日

自然素材の家 Oh!

石綿、アスベスト問題が毎日のようにニュースで騒がれています。私の周りでも、知り合いの所もこのアスベスト問題で一時的におおわらわなのですが、やっぱり住む家や働く場所の安全性には十分気を使いたいものです。

そんな場合に、健康を意識した選び抜いた自然素材にこだわる不動産屋さん、アンケート調査で住みたい街トップにあげられた芦屋を中心に営業する、 感動創作工場 Oh! さんは、珪藻土を中心に自然素材にこだわった家作りを目指していらっしゃって、デザイン性と自然素材で健康と心地よさを追求した住環境を提供しています。というか、実際に見せて体験させてもらいました^^; 選び抜かれた自然素材であれば健康にも関しても安心です。 事実、デザインをされている階地さんは、以前から喘息もちだそうで、デザインする際は、実際に住む人の健康には人一倍気をつけているそうです。

珪藻土、私は知らなかったのですが、詳しくは、こちらを参照していただきたいのですが、色々な良い特性があるそうです。土壁とか、天井、水周りに使われていて中々面白かったです。他にも色々あって勉強になりました。で、もちろん、サイトを作らせて頂いたのはウィザシステムなんですが ;-) まだ動き出して間もないので、ブログの活用、特に自然素材ネタを中心に今後も注目していきたいと思います。

投稿者 BlogWrite担当 : 17:59 | コメント (0) | トラックバック

2005年08月20日

BlogWriteからSo-net blog、Livedoor blogへ画像の送信(未遂)

もっとも要望の多かったAtomAPI経由での画像のアップロードに関して。

BlogWrite 2.3より、So-net blogさんを想定してAtomAPIでの画像等のファイルアップロードに対応した訳ですが、今回Livedoor blogさんが新環境に移行した為、BlogWriteの動作チェックをしていたら、LivedoorさんもSo-netさんと同じ方式で画像等のアップロードに(規格的には)対応されている事を発見しました。

ただし、Livedoorさんではエラーが返り画像が送信出来ませんでした。すでにLivedoorさんの窓口から報告入れたので、修正され次第、BlogWrite2.3.3以上からLivedoor blogさんへの画像等のファイルアップロードが可能となると思います。(エラー文から想定すると、単になる良くあるタイポ見たいなのですぐ修正されると思われます)

また、So-netさんの方は画像の投稿は出来ておりましたが、BlogWriteの不具合で「記事投稿時に後で画像を...」で画像を追加すると、画像がアップロードされない不具合があったため、昨日修正いたしました。申し訳ありませが更新していただきたく思います。現在動作確認できていない状況ではありますが、すでに複数のSo-net blog + BlogWriteでの投稿がされているのを把握しており、御連絡もいただいているため、暫定的に正式対応とさせていただきます。関係者の方ありがとうございました。

注意点として、BlogWriteのブログ設定で指定する「アップロード先ディレクトリ」が両者共に無視されるようです。さらにSo-netさんでのユーザー名とパスワードに関してはこちらをご参照ください。

もし不具合等ございましたら、お手数ですが、サポートフォーラムの方へご一報いただけると幸いです。

投稿者 BlogWrite担当 : 14:43 | コメント (0) | トラックバック

2005年08月18日

The Atom Syndication Format 正式に完成

Atomフィード;つまりThe Atom Syndication Formatが正式にIETF標準化団体において、Proposed Standard(解説)として承認されました。長いことAtom(API)を追っかけてきましたが、おめでとうございます、という感じです。プロトコルも早いとこ完成...え?それは禁句?

The Atom Syndication Format

公式アナウンス:
Protocol Action: 'The Atom Syndication Format' to Proposed Standard

投稿者 BlogWrite担当 : 12:30 | コメント (0) | トラックバック

2005年08月12日

BlogWrite 2.3

BlogWrite 2.3へ更新いたしました。

・投稿日時を指定して投稿した場合、BlogWriteの投稿記事ログ一覧にて、指定した日付ではなく投稿した日付で並んでしまう不具合を修正。

・AtomAPIで(対応しているブログサービス・ソフトにおいてのみ)画像等のアップロードを出来るようにした。
 これにより、おそらくですがSo-netブログさんで画像等のアップロードが出来るようになったと思います参考)。現在の所把握している限りではLivedoorブログとBloggerはこのアップロード機能には対応しておりません(公平を期すと、この機能は元々SixApartの独自実装です。実装するしないはもちろん運営者の裁量範囲です)。他のサービスでも対応してくださると便利ですよね...。 追記:Livedoor新環境では一応規格的には対応している模様...

実装する側から見てこの機能の良いところは、サービスUploadURIをチェックし、そのサービスがアップロードに対応しているかどうかが分かるので実装しやすい、という事。Draft機能などは、投稿して見ないと分からないので、対応し辛い。

さらに、将来的に、IETFで策定されるThe Atom Publishing Protocol でのCollectionと基本的には似ているため、最小の変更で今後も対応しやすい。

So-netブログでの使い方は、AtomAPIを使ってみた」 で非常に詳しく解説していただいています。感謝。(解説されてますが、AtomAPI用のパスワードは管理画面で別途生成する必要があるのでご注意ください)

投稿者 BlogWrite担当 : 10:32 | コメント (0) | トラックバック

2005年08月06日

Web2.0的アプリケーション

近いうちにPerlによるWebアプリケーションを開発することになりそうです。いまどきのRSS・AtomやAPI公開、みたいなWeb2.0的なものになる予定です。ただしサービス内容はぜんぜんRSSとかにまつわるものではありません。古くからある業界に関するものです。とっても硬直化してしまっている分野なのでWeb2.0的文化を持ち込んでみたら面白いと思いました。

ところで、いったいWeb2.0とは何なのか。

Webスタンダード(XML、XHTML、CSS)、Webサービス(API、RSS・Atom)=Remix、ユーザー参加型(メタデータ・タギング、OpenData、初期ベータ公開と頻繁なリリース) あたりがキーワードとして浮かびます。

最近Web2.0という言葉をよく耳にする。
要はWebサービス(≠SOAP Webサービス)やXMLの普及により、WWW上のサービスやコンテンツを再利用するという考え方、本歌取りやSampling、Remixというアイデアが浸透してきたんだろうと思う。つまり、従来はServer To Clientでサービス/コンテンツの「提供者」から「利用者」への一方向の流れだったのが、よりPeer To Peerというか双方向型というか無限増殖型というか、「利用者」が与えられたものを再Hackすることで「提供者」化し、WWWに再貢献するようになってきたということだ。
ただ、こうこと自体は新しいものではなく、WWW本来の性質ではなかろうか。

http://teddy-g.cocolog-nifty.com/blog/2005/07/web20_4581.html

Web2.0の特徴はWebの本質であり、本来のWebへの再帰かもしれません。そもそもの始まりからWWWで使われるHTMLは他のWeb上のリソースをHTML中に引用し自らのデータを付加しRemixできました。

 Here’s my take on it: Web 2.0 is an attitude not a technology. It’s about enabling and encouraging participation through open applications and services. By open I mean technically open with appropriate APIs but also, more importantly, socially open, with rights granted to use the content in new and exciting contexts. Of course the web has always been about participation, and would be nothing without it. It’s single greatest achievement, the networked hyperlink, encouraged participation from the start. Somehow, through the late nineties, the web lost contact with its roots and selfish interests took hold. This is why I think the Web 2.0 label is cunning: semantically it links us back to that original web and the ideals it championed, but at the same time it implies regeneration with a new version. Technology has moved on and it’s important that the social face of the web keeps pace.

http://internetalchemy.org/2005/07/talis-web-20-and-all-that

「私は以下のように捉えています:Web2.0とは単なる技術ではなく、捉え方(態度)であると。それはオープンなアプリケーションとサービスを通して参加を可能にし、それを促進することにあります。オープンとは、適切なAPIにより技術的にオープンにするだけでなく、より重要なのは、社会的にオープンであるという事。社会的オープンとは、利用許可されたコンテンツの新しいエキサイティングな利用が出来るということです。もちろん、Webはずっと参加型であり、欠くことを出来ないものでした。それはWebの始まりから、もっとも素晴らしい業績であり、ネットワーク化されたハイパーリンクは参加を促進してきました。それがいつの間にか、90年代の終わりから、本来のルーツを忘れ、自己中心的な興味に走りました。...以下略(疲れた)」

という事なんですが、もしユーザーが登録したデータではなく、こちらが足で稼いだデータだった場合、オープンに利用できるようにしちゃうのはかなり抵抗があるのですが、そこがムズカシイ...。もちろんAPIなどでユーザ自ら登録できるようにしても、データが集まらない分野だとしたら? そもそもがデータ握っている人たちにパソコン使えない層が多い業界^^; いまだFAX全盛です...orz 

 

http://www.housingmaps.com/ (Web2.0的サイト)

http://bb.watch.impress.co.jp/cda/alphageek/9965.html (分かりやすい記事)

投稿者 BlogWrite担当 : 07:41 | コメント (0) | トラックバック

2005年08月04日

iTMS アフィリエイト Webサービス APIを希望

思いっきり仕事の途中ですが、iTunes Music Store Japanが登場しましたね。

そこでなんですが、ブログの各エントリーに、このようなiTunesボタンを付けたい場合ってiTunesのCOM APIやWebサービスで何とか出来ないんでしょうか。いや、というのもBlogWriteのNowListeningプラグインというのがあるのですが、単に曲のタイトル・アルバム名・アーチスト名だけをエントリに挿入するのではなく、上記のページにあるように、ボタンのワンクリックで視聴、ショッピングカートに入れて購入まで出来るようにしたいと思うわけです。

今の所アフィリエイトのように何かしらのインセンティブがないのはちょっとアレですけどぜひ 追記:iTunes アフィリエイトプログラム発見!残るはAmazonのような WebサービスAPIですね。linkshareという所と提携しているようですが、WebサービスAPIは未提供の模様、とても不便。これではamazletのようなサービスも作れないし、BlogWriteのプラグインにも出来ないです。Appleさんにはぜひ(技術力あるのだから)自前でトライしていただきたいなと思ってみたり...。

関連:ブラウザーからiTMS内を検索するiTunes Link Makerも日本版に対応

投稿者 BlogWrite担当 : 16:05 | コメント (0) | トラックバック

アクセス数という指標の曖昧さ

この三ヶ月、このサイトへのアクセス数はおかげさまで順調に倍程度増えている訳ですが、そんなことをチラッと人に話すと、「で、いくつなんだい」と数字を聞かれるんですよね。このいわゆるアクセス数、とんでもなく誤解される事が多くて以前から問題だと思っていました。

単に(あくまで例えば)月間9万アクセスがあります、というと、人によっては「ほう、9万人が読んでいるのかっ」と言われてしまうからです。知っている人は知っていると思うのですが、単純にアクセス数といっても何のアクセス数かどう解析したかによって数字はどうとでもなってしまいます。9万アクセスがあっても実は一人の特定の人間しかそのサイトを見ていないという事もありうるのです。

そういった知識のない方に単なる数字を話すのは、わざとうそをついているようであまり気分がよくありません。かといって数字を言わない理由を説明しようとすると、「これだからパソコンやってる奴は理屈だらけで...」と言われてしまい、とても凹みます...。単純に正直に話そうと思っているだけなんですが...。正直ものは馬鹿を見る...。

アクセス数といっても色々あります。(それに詳しい人はアクセス数とリクエスト数は違う、と言うかもしれませんし、ページビューというのもユニークIPとか色々あります)

ファイルへのアクセス(ヒット)数。
一ページのHTMLには場合によっては数十以上の画像やCSS、JavaScriptファイルが埋め込まれていて、一ページ読まれただけで、数十のアクセスが発生します。

フレームのページ。
フレームによってページを分割しているページ(これ自体アクセシビリティ最悪で非推奨だけど)の場合。例えば左、上、右に3分割している場合、一ページ読み込んだはずが、実は一度に4ページのアクセスがあるのです。

インターネット高速化・先読みツール。
こういったツールを利用すると、実際には読んでもないし読もうとも思っていないページにもアクセスが発生します。

ロボット・スパイダー。
よく更新されるサイトほど、検索エンジンのスパイダーが頻繁にチェックに来ます。最近では本当に様々な検索エンジンがありますし、同じ所から一日に何回もアクセスしてきます。これらは人が読んでいるのではなく、検索エンジンに反映させるために機械的にアクセスしているだけです。

スパマー。
ブログを設置していると、ブログのコメントやトラックバックに対する大量のスパム行為を受けます。実際ここでもかなり弾いています。(言及なしトラックバック弾くプラグインとか、コメント承認制とかで)。さらに、メールアドレスを収集するロボット等々。こういった英語・中国語等の意味のないスパマーからの機械的なアクセスも多いわけです。

RSSリーダー。
で最近顕著な問題となってきたのが、RSSリーダー。ほんの数ヶ月前まであるRSSリーダーで5分間隔でアクセスできるようなものもありました。という事は一人がRSSリーダーを10時間起動しているだけで、一日大量のアクセス(リクエスト)があることになります。そして、RSSで全文配信している場合、内容はしっかり読んでサイトには一度もアクセスしない事もあります。特に最近のRSS・Atomによる配信・購読という流れで、もう、一定数超えたら正確な訪問者数なんて計測するのは無理でしょ、見たいな気持ちです。

ちょうど、Webサイトのトラフィック計測基準,英国でRSS User-Agentsを削除という記事がありました。UAで弾くというものですが、世界中の無数にあるRSSリーダーをすべてリストアップするというのも中々大変そうです。

はてなアンテナやMyRSS等
通常のHTMLページの更新を見張るサービスも定期的にアクセスしてきます。

こういうのを見ても分かると思いますが、アクセスといっても色々なのが分かると思います。

実際、某広告営業の方がいらっしゃって話した時、「このサイトは10万アクセスがあって...ですから広告費は月20万です」と言われて見せられたのが、良くあるanalogのアウトプット。モロにファイルアクセス数....orz。つまり、仕事とかお金に関る所で単純にアクセス数、と言われた場合、鵜呑みにせず、アクセス数とはなんの事かしっかり質問して把握しましょうという事だったりします。

では一日に何人の人間ブラウザでサイト内のページを任意に読んだのか正確に知る方法はあるのでしょうか。結論から言うと通常、数学的な正確さでは不可能です。毎回パスワード入力させたりるか、会員制のサイトでは別ですけど。現状では、例えばすべてのページを動的生成にして、アクセスしてきたPCにクッキーを食わせて、かつアクセス元IPアドレス比較し、UAでロボットは除くようにして...というのがもっとも有望ですが、これもまったく正確とは言い難い。何しろGoogle等のキャッシュで読まれた場合、会社・学校等のプロキシ・NAT経由、クッキー無効、UA偽装...いくらでも補足しきれない要因があります。最近ブラウザーのセキュリティの向上で埋め込みビーコンも効かなくなってきているし。もちろん大規模サイトでは上記の併せ技を駆使して出来るだけ正確に近い数字を出しているところもあるでしょうが、普通のサイトでは難しいと思います。

と書いていて、我ながら、「これだからパソコンやってる奴は」と言われるのも分かる気がしてきました^^;。頭の中でif ..then .. else .. if .. if . select case ..case ... else...if...

もし、絶対確実な手法というのはなくても、アクセス数を計測する標準的なアルゴリズムというか手法が指針として確立されているならぜひ知りたいです(除くべきUAのリスト一覧とかも)。でなければ同じログ解析ツールを利用とかしないと、正確なアクセス数の他サイトとの比較などまったく意味をなさないです。

将来的にはアクセス数などだけではなく、RSS・Atomフィード購読者数やサイト内のパーマリンクに対する総ブックマーク数とかも一つの指標にしていけたらいいなと思うこの頃です。

追記:
Hits Files Pages Visits Sitesの違いについて、詳しい。やっぱり「ヒット数にだまされてはいけない!」「かなり曖昧」だそうです。

投稿者 BlogWrite担当 : 04:29 | コメント (0) | トラックバック

2005年08月02日

ブログ投稿APIと認知度

先日、某ブログサービスの中の人とお話できたのですが...。BlogWriteどころか、他の投稿ツール一般に関してご存知ないと、言われてしまいました。あまりのショックに引き篭もりたくなりました(笑)。

やっぱり投稿用ツールというかブログ投稿クライアントの存在自体、その認知度ってまだまだかなり低いんですね、便利さの割りに。もしテレビに出てるような有名人とかが「使ってます」って言うと人気になるのでしょうか。

ともかく、まずはブログサービスの提供者側として、投稿APIを公開する利点というものを整理してみたいと思います。

まず前提として、投稿API公開とは、標準規格(例えばAtomAPI、XML-RPC API) - などのオープンスタンダードに対応すればよい、という事。特別に「BlogWriteに対応」などする必要はありません。誤解されるケースがあるみたいですが、標準的規格に対応するだけで、どんなソフトでも使えるようになり、使うソフトはユーザーが好きに選べます。

投稿APIに対応すると良い事があるかもしれない点:

■サーバーの付加軽減と通信帯域の減少があるかも

APIを通じて投稿・編集されると、やり取りされるのは、XML形式のコンテンツなので、Webページに付属する画像データ、スタイルシート等の余分な行き来が減り、サーバークライアント間のデータ通信量が減少する傾向があります。また、オフラインで記事は編集されプレビューも出来るので、サーバー上でのユーザーの操作が減り、場合によっては負荷軽減に結びつく可能性もあります。

■ユーザーに選択肢を提供

人によってはエディタや通常のデスクトップアプリケーションで文章を書くほうを好む場合があります。また、ブラウザーで書いていて間違ってブラウザを閉じて書きかけの文章が消えたり、別ページへ移動して戻ったら文章が無い、などのアクシデントを防ぎ、ユーザーエクスペリエンスの向上を図る事が出来る場合があります。

■長く使ってもらえなければ意味が無い

ブログは日々利用されるもので、継続して使って(書いて)もらわなければ意味がありません。ユーザーに継続して毎日使いつづけてもらえるように、サクッと書けるデスクトップアプリの活用があってもよいでしょう。 もちろん、BlogWriteが持っている様々な機能(WYSIWYGモード、HTMLエディタ、雛型、表、画像サムネイル、ポップアップ....)等々の利用も出来るようになる、という利点もあります。

■オープンさのアピール、そしてサービス連携によるコミュニティの盛り上がり

ブログの定義はいくつかあると思いますが、オープンスタンダードに準拠していることが重要です。XHTMLとCSSで構成され、RSSを吐き出し、ブログのソフトもできるだけWebサービスを使って、そのAPIはオープンにする。そうすることで、誰でもそれらをつなげるソフトウェアを作ることができる。抱え込むのではなく、小さなデベロッパーが一緒にコミュニティーを作れるか、というのがブログの哲学ではないかと思います。ここ数年で革命的に伸びた新興企業の多くが、オープンスタンダードを用いて「自分」のためにシンプルに作る、というところからスタートし、そして成功しています。その意味では、韓国や一部日本のブログサイトは大企業が自分たちの独自技術で作ってしまっているので、旧態依然な感じがします。

 「Joiこと伊藤穰一氏、ブログの「今」を語る」 ITmedia:インタビュー

サービス間連携とコミュニティの盛り上がりの一例として、こうさぎなどのBlogPetによる投稿などが上げられます。

■万が一の時のバックアップ

サーバー上での問題が起きて、DB内の記事が消えてしまった、という事が万が一あったとしても、ユーザーの手元にコピーが残っていれば、ユーザーの怒りもそれほどではないかもしれません(保証の限りではありませんが^^;)。

■他のサービスに遅れない

あまり知られていないのかもしれませんが、かなり多数のブログ、特に有名且つ評価の高いブログサービスほど、APIに対応しています。投稿APIに対応していないと、一部ユーザーから遅れている、という評価を食らってしまうかも知れません。ブログのような(評価などの伝播が早い)サービスでは結構致命的かも...。

という事で今回は、サービス提供者にとって、投稿APIに対応し、本腰を入れる利点をあげて見ました。このような一見地味な機能も軽視せずに積極的、かつ本格的に対応していく、というのは大事だと思います。

 

追記:これとほとんど同時にPostされた「Open Data」に関する記事や、「Philosophy of Yes」も関連してきますね..。

投稿者 BlogWrite担当 : 13:09 | コメント (0) | トラックバック