が近所で開始されたので体験しに行ってみました。
手にもつタイプのバーコードリーダーがどうにも反応しないので、
据え置きタイプの方で読みとりしました。
べ、弁当ひっくりかえさないと読み込んでくれない…
どっちも使い方覚えたら早そうね~
でも開始直後らしく、
店員さんが説明に右往左往して人によっては遅い遅い。
将来的にはレジの行列が減ってくれるの…かな?
いや、それ以前に不正で潰れないといいんだけど…
追記:案外、不正はないらしいですね。
でも…、お惣菜とかの割引に対応していないのが一番痛い…
その度に店員さんが来ないといけないんじゃ本末転倒でしょう?
2011年7月31日日曜日
2011年7月29日金曜日
内藤を呼ぶ店
某カレー店と某アニメのタイアップポスターに、
草を生やされてしまいました。
あの駄コラはないわ~
とりあえず貼り付けたって感じにしか見えないわ~
そして何のキャンペーンも始まっている気配もないわ~
もしかして、
狐か狸に化かされた?
上手に焼け…なかった
賞味期限をちょっと過ぎたベーコンを安全に食べようと、
カリカリになるまでフライパンに炒めることにしました。
じゅわ~
じゅわ~じゅわ~
じゅ~じゅ~
じゅ…ぅ…(火を止める)
…(お皿に移す)
……(凝視)
………何かスナック菓子みたいな状態になりました。
夜食替わりにパクっ………
…まずい!
ほとんどコゲじゃないか!?
思ったより繊細な調整が必要なようです。
あ~なんか干し肉を作りたくなりました。
カリカリになるまでフライパンに炒めることにしました。
じゅわ~
じゅわ~じゅわ~
じゅ~じゅ~
じゅ…ぅ…(火を止める)
夜食替わりにパクっ………
…まずい!
ほとんどコゲじゃないか!?
思ったより繊細な調整が必要なようです。
あ~なんか干し肉を作りたくなりました。
2011年7月28日木曜日
Pixiv騒動ねぇ~
結局まだPixivには1枚も絵を投稿していなかったのですが、
そんな合間に何やら騒動が起こってしまいました。
そこまでメインコンテンツにする予定はないのですが、
今の状況で絵を投稿するのはちょっと気が引けますね。
気分はチラシの裏なんですが、
チラシが燃えそうなのに色々描くのは…って感じ?
ちょっと静観することにします。
あ、Gravatar用のアイコンは例外とします。
そんな合間に何やら騒動が起こってしまいました。
そこまでメインコンテンツにする予定はないのですが、
今の状況で絵を投稿するのはちょっと気が引けますね。
気分はチラシの裏なんですが、
チラシが燃えそうなのに色々描くのは…って感じ?
ちょっと静観することにします。
あ、Gravatar用のアイコンは例外とします。
2011年7月27日水曜日
IDE vs emacs
タイトルの通りではあるんですが、
お恥ずかしながらemacsは軽く触ったことしかありません。
なので、
普段IDE(つ~かeclipse)を使っている身から見て、
何が入っていればemacsに魅力を感じるのか妄想してみました。
(拡張性の高さとかは十分聞き及んでいるので、emacsの勝ちだと思ってます。
さすがにちょっとした問題でプラグインを直すのは手間すぎですからね~)
最初に挙がるのは何と言っても“インテリセンス”です。
というかコーディングの大半はこれの恩恵の基に成り立っています。
言語標準、自身のソース、参照しているライブラリなど…
ドキュメント単体に含められない情報が数多くあります。
まあ自分が使っているフォルダ構成から憶測するように拡張するでしょうけど…
拡張前提な予感がしているのがためらっている理由かな?
(使ってもいないから分かるわけないんですけどね~)
次は“インデント”とかの仕組みでしょうか?
これはむしろemacsなら自分の好みにできていい感じなんでしょうね~
と言っても、IDE標準で大体間に合っている不具合。
いや、K&RをBSD/オールマンに変えたいのはありますけど、
仕事がK&Rスタイルだからな…
後はなんでしょう?
あ~デバッグ機能という重要なものを忘れていました。
と言っても、コンパイルの実行をショートカットに挟めば終わりかね?
個人的にはeclipseのconsoleウインドウが好きなので、
あれが再現できたら問題ないかな~って思ってます。
結論、拡張すればemacsはすごそうだけど、
拡張しないと宝の持ち腐れです。
よってLISPは習得すべき、そうすべき。
(人力検索はてなの回答者と同じ結論に…※自分は質問者じゃないですよ。)
お恥ずかしながらemacsは軽く触ったことしかありません。
なので、
普段IDE(つ~かeclipse)を使っている身から見て、
何が入っていればemacsに魅力を感じるのか妄想してみました。
(拡張性の高さとかは十分聞き及んでいるので、emacsの勝ちだと思ってます。
さすがにちょっとした問題でプラグインを直すのは手間すぎですからね~)
最初に挙がるのは何と言っても“インテリセンス”です。
というかコーディングの大半はこれの恩恵の基に成り立っています。
言語標準、自身のソース、参照しているライブラリなど…
ドキュメント単体に含められない情報が数多くあります。
まあ自分が使っているフォルダ構成から憶測するように拡張するでしょうけど…
拡張前提な予感がしているのがためらっている理由かな?
(使ってもいないから分かるわけないんですけどね~)
次は“インデント”とかの仕組みでしょうか?
これはむしろemacsなら自分の好みにできていい感じなんでしょうね~
と言っても、IDE標準で大体間に合っている不具合。
いや、K&RをBSD/オールマンに変えたいのはありますけど、
仕事がK&Rスタイルだからな…
後はなんでしょう?
あ~デバッグ機能という重要なものを忘れていました。
と言っても、コンパイルの実行をショートカットに挟めば終わりかね?
個人的にはeclipseのconsoleウインドウが好きなので、
あれが再現できたら問題ないかな~って思ってます。
結論、拡張すればemacsはすごそうだけど、
拡張しないと宝の持ち腐れです。
よってLISPは習得すべき、そうすべき。
(人力検索はてなの回答者と同じ結論に…※自分は質問者じゃないですよ。)
2011年7月26日火曜日
フレームワークの独立記念日
shot6さんが紹介している、
[Java]JBoss Tattletaleを使って依存関係を調べよう
に関連したお話です。
JBoss Tattletaleでjarファイルの依存関係を追えますよって内容です。
う~ん、ここまでできるんなら、
必要なクラスだけかき集めてバイナリ化できないかと妄想してしまいます。
(Java標準クラスへのリフレクションによる参照は犠牲になるでしょうが…)
と言っても、Javaならそこまで欲しくはないんですけどね。
本当に欲しいのは.NET Frameworkについてです。
こっちは冗談抜きで欲しい機能です。
バージョンごとに独立しやがって…
同じ製品で紛争でもしているかと思いました。
そのたびにフレームワークのインストール…
ユーザーが許せるのはせいぜい1回が限度ではないでしょうか?
そんなアップデートを繰り返そうというのであれば、
必要なクラスを抽出してバイナリにして欲しいってわけです。
(.NET標準クラスへのリフレクションによる参照は犠牲になるでしょうが…)
それが叶ったとき、フレームワークは真の独立を迎えるのだ~!!
………Window7は標準でインストールされているって?
悪かったよ!自分はXPだよ!
そんな愚痴。
[Java]JBoss Tattletaleを使って依存関係を調べよう
に関連したお話です。
JBoss Tattletaleでjarファイルの依存関係を追えますよって内容です。
う~ん、ここまでできるんなら、
必要なクラスだけかき集めてバイナリ化できないかと妄想してしまいます。
(Java標準クラスへのリフレクションによる参照は犠牲になるでしょうが…)
と言っても、Javaならそこまで欲しくはないんですけどね。
本当に欲しいのは.NET Frameworkについてです。
こっちは冗談抜きで欲しい機能です。
バージョンごとに独立しやがって…
同じ製品で紛争でもしているかと思いました。
そのたびにフレームワークのインストール…
ユーザーが許せるのはせいぜい1回が限度ではないでしょうか?
そんなアップデートを繰り返そうというのであれば、
必要なクラスを抽出してバイナリにして欲しいってわけです。
(.NET標準クラスへのリフレクションによる参照は犠牲になるでしょうが…)
それが叶ったとき、フレームワークは真の独立を迎えるのだ~!!
………Window7は標準でインストールされているって?
悪かったよ!自分はXPだよ!
そんな愚痴。
2011年7月22日金曜日
強制ログローテート
t-katochinさんが開発したlog4jの拡張アペンダをさらに拡張してみました。
[log4j] いいとこどりAppender
名前は「org.mericle.log4j.ForcedDailyRollingFileAppender」です。
どんな拡張かというと、
ログローテートを*必ず*実行する機能です。
例えばバッチ処理でログに加工を行う場合、
バッチが動作するまでにログローテートが行われている必要があります。
ですが今までのアペンダには、
ログローテートのタイミングは*最初の*ログ出力時という問題があります。
日次でローテートを行い、
バッチ処理が0時05分だったとしましょう。
もしも0時丁度から0時05分までにログが出力されなかったとき、
その日のバッチ処理が行えないことになってしまいます。
今まではそうした要件がある場合、
ログローテートのためにログ出力を行うことで対応していました。
ただそのためだけに、
別のバッチ処理が発生することになってしまいます。
また、ローテート用のあまり意味のないログが出力されることにもなります。
要件次第ではこれが許されないことがあります。
同じことを要求される案件が3つ目を迎えたとき、
このアペンダの作成を決意しました。
このアペンダは日次なら0時丁度にログローテートされます。
分次、週次、月次、年次にも(理論上は)対応している憎いやつです。
スレッド処理があるので不安がありますが、
JMeterでの10万回試験では問題は見つかっていません。
…きっと大丈夫!
同じ悩みを抱えたマイノリティな仲間がいましたら、
その助けになることを祈ります。
○バイナリ
log4j-extention-1.21.jar
※JDK6でコンパイルしています。
○ソース
log4j-extention-1.21-sources.jar
※Seasarファウンデーションソフトウェアライセンスに従ってください。
※2011-07-26追記:ちょっとコメントを直しました。
※2011-11-30追記:ローリング→ローテートに変更。なぜかこう言ってしまう…あ、アペンダ名か!
[log4j] いいとこどりAppender
名前は「org.mericle.log4j.ForcedDailyRollingFileAppender」です。
どんな拡張かというと、
ログローテートを*必ず*実行する機能です。
例えばバッチ処理でログに加工を行う場合、
バッチが動作するまでにログローテートが行われている必要があります。
ですが今までのアペンダには、
ログローテートのタイミングは*最初の*ログ出力時という問題があります。
日次でローテートを行い、
バッチ処理が0時05分だったとしましょう。
もしも0時丁度から0時05分までにログが出力されなかったとき、
その日のバッチ処理が行えないことになってしまいます。
今まではそうした要件がある場合、
ログローテートのためにログ出力を行うことで対応していました。
ただそのためだけに、
別のバッチ処理が発生することになってしまいます。
また、ローテート用のあまり意味のないログが出力されることにもなります。
要件次第ではこれが許されないことがあります。
同じことを要求される案件が3つ目を迎えたとき、
このアペンダの作成を決意しました。
このアペンダは日次なら0時丁度にログローテートされます。
分次、週次、月次、年次にも(理論上は)対応している憎いやつです。
スレッド処理があるので不安がありますが、
JMeterでの10万回試験では問題は見つかっていません。
…きっと大丈夫!
同じ悩みを抱えたマイノリティな仲間がいましたら、
その助けになることを祈ります。
○バイナリ
log4j-extention-1.21.jar
※JDK6でコンパイルしています。
○ソース
log4j-extention-1.21-sources.jar
※Seasarファウンデーションソフトウェアライセンスに従ってください。
※2011-07-26追記:ちょっとコメントを直しました。
※2011-11-30追記:ローリング→ローテートに変更。なぜかこう言ってしまう…あ、アペンダ名か!
2011年7月21日木曜日
ボタンは押す?クリックする?
Microsoft日本語スタイルガイドによると、
「[ボタン名]ボタンをクリックしてください。」
という表現を使うように推奨されています。
…ですが本当にこれで良いのでしょうか?
「[ボタン名]ボタンをクリックしてください。」
という表現を使うように推奨されています。
…ですが本当にこれで良いのでしょうか?
「[ボタン名]ボタンを押してください。」
が正しいのではないでしょうか?
というのが本日の内容です。
「本当にすごいこと」でも似たようなことを言いましたが、
ユーザーの敷居ハードルを下げる代わりに、
成長する可能性を阻害している表現ではないかと思うからです。
なぜならGUIのボタンを*押す*手段は、
クリック以外にもあるからです。
選択中であればエンターキーを押せば*押した*ことになりますし、
タッチパネルなら表示されたボタンをタッチしたことで*押した*ことになります。
ボタンによってはショートカットキーがあるかもしれません。
こんなことを考える可能性を、
無意識のうちに奪ってしまっていやしないでしょうか?
常識的に考えて、
ボタンはクリックするものではありません。
*押す*ものです。
クリックを手段、*押す*を目的だとすると、
手段だけ教えて目的を教えていないようなものです。
自分はそこに違和感を感じているのだと思います。
これは、自分だけでしょうか?
簡単に言いたいことをまとめ…いや、言い換えます。
これはユーザーインターフェースの理解を妨げる一端だと考えています。
GUIの各部品は、現実世界のメタファー(比喩)なのです。
コンピューター上にある部品を操作するための手段として、
マウス、キーボードのような各種操作デバイスがあるのです。
今後はより操作も多様化し、
複雑になっていくことでしょう。
それこそ、クリックという表現が古いものになるかもしれません。
(実際にそうなるかは別ですよ?)
だからこそ!
マニュアルの表現であっても!
本質を突いた表現にするべきではないでしょうか!?
…という理想論。
ながながとした長文を読んでいただき、
ありがとうございました。
追記:スマートフォンの場合はクリックではなくタップになるわけで、
やっぱりメタファーとしての動詞で表現するべき…だよねぇ?
追記:スマートフォンの場合はクリックではなくタップになるわけで、
やっぱりメタファーとしての動詞で表現するべき…だよねぇ?
2011年7月20日水曜日
Anonymousを翻訳しよう
最近ニュース記事を読むと、
ハッカー集団Anonymousなんて言葉が頻繁に登場します。
カタカナ表記もありますが、
アルファベットの表記が多いように感じます。
さて、今回はこのAnonymousを翻訳しようというお話です。
まずAnonymousは4chanのデフォルト名を指しています。
というかそのものです。
4chanは日本のふたば☆ちゃんねるを目指して立ち上げられました。
でしたら翻訳にはふたば☆ちゃんねるにおけるAnonymousを採用するべきです。
ハッカー集団Anonymousなんて言葉が頻繁に登場します。
カタカナ表記もありますが、
アルファベットの表記が多いように感じます。
さて、今回はこのAnonymousを翻訳しようというお話です。
まずAnonymousは4chanのデフォルト名を指しています。
というかそのものです。
4chanは日本のふたば☆ちゃんねるを目指して立ち上げられました。
でしたら翻訳にはふたば☆ちゃんねるにおけるAnonymousを採用するべきです。
- ハッカー集団名無し
- ハッカー集団としあき
- ハッカー集団「」
が候補でしょうか?
これからAnonymous関連のニュースを読んだら、
いずれかの翻訳に脳内変換してみてください。
普段と違った感想を抱くかも?
2011年7月19日火曜日
台風の来る季節
外を見るともう真っ暗…
(いや、もう夜だからか?)
昔は台風が来ると、
何か熱いものが込み上げてきたように感じます。
今はそんなこともなく、
「ふ~ん」で一蹴されてしまう程度です。
まだ雪だと補正がかかるのですが…
希少度の違い?
どうでもいいか、
それより台風対策です。
何をするかって?
会社に行けなくなった場合の連絡先ですよ…
(いや、もう夜だからか?)
昔は台風が来ると、
何か熱いものが込み上げてきたように感じます。
今はそんなこともなく、
「ふ~ん」で一蹴されてしまう程度です。
まだ雪だと補正がかかるのですが…
希少度の違い?
どうでもいいか、
それより台風対策です。
何をするかって?
会社に行けなくなった場合の連絡先ですよ…
登録:
投稿 (Atom)