2006-11-24 アーカイブ

http://hxxk.jp/2006/11/24/

ソフトバンクモバイルを脱会しました

記事データ

投稿者

望月真琴

投稿日時

2006-11-24T18:33+09:00

タグ
概要

携帯電話を au に替えましたよというお知らせと、 W44K の使用感、ソフトバンクモバイルの新たな動向について。

リプライ

リプライはまだありません。

記事本文

結果報告

さらば……そしてありがとう J-PHONE & vodafoneモバイルナンバーポータビリティ関連の人気エントリーのメモなどいくつかの記事で MNP を行ってソフトバンクモバイルから脱会することを示唆していましたが、昨日欲しい機種が九州地区で発売となったので、滞りなく脱会手続きを済ませてきました。

Hatena::Diary::Code-404 - W44K を入手でも購入者によるレビューが書かれていますので、私も真似して書いてみようと思います。 KDDI 会社情報: ニュースリリース > au携帯電話の新ラインナップとして「W44K」を販売開始にもあるように、関東・中部・東北地方の方はまだ発売されていないので、該当地域で購入予定の方にはネタバレになっちゃうかもしれませんが……。

画面表示や動作

前機種の vodafone V604SH に比べるとほんの少しだけ遅く感じます。 しかし不満を感じるほどではなく、あくまで相対的にそう感じるだけですが。 「ペタメモ」というショートカット機能と組み合わせると通常の使用に関するストレスはそう発生しないのではないでしょうか。

液晶は少し不鮮明な印象。 むしろ SHARP の液晶が綺麗なことの裏返しかもしれません。 ハーフミラーに備えられているサブディスプレイは綺麗。 これはデザインの勝利ですかねえ。 残念なことは、通話着信時に名前をサブディスプレイに表示するのなら、メール着信時にも名前をサブディスプレイに表示して欲しかったなあ。

各種ソフトウェア

基本的には良い感じじゃないでしょうか、漠然としか言えませんが。 個人的に勘弁と思ったのは、メール一覧表示のバリエーションが少なく、また文字サイズの変更ができないこと。 これではメールの内容をざっと斜め読みで確認することができず、いちいち一通一通開く必要があります。

Hatena::Diary::Code-404 - W44K を入手でも メールフォルダ振り分けがグループで登録できない。 何のためにグループがあるのか分からなくなる。 と言われていますが、同感です。 そのことに最初に気付いたため、アドレス帳のグルーピングは行いませんでした。 メールフォルダ振り分けは、実際に届いたメールを開き、 From の横にある差出人のリンクを選択して「振分登録」を選ぶようにするのが一番素早く行えると個人的に思います。 なお、振分登録を行った後に、「メール再振分」ができるのは大きなメリットだと思います。

メール以外の機能はまだ使いこなせていないので、あまり感想もありません。 実はカメラ機能はほとんどこだわりませんし、ミュージックプレイヤーも iPod nano があるので使わないと思いますし。 vodafone 2G からの移行なので、 EZweb の速度の速さや PC サイトビューワの便利さ、定額制によるパケット代の心配が不要という点は非常に良いと思います。

本体・ハードウェア

W44K 最大のセールスポイントである薄さ、これはかなり良いです。 これまで使っていた V604SH もそんなに厚い端末ではなかったのですが、これはその約半分ということで、全くかさばりません。 私の中で「スリム」というのは大きなポイントなので、この薄さには満足しています。

逆に、ハーフミラーであるサブディスプレイ部ですが、指紋が付きやすくて気になります。 仕方ない部分なのかもしれませんが。 これは防護フィルムなどがあれば是非活用したいですね。 逆に、本体部分のブラックは汚れが目立ちません。 V604SH も本体部分がブラックだったんですが、ちょっと触っただけでも指の脂の跡などが目立っていたんですよね。

なお、購入時点では microSD カードは同梱されていません。 しかし USB ケーブルが試供品で同梱されているので、データのやりとりは USB 接続をしてマスストレージモードで行おうかなあと思っていたら、どうも microSD カードが無いとマスストレージモードにできない模様。 安い ( 容量が大きくない ) microSD カードを購入して対処しようかな。 もしかして試供品の USB ケーブルではなくて別売りの USB ケーブル WIN も必要ってオチじゃないでしょうね……。

あ、カメラのフラッシュをペンライト代わりに使う場合、少し光量が弱いのもちょっと気になります。

総合的に

vodafone 時代は SHARP のインターフェースに慣れきっていたのでずっと SHARP 端末だったのですが、 MNP を機に他社端末にチャレンジしてみました。 購入後数時間は戸惑いましたが、丸一日一通り触ってみると、そんなに操作性の違いも気になりませんでしたので、この端末にして良かったと思っています。

ところで、もう脱会したから関係無いと言えば関係無いのですが…… よっけのぶろぐ | 史上最悪の改定始まる「S!ベーシックパック」非契約ユーザー、ワンタッチで自動契約というニュースも出てきているようですね。 説明を記したSMSをよく読まないまま、操作ミスで「Y!」ボタンを押すと、利用するつもりがなかった「S!ベーシックパック」を契約してしまうことになるため、非契約のユーザーは注意が必要だろう。 というケースも考えられるようです。 そりゃあ説明を読まない方が悪い、という見方もありますが、年配の方などは「読んでも分からない」ということだって充分に考えられます。 このニュースが今後どう展開していくか、脱会した身とはいえ心配です。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

はてなブックマークは拡張子無しの URI の時に謎概要 ?

記事データ

投稿者

望月真琴

投稿日時

2006-11-24T17:30+09:00

タグ
概要

約 1 年前に同じ話題を取り上げていましたが、どうも拡張子が無い URI だとヒューリスティクスな概要になるようです。

リプライ

リプライはまだありません。

記事本文

やっぱりはてなブックマークの概要取得はよく分からない

hxxk.jp の各記事は PHP ファイルをサーバ上に静的に生成しているのですが、 MultiViews を使って URI には拡張子を含んでいません。 しかし拡張子 .php を付けてアクセスしてもリクエストは成功するため、何故はてなダイアリーの記事は、はてなブックマークが分散するのか ? ほどではないにしろ、稀にはてなブックマークのブックマークが分散することがあります。

先程の記事の仕様をちゃんと理解しておくか、英文をしっかりと読むことで誤解を防ぐもその分散した例の一つなのですが……

分散したそれぞれのブックマークで、取得されている概要が違うのです。

b.hatena.ne.jp/entry/http://hxxk.jp/2006/11/24/1248 の概要

なんだかなあ IFRAMEを使わずにHTMLファイルから他のHTMLファイルを読み込む方法:phpspot開発日誌という記事が多くの数のはてなブックマークを集めているようですが、そんなに画期的で素晴らしい方法なのかなあと思ったり。 それでいて紹介元記事の方はそんなに多くのはてなブックマークは集まっていないというのが何とも。 まあ英語と日本語の違いということもあり、「日本語...

b.hatena.ne.jp/entry/http://hxxk.jp/2006/11/24/1248.php の概要

iframe 要素は XHTML 1.1 や XHTML 1.0 Strict では定義されていませんが、 XHTML 1.0 Frameset や XHTML 1.0 Transitional では定義されています。 それを知っているか、または知らなくても原文をよく読めば「XHTMLではiframeタグは禁止されている」という誤解は生じないのですが。 そしてはてなブックマークなどではその誤解をそのまま受け止めてしまっているケースも。

拡張子付きだと概要をうまく取得する ?

約 1 年前にはてなブックマークと dc:description

  • <$MTEntryTrackbackData$> を記事中に記述している
  • コンテントネゴシエーションをしていない、あるいはコンテントネゴシエーションをしていても <$MTEntryPermalink$> を拡張子付きで生成している
    • <$MTEntryPermalink$> を拡張子無しで生成していても、 rdf:about も合わせて拡張子無しにしている

これらの条件が満たされればちゃんと概要を取得してくれるのではないか、ということです。

と書いていましたが、ブックマークされる際に拡張子付きの URI であれば概要を適切に取得してくれるんでしょうか、もしかして。 そのために permalink を拡張子付きの URI にするということはしませんが、これで謎概要の秘密 (?) の答えになれば去年からの悩みが一つ解決するのになあ。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

仕様をちゃんと理解しておくか、英文をしっかりと読むことで誤解を防ぐ

記事データ

投稿者

望月真琴

投稿日時

2006-11-24T12:48+09:00

タグ
概要

iframe 要素は XHTML 1.1 や XHTML 1.0 Strict では定義されていませんが、 XHTML 1.0 Frameset や XHTML 1.0 Transitional では定義されています。それを知っているか、または知らなくても原文をよく読めば「XHTMLではiframeタグは禁止されている」という誤解は生じないのですが。そしてはてなブックマークなどではその誤解をそのまま受け止めてしまっているケースも。

リプライ

3 件のリプライがあります。

記事本文

なんだかなあ

IFRAMEを使わずにHTMLファイルから他のHTMLファイルを読み込む方法:phpspot開発日誌という記事が多くの数のはてなブックマークを集めているようですが、そんなに画期的で素晴らしい方法なのかなあと思ったり。 それでいて紹介元記事の方はそんなに多くのはてなブックマークは集まっていないというのが何とも。

まあ英語と日本語の違いということもあり、「日本語で紹介・解説している」記事にはてなブックマークが多く集まるというのは自然なことかもしれません。 実際に、 del.icio.us の方では 紹介元記事の saved people の方が phpspot 開発日誌の saved people を大きく上回っていますし。

まあ、この object 要素を用いる手法自体については今回は置いといて。

元の文意を理解せずに紹介してブックマークを集めることの危険性

さて、はてなブックマークでは紹介元記事よりも紹介記事の方が多くブックマークされている。 ということは、日本語を母語とする人の中には、もしかしたら紹介元記事を読まないままに紹介記事だけを読んで完了している人もいるのではないでしょうか。

そういう状況で、その紹介記事が紹介元記事の文意を理解せずに、誤った情報を流していたとしたら ? 誤った情報をそのまま信じてしまう人も出てきてしまうでしょう。 XHTMLではiframeタグは禁止されている なんて紹介元記事では全く書かれていませんし、実際に XHTML 1.0 Frameset DTDXHTML 1.0 Transitional DTD では iframe 要素は定義されています。

厳密に言うと紹介元記事で書かれているのは what to use instead of iframe in XHTML Strict pages. と、「 Strict DTDXHTML で iframe 要素の代わりに使うべき手段は何か」ということです。 そして紹介元記事自体は XHTML 1.0 Strict DTD であるために my pages are XHTML 1.0 Strict, in which iframe is banned element. と書いており、その文意を汲むなら「 XHTML 1.0 Strict では iframe 要素は禁止されている」と紹介すべきです。

特に Validにしたい場合は という意味で紹介するのなら、この Strict の部分を無視して紹介してしまうのは非常に良くないと思います。 ついでに言うなら、 iframe is banned element iframeタグは禁止されている と訳するのも。

既にはてなブックマークの方でも del.icio.us の方でも数名誤解している方が出てきてしまっているようですが……。

TERRAZINE - GIGAZINEは元記事が英文の時は疑ってかかった方が良いという記事が話題になったこともありましたが、英文・和文に関わらず紹介されている記事の内容を自分でも読むことが大切だなあと考えさせられる記事でした。

リプライ

3 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2006-11-26T14:07+09:00 - その記事は本当に正しいのか? < メモランダム

久しぶりにはてなを見たら、「IFRAMEを使わずにHTMLファイルから他のHTM...

2006-11-27T03:09+09:00 - iwaim

まあ、英文を読んだところでそれが仕様として正しいのかは不明だとしか言えないという点は忘れてはならないと思います。

2006-11-29T01:20+09:00 - 真琴

ええ、先に <a href="http://hxxk.jp/2006/11/27/2253">http://hxxk.jp/2006/11/27/2253</a> の方でリプライをしましたが、元のリソース自体がダメダメな場合に、それを正しいかダメなのかを判断できるかどうかというのは英文の理解力にはよらないですよね、と思いました。

補足情報

著作、講演、制作実績など