2006年9月29日
#
玩電腦寫程序多年了,太投入,以至于得了職業病。手指、手腕、肩頸部都經常疼痛,眼睛干澀紅癢,肚子也變將軍了。
后來在家soho,頸椎問題尤為嚴重。在網上尋求解決方法,并自行研究實踐,有了明顯的好轉。記錄于下,望對使用電腦工作的人有點用處。
1.頸椎問題的嚴重性:會引發腦部供血、脊柱神經、睡眠等問題。不是專家,網上可自己查找相關資料。
2.原因。久坐少動。肩頸部肌肉勞損以至骨骼、軟骨受損。
3.我的解決過程。
? 買了個太空枕,睡覺時可支撐頸部。效果不明顯。
? 后來每周按摩1小時。你要想有點效果一定得到正規的地方,還得受得了疼。按一次,得疼三天。有是有點用,回想一下,這不是花錢找罪受么?
? 然后去了曙光醫院,醫生給開了一些藥,問了,大概都是緩解癥狀的,不能治本。
? ---我一向不同意程序員30歲轉行的觀點,難道我過不去這個坎?---
? 轉而采取日常生活中自己注意保健。一般來說,主流的意見是多運動。包括體育運動和針對性的保健操。
? 我在家實踐了兩個月,3天一次長跑或羽毛球,每天一次散步和多次保健操。效果不算明顯。
? 后來我從源頭上著手。
????? 硬性的就是減少坐在電腦前的時間,打游戲不打了,工作時想問題就起身。這個也不易。這個對工作有一定影響,但也是重要方法之一。
????? 軟的是調整桌椅高度及坐姿。桌椅一定是符合三個90度:坐著膝蓋90度,大腿和上身90度,肘部90度。
? 肘部一定要有依托,至少有椅子的扶手,我現在是用了大桌子,對著90的圓弧,兩肘都放在桌面上。
現在我的頸椎問題已經好多了。
總結一下,方法是綜合的。但效果最明顯的就是桌椅。其中最關鍵的就是肘部的依托,肘部放在桌面上我覺得是挺有效。
另外,不能覺得沒有時間想健康問題,否則結果是不得不想。拿出你打游戲、寫程序的勁頭對待健康,肯定能解決問題的。
2006年9月11日
#
www.lucas-lee.com
免費軟件,非開源軟件。
純JAVA開發,B/S架構。目前支持MySQL5.0.21及以上數據庫。
預定義了多種缺陷處理流程,可選擇使用。
- 小型團隊自由流程
由當前處理者指定下一個處理者,流程比較靈活。
- 小型團隊受控流程
以項目經理為中心的流程,提交后的審核、轉交程序員、修改后的驗證等步驟都由項目經理控制。
- 單人流程
只有一個使用者的流程。適合個人軟件的開發過程。
缺陷統計功能。使用琴棋報表。
郵件提醒。流程轉入下一步驟后,系統會自動發郵件給下一處理者。
字典數據可自定義。優先級別、嚴重程度、項目、模塊等等。
基于角色--用戶組--用戶的權限控制。
www.lucas-lee.com
1)解決了Excel格式輸出大量單元格時出現的Excel樣式過多的問題。
2)優化了clone的算法。
2006年9月1日
#
所謂字典就是數據庫應用中被其他表(通常加以外鍵約束)引用的表,如客戶表引用客戶類型,那么客戶類型即為字典表。刪除字典數據要考慮是否已被其他數據引用,一般不允許做級聯刪除。
這個問題想必大家都碰到過,但各有各的?做法。本人與若干同事討論過,將各種做法總結一下。
- 物理刪除,即用delete SQL刪除。如果字典數據被引用,則會拋出違反外鍵約束的異常,將其封裝為可讀的信息提示給用戶。JDBC中的異常類為SQLException,如何判斷是違反外鍵約束的異常呢?有方法如下:
- 利用SQLException中的errorCode,這是數據庫特有的錯誤編碼。
- 利用SQLException中的SQLState,在JAVA API DOC中說明這個是SQL99或XOPEN 標準的編碼,而且可以用connection的meta data來判斷符合哪個標準。經過的試驗,說明這個meta data不太好用,但是SQLState還是較為統一的。
? | mysql5.0.21 | sqlserver2000 | oracle10 | postgresql8 |
ANSI99 SQLState標準的違反外鍵約束編碼為:23000 | 23000 | 23000 | 23000 | 23503(可能要在BatchUpdateException的nextException中才能取得) |
Connection的meta data中的getSQLStateType(),符合SQL99標準應該為2 | 2 | 2 | 0 | 2 |
- 邏輯刪除。即置表中的一個標記字段為已刪除。查詢時不可見,但實際還保留在表中。 好處是不用處理數據被引用的情況。它的缺點是,如果數據沒有被引用,那么它其實可以被物理刪除,但確留在系統中成為垃圾數據;其次在數據有唯一編碼的情況下,被邏輯刪除的數據實際上還占用著一個編碼,有時用戶會疑惑,明明表中查不到這個編碼,我在新增的數據中使用這個編碼卻總提示編碼已存在。
??? 各位又是用的什么方法來處理的呢?你的方法有何優缺點,不妨一同討論一下。
??
2006年7月9日
#
[一.奠定基礎]
1. 任何不能改善產品的工作,都是浪費時間或是偏離方向。
2. 領導者的任務是努力消除程序設計師工作上的一切障礙,讓程序設計師全力專注在真正重要的工作─改善產品。
3. 千萬不要把程序設計師的時間浪費在改善產品以外的工作上。
4. 永遠記得自己真正的目標,然后讓團隊用最有效又最愉快的方法把它完成。
5. 理清詳細的項目目標,可以避免在不必要的工作上浪費時間。
6. 不要因為制定目標需要花很多時間,或是別人都沒有做,就省略了目標的制定。制定明確詳盡的目標所花的時間,絕對會讓團隊得到更大的好處。
7. 事前決定最合適的優先考慮順序,以及各考慮點的質量規范,能夠指引開發團隊的工作。
?
[二.策略性的作業方式]
8. 錯蟲愈晚清除,時間花得愈多。畢竟,您得知道程序是怎么寫的,才能判斷那里出了錯蟲;剛寫完的程序記憶猶新,一年前寫的程序可能早就忘了
。
9. 在開發的過程就立即除蟲,可以讓您早些學到經驗,然后就不會再犯同樣的錯誤;相反地,如果到了項目后期才發現,您可能已經犯過多次同樣的錯誤而不自知。
10. 發現錯蟲而立即除錯是一種緩沖器,提醒那些講求快速而不夠謹慎的程序設計師,以后多加小心。如果您堅持錯蟲全都清除了才能開發新的功能,就可以防止所有的程序處于半完成狀態,因為錯蟲太多而使項目延誤乃至無法推出;相反地,如果您允許錯蟲的存在,等于是埋下了項目失控的地雷,最后看似完成的項目,其實已經失控。
11. 若能保持沒有任何錯蟲,您就能比較準確估出項目的完成時間。不必猜測3 2項功能和1 742個錯蟲共要花費多少時間,只要估算3 2項功能的工作時間就行了。更重要的時,萬一到時候有些功能做不完,您可以做多少算多少,因為軟件一直保持在無錯誤狀態。
12. 不要把策略性工作方式當作訓練的教條,應該向組員解釋這些工作方式的內涵與用意。
13. 提出精確詳盡的問題,可以引導出真正有效的策略性工作方式,幫助項目目標順利完成。
14. 策略不是死的定律,要把它當作指導原則來活用。大部分的時候都應該遵循,但也有例外的時候。
?
[三.保持進度]
15. 定期暫停手邊的工作,然后往前思考,隨時做必要的修正,以避免未來的大障礙。
16. 有什么事情是我今天能做,而且可以幫助項目在未來幾個月內順利進行的?
17. 不要浪費時間在錯誤的問題上,一定要先確定真正的問題在哪里,然后才去改正它。
18. 人們開口要求的東西未必是他真正想要的。處理他的要求之前,請務必確定他究竟想要做什么。
19. 絕對不要答應別人自己做不到的事情,這樣對雙方都有益無害。
20. 不要為了討好別人而傷害雙方的工作進程,您永遠要根據自己的目標,做適當的決策。
21. 是您在為項目負責。不要讓任何人的建議阻礙項目的進行,包括上級的建議。
22. 天下沒有真正免費的軟件
23. 應該開發策略上具有重要性的功能,而不是把媒體的評比項目都做齊全。
24. 軟件產品的開發,不能只為了有趣、挑戰性,或是夠有個性夠令人眩目。
25. 不要把時間浪費在無法改善產品的工作上,即使這么做在將來會有潛在的利益,也要與現在投入的時間成本做個衡量。
?
[四.走向極端的狂熱]
26. 確定您所要求的報告真的值得屬下暫停工作,花那么多時間去寫。
27. 利用項目檢查報告來改進軟件開發的工作程序。為了使報告發生作用,報告中必須確實描述我們這次解決問題的每一個詳細步驟,以及將來應該如何運用這項新發現。
28. 請注意定期會議的價值,確定它值得每個人放下手上的工作。
29. 召開任何會議之前,請確定本次會議的目的是什么,達成這個目的的條件是什么,然后,務必達到開會的目的。
30. 試著排除不必要的后續工作。
?
[五.進度狂]
31. 不要利用進程表來驅使項目的進行,這對小組的士氣傷害太大了。
32. 讓日程表維持適度的緊迫,但又是可以做到的,好讓組員振奮、不松懈,專心致力于項目的推進。
33. 絕對不要草率定出不可能的期限,導致組員為了趕進度而損害產品的質量。
34. 把長期的大項目,分成幾個完整而獨立的小項目,各小項目必須有一個主題。
35. 為了保持創意的活力和團隊士氣,必須讓每一個小項目都有令人興奮的結果。
36. 產品的質量遠比遵守期限重要.
?
[六.學無止境]
37. 不要讓程序設計師的學習停滯不前,要讓程序設計師有機會磨練不同領域的技術,培養十八般武藝樣樣精通的組員。
38. 訓練新進程序設計師時,先培養他對整個公司所有項目都有價值的技術,然后才培養本項目獨有的技術。
39. 不要舍不得放您最優秀的程序設計師到別的項目去。如果他在您的項目已經沒有新的東西可學,為了公司和他個人的前途,您應該把他推薦到別的項目,讓他的成長永不間斷。
40. 確定每位組員、每兩個月都有一項技術上進步。
41. 一發現某處需要改進,就立即采取更正的行動。
42.不要用年終考評來訂立學習目標,要利用年終考評來記錄個人的成長。
43. 絕對不要讓組員一直做同樣的工作,這樣是限制了他的學習,使他停滯在原來的領
域。一旦程序設計師精通了某一個領域,就讓他換別的領域做做看,永遠讓他們學習新的技術。
44. 各種技術的用途范圍有所不同,有的技術在一般的項目都用得上,有的技術只有在特定性質的項目才用得上。當您訓練您的組員時,必須讓他們的技術能在公司發揮最大的用處,最好的辦法就是,把應用范圍最廣的技術放在訓練的最前期,應用范圍最小的技術放在最后訓練。
45. 優秀的程序設計師是項目經理最需要的,所以經理們通常舍不得讓自己手下功力最強的人到別組去,但是如果這位第一高手在本組內再也沒有新東西可學時,經理就應該讓他到別的項目去,一方面他個人可以重新開始另一次的成長,一方面讓接替他的人學著承擔重要的工作,最后公司的平均程序技術水準因而提升,對大家都很有好處。
46. 為了確保每位程序設計師的技術都在穩定地進步,一定要讓每個人有個努力的目標,最好的方法是把個人的成長和項目每兩個月的階段性目標相結合,這樣一年就有至少六次的進步了。假定一位組員在公司待了五年,那么他就學了3 0種新技術、或是讀了3 0本好書、或是1 5項技術加1 5本書,對他的工作能力影響多大啊。
47. 最好的成長目標是出于當時的需要。如果您發現有位組員工作缺乏效率,或總是在犯同樣的錯誤,最好抓住機會立即為他立一個目標,并且要求他立刻開始改進。這種當時設立的目標讓人印象深刻,又是馬上尋求改善,效果通常會非常好。比起年終考評那種模模糊糊的建議,更能引起程序設計師的重視。
?
[七.態度問題]
48. 要讓每一位程序設計師都明白,寫出零錯誤程序是很不容易的,所以應該多花功夫用各種方法做最徹底的測試。
49. 糾正程序設計師以為加除錯碼會花太多時間的觀念,應該訓練程序設計師第一個反應是考慮加上除錯碼是否有道理,第二是考慮加除錯碼是否符合項目的目標與工作的優先級。
50. 當某人說“某件事不可能做到”時,他往往是錯的。
51. 不要讓凡事不能的態度阻礙了創新。
52. 使用者和程序的撰寫者一樣關心速度和品質的問題。
53. 不要讓程序設計師以為使用者并不在乎軟件的質量。
54. 不要給使用者次品,寧愿延期交貨,務必追求質量完美。
55. 程序設計師必須經常以使用者的觀點來看自己寫的程序,程序設計師必須能體會使用者的感受。
56. 在包裝盒里的每一件東西,都是產品的一部分。
57. 將程序的重用性當作優先考慮的目標之一,否則程序設計師將經常做重復的工作。
58. 充分利用現有資源或創造新資源,以便從每一項工作中獲得更大的價值。程序代碼的再利用,就是很好的例子,當然,還有其他的地方可以運用“杠桿原理”。
59. 如果您創造了一項資源,并且讓別人知道,那么總有一天會派上用場。
60. 從您的每件工作中創造最大的資源,不管是利用現有的杠桿,或是創造新的杠桿。
61. 小心那種“太難了”、“太花時間”或是“太麻煩”的反射性反應。當您遇到別人有這種反應,請先問自己他有沒有認真思考過這件事的重要性、以及是否符合項目目標,如果您認為他其實未經深思熟慮,只是直覺的反應,那您就應該把您的想法告訴他,請他重新評估,也許就會有公平的答案。
62. 人們遇到經驗范圍之外的事情,多少有恐懼感,就會認為“這完全不可能”而強烈反對。試著消除這種習慣性的反應,設法給組員灌輸“只要花時間想想看,大部分的事情都做得到”的觀念。您不妨以這個問題來對付那種“凡事不能”的態度:“我了解這是做不到的,但是‘如果’做得到,那你會怎么做?”然后您就會發現驚人的轉變,您馬上就會聽到組員七嘴八舌地說應該這樣做、那樣做,說的是他們剛剛堅持做不到的事情。這個“如果”把他們帶離直覺的反應,帶到全新的思考模式,這才是他們應該做的。
63. 把使用者當作什么都不懂的外行人,是非常不好的觀念。每當您發現有人表露出這種心理,一定要立即糾正,提醒他們使用者才是真正受產品好壞影響最深的人,他們和程序設計師一樣關心軟件的執行速度和質量。
64. 杠桿原理是您最有用的觀念,找到您工作中的杠桿,您可以為小組、項目、公司、甚至軟件業創造無可限量的價值。無論如何,盡量利用資源并創造資源,這個原則是絕對錯不了的。在您寫程序的時候注意程序代碼的共享性、訓練組員的時候注意到他對公司的價值,即使是像函數命名這種小事,都有杠桿的存在。不管做任何事,都要想到“善用資源”,為未來做好準備。
?
[八.沉船的感覺]
65. 如果進度發生落后,那表示有個地方出錯了。您應該找出問題,并加以解決,不要一味要求組員加班,在問題沒有解決之前,加班是沒有用的。
66. 別誤信加班等于增加生產能力,長期的加班只會傷害生產能力,對項目沒有幫助。
67. 周末是屬于組員私人的時間,不是公司的。公司不應該以打敗競爭對手為理由,要求員工周末加班。
68. 強調思考的重要性,而不是長時間工作。
69. 訓練開發小組懂得在正常工作時間內掌握好工作的效率,不要讓他們超時工作,因為超時工作只是浪費時間的假面具。
70. 與程序設計師共同研擬出一份每日活動的時間表,把無法預期的臨時公務變成固定時間處理的事情,并且把程序開發的工作放在最優先的地位,不要讓其他次要的事情干擾到寫程序。
71. 經常加班就是項目出問題的明顯信號,也許是因為主管的觀念錯誤或是目標不夠清楚,不論是什么原因,項目經理絕對不能忽視這種現象,要對這個問題正確處理,項目經理必須協助組員在每周4 0小時的工作時間里,把事情做得更有效率。
72. 我經常聽到高層主管稱贊組員每天為公司工作很長的時間:“您對公司的貢獻值得嘉獎,做得很好!”這絕對是錯誤的信息,員工應該是因為工作做得好而受到稱贊,而不是因為在辦公室待得久,管理者不該把“生產效率”和“工作時間”混為一談,有的人也許可以用更少的時間,完成兩倍的工作呢。
73. 為了讓組員把辦公時間用在正確的地方,并提高部門的工作效率,項目經理不但要為他們排除任何不必要的會議、報告和雜事,還要協助他們好好運用寶貴的上班時間。您應該協助組員安排適當的每日活動表,用一些小技巧,讓組員有長段又不受干擾的時間,適合進行開發工作。
74. 如果您關心組員的生活,就不要讓他們把全部的時間都投入在工作。每天只要確定他們賣力工作了八小時,就可以把他們趕出辦公室了,當然這樣做也許會有老板看不順眼,但是如果您像我一樣相信均衡、健康的生活是一切創意的原動力,就堅持這份理念吧!
75. 每周工作4 0小時并不是金科玉律,只不過是美國的傳統,而軟件開發項目大都以此為前提編定日程表。所以如果一個項目需要程序設計師每周工作40 小時以上才能趕上進度,就表示有問題,也許是日程表定得太樂觀,也許是程序設計師需要再訓練。不管怎么說,這個問題一定要認真解決,絕對不應該讓程序設計師加班來彌補這個漏洞。
2006年6月13日
#
MySQL5支持視圖、存儲過程、觸發器等高級特性了,終于象個完整的數據庫了!
很高興啊,我們做項目的時候選擇性更強了。
不過在我一個實際的網站項目中,發現事實和看上去的不太相同啊。是否支持這些特性和支持得多好畢竟是不同的問題!比如在使用Oracle時,發現在9i上能正確執行的統計SQL到8i上居然報錯,無非是多用了幾個嵌套的子查詢。Oracle尚且如此,MySQL也的確不能有太高期望。
下面列舉一下MySQL5的問題:
版本5.0.16中對視圖進行排序時,會導致服務器崩潰。如:select * from 視圖名 order by 某字段。所幸5.0.21版本解決了這個問題。不過我這只是隨便一用就能碰上這種致命錯誤,誰知道還有多少bug隱藏著呢?
存儲過程更是不太爽。居然不支持遞歸,SQLServer和Oracle都早就支持了。郁悶,在處理樹形數據時,只能寫點固定樹的深度的視圖了。
1.1.20版本的Query browser和1.1.9版本的Administrator客戶端工具穩定性好差,每天能崩個幾回。不過功能比以前強些了。Query browser中多粘貼點SQL腳本就能搞死它;CREATE 某東西,按執行多兩次、或快了些也能搞死它。只能說比沒有強,湊合用吧。
其他基本功能用起來還不錯,沒碰到什么問題。當然MySQL有如此影響力肯定有他獨到之處,對我來說除了免費外就是速度快、用戶群大(則技術支持會比較多),否則可以考慮免費的其他數據庫,如PostgreSQL,它的客戶端工具就專業多了,初步感覺跟SQLServer的差不多了。
2006年6月12日
#
1.歷史上出現的編程方法
? 1)結構化編程
??? 程序應該按自上而下的順序執行,不會做隨便跳轉。主要為了提高可讀性(特別是控制結構的),可自上而下的閱讀代碼,并且執行的順序也大體是這樣的。
??? 它的三個組成部分:順序Sequence,選擇selection,循環(或迭代)repetition (or iteration)。任何控制結構都可以用這三個部分組成。
??? 需要小心使用其他方式如:break,continue,return,throw-catch.
? 2)模塊化編程
??? 將邏輯相關的數據和函數放在一個模塊中。
??? VB中的Module就是這個思想的應用。
??? 它沒有多個實例的概念,相當于面向對象中的僅包含靜態方法和靜態變量的類。不需要實例化即可直接調用方法,只存在一個"實例"。
? 3)面向對象編程
??? 主要特點:封裝(Encapsulation),繼承(Inheritance),多態(Polymorphism)。
??? 封裝:將邏輯相關的數據和方法(函數)放在一個類中。跟模塊化編程做的一致。
??? 繼承:將內容或接口重用,并實現類型的多態。
??? 多態:不同的語義環境下,同一名稱可以有多種不同的實現。
? 具體表現為兩類:
? 同名方法不同內容,實現方式:使用重載(overload),當然方法的參數是不同的;
? 同名類型不同內容,實現方式:使用覆蓋(override)或實現(implement)。允許使用同一接口調用不同類的的實例對象。
2.各種方法的目標
? 結構化編程。重點是是控制結構,可看作是基本程序語句(無子程序)的結構;
? 子程序化編程。似乎沒有相關的歷史潮流,但我認為加入認為的加入它會使整個方法的發展過程更加完整。也許這個大家都認為是當然的了?子程序(或過程、函數、方法)是模塊化、面向對象編程的最重要的基石。
? 模塊化編程。重點是將數據和子程序邏輯相關的組合;
? 面向對象編程。在模塊化的基礎上重點加入了模塊之間的關系。這里的模塊已演化為類。
3.方法體系
? 上述幾種編程方法可以歸為一類,屬于一個方法體系,其重點在于編程本身,力圖有效管理并降低程序邏輯的復雜性。
? 隨其發展,管理的代碼單元越來越大,越來越復雜,其方式也越來越接近日常的思維。
? 其輔助技術或方法有編輯器、調試器、UML、軟件工程等。
? 我認為此體系中新的方法還未出現。現在流行的方法中:AOP面向方面編程,僅是此體系有益的補充;SOA面向服務架構,重點在于用統一的方式調用,而不依賴于底層技術,是組件化的一種形式,這不是這一類的主線方向。
?
4.總結:
????? 以往的編程方法和原則在現代的方法中得到了保留和發展,這對新手是一個挑戰,不循序漸進的學習這些技術,想要短期學會現代方法(如:面向對象編程)是困難的。
????? 記住這些編程方法的主旨是很有好處的。
????? 新的編程方法必將是歷史方法的繼承和發展,所以學好這些舊的方法非常重要。
????? 掌握這些在各種層出不窮的新語言和新工具中不變的精華,或許,你可以不再那么疲于追趕新的技術潮流。
2006年6月9日
#
老婆的堂弟今年要畢業了,老婆本想給他介紹個工作,就問你想做什么工作?回答是什么賺錢做什么,現在不都這樣么?
好熟悉的話!現在社會上的確是這么個風氣。回想當初我畢業時,也基本是這么個態度。不過我當時對本專業基本沒興趣,當時本專業工作也難找,在一個中南地區的省會城市工資3、5百。當然也有好點的1千多,不過那是給成績好的人留的。不是我這種不務正業的主可以觸及的。
當初的考慮是基本上要先能養活自己。獨立!在我心中是第一位的。上大學時,我就已經恥于每月向我爸要300月生活費了。我的考慮是:
- 干本專業如果有人要我,有個5百塊我也就勉為其難的去了。不過由于我不感興趣也就沒有好好學,成績單上是比較難看的,估計不找點門路也不會有人要。總之想來想去這條路可行性約等于0。
- 那我有什么拿手的?好像還有門手藝,倒是玩了4年吉他,也有不少大學畢業的去酒吧唱歌。不過本人嗓子容易啞,不適于干這個職業。
- 我應該找我喜歡干的,又比較能賺錢的。計算機,就是它了。我十分想當程序員,這個名稱對我,那就是一個夢想啊。就跟剛玩計算機時,對“電腦高手”名號之渴望一般。
?結果我走了第三條路。不容易啊,其間辛苦和曲折一言難盡。簡而言之,就是嘗試了考研換行的(考計算機)的路子失敗,賣過10臺品牌電腦5周后試用期后被開除,兩次進過我哥同學的公司干活。成功的是第二次進我哥同學的公司,做ASP+SQLServer開發。
我當時對ASP連聽都沒聽說過。填面試單時,我在期望工資上寫的是500,我想基本上能維持大學生活的水平,夠自己活下去就行了。面試時,那邊就是我哥的同學,他問了些學什么專業之類的問題,我據實以告,他似乎不太滿意。看到我的期望工資時,他有些憤怒,說我們這里3000以下的都不要!后來他想了想,給我的500前面加了個"1",因為這個是公司對畢業生的平均水平。
面試完那個狂喜阿,讓我下周一去上班。我回家時在路上就暗下決心,一定要好好抓住這個機會!給我一個月的試用期,說一個月后水平可以就留下否則就走人。我的壓力很大啊。買本書自己看,項目經理偶爾回來指點一下,前兩周我基本上是在公司自學。后來讓我做個簡單的數據查詢頁面。搞出來就算通過。
過了好多年了,對那時的心情還是如此清晰。感謝我哥和他的那個同學讓我步入了這一行。不容易,不容易。
畢業后的幾年,本專業忽然熱了起來,一點不比計算機掙得少,但是比干編程的輕松多了。真是30年河東,30年河西!不過我基本上對這個選擇沒有后悔,因為我當時也不是把賺錢當作唯一的或者第一的目的。主要是因為喜歡。
所以,逢老婆的堂弟即將畢業、找工作之際,說兩句心里話,不要把錢看作是好工作標準的全部,錢的多少是可變的。綜合考慮行業未來的發展、自身的興趣等多方面因素,才是比較正確的方法。
?
Servlet是在多線程環境下的。即可能有多個請求發給一個servelt實例,每個請求是一個線程。
struts下的action也類似,同樣在多線程環境下。可以參考struts user guide: http://struts.apache.org/struts-action/userGuide/building_controller.html 中的Action Class Design Guidelines一節:? Write code for a multi-threaded environment - Our controller servlet creates only one instance of your Action class, and uses this one instance to service all requests. Thus, you need to write thread-safe Action classes. Follow the same guidelines you would use to write thread-safe Servlets.
譯:為多線程環境編寫代碼。我們的controller servlet指揮創建你的Action 類的一個實例,用此實例來服務所有的請求。因此,你必須編寫線程安全的Action類。遵循與寫線程安全的servlet同樣的方針。
?
1.什么是線程安全的代碼
? 在多線程環境下能正確執行的代碼就是線程安全的。
? 安全的意思是能正確執行,否則后果是程序執行錯誤,可能出現各種異常情況。
2.如何編寫線程安全的代碼
? 很多書籍里都詳細講解了如何這方面的問題,他們主要講解的是如何同步線程對共享資源的使用的問題。主要是對synchronized關鍵字的各種用法,以及鎖的概念。
? Java1.5中也提供了如讀寫鎖這類的工具類。這些都需要較高的技巧,而且相對難于調試。
?
? 但是,線程同步是不得以的方法,是比較復雜的,而且會帶來性能的損失。等效的代碼中,不需要同步在編寫容易度和性能上會更好些。
? 我這里強調的是什么代碼是始終為線程安全的、是不需要同步的。如下:
? 1)常量始終是線程安全的,因為只存在讀操作。
? 2)對構造器的訪問(new 操作)是線程安全的,因為每次都新建一個實例,不會訪問共享的資源。
? 3)最重要的是:局部變量是線程安全的。因為每執行一個方法,都會在獨立的空間創建局部變量,它不是共享的資源。局部變量包括方法的參數變量。
??? struts user guide里有:
??? Only Use Local Variables - The most important principle that aids in thread-safe coding is to use only local variables, not instance variables , in your Action class.
??? 譯:只使用用局部變量。--編寫線程安全的代碼最重要的原則就是,在Action類中只使用局部變量,不使用實例變量。
?
總結:
??? 在Java的Web服務器環境下開發,要注意線程安全的問題。最簡單的實現方式就是在Servlet和Struts Action里不要使用類變量、實例變量,但可以使用類常量和實例常量。
如果有這些變量,可以將它們轉換為方法的參數傳入,以消除它們。
??? 注意一個容易混淆的地方:被Servlet或Action調用的類中(如值對象、領域模型類)中是否可以安全的使用實例變量?如果你在每次方法調用時
新建一個對象,再調用它們的方法,則不存在同步問題---因為它們不是多個線程共享的資源,只有共享的資源才需要同步---而Servlet和Action的實例對于多個線程是共享的。
換句話說,Servlet和Action的實例會被多個線程同時調用,而過了這一層,如果在你自己的代碼中沒有另外啟動線程,且每次調用后續業務對象時都是先新建一個實例再調用,則都是線程安全的。