スコーンを食べながらビールを飲むなどしている。
スコーンはゆるやかなティータイムにいただくやつじゃなくて
カリッとサクッとおいしいスコーンの方ね。
スコーンスコーンコイケヤスコーンの方。

で、このように心地の良い時間を過ごしながら
これはもう素直になった方がいいなと思うことがあるので
へべれけな勢いのままに書きます。

冷たいビールが好きだ。
もう薄氷も張ろうかというほどに冷たいビール。

何か真のビール好きは常温に近いビールを好むのだとか
本場ドイツではそんなに冷やしたビールは飲まないとか
キンキンに冷やしたビールばかり飲むのは日本人ぐらいだとか
いろいろ聞きますが、でもビールは冷たいのがいいです。
真のビール好きじゃなくてもいいし、日本人ですし。

だからどうということもないんですが、
ともかくビールは冷たいのが好きです。

明日の朝これを見たらきっと
「何書いてんだ自分」と思うんだろうけど、
ともかくビールは冷たいのが好きです。

2000年問題というのが話題になったことがありますね。

当時はコンピューターの記憶容量の消費を抑えるために
西暦の下2桁だけを使って年を計算するシステムが多かったので
99 (1999年) の次の年は 00 となり、
1900年なのか2000年なのかわからなくなってしまい
コンピューターシステムに異常が発生するんじゃないか、という話。
懐かしいですね。

見えないところでいろんな人が頑張ってくれたおかげか
結局 知っている範囲では大きな問題は起きなかったんだけど、
コンピューターで扱う数字の桁に関しては
想定されている問題が他にいくつもあるみたい。

見てたらいくらか出てきたので、
目についたものをまとめてみます。

2038年問題

コンピューターで時間を表現するのに
UNIX 時間がよく使われますね。
1970/01/01 00:00:00 からの経過時間を秒で表すやつ。

32ビットの整数データ型が使われている場合
正の値は2,147,483,647までしか数えられないから、
UNIX 時間で2,147,483,647にあたる
2038年1月19日3時14分7秒の次の瞬間に数値がオーバーフローして
どっかで何か誤作動が起きるんじゃなかろうか、というのが
いわゆる2038年問題。

これを2000年問題よりややこしくしているのは

• 2000年問題より意味がわかりにくいので、エラい人に説明しても伝わりにくい。
• UNIX 時間は時差を持たないから、全世界で一斉に発生する。

というあたりでしょうか。

まだ2038年にはなってないけど、
時間の計算をする過程で数値がオーバーフローしてしまい
トラブルが発生したという事例は既にあるようです。

10000年問題

2000年問題をクリアして以降
多くのシステムでは西暦を4桁の整数で表しているので
西暦9999年の次は桁が溢れてしまうという話。
これはわかりやすいですね。

2038年問題はもうすぐだけど、
まあ10000年問題のことは
あと7900年ぐらい経ってから考えますか。

292277026596年問題

2038年問題をクリアする方法として
時間を扱うのデータの型を
32ビットから64ビットに変更するというのがありますね。
そうすれば UNIX 時間で
9,223,372,036,854,775,807 までカウント可能。

ただ、桁を増やしても
いずれオーバーフローが発生するというのは同じこと。
次は西暦2922億7702万6596年12月4日に溢れます。

他にもいろいろありそう

2038年問題と似たような話だけど、
Windows や NTP では1900年からの秒数を符号なし32ビットで扱うから
4,294,967,295秒後の2036年2月6日に発生する「2036年問題」とか
いろいろ節目のタイミングはありそう。
他にもご存じだったら教えてください。

永遠とか完全とか絶対とかいうことはないので
常に「次の問題」は存在しますね。

まあ人間のやることは完璧にはならないし
いずれは地球がなくなったり太陽が消え去ったり宇宙が消滅したりするので
それまでは一生懸命に生きていきましょう。

Twitter が投稿内の URL を短縮するのに使うサービスを
tinyurl から切り替えたということもあって、
bit.ly がにわかに注目を集めている。

単に長い URL を短縮するだけじゃなくて、
ユーザー登録しておけば
自分が作った短縮 URL のクリックログを
リアルタイムで見ることもできるとか
URL を短縮してそのまま Twitter に投稿できるとか
リッチな API が提供されていてサービスに組み込みやすいとか
いいところがいろいろあるみたい。

その便利さの前では実に些細なことなんだけど、
bit.ly にユーザー登録をして使うときは
プライバシー設定を見ておいた方がいい人がいるかもしれない。

自分が作ったリンクの履歴を公開する設定に
デフォルトでチェックが入っているから。

要するに、ユーザー登録したままの状態だと
アカウント名のあたりをつけてアクセスされたら

• http://bit.ly/user/recent/msng

これまでに bit.ly で作ったリンクの一覧が人から見える。

どこへのリンクを作ったかを人に見られたら困るという人は
そうそういないかもしれないけど、
例えばちょっとしたおふざけを仕掛けるのに bit.ly を使った場合に
ここを見られたらバレて「お前の仕業か！」などと言われるかもしれない。

気になる場合は、画面右上の "Account" というところから

設定を確認しておくといいかもしれませんね。

あと何ですか、
何か頻繁にアクセスしていることを
人に知られたくないようなサイトがあるんでしょうか、
よくわかりませんけども、
わかりやすい形で URL をメモしたり保存したりするのを避けたい人が
URL 短縮サービスを使うことがあるんでしょうか、
よくわかりませんけども、
まあともかくお心当たりの方はご確認ください。

先ほどまでしゃっくりが止まらなくて困ってたんだけど、
教えてもらったやり方が見事に効いて感動したのでその勢いで。

お腹に手を当ててみたり背伸びをしてみたり
ネットで読んだことがある方法を試してみたりしたんだけど
なかなか治まらず、
どうしたものかと困っていたら
dubstronica の人がこれを教えてくれた。

しゃっくりの止め方｜拝むように弾いてくれ

1. 肺に残っている息を吐ける限界まで吐き出す。
2. 吸える限界まで息を思いっきり吸い込む。
3. 止められる限界まで息を止める。

やってみたら効果覿面。
何事もなかったようにしゃっくりが止まった。
ありがとう dubstronica の人！

人によって違うのかもしれないけど
個人的にはこれが最強の止め方だと思う。

あまりに気持ちよく止まったのでまたやりたい。
しゃっくり出ないかなー。

本を見ながら作業しようとしても
大抵の本は開いた状態を維持できずにすぐ閉じてしまうので、
これまでは他の本なんかを文鎮代わりに載せていた。

でもそのぶん余計な場所を取るし
重しが載っている部分を見たいときはずらさないといけないしで
不便な思いをすることも多い。

何か便利なものはないかと思っていたら
Twitter 経由でいろんな方がいろんなものを教えてくださった。

その中に「これだ！」と思うものがあったのですぐさま入手。
昨日届いたのでさっそく使ってみた。

「ブックストッパー」という、もうそのまんまの名前。
要するに重りがついたクリップなんだけど、
使ってみるとこれが実に便利だった。

開いておきたい本の、ページ数が少ない方をこれで挟んでおくと

本が閉じなくなる。

クリップ部分で挟めるページ数には限界があるけど
厚みのある本の場合も開きたいページの一部だけ挟んでおけばいい。

むしろこの使い方の方が安定している気がする。

書見台というかブックスタンドというか
そういうものも便利かなと思ったんだけど、
これは小さくて持ち出すのも楽ちんなので
外出するときにも活躍してくれそう。

資料を2冊同時に見たいときも大丈夫。

2個買ったから。

というわけで、
本を開いておくために別の本を載せておいたら
載せてる方を開く必要が出てきてまた別の本を、
という経験がある人は試してみてもいいかも。

ブックストッパー

トモエ算盤

上の本を持ち上げたときうっかり下のを閉じてしまって
どこを開いてたかわからなくなった経験がある人とかね。