首先簡單的描述一下這個專案，乙個web考勤系統，資料庫sqlserver，8個頁面。其中2個頁面在ipad中使用，其他6個pc使用。
規定無論是ipad和pc中，使用的客戶端是webkit核心的safari瀏覽器。
現在這個專案，只做了三個頁面，因為設計在不停的更改，所以**屬於在一直修改中。
既然提到了是個奇怪的專案，就給大家看看奇怪的地方吧。
奇怪1：專案體制
這個專案由乙個專案leader帶領3個設計人員及1個半**人員，半個是我，我只做了ipad的乙個畫面就撤出了這個專案組。leader主要負責業務和資料庫表設計，3個設計人員負責
業務邏輯，**人員當然負責**了。
體制奇怪處1：4個設計對應乙個開發人員，想累死寫**的人吧。
體制奇怪處2：3個設計人員是剛進公司的新人，無開發和設計經驗，當時討論畫面時，連textbox是什麼都不知道。
奇怪2：流程
先不說新人做設計文件能做成什麼樣子，單說leader帶這些設計人員，只是對leader對業務的口頭描述拷貝成設計文件。描述有的，可能丟了，沒有的，更直接沒有。
在後面的**過程中，基本上由**人員去找leader確定設計，然後由設計人員修改。
奇怪3：業務
本身這個專案沒有使用者基礎表的錄入畫面，使用者的基礎資訊由乙個batch從excel中匯入。匯入時將使用者的5年考勤記錄，作為空資訊插入到資料庫表中。
開始我們一直奇怪的是，為什麼設計裡面對於考勤打卡這個手續，為什麼只有update，而沒有insert。後來在詢問leader的時候才知道因為batch都做了insert處理了。
奇怪4：資料庫設計
在設計中，對於出勤時間的計算，跨天的當作前一天的資料計算，
資料庫表設計為
出勤表：
出勤日期
出勤人員
出勤1退勤1
出勤2退勤2
出勤3退勤3
yyyy/mm/dd
nnnn
hhmm
hhmm
hhmm
hhmm
hhmm
hhmm
2012/01/01
0001
0800
0700
出勤1~退勤3為number(4,0) ,其他為varchar型別
第二行資料是跨天資料
打卡畫面獲取的是伺服器時間，奇怪的是，我怎麼能在第二天打卡點退勤按鈕的時候，將資料記錄在前一天裡面，而且不是前2天，前三天裡面。
為此還跟leader討論的半天，終於leader無語了，在每個出退勤的字段後都加上了乙個輔助計算字段。格式是yyyy/mm/dd hh:mm。還是不放棄的保留了原先的出退勤字段。
此上改動為做到第三本畫面時，口頭了解到出退勤時間計算方式時，找leader確認計算方法時才知道。設計書上就沒有說過，那個汗啊。
幸虧是個小專案，大專案不就徹底崩潰了。
奇怪的人（日本人）帶奇怪的專案，奇怪的專案出現奇怪的設計，奇怪的設計出現奇怪的**，最後不出現bug，就更奇怪了。
乙個奇怪的listview
一般情況下listview就是乙個頭有控制代碼 用spy看看任務管理器 就是 程序 這個有個控制代碼 就知道了 再就是整個listview乙個控制代碼 一共2個控制代碼 分別是 主控制代碼 syslistview32 和頭控制代碼 sysheader32 這個奇怪的listview被分成了3個控制代...
乙個奇怪的Exception
環境大概是，jdk8 tomcat8，為了進行強加密，使用了bouncycastle的庫。但是在啟動的時候總報告乙個錯誤 must be passed recipient s private ec key for decryption 錯誤出在乙個instance of的判斷 if var2 ins...
乙個奇怪的國家
有乙個奇怪的國家，裡面的國民對於事情的態度永遠只有兩面。當兩個人遇到一起討論乙個事情的時候 兩個持贊同觀點的人遇到一起後會對這個事情都繼續贊同 乙個持贊同觀點的人遇到乙個持不贊同觀點的人的時候，兩人都會不再繼續贊同 兩個持不贊同觀點的人遇到一起討論後反而會對這個事情開始贊同。輸入包括兩行，每行包括n...