博客來借貼：http://www.books.com.tw/exep/prod/booksfile.php?item=0010396026
本作品應該是皇冠出版社為了推動(日式)推理小說而引進的現代精選作品。作者相當年輕，文筆也很靈活。翻譯的也很棒，應該有把原作的九成都給發揮出來了吧？
導讀是寵物先生，一位非常用心的導讀者。他很認真的從米澤的發跡歷程，一步一步介紹米澤的作品，以詳細的介紹這部小說。誠品的導讀在下也去看過，這位仁兄真是個非常有行動力，很有趣的傢伙呢！
如導讀所言《尋狗事務所》雖然是以私家偵探辦案的架構展開，但是並非傳統的『冷硬派』風格，而是現代感十足、風趣幽默，被寵物先生形容成『青春』的style。
事務所成立的目的是為了『找狗』，當然要找別的動物的話，老闆---紺屋---應該可以勉為其難的接受吧？不過，如果是找小鳥就不行，畢盡小鳥會飛...
這麼一個毫無衝勁的事務所搞不好立刻就會倒閉吧。所幸，老闆還算軟弱的個性，讓他沒辦法推掉尋人的請託，便開始尋狗事務所的第一個案子---尋人。
本書在探案的過程相當平和，若不是幾個主角有趣的對話，恐怕很難撐到後半段。但是反過來說，本書在對話上是真的很有趣，能讓人愛不釋手。
後半段的事故，案情自然而然的逐漸明朗。或許這是私探故事，內容比較注重辦案的過程，反而沒什麼推理的機會，讀者們可以順著主人翁的調查，一路讀完。
這部作品還不錯，很適合對推理小說有成見的新讀者。一般推理小說謎也可以讀看看，好好放鬆一下。除此之外，發生在"被害人"身上的事不說，結局我還蠻喜歡的。
2008年8月1日 星期五
懸案的魔力 - Zodiac
這幾天，HBO猛播一部叫《索命黃道帶》(Zodiac)的電影。在下看了以後，有一點小小的感想...
Zodiac就是美國知名的連續殺人犯(serial killer*註)，也就是黃道帶殺手。詳細可以看維基百科。裡面(目前)有五個子項目是我翻譯上去的。
他知名的主要是因為這個殺人犯會寄信給警方，公然挑釁。其次是因為這個案子也經常被改篇成電影，再其次大概就是因為這個連續殺人案還沒被偵破。
雖然，我很討厭兇手沒有被逞罰的故事，但是故事夠懸疑，兇手囂張的行徑也激起我解謎緝兇的動力，所以才能看得津津有味。
看完這部作品後，在下立刻上網搜尋了相關的資料。而且，對於這備案子，也很始有我自己的一些想法。
然而...然而，在下卻忽然驚醒...。我倒底在做什麼呀...案子已經發生快五十年了，而且其中有許多人力物力投入都未能偵破。一個小小的Jackmis，遠在太平洋另一端的Jackmis何德何能去解決它呢？
劇中人也為了查案抛家棄子的陷入瘋狂的境界，一想到自己有點陷入同樣的情境，差一點連國外的調查報告都拿出來看，就覺得有點可怕。
不過，這次的經驗，也讓在下看到了一些有趣的東西。
原來，懸案真的可以讓人痴狂呀。
雖然在下覺得兇手Zodiac沒動什麼腦筋，只是一點運氣，一點時空環境的關係，才沒被抓到。
可是他囂張的行徑、謎一般的密碼，卻增加了旁觀者更多想像的空間。變成刺激旁觀者想知道真相的動力。這大概就是推理小說家范達因所強調的：
七、 ...，殘暴的凶殺足以激起其報復心和恐懼心。他們都希望將加害者繩之以法。...即連比誰都溫厚的讀者都會以滿腔的正當熱忱去從事追蹤。[來源]
我把這句話解釋成‥推理小說激起讀者探案的欲望。這正是推理小說作者最重要的任務吧？
我們經常看到，有些推理小說的相關作品，雖然兇手在故事的表演很高竿，但是讀者並沒有融入案情，只是一頁一頁的翻，等到翻到解謎的章節。這麼一來，真是可惜了犯案的詭計。
另一方面，有些小說的詭計不怎麼樣，幾乎一點就破。可是讀者卻能身入其境，體驗懸疑，每翻一頁都要擔心害怕。
這就說明了除了詭計之外，作家也要注意情境的塑造。
最後，在這裡做一個總結。Zodiac是真實事件，與作家幻想不同，但是仍值得拿來思考。事實上，電影《索命黃道帶》本身就是經過改篇，讓其中的懸疑呈分加溫。
因此，未來在創作的時候，除了那讓人想破頭的詭計。更重要的是要如何塑造氣氛。
免得人家說推理小說只是猜謎遊戲，看起來沒fu呀。
*註：serial killer的兇手通常會殺很多人，但不是殺很多人就能被稱為serial killer。其中有微妙的差別，煩請自己查查。另一方面，大陸型國家比較容易造就serial killer。
Zodiac就是美國知名的連續殺人犯(serial killer*註)，也就是黃道帶殺手。詳細可以看維基百科。裡面(目前)有五個子項目是我翻譯上去的。
他知名的主要是因為這個殺人犯會寄信給警方，公然挑釁。其次是因為這個案子也經常被改篇成電影，再其次大概就是因為這個連續殺人案還沒被偵破。
雖然，我很討厭兇手沒有被逞罰的故事，但是故事夠懸疑，兇手囂張的行徑也激起我解謎緝兇的動力，所以才能看得津津有味。
看完這部作品後，在下立刻上網搜尋了相關的資料。而且，對於這備案子，也很始有我自己的一些想法。
然而...然而，在下卻忽然驚醒...。我倒底在做什麼呀...案子已經發生快五十年了，而且其中有許多人力物力投入都未能偵破。一個小小的Jackmis，遠在太平洋另一端的Jackmis何德何能去解決它呢？
劇中人也為了查案抛家棄子的陷入瘋狂的境界，一想到自己有點陷入同樣的情境，差一點連國外的調查報告都拿出來看，就覺得有點可怕。
不過，這次的經驗，也讓在下看到了一些有趣的東西。
原來，懸案真的可以讓人痴狂呀。
雖然在下覺得兇手Zodiac沒動什麼腦筋，只是一點運氣，一點時空環境的關係，才沒被抓到。
可是他囂張的行徑、謎一般的密碼，卻增加了旁觀者更多想像的空間。變成刺激旁觀者想知道真相的動力。這大概就是推理小說家范達因所強調的：
七、 ...，殘暴的凶殺足以激起其報復心和恐懼心。他們都希望將加害者繩之以法。...即連比誰都溫厚的讀者都會以滿腔的正當熱忱去從事追蹤。[來源]
我把這句話解釋成‥推理小說激起讀者探案的欲望。這正是推理小說作者最重要的任務吧？
我們經常看到，有些推理小說的相關作品，雖然兇手在故事的表演很高竿，但是讀者並沒有融入案情，只是一頁一頁的翻，等到翻到解謎的章節。這麼一來，真是可惜了犯案的詭計。
另一方面，有些小說的詭計不怎麼樣，幾乎一點就破。可是讀者卻能身入其境，體驗懸疑，每翻一頁都要擔心害怕。
這就說明了除了詭計之外，作家也要注意情境的塑造。
最後，在這裡做一個總結。Zodiac是真實事件，與作家幻想不同，但是仍值得拿來思考。事實上，電影《索命黃道帶》本身就是經過改篇，讓其中的懸疑呈分加溫。
因此，未來在創作的時候，除了那讓人想破頭的詭計。更重要的是要如何塑造氣氛。
免得人家說推理小說只是猜謎遊戲，看起來沒fu呀。
*註：serial killer的兇手通常會殺很多人，但不是殺很多人就能被稱為serial killer。其中有微妙的差別，煩請自己查查。另一方面，大陸型國家比較容易造就serial killer。
2008年7月15日 星期二
DB2's way to convert string into date
SQL一二三事
SQL是一種資料庫查詢語言的標準。依尋這些標準，資料庫的設計變得有跡可尋，也讓使用者、資料庫管理者更能方便學習與管理資料庫(以下稱DB)。
然而，各家DB大廠對SQL標準的支持呈度不同，也不知道是在搞什麼特色，讓Jackmis被一個小問題惡搞了兩個小時左右...
#在M$SQL計算日差
DATEDIFF(DAY, GETDATE(), db_date)
DATEDIFF函式會把GETDATE(今天的日期)減掉db_date的日期，並以DAY(日)為準，傳回相差的天數。比如今天是2008/7/15，而db_date的內容是20080720，則結果就是-5
當Jackmis把上面的式子放到DB2的時候...恐怖的來了...
#DB2字元切割
原本想利用date()函數，讓db_date的字元直接換成日期型態...沒想到，DB2的date()比較弱，沒辦法識別。所以我只好把20080720轉成2008-07-20了。
我的首次切法是：
left(db_date,4)+'-'+mid(db_date,5,2)+'-'+mid(db_date,7,2)
結果失敗了。因為
1. DB2的字串相連是用兩個水管符號(︱︱)，在網頁上會被拿掉，所以我用全形字。
2. DB2沒有mid函數；這函數的效果是取中間字串的函數，比如mid('abcd',2,2)='bc'才對，但DB2不是這個名字，而是substr()，用法一樣(搞特例)。
然後，改成：
left(db_date,4)︱︱'-'︱︱substr(db_date,5,2)︱︱'-'︱︱substr(db_date,7,2)
得出2008-07-20。但轉日期時還是失敗...
#DB2字元轉日期
這時候，在下已經很想罵人了...看了很多文章發現一些怪怪的現象，於是我試了
substr(db_date,1,4)︱︱'-'︱︱substr(db_date,5,2)︱︱'-'︱︱substr(db_date,7,2)
將left改用substr這個函數。然後再用date函式包起來，就轉成日期型態了！
倒底為什麼不能用left呢？這是個謎...
#在DB2計算日差
最後，GETDATE函式在DB2裡面沒有，請改用current date(或current_date)，如下：
days(current date)-days(substr(db_date,1,4)︱︱'-'︱︱substr(db_date,5,2)︱︱'-'︱︱substr(db_date,7,2))
然後就可喜可賀...
神呀...制裁這些讓世界更複雜的人吧...更...
參考資料：
http://www.ibm.com/developerworks/cn/db2/library/techarticles/0211yip/0211yip3.html
http://www.tek-tips.com/viewthread.cfm?qid=1175566&page=1
SQL是一種資料庫查詢語言的標準。依尋這些標準，資料庫的設計變得有跡可尋，也讓使用者、資料庫管理者更能方便學習與管理資料庫(以下稱DB)。
然而，各家DB大廠對SQL標準的支持呈度不同，也不知道是在搞什麼特色，讓Jackmis被一個小問題惡搞了兩個小時左右...
#在M$SQL計算日差
DATEDIFF(DAY, GETDATE(), db_date)
DATEDIFF函式會把GETDATE(今天的日期)減掉db_date的日期，並以DAY(日)為準，傳回相差的天數。比如今天是2008/7/15，而db_date的內容是20080720，則結果就是-5
當Jackmis把上面的式子放到DB2的時候...恐怖的來了...
#DB2字元切割
原本想利用date()函數，讓db_date的字元直接換成日期型態...沒想到，DB2的date()比較弱，沒辦法識別。所以我只好把20080720轉成2008-07-20了。
我的首次切法是：
left(db_date,4)+'-'+mid(db_date,5,2)+'-'+mid(db_date,7,2)
結果失敗了。因為
1. DB2的字串相連是用兩個水管符號(︱︱)，在網頁上會被拿掉，所以我用全形字。
2. DB2沒有mid函數；這函數的效果是取中間字串的函數，比如mid('abcd',2,2)='bc'才對，但DB2不是這個名字，而是substr()，用法一樣(搞特例)。
然後，改成：
left(db_date,4)︱︱'-'︱︱substr(db_date,5,2)︱︱'-'︱︱substr(db_date,7,2)
得出2008-07-20。但轉日期時還是失敗...
#DB2字元轉日期
這時候，在下已經很想罵人了...看了很多文章發現一些怪怪的現象，於是我試了
substr(db_date,1,4)︱︱'-'︱︱substr(db_date,5,2)︱︱'-'︱︱substr(db_date,7,2)
將left改用substr這個函數。然後再用date函式包起來，就轉成日期型態了！
倒底為什麼不能用left呢？這是個謎...
#在DB2計算日差
最後，GETDATE函式在DB2裡面沒有，請改用current date(或current_date)，如下：
days(current date)-days(substr(db_date,1,4)︱︱'-'︱︱substr(db_date,5,2)︱︱'-'︱︱substr(db_date,7,2))
然後就可喜可賀...
神呀...制裁這些讓世界更複雜的人吧...更...
參考資料：
http://www.ibm.com/developerworks/cn/db2/library/techarticles/0211yip/0211yip3.html
http://www.tek-tips.com/viewthread.cfm?qid=1175566&page=1
訂閱：
文章 (Atom)
發表文章
