二〇一四年 睦月 十九日 日曜日
■ 自然数の総和は -1/12？ [/links]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
自然数の総和（1 + 2 + 3 + 4 + ...）は -1/12 だという話がある。その「証明」にはゼータ関数を使ったりすることが多いようだが、Numberphile が直感的な「証明」をしていて、おもしろかった。
このビデオの中では S1 = 1 - 1 + 1 - 1 + 1 - 1 + ... = 1/2 であることを「証明」していないが、この「証明」はやはり Numberphile にある。
このビデオの中でも説明されているが、S1 = 1/2 というのは、数学的には誤りだ。S1 は、収束しないので、値を持たない。だから、S1 を用いて四則演算をすることはできない。したがって、最初のビデオでの計算は、実際にはすべて成り立たない。
ところが、この結果は物理学のさまざまな分野で実際に使われているそうだ。ということは、物理学はあちこちで間違っているということか。
[この記事だけを読む。] [最新の記事を読む。]
二〇一三年 師走 八日 日曜日
■ 特定秘密保護法成立に思う [/links]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
6日、特定秘密保護法が成立した。と言っても、現在の衆議院議員は最高裁が違憲状態と判断した選挙で選ばれた人たちだし、前回の参議院選挙も違憲状態だという判決が各地の高裁で次々と出ている。岡山選挙区では無効の判決すら出た。だから、そもそも現在の国会議員に法律を作る権利があるかどうか疑問だ。
さらに、参議院安全保障特別委員会では、民主党の委員長を解任するという布石を打った上で、自民党の委員の発言中に強引に採決したことにした。「ことにした」と書いたのは、議事録には採決したかどうかが記載されていないからだ。
このようなことがまかり通る国は、法治国家とは言えない。法治国家であることを捨ててまで、この法律を成立させなければならなかったのはなぜか。
特定秘密保護法の成立は、2日に自民党沖縄県連が辺野古移転容認に転じたことと関連があるだろう。自民党沖縄県連はこれまで、沖縄県民の民意を受けて、普天間基地の辺野古移転に反対してきた。ところが、自民党幹事長の石破氏が沖縄に乗り込んで、辺野古移転を容認させた。
特定秘密保護法の参議院本会議での採決は、反対する多数の市民が国会を包囲するという異常な状況で行われた。どちらの動きも、民意はいっさい考慮に入っていない。考慮されているのは、官僚の権限をどう守り拡大するか、そしてそれを米国がどう受け取るかということだ。日本の為政者は、国民の意見を聞くことより、米国に媚を売ることを優先している。
では、媚を売られた米国は、日本に何をしてくれるのだろうか。
先月、中国が防空識別圏を設定した。それに対し、米国はすぐに軍用機を識別圏内に飛ばしたものの、日本政府が日本航空と全日空に対して事前通告をしないよう求めた（命じた）のを見て、米国の航空会社に対して中国に事前通告することを促した。米国は、日本にはしごを上らせておいて、はしごを外してしまった。日本のマスコミは、世界中が中国に反対しているというイメージ（幻想）をなんとかして作ろうとしているが、実際には、中国の防空識別圏を認めようとしないのは実質的に日本だけだ。
日本は戦後、一貫して対米従属を国是としてきた。ある時期までは、米国にとって日本は反共の防波堤としての利用価値があったが、冷戦が終わった今、米国にとって日本は金蔓でしかない。一方、中国は、経済構造をこれまでの輸出主導から内需主導に転換しており、米国にとっては（他の国にとっても）ますます魅力的な市場になる。
それに、中国は米国の国債を大量に持っているので、米国は中国と戦争ができない。仮に日本が中国と戦争をした場合、米国は日本の味方にはつかないだろう。そのような状況で、対米従属を続けながら、憲法を改正して日本を戦争のできる国にしようとすることは、日本国民にとって大変危険だ。
いざ戦争となれば、米中連合国対日本という構図になる可能性が高い。軍事的な戦争をしなくても、経済において、今後そのような構図にシフトしてゆくだろう。自民党政権やそれと同等の政治（すなわち官僚独裁）が続く限り、日本は衰退し続けるだろう。
[この記事だけを読む。] [最新の記事を読む。]
二〇一三年 霜月 卅日 土曜日
■ 傷の湿潤治療 [/links]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
夏井睦著『傷はぜったい消毒するな』
また、人間の皮膚には多数の細菌が常に存在している。皮膚常在菌の多くは皮脂を餌としており、皮脂を細菌が脂肪酸に分解するため、人間の皮膚は弱酸性に保たれている。化膿の原因となる細菌は、酸性の環境では増殖が抑えられる。消毒すると化膿の原因となる細菌もいなくなるが、皮膚常在菌もいなくなる。すると、化膿の原因となる細菌が最初に増える。
このように、消毒というのは、傷を治すには逆効果なのだ。また、一般的な傷の治療では傷口を乾燥させるが、表皮細胞や皮膚常在菌が増殖するには水が必要だ。乾燥もやはり傷の治癒を阻害する。そこで夏井は、傷口を消毒せず乾燥させない「湿潤治療」を実践している。これで、擦り傷でも火傷でも、痛むことなくすぐに治るそうだ。
では、なぜ多くの医者が傷を消毒し乾かし続けているのか。その理由は、今までそうしてきたからというだけだ。
そもそも最初に消毒を提唱したのは、夏井によれば、19世紀の医師ゼンメルワイスだそうだ。当時は、病院で出産した女性の一割から三割が産褥熱で死んでいた。その主な原因は、医師に手を洗う習慣がなかったことだ。ゼンメルワイスは、解剖を終えた後に手を洗い、出産に立ち会う前にも手を洗った。それだけで産褥熱は大幅に減った。当然ゼンメルワイスはそのことを発表した。ところが、その結果ゼンメルワイスは、学会から無視されたばかりか、大学から追放された。
そのころ、パスツールが、腐敗の原因が微生物であることを示した。それにヒントを得たリスターという医師が、傷口を石炭酸で洗い、石炭酸に浸した布で覆ったところ、傷口が化膿しなくなった。リスターも当初は医学会から無視されたが、コッホが細菌を発見し、化膿の原因が細菌であることを証明すると、リスターの方法が受け入れられた。コッホはまた、細菌は水がなければ増殖しないことも示した。そこでリスターは、傷口を石炭酸で消毒するだけでなく、乾燥させるようにした。
20世紀になると、皮膚常在菌が知られるようになり、傷が治る過程についても分かってきた。ところが、今でも多くの医師は、消毒と乾燥によって、有害な細菌だけでなく有益な細菌や人間の細胞を殺し続けている。それを夏井は「パラダイム」という用語で説明している。この言葉は、本来は科学史の用語だ。夏井は、医学におけるパラダイムについて一章を費やしているが、それを読むと、パラダイムについての夏井の理解は表面的であるように見える。
実際、湿潤治療は現在ではだいぶ市民権を得てきたように思われるが、それでも傷治療にパラダイムシフトないし科学革命が起きる気配はない。科学革命というのは、科学者集団の研究の仕方や研究すべき問題そのものが変わってしまうような変化をいうのであって、ゼンメルワイスとリスターの違いをパラダイムで論じるのは適当だと思うが、消毒・乾燥と湿潤治療との違いにパラダイムを持ち出すのは適切でない。単に新しい治療法が確立されたというだけだ。ただし、パラダイムという言葉は一般に拡大解釈されているので、夏井ばかりを責めることもできないのだが。
[この記事だけを読む。] [最新の記事を読む。]
二〇一三年 神無月 卅一日 木曜日
■ CSS だけでアクセシブルなラジオボタンとチェックボックス [/links]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
HTML のラジオボタンとチェックボックスはブラウザによって外見が大きく違う。それを統一しようと思った場合、本格的にするなら jQuery のプラグインを使ったりすればよいのだけれど、それほど大がかりにせずに CSS だけで外見を統一する方法を考えた。CSS3 を使えば、JavaScript はいらない（ただし、IE8 以前には対応しない）。
基本的な考え方は、Styling checkboxes and radio buttons using CSS に書かれている通り。本来のラジオボタンやチェックボックスを opacity: 0; で透明にして隠し、label 要素の margin-left を負の値にして、本来のボタンの上にカスタムボタンをかぶせる。
本来のボタンを display: none; で隠すというコードを紹介しているウェブページが多いが、その方法には致命的な欠陥がある。ボタンをキーボードで操作できなくなるのだ。-webkit-appearance: none; を使っている例もあるが、これは当然 Webkit 系のブラウザ（Chrome や Safari など）でしか有効でない。
上記のページでは、ボタンの外見を画像で作って、その画像を label 要素の背景にしている。しかし、アクセシビリティを考えたら、文字を大きくしたときにボタンも比例して大きくなるほうがよい。(それに、画像を用意するのは面倒だ。）
最小限必要な HTML は概ね以下の通り。
<p><input type="radio" id="radio"><label for="radio">ラジオボタン</lable></p>
<p><input type="checkbox" id="checkbox"><label for="checkbox">チェックボックス</lable></p>
まずは本来のボタンのスタイルを指定する。幅をカスタムボタンと同じにした上で、透明にして隠す。
input[type="radio"],
input[type="checkbox"]{
font-size: 100%;
width: 1em;
margin: 0;
padding: 0;
opacity: 0;
}
次に、カスタムボタンを作って上にかぶせる。色はお好みで。border-width は、フォントサイズが 16 ピクセルのときに 3 ピクセルになるようにしている。margin-top と margin-right は位置調整なのでお好みで。
input[type="radio"]+label:before,
input[type="checkbox"]+label:before{
display: inline-block;
content: "";
vertical-align: top;
background-color: white;
color: black;
border-style: solid;
border-width: 0.1875em;
width: 0.625em;
height: 0.625em;
margin-left: -1em;
margin-top: 0.25em;
margin-right: 0.25em;
}
input[type="radio"]+label:before{
border-radius: 0.5em;
}
input[type="checkbox"]+label:before{
border-radius: 0.1875em;
}
そして、チェックしたときのスタイルを指定する。
input[type="radio"]:checked+label:before,
input[type="checkbox"]:checked+label:before{
border-style: double;
border-width: 0.5em;
width: 0;
height: 0;
}
チェックボックスは次のようにしてもよい。
input[type="checkbox"]:checked+label:before{
content: "\2714";
line-height: 0.625;
}
フォーカス時のスタイルを指定するのも忘れずに。
input[type="radio"]:focus+label:before,
input[type="checkbox"]:focus+label:before{
outline: 1px dotted;
}
outline ではなく box-shadow を使うと、アウトラインをぼかすことができる。色や太さはお好みで。
input[type="radio"]:focus+label:before,
input[type="checkbox"]:focus+label:before{
box-shadow: 0 0 1px 2px orange;
}
以下で動作を確認できる。マウスでもキーボードでも操作できること、ボタンの大きさがフォントサイズに比例していることに注意してほしい。ただし、繰り返しになるが、IE8 以前には対応しない。
[この記事だけを読む。] [最新の記事を読む。]
二〇一三年 長月 廿五日 水曜日
■ たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる [/links]
この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。
この記事は古くなっています。改訂版があります。
ウェブサイトをスマートフォンに対応させるために <meta name="viewport" content="..."> と指定することは、多くの人が知っていると思う。しかし、content の中身を何にするべきか本当に理解している人は、日本ではごく少ないようだ（かくいう私もつい最近まで理解していなかったのだから、大きなことは言えない）。
試しに「meta viewport」を Google で検索すると、以下のページが上位に出てくる。
Quick Tip: Don't Forget the Viewport Meta Tag @ Webdesigntuts+
A tale of two viewports - part two @ QuirksMode
Configuring the Viewport @ Apple Developer
ところが、日本語ページに限って検索結果上位 20 件を見てみたところ、これら３つの英語のページで書かれていることを理解していると思われるページは１つもなかった。もっとも、英語圏でも viewport meta タグを不適切に使っている人は多いようで、Stop using the viewport meta tag (until you know how to use it) という記事も見つけた。
先に結論を書いておく。適切な設定は、ページ幅が固定されているウェブページの場合、viewport meta タグを書かないか、
<meta name="viewport" content="width=(幅をピクセル数で指定)">
とする。ページ幅が可変（リキッドレイアウトとか RWD とか）のウェブページの場合、
<meta name="viewport" content="initial-scale=1.0">
とする。たいていの場合は、この３つのいずれかで用が足りるはずだ。
以前よく見られた（いまでも見かける）設定は次の通り。
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=no">
これは最悪だ。user-scalale の設定はあったりなかったりするが、あってもなくても同じ。最小が 1 で最大が 1 なのだから、どちらにしてもズームはできない。この「ズームができない」ということが問題だ。コンテンツを見せるためのウェブサイトであれば、ユーザーにズームをさせないというのは、ユーザビリティを多いに損ねる。ウェブを見る人は目がいい人ばかりではない。
最近は次の設定を見かけることが多い。
<meta name="viewport" content="width=device-width, initial-scale=1.0">
これなら、ユーザーがズームできるし、最近のスマートフォンでは表示も適切だ。しかし、iOS 5 以前では、画面を横向きにするとページが拡大されるという問題があった。これは iOS のバグではなく、設定が不適切なのだ。
そもそも width で指定しているのは何の幅かといえば、viewport の幅だ。ブラウザは、ウェブページを表示する前に、ウェブページを viewport の大きさに合わせてレンダリングする。そしてレンダリングした結果を、デフォルトでは viewport の幅がブラウザウィンドウの幅に合うように、拡大したり縮小したりして表示する。その拡大縮小のスケールを指定するのが initial-scale だ。
実は、iOS の場合、縦向きでも横向きでも device-width は 320 ピクセルで変わらない。（Android では、縦向きと横向きで device-width が変わる。）縦向きで表示するときは、ブラウザウィンドウの幅が 320 ピクセルで viewport の幅も 320 ピクセルでスケールが 1 だから、何も問題がない。ところが端末が横向きになると、ブラウザウィンドウの幅が 480 ピクセルになるのに、viewport の幅は device-width すなわち 320 ピクセルのままだ。スケールも引き続き 1 だから、width と initial-scale の設定がお互いに矛盾することになる。iOS 5 以前では width が優先されてページが拡大されるが、iOS 6 以降では initial-scale が優先されて viewport の幅がブラウザウィンドウの幅と同じになる。
矛盾を避けるには、width と initial-scale のどちらか片方のみを指定すればよい。もう片方はブラウザが自動的に計算してくれる。そして、device-width の解釈が iOS と Android で違うので、width=device-width の設定は使わない方がよい。
2013年9月29日追記 ところが、ここに IE が登場すると、例によって困ったことになる。Windows Phone の IE は initial-scale をサポートしていない。Windows Phone に対応しようとすれば、width=device-width と initial-scale=1.0 の両方を指定しなければならない。ということは、Windows Phone をとるか iOS 5 以前をとるかの二者択一を迫られるわけだ。
現状、日本では Windows Phone のシェアは極めて低いので、日本国内のみを対象にするなら initial-scale のみがよいだろう。しかし、Microsoft が Nokia を買収するので、今後日本でも Windows Phone 端末が販売されるかもしれない。それに、新しい iOS が矛盾をうまく回避してくれるようになったのだから、将来を考えたら width と initial-scale の両方を指定するのがよいかもしれない。
もっとも、将来と言えば、おそらく viewport の幅は meta タグではなく CSS で指定するようになるだろう。構造と表現を分離するという HTML5 の基本理念から言えば、viewport の幅を HTML ファイルの中で指定するというのはおかしい。そう考えると、ほとんどの人がまちがえているわけではなく、まちがえたのは Safari の開発陣だということになるだろう。
hiroさんのコメント：
ちょうど設定をやっている際にこお記事を見て助かりました。
最初に参照したページが、まさに間違いの例でした。
確かに、viewportがhtmlの中に記載されるのは不自然ですよね。
どう見てもcssの範疇なのに。
羽鳥さんのコメント：
hiro さん、コメントありがとうございます。
この記事を書いたときには iOS5 のシェアがそれなりにあったのですが、今では iOS5 以前を使っている人はほとんどいないでしょうから、ページ幅可変の場合は width=device-width, initial-scale=1.0 の指定が適切だろうと思います。
W3C では CSS に @viewport ルールを加えようとしているようなのですが、仕様が 2011 年からドラフトのままです。「将来は CSS で」という私の予想ははずれるかもしれません。
metaさんのコメント：
このページをスマホで見ると横スクロールしないといけないので非常に読み辛い
羽鳥さんのコメント：
meta さん、コメントありがとうございます。
スマホ未対応の件、申し訳ありません。ソースを見ていただくと分かる通り、table タグを使った古式ゆかしいサイトになっております。スマホ対応の予定はあるのですが、本業が忙しくて手が回っておりません。
[この記事だけを読む。] [最新の記事を読む。]
カテゴリ
[/language] (98)
[/links] (254)
[/mac] (114)
[/music] (36)
[/origami] (406)
[/this_blog/ajax] (7)
[/this_blog/blosxom] (4)
[/this_blog/history] (12)
[/this_blog/perl] (9)
最新記事
◇ パスワードについてのあなたの常識はもはや非常識かもしれない・その１ [/links]
◇ ニューラルネットワークとディープラーニングで翻訳はどうなる・その５ [/language]
◇ ニューラルネットワークとディープラーニングで翻訳はどうなる・その４ [/language]
◇ HTTPS 対応 [/links]
◇ ひらがな・カタカナ学習ウェブアプリ [/links]
◇ 日本語の「た」と英語の過去形 [/language]
◇ ORI-REVO で回転楕円体を折る・その２ [/origami]
◇ ORI-REVO で回転楕円体を折る・その１ [/origami]
◇ 折り紙建築 [/origami]
◇ 折鶴に松図小柄 [/origami]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その６ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その５ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その４ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その３ [/links]
◇ 改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その２ [/links]