知り合いのフィンランド人からこんな画像が送られてきた
近所の服屋で売っているのを発見したらしい。フィンランドはさだめしカオスな国なのであろう。
モルグ街の殺人(The Murders in the Rue Morgue)を読んでいるが、思いの外に英語が難しい。考えてみれば、もう160年ぐらい前の文章なのだから、今の英語と違っているのは当然なのだが。
ともかく、モルグ街の殺人は、探偵小説の初めとなった小説である。ファンタジー小説における指輪物語にあたる本だ。
The Murders in the Rue Morgue
あるテキサス人が、放棄されていた家を16ドルで手にいれた。
動画によると、この家は放棄されていて、誰も所有権を主張していなかったそうだ。元の住人は賃料が払えず手放し、家を管理していた不動産会社は倒産した。そのため、家の権利は宙ぶらりんで、誰も権利を主張していない状態であった。
そこで、この男は、一ヶ月もの間、テキサスの法律を調べ、この放棄された家の所有権を主張する法的な申請を行った。その申請手続きにかかった金が16ドルとのこと。このまま三年間、元の所有者か、倒産した不動産会社の負債をもっていた銀行に権利を主張されずに住み続ければ、完全にこの男の所有物になるそうだ。しかし、元の所有者が権利を主張するには未納の賃料を払わねばならず、銀行が権利を主張するには、相当に複雑な手続きをしなければならない。だから、誰からも権利を主張されることはないだろうと男は踏んだそうだ。なんとも賢い男である。
しかし、お隣のレイシストな白人ビッチは、どうもこのやり方を気に入っていないようだ。
BBC News - Lucas loses Star Wars copyright case at Supreme Court
ストーム・トルーパーの衣装をデザインした人物が、その衣装を作って売っていたのだが、それに対してジョージ・ルーカス側が文句をつけた。
問題は、当時、明確な契約というものが存在しなかったらしい。
今回、イギリスの最高裁で、ジョージ・ルーカスは販売差し止めの権利を持たないという判決を下したそうだ。
イギリスの著作権法はよく分からないのだが、記事では、工業意匠の著作権の保護期間は15年であると言っている。そういうものなのだろうか。
しかし、これはルーカスの他の映画のデザインにも影響しそうだ。
追記:オリジナルの設計者の主張は、コスチュームは芸術品ではなく、実用品だというものらしい。イギリスの法では、そういう工業意匠の著作権の保護期間は15年間なのだとか。
CSSで、画像や動画を垂直方向の中央に配置したいと考えた。さっそくどのプロパティを使えばいいかググったのだが・・・どうもプロパティ一発というわけにはいかないようだ。もちろん、この問題は、いまさら知らなければモグリであるほどの古典的なものだが、CSSグルではない私は知らなかったので、書いておこうと思う。
もちろん、垂直に中央配置する方法はある。しかしどの方法も、汚いハックなのである。さらに、大抵の初心者が陥る問題がある。
まず誤解しやすいのが、vertical-alignプロパティであろう。これは名前が宜しくない。vertical-alignは、インライン要素のラインボックス(つまり文字列のレイアウト)の垂直方向の配置を指定するためのプロパティである。残念ながら、凡人が期待するようには動かない。
ただし、テーブルセルにvertical-alignを適用した場合のみ、凡人が期待するように動く。つまり、要素自体のアラインを垂直方向に対して指定できる。
CSS 2.1: vertical-align
CSS2.1: Table height algorithms
つまり、vertical-alignには、二つの全く異なる機能が混在しているといっていい。なんとも悲惨な仕様である。
ただし、このテーブルセルの仕様は利用できる。つまり、displayプロパティで、要素をtable-cellに変えてしまえば、vertical-alignが使えるのだ。ただし、その要素を囲むdisplayプロパティがtableな要素が必要になってしまうのが欠点だが。
<div style=" display : table ; "> <div style=" display : table-cell ; vertical-align : middle ; "> <!-- 実際のコンテンツ --> </div> </div>
この方法は、コンテンツのheightをあらかじめ知っておく必要はないし、コンテンツのheightを動的に変えても問題のない、現時点で最良の方法である。IE8以下では動かないようだが、CSSの信奉者は、IE8などという劣ったブラウザーはもとより使わないので問題はない。
一応、CSS 3には、Flexible Box Modelというのが提案されているようだが、どうも仕様が二転三転して、未だに固まっていないように思われる。現時点では、まだ使うべきではない。
C++0xの規格はほぼ固まり、もはや変更されることはない。恐らく、このまま規格制定されるものと思われる。さて、今C++の主要なコンパイラーを上げるとすると、gccとclangをおいて他にはない。MSVCはオモチャだ。右の両コンパイラーは、C++0xの新機能を実装し始めている。もちろん、まだ不完全な実装も多いが、とりあえず遊べる程度には実装できている機能も多いので、比較してみることにする。
gccのC++0xサポート状況は、以下のページに簡易な一覧がある。
C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)
clangのC++サポート状況は、以下のページに簡易な一覧がある。
面白いことに、どちらか片方のコンパイラーでしか実装されていない機能が、結構ある。ここで少し比較をしてみようと思う。もちろん、細かく観ていくときりがないので、大きな機能だけを紹介する。また、どちらのコンパイラーでも実装されている機能は省く。実装されていない機能は紹介する。
gccしか実装していない機能は、以下の通りである。
初期化リスト
std::vector<int> v = { 1, 2, 3, 4, 5 } ; // 便利便利
lambda
std::string str("表示するよ:") ; // キャプチャもできるよ std::for_each( v.begin(), v.end(), [=](int i){ std::cout << str << i << std::endl ; } ) ;
ローカルクラスと無名クラスをテンプレート実引数に取る
template < typename T > void f(T) { } void g() { struct X { } ; std::vector<X> v ; // ローカルクラスはOK enum { e1 } ; f( e1 ) ; // 無名クラスもOK }
生文字列リテラル
char16_t const * ptr = uR"( ここには何でも書ける。 もちろん、\とかも書けるし、 この改行だって、ちゃんと改行として反映される。 ただし、\に続くuとUは使えないので注意。 "に続く(とか、)に続く"も書けない。 もちろん、連続しなければOK。 )" ;
unionの制限取っ払い
union U { int x ; double d ; // 普通のクラスは余裕で持てる。 std::string s ; // コンストラクターだって楽勝。 U() : s("initialize") { } // メンバー関数もOK。virtual関数はダメだけど void f() { } } ;
constexpr
constexpr int twice( int x ) { return x * 2 ; } template < int I > struct X { } ; X< twice(100) > x ; // X<200>
clangしか実装していない機能は、以下の通りである。
コンストラクターのデリゲート(丸投げ)
struct X { X( int i ) : X(i, 0) { } // 丸投げ X( int i1, int i2 ) { } } ;
非staticデータメンバーの宣言の初期化子
struct X { int m = 0 ; X() { } // mは0 X( int i ) : m(i) { } // mはi } ;
テンプレートエイリアス(エイリアス宣言も含む)
using A = int ; A a ; // int template < typename T > using B = T ; B<int> b ; // int template < typename T > using C = std::vector< T, CustomAllocator > ; C<int> c ; // std::vector< int, CustomAllocator >
まだどちらも実装していない機能
アトリビュート
[[]] int [[]] x ;
アライメント
struct X { int x ; double d ; } ; void f() { alignas(X) char a[100] ; // X型に要求されるアライメントを指定 alignas(16) char b[100] ; // 16バイトアライメントを指定 alignas(X, 4, float) char c[100] ; // X型と4バイトとfloat型とで、一番強いアライメント要求を指定 alignof(int) ; // int型に要求されるアライメント(定数式) }
コンストラクターの継承
struct Base { Base() { } Base(int) { } Base(double) { } } ; struct Derived : Base { // コンストラクターを継承 using Base::Base ; } ; Derived d(0) ; // OK
ユーザー定義リテラル
void operator "" _owata ( char16_t *, std::size_t ) { } int main() { uR"(  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄」 ―――――――――――――‐┬┘ | ____.____ | | | | | | | ∧_∧ | | | |( ´∀`)つ ミ | | |/ ⊃ ノ | |  ̄ ̄ ̄ ̄' ̄ ̄ ̄ ̄ | ミ ユーザー定義リテラル )"_owata ; }
今までは、
http://twitter.com/search?q=文字列
だったのに、今日からは、
http://twitter.com/#!/search/エスケープされた文字列
になってる。URIの文字、, / ? : @ & = + $ #などを、たとえばJavascriptでいうencodeURIComponent()を使ってエスケープしなければならない。
URLのエスケープは、Bloggerのテンプレートのexprではできないので、Javascriptを使って行うことにした。
また、すべての検索を表示するには、http://twitter.com/#!/search/realtime/というURLになっている。
慣習的に、malwareを「ウイルス」とか「ワーム」とか「トロイの木馬」などと読んでいる。これは、やめるべきである。結局、これらの言葉は、一般人には理解出来ない専門家が、ある特定のソフトウェアのカテゴリー分けをするために使っていた符牒である。符牒は、一般人に使われることを想定していないのだ。
寿司屋では、「上がり」とか「おあいそ」といった言葉が使われる。これは、「うぉーい、客が帰ェるぞぉ。茶ァ出せ茶ァ」とか、「勘定しろぉい」など叫ぶのが、あまりにも客に対してぶあいそであるので、店側の人間だけで通じる、同様の意味を持つ暗号を取り決めたのだ。それが、いつの間にか客側にも広まってしまい、今では、客が「上がり頼むよ」とか「今日はこのへんでおあいそして」などというようになってしまった。本来、客側での使用を想定していない言葉が定着してしまったために、知らないものから見ると、非常に不思議に聞こえるのである。
ウイルス、ワーム、トロイの木馬にも、同じことが言える。これらの用語は、一般人が使うべきではない。英語圏では、すでにこれらの用語は廃れ、今では、マルウェア(malware)という言葉が使われている。これはMalicious Softwareの略である。日本語に直すと、悪意あるソフトウェアとなる。
単に、「彼、ウイルスを保管せしによりて罪せらる」というのは、誤解を招く。正しくは、「彼、ウイルスを邪まに用いんと欲して保管せしによりて罪せらる」と書かれるべきなのだ。しかし、これがもし、「彼、悪意あるソフトウェアを保管せしによりて罪せらる」とあれば、誤解は生じないはずだ。
したがって、ウイルス、ワーム、トロイの木馬といった用語は、使ってはならない。マルウェアも、日本人にはmalfunctionなどと使われるmalという言葉の意味がわからないので、不適である。「悪意のあるソフトウェア」という言葉を用いるのが、最もふさわしい。
月額1,000円見放題|アニメ・動画配信 / バンダイチャンネル
バンダイチャンネルが、月千円でアニメ見放題の動画配信を始めるらしい。第一話が無料でみられるようなので、ためしにTHEビッグ・オーを観てみた。
「THE ビッグオー」 | アニメ配信 | 無料動画2000本以上! | バンダイチャンネル
どうせ旧態依然のバンダイのやることだろうから、嫌な予感はしていたものの、品質が最悪である。まず、エンコードがクソである。正直いって観れたものではない。しかも、常に右下にロゴが表示されている。これで金を取るというのだから、呆れるばかりだ。あるいは、課金するとまた違うのだろうか。
さらに極めつけは、日本国外から観ることはできないということだ。せっかくアニメ好きの外人に紹介したのがバカみたいだ。クソにもほどがある。
ところで、THEビッグオーは、個人的に好きな数少ないアニメのひとつである。だいぶ世間からは過小評価されているが、私の中では、文句なく最高の巨大ロボットアニメである。一言でいえば、バットマンが巨大人型ロボットに乗って戦うアニメである。そのあまりにアメコミかぶれの内容から、日本よりアメリカでの評価が高い。ただし、アメリカのスポンサーを得て作られた第二期は黒歴史なので、見る必要はない。
しかし、なぜアニメ業界はこうも旧態依然なのだろう。いまどき光学ディスクなど売れるわけがない。売れないから値段を高くして、ますます売れなくなっている。光学ディスクにしたって、ブルーレイほどの容量があれば、一枚に一期程度を収めることは可能である。それが、一枚に二話程度入っているだけだ。いちいちディスクを入れ替えろというのだろうか。
要するに、アニメを見るのはものすごく不便なのである。技術の進歩に全く追いついていない。いまだに、VHSとおなじような感覚でいるのだ。時代は変わったというのに。
この問題だけを完結にまとめた文章が必要であると感じたので書く。
テンプレートなコンストラクターや代入演算子は、コピー/ムーブコンストラクター、コピー/ムーブ代入演算子とはみなされない。したがって、テンプレートなコンストラクターや代入演算子の存在は、暗黙のコピー/ムーブコンストラクターやコピー/ムーブ代入演算子の生成を妨げない。
ただし、テンプレートなコンストラクターや代入演算子は、コピー、ムーブが必要な場合に、オーバーロード解決の候補になる。
struct X { X() { } template < typename T > X( T & ) { } // 以下の暗黙のコピーコンストラクターが生成される // X( X const & ) ; } ; int main() { X a ; X const b( a ) ; // テンプレートコンストラクター X c( b ) ; // 暗黙のコピーコンストラクタ― }
bの初期化では、aは非constなオブジェクトであるので、オーバーロード解決により、テンプレートコンストラクターが選ばれる。cの初期化では、bはconstであるので、オーバーロード解決により、非テンプレートな暗黙のコピーコンストラクターが選ばれる。
もし、この挙動が嫌であれば、コピーコンストラクターを明示的にdelete定義しておけばよい。
struct X { // 暗黙のコピーコンストラクターの生成を阻害 X( X const & ) = delete ; }
クラスXのコンストラクターは、Xを引数に取ることはできない。
struct X { X(X) ; // エラー } ;
ただし、テンプレートの場合、インスタンス化の結果がこのようなシグネチャになる場合、インスタンス化されない。
struct X { X() { } template < typename T > X( T ) { } } ; int main() { X a ; X b( a ) ; // 暗黙のコピーコンストラクター }
したがって、テンプレートなコンストラクターを、安心して書くことができる。
代入演算子も、同様である。テンプレートな代入演算子は、コピー代入演算子ではない。ただし、コピーが必要な場面では、テンプレートな代入演算子も、オーバーロード解決の候補になる。
[重要]zoomeサービス終了のお知らせ zoomeインフォメーション - 動画共有サイトzoome
zoomeがとうとう修了するらしい。確かに、他の動画サービスに比べて、何の特色もない平凡なサイトであった。規模でいえば、どの動画サイトも、YouTubeには勝てない。ただし、ニコニコ動画は、コメントなどの、動画以外の要素で勝負している。ではzoomeはというと、アップロードした動画が、ある基準を満たしている場合、再エンコードされない程度の要素しかなかった。これでは、一部の動画ヲタを除いては、誰も喜ばない。そんな一部のユーザー向けに課金を初めても、収益の上がるはずがないのは当然だ。終わるべくして終わった動画サイトと言える。
それにしても、動画サイトというのは、もうすっかり一般的になったものである。私は、大衆化したものには興味をなくしてしまう性質なので、最近は動画サイトも積極的に観ているわけではない。たまに、Google Readerを通じて流れてくる、面白い動画の紹介ページを通じて、間接的に観る程度である。
では、今注目しているものは何かというと、これが実は、存在しない。Pixivは毎日みているが、これも、最近きな臭い話が聞こえてきて、いつまでつづくとも思えない。思うに、インターネット自体が、すでに大衆化してしまい、これ以上進歩する見込みがないのではないだろうか。この現状を打破するためには、インターネットを超える「何か」を発明するしかない。
もちろん、その「何か」を、いま予測するのは不可能である。かつて予測された、蒸気で動く鉄の馬とか、空を飛ぶ車、体にぴったりとフィットする機能的に無駄のない統一された服、栄養のバランスが完璧にとれた完全食は、一向に実用化される気配がない。
ただ、あえて妄想を書くとすれば、アプリケーション層より下層が、P2Pになったら面白いのではないかと思う。たとえば、すべてのノードは無線通信装置を備えており、数十メートルから数百メートルぐらいの範囲の他のノードと通信できる。各ノードが接続しあい、P2Pなネットワークを構築する。無線の届かない距離にあるノードに対しても、ノードを中継することにより通信ができる。
これにより、検閲の不可能なネットワークを構築できるだろう。
まあ、もちろんこれは妄想であって、実現することはない。未来は常に、予想外の技術にとって変わられるのだ。ただし、私が生きているうちに、インターネットはラジオやテレビと同じく、過去のメディアになっているとは思う。それだけの時間はあるのだから。
このスレ読んで、ちょっと遠州弁を書き下してみたくなったんだに。遠州弁と言っても、俺が使ってるのは、旧浅羽町で話されてた言葉だに。今、市町村合併のあおりを受けて、もう隣の袋井市と合併してしまったので、浅羽町という町はなくなってしまったんだに。浅羽町は、田んぼとメロンハウス(メロン栽培のための温室のことだに)しかないド田舎だに。まあ、基本的には、静岡県西部で使われている一般的な方言と、あまり代わりはないと思うに。
まず特徴的なのは、語尾につく助詞だに。よく、ダニ、ダラと言われるけど、これ実は違うと思うに。ダは余計で、本当はニとラだと思うに。というのも、ダニ、ダラというのは、ニやラをとったら、普通にダで終わる日本語になるら? もちろん、ニとラの意味はなくなってしまうけど、言葉としては問題はないら? ダで終われない言葉の場合、ラやニが直接つくことになるに。ただし、それ単体で、「ダニ!(そうだ!)」、「ダラ?(そうでしょう?)」と使うことはあるに。
さて、ニというのは、強意断定という意味だに。意味としては、!をつけるような意味だに。ラというのは、強意疑問だに。なんでもラをつければ、疑問文になるに。これは単純に?ではなくて、強い念押しの、相手に同意を求めるような意味合いを持つ疑問だに。基本的に、この二つさえ覚えておけば、遠州弁は完璧にしゃべれるに。というのも、今の遠州弁話者の間では、もう遠州弁特有の言葉というのは、ほとんど死語になってるからだに。ラジオやテレビ(まだ当時はインターネットなんて主流じゃなかったに)の影響だと思うに。
もうひとつは、間投詞としてのハァだに。これは、「まあ」のような意味を持つに。子供はあんまり使う言葉じゃなかったに。じいさんばあさんが家にいるような子は別だけど。
あと気をつけることとしては、基本的に遠州弁ネイティブは敬語なんて話さないに。まあ、ド田舎だから敬語なんて必要なかったんだら、きっと。俺は、幼稚園の頃関西から引っ越してきたんだけど、母親が電話口に出るときは、必ず「はい、○○でございます」というので、友達から、「お前んちのおばさん、サザエさんだら、バカだら」ってバカにされてたに。今から思えば、どっちがバカかは、明白だら? 片や敬語を使える人間と、敬語の使えない辺土の土人だに。
まあ、それはともかく、せっかくだから、まだ少々は生き残っていた方言特有の単語を紹介するに。といっても、これがおかしな話で、今から紹介する二語は、小学生しか使ってなかった言葉だに。なぜか、中学生になると、みんな、全然使わなくなってたに。
ひとつは、ジーコン。これは、自転車という意味だに。なんでジーコンというのかは、よくわからないに。多分、自転車のチェーンがジーコジーコと鳴るから、ジーコンなんじゃないかと、その当時は考えてたに。
もうひとつは、ズッパ。これは、「すぐに」、という意味だに。ただ、「すぐに」、じゃ、ズッパの速さには足りないと思うに。だから、ここはソッコーと訳すほうがいいと思うに。ソッコーは全国的に知られてる言葉だら? 用例は、以下のような感じだに。
「おい、今日(学校から)帰ったら、俺んち遊びに来いよ」
「おう、ズッパで行くに」
ズッパで行くときは、たいていジーコンを使うに。ド田舎で家離れてるし。
ズッパの語源も不明なんだけど、素早く移動することを、「つっぱしる」というから、そこから来ているんじゃないかとは思うに。だとすると、ヅッパと書いた方がいいんだろうか(ここでは、あまり自身がないから、ラは使えないに)。もっとも、ヅはあまり一般的ではないから、ハァ、ズの方が自然だら。
なんで中学生になると、ズッパとジーコンを使わなくなるのかは、よく分からないに。日本全国に、子供しか使わない方言は、もっとたくさんあるんじゃないかと思うに。そういう言葉は、方言研究からも、漏れているんじゃないかと思うに。そういう言葉が消えてしまう前に、何とかして採集をするべきだと思うに。
ほんで、今京都に住んでるわけやけど、ほんま京都の言葉はわからへんねん。引っ越してきてから一年ぐらいは、ほんま苦労したわ。皆何言うてるか、さっぱり分からへんねやから。しかも、京都と大阪では言葉が違ういいよるねん。何が違うねん、何が。そんなん全然分からんわ。まあ、今はラジオ、テレビ、インターネットなどの普及で、明確な違いはどんどん薄れてきてるんやろうけど。いま書いてるこれも、ほんまの京都弁やないと思うんや。まだ京都に住んでからそんなにたってへんもん。
でもな、京都に住んでからおもたんやけど、古典って、やっぱり当時の都である、京都の発音で読まれてたんやろか。たとえば、今昔物語集には、「早ゥ」ってな言葉が頻出するんや。今の京都弁でも、「はよぅ」とかいうやろ。今の発音は、当時の発音をどのくらい残してるんやろか。
もっとも、この早ゥは、はやくしろという意味では、あまり用いられてへんねやけどな。大抵は、以前に知られていない事実が判明したときに、「早ゥ、○○ナリケル」なんて使ってるんやけど。まあでも、今の一般的な用例がないわけやない。例えば、今昔物語集の巻第二十八 金峰山別當、食毒茸不酔語第十八では、今の別當がなかなか死なないので、役職が空かず、「此ノ別當早ゥ死ネカシ」といって毒キノコを食わせる話があるんや。なかなか人間的な発想で面白いやろ。他にも、弘法大師が栗を煮るのを邪魔した修円僧都と、「互ヒニ死ネ死ネト呪詛シケリ」とあったり、古典にしては珍しく、人間味あふれる本や。読んどかな損やで。
Chromium Blog: Chrome Extensions: Now with more powerful scripts and improved proxy management.
なんと、content scriptからクロスドメインなXMLHttpRequestができるようになった。これで、いちいちマヌケにもbackground pageを介してメッセージのやり取りをする必要はない。パフォーマンスも向上する。
この仕様は常々疑問だったのだ。background pageといえども、manifesto.jsonに指定したpermissionを無視したXMLHttpRequestはできない。それならば、content script内で、permissionを考慮したクロスドメインなXMLHttpRequestができてもしかるべきだ。何しろ、こちとらはエクステンションなのだ。
さっそく、個人的に作って使っているエクステンションを書き換えたところ、体感できるほどパフォーマンスが向上した。
ちなみに、ユーザー側の利点としては、Greasemonky用のスクリプトで、GM_xmlhttpRequestを使っているという理由で今までは動かなかったスクリプトが、chromeでも動くようになる。
Boost 1.47.0がリリースされた。
このリリースには、新たにratioとchronoが含まれている。これは、C++0xに追加された、時間と単位のライブラリである。
ドキュメントを流し読みしてみたところ、Boostのratioには、MPLのメタ関数を適用できる拡張が施されている。chronoには、プロセスやスレッドのCPU時間を得られるクロッククラスが追加されている。
Verblingという、始まったばかりのWebサイトがある。これは、Chatrouletteに似ている。今現在、チャットをしたいと考えている人同士のマッチングを行うサービスだ。
Chatrouletteと違うのは、語学を目的としていることだ。つまり、英語を知っていてスペイン語を学びたい人間と、スペイン語を知っていて英語を学びたい人を結びつけるサービスである。このような学習方法を、英語では言語交換(Language exchange)という。
インターネットのおかげで、言語を学ぶのは便利になった。例えば、リーディングを学ぶのはたやすい。有名な古典で、著作権の切れているテキストは多く出回っているし、現代文ならば、どのサイトでも豊富にある。リスニングも容易い。YouTubeを始めとした、動画サイトは世にあふれている。ライティングもたやすい。チャットサービスは山ほどあるし、lang-8のような、ユーザーによる添削サイトもある。
ところが、スピーキングとなると、これがなかなかうまくいかない。確かに、Skypeを始めとした、ボイスチャットサービスは山ほどある。しかし、相手を探す方法が、今ひとつ洗練されていない。
確かに、言語交換の相手を見つけることを目的としたWebサイトはある。実際に相手は見つかる。ただし、練習をするのは難しい。というのも、相手の住んでいるタイムゾーンは様々であり、仕事なども様々であるので、お互いに都合のつく時間は、なかなか存在しない。およそ勉強というものは、勉強をしたいと思うときにするのが、一番効率がいい。ところが、その肝心の勉強ができる時間に、相手がいるとは限らない。そのため、無駄にskypeのコンタクトだけ増えていくのである。
そのため、今からすぐに、会話を開始できる人間と自動的にマッチングしてくれるサービスというのは、都合がいい。
とはいっても、Chatrouletteのようになってもらっては困る。つまり、チンコやマンコを見せつける人間はお呼びではない。はたしてこのサービスが、健全に本来の目的のみに使われてくれるのか、その辺は大いに不安である。
また、どうも今現在、英語とスペイン語のマッチングしか行っていないらしい。残念。一応、将来的にはもっと多くの言語をサポートする意志はあるようなので、覚えておこうと思う。
Chromium Blog: Using Cross-domain images in WebGL and Chrome 13
クロスドメインを禁止することは重要である。もしクロスドメインが完全に許されているのならば、任意のドメインのWebサイトから、閲覧者のログイン済みのGMailやTwitterなどの他のサービスにアクセスできてしまう。
これは、画像や動画といったリソースでも同様である。例えば、あるサイトは、ユーザーに応じて画像や動画を生成するかもしれない。その場合、Javascriptから画像の内容を取得できてしまうのは、セキュリティ上危険である。img要素は、クロスドメインの画像を表示できる。しかし、Javascriptから画像の内容を取得する方法はない。
img要素なら問題はないし、2Dのcanvasは、他のドメイン下の画像や動画が描画されたときは、ピクセルが得られないようになっている。
ところが、WebGLの場合は、単にピクセルを得られないようにするというのでは、不十分である。なぜならば、WebGLはシェーダーが使えるからだ。シェーダーを使って、ピクセルごとに処理時間を変えるなどすれば、リソースの内容をほぼ正確に推測できてしまう。これはまずい。
そこで、WebGLのテクスチャーとして使うリソースを、他のドメインでホストする場合は、その他のドメインのサーバーが、Cross-Origin Resource Sharingを実装しなければならない。クロスドメインは問題ないということを証明できるのは、自分ではないのだ。
HTML5 Parsing in IE10 - IEBlog - Site Home - MSDN Blogs
とうとうIE10では、Conditional Commentを廃止するようだ。よくぞ決断した。MSにとっては非常に難しいことだったに違いない。しかし、これは重要なことである。同じHTMLがすべてのブラウザーで同じように解釈されるのは当然である。条件コメントは廃止されるべきである。
しかし、IE10のためにOSをアップグレードしたいのだが、カネがない。PCもいい加減に買い換えないとまずいのだが、カネがない。C++本をさっさと書き終えて、真面目な仕事を探さなければ。
私はこれからの時代、コンテンツは無料になると確信している。いや、これは誤解を招く言い方である。本当は、コンテンツが売れなくなるのだ。
例えば漫画だ。私は常々、最近はロクな漫画がないことを嘆いていた(ただしジョジョを除く)。しかし、今気がついてみると、私は実際には、漫画をたくさん読んでいるのである。読むべき漫画がないというのは、商業漫画の話なのだ。
pixivというWebサイトがある。これは、絵の投稿サイトである。投稿されている絵の品質は様々であるが、非常に素晴らしい絵が、毎日大量に投稿されている。絵には、漫画も含まれる。
Pixivに投稿されている漫画には、非常に面白いものもあるのだが、商業漫画たりえない理由がある。例えば絵があまりうまくなかったり、内容があまりに偏っていて、万人受けしないということである。
商業漫画は、非常にコストの掛かる商売である。漫画を印刷して全国に流通させるのは、決して安くない。そのため、出版される漫画は、売れる見込みのある漫画ばかりとなる。これには、絵のうまさという要素もあるが、もっと重要なことには、老若男女すべてに受け入れられるかという要素がある。万人受けを狙うとすれば、共通して楽しめる内容にするしかない。このため、同じ年代の漫画は、似たり寄ったりな絵になり、ストーリーも似通ったものになる。つまり、いずれも似たような凡作ばかりで、平均からかけ離れた逸作がでてこないのである。
これは、漫画というものが市民権を獲得した近年、とみにみられる傾向である。漫画の黎明期は、実験的な漫画が多かった。昔の漫画が面白いのは、このためである。今の漫画は、売るために当たり障りのない内容ばかりである。昔と比べて、絵の質は上がっているものの、内容はむしろ劣化している。
これは、東京都の表現規制を待つまでもない。赤字にならないこと、売れることを追求した、大衆迎合の結果である。これでは芸術品の生まれるわけがない。
一方、Pixivのような投稿サイトは、もともと利益にならないのだから、好きなように描く。だから、飛び抜けた作品も多い。決して万人受けはしないものの、飛び抜けた作品が生まれる可能性がある。
動画に関しても同じだ。YouTubeというWebサイトがある。これは、動画の投稿サイトである。もちろん、YouTubeには他人の著作物が違法にアップロードさされているという批判もある。しかし、大部分の動画は、オリジナルである。私のよく見る動画は、完全に合法である。特に、私の大好きな猫の動画に関しては、一日に24時間以上もの動画がアップロードされている。これは、YouTubeだけで生涯に渡る猫動画の需要を観たせることを意味する。また、オリジナルの猫のアニメーションなども多数アップロードされている。わざわざ違法にアップロードされた昨今の糞アニメなどをみる必要はないのである。
では、文章はどうか。私に言わせれば、読むべき価値のある文章は、すでに書き尽くされてしまった。例えば、私は今日、古事記を読んだ。本居宣長が古訓の復元に努めてくれたおかげで、高等教育を受けていないこの私でも、スラスラと読むことができる。また、有名所の古文は、大抵インターネット上にテキストがあるので、金はかからない。
これは、英文学でも同じである。私の最も好きな英文は、Lord Dunsanyの文章であるが、彼の著作は、すべて著作権が切れている。 好きなだけ読むが良い。
追記:今、気がついたのだが、戦時加算を考慮すると、Lord Dunsanyのほとんどの著作物は、まだ著作権が切れていないということになるのだが・・・・・・。
つまり、娯楽作品に限れば、もはやコンテンツにカネを払う価値はないと言える。何故ならば、商業作品はつまらないし、合法的に無料で楽しめる作品は、世にあふれているからだ。いい時代になったものだ。
では、娯楽以外のコンテンツはどうなのか。例えば、プログラミングの参考書はどうかというと、これもやはり、商業的なコンテンツは廃れていくのではないかと思っている。個人がやっているWebサイト上の解説では、まとまった内容とはなりにくいことは確かだ。しかしこれも、複数のサイトを横断した縦横無尽な検索によって駆逐されてしまうだろう。それに、今後プログラミングの初期学習は、comp.std.c++やStack Overflowのようなプラットフォームが主流になるはずだ。
少し前から、gccのiostreamを使うとクラッシュしてしまう問題に悩まされていたが、どうやら問題が解決した。
私はgccを自前でコンパイルするのが面倒なので、コンパイル済みのバイナリを落として使っている。使っているのは、このサイトのビルドだ。
簡易なインストーラーが付属しているが、これは、単に指定したパス下にファイルを展開し、そこへのパスが、まだ環境変数に書かれていなければ、付け加えるだけである。アンインストーラーはないので、取り除くのは手動である。私は面倒なので、毎回、同じディレクトリを上書きしていた。
ところが、どうもこれがまずかったらしい。何故ダメだったかという理由はいくつか思い浮かぶが、それはもうどうでもいいことだ。とにかく、上書きしないことで問題を解決できた。
なるほど、大臣は客なのだな。
県にそれ、コンセンサス得ろよ。そうしないと我々、何もしないぞ。ん、ちゃんとやれよ。
今、後から自分は入ってきたけど、お客さんが来るときは、自分が入ってからお客さんを呼べ。いいかぁ。長幼の序が分かってる自衛隊なら、そんなことやるぞ。分かったぁ。はい。しっかりやれよぉ。
今の最後の言葉はオフレコです。いいですか、皆さん。いいですか?はい。
書いたらもう、その社は終わりだから。
koutarou666: b-mobile 980円SIMをNexus Sで使ってみた。テストしたら驚愕の事実が!
Q.下りのRTPが流れてこないが?
A.仕様で御座います。大量にパケットを使う方がいると他の方が迷惑しますので。
Q.いや、大量もなにもいきなり流れてこないんだけど。
A.未然に防いでおります。
Q.VoIPだけ選別している?
A.しておりません。下りのストリーム(RTP)全て遮断しています。
Q.そんなご無体な。
A.契約時の規約にも記載御座います。
Q.いや規約には制限する場合がございますと。
A.はい。今がその場合で御座います。
Q.ひょっとしてU300とかU400とかも全部遮断している?
A.b-mobile Fair以外は全て遮断しております。
下りのRTPはすべてブロックとは、潔すぎる。実に効果的にskypeとかYouTubeの利用を禁止しているわけだ。しかし、ちゃんと話の通るサポセン要員を用意している点は、評価できるのかもしれない。
複数のmutexが必要な状況を考えてみた。
// 排他的にアクセスするリソース class exclusive_resource { public : std::vector<int> v ; private : std::mutex m ; public : void lock() { m.lock() ; } void try_lock() { m.try_lock() ; } void unlock() { m.unlock() ; } } ; exclusive_resource res1, res2 ; void thread1() {// res1のみを操作 std::lock_guard< exclusive_resource > guard( res1 ) ; res1.v.push_back(0) ; } void thread2() {// res2のみを操作 std::lock_guard< exclusive_resource > guard( res2 ) ; res2.v.push_back(0) ; } void thread3() {// res1, res2両方を操作 std::lock( res1, res2 ) ; // デッドロックを回避するためstd::lockを使用すること // res1, res2両方を操作、実際には途中のreturnや例外に気をつけること res1.unlock() ; res2.unlock() ; } void thread4() {// thread3と同じく、res1, res2の両方を操作、thread3とは異なる処理 std::lock( res1, res2 ) ; // デッドロックを回避するためstd::lockを使用すること // res1, res2両方を操作、実際には途中のreturnや例外に気をつけること res1.unlock() ; res2.unlock() ; }
今、異なるスレッド間で操作したいオブジェクトが複数あるとする。しかし、常に全オブジェクトを操作する必要はないものとする。とすれば、この複数のオブジェクトを、単一のmutexで排他的にアクセスするのは、非効率的である。したがって、アクセスしたい単位ごとに、別々のmutexを用意するのは当然である。
しかしまた、ある状況では、複数の単位に、同時にアクセスしたい場合もあるとする。この場合、複数のmutexをlockしなければならない。しかし、普通に一つづつlockしたのでは、デッドロックに陥る可能性がある。このため、デッドロックを避けるように気をつけつつロックしなければならない。
std::lockは、lock(), try_lock(), unlock()を組み合わせた一連の呼び出しにより、デッドロックに陥らない方法で、すべてのLockable要求を満たす型のオブジェクトをロックしてくれる。
まとめとしては、複数のmutexを同時にlockする際には、デッドロックを避けるために、std::lockを使うべきである。