雑文発散

«前の日(07-22) 最新 次の日(07-24)» 追記
過去の日記

2002-07-23 暑い日は続くよ火曜日

うまい

徒歩通勤後のボルヴィックがひたすらうまい。

校則

「高校で一番厳しかった校則」ねぇ。。。制服ナシだし、免許はどんどん取れだったし、、、だいたい生徒手帳とかなかったから、当時から校則なんか意識したことなかったような。

うますぎて

出社1時間にして500mlが空。追加500mlを買いにローソンへ。クーポン本があったので貰ってきたら、ボルヴィック500mlが30円引きになるクーポンが。次回は使おう。

アレ

買った。

買うと言えば

会社の椅子を新調してくれるらしい。そこで「アーロンチェアがいい!」と言ったら却下された(泣)

眠気覚まし

昨日、モカ2錠飲んで効かなかったので、今日は机の引き出しに未開封なまま放置してあったフリスクにしてみた。カフェイン系とは違った刺激で結構効く。が、いっぺんに5〜6粒くらい口に入れるので、あっと言う間になくなってしまった。

糸が

切れてるならしばって直したいとこだ。

おぉ!

まさかこんなに簡単に行くとは!今年前半の自分も誉めてやりたい。これなら意外といいペースで進むかもしれない。がんばれば夏休み取れるかなぁ。。。よーし、じゃ、もうひとがんばり、、、はしないで、今日はもう帰ろう。

本日のツッコミ(全14件) [ツッコミを入れる]

Before...

ゆうすけ [なんか、コッチで話が展開しているし。(笑)中学のときは髪の長さとか学ランにカラーつけろとかいろいろしょうもないことを..]

はづき [校則?なにそれ?という高校時代でした。無秩序な学校だったよなあ・・・]

すずき [ま、まさか、はづきさん、超ロングスカートにカミソリとかってファッションだったんじゃ。。。(笑)]

はづき [あー、長いスカートはトレンドでしたねえ(笑)当然男子は短ラン・中ランね。]

ケーコ [校則ゼロのバカ高でした(笑)男子は短ラン・ボンタン当たり前で短ラン短すぎて裾から原色シャツがはみだしてるし髪型はトサ..]


2003-07-23 眠気に負けそう、水曜日

チーズケーキ

yoosee は、ジャンジャンブルのダブルチーズケーキも食べてみて欲しいな。ヨハンとは、また違った美味しさなので♪

ところで、ジャンジャンブルの公式サイトの予定はないんだろうか? 今なら ginganbre.jp も .com も .net も取得可能だけど。

freecom.ne.jp

なんかメールサーバが惨いことになってるようで。

それにしても、【FREECOMよりお知らせ】で、

【重要】メールサーバメンテナンス(2003年6月28日)
  
日時: 2003年6月28日(土) 8時30分〜22時00分
影響: メンテナンス期間中のメール送受信不可 
  
※※新システムへ変更する際に、メールサーバに保存されていた
メールやWEB MAILのアドレス帳のデータ等が失われます。

なんて書いてある。さらに、「2003年6月28日(土) メールサーバメンテナンスに関する質問」に於いては、

メンテナンス期間中に、他社様より送信されたメールにつきましては、
FREECOMのメールサーバには到着致しません。

なんて書いてある。無料とは言え、プロバイダがこんなことで良いんだろうか。。。

best / クラムボン

ポチった。

Tu-Ka の EZweb

au の技術情報サイトにある「端末別情報一覧」には、同じ EZweb 同盟(?)として、Tu-Ka の端末も載っている。で、適当に流し見していて気が付いた。Tu-Ka って、XHTML 対応というか WAP2.0 の端末が1台も出てないんだな。

今後、EZweb 系って XHTML に移行するもんだと思ってたんだけど、Tu-Ka はどうするんだろう? EZweb サーバで行われる HDML → HTML HTML → HDMLコンバートも完全じゃない(特に入力フォームは厳しい)のに。

まぁ、Tu-Ka は「きちんと話せてメールができれば十分だという結論に達した」らしいので、Web コンテンツはどーでもいいのかも(笑)

本日のツッコミ(全6件) [ツッコミを入れる]

Before...

すずき [えー!、もしかして辞めちゃう可能性があるの!?>ジャンジャンブル]

ウラウラ [んんん、可能性が無いとは言えないってことだよ。諸行無常。]

すずき [あー、ビツクリした。そーゆーことか。]

AG [>HDML → HTML コンバート 逆っしょ? もう嫌になるぐらい泣かされましたが、大体癖はつかめたなり。てか、マ..]

すずき [おー、逆。修正しときます。]


2004-07-23

[] MS、スパム対策技術「Sender ID」をHotmailなどに導入へ

10月1日までに Hotmail や MSN 宛のメールに対し、Sender ID を用いた送信元認証を開始するとのこと。送信側に対して、9月半ばまでに必要な設定を済ますように呼びかけているそうだ。

設定しなかった場合については、次のように言っている。

この照合プロセスを通過しなかったメッセージは「拒否」されることはないが、さらなる検査とフィルタリングが行なわれる

ということは、Sender ID を適切に設定しておけば、システム側でフィルタリングしないってことなのだろうか?

例えば、example.com を持っている spam 屋が、From: spam@example.com というアドレスを使って、第三者中継を許している 192.168.0.1 というメールサーバを踏み台にして送信して来たとする。

このとき、example.com を管理している DNS の SPF レコードに 192.168.0.1 を加えてしまえば、本来は spam 屋の持ち物ではないメールサーバなのに、Sender ID の仕組み上は example.com の持ち物として認識されてしまうのではないだろうか?

となると、結局、フィルタリングが依然として必要となる気がするのだけれど。Sender ID の資料をまだ良く読んでないので、認識が間違ってる可能性はある。

http://www.itmedia.co.jp/news/articles/0407/23/news054.html


2006-07-23

[] とんかつ丸五

ひさびさに秋葉原の丸五(まるご)に行った。数年ぶりかな。行く前に営業時間を調べようと検索してて知ったのだが、昨年末から今年の4月まで改装していたそうで。食べたくなったときにオープンしていてくれて良かったよ。

実際行ってみて、改装後の建物を目にしたとき、あのボロ家風情ある建物の方が良かったなぁと思ったけど、中に入ってみれば昔と同じレイアウトでなんか安心した。

丸五 ヒレ

頼んだのは特ヒレカツ+食事セット。秋葉原に勤めていた若かりし頃は高嶺(高値?)の花だったけど、オトナになったのでフツーに食えるようになった(笑)

肉がうまいのはもちろんのこと、ちょっとだけシソが混ざっているキャベツのサッパリさとか、赤出しのみそ汁、キュウリの漬け物など、どれもオレの味覚にあっていて満足。食前に出てくるのは緑茶だけど、食後に出てくるジャスミン茶ってのも気が利いている。ジャスミン茶が、ちょっと油っぽくなった口をリセットしてくれるのだ。

あぁ、やっぱりトンカツと言えばココだなぁ。幸せ。


2007-07-23

[] ハードな仕事の疲れに

コンビニでレジに並んでいたら「ハードな仕事の疲れに」というコピーに目がいって、つい栄養ドリンクを買ってしまった。タウリン3000mgだ! まずかったけど。。。

[] はてブで「これはうまい」タグを付けたいアイスクリーム

こちらもコンビニで見つけた「Aya Sweets Dessert ライチミルク」。これはうまい。

バニラの甘さとライチのフルーティな感じが見事にマッチしている。もともとライチ好きなので評価が寄っている可能性はあるけど、これは(無くなっちゃう前に)リピートしたい。


2008-07-23

[] 野外料理入門

夏キャンプの日程が決まったので、妙にウキウキしている本日なのだ。「GIANT KILLING 6」を買いに書店へ行ったついでにアウトドア系の書棚を見ていたら、ちょっと気になったので買ってしまった。

野外料理入門―あなたの外ごはんを革命する!

いつも料理担当をしてくれているメンバーが参加できなくなってしまったので、ちょっと手伝おうかなというのもある。「ust 配信担当者が足りないので手伝おう」というのと同じ論理だね(笑)


2014-07-23

[] ウォーキングでスピードを 5.0 にしたら、過去最高の汗だくに

今日もウォーキングに。いつもは歩行スピードを 4.0 〜 4.2 くらいにしているんだけど、そろそろ上げてみるか?と思って、今日は 5.0 にしてみた。単位は km/h なのかな、きっと。

最初のうちは調子良かったものの、マシンの角度が 7.0 とか 9.0 になると、結構心拍数が上がって、160くらいまでいったり。

前にトレーナーの人には「130〜135くらいで推移すると良い」みたいなことを聞いてたけど、全然当てはまらない。まぁ、それでもマシンの角度は自動的に変わって、キツイ坂の後には緩やかになるので、そこで深呼吸を繰り返して心拍数を戻す努力をしたりして。

結局、5.0 のスピードで60分歩き通したんだけど、半袖Tシャツの袖の下からも汗が滴るほどの汗だくに。もうTシャツのどこもかしこも汗を吸い取らない状態になっていた(笑)

ちょっとまだ毎回 5.0 だとキツイかなぁ。まぁ、様子を見ながら、いま最適な「ちょっと負荷のかかるポイント」を探っていこう。


2015-07-23

[Embulk] embulk-output-mysql の merge モードの挙動をしりたくてソースコードを眺めてみたりしていた

embulk-output-mysql プラグインには、MySQL へのインポート時のモード設定がある。現状だと insert, insert_direct, truncate_insert, merge, merge_direct, replace の6種類。

いま使いたい動作だと、merge もしくは merge_direct の挙動が近そうだったのだけど、ちょっとだけやりたいこととマッチしない部分があった。

例えば、こんなテーブルがあるとする(適当にいま考えた)。

CREATE TABLE ramen (
  id   BIGINT AUTO_INCREMENT,
  name VARCHAR(100) NOT NULL,
  location VARCHAR(100),
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  PRIMARY KEY (id),
  UNIQUE INDEX name_idx (name)
);

現在はこんな感じのデータが入っている状態だとする。

id name location created_at updated_at
1 しじみラーメン和歌山 北海道 2015-07-18 2015-07-18

このテーブルへ新しいデータとして、こんなデータをブチこみたい。「しじみラーメン和歌山」の location が間違っていた(北海道じゃなくて青森が正しい)のに気がついたので、修正が入っているんだよ。

name location created_at updated_at
しじみラーメン和歌山 青森 2015-07-19 2015-07-19
中華のカトウ 新潟 2015-07-20 2015-07-20
坂新 福島 2015-07-20 2015-07-20

これを embulk-output-mysql の merge / merge_direct モードで入れると、こんな感じになる。ちゃんと「しじみラーメン和歌山」が「青森」に変わっている。でも、本当は更新したくなかった created_at の日付まで更新されちゃっている。この created_at を更新対象から外せないかなぁというのが今回の悩みポイント。

id name location created_at updated_at
1 しじみラーメン和歌山 青森 2015-07-19 2015-07-19
2 中華のカトウ 新潟 2015-07-20 2015-07-20
3 坂新 福島 2015-07-20 2015-07-20

merge_direct モードで発行されるクエリは、抜粋するとこんな感じになる。実際にはプリペアドステートメントを作成した後でパラメータを設定してガシガシ回しているみたいだし、このクエリがそのまま発行されている訳ではない。

INSERT INTO ramen (
  name,
  location,
  created_at,
  updated_at)
VALUES (
  'しじみラーメン和歌山',
  '青森',
  '2015-07-19',
  '2015-07-19' )
ON DUPLICATE KEY UPDATE
  name = VALUES(name),
  location = VALUES(location),
  created_at = VALUES(created_at),
  updated_at = VALUES(updated_at)
;

このクエリを次のように書き換えられれば、この悩みは解決しそうな気がする。ON DUPLICATE KEY UPDATE の後ろにあった created_at = VALUES(created_at) を取り除いた感じ。

INSERT INTO ramen (
  name,
  location,
  created_at,
  updated_at)
VALUES (
  'しじみラーメン和歌山',
  '青森',
  '2015-07-19',
  '2015-07-19' )
ON DUPLICATE KEY UPDATE
  name = VALUES(name),
  location = VALUES(location),
  updated_at = VALUES(updated_at)
;

この ON DUPLICATE KEY UPDATE あたりの構文は embulk-output-mysql プラグインのこの辺りで組み立てられているのは把握できた。

for (int i=0; i < toTableSchema.getCount(); i++) {
    if(i != 0) { sb.append(", "); }
    String columnName = quoteIdentifierString(toTableSchema.getColumnName(i));
    sb.append(columnName).append(" = VALUES(").append(columnName).append(")");
}

一方で、なにやら mergeKeys という変数が渡されているいることにも気が付いた。

@Override
protected String buildPreparedMergeSql(String toTable, JdbcSchema toTableSchema, List<String> mergeKeys) throws SQLException

現在はドキュメントに書かれていないのだけど、これは、Embulk の config で次のように指定するもののようだ。

out:
  type: mysql
  [snip]
  merge_keys:
    - name
    - location

このリストを使って、ON DUPLICATE KEY UPDATE の対象カラムを指定することができるんじゃないか?と思って、手元でちょっと修正してみたら、それっぽく動くことは動いた。

ただ、embulk-output-postgresql の中での使われ方を見ると、どうもマージ対象を絞り込むためのキーとして使うものみたいだったし、用途が違っている気がする。名前が mergeKeys ってところで気がつけよって話だけど。

mergeKeys 以外に updateColumns みたいなリストを新たに渡すために Config 項目を増やして、それを buildPreparedMergeSql() に渡すように修正して、、、という感じで修正すれば実現可能な気がするんだけど、Java 歴が数ヶ月、Embulk 歴が3日の状態だといろいろ悩んでしまって、なかなか先に進まない。

あと、merge モードのときに UPDATE 対象のカラムが限定できる機能って一般的に欲しいものなのだろうか(オレはいま欲しいんだけど)。

この例だと created_at が気になるだけなので、こいつにデフォルト値を設定しておいて、INSERT / UPDATE 対象から外しちゃえばいいという手法で逃げられそうな気がするけど。デフォルト値を入れられない感じのデータ場合の需要がオレの他にもあるんだろうか。。。


2016-07-23

[] 内出血の治療のつもりで長湯

再発した単純性紫斑病と、それに伴ってか一部炎症が発生してしまっていて、歩くときに若干痛みを感じていたので、今日は完全休養。斑点が増える勢いはおさまったようなのだけど、まだ目立っている。

斑点が内出血した後ならば、血行を良くすれば回復するのでは?という考えで、普段はシャワーで済ますところ、昨夜も今朝も湯船にお湯を張って、足を温めてみた。Kindle アプリで未読コミックを読みながらの長湯。

それ以外は、特に外出もせずにダラダラ過ごした。治りを良くするため、安静にするという名目で。