今日の振り返り
はてな記法がURLのリンクを指定したとき、宛先のタイトルを表示できることを知った
知らなかった。
[http://hatenadiary.g.hatena.ne.jp/keyword:title]
こういう風に書くと、ちゃんとタイトルをリンクテキストに取るんだね〜
はてなダイアリーのヘルプのキーワード一覧 - はてなダイアリーのヘルプ
今までずっとわざわざタイトルを手でコピペしていたけど今後は活用しよう☆
livedoor Readerの画面からクリップを付けられることも知った
これも知らなかった。
記事のタイトルの隣にクリップのアイコンがあって、そこからlivedoorクリップの入力フォームが開ける。
何か、こういうのは知らなかったことを嘆くんじゃなくて、今日知ることができたことを喜ぶべきだよね！
今日の振り返り
仕事のこと
今日は全然タスクを消化できなかった。
正直仕事をしていなかったんじゃないかな？
う〜ん、でもそんなことない気がする。
そういえばテストを書いたし、チケットの整理もしたし、レビューもやった。
いやぁでも今日一番ダメだったのは、毎日職場に持っていくノートを持って行かなかったことだね。
僕はノートに今日やったことと、明日やるべきことをつけることにしているんだけど、
そのノートが手元にないとどうにもならない。
(でも紙のノートをインターネット上のサービスに置き換えるのは僕的にはありえない選択なの…)
他人にお願いするのも頻度を踏まえてやらないと自分が腐る
この間、何でも自分でやろうとしない: 他人にお願いする勇気ということを言った。
簡単な作業であっても一度に沢山やろうとすると終わらないし、 チケットを先送りにして残し続けるのはとても悪いことなので、 そういうものは他の人にお願いしてしまうべきなんだと思うようになった。
確かにこれはそうだと思う。
でも、これに味をしめて何でも他人にやらせようと無意識のうちになってしまったらおしまいだ。
最近、友達の仕事をちょっと手伝っているけど、その中で友達に何でも作業を押し付ける人がいて、
その人を見ていてこう思った。
自分から行動を起こさないし、自分に仕事が回りそうになるとまず他人に押し付けることを考えることから始めるし、
それでいて他人の作業成果に責任を持とうとしない。
これは腐っている。
これではだめだ。
なぜ僕が毎日ブログをつけることにしたか
内容がどれだけ他人に価値のあるものかとか、いい記事を書いているかっていうことは除外して、
まず毎日ブログをつけようと僕はこの間決めた。
理由は、毎日何かに取り組む姿勢を保つためのペースメーカーにしようと思ったからだ。
Twitterで適当につぶやいているだけだと、怠けていてもあまり気にならない。
何か、「後で本気出す」とか言っていつも先送りにしてしまいがちな自分自身に警告を出そうと思わない。
でも、ブログで毎日「今日の振り返り」を最低限やっておくと、
取り組もうと決めていたことに取り組んでいない事実を気にせざるを得ない。
自制心を保つための道具としてブログを毎日つけることには意味がある。
ある程度まとまりのある内容を書けるときは単独の記事として僕はブログをつけている。
でも、単独の記事にできないまでも、何かしら毎日学んでいること・気づいたことはあるのだ。
それらを記録に残し、振り返る為に「今日の振り返り」という記事だけでも毎日つけるのは意味がある。
あと、単純に、Twitterに自分の怠慢を嘆くつぶやきを毎日大量に垂れ流すと、普通に「うざい」。
だからブログにつけているとも言える。
MySQLの複合UNIQUEインデックスと文字列型のはなし
- 作者: 木村明治,はやしつとむ,坂井恵
- 出版社/メーカー: 翔泳社
- 発売日: 2009/12/10
- メディア: 大型本
- クリック: 19回
- この商品を含むブログ (11件) を見る
Firebird SQLの人だそうだが、MｙSQLや他のデータベースにも詳しく、ブログで様々なデータベースの話が取り上げられている。
MySQLの複合UNIQUE制約をNULLはすり抜けるが空文字列はすり抜けない
キムラデービーブログ MySQLでの一意インデックス(Unique index)の実装について
つまり、Firebird(Oracle, PostgreSQL)からMySQLに移行する場合、 エラーとしてはじかれていた(1,null)がはじかれなくなります。 逆に、MySQLからFirebird(Oracle, PostgreSQL)に移行する場合は、 エラーでなかったものが、はじかれる可能性がありますので、ご注意ください。
MySQLって、複合UNIQUEインデックスを作ってもNULLはその制約をすり抜けてしまうという罠があるんだよね〜
例えば、foo（INT）, bar（INT）, baz（VARCHAR）っていう3つの列の複合UNIQUEインデックスを作ったとして、
foo, bar, baz 1, 1, NULL 1, 1, NULL <- これは一意性約に違反しない！ 1, 1, "(空文字列)" 1, 1, "(空文字列)" <- これは一意制約に違反する。
こういう風に、NULLだと一意制約をすり抜けるけど、空文字列だと一意性約に引っかかるっていう仕様があります。
今までMySQLを使っていてこの仕様は知っていたんだけど、
MySQLから他のデータベースに移行することを考えたことがなかったので記事を読んでなるほどなぁと思いました。
データベース移行をしないとしても、テーブル設計で注意しなければならない点ですね。
MySQLの文字列は後ろのスペースを見ない
キムラデービーブログ MySQLの文字列比較セマンティクスは「空白埋め」
http://blog.kimuradb.com/?eid=877166
Oracleとは違いMySQLの場合は、 CHARもVARCHARも空白埋め比較セマンティクスで比較されるということ。 そのため、以下のような後続の半角スペースの個数が違うだけの文字列は、 CHAR, VARCHAR、文字リテラルで同一視されます。
これは知りませんでした。
以降、僕が知っているMySQLの文字列型の注意点を書いておきますね☆
MySQLの複合UNIQUEインデックスに２５５文字を超えるVARCHAR型のキーを入れることができない
なぜかよくわかりませんが、そういう縛りがあります。
ぐぐっても根拠がわかりませんでした。
MySQL5.1で試した例ですが、
確かに２５５文字を超えるVARCHARの列を含む複合UNIQUEインデックスを定義しようとするとエラーになります。
DROP TABLE IF EXISTS muluni
;
-- 256文字の列として定義
CREATE TABLE muluni (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(256) NOT NULL
) DEFAULT CHARSET=utf8 ENGINE=InnoDB
;
ALTER TABLE muluni ADD CONSTRAINT UNIQUE (id, name)
;
-- これはエラーになる。
-- ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes
DROP TABLE IF EXISTS muluni
;
-- 255文字の列として定義
CREATE TABLE muluni (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(255) NOT NULL
) DEFAULT CHARSET=utf8 ENGINE=InnoDB
;
ALTER TABLE muluni ADD CONSTRAINT UNIQUE (id, name)
;
-- エラーにならない。
-- Query OK, 0 rows affected (0.03 sec)僕はさっきまで「合計で７６７バイトを超える定義はエラー」と思っていたのですが、
確認したらそうではなく、７６７バイトを超える列を含めるとエラーのようです。
これも要注意ですね。
この問題の原因と対策は以下の記事が詳しいです！
tanamonの日記 MySQLのUNIQUEなINDEXには長さ767byteまでしか使えない件と対策
http://d.hatena.ne.jp/tanamon/20090930/1254332746
MySQLのVARCHAR型は桁長オーバーでも定義長以降を切り捨てて挿入・更新される
これも要注意の仕様です。
MySQLのVARCHAR型は定義長よりも長いデータを入れようとしたときにエラーにならず、
桁長を超えた部分を切り捨てて入れます。
INSERT INTO muluni VALUES (1, REPEAT('A', 256))
;
SELECT LENGTH(NAME) FROM muluni
;
/*
+--------------+
| LENGTH(NAME) |
+--------------+
| 255 |
+--------------+
1 row in set (0.00 sec)
*/
UPDATE muluni SET name = REPEAT('B', 256)
;
SELECT LENGTH(NAME) FROM muluni
;
/*
+--------------+
| LENGTH(NAME) |
+--------------+
| 255 |
+--------------+
1 row in set (0.00 sec)
*/結構文字列型って気をつけないといけないことがあるんですね。
今日の振り返り
二つほどずっと抱え込んだまま終わらせられなかったタスクをやっとfixさせました〜
とってもめでたい（＾_＾）
最近は韓国語も大学の第2外国語で受講できるらしい
僕が大学生の頃は中国語はあっても韓国語はなかったけど、いまどきの大学では韓国語も受講できるらしい。
べっ、べつに韓流が好きだとかそんなんじゃないんだからねっ！！
仕事のこと
今日は身体が痛くて仕事どころじゃなかったっていうのが本音だった。
でも、どうしても今日終わらせなければならないタスクが二つあったので頑張って終わらせた。
やっぱり健康に難があると8時間の勤務時間をずっと作業し続けるのは難しいな〜
残業時間を含めてトータルで8時間働いたって感じの一日になってしまった。
MySQLとPostgreSQLのメーリングリストに入会
日本のユーザー会の方ね。
これからデータベースのことをもう一度ちゃんと学び直そう。
特にPostgreSQLは使ったことがないので力を入れてやっていこう！
今日の振り返り
怪我で筋を痛めてしまいました！
何をするのも辛い ToT
今日はあまりに痛いのでお風呂に入るのもやめて寝てしまった。
あと最近、「今日の振り返り」を翌日に書くようになっているのも良くない ToT
今日の振り返り
ずっと定員オーバーで補欠だった勉強会に急遽行けるようになったので行ってきた。
準備とか全然していなかったので話を聞くだけって感じになってしまったけど次も参加したいなって思った。
仕事のこと
この頃本当に自分が作業者として何かやるってことが減った。
今日も他の人のやってくれた作業結果をレビューしていた。
あとは、Issue Tracking Systemに起票したチケットを整理していた。
何でも自分でやろうとしない: 他人にお願いする勇気
チケットを見ていると
- 「これは自分でやってしまおう」
- 「これは僕でもできる」
- 「これは僕がやっておくべき」
と思うものが結構あるけど、全部をやろうとするんじゃなくて
他人にお願いしなければならない場合もあることに気づいた。
簡単な作業であっても一度に沢山やろうとすると終わらないし、
チケットを先送りにして残し続けるのはとても悪いことなので、
そういうものは他の人にお願いしてしまうべきなんだと思うようになった。
作業成果の確認とチケットの棚卸をやる人は絶対必要
チケットの担当者がステータスを進めて、最後にチケットを閉じるとか、
そういう担当者次第のチケット運用はとても良くないと思う。
放置しっぱなしのチケットにも関心がいかなくなるし、チケットに起票した作業自体が本当に必要・妥当なのか確認すべきだと思う。
あと、チケットの粒度を考えたり、作業内容の説明をわかりやすく書くといったことは、
慣れていないうちはとても難しいので、誰かが全体的なチケット整理をちゃんと責任を持ってやる必要があると僕は思う。
その日のうちに明日の作業予定を決めてしまうと良い
今日やったことは比較的覚えているし、やり残したことも把握している。
でも明日になった途端、全然思い出せなくなったりいい加減な記憶になっていることは多い。
だから明日やると決めたことは今日のうちにノートに控えておくよう生活習慣を変えてみた。
僕は毎日コーネルノートに当日の作業予定をつけているので、
夕方に忘れず明日の作業予定を次のページに書き込んでしまうようにしている。
これは良かった。
こうしておくと作業内容を忘れずに済むし、翌日の朝に作業予定を見返して、
その作業を自分でやらないで他の人にお願いしてしまおうとか考えることができる。
こういうものをタスクボードとかIssue Tracking Systemで管理するのは「鶏をさばくに牛刀を以ってす」って感じで面倒くさい。
僕にはノートにつけるのが一番手軽で効果が高い。
今日の振り返り
SQLの勉強で苦戦して悔しいし悲しいToT
今日こそはブログにまとめられると思っていたのに
本質的な部分を理解できていないことに気づいて頓挫してしまった。
明日はこの壁を乗り越えたいな。
頑張ろう☆
あと、夜中にお菓子を食べ過ぎてしまった。
- ピーナツせんべい
- グミキャンディー
- ポッキー
- チューイングキャンデー
うわ〜 超食べ過ぎじゃんww
家でなにかやっていてうまく捗らないとイライラしてお菓子を食べてしまうんだな〜
これは良くないねー
仕事のこと
今日は案件の仕事はチケットの棚卸とスケジュール設定に費やした。
あとは軽微なバグをちょっと潰した。
簡単なソースレビューもやった。
僕自身の担当している仕事は進まなかった。
その代わり、案件の仕事じゃないタスクを一日の時間の半分くらい費やしてやった。
Google Apps Scriptは慣れなくてなかなかコーディングが捗らない。
もうひとつは執筆をちょっと進めた。
うん、頑張ろう… 頑張ろう… 沢山タスクを抱えてしまって辛いなぁ…
SQLの相関サブクエリがまだ解っていない
僕は今日家に帰ってから、ずっとこのSQLの意味が理解できなくて苦しんでいた。
そして今もまだ解っていない。
SELECT
prc_date,
A1.prc_amt,
(SELECT SUM(prc_amt)
FROM accounts A2
WHERE A1.prc_date >= A2.prc_date
AND (SELECT COUNT(*)
FROM accounts A3
WHERE
A3.prc_date BETWEEN A2.prc_date AND A1.prc_date
) <= 3
HAVING COUNT(*) = 3
) AS mvg_sum
FROM accounts A1
ORDER BY prc_date
;
わからないことは二つあって、
- この、赤字にした部分を"<= 3"から"= 3"に変えるとどうしてNULLばかり返ってきてしまう（SUMするレコードがヒットしない）のか解らない。
- どうして日付がちゃんと連続したレコードの集まりしかSUMの対象にならないのか解らない。"A1.prc_date >= A2.prc_date"を満たす3件のレコードならば、日付が飛んでいても構わないはずなのに、何でちゃんと並んだ日付にしかならないのか解らない。
ちなみに、accountsというテーブルに
mysql> select * from accounts; +------------+---------+ | prc_date | prc_amt | +------------+---------+ | 2011-10-26 | 12000 | | 2011-10-28 | 2500 | | 2011-10-31 | -15000 | | 2011-11-03 | 34000 | | 2011-11-04 | -5000 | | 2011-11-06 | 7200 | | 2011-11-11 | 11000 | +------------+---------+ 7 rows in set (0.00 sec)
こういうデータが入っていると、
+------------+---------+---------+ | prc_date | prc_amt | mvg_sum | +------------+---------+---------+ | 2011-10-26 | 12000 | NULL | | 2011-10-28 | 2500 | NULL | | 2011-10-31 | -15000 | -500 | | 2011-11-03 | 34000 | 21500 | | 2011-11-04 | -5000 | 14000 | | 2011-11-06 | 7200 | 36200 | | 2011-11-11 | 11000 | 13200 | +------------+---------+---------+ 7 rows in set (0.03 sec)
こういう結果を返す。
移動累計が何に役立つのかわかった
移動累計は一定期間の合計値同士を比較するので、「変化を把握する」のに役立つらしい。
START's HOMEPAGE -- 超便利フォーム 第３弾「先見グラフ」
http://homepage3.nifty.com/mstart/form/form3.html
ここが参考になった。
毎月の売上高を見るだけでは、 その時々に業績が上昇しているのか、下降しているのか分からないが、 この表のように過去12カ月の移動累計を見れば、 毎月、その時点で、売上高の変化がひと目で読み取れる。 （この例の場合は上昇傾向のみにしてある） 常に、過去１年間の累計を追っているので、 前年同月比の差だけ数字が変化し、 月ごとの特別な事情や季節変動はすべて吸収されてしまうからである。
