「閏年」を含む日記

■西暦4年から

元号バグを聞いて「日付をシリアル値で管理して出力後に変換テーブルを噛ませばいいんじゃないの？」って思ったんだ。

でも銀行だったら昔のデータもあろうから使えないって気付いたので、「じゃあもっと昔から起算すればいいのでは？」と思ったので作ってみた。

おぼえがき

• 干支は60年が1タームで短すぎることの補佐として元号が開発されたと聞いたので、元号を避けるのならば干支が本筋だろうと判断した
• でも60年という短さが問題なので、何巡目という組み合わせとした
• 何巡目をどこから起算するべきかというときに、Wikipediaに(1)古くは木星の動きに合わせてリセットしていたこと(2)西暦50年＝庚戌としてリセットを廃止したこと、という記載があったのでここから逆算して西暦4年を起算年とした
• シリアル値は全てグレゴリオ暦で連番を降ることにした。ユリウス暦のシリアル値への需要は低いと判断した。

Permalink | 記事への反応(2) | 17:13

ツイートシェア

■anond:20180328101443

はああじゃねえよ。

ローマ時代には一年はMarchから始まってFebruaryで終わったんだよ。

だからFebruaryだけ特別に短かったり閏年の調整に使われたりしてんだよ。

ちゃんと話の辻褄が合うだろが。

Permalink | 記事への反応(1) | 22:23

ツイートシェア

■[年問題]コンピューターで発生する技術面の問題

1999年問題

1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。

1999年8月21日問題

GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。

2000年問題(Y2K)

年数を下2桁だけで処理していたシステムや、2000年を平年(閏年ではない)と誤解したシステムに問題が起こる。

2001年9月9日問題

1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。

2008年問題

2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。

2010年問題

潜在的なバグが発覚した。シチズン電波時計やソニーのゲーム機「プレイステーション3」(閏年処理)、オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。

2019年4月7日問題

GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。(10ビットでは2回目)

2030年問題

1930年 - 2029年を下2桁で表現しているシステムに問題が起こる。同様のものに2050年問題や2070年問題などがある。

2036年問題

1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。

2038年問題

Unixなど。1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。

2038年11月21日問題

GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。(10ビットでは3回目)

2040年問題

HFSのタイムスタンプは2040年2月6日までしか取り扱えない。

2042年問題

System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。

2048年問題

2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。

2050年問題

1950年 - 2049年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2070年問題などがある。

2053年問題

2038年問題の1985年起点版。TRONなど。

2070年問題

1970年 - 2069年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2050年問題などがある。

2079年問題

FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。

2100年問題

2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。

2108年問題

FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。

2137年問題

更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る(正確な日時は未定)。

2286年問題-2286年11月20日17時46分40秒に起こる。原因は、2001年問題と同じ。

3000年問題

Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。

10000年問題

西暦が5桁になる西暦10000年1月1日に起こる。

Permalink | 記事への反応(0) | 14:51

ツイートシェア

■https://anond.hatelabo.jp/20171013100220

いまさらだけど閏年と曜日の周期なんだから28年に決まっとろう。

あと、そこまで書いたんだから2100年にまさに28年周期が崩れてることに気づけよ。

Permalink | 記事への反応(0) | 00:29

ツイートシェア

■私は2月29日を有意義に過ごせただろうか

閏年で降ってきた1日、私はなんでもない日常を繰り返しただけだった。

昨日より良い1日を過ごすことができなかった。

今年は去年より良い1年にはならないのだろう。

Permalink | 記事への反応(1) | 00:38

ツイートシェア

■閏年ネタで思い出せない話

昔、父親がなんか興奮気味に言ってたんだけどさ。

父親「昔、実況で『今年はオリンピックがあるので、閏年なんですねー』ってのがあったんだけど、その時は１００年に１回の閏年が無い平年のはずだから間違いのはずだったんだけど、４００年に１回は閏年になるよってルールもあるから、逆の逆で正解だったんだよねー」

父親が語ったんだから、そういう年があったと思うんだけど。いつの話だ？

いやいや、２０００年のことらしいな、ググッタら。シドニーオリンピックのことか。

つか、４００年に１回じゃなくて、９００で割ったあまりが２００と６００か。まあ、４００年って言い方も直近４００年前って意味では大同小異か。

でも、俺の記憶では、もっと昔の話だったなあ。俺が小学生、つまり、２０年くらい前に聞いた覚えがあるんだよその話。つまりシドニーオリンピックの話がでるのはおかしい。

俺の記憶違いってのが濃厚なんだけど。

でもなんだろうなー。

せめて、その当の実況動画とか見れないかなあ。

Permalink | 記事への反応(0) | 13:25

ツイートシェア

■Apple Watchを使っている馬鹿に煽られたので、機械式腕時計の良さを説く

Apple Watchを使っている奴が馬鹿なのではなくて、Apple Watchを使っているユーザーの中にいるとある馬鹿に煽られたので書く。

俺は機械式時計を昔から使っているが、その馬鹿が「腕時計なんて携帯があればいらないだろ」と一方的に突っかかってきていて鬱陶しかった。

携帯を見れば問題ないと思っている人にとって腕時計は必要ないものだ。そしてそういう人はたくさんいるだろうし、彼がそう思うのは全く否定しない。

そいつが馬鹿なのは、その主張にもかかわらずApple Watchを買い、お世辞にも使いやすいとはいえないインターフェースで、メールとかの通知を必死に読もうとしていることだ。

諦めて携帯出せよｗ

その馬鹿のことはともかく、Apple Watchのおかげで機械式腕時計も注目度が上がってきて嬉しい限りだ。

せっかくここまで読んでくれた人に、俺の「主観的な」機械式腕時計の良い所と悪い所を挙げてみたいと思う。

機械式時計は電池がいらない

機械式腕時計は電池がいらない。充電もいらない。ゼンマイを巻けばすぐに時計が動き出す。これが一番大きなポイントだ。

久々にクオーツ時計を使おうとしたときに、電池がなくて使えなかった経験をした人は多いのではないだろうか。

USB充電式の時計だと、充電忘れなんて日常茶飯事だ。携帯ですらたまに忘れるのに、さらに充電が必要なアイテムを増やすのは辛い。残り容量を気にして生活するのも辛い。

機械式だと、リューズと呼ばれる横のゼンマイをチャチャっと巻くだけですぐに動き出す。

自動巻きの機械式腕時計ならば、腕につけているだけで自動的にゼンマイを巻いてくれるので、腕に着けている限り巻き直す必要もない。

すぐに動き出さないという難点はあるが、ソーラー時計も似たような特性があるので、毎日ゼンマイを巻くのが面倒な人は、自動巻きかソーラー式が良いだろう。

自分はメインでは手巻きの機械式時計を使っていて、それをつけている時は夜寝る前に巻いてから寝ている。USBよりはよほど楽だし、一日の最後に時計を巻くのは楽しい。

機械式時計は時間が狂う

機械式時計は時間が狂う。超精密な時計であっても、月に15秒くらいは狂う。

クォーツ時計もその程度は狂うのだが、携帯電話や電波時計などはいつも正確な時間を指すので、それらに比べると明らかに時間が狂う。

機械式時計には「トゥールビヨン」と呼ばれる、重力の影響を可能な限りキャンセルして時間を狂わせなくしようとする機構もあるが、それでも機械式である以上狂う。

なので機械式時計を使う以上、時刻を合わせる必要がある。自分の時計は1ヶ月で1分ほど狂うので、1ヶ月に1回くらい合わせているが、この頻度をどう判断するかは人それぞれだ。

特に、ラッシュアワーとかの乗り換えで秒単位を認識しながら行動している人にとっては、電波時計やスマートウォッチ（Google WearやApple Watch）を使ったほうがいいだろう。

ちなみに自分の機械式時計は秒針すらない。

機械式時計にも色々な機能がついている

機械式時計にSiriはついていないが、それでも日頃必要になる機能は大体ついている。

一番よくあるのがデイト、すなわち今日が何日かを表示する機能だ。外回りとかで入館証明を書かされたりするとき、デイトがあると便利である。

高価なのになると永久カレンダーと言って、30日31日の判定はおろか閏年までしっかり対応してくれる。安いやつは月初に自分で合わせることになる。

次に、好きな人が多いクロノグラフ。乱暴に言うとストップウォッチ内蔵腕時計だ。これは機能よりも見た目の格好良さで好まれることが多い。

ワールドタイマーは、海外とのやりとりの多い人には便利だろう。時差のある国の時間も同時にわかる機構だ。2国だけの場合もあれば、複数の国の時間が一気にわかることもある。

自分は仕事で日本以外に海外二拠点とやりとりが必要なことがあり、その時にはワールドタイマーの腕時計を着けているが、大変重宝している。多分スマートウォッチより見やすいと思う。

ミニッツ・リピーターという、時代遅れの機能も人気だ。光が一切ない夜に時間を知りたくなったことを想定して、今が何時何分か音で知らせる機構である。

今のご時世、電気のつかない暗闇なんてものはそう滅多にないので実用性はほとんどないが、ゼンマイ式なのに音を出せるその複雑な機構のファンは大変多い。

これらの機能はみな電池式の時計でも可能なものばかりだが、機械式のメリットを享受したままこれらの機能が使えるのが嬉しい。

機械式時計ならでは機能もある。ドレスウォッチは薄型がフォーマルだが、機械式だと電池の厚さ以上に薄いフォーマルな時計もある。（充電型だともっと薄いものもあるにはあるが）

スケルトンの時計も電池だと格好わるいだろう。ミステリークロックの腕時計版、ミステリーウォッチなんてものは、スマートウォッチでは到底実現出来ないだろう。

こういった機能はもう自己満足の世界かもしれないが、電気を使わずカラクリだけでこういった機能が実現出来るのに魅力を感じる人は多い。

機械式時計は高い

実際の所、今まで挙げてきた色々な機能は、ソーラー式の電波時計を買えば大体まかなえる。

ソーラー式の電波時計は、充電の必要もなく、常に正しい時刻を刻んでくれる。そして機械式時計に比べればまだ安い値段で買える、大変良い選択肢である。自分も1本持っている。

それに比べて、機械式時計は高い。ちょっとしたものでもノートパソコンくらいするし、50万円くらいの時計もたくさんある。数百万から1000万円超えも高級時計のラインナップに普通に並ぶ。

機械式時計は大体3年に1回オーバーホールに出す必要があり、そこで費用がさらに発生することもある。色々と高くつくのだ。

一方、機械式時計の価格の大きなメリットの一つとして、価値が落ちないというものがある。ノートパソコンは10年も経ったら間違いなくゴミだが、高級な機械式時計は50年くらいは余裕で動作する。

結婚生活でずっと身につけて欲しいという思いから結納返しの定番商品であるし、親から子供に自分の使っていた時計をプレゼントするのも機械式時計ならよくある話だ。

生活を一緒に歩む、気持ちを込めた道具としての腕時計、という側面は、機械式時計ならではのものだと思っている。

終わりに

これを読んで、機械式時計もちょっといいな、と思う人が出てくれたら嬉しい。ソーラー電波がいいなと思ってくれても嬉しい。やっぱりApple Watchいいじゃん、でも結構嬉しい。

自分で調べて自分好みの魅力的な一本に出会えた時の嬉しさは格別なので、敢えてお勧めの時計は挙げないことにする。

興味を持った方は、是非腕時計の世界を調べてみて欲しい。

Permalink | 記事への反応(3) | 12:04

ツイートシェア

■人生における自慰の時間を計算してみた

いきなりですが、僕は毎日２時間オナニーをしていた時期がありました。

平日は１回、休日は２〜４回。我ながらやりすぎなのではないかというくらいです。

４回した日にゃ、たまたまその後にエロいものをみて反応してしまったときの息子の痛さときたら、、、。

そこで僕はいったい人生でどれだけの時間をオナニーに費やしたのだろうと考えました。

まず一般男性はどれくらいなのだろうか。

あるアンケート結果を載せたいと思います。

==========================

「Ｑ１　頻度は？」。

・「ほぼ毎日」８１人

・「１週間に２、３回」１３８人

・「１週間に１回」４８人

・「それ以下」３３人

「Ｑ２　１回にかける平均時間は？」。

・「５分」４１人

・「１０分」９３人

・「２０分」５３人

・「３０分」７０人

・「４０分」１２人

・「６０分」２６人

・「６１分以上」５人

「Ｑ３　１日にした最高回数は？」。

・「１回」１８人

・「２回」７９人

・「３回」９２人

・「４回」３３人

・「５回以上」７８人

by:http://news.livedoor.com/article/detail/7974505/

==========================

ここで僕には統計学の知識がないので、以上の質問と回答で最も人数の多い回答結果を利用したいと思います。

よって、今回のサンプル男性は、

「１週間に２、３回（ここでは回＝日とします）、１回に10分、１日に３回もオナニーをする男性」とします。

となると、この男性がいつオナニーを始めたかも気になりますよね？

だって、人生でのオナニー時間を知りたいので。

と思って、ぐぐると女性のオナニー事情についての記事がでてくるわでてくるわ。

僕は男のオナニーが知りたいのに。。。

参考までに載せておきますね。

http://sextechnique.net/anan15

http://enq-maker.com/result/an2ZHxb

http://www.xn--u9ja5c230uvnfg8kc0ap9b411ht4x.com/

で、男性は以下にアンケートがありました。

http://kagai110.web.fc2.com/onani2.html

ここによると、１２歳が最もおおいため、１２歳から始めたと仮定します。

サンプル男性は、１回に１０分のオナニーを１日に３回し、その作業を１週間に３日しています。

ということは、１週間に行うオナニーの時間は、９０分です。

１年間（この場合、閏年ではないと仮定します）では、４７７０分です。

この作業をこのペースで行えるのを３０歳までとしましょう。

１２歳から始め、３０歳まで行うので、１８年間です。

１８年間では、８５８６０分です。

さらに、一番最初に紹介したアンケート結果のサイトでは、以下のようなことをおっしゃっています。

==========================

３０歳以上になると、「１週間に１回以下。平均時間は約２１分」

==========================

ということで、３０歳から４０歳までを上記のペースで行うと仮定します。

１週間にざっと２１分なので、１年間では１１１３分です。

これを１０年間続けるので、１１１３０分。

１２歳から４０歳までのオナニー時間を合計すると、９６９９０分。

つまり....1616.5時間

人生は８０年あると仮定すると、時間に換算して700,800時間。

これだけを見たら、意外と人生のうちに占めるオナニーってたいしたことないじゃんと思いますよね。

では、以下の計算を見てもそう言えますか？

==========================

仕事の一日の拘束時間が９時間＋残業2時間

週休二日制とすると月に８日前後休日＋（GW＋年末年始＋祝日で年間合計20日休日）＝

年間休日は116日程度

一生の内訳は

合計時間＝569,400時間

睡眠時間＝166,075時間（29％）

仕事時間＝120,615時間（21％）

残り時間＝282,710時間（50％）

by:http://miya-j.com/archives/31

==========================

どうですか？

人生の自由な282,710時間のうち、1616.5時間がオナニーの時間です。

人生の0.57％がオナニータイムです。

そうでもないでしょう？

ただ、僕の場合はオナニーは１０分じゃ済みません。

なぜなら、最高の動画を探す時間があるからです。

だいたい３０分程度でしょうか。

ということで、サンプル男性の時間の３倍の時間を費やしているので、4849.5時間。

それでも、1.7%です。

でも、よく考えてください。

この１.７％をもっと有意義な時間にしたら、この積み重ねが人生の差を決めるのです。

「僕はこのままオナニーばかりしてていいんだろうか？」

僕はある日疑問に思いました。

「この時間を、もっと自分の成長する時間に費やしたらどうなんだろう」

そう思い、オナニーの時間を削減するwebサービスを作りました。

エロサイト専用RSSリーダーです。

はい、宣伝です（笑）

これは、RSSができるだけでなく、外部サイトで気になった動画ページを他の端末、アプリと共有するためのブックマーク機能もついています。

他の人のRSSも見れるので、新しいエロサイトとの出会いもあります。

http://technobreak.jp

ここで皆さんが短時間にテクノブレイクする寸前までいってくれることがこのサービスのコンセプトです。

皆さんはきっとお気に入りのエロサイトがたくさんあるでしょうから、一度にまとめてすべてのサイトの更新をチェックして、是非オナニー時間を短縮してください。

でも、オナニー時間は短縮できますが、本番での時間短縮には気をつけてくださいね。

Permalink | 記事への反応(1) | 00:18

ツイートシェア

■「password」のハッシュ値

MD5は「5f4dcc3b5aa765d61d8327deb882cf99」

SHA1は「5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8」

生年月日(数字8桁)も過去100年分(36500＋閏年分)あればだいたい足りるよね

Permalink | 記事への反応(0) | 15:15

ツイートシェア

■プログラマ採用面接における足切り質問案

Joel氏の採用面接ゲリラガイドにもあるように、デキる開発者と一緒に仕事をしたいというのは、開発者なら誰でも思うことだ。

そこで、自分が面接する側だったら、初歩の初歩レベル、即ちプロとしてあり得ないレベルの人を足切りするような、くだらない質問を2つ考えてみた。

Java、VB.NET、C/C++、PHP、Perlといったオープン系では広く普及している言語で、ごく普通のPCやサーバで動作するコードを想定し、実装方法を考えてもらうというもの。

1. 1からnまでの整数を加えるといくつか求める。
2. ある年が閏年かどうか求める。

ここでポイントとなるのは「プログラムに正解はないが、明らかな間違いはある」という考え方。

つまり2つの質問に対して、明らかに間違った回答をしてきた人が失格ということ。

では上の問いで想定している明らかな間違いは・・・

1. n回ループする処理内でループをカウントしている変数を足していく。
2. 4で割り切れる年は閏年だけど100で割り切れる年は(中略)というロジックを書く。

どっちも教科書でよく見るやり方だけど、仕事でそれやるのは頭悪すぎて話にならないということで。

ちなみにそれぞれの質問で何を見ているか、デキる開発者には一目瞭然だと思うけど、説明すると

1. シンプルでエレガント()で力強く、高速かつ可読性も高くて(中略)そのためのアルゴリズムは・・・という工夫を実装において考えられるか
2. 誰もが欲しいと思うものは既に用意されているだろうという想像力を発揮してサボれるか

結局、コードを書くときに一番大事なのはそういう能力であって、間違っても努力や気合じゃないってこと。

最後に、各質問の正解例を書いてみるとこんな感じ。

1. n(n+1)/2
2. 求めたい年の2月29日0時0分0秒をtimelocal()的な関数に放り込んで、結果がエラーだったら閏年じゃない

願わくば、こんなのよりもっと驚くような回答をする人と仕事したいっす。

Permalink | 記事への反応(1) | 14:41

ツイートシェア

■ダメなコードを見ていて疑問に思うこと

数百行、果ては数千行もある関数やメソッドが何故生まれるのか、どうしても理解できない。それ仕様の通りに動かそうと思ったら、テストもデバッグもライフワークになるよね？それとも未完成でも納品するってこと？もしかしたら「勝手に関数/メソッド作るな」司令が出てるのかもしれないけど、だったら「できません」と断ったほうが絶対楽だと思うぞ。あ、楽といえばこういうコードのレビューは楽だよ、「長すぎて読めない、書き直し」で終わるから。

条件分岐やループを何重にもネストしたコード。スクロールさせるとうねって見える。それさ、正常系の処理だとして一番最後の行の直前はどこ通るの？即答できないなら書き直せ。即答できても「こういう複雑なコードを書けるのがプロ」とか誇らしげな表情しちゃう人はただの勘違いバカだから、その姿勢改めるまで可愛がられるかサクッと見捨てられるかでしょう。

ANDやORが入り組みまくった条件式だけどさ、お前一体何がしたいの？それ多分お前しか理解できないから、システムがEOLになるまで面倒見てあげてね。

「1からnまでの総和」とか、公式がありそうなものをロクに調べもせず、n回ループする方法しか思いつきませんでした的に書いたコード。そんなバカ丸出しの実装で恥ずかしくないの？バカはプログラマに向いてません。それは前述の勘違いバカもそうだけど、頭を捻るセンスが無いのも致命的。

閏年を始めとする日付の計算アルゴリズムとか、標準提供されていそうなものまで手で実装したコード。お前それ辛くないか？てかマニュアルやヘルプはちゃんと読もう、な？

なんで同じコードをコピペするの？共通ルーチン作らなくてもgrepで直して回れば修正漏れも起きないって魂胆？同じ処理が出てくるたびに読んでてうんざりしてくる人も少なからずいることを理解して仕事してください。頼むよ。

DBのテーブルから全レコード取得して、必要なデータか判定して処理するコード。WHERE句って知ってる？データが数億件とかあってもそれでいいと思ってる？

その処理は本当にコードで書かないとダメなの？書かないで済みそうなことまで何故書くの？書かなきゃいけないとして、どうやって短く書くか工夫しないの？コードが増えただけバグも増えることを、もっと深刻に受け止めて欲しい。

最後にコードじゃないけど、巨大なディスプレイに高解像度で極小フォントという環境で開発ってどうなのよ。そこまでしてコード全部表示しないと書けないんだ？今まさに書いている部分なんて、変数もアルゴリズムも自分の頭の中にあるんだから画面に表示する必要なくね？確かに開発用のディスプレイは大きいものが複数あったほうがいいけど、それらはそういう使い方をするためにあるものじゃないと思うぞ。

Permalink | 記事への反応(4) | 13:22

ツイートシェア

■[日本eリモデル]ある意味最強の会社 日本eリモデルについて

確かにねー活動過激( ﾟдﾟ)

よくよく観察するとw

日本eリモデル 独占評価

直近の投稿？何？スゴすぎ？会社で勉強大会しているのかなぁ～^^;

http://ameblo.jp/mystandardjp/entry-11018488804.html

9月15日 | 今ホットな話題情報2011年09月15日

テーマ：日本eリモデル

注目度ナンバー1！ホットケナイ！ホットなキーワードをチョイス！

■ 9月15日の話題

9月15日（くがつじゅうごにち）はグレゴリオ暦で年始から258日目（閏年では259日目）にあたり、年末まであと107日ある。

1590年 - ウルバヌス7世 (ローマ教皇) ウルバヌス7世が教皇 ローマ教皇に選出される（在位13日で死去。在位期間史上最短の教皇）。

1821年 - コスタリカ、グアテマラ、ホンジュラス、ニカラグア、エルサルバドルがそれぞれスペインからの独立を宣言。

1830年 - イギリスで世界初の鉄道開通。開通式典で死亡事故。

1835年 - ビーグル (帆船) ビーグル号による世界探検を途上にあったチャールズ・ダーウィンがガラパゴス諸島に到達する。

1868年（慶応4年7月29日 (旧暦) 7月29日）- 戊辰戦争: 二本松城が落城する。

1888年 - 東海道本線、大府駅～浜松駅間開業。

http://mystandardjp.cocolog-nifty.com/

■ 9月15日 (旧暦)の話題

旧暦9月15日は9月 (旧暦) 旧暦9月の15日目である。六曜は六曜#大安 大安である。

慶長5年（グレゴリオ暦1600年10月21日） - 関ヶ原の戦い

慶長18年（グレゴリオ暦1613年10月28日） - 支倉常長ら仙台藩の慶長遣欧使節が日本を出発

建炎4年（ユリウス暦1130年10月18日） - 朱子、朱子学の祖（+ 1200年）

貞享2年（グレゴリオ暦1685年10月12日） - 石田梅岩、思想家（+ 1744年）

文政8年（グレゴリオ暦1825年10月26日） - 岩倉具視、政治家・明治維新の元勲（+ 1883年）

保延6年（ユリウス暦1140年10月27日） - 覚猷 鳥羽僧正覚猷、天台宗の高僧。伝『鳥獣人物戯画』作者。

嘉元3年（ユリウス暦1305年10月4日） - 亀山天皇、90代天皇（* 1249年）

http://ameblo.jp/mystandardjp/entry-11017507873.html

チャンピオンズリーグ | 今ホットな話題情報

2011年09月14日

テーマ：日本eリモデル

注目度ナンバー1！ホットケナイ！ホットなキーワードをチョイス！

■ チャンピオンズリーグの話題

大会名

開始年 1955

終了年

主催 欧州サッカー連盟 UEFA

参加チーム数 32

（3回目）

（9回）

備考

欧州クラブシーンにおける最も権威ある国際大会であり、各国リーグ戦の上位クラブが総登場することから世界的な注目を集める。勝ち上がるごとにクラブには莫大な収益がもたらされ、優勝クラブは名実共に欧州一の称号を得られることから、自国のリーグ戦よりもこちらで勝つことを優先しているクラブも数多い。

優勝クラブは「クラブ世界一」を決めるインターコンチネンタルカップ (サッカー) インターコンチネンタルカップやFIFAクラブワールドカップへの出場権を得られるが、世界の有力サッカー選手は軒並み欧州のクラブに集中しているため、この大会で優勝したクラブが実質的には世界一のクラブであるというのが衆目の一致するところである。

http://w.livedoor.jp/nihonerimo/

■ チャンピオンズリーグ (曖昧さ回避)の話題

チャンピオンズリーグ（Champions League）

サッカー

UEFAチャンピオンズリーグ

CAFチャンピオンズリーグ

AFCチャンピオンズリーグ

CONCACAFチャンピオンズリーグ

OFCチャンピオンズリーグ

アラブ・チャンピオンズリーグ

EHFチャンピオンズリーグ（ハンドボールのヨーロッパクラブNo.1を決める大会）

ヨーロッパチャンピオンズリーグ (卓球)

バレーボール欧州チャンピオンズリーグ

WBFチャンピオンズリーグ

FUTSAL地域チャンピオンズリーグ

チャンピオンズリーグ (麻雀)

cs:Liga mistr?

da:Champions League

Champions League

es:Liga de Campeones

http://www.geocities.jp/nihonerimodel/

■ チャンピオンズリーグ (麻雀)の話題

チャンピオンズリーグは、日本プロ麻雀連盟が主催する麻雀のタイトル戦。

古くは内外タイムス杯。2001年度前期までは王座杯という名称。2001年度後期よりチャンピオンズリーグへ改称。

出場資格：日本プロ麻雀連盟員。

ルール：連盟Ａルール。

半荘4回戦×5節。1半荘は時間制限ありの50分＋1局で打ち切り。準々決勝からは現チャンピオンズリーグの1名を加えた16名で行う。決勝は準決勝勝ち上がりの4名で半荘5回戦。その半荘5回戦合計総合計ポイントトップ者が今年度の優勝者となる。

麻雀のタイトル戦 ちやんひおんすりーく

毎日観察するからw

Permalink | 記事への反応(2) | 19:32

ツイートシェア

■http://anond.hatelabo.jp/20100826175941

フランス革命歴

ちょ、フランス革命歴とかマジ勘弁してください。

そんなんされたら生きていけないｗ

そもそも、中立的で普遍的な暦じゃないし。

閏年とかどうするんだｗ

Permalink | 記事への反応(0) | 18:19

ツイートシェア

■SCEにこれから襲いかかる閏年誤判定障害の後遺症

まぁ、色々な幸運？が重なってそこまでデカイ障害にはなっていないように見える今回PS3の閏年問題。

しかし、SCEはこれから対処しなければならない問題があり、企業の障害対策の観点から言えばここからが本番だ。

一応サービス業に従事するものとして、勉強を兼ねて緊急度別にどんな問題を解決しなければならないのか挙げておこうと思う。

緊急度：最大

• ビデオレンタルユーザーへの保証

まぁ、コレがぶっちゃけ一番でかいよね。なんせ金取ってるし。

全部の商品を調べたわけではないが、基本72時間単位で課金をしている事から見て、今回の障害で72時間中最大24時間、

実に契約期間の1/3も利用不可の状態にしてしまったわけで、このまま白を切るワケにはイカンよね。

何らかの保証が必要でしょう。

PSNの利用規約にざっと目を通したところ、「ナニが起こっても基本的にSCEに責任ありません」とか、

「最悪保証する場合も購入金額を超える保証はしません」というこの手のサービスによくある記述しか無いため

どのような保証がなされるのかは現段階で不明。

せめて障害期間に被ったレンタル契約に関しては全額返金するぐらいの対応をすれば、

多少の痛手と引換に今後のブランドへの信頼感を得られるのではないでしょうか。

つか、何の根拠も無い俺の個人的な予想では、痛手ですら無い額だと思うけどね。

緊急度：大

• その他課金サービスへの対応

上とまとめても良かったんだけど、ビデオレンタルは利用期間が短く障害の影響がほかと比べて甚大すぎる為切り分けました。

その他課金サービスに関しては、殆どがSCEを通して他の企業が提供しているサービスなので、企業間契約でSLAがどうなっているか

によるのですが、ぶっちゃけその辺の契約なんて分かる訳ないので割愛。まぁ、丸一日商売の邪魔したわけなので、

お咎めなしってワケには行かないでしょうね。お偉方が菓子折り持って謝罪行脚程度で済めばいいんですが。

緊急度：中

• 破損したデータの対応

ウチのPS3は運良く障害期間に全く利用しなかったのと、まだ情報を集めてないのでコレがどうなったか分かってないんですが、

報告にはセーブデータがイカれた、テーマがイカれた、トロフィーデータが消えた等の報告が上がってました。

トロフィーは同期してない分は復旧無理だろうけど、ぶっちゃけ他に比べたら緊急度低すぎてココに含めなくても良かったぐらいですが

一応おなじデータって分類なのまとめました。

購入したDLCについてはアカウント情報さえ手元にあれば購入履歴から再度DLし直せばいいので、謝罪文のみですむ場合がほとんどでしょう。

ただ、セーブデータに関しては対応を間違うと今後の商売に響きかねないので注意が必要でしょう。

とはいえ、たぶん最終的には諦めてもらうしかないんですけどね。

セーブデータに関しては、発売当初誰とでもセーブデータの交換がネットを通じて出来ると言う恐ろしいまでのオープンな姿勢から一変、

オンラインゲームが増えてきたこともあり管理が非常に厳重となっております。万が一破損フラグを立てるだけでデータはそのまま残っていた場合でも

コレをパッチ等で復旧させるのは、技術的には簡単でもPSNの今後を考えると絶対に行えない対処です。

なぜかというと、今年に入ってPS3のファームウェアが完全にクラックされてしまった可能性があるからです。

iphoneのJailBreak等で名を馳せたとあるクラッカーが年末年始あたりからPS3に手を出し、実質5週間で完全にクラックした、という報告を自身のサイトで

発表したと言うニュースがありました。コレがすぐ割れにつながるわけではないですが、最高レベルのシステム権限すら握れてしまうらしく、事実であるなら

破損フラグ除去パッチなど、どう考えても配信できる訳ない。手がかり無しで自体を把握しなければならないクラッカーにわざわざヒントを与えることになりかねず

泥棒に追い銭やるようなもんだからです。

というわけで、誤って起動してデータが破損してしまった方は残念ですが諦めた方が良さそうな感じ。

オンラインに関係ないゲームなどは多少融通が効くかもしれないですが、そのへんはゲームタイトルによるのかもしれません。

緊急度：低

• 野次馬対応

まぁ、緊急度ゼロでも良かったんだけどｗｗｗ

コレはぶっちゃけどうでもいい。大した影響ないから。外野が多少喚いたところで今のPS3の勢いなら何の影響もないでしょう。

地デジ需要も見込めそうだしね。

長々と書いたけど、こんなもんじゃなかろうか？どう対応するのか見ものです。

何もしないってことは.....流石にないよね？特に課金関連。

まぁ、他人事なので興味深く見守りたいと思います。

Permalink | 記事への反応(1) | 20:16

ツイートシェア

■PS3閏年についての妄想

PS3のバグは閏年の判定ミス，だそうな．

流石にいくらなんでもそんなしょーもないミスはないだろう，と．

だって閏年を忘れたんじゃなくて，閏年じゃない年を閏年だと判定したってことなんだから状況がおかしい．

閏年の判別なんてmod 4を取って，後は100と400に関して調べればいいだけ．

2000年が終わったから100とか400とかやる必要が事実上無いと考えてもmod 4を取ればいいだけ．

流石に間違えようがないだろう．

しかも20G,60Gと40Gモデルでだけ起きるってのも変な話．

で，PS3の発売されたのが2006年だってのを考えると，

まさかとは思うが2006年からスタートする内部時計（ソニータイマー）を保持していて，

閏年の判定にその時計を使ってしまったとか．

インポートするときにTimeクラスではなくTimeSonyクラスを使ったとか．

そうすると2010年はソニー歴の閏年になるわけで，PS3は間違っていない．

20G,40G,60Gでは起きて，基盤が大きく異なる80Gと薄型では起きないという説明もこれでうまくいく！

まぁこれでは肝心の本当の閏年（2008年）に問題が起きるはずなので，やっぱりそんなことはないですかね．

# 一部で言われていたトロフィー関連のバグってのが真相な気はするけどなぁ．

Permalink | 記事への反応(0) | 13:49

ツイートシェア

■http://anond.hatelabo.jp/20090901021557

datetimeって2.0系列で閏年の扱いが曖昧だからじゃね。

leapdays()のバグ（こっちは2.0だと直ってる）と同じく、timedeltaのdaysって400で割り切れる年を平年と見なす（本来は閏年）バグが入ってるだろ。

たぶん、2009年の時点で５日ずれてると思うよ。3.0環境とかだと直ってる？

Permalink | 記事への反応(1) | 11:02

ツイートシェア

■http://anond.hatelabo.jp/20090831161712

友達に、こう指摘してみてよ。

• 2009年3月1日0時0分0秒までの秒数よりも2009年2月1日0時0分0秒までの秒数の方が長いのは何故か？
• 2004年は閏年なので、 2005年1月1日0時0分0秒までの秒数と2004年1月1日0時0分0秒までの秒数の差は31622400になるはずだが、31536000秒しかないのは何故か?
• 求める日時を変更するために、わざわざ計算させている部分の変数をいじらないといけないのは、いいプログラムといえるか。より具体的には、計算部分は別関数に分離して、mainは引数を指定しての呼び出しと、返り値の表示のみに止めた方が良いのではないか
• 2678400などの値をわざわざプログラム中に直接書いているが、その意義は何か？ 1時間は3600秒や、1日の秒数くらいまではそのまま打ち込んでもいいかもしれないが、29日が何秒かなんて、答えられる人はそうそういない。3600*24*29とソース中に入力したら、何がいけないか？(この計算は、コンパイル時に行われるので、掛け算数十個分だけコンパイルの時間は伸びるかもしれないが、それは微々たるものだし、それに実行時はどちらも同じ時間で実行される)

Permalink | 記事への反応(0) | 00:34

ツイートシェア

■http://anond.hatelabo.jp/20090831161712

よく分かりません。誰か解説してください。

せっかくだからベタに解説してみる。

（クラス名がsecとかつっこみどころは全部スルーで）

まず変数宣言。

時間と日付を変数に入れてる。2009-6-5 23:53:0だね。

秒も0にして。ur(たぶん閏uruuの略)をfalseに。

最初のfor文で、2008年までの秒数を足そうとしてる。

しかし、閏年の処理が変なので上手くいかない。

（400で割って1余る年と、4で割って１余る年は、別に閏年じゃない）

月が2だったら、2678400を足してる。

その後は特筆のおもしろさ。

monthが２でかつ、monthが３でかつ、urがtrueなら2505600を足してる。

（さっきのurの扱いに注目。去年が400で割って1余る年か、4で割って１余る年の時だけ）

しかし、判るとおりmonth が 2 で かつ 3 なんて素っ頓狂な事にはならない。

つまりここは、month が 2 かそれ以外かの処理しかない。

		if(month == 2){
			sec += 2678400;
		}

要はこう圧縮できる。

最後に日付（月の頭からその日付）の前日までの秒数を足して

時間と分と秒を、全部秒に直して足して、

表示してる。

総評

• ファビュラス！！

Permalink | 記事への反応(0) | 19:05

ツイートシェア

■http://anond.hatelabo.jp/20090224080227

52×7が364だから、平年の次の年の曜日は一つだけ動いて、4年に1度の閏年は2月と3月の曜日がずれて次の年は2つ動く。

だから28年周期で、その間に2月13日の金曜日は4回あるけど、そのうち1回が閏年なので3月13日が土曜日になってしまって、かわりに12年前の閏年に3月13日の金曜日が来るらしい。

というのをエクセルで確認したw

直近だと、2009年の後は2015年、2026年、2032年で2032年が閏年で2020年に3月13日の金曜日がある。

Permalink | 記事への反応(1) | 08:57

ツイートシェア

■http://anond.hatelabo.jp/20090224061416

何年に一度かは分からんけど、元日が木曜で始まる年（閏年除く）は2月3月が13日の金曜日なんだよね。

単純に考えたら、だいたい1/7くらいの確率？

Permalink | 記事への反応(1) | 08:02

ツイートシェア

■よくある曜日の話

3月1日を月曜日とする。29日は1日と同じ曜日だから3月31日の翌日である4月1日は木曜日である。同じように5月以降の1日は順に土、火、木、日、水、金、月、水となる。つまり全ての曜日が揃っている。ここまで閏年は関係ない話なので、13日の金曜日は毎年必ず訪れる。

さて

ある年の元日を月曜日とする。平年なら翌年の元旦は…火曜日と曜日が一つ進み、閏年なら水曜日と曜日が二つ進む。閏年は4年に一度、しかし100年に一度平年、さらに400年に一度は閏年になる。よって400年で+400 +(400/4) -(400/100) +(400/400) 曜日が進むが、整理すると7の倍数となり、つまるところ400年前の曜日と同じになる。

さてやたら手間のかかる問題です。400年のうち、13日の曜日は何曜日が一番多いでしょう。

Permalink | 記事への反応(0) | 20:00

ツイートシェア

■

http://www.gamedesign.jp/flash/yomi/yomi.html

Permalink | 記事への反応(0) | 04:52

ツイートシェア

■Joel On Software私訳

訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。

注意：以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、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を快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:

• これらはバイナリフォーマットだ。だからレコードのロードは通常は、単にディスクからメモリへある範囲のバイト列をコピーする(blitting)ことで、それは結局あなたが使うCデータ構造だ。lexing も parsing も ファイルのロードに際しては行われない。lexing と parsing は blitting よりも 1オーダー遅い。
• このファイルフォーマットは、よくある操作を速くするために、必要なところでは捻じ曲げられている。例えば Excel 95 および 97 は "Simple Save" と呼ばれるものを持っており、これは主流の使いどころでは十分に高速とはいえない OLE compound document formatの 高速なバージョンとして使われた。Word は Fast Saveと呼ばれるものを持っていた。長いドキュメントを素早くセーブするために、15回中14回は、1からドキュメントを書き直すのではなく、変更分がファイルの最後に追加されるだけだった。当時のハードディスクでは、これは長いドキュメントのセーブが30秒でなく1秒ですむことを意味していた。(またこれは、ドキュメント内の削除済みデータがファイルに残ることを意味してもいた。これは人々が望んだことでないと(のちに)判明した。)

これはライブラリを使うことを想定して設計されている。もしあなたがバイナリをインポートするものを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内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。

1. Webベースのアプリケーションがあって、それが既存のWordファイルをPDFフォーマットに出力するようにする必要がある場合、それを実装するにはこうする: ファイルを読み込んでからWord 2007のビルトインのPDFエクスポーターを使ってそれをPDFとして保存する、数行のWord VBAコードだ。あなたはこのコードをIISで動作しているASPやASP.NETのコードから直接呼び出す。これでうまくいく。最初にWordを立ち上げるときは数秒かかる。2回目はCOMサブシステムによりWordはまたあなたがそれを必要としたときのためにメモリ中にキープされている。それは通常のWebベースアプリケーションにとっては十分に速い。
2. 上と同じ。ただしあなたのWebホスティング環境がLinuxだった場合。フルライセンスのWordがインストールされたWindows 2003サーバを買う。そしてその仕事をする小さなWebサービスを構築する。C#とASP.NETでの半日の作業だ。
3. 上と同じ、ただしあなたがよりスケールさせたいと望む場合。ステップ2で構築した全部のボックスの前にロードバランサーを置きなさい。コードは必要ない。

この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:

• Excelのワークブックを開き、セルに何らかのデータを入れ、再計算して、そして結果を出力セルに書きこむ。
• GIFフォーマットでチャートを生成するのにExcelを使う
• 色々なExcelワークシートから色々な情報を取り出す。ファイルフォーマットについて考えることに時間を使うことなしに。
• ExcelファイルフォーマットからCSVのテーブルデータへの変換 (別の方法は、Excel ODBCドライバをSQLクエリを使ってデータを吸い出すのに使うことだ)
• Wordドキュメントを編集する
• Wordフォームへの記入
• Offceがサポートしている沢山のファイルフォーマットの間でのフォーマット変換 (ワードプロセッサと表計算のフォーマットについては沢山のインポーターが存在する)

これらのケースの全てにおいて、Officeオブジェクトにインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザに入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。

書き込むファイルにはもっとシンプルなフォーマットを使いなさい。単にOfficeドキュメントをプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマット、WordやExcelでも問題なく開くことができるようなフォーマットが存在する。

• 単に、Excelで使うテーブルデータを生成することが必要なだけなら、CSVを考えなさい
• CSVがサポートしていない、worksheetの計算というフィーチャーが本当に必要なら、WK1フォーマット(Lotus 1-2-3)はExcelよりもずっとずっとシンプルで、しかもExcelでも開ける
• 本当に、本当に、ネイティヴなExcelファイルを生成しなくてはいけないなら、Excelのすごく古いバージョンを見付けなさい。Excel 3.0が良い選択だ。compound documentの構成物の全ての前に、あなたが使う必要のある最低限のフィーチャーだけを含むミニマムなファイルを保存しなさい。このファイルを、きっかりミニマムなBIFFレコードを見るために使い、仕様のその部分だけにフォーカスしなさい。
• Wordドキュメントなら、HTMLを書き出すことを検討しなさい。これもWordは開ける。
• 凝ったフォーマットのWordドキュメントを生成したいなら、最高の選択はRTFドキュメントを生成することだ。Wordに出来ることはRTFでも表現できるが、しかしそれはバイナリでなくテキストフォーマットなのだ。だからRTFドキュメントのなかのものは変更できるし、変更しても問題なく使える。Wordで、いい感じにフォーマットされたドキュメントの中にプレースホルダを置いたものを作って、RTFでセーブして、そして単純なテキスト置換を使ってそのプレースホルダを置き換えることができる。これでどのバージョンのWordでもうまく開けるRTFドキュメントができる。

いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。

Permalink | 記事への反応(1) | 11:38

ツイートシェア