|
||
|
New Member
加入日期: Jan 2004
文章: 7
|
技術的選擇有些會因為所待的公司產業性質而有所差異
是軟體開發公司? 網路服務公司? 使用者環境(User Side)公司? 這也反應出公司會有怎樣的resource以及技術價值觀,關鍵就在這裡 依我自己的經驗來看 1.用opensource能自行維護甚至去發佈新branch的很少 專案都沒時間了,除非自己利用工作外的時間 所以大多習慣有原廠的support 2.如果只看跨國企業來說,那就有點各說各話了 這裡是台灣自然以國內情況為主,至少在國內的需求上, RDesign說的沒錯 而且linked上有些跨國企業也都專門找台灣的.NET人才,都是做高承載量平台的產業 3.用單一技術方案或混合多種技術方案? 個人比較傾向後者,因為每種技術各有特色 4.YAHOO可是有個B2C電商系統服務是用.NET技術平台,還有個上到Azure去 連知名台灣趨勢的技術主管還是看媒體才知道自家公司也有在用微軟技術平台 5.個人私心覺得過去和現在太多人神化JAVA技術的優點了, 大概僅次於神話APPLE XD 還會跟我靠北 VS 太肥太慢, eclipse才肥才慢. 原來要好的效能JVM還要另外付費? 這不是跟萬惡微軟一樣嗎? 而且JVM的安全性也愈來愈差.
__________________
台灣人最大的悲哀是,只認顏色,不看專業,心中有黨,卻沒有國. 直到2014年才有了改變 |
|||||||
2014-11-16, 10:53 AM
#61
|
|
|
*停權中*
加入日期: Mar 2011
文章: 1,522
|
這串感覺越來越像占卜文
 越來越和某數字站的業代們爭論tesla和牛頭牌的純電動車誰好誰壞一樣 市場就是供給和需求的最後加總的結果 那就過個幾年看看dotNET還能否保持現在這副德性 還是要屈服於市場機制搭配xamarin讓自己和java一樣慢 若最後dotNET的走向是xamarin 這串結果也不言而喻  |
||
|
2014-11-16, 03:47 PM
#62
|
|
|
Master Member
  
加入日期: Jan 2003
文章: 1,591
|
引用:
他的意思是 出事了有問題,找誰扛?找誰背黑鍋? 自己改!?那就準備黑到發亮,電到九重天 幸運的話還可以享受最新版的逆境人生阿 
__________________
So you walk eternally through the shadow realms, standing against evil where all others falter. May your thirst for retribution never quench, may the blood on your sword never dry, And may we never need you again. |
|
|
2014-11-16, 04:41 PM
#63
|
|
|
Regular Member
 加入日期: Jan 2011
文章: 64
|
引用:
上線之前應該都會跑過test case。 上線之後如有網友提到的，應該是不會有人沒事去做更動。 但是假如在不是專注於軟體工程的公司(不做test case等等)，那思考的方向是就不一樣。甚至應該早做好準備。 參與opensource專案是不錯的能力提升及加深團隊合作觀念，但是台灣很難會有人有時間以及公司不鼓勵。 剛剛看了一篇文章，科學家分析數千對情侶，終於找到美好長久愛情的終極秘訣 。 重要的應該是說溝通的方式所造成的差異。 |
|
|
2014-11-16, 06:29 PM
#64
|
|
|
Junior Member
加入日期: Jun 2003 您的住址: CC BY-NC-ND 4.0授權
文章: 797
|
引用:
|
|
|
2014-11-16, 06:54 PM
#65
|
|
|
*停權中*
加入日期: Mar 2011
文章: 1,522
|
引用:
看這邊一下 https://github.com/alibaba 小弟無法反駁您的說法 因為小弟的工作環境就是這樣!! 老闆要速成，不需要員工創新!! 誰要創新就等著黑到發亮 等著回家吃自己!! 身為一個在基層的台灣人 看到對岸這樣鼓勵創新 自己需要的全部重新創造一遍 還會發到github與世界分享 自己對於自身工作大環境除了默默接受 也有與L兄一模一樣覺悟，為了那份薪水，選擇沉默 |
|
|
2014-11-16, 08:26 PM
#66
|
|
|
Silent Member
加入日期: Aug 2013
文章: 0
|
引用:
說真的， 寫軟體的都知道， 沒有所謂的一次到位， 寫再多的test case也是有沒cover到的case。 很多年前寫EJB的時候， 程式已經上線了， 結果偶爾jboss會當掉， 看stacktrace也看不出所以然來， 完全沒人可以問， 後來忘記怎麼trace出來的， 原來是資料庫的locking導致entity bean的讀還是寫crash， 這種case怎麼test， 不要開玩笑了。 |
|
|
2014-11-16, 09:26 PM
#67
|
|
|
*停權中*
加入日期: Mar 2011
文章: 1,522
|
引用:
不行嗎? 那java exception: SQL Error: 1213, SQLState: 40001 是怎麼產生的呢?  有些除錯是靠經驗還有足夠的壓力測試 deadlock問題本來就要靠壓力測試夠多次才看的到 此文章於 2014-11-16 09:35 PM 被 csshih 編輯. |
|
|
2014-11-16, 09:34 PM
#68
|
|
|
Silent Member
加入日期: Aug 2013
文章: 0
|
引用:
老大， 如果有這種error message， 問題很容易解決好嗎？ 而且stress test一定會測的出來嗎？ Test environment和production的load怎麼可能一樣， 如果你寫的程式都是一次到位， 那我服了你。 |
|
|
2014-11-16, 09:43 PM
#69
|
|
|
Junior Member
加入日期: Feb 2013
文章: 757
|
引用:
深表同意  |
|
|
2014-11-16, 09:48 PM
#70
|
|
