はてなキーワード: チェックボックスとは
はてなブックマークのコメント一覧非表示機能について - はてなブックマーク日記 - 機能変更、お知らせなど
みんな知ってる記事だよね。
ブコメでもちらほら批判されてるけど、
なんてのはとんでもない糞仕様。
こんなWeb標準違反をユーザーに強いるのはバカでアホ。低脳でワーキングプア、と言いたいところだけど、何気に月収100万だったりするからワーキングプアは違いますねごめんなさい。
この仕様が糞だと判別するのは刺身にタンポポ乗せるよりも容易なので、要するにはてなは解ってて直せないんです。
ここで糞仕様と言ってるのは meta で判別する仕様とか body 内の meta を拾っちゃう仕様とか、ではなく、はてダの仕様のクソさを言ってます。
これまた至る所で指摘されてるけど、普通なら、日記の編集フォームに一つ「ブクマページでブコメを表示する」というチェックボックスを付ける。チェックが off なら head に件の meta を入れる。
こんだけあちこちで言われてるアイディアですから、当然スタッフは思いついたでしょう。さすがにそこまで馬鹿じゃないでしょう。
でも実装しませんでした。実装できないんです。
なぜ実装できないか。それは、フォームを増やすと記憶すべきテーブルが変わっちゃうからです。各日記毎に1つ、 BOOL 型を余分に記憶しなきゃいけないからです。
その程度の変更、大した事無いような気がします。でもはてな的にはできません。
はてなは何故か、はてダの個別記事の記憶の仕方を変更できません。実はこれは今回が初めてじゃありません。
はてダには日記モードの他に「ブログモード」などという名前に偽りのあるモードがあります。このモードにすると、日付ではなく個別の記事単位での表示も可能になります。一日に複数の記事を投稿できます。
でも、何故か、編集は日付単位でしかできません。「見出し記法」なる抜け道で、擬似的にブログを実現してるに過ぎません。だからコメントとかトラバはまともに管理できない。
なぜ記事毎の編集にできないか。日付で管理するはてな「ダイアリー」のシステムを変更できないからです。
はてダはトラックバックは実装してます。なぜならトラバは送りっ放しで良いから、何も記憶しなくていいからです。
でも、少なくないブログエンジンは、トラバの送り先も記憶します。「あれ?送ってないっけ?」とか勘違いしないで済みます。
なぜはてダはトラバの送り先を記憶しないか。記憶できるようにするには、各記事毎に新たなテーブルを用意することになるからです。
記事をカテゴリー(っつーかタグ)毎に分ける機能も、ちゃんとは実装されてません。はてな記法と検索で誤摩化してます。
記事毎にカテゴリーを記憶するにはデータベースを弄らなきゃいけないからです。
◯◯記法の多彩さであたかも凄い事をやってるかのように見せかけてますが、実際には、◯◯記法はデータを読み込んで吐き出すところにフックするだけです。
小手先の技術が巧みなのは認めましょう。
でも、小手先の技術ですべてを実現せざるを得ないから、こうやって筋の悪い仕様があちこちに出てくる。
engadgetもgizmodeも返事しないからはてなに書く。
昨日docomo、auの両キャリアに@i.spftbank.jpに対しての
PCメール除外設定を解除してくれませんか?という質問をしてみた。
以下質問------------------------------------
送っているのですが、
オフにしていただけないでしょうか?
すぐに、というのは不可能かもしれませんが、
対応予定等があるのかお教え願いますでしょうか?
よろしくお願いいたしいます。
そこをなんとか!という気持ちで質問してみた。
昨日は何の返事もなく終わったが、
連絡しろというSMSが届く(メールが届かないのに無理ですよ)
そののちauから返事が
以下au------------------------------------
この度は、ご意見をいただく次第となり、申し訳なく存じます。
恐れ入りますが、お問い合わせいただいたサービスの提供につきまして
は、現在のところ、未定とさせていただいております。
ご期待にそえる回答をお返しできず、恐縮でございますが、
何とぞ、ご了承くださいますようお願い申し上げます。
なお、お客様よりいただきましたご意見は、貴重なお声として受け止め、
今後、より多くのお客様にご満足いただけるよう、サービスの提供に活
かしていく所存でございますので、引き続きauをご愛顧くださいますよ
う、よろしくお願い申し上げます。
また、お気づきの点がございましたらお気軽にお問い合わせください。
その7分後(!)ドコモから
お客様からお問い合わせいただきました件について、ご回答申し上げます。
誠に恐れ入りますが、「@i.softbank.jp」のドメインからのメールは、
携帯電話からのメールではなく、インターネットメールとなります。
そのため、ドコモ携帯電話で、パソコンからのメールを受信拒否に
設定している場合、i-Phoneからのメールは受信することができません。
何とぞご了承くださいますようお願い申し上げます。
また、現時点では、今後、「i.softbank.jp」を携帯電話からのメールとして
対応できるかにつきましては未定となっております。
恐れ入りますが、迷惑メール対策(受信設定)をされている
ドコモの携帯電話へ「@i.softbank.jp」のドメインからメールを
行なっていただきますようお願いいたします。
→オプション設定→メール設定→迷惑メール対策→iモードパスワード入力
→受信/拒否設定→ステップ2でインターネット(PC)からのメールを
「受信する」のチェックボックスにチェックを入れる または、
→ステップ4で「××××@i.softbank.jp」(アドレス指定受信)、
「i.softbank.jp」(ドメイン指定受信)を個別に設定する
※「@i.softbank.jp」のドメインへの送信メールは、
絵文字変換に対応していません。
受信・拒否設定の設定方法の詳細は、以下URLをご参照いただければ幸いです。
<受信・拒否設定>
http://www.nttdocomo.co.jp/info/spam_mail/measure/domain/index_image.html
このたびは、お忙しい中お問い合わせいただいたにもかかわらず、
ご希望に添った回答ができず、誠に申し訳ございません。
また、何かご不明な点がございましたら、お気軽にお問い合わせください。
と2キャリアから連絡をいただきました。
時間帯からして3キャリア間でなんらかの協議があったのでしょうか??
ということでしばらく対応はないみたいだから
あきらめて電話で個別に連絡していくしかないかなぁ。
わかってたけどめんどくさい!
自分は某メーカー勤務である。はてなTOPからいろんな記事を見るのが好きだ。自分の業界とは違う業界の話をたくさん見る事が出来て面白い。違う業界と言えども全く関係ないわけでもなく業務にはいろいろと関係してくる。そういう業界の人たちの考えが垣間見えるのは面白いものだ。
うちの会社では、勤務表は手書きであったが、今年度からwebでログインして勤怠管理するようになった。定時に出勤して定時に帰宅する場合の入力はとても簡単に出来ているが、残業、深夜残業、休日出勤、休日出勤時の残業、代休、有給、忌引き処理などとなってくると複雑になってくる。
複雑である為に、入力後、上司の承認の際に間違いが発見され、再度、入力/申請が必要になったりする。何故、申請の時ではなく、承認の時にエラーになる仕様になっているのか解らない。手元でエラーになれば直ぐに再入力できるのに、他人の承認時にエラーになったら手間がかかる。
全くふざけた仕様だ。文句を言っても始まらないので、自分が入力の時にミスらないように気をつけるしかない。ヘルプなどを参照しつつ、確認しながら進める。慣れもあり、最近はそこそこうまくできるようになってきた。しかしチェックボックスがデフォルトで変な所にあったりして使いにくいことこの上ない。
ヘルプといっても大したものは無いが、どこかの部分に面白い事が書いてあった。「当社はお客様の立場に立ってソフトウェアを設計します」というような事が自慢げに書かれていた。この文言は、使っているシステムだけに書かれているようなものではなく、社是のような雰囲気で書かれていた。
思わず苦笑。クソシステムを使わされているからというのもあるが、当たり前すぎる事がなんか、さもすごい事かのように書かれている。なんだこの会社は。ふざけている。会社名は伏せるが、一部上場企業の名前が社名の頭についているので、それなりの会社であると思えるのだが・・・
ここ最近の人気エントリにも、IT業界(SI業界)の話がたくさん出ている。ふと気が付いたんだけど、そのテの話には必ずと言っていいほど、客やユーザーの話が出てこない。5次請け6次請けそれ以上が当たり前のようだから存在すら気にしていないのだろうか。なんの為に仕事してるのか解らなくなってるのであろうか。
例の会社がわざわざ「当社はお客様の立場に立ってソフトウェアを設計します」と書いているのは、そういう業界では無いからこそ、そんな事を書くのだろうと思えてしまう。
あーでもない、こーでもない、と御託ばかりで、品質を高めようとしているエントリなんか全然無い。
はてなのヘルプがうんぬんといったエントリがいくつか出てるけど、当然だと思う。あまりはてな使っていない自分ですらヘルプに苦労させられた事がある。結局、Googleに世話になる。別にそれで済んだからそれでいいんだけど。正直、はてなで苦労するより、利用者としては検索した方が最適な答えが出てくると思う。今も今後も。
はてなも含めて、IT業界で働く人たちは、客やユーザーの事なんてほとんど考えていないんだと思える。
はてなスターがどうこうと言ったエントリもあった。まさにそういう事だ。
なんの為に仕事してるのかよく考えて欲しい。
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。
注意:以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、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バイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。
つ ツール→オプション→コンテンツタブ→「Javascriptを有効にする」チェックボックス横の「詳細設定」ボタン→「コンテキストメニューを無効化または変更する」チェックボックス
おお便利だと思ったけど、グーグルマップが使いづらいのでおかしいなと思ったらこれのせいだった。
誰か教えて。
oncontextmenuで禁止してるのを無効にするgreasemonkey書いてみた。
つ ツール→オプション→コンテンツタブ→「Javascriptを有効にする」チェックボックス横の「詳細設定」ボタン→「コンテキストメニューを無効化または変更する」チェックボックス
GMならURLでオンオフ指定できるけれども。アドオンでサイト毎設定とかはありそうな気がする。その昔はどっかの野良アドオン使ってた。piroさんのところだったっけか。
そんな私は現在NoScript。なので、
右クリック禁止にしてあったところで何の問題もない
わけだが、コンテキストメニューを変更して便利にしてるサイトを知らない。
誰か教えて。