從凌開始

時常聽到有些人這麼說，這問題「應該」很簡單 當聽到應該就代表有那些一些不確定性 但這樣說其實是很不負責任的 記得有天晚上，有個同事隔天要出差出廠商那裝機 需要帶的資料有上百GB，他跟主管要了顆硬 主管拿了顆硬碟給他，說「應該」可以用 接著就走了 很不幸的，這顆「應該」可以用的硬碟不能用 於是厚著臉皮打了電話跟主管求救 才又找到了顆可以用的硬碟 回家時已經超過晚上十點 雖然我經常可以很快的解決問題 但對於我不確定的問題我不說簡單 因為那可能真的不簡單 有段時間我兼任PM的工作 要分配工作給下面的人 我會很細心的仔細看完工作的項目 甚至加上我覺得重要的關鍵提醒，這一個重要提醒 可能就是讓問題由「應該」很簡單變成「真的」很簡單 但公司卻認為我這麼做是多餘的 在問題解決之前不說簡單 在問題解決之後不說困難

利用颱風假期一口氣看完這兩部片 觸不到的戀人是韓國版原著 跳越時空的情書是美國版的改編 兩部在表現手法有些不同 給人的感受也不同 雖然很多人說韓國版的比較感人 但我覺得美國版比較讚 可能看韓國版時不是很專心吧 兩片的結局大不相同 但我比較喜歡美國版的結局 雖然美國版的比較誇張一點 但讓整個劇情也更有張力

其實程式真的很像藝術，看看下面的程式碼： bool check; // 第一種 if (check) { check = false ; } else { check = true ; } // 第二種 check = (check) ? false : true ; // 第三種 check = !check; // 第四種 check ^= true ; 一樣的句子，透過 xor ( ^= ) 變的多麼簡單，也許上面的式子感覺不太出來，那看看下面的，因為取屬性的寫法變的比較長了，自然 code 也變長了，當然還可能會更長 但一樣透過 xor 就變的很簡潔，像藝術作品一般 // 第一種 if ( this .checkBox1.Checked) { this .checkBox1.Checked = false ; } else { this .checkBox1.Checked = true ; } // 第二種 this .checkBox1.Checked = ( this .checkBox1.Checked) ? false : true ; // 第三種 this .checkBox1.Checked = ! this .checkBox1.Checked; // 第四種 this .checkBox1.Checked ^= true ;

其實不是第一次被問了，每次都要查一下資料 還是特別筆記一下好了 參考資料：http://msdn.microsoft.com/en-us/library/bb386454.aspx Controls that Are Not Compatible with UpdatePanel Controls The following ASP.NET controls are not compatible with partial-page updates, and are therefore not designed to work inside an UpdatePanel control: TreeView control under several conditions. One is when callbacks are enabled that are not part of an asynchronous postback. Another is when you set styles directly as control properties instead of implicitly styling the control by using a reference to CSS styles. Another is when the EnableClientScript property is false (the default is true ). Another is if you change the value of the EnableClientScript property between asynchronous postbacks. For more information, see TreeView Web Server Control Overview . Menu control when you set styles directly as control properties instead of implicitly styling the control by using a reference to CSS styles. For more information, see Menu Contr

自 7/18 後，陸續有些人出現 emesene 無法連線的問題 一開始以為是 msn 有問題，但上 ptt 發現只有少數人 改試 pidgin 連的卻好好的 那問題是出在 emesene 查詢後，問題可以說是 emesene ，也有人說是 microsoft 搞鬼 解決方法： sudo sed -i.bak 's/09607671-1C32-421F-A6A6-CBFAA51AB5F4/CFE80F9D-180F-4399-82AB-413F33A1FA11/g' /usr/share/emesene/emesenelib/XmlTemplates.py emesene 真的是不錯用，而且支援離線訊息

ubuntu 內建的 gcin 是 1.3.7 版，已經有點舊了 而在 gcin 同好會 裡，能下載到的deb檔，最新的只有 1.4.0 debian 中的 1.4.2 因為 libpango 的版本相依性關性無法安裝 只好自己編譯了 取得最新版本原始碼 wget http://cle.linux.org.tw/gcin/download/gcin-1.4.2.tar.bz2 tar xvf gcin-1.4.2.tar.bz2 安裝必須的編譯套件 sudo apt-get build-dep gcin 由於 ubuntu 的部份設定和原作者的環境不同，所以必須先修正部份檔案 1. 修改configure檔案， 找到 QT_IM_DIR=/usr/lib/$i/plugins/$LIB/inputmethods 改為 QT_IM_DIR=/usr/lib/$i/plugins/inputmethods 2. 修改 qt-im目錄中的 Makefile 找到 /usr/lib/$(QT)/bin/moc $< -o $<_moc.cpp 改為 moc $< -o $<_moc.cpp 3. 在 /usr/lib/qt3 增加 連結到 /usr/include/qt3 ln -s /usr/include/qt3 /usr/lib/qt3/include 一切準備就序後，就可以開始編譯囉 ./configure --prefix=/usr make sudo make install

今天追一個問題，追了半天，原本程式碼如下： MyContext context = new MyContext (); int count = context.Logs.Count(m => m.CreateDate.Value.ToShortDateString() == DateTime .Today.ToShortDateString()); 上面的式子在使用了 linq to Sql， 其中 Logs 資料表中有一個欄位 CreateDate 是 Sql 的 DateTime 型別，在 lamba Expression 中，把它當做 DateTime 型別使用，於是使用了 ToShortDateString 這個方法，編譯一切正常，但執行時，卻發生了例外。 不死心的，將上述的式子改為： MyContext context = new MyContext (); int count = context.Logs.Count(m => m.CreateDate.Value.ToString(" yyyyMMdd ") == DateTime .Today.ToString(" yyyyMMdd ")); 依然出錯，最後只好將式子改為 MyContext context = new MyContext (); int count = context.Logs.Count(m => m.CreateDate.Value.Date == DateTime .Today.Date); 才終於過關，但這一切過程都是 runTime 時才發生問題，原本強調 var 型別的動態性，與強型別編譯的好處，以減少錯誤的發生，但眼前卻顯得一切都不可靠。 最後終於在 msdn 中找到了答案： http://msdn.microsoft.com/en-us/library/bb425822.aspx 節錄最後面一段： System.DateTime Implemented Constructors: Copy Code DateTime(year, month, day) DateTime(year, month, day, hour, minutes, seconds) DateTime(year,

從國中開始寫程式時，程式對我而言，就是達成目的的指令，在當時並沒有所謂時程和效率的考慮，沒有受過正統程式設計訓練的我，只有零星的上過一些相關課程，和絕大多數的自修，但一些專有名詞，像復雜度、NP HARD之類的，我也還蓋得出來。 在軟體討論區甚至是open source 討論區，出現了 IDE 工程師這樣一個名詞，原本這個詞並不是什麼不好的意思，但在那些討論區裡指的卻是一群只會使用圖形化開發工具(泛指微軟系列為主)的工程師，講求易上手，快速開發，但結果卻是常常忽略了一些細節，造成漏洞、效率等的問題。 經常遇到的是開發時使用的小型案例一切正常，但真正上線時，完全攤換，這不全是工程師的錯，如果規劃時周全一點，如果讓比較有經驗的來領導專案進行，如果肯針對不良的程式碼痛下決心大改寫，都可能讓這些問題不要發生。 第一場戰役：jQuery，從開始引入jQuery開始，本來這應該是個美好的開始，但新人進來就開始學jQuery，基本Dom操作的也jQuery，諸如 jQuery("#id") 這樣的式子完全被濫用，基本的 document.getElementById 反而都不會用，有些效能卻是在這些地方消失掉的。 第二場戰役：linq，雖然 linq 讓很多的程式開發更有彈性，特別是 linq to sql 讓工程師幾乎可以不了解 sql 句也能完成資料庫的存取，但如果沒有優良的 DBA 在幫忙輔助管理資料庫，就算 linq 用的再熟再好，也解決不了因為資料庫設計不良造成的效能低落問題。 打了越多場硬戰後，我也了解了更多，快速開發與效率其實也是有辦法兼顧的，快速開發靠的是工具，但效率就必須靠著工程師的素養、經驗、細心。