徒歩通勤後のボルヴィックがひたすらうまい。
「高校で一番厳しかった校則」ねぇ。。。制服ナシだし、免許はどんどん取れだったし、、、だいたい生徒手帳とかなかったから、当時から校則なんか意識したことなかったような。
出社1時間にして500mlが空。追加500mlを買いにローソンへ。クーポン本があったので貰ってきたら、ボルヴィック500mlが30円引きになるクーポンが。次回は使おう。
買った。
昨日、モカ2錠飲んで効かなかったので、今日は机の引き出しに未開封なまま放置してあったフリスクにしてみた。カフェイン系とは違った刺激で結構効く。が、いっぺんに5〜6粒くらい口に入れるので、あっと言う間になくなってしまった。
切れてるならしばって直したいとこだ。
まさかこんなに簡単に行くとは!今年前半の自分も誉めてやりたい。これなら意外といいペースで進むかもしれない。がんばれば夏休み取れるかなぁ。。。よーし、じゃ、もうひとがんばり、、、はしないで、今日はもう帰ろう。
yoosee は、ジャンジャンブルのダブルチーズケーキも食べてみて欲しいな。ヨハンとは、また違った美味しさなので♪
ところで、ジャンジャンブルの公式サイトの予定はないんだろうか? 今なら ginganbre.jp も .com も .net も取得可能だけど。
なんかメールサーバが惨いことになってるようで。
それにしても、【FREECOMよりお知らせ】で、
【重要】メールサーバメンテナンス(2003年6月28日) 日時: 2003年6月28日(土) 8時30分〜22時00分 影響: メンテナンス期間中のメール送受信不可 ※※新システムへ変更する際に、メールサーバに保存されていた メールやWEB MAILのアドレス帳のデータ等が失われます。
なんて書いてある。さらに、「2003年6月28日(土) メールサーバメンテナンスに関する質問」に於いては、
メンテナンス期間中に、他社様より送信されたメールにつきましては、 FREECOMのメールサーバには到着致しません。
なんて書いてある。無料とは言え、プロバイダがこんなことで良いんだろうか。。。
au の技術情報サイトにある「端末別情報一覧」には、同じ EZweb 同盟(?)として、Tu-Ka の端末も載っている。で、適当に流し見していて気が付いた。Tu-Ka って、XHTML 対応というか WAP2.0 の端末が1台も出てないんだな。
今後、EZweb 系って XHTML に移行するもんだと思ってたんだけど、Tu-Ka はどうするんだろう? EZweb サーバで行われる HDML → HTML HTML → HDMLコンバートも完全じゃない(特に入力フォームは厳しい)のに。
まぁ、Tu-Ka は「きちんと話せてメールができれば十分だという結論に達した」らしいので、Web コンテンツはどーでもいいのかも(笑)
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
ひさびさに秋葉原の丸五(まるご)に行った。数年ぶりかな。行く前に営業時間を調べようと検索してて知ったのだが、昨年末から今年の4月まで改装していたそうで。食べたくなったときにオープンしていてくれて良かったよ。
実際行ってみて、改装後の建物を目にしたとき、あのボロ家風情ある建物の方が良かったなぁと思ったけど、中に入ってみれば昔と同じレイアウトでなんか安心した。
頼んだのは特ヒレカツ+食事セット。秋葉原に勤めていた若かりし頃は高嶺(高値?)の花だったけど、オトナになったのでフツーに食えるようになった(笑)
肉がうまいのはもちろんのこと、ちょっとだけシソが混ざっているキャベツのサッパリさとか、赤出しのみそ汁、キュウリの漬け物など、どれもオレの味覚にあっていて満足。食前に出てくるのは緑茶だけど、食後に出てくるジャスミン茶ってのも気が利いている。ジャスミン茶が、ちょっと油っぽくなった口をリセットしてくれるのだ。
あぁ、やっぱりトンカツと言えばココだなぁ。幸せ。
コンビニでレジに並んでいたら「ハードな仕事の疲れに」というコピーに目がいって、つい栄養ドリンクを買ってしまった。タウリン3000mgだ! まずかったけど。。。
こちらもコンビニで見つけた「Aya Sweets Dessert ライチミルク」。これはうまい。
バニラの甘さとライチのフルーティな感じが見事にマッチしている。もともとライチ好きなので評価が寄っている可能性はあるけど、これは(無くなっちゃう前に)リピートしたい。
今日もウォーキングに。いつもは歩行スピードを 4.0 〜 4.2 くらいにしているんだけど、そろそろ上げてみるか?と思って、今日は 5.0 にしてみた。単位は km/h なのかな、きっと。
最初のうちは調子良かったものの、マシンの角度が 7.0 とか 9.0 になると、結構心拍数が上がって、160くらいまでいったり。
前にトレーナーの人には「130〜135くらいで推移すると良い」みたいなことを聞いてたけど、全然当てはまらない。まぁ、それでもマシンの角度は自動的に変わって、キツイ坂の後には緩やかになるので、そこで深呼吸を繰り返して心拍数を戻す努力をしたりして。
結局、5.0 のスピードで60分歩き通したんだけど、半袖Tシャツの袖の下からも汗が滴るほどの汗だくに。もうTシャツのどこもかしこも汗を吸い取らない状態になっていた(笑)
ちょっとまだ毎回 5.0 だとキツイかなぁ。まぁ、様子を見ながら、いま最適な「ちょっと負荷のかかるポイント」を探っていこう。
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 対象から外しちゃえばいいという手法で逃げられそうな気がするけど。デフォルト値を入れられない感じのデータ場合の需要がオレの他にもあるんだろうか。。。
Before...
▽ ゆうすけ [なんか、コッチで話が展開しているし。(笑)中学のときは髪の長さとか学ランにカラーつけろとかいろいろしょうもないことを..]
▽ はづき [校則?なにそれ?という高校時代でした。無秩序な学校だったよなあ・・・]
▽ すずき [ま、まさか、はづきさん、超ロングスカートにカミソリとかってファッションだったんじゃ。。。(笑)]
▽ はづき [あー、長いスカートはトレンドでしたねえ(笑)当然男子は短ラン・中ランね。]
▽ ケーコ [校則ゼロのバカ高でした(笑)男子は短ラン・ボンタン当たり前で短ラン短すぎて裾から原色シャツがはみだしてるし髪型はトサ..]