今日は、素晴らしく風情のある雪が降った。もっとも、北のほうに行くと、風情どころではなく迷惑な雪になってしまっているのだろう。
ともかく、今年も最後の日になってしまった。年越しそばをつくる為に、午後二時頃、いつも麺を安く売っている、とある店に買いに行ったところ、なんと売り切れであった。去年は、夕方に行ってもまだ残っていたのだが、今年はどうしたことだろう。仕方がないので、唯一残っていた、にしん蕎麦セットを、330円で買ってきた。麺と、にしんと、だしと、刻みネギが入っているので、それなりに便利だ。
甘酒を作るために、酒粕も買ってきた。
また、今年もうまい餅が手に入った。今年も、近所の餅屋でバイトをしたのだ。その代償は疲労と筋肉痛なのだが。何しろ、今年はずっとPCの前に座ってC++の規格書をにらみ暮らしていたので、運動不足だったのだ。
とりあえず、これで新年を迎える準備はできた。来年はC++の参考書を完成させなければ。
ある顧客が、以下のような不思議な質問をしてきた。
あるコンピューターから別のコンピューターに、ネットワーク越しにテキストファイルをコピーしたんだけどさ、コピーが終わってネットワークディレクトリーをみてみたら、まあ、たしかに同じ名前のファイルはあるんだけどさ、タイムスタンプがまるで違っているわけよ。不思議に思ってファイルを開いてみると、コピーしたファイルとは違うんだ。何故か、昨日のファイルなんだな、これが。今日の変更が含まれていないんだよ。俺はまだ、画面上にコピー元とコピー先のフォルダを開いてるし、もちろん、コピーしたファイルは、ちゃんと変更したものであって、バックアップディレクトリのヤツじゃない。
も一度やってみたんだけどさ、やっぱ古いファイルがコピーされる。よく分からんけど、ドラッグ＆ドロップを使ったら、問題はない。Ctrl+CとCtrl+Vを使った時だけ問題が起こる。何とかしてくれ。
これは実に訳の分からない問題だ。ひとつの可能性としては、顧客は間違って以前のバージョンのフォルダー（訳注：Volume Shadow Copyによるもの）からコピーしているのかもしれない。さらに別の仮説を立てる前に、顧客が追加情報を送ってきた。
何か問題を絞り込めた気がする。俺のインストールしてるクリップボードツールとなにか関係があるんだ。ツール使ってなければ、問題はないみたい。なんでツールを使ってたら、エクスプローラーはがタイムマシーンみたいな事をしてくれるんだ？ この古いファイルは、パソコンの中にないんだけど、エクスプローラーはどっから取ってきてんだ？
他のMS社員は、I/Oトレースログを取るなどして、問題を調査した。興味深いことに、I/Oトレースでは、エクスプローラーはコピー元とコピー先のファイルを開いて、コピー先に対してWriteFile呼び出しを多数発行しているのに対し、コピー元に対して、ReadFileを一切呼び出していないのであった。「以前のバージョン」も確認してみたが、「以前のバージョン」のファイルは存在しなかった。まるで、無からファイル内容を生成しているようであった。
他のMS社員が次第に調査を諦める中、突然、僕の頭は震え、トランス状態に陥った。僕のエスパー能力が、勝手に喉から声を発した。それは一瞬の出来事で、僕は眼を閉じて、すぐさま現実世界に戻ってきた。さて、僕はぶっきらぼうに、以下のようにタイプした。未だに返事を覚えているのだ。
私のエスパー能力によると、このクリップボードプログラムは、クリップボードの中身を仮想化している。つまり、クリップボードの中身を勝手に書き換えている。そして、ファイルに対するクリップボードのペースト操作に対し、元の中身に差し戻そうとして、失敗している。
クリップボード拡張ユーティリティを調べると、古いクリップボードの中身を記録する機能を提供している。MS Officeクリップボードに似た機能だ。I/O操作の中に、最終アクセス日時へのクエリーが含まれていた。
問題はこれだ。
Windows Vistaからは、最終アクセス日時はデフォルトでアップデートされなくなった。どうやらプログラムは、ファイルがアクセスされていないという情報から、ファイルが更新されていないと判断し、ファイルの中身を、内部のキャッシュから作り出しているのだ。この問題を手っ取り早く解決するには、最終アクセス日時のかわりに、最終更新日時を使うとよい。
やれやれ、私のエスパー能力が正しいということを、またもや証明してしまった。ところで、エスパー能力が正しいということは、代償であるということに気がついた。以前より、さらに大勢の人々が、不思議な問題をデバッグしてくれと頼み込んでくるようになったのだ。
ちなみに、最終アクセス日時がデフォルトでアップデートされなくなった理由は、NTFSのパフォーマンス向上のためである。そもそも、最終アクセス日時の精度は、一時間らしい。
そもそも、出版業界が電子書籍を真面目に提供していれば、今頃あんなサービスが出てくるわけがない。何も難しいことはいっていないのである。連番の画像ファイル集で十分だ。いまだにそのような媒体の電子書籍を提供できていないから、あの手のサービスが現れてしまうのだ。
そもそも、電子書籍という名称からしておかしい。E-Mail（電子手紙）は、単にメール（手紙）と呼ばれるようになった。電子書籍も、近いうちに、単に本と呼ばれるようになるだろう。もっとも、いまだにまともな電子書籍がない日本では、もうしばらくかかるだろうが。
C++0x Memory Model 第0回 - メモリモデルとは何か
C++0x Memory Model 第1回 - 1.9 Program execution
だいたい2300年ぐらい前に、ユークリッドという原理主義者が、原論という本を書いた。原論では、実に当たり前で、わざわざ言うまでもないことを説明している。例えば、「点とは大きさのない位置のことである」とか、「線とは幅のない長さのことである」などといったどうでもいい定義や、「任意の点から任意の点に、直線を引くことができる」などといった当たり前すぎる公理の類である。原論が日本に入ってきたのは、1730年代のことであったが、このような当然の事柄を延々と羅列しただけの本を見た当時の日本の和算学者は、一笑して無視したという。
しかし、このような定義と公理の羅列は、やはり重要なのだ。しかし、それを真面目にやると、プログラミングの参考書ではなくなってしまう。一般のプログラマが参考書に求めることは、このような原理主義的な定義の列挙ではなく、スレッドや同期処理ライブラリの使い方だろう。
アクセス宣言という項目を独立して立てて、解説をすべきだろうか。
アクセス宣言は、batavia会議の結果、削除された。deprecatedではない。削除されたのだ。したがって、アクセス宣言という用語自体が、もはやC++には相応しくない。
アクセス宣言が提供していた機能は、using宣言で行える。たとえば、以下のようなクラスがあるとして、
class Base
{
int value ;
public :
int get() const { return value ; }
void set( int value ) { this->value = value ; }
} ;
このBaseクラスからprivateで派生したいとする。ただし、Base::getだけはpublicで提供したい。その場合に、using宣言を使って、以下のように書くことができる。
class Derived : private Base
{
public :
using Base::get ;
} ;
これにより、Base::valueやBase::setをprivateにしながら、Base::getだけをpublicにすることができる。
現実に必要になる例としては、operator newやoperator deleteのオーバーロードをしている基本クラスからprivate派生したクラスを、クラス外からnewさせたい場合などが当てはまる。
また、オーバーロード解決の候補関数にしたい場合も考えられる。
struct Base
{
void f( int ) { }
} ;
struct Derived : Base
{
void f( double ) { }
} ;
int main()
{
Derived d ;
d.f( 0 ) ; // call Derived::f(double)
}
クラスメンバーの名前探索では、派生クラスのメンバーに、目的の名前が見つかった場合は、その時点で名前探索を打ち切る。つまり、基本クラスのメンバー名が見つかることはない。そのため、Base::fが呼ばれることはない。これも、using宣言を使って解決できる。
問題は、この機能は、一般にあまり知られているとは言いがたいし、おそらく現実のプログラミングでは、知らなくても全く問題ないだろう。using宣言で基本クラスのメンバー名を派生クラスのスコープの持ってくるというのは、まず必要にならないからだ。
これを、わざわざ独立して解説すべきなのか。
さて、今年も残りわずかとなった。そこで、今年も鬼を笑わせてみようと思う。
まず、PCの未来を予想してみる。
CPUの性能は、なにかすごい技術革新がない限り、あまり期待できないだろう。たしかに、より多くのコアやGPU内蔵といった未来はある。しかし、CPU自体のパフォーマンスの向上は、近年、実にわずかである。
そもそも、CPUのパフォーマンスを、最大限に使う必要がある状況も、今ではほとんど存在しない。ブラウザはそれほど重くはない（ただしIEとFirefoxをのぞく）。PCゲームのパフォーマンスは、ほとんどGPUに依存している。もはや、CPUは、十分に早いのだ。現代では、CPUの実行時間を100%必要とする処理は、動画のエンコードぐらいなものであろう。
GPUは、今後もしばらく、性能向上が続く。ただし、GPUの新機能を使ったPCゲームは、次世代コンソールが登場するまで待たねばならない。これは、後述する。
SSDの未来。SSDは、容量を増やす必要がある。まだ、SSDの容量は十分ではない。
ソフトウェアの未来。我々は何としても、Windows XPとIEの害悪から解放されねばならない。Windows XPは、もはや使われるべきではないし、IEはブラウザとは到底認め難い。32bitコードも、いずれ何とかしなければならないが、これは、もう10年ぐらいは、どうにもならないだろう。
PCゲームの未来。ここでいうPCゲームとは、MS Windows上で動くゲームのことだ。PCゲームの未来は、あまり明るくない。
そもそも、PCゲームの人口というのは、もともと、そう多くはないのだ。今では、コンソール向けにゲームを開発するついでに、PC版も提供するといった感じになっている。マルチプラットフォームの何が問題かというと、ゲームの設計自体が、コンソールを前提としたものになってしまうことだ。
特に、現行のPCゲームのUIや操作性は、まったくもって洗練されていない。では、コントローラーを使えばいいかというと、そういうわけでもない。大抵の3Dゲームは、コントローラーを入力装置として遊ぶには、極めて苦痛である。私には、3D FPSゲームをコントローラーでプレイする人間の親指の精度が理解出来ない。
ゲームがコンソールに合わせられるということは、GPUの新機能が宝の持ち腐れになってしまうことをも意味する。たとえば、Geometry ShaderとかTessellationなどといった機能は、いまだにあまり活用されていない。PCゲームの市場の規模を考えると、わざわざPC専用に新機能を実装するほどのコストに見合った利益が得られないからであろう。
総じて、PCゲームの未来は暗い。
毎年、クリスマスになると、大抵の店でかかっている歌がある。あまりにも多用されているので、毎年、なんという歌なのか気になっていた。聞くたびに、調べようとは思うのだが、帰宅する頃には、調べるということ自体を、すっかり忘れてしまうのだ。
今日、たまたま覚えていたため、早速調べた。問題の曲は、Last Chrismasであった。この曲は、大勢の歌手によってカバーされている。
日本の店でよく流れている、つぶやくような聞き取りにくいアレは、誰のカバーなのだろう。
出だしは、いつもほとんど聞き取れずにいるのだが、以下の通り。
Last Christmas I gave you my heart
But the very next day you gave it away
This year to save me from tears
I'll give it to someone special
なんと、失恋の歌だったとは気がつかなかった。
Don't do this at home. I am professional.
絶対にマネをしてはいけません。
昨晩、これと同じことがC++で出来るかどうか質問を受けた。5という数字が与えられたときに、0,1,2,2,3,3,3,4,4,4,4,5,5,5,5,5という数列をコンパイル時に生成できるかという問題である。
その時は、プリプロセッサー以外に、どうにもうまい実装方法が思いつかなかった。問題は、再帰を止める方法だ。しかし、今朝、改めて問題を考えると、頑張ればなんとかなるのではないかとも思った。
まず、プリプロセッサーによる実装を考えよう。これは、BOOST.Preprocessorを使えば、簡単に実装できる。簡単というのは、C++のプロにとって簡単という意味である。言うまでもなく、プリプロセッサーは邪道であり、中でもBoost.Preprocessorは禁断の秘術である。D&Eの第18章を暗唱できるようになるまで、プリプロセッサーを書いてはならない。今回は、メタプログラミングの可能性を示すために、あえて、この極悪非道の魔術を使うことにする。
#include <boost/preprocessor/enum.hpp>
#include <boost/preprocessor/enum_shifted.hpp>
#include <boost/preprocessor/arithmetic.hpp>
#define HITO_PRINT_PP( z, n, data ) data
#define HITO_DUP_HELPER_PP( z, n, data ) \
BOOST_PP_ENUM_ ## z( n, HITO_PRINT_PP, n )
#define HITO_DUP_PP( COUNT ) \
0, BOOST_PP_ENUM_SHIFTED( BOOST_PP_ADD(COUNT, 1), HITO_DUP_HELPER_PP, ~ )
int main()
{
constexpr int a[] = { HITO_DUP_PP(5) } ;
for( auto value : a )
{ std::cout << value << "," ; }
}
このメタプログラムは、コンマで区切られた目的の数列を生成してくれる。
問題は二つある。まず第一に、これはプリプロセッサーである。第二に、BOOST_PP_LIMIT_REPEATまでしか数列を生成できない。BOOST_PP_LIMIT_REPEATの値は、現在のところ、256である。
では、これを本当のC++0xの言語機能で実装しよう。まず、前提知識として、配列を返す関数を書くことはできない。これは、C++の制限である。そこで、配列をメンバーに持つリテラル型を使うことにする。std::arrayは、ちょうどこの条件をみたしている。
どうやって配列を初期化するのか。それには、Variadic Templatesを用いる。以下のようにpack expansionをしてやればいいのだ。
template < typename ... Types >
std::array< int, sizeof...(Types) > f( Types ... args )
{
return std::array< int, sizeof...(Types) >{ args... } ;
}
つまり、この関数をconstexprにして、再帰で実引数を加えていき、目的の数列を生成した上で、std::arrayを返せばいいのだ。問題は、再帰を止める条件である。C++0xでは、関数も特殊化できるようになった。しかし、部分的特殊化はできない。そのため、クラスを使うしかない。
また、std::arrayのサイズは、最初のインスタンス化の際に決定して置かなければならない。つまり、数列の数の個数を、あらかじめ与えてやらなければならない。幸いにして、この非常に難しい数学上の難問は、300年以上前に、当時小学生のガウス君が、宿題を真面目にやるのがめんどくさかったという理由によって、見事に解決してくれている。
// summation from n=0 to i of n
constexpr std::size_t summation( std::size_t i )
{
return 1 + i * (i + 1) / 2 ;
}
// for compile time selection
template < bool, bool >
struct selector ;
// list construction completed.
template < bool b >
struct selector< true, b >
{
template < std::size_t COUNT , int I, int J, typename ... Types >
constexpr static std::array<int, summation( COUNT )> invoke( Types ... args )
{
return std::array<int, summation( COUNT )>{ args... } ;
}
} ;
// add number I, I times.
template < >
struct selector< false, true >
{
template < std::size_t COUNT , int I, int J, typename ... Types >
constexpr static std::array< int, summation( COUNT ) > invoke( Types ... args )
{
return selector< (COUNT < I), I != J + 1 >:: template invoke< COUNT, I, J + 1 >( args..., I ) ;
}
} ;
// carry over to the next number.
template < >
struct selector< false, false >
{
template < std::size_t COUNT , int I, int J, typename ... Types >
constexpr static std::array< int, summation( COUNT ) > invoke( Types ... args )
{
return selector< (COUNT < I + 1), true >:: template invoke< COUNT, I + 1, 0 >( args... ) ;
}
} ;
// User Interface
template < std::size_t COUNT >
constexpr std::array< int, summation( COUNT ) > dup( void )
{
return selector< (COUNT < 1), true >:: template invoke< COUNT, 1, 0 >( 0 ) ;
}
int main()
{
constexpr auto a = dup<5>() ;
for( auto value : a )
{ std::cout << value << "," ; }
}
selectorクラスを三つに特殊化し、それぞれで別のことをしているのには、理由がある。というのも、単にひとつの関数に条件演算子を使って書いたのでは、インスタンス化を止めることができないからである。つまり、どの処理をするか判定した後まで、インスタンス化を遅らせる必要があるのだ。そのために特殊化が必要になる。
さて、ここで非常に悲しい事実が判明した。このC++0xの機能をあますところなく使った美しいコードは、なんと、最新のgcc 4.6では、dup<18>までしかインスタンス化できないのである。片や、プリプロセッサーはHITO_DUP_PP(256)まで、問題なくコンパイルできるというのに。なんと、プリプロセッサーに負けてしまったのだ。
ちなみに、これは私の経験上、もっとも難しかったテンプレートメタプログラムである。このコードを書くのに二時間半も費やしてしまった。このコードのデバッグは、非常に困難であった。何しろこのコードで、再帰的インスタンス化を止められなければ、gccが一切のエラーメッセージを出さずにクラッシュしてしまうのだから。
追記：MPLを使ったところ、非常に分かりやすくなった。
#include <boost/mpl/if.hpp>
#include <boost/mpl/eval_if.hpp>
// summation from n=0 to i of n
constexpr std::size_t summation( std::size_t i )
{
return 1 + i * (i + 1) / 2 ;
}
// we've done it. return the result.
struct construct_initializer_list
{
typedef construct_initializer_list type ;
template < std::size_t COUNT , int I, int J, typename ... Types >
constexpr static std::array<int, summation( COUNT )> invoke( Types ... args )
{
return std::array<int, summation( COUNT )>{ args... } ;
}
} ;
struct carry_over ; // forward declaration
// add a initilizaer of number I, I times.
struct add_initializer
{
template < std::size_t COUNT , int I, int J, typename ... Types >
constexpr static std::array< int, summation( COUNT ) > invoke( Types ... args )
{
return boost::mpl::eval_if_c< ( COUNT < I ),
/* if true then*/ construct_initializer_list,
/* else */ boost::mpl::if_c< ( I != J + 1),
/* if true then*/ add_initializer,
/* else*/ carry_over > >::type:: template invoke< COUNT, I, J + 1>( args..., I ) ;
}
} ;
// carry over to the next number
struct carry_over
{
template < std::size_t COUNT , int I, int J, typename ... Types >
constexpr static std::array< int, summation( COUNT ) > invoke( Types ... args )
{
return boost::mpl::if_c< ( COUNT < I + 1 ),
/* if true then*/ construct_initializer_list,
/* else */ add_initializer >::type:: template invoke< COUNT, I + 1, 0 >( args... ) ;
}
} ;
// User Interface
template < std::size_t COUNT >
constexpr std::array< int, summation( COUNT ) > dup( void )
{
return boost::mpl::if_c< ( COUNT < 1 ),
/* if true then*/ construct_initializer_list,
/* else */ add_initializer >::type:: template invoke< COUNT, 1, 0 >( 0 ) ;
}
int main()
{
constexpr auto a = dup<5>() ;
for( auto value : a )
{ std::cout << value << "," ; }
}
Trailerで使われている音楽の歌詞の書き起こしが、ぼつぼつ出始めている。ただし、なぜか意見が別れている。
ひとつは、以下のような歌詞である。
For the King, For the King
For the fate of Skyrim.
For the Nine, for the Wulf
For the Godless One
And he'll do it for the Just
For the sole single star
For the King, For the King
For the Dawn will rise. Yah!
もうひとつは、以下のような歌詞である。
For the king, For the King
For the sake of Skyrim
For our life, for our Home
For Hrothgars blood
For the Nords, For the gods
For the sole single son
Dovakiin, our king, who'll dawn with fire!
私には、後者の方が正しいように聞こえる。前者は、そのように聞こえないばかりか、意味が通じない部分も多い。
追記：Dovakiinは、おそらくDragon Bornの意味であろう。Hrothgarは、Skyrimにある山の名前であり、Nordの祖先が生まれたとされている場所である。
Bethesda Blog » Blog Archive » The Bethesda Podcast Episode 6: Enter the Dragon
とくにゲーム内容には言及していない。ただし、来年の一月半ばあたりに、結構な量の情報が公開されるらしい。
ちなみに、BethesdaのTwitterのつぶやきによると、新エンジンらしい。Twitter / Nick Breckon: We can now confirm that th ...
ようやく、OblivionとFalloutで使われてきた糞古い環境からおさらばできるのか。こんどはまともな物理演算がなされているといいのだが。
とりあえず、メインテーマでも聞きながら待とう。
現時点でのChromeのDev版のバージョンは、10.0.612.1である。
ところが、どうもエラーがでてアップデート出来ない問題が、広く発生しているようだ。エラーメッセージは、Update server not available (error: 7)である。
これを解決するには、Chromeの再インストールをするしかない。もちろん、引き続きDev版を使いたい場合は、かつてしたように、設定しなければならない。
Google Chrome Releases: Dev Channel Update
"Update server not available" : Installation and update issues (Windows) - Google Chrome Help
CBC News - Edmonton - Thieves target Edmonton free store
エドモントン（訳注：カナダのアルバータ州）にある、ちょっと風変わりな店に、二人組の強盗が押し入ったことで、店長は、首をかしげている。
なぜ押し入る必要があるのか、と店長は言う。店にあるものはすべて、無料なのに。
84番街と118番通りの近くにある、このフリーストアは、今年、開いたばかりである。ここでは、2ドルを支払うことで、店に不要な物を引きとってもらうことができる。お客は、店にあるものを何でも、無料で手に入れることができる。
店の共同経営者であるBrandon Tysonは、木曜日の夜に店に来たところ、二人組の男が店内にいるのに気がついた。彼らは窓ガラスを蹴破り、店内にはガラス片が散乱していたのである。
「無料の店として、我々は誰かが強盗に押し入るなどということを想定していませんでした。というのも、次の日にやってきて、全部無料で持って帰ればいいのですから」とTysonは言う。「まあ、それでも、強盗というものは、いるんですね」
Tysonは二人組の強盗未遂を店の外まで追いかけ、捕まえた上で、警察を呼んだ。二人組は酒に酔っていたという。
Tysonは、この事件は実に奇妙だと言う。
「ここは無料の店なのです」と彼は言う。「ここにあるものは全部無料で持って帰ることができます。そうすることによって、これらの資源は、ゴミの埋立から免れるわけです」
「そういうわけで、ここに実際に誰かが押し入って、物を盗んでいくというのは、実におかしいのです。いいジョークのネタになりますな」
彼らが処罰されたかどうかは不明である。
今日は、奇跡的に素晴らしいパラパラのチャーハンが作れた。作り方を、忘れないように書いておこうと思う。
まともなHTML5マークアップを使っている。たしかに、HTML5 Validatorsに通すと、いくつかのエラーを吐くが、どれも実質は問題のないエラーばかりである。
私は、Flashを無効にしているが、ちゃんとvideo要素を使っているために、動画が表示される。素晴らしい。
あとは、TES 5: Skyrimが、Unicodeを使っていればいいのだが。
ソースを見てほしい。このような邪悪なHTMLがいまどき存在を許されるのだろうか。
なんという前衛芸術のようなdivだろうか。
さらに細かいことをいうと、HTML4.01としてもおかしい。
まず、HTMLだが、DOCTYPE指定がない。つまりこのサイトは、互換モードで表示されているということになる。
次に、目につくのは、body > center > tableである。いまどき、レイアウトをテーブルで組んでいるのだ。ああ虫酸が走る。もちろん、邪悪なfont要素も使っている。吐き気をもよおす邪悪とは、このようなことをいうのだろう。centerとfontは、HTML4.01ですら廃止予定の要素である。ここまでくれば、もう誰も驚かないだろう。width、 height、bgcolor、alignなどという属性は、当然のごとく使っている。まあ、些細な問題だろう。
また、文字コードは当然のごとくShift JISである。日本人であるからこそ、一刻も早くShift JISを捨て去らなければならないというのに。
ああ、日本の将来は暗い。
追記：今頃気がついたのだが、DOCTYPEすらない。すると、これは互換モードで解釈されるのであって、このような邪悪なHTMLでも問題はないということになる・・・いや、それをやっちゃ駄目だろう。
これもひどい。
中学生のコンピュータの問題 | Okumura's Blog
分からん。
金沢市長選：当選陣営がツイッターで選挙戦 指導を無視し - 毎日ｊｐ(毎日新聞)
たぶん、ネット利用が公職選挙法違反に当たるかどうかは、前例がないから誰も分からないんだろう。そんな法律に縛られて今まで選挙期間中はインターネット禁止などという時代錯誤のドブ板選挙をしていたのでは、日本の将来のために害悪である。
本来ならば、とっくの昔に公職選挙法は改正されているべきであるが、いまだに変わっていない。これは、現行の政治家が、特に変える必要はないと考えているためであろう。日本の将来のために害悪である。
もう、かれこれ一二年ぐらいは噂になっていたが、どうとうTrailerがでた。
動画によると、2011年11月11日に発売されるらしい。
かねてからの噂通り、時代はOblivionゲートが開いた後の世である。場所はCyrodiilの北に位置するSkyrim（Nordの故郷）である。かなりの寒冷地であると予想される。一面雪景色なのだろうか。ちなみに、Skyrimがゲームの舞台になるのは、実に第一作のArena以来である。動画では、Dragon Bornと言っている。つまり、Septimと同じく、新たなドラゴンの血を引く皇帝が誕生するということだろうか。
You should have acted.
They're already here.
The Elder Scrolls told of their return.
Their defeat was merely delay.
Til the time after Oblivion opened.
When the sons of Skyrim would spill their own blood.
But no-one wanted to believe.
Believe they even existed.
And when the truth finally dawns:
It dawns in fire.
But...
There's one they fear.
In their tongue, he's Novak'leen Dragon Born!
ちなみに、歴史を振り返ってみると、これまでのTESは、すべて、Dragon BornであるEmperor Uriel Septim VIIの御宇の話であった。最後の血筋であるMartin Septimが薨去したことにより（戴冠したかどうか微妙なので、崩御は正しくないだろう）、TES5の世界では、Dragon Bornがいないということになる。
ちなみに、Oblivionより後日談を書いた小説によれば、TES4: Oblivion以降のFourth Eraでは、Tamrielの統一が崩れ、Black Marsh（Aragonianの故郷）とElsweyr（Khajiitの故郷）が独立した。MorrowindはAragonianによって征服された。
Military Bans Disks, Threatens Courts-Martial to Stop New Leaks | Danger Room | Wired.com
しかし問題は、対象となるコンピューターはたいてい、ネットワークにつながっていないか、つながっていたとしても、相当遅い。そのため、外部メディアでデータを持ってくるのだが、それができなくなった。曰く、「家を建てろと言っておきながら、ハンマーを禁止するようなものだ」
そもそも、そのようなコンピューターのソフトウェアを、どうやって更新するつもりなのだろうか。厳重に管理されるべきコンピューターが、既知の脆弱性に対するパッチを適用していない状態になるのだろうか。それでは、リークしてくれと言っているようなものではないか。
Social Networking: The Past
Social Networking: The Present
Social Networking: The Future
これは興味深い。気になる意見をまとめてみた。
まず過去。ソーシャルネットワーキングというものは、何も今に始まったものではないということ。大昔から似たようなサービスはあった。
面白いのは、かつて市場をほぼ独占したサービスなのに、今はすっかり衰えているものがあるということだ。例えばAOLだ。AOLは、他社を参入させず、独自のネットワークをつくろうとした。そこでは、AOLが管理し、AOLが善悪を決めるのだ。かつて、AOLはインターネットにも参入した。かつて、AOLが史上を独占してしまうのではないかと恐れられた。今から考えると、笑い話である。そのような独裁は、成功しなかった。WWWがやってきて、HTMLでWebサイトが記述できるようになると、AOLの独裁は終わった。
WWWではYahooが突出した。Yahooの勢いは、誰に求められないように思われた。今から考えれば、笑い話である。
さて、現在。現在主流のソーシャルネットワーキングサービスを、スパムベースであるとしている。つまり、自分が何をしているかという情報を、友人全員に送りつけるのである。
ブログが登場した。しかし、ブログはあまり残らなかった。というのも、大衆は、ブログを書きたいとは思わなかったからだ。大衆は画像や動画をアップロードして、それについて議論したかったのである。皆が皆、長々とブログを書くわけではない。
そこに、Myspaceが登場した。アイディアはよかったものの、Myspaceは、画像や動画をうまく扱えなかった。そこでユーザーは、、画像や動画を、専用のサイトにアップロードし、Myspaceからは、単にリンクを貼るという使い方をした。
FoxがMyspaceを買収した。FoxのRupert Murdochは、頭が良さそうに見えた。実際はそうでもなかった。Myspaceは、Facebookに負けたのだ。
なぜMyspaceはFacebookに負けたのか。それは、他社を締めだしたからである。一方、FacebookはAPIを提供して、開発を推奨した。シリコンバレー30年のビジネス上の歴史を振り返るに、「オープンにして、あとで課税しろ」というのが、成功する秘訣のように思われる。
Foxはまた明らかに成功しなさそうなことを始めた。御年75歳のRupert Murdochには、イノベーションというものが分かっていないらしい。22歳のMark Zuckerbergに勝てるわけがない。
最後に、ソーシャルネットワーキングは、リアルタイムになった。Twitterである。
未来はどうなるのか。まず、Facebookの独占などということはありえない。かつてはMicrosoftが、Yahooが、Googleが、それぞれ市場を独占してしまうのではないかと恐れられた。もちろん、今となっては笑い話でしかない。
ソーシャルネットワーキングは、オープンになるべきだと言っている。どこか一社にロックインされるのは、誰も望んでいないし、ロックインしようとしても無駄だろうと。
Facebook connectとかいって、サイトにFacebook上の情報を得る許可を出すボタンがあるが、あの情報の使い方も、もう少し研究する必要がある。今は、単にユーザーの嗜好に合わせた広告を出すぐらいにしか使われていない。他の使い方もあるはずだ。
プライバシーの問題も少しだけ触れている。しかし、それほど問題にはならないだろうと言っている。
また、プライベートとビジネスを分けるべきだとも言っている。自分の妻子の写真だとか、学生時代のマヌケな写真だとかを、ビジネス上の相手と共有してもしょうがない。今、Facebookは、プライベートとビジネスを分けていない。そこで、アカウントを複数使い分けているユーザーが結構いる。これを分けるべきだ。
librahack事件はちっとも終わってない。岡崎市立図書館は被害届を取り下げるべき。MDISはそれにとことんつきあうべき。
無実の罪で逮捕、拘留されるからである。
ISO/IEC JTC1/SC22/WG21 - Papers 2010
最新ドラフトは、N3225になった。ドラフトに対する変更点は、N3226: Editor’s Reportに列挙されている。
今回は、名前通りの単純な変更や、単なる文面の誤りや不明確な点の修正などが多い。そのため、特に気になるペーパーだけを取り上げる。
N3189: Observers for the three handler functions
get_new_handler, get_unexpected, get_terminateを追加する提案。
N3197: Lockable Requirements for C++0x
名前通り。
N3198: Deprecating unary/binary_function (Rev 1)
これまた名前通り。当然deprecatedにするべきである。
重いコンダラ試練の道を～♪ 行くには行くが、下位互換性は守るのが標準化委員会のド根性。
暗黙のムーブを、どのような場合に生成すべきか。また、暗黙のムーブはどのように実装されるべきかという問題について論じている。
暗黙のムーブは、ユーザー定義のコピーやムーブ、デストラクターに加えて、コンストラクターが存在する場合も、生成を抑制されるべきではないかという話がひとつ。
もうひとつ、暗黙のムーブの実装をどのように定義すればよいか。問題となるのは、ムーブした後のオブジェクトのことだ。ライブラリ実装者としては、ムーブされた後のオブジェクトは、代入などをすれば使える状態であってほしい。
Object x ; Object y = std::move( x ) ; // xはムーブされた後の状態になる Object z ; x = z ; // xが使用可能の状態になる。
しかし、一体この状態をどうやって作り出せばいいのか。クラスの実装次第では、ムーブ後のオブジェクトに対する代入ができない可能性もある。では、ムーブ後の状態を、暗黙のムーブという一般的な実装から作り出すのは、どうすればいいのか。
デフォルトコンストラクターを使うというのはどうだろう。つまり、暗黙のムーブは、各メンバーごとにムーブした後のオブジェクトに対して、デフォルトコンストラクターを呼び出すのだ。これによって、妥当な状態にすることができる。もし、別の実装がしたければ、ユーザーは自前のムーブを実装すべきである。
しかし、勝手にデフォルトコンストラクターが呼び出されるというのは、やはり色々と問題がある。さて、どうするか。
個人的には、現行FCDのままの方が、一番混乱が少なくていいと思う。
N3202: To which extent can noexcept be deduced?
noexceptには、ひとつ問題がある。わざわざ、すべての関数にnoexceptを指定するのが、甚だ面倒だということだ。それゆえ、インライン関数は、noexceptを暗黙のうちに推定してもいいのではないだろうか。つまり、インライン関数の関数本体に、例外を投げるかもしれない式が含まれていない場合、そのインライン関数は、noexcept(true)と暗黙のうちに指定されるべきではないか。という提案。
N3203: Tightening the conditions for generating implicit moves
ユーザー定義のコピー、ムーブ、デストラクターがある場合、暗黙のムーブを生成しない。ユーザー定義のコピー、ムーブ、デストラクターがある場合、暗黙のコピーを生成する機能を、deprecatedにする。
ユーザー定義のコピーがあるのに暗黙のコピーを生成する場合というのは、すこし妙に聞こえるかもしれない。これは、ユーザー定義のコピー代入演算子があって、コピーコンストラクターが定義されていない場合、またはその逆である。
struct X
{
// ユーザー定義のコピー代入演算子
X & operator = ( X const & ) { return *this ; }
// 暗黙のコピーコンストラクターが生成される
} ;
このような挙動は、C++0xではdeprecatedであるので、まともなC++プログラマーならば、この挙動に頼ったコードを書いてはいけない。
N3204: Deducing "noexcept" for destructors
デストラクターに明示的にnoexceptが指定されていない場合、暗黙のデストラクターと同じ方法でnoexceptが推定される。結果的に、明示的にnoexcept(false)を指定しない限り、デストラクターはnoexcept(true)となる。
n3205 Delete operators default to noexcept
名前通り。
N3206: Override control: Eliminating Attributes
いままでattributeの機能であった、base_check, final, override, hidingを、contextual keywordにする。base_checkはexplicitに、hidingはnewになる。
struct Base
{
int x ;
virtual void f() ;
} ;
struct Derived explicit final : Base
{
int x new ;
void f() override ;
} ;
finalとoverrideは、contextual keywordなので、識別子としても利用出来る。
ただし、会議後、この文法にも新たな問題が見つかっており、おそらく、また文法は変わるだろうと思われる。ひょっとすると、hidingがなくなってしまうかもしれない。
関数の本体から、noexceptを推定させるための例外指定を追加する提案。以下のようになる。
void f() {} // 例外を投げるかもしれない関数
void g() noexcept { } // 例外を投げないと保証されている関数
// noexcept(false)
void h() noexcept(auto)
{
f() ; // 例外を投げる可能性のある式
}
// noexcept(true)
void i() noexcept(auto)
{
g() ; // 例外を投げる可能性のない式
}
N3209: Progress guarantees for C++0x (revised)
残念ながら、私はこのペーパーの内容を理解していない。スレッド間の保証は難しい。
N3210: New wording for arithmetic on ratios
文面の書き換え
N3214: US 19: Ambiguous use of "use" (version 2)
ODRのuseと、一般動詞としてのuseが混用されていてややこしいというNBコメントに対し、ODRに関するuseを、odr-useに置き換える変更。
N3216: Removing Implicit Move Constructors and Move Assignment Operators
今回のドラフトでは採用されなかったが、もし、暗黙のムーブを取り除くとした場合の、規格の文面の変更案。
N3217: Wording for brace-initializers as default arguments
{}をデフォルト実引数として使えるようにするための文面。
N3218: Core Issue 1125: Unclear definition of "potential constant expression" (DE 8, GB 26)
定数式の文面の不明確な点を解消。
ちょっと面白かったので紹介する。
C++ Standard Core Language Defect Reports: issue 1122
The return type of the sizeof operator is defined as being of type std::size_t, defined in library clause 18.2 [support.types]. This, in turn, says that size_t is defined in the C standard, which in turn says that size_t is defined as the type of the result of the sizeof operator!
sizeof演算子の戻り値の型は、std::size_t型であるとされている。std::size_tは、ライブラリ18.2[support.types]で定義されている。そこでは、size_tはC規格で定義されているとしている。C規格では、size_tはsizeof演算子の結果の型であると定義されている！
なんというたらい回し。
以下は、Youtubeの動画をHTML5のvideo要素を使って埋め込むためのコードを生成するbookmarkletである。これは、http://www.youtube.com/watch?v=で始まるURL上で使うことを想定している。マイチャンネル上で使うことは想定していない。
javascript:(function(){ var url = document.URL ; var id = url.slice( url.search("v=") + 2 ) ; id = id.slice(0, id.search(/(&)|($)/) ) ; var str = '<div><iframe class="youtube-player" type="text/html" width="640" height="505" src="http://www.youtube.com/embed/' + id + '" frameborder="0"></iframe><br /><a href="http://www.youtube.com/watch?v=' + id + '">' + document.title + '</a></div>' ; prompt("", str ) ; })() ;
これは、まだ実験段階のYoutubeの埋め込みコードを使っている。詳しくは、YouTube API Blog: A New Way To Embed YouTube Videosを参照。また、YouTubeにHTML5のvideo要素を使わせるためには、この設定ページで、HTML5を有効にしなければならない。
Webの正しい進化のためには、Flashを撲滅すべきである。当然だ。しかし、私はいまだにFlash Playerを有効にしている。これはよろしくない。たしかに、Flashというコンテンツをみるためには、Flash Playerが必要だ。しかし、真に見る価値のあるFlashというのは、実はそれほど多くない。ゆえに、通常はFlash Playerは無効にすべきであるという結論に至った。
さて、現在のWebで、どうしてもFlashが必要なコンテンツとはなにか。動画である。数ある動画サイトでも、最も有名なサービスはYouTubeである。YouTubeには、話題の動画が数多く上げられている。単なる娯楽であれば、見ないという選択もできるが、そうはいかない。最新の技術や製品の説明が、動画を使って行われていることも、しばしばある。
そもそも、最新の研究結果によれば、インターネットはぬこによって構成されているのである。
しかし、既存の埋め込みのYoutube動画は、いずれもflashを直接参照している。これでは動画を見ることができない。HTML5で埋め込む方法は、実験段階とはいえ、公式に公開されている。そこで、このBookmarkletをつくることにした。
YouTubeを埋め込む者は、せめて、YouTubeの該当URLへの、直接のリンクを貼るべきである。Flash Playerを使っていない人間は、たとえ動画がWebMでエンコードされていて、ブラウザがHTML5のvideo要素でWebM再生をサポートしていたとしても、YouTubeを再生できなくなってしまう。また、リンクがないので、ソースを読まない限り、該当ページに飛ぶこともできない。また、その際、マイチャンネルにリンクをはってはいけない。なぜならば、マイチャンネル上では、Flashが強制されてしまうからだ。
追記：2011/01/26、バグ修正。
良品計画がイスラエルへの出店を取りやめるらしい。もし、馬鹿げたボイコットに影響されたのだとしたら、それこそ馬鹿げた事だ。
そもそも、本当にイスラエルをボイコットしたら、PCは使えない。
イスラエルをボイコットしたい君、もしかして、手持ちのPCは、Intel製のCPUを使っているのではないだろうか。もしそうならば、今すぐにたたき壊すべきだ。IntelのCPUはイスラエル人が開発している。
イスラエルをボイコットしたい君、もしかして、手持ちのPCは、AMD製のCPUを使っているのではないだろうか。もしそうならば、今すぐにたたき壊すべきだ。AMDのCPUはイスラエル人が開発している。
彼らは商人である。国ではない。商人は国に対してどうしようもできないのだ。国は国でなければ相手ができない。もしイスラエルを変えたいのならば、真にすべきことは、自国の政府をして公式にイスラエルを批難させることである。商人にものをいっても、国は変わらない。
まあ、イスラエルはどうしようもない国であることは確かだ。第一、奴ら人種的にユダヤ人というわけでもないだろうに、理解出来ないことだ。
この視覚化はすごい。
追記：はてブで、「横軸が対数だから実はアフリカはぶっちぎりで取り残されてるのでは」という意見があるようだ。
追記2：ついでにいうと、基軸通貨の価値も、当時とは変わっているのではないかと思う。
Librahackメモ | Librahack ： 容疑者から見た岡崎図書館事件
私選弁護士を雇えない限り日本でプログラミングしてはならない。いや、それをするぐらいなら、海外で開発すべきだ。悲しいことだ。
もう、SNS需要は一巡している。つまり、SNSに興味を示すユーザーは、すでにどこかのSNSサービスを使っているであろう。つまり、SNSは、もうこれ以上ユーザー数を増やすことはできないのだ。
これはSNSにとって問題である。従来、SNSの収入は広告に頼っていた。今では、SNS内のゲームによる収入もかなりあるが、やはり、まだ広告の力は大きい。手っ取り早く広告収入を上げるためには、ユーザー数は多ければ多いほどいい。また、新規ユーザーを常に獲得しなければならない。というのも、新規に入ってきたユーザーは、すでにいる興味が覚めたユーザーより、より多く操作をするので、広告収入もより得られるであろう。
広告収入を上げるには、Webサイトで操作している時間を増やすのが、非常に効果的である。
しかし、SNS需要はすでに一巡している。得られないものを得るためには、新規の何かが必要である。従来、ほとんどのSNSというのは、招待制であった。つまり、一見さんお断り、既存ユーザーから招待されない限り参加できないというものであった。これは、ユーザーの急激な増加を防ぐというよりは、単に話題取りのための仕様であった。SNS需要が一巡した今、そのような宣伝は取り除かれなければならない。
今回、mixiは、アカウントに紐付けられている、メールアドレスによる検索を可能にした。これは、一時的な広告収入を得る手段として、素晴らしいといえる。私は正気である。広告収入を上げる手段として、素晴らしいのだ。
なぜ素晴らしいのか。というのも、従来、アカウント用のメールアドレスは公開されていなかった。そのため、ユーザーは、そのことを前提にした活動をしていた。これを急に変更するとどうなるのか。メールアドレスに対して、素晴らしい個人情報が得られるのだ。あらゆる利用が考えられる。検索しない手はない。すなわち、操作が増える。操作が増えると、広告収入が上がる。
もちろん、これはユーザー側からすれば、個人情報の切り売りである。とんでもないことである。だから、私のようなパワーユーザー（笑）は、この手のサービスに対して、実際に使っているメアドとは別の、捨てアドを設定しておくのだ。しかし、捨てアドとはいえ、複数のサイトで使い回しているアドレスである。これが公開され、紐付けられてしまうのは、やはり困る。
まあ、私などは、mixiは単に登録しているだけである。日記は、このブログのRSSを流し込んでいるだけだ。しかし、そろそろ手を切るべき時期だろう。足あとによると、私のmixiアカウントを定期的に見ているのは、三人ぐらい。このブログ記事が、mixi日記に流し込まれて、登録してある友人が見るまでの数日、アカウントを保持して、それから消すことにしよう。
ニコニコ動画に引き続き、mixiも終わったか。日本のインターネット史を編纂する際には、必ず言及されるであろうサービスだ。栄枯衰勢というか、諸行無常というか。
次に消えるサービスはなにか。オンラインブックマークは、すでに下火である。はてなブックマークも、Diggも、かつての勢いはない。Micro bloggingは、死ぬべきである。ただ、これは、ブログに長文を書けない者、リテラシーのない者への、文盲用サービスとして、しばらく生き残るだろう。
私がまだしばらく使うであろうと思われるWebサービスは、メールとフィードリーダーである。私の場合、GMailとGoogle Readerを使っている。
まだ、Eメールに置き換わるプロトコルは発明されていない。たとえばこのmixiの問題にしたって、いまだにメールが重要だからこそ、問題なのだ。これが、単にログインIDで検索できる程度なら、それほど問題にはならないだろう。ログインIDは、それほど重要ではないからである。
Webの多くの更新情報は、単純なテキストで表現できるので、フィードは便利である。わざわざWebサイトを巡回しなくてもよい。そう、まだフィードリーダーが一般的ではなかった頃、かつては巡回と称し、お気に入りのサイトの更新を、手動で確認する原始的な更新チェックが行われていたのだ。いまだに少し力を持っている、ニュースサイト（フィードすら提供していない日々更新されるリンク集）なるものも、あの時代の名残であると言える。
メールとフィードは、いつ廃れるだろうか。その時、一体我々は何を替わりに使っているのであろうか。
Chrome OSの対抗馬を意識したOS。設定変更すら、ほとんどをWindows上から行う。このOSでは、ブラウザぐらいしか使うことはできない。その代わりに、数秒で起動。
ところで、このことは日経新聞で知ったのだが、その日本語が不思議すぎて笑える。
高速で起動できるＯＳ（基本ソフト）の無料ダウンロード（取り込み）を始めたと発表した。
基本ソフト、取り込み・・・んん？ 余計に分からなくなっている。しかも最悪なことは、当のSplashtop OSのウェブサイトへのリンクが貼られていない。上記のサイトは、ググッて見つける必要があった。そりゃ、基本ソフトとか取り込みとかいう、不思議な言葉を使うわけだ。事によると、連中はまだ、社内では漢語を使っているのではあるまいか。