おにぎりの存在が定まらない…

朝一からバタバタしていたら、
買っておいたおにぎりが消えていました。

あれ？食べたんだっけ？
レジ袋は…もう捨てたんだっけ。

でもこの空腹感は、食べてないと言っている気がする。

レジ袋ごと捨てた？
さすがにそこまでアホじゃな…いと信じたい。

コンビニのおにぎりは海苔がパリパリだから、
デスクに海苔の破片が残るはず…なのにない。

やっぱり食べてない！
仕方ない、ゴミ箱から取り出して分別だけでも…あれ？

ゴミ箱にも見当たらない。
奥の方か？
さすがにオフィスでゴミあさりを召喚する勇気はない。

…そもそも買ってない？
いやいや、レシートが買っていることを証明している。

おにぎり…どこに行ってしまったんだ。

目grepの世界

目grepなるものがあるそうなので、
前回のヘビードキュメントと自分のドキュメントを目grepしてみました。

まず自分のドキュメントは…
う～ん、結構なまだら模様です。
かろうじてヘッダー部分に特徴的な形が見られました。
PNGだってそのうち分かるのかね？

そしてヘビードキュメントです。

…( ﾟдﾟ)ﾎﾟｶｰﾝ

そこには見事なストライプ模様がうつされていました。
これは…ビットマップなんだろうな…
(後にWordからもビットマップであることを特定しました)

ファイルの大半はそんなふつくしい状態でした。

視覚的に見比べると、
やっぱりまた違った印象があるということですね。

別にハッカーじゃなくても、
気になるファイルに目grepするのは楽しいかもしれませんよ？

ヘビードキュメントェ…

会社である方が作ったドキュメント(Microsoft Word)をコピーしたところ…重っ！

たかだか30ページ前後なのに、
100MBを余裕で超過していました。

対して自分が作った20ページ前後のドキュメントは、
500KBに届かない程度しかありません。

10ページの差で…なわけはありません。
明らかに別の原因があります。

どちらもふんだんに画像を貼り付けているのですが、
この画像のフォーマットが怪しい…というかもしかしてBMPでは？
作成者は疑問に思わなかったんでしょうかねぇ…

自分はPNGに圧縮するのが好みです。
等倍で貼りつければ、
画像がクリアで大変見やすいからです。

変換するのが面倒だって？
そんなことはありません。

クリップボードの画像自動保存ソフトを使っているからです。

これを使うと変換作業は全て自動で完了します。

他にもこういうフリーウェアは結構あるはずなんですが…
何でこう残酷なことをするのか…

あなたの上司にもいませんか？

カレンダー入力をしよう♪

JKL.Calendarを改造したので公開してみました。

基本的な使い方は変わらないですが、
時分秒も入力できるようになっています。

後は個人的な好みで初期設定が白黒ベースのカラーリングです。

まあ適当品なんでバグはあるでしょうが、
おんなじことをしたい物好きへの助けくらいにはなるでしょう。

→jkl-calendar-with-time.js
※修正BSDライセンスになります。

ああ、スピンボタンの押しっぱなしはめんどくさくて実装していません。
ごめんね？

というわけでもう寝る。

そんなにログが見たいのか！？

いや、何がいいたいのかって…
記事のランキングの話です。

「myBatisのログをLog4jに出力する」
が一位ってどういうこと！？
そんなに困っている人がいるってこと！？

う～ん、気が向いたらlog4jのおバカな解説書こうと思っていましたが、
先にmyBatisにした方がいいのかな？

確かにログが見れないと詰む要素はありますし。
(ソース読めばかなり分かりやすくログを出す方法が…いやよそう俺勝手皆混乱)

日本語のまとめサイトは少なそうだし、
需要があると信じて…まあ気が向いたら？

白黒はっきりつける程度の(ry

別にえいきっきの話ではありません。

ブログの背景を“白”ベースにするか“黒”ベースにするかの話です。
…明るめなのか暗めなのかと思ってください。

TFT液晶モニターの消費電力的には“白”に軍配が上がります。
(LEDモニターはまだ未調査だけど…こっちは“黒”かなぁ？)
感覚的には不思議な話ですが、まあ事実としてあるようです。
たしか液晶は“黒”にするために電気を使うとか何とかだそうで。
(体温計とかが分かりやすいかな？電気を通すと黒い数値がでますよね？)
今後は分かりませんが、今のシェアなら“白”でしょう。

※ちなみに携帯の画面は“黒”の方が良いらしいという情報も…いやよそう俺勝手皆混乱。

目の健康で言えば、“黒”に軍配が上がります。
紙に慣れているため意外に思われるかもしれませんが、
モニターは光の三原色のルールが適用されるので“黒”の方が良いのです。

ただここには落とし穴があります。
“白”のサイトから“黒”のサイトへ移動した場合、もしくはその逆です。
急激な光度の変化は、決して目に良いとは言えません。

なので、
“使われる頻度の高いサイトに合わせる”という考えも発生するわけです。
例えばGoogleが“白”ベースなら、
それに合わせるという考えもあるわけだったりします。

さぁ、いよいよややこしくなってまいりました。
もうどっちがいいんだよ！？

ド○えもん～～～～～～～～～～～～～～～～～～～！！

きたぜ…ぬるりと…

というわけで、
ブログのアクセスカウントが1000を突破しました。

まだまだブログの閲覧数としては貧弱そのものですが、
この小さな一歩は、次の大きな一歩の布石になると信じています。

さて、このタイミングで知人に教えるべきか…
第一コメントが登場するまで待つべきか…
(くだらないこだわりなんて捨てればいいのに…というのは秘密。)

そんなわけで、
引き続き「めりくるくるりん」をよろしくお願いいたします。

あ、あれ？

風邪から復帰したら、
既にカルネージハートのクローズβテストが終了していました…そんな。

もっと長いかと思っていましたが、
あっという間でした。

次はオープンβテストのようなので、
今度はバリバリ組んだAIを動かすとしましょう。

あ、誰か誘った方がおもしろくなるかな？

正式版には近接兵装を！とっつきを！ブレードを！

リアルタイム検索が無くなった…

ぬりかべ経由から知ったのですが、
Googleのリアルタイム検索が無くなっていました。

あれには3月に随分助けられた記憶があります。
路線の情報を知るには最速だったからです。
(乗っている路線のWebサイトが応答不能だった…)

後はBloggerの不調のときもこいつで知ることができました。

「今みんなはどうなっているのかな？」

というのにリアルタイム検索は非常に便利だったのです。

その還元としてならTwitterを利用する価値も…と思いましたが、
リアルタイム検索が無くなったならしばらくは見送るとしましょう。

真偽値を使わない人たち

プログラマーの技量を見分けるひとつの判断材料として、

「真偽値を使わずに数値や文字列でフラグ管理する。」

というものがあるような気がします。

もちろん使わない人は技量が低い(と思われる)プログラマーです。

これは明らかに2値しか持たない真偽の判定を行う要素での話です。
なぜかこう実装してしまうんです。

データベースの設計でもそのようでして、
イレギュラーなデータがバンバン入り得る設計を生み出します。
真偽値 + NOT NULLで完全二値になる(はずな)のに…
(ちなみに大抵10桁前後の文字列型にされていることが多いです。なぜ？)

処理が集合の世界の話に限定されてより分かりやすいと思うのですが、
どうやらその集合を嫌っているらしいのです。
…いえ、集合という概念を知っているかどうかという段階からでしょうか？

そういう人たちって否定演算子も拒否反応があります。
愚直に論理積と論理和ばっかりで、0と1のオンパレードです。

さらに厄介なのは、
そういう人たちが作ったコーディング規約です。

典型的なシステムハンガリアン…っと思ったら真偽値が入ってない！
システムハンガリアンを強制する上に真偽型まで奪うのか！？

っと、ソースを修正していて感じました。

※例外として、
　　「真偽値を使わずにビットフィールドでフラグ管理する。」
　　なんて人たちがいます。
　　これは組み込み系のテクニックなので、全くの別問題です。


追記：やっぱりC言語からの移行に失敗した弊害なのでしょうか？
　　　　C99が普及しないのも、こういった人たちのせい？(真偽型はC99から)


さらに追記：バカは自分だ…なんだよ真偽型って…真偽値に修正しました。