Feeds:
文章
留言

Archive for the ‘工作感想’ Category

原文連結:http://www.eettaiwan.com/ART_8800559985_480102_NT_22572e2d.HTM

1. 產業界必須接受以下現實──消費性電子IT產業與娛樂產業實際上已經融合,而且一定會繼續“無縫互動”。

2. 消費性電子產業必須成為一個「加強服務」型產業,否則就會落伍。

3. 消費性電子產品必須要是多功能的,也就是讓消費者能在不同的環境中使用;

4. 要實現第三項策略,廠商必須支持開放性技術。「消費者都希望有所選擇,」Stringer表示:「他們也希望所使用的裝置能與其他裝置一起工作。」

5. Stringer指出產業界應提升透過不同設備連結網際網路的體驗

6. 各家廠商應朝著「更佳的使用者體驗」這個目標繼續創造新價值,例如藍光(Blu-ray)與HDTV即是這個策略的展現

7. 消費性電子產業應該擁抱綠色科技

Read Full Post »

依據收入排行的前15名證照

Read Full Post »

今天到恆逸上了一天的 Silverlight 課程,主講人是呂高旭,我個人覺得呂老師課上的相當好,整個課程安排相當流暢。課程先從綜覽整個 Internet 技術,讓大家對常見技術有全面性的了解,然後談到 Silverlight 嘗試想要彌補目前技術上的缺口。接著說明 Silverlight 架構,使你可以了解 Silverlight 支援功能、運作架構以及未來的走向。

以上的主題都比較偏向概念性,再來談論的是比較偏向實務 XAML 與 Javascript,當然免不了的談論到 Silverlight 中文支援問題(這已經算是 FAQ)。也說明 Expression Blend 2 與 Visual Studio 2005 如何讓設計人員與開發人員協同合作。畢竟是 Microsoft 技術,最後談論的是 ASP.NET、AJAX 與 Silverlight 技術整合。

雖然,已經參加兩個研討會,也看了兩本 Silverlight 書,基本上談論的主題與技術都差不多。不過,今天課程仍讓我再次完整的將 Silverlight 快速複習一遍。基本上 Silverlight 1.0 技術我個人覺得不是什麼困難技術,畢竟只是 XAML + Javascript。我覺得真正門檻在於"創意",這有點像在畫圖,雖然每一個工具都會用,但有人可以畫出漂亮的風景畫,有人畫的就像小孩塗鴉 orz 。 所以,我想還是先多觀賞經典的 Silverlight 作品尋找靈感~

目前 Silverlight 1.0 已經可以作許多事情,不過我更加期待 1.1 版,因為到時 Silverlight Runtime 內建 CLR,可以充分利用客戶端的運算資源,想必到時開發人員可作的應用將會更加豐富。另外,目前最好的 XAML 設計工具應該就是 Blend 2,不過,我覺得該工目前有一個很大問題,就是缺少元件庫。如果,我設計了一個很棒的按鈕,每次要應用到專案中,都需要從另一個專案 Copy & Paste 過去,那真的是很不方便,如果可以像 Visio 將元件直接放置在元件庫重複使用,那就方便許多。我想未來應該會有這個功能才對,不然應該也會有人和我有相同的感受,而去寫個附屬程式 ^^

Read Full Post »

來源:電子郵件,真正出處不詳

那是義大利一個電信公司招考部時所發生的一段小插曲。據說,招考部的筆試結束後,這家公司發給所有甄選通過的人一袋綠豆種子,並且要求他們在指定時間,帶著發芽的綠豆回來,誰的綠豆種得最好,誰就能獲得那份競爭激烈、待遇優渥的工作。

果然,當指定時間來臨,每個人都帶著一大盆生意盎然、欣欣向榮的綠豆芽回來,只有一個人缺席。總經理親自打電話問這人為何不現身?這人以混合著抱歉、懊惱與不解的語氣說他感到抱歉:因為他的種子還沒發芽,雖然在過去那段時間,他已費盡心血全力照顧,可種子依然全無動靜!「我想,我大概失去這個工作機會了。」據說,這是那唯一的缺席者,在準備放下電話前所說的一句話。

但經理卻告訴這孵不出綠豆芽的男子說:「你,才是唯一被我們錄用的新人!」

原來,那些種子都是被處理過的,不可能發芽。種不出綠豆芽,正證明了男子是一個不做假的人,公司高層認為,這樣的人必也是一個有道德操守的人。「而這」,總經理說:「就是我們用人的唯一準則!」……

有一句西方諺語說:「如果表現卓越是魚的話,那麼操守就是保鮮劑!」這話的意思是,工作追求卓越固然重要,但不講道德操守,一切都可能落空。就像一條魚,再怎麼美味,沒有保鮮劑,最後還是會腐爛。

同樣,那些志在必得的應徵者,所捧出的綠豆芽雖無比美麗茂盛,但不曾以誠實做為人格的保鮮劑,最後,他們終還是失去了那努力爭取、夢寐以求的工作。

——

不論這則故事是不是真實發生,聖經中也有提到"你們的話、是、就說是.不是、就說不是.若再多說、就是出於那惡者。(馬5:37)",所以,憑著你的良心作你該做的事情,其他的交給神吧~

Read Full Post »

      今天看到這句話,真是寫的太好了。很多人常常會想,以前學校學的東西在職場上好像都用不到,這句話我覺得在80%的情況下好像是正確的,除非你遇到的問題是比較深入的,也就是如標題的這句話。

      當找不到問題的原因時,常常會想"為什麼會這樣呢?",這句話的背後可能就代表我們可能缺乏某些基礎知識來解決問題。由於本身非程式科班出身,常常覺得多東西都不瞭解,尤其是作業系統這麼龐大的東西,一堆專有名成語概念總是把我弄的頭昏眼花。不過,瞭解作業系統的運作,對於程式撰寫與程式運作的瞭解是很有幫助,雖然,一個問題解法有很多種,為什麼有的人解法精簡而且漂亮,有的人卻寫的又臭又長且執行效率也不佳。所以,"當問題無解時,回去念理論"是遇到瓶頸時的一個解決方向。

Read Full Post »

兩篇獨孤木的雞肋文章

真是深得我心的兩篇文章,兩天文章依然不改獨孤木的本色

食之無味 棄之可惜
安心啃雞肋還是…?

Read Full Post »

[轉貼] 豬排VS績效

摘自電子郵件,如有侵犯您的著作權請通知我,謝謝

  話說….
 在一個農莊裡有一隻豬,擁有多項技能,
 牠會一大早學公雞叫主人起床;
 牠會學貓去抓偷吃起士的老鼠;
 牠會學牧羊犬去管理羊群….
 其他動物問牠幹嘛這麼雞婆,牠說:
 "你們這些笨蛋!在現在這個社會,沒有多項技能怎麼可以生存!況且我這些技能還有證
 哦!"  (  可不是 CAS 喔!!!  )
 可是有一天,主人還是把豬抓起來,準備宰了牠.
 豬不可置信的問:
 "我會這麼多技能,又幫你做那麼多事,為什麼你還是要殺了我?"
 主人淡淡地回答:"沒什麼!我只是想吃豬肋排……."
 
 (績效在於老板認為你該做什麼, 而不是你會做什麼)


最後一句說的太好的,對於基層員工來說,反正你做的再多給的再多,不是他要的他都覺得是 garbage
所以,先弄清楚他要什麼再努力吧,否則只是徒勞無功白忙一場…
反觀如果是主管,是否應該明確讓部屬了解目標是什麼,否則他一定會越來越無力,最後可能導致出走,我想這就是公司或團隊的損失。

Read Full Post »

今天看了 Taiwan.CNet 上的"Mozilla自己人看Linux桌面"這篇文章,文中提到許多重要但工程人員常常忽略的問題,我簡單的歸納為兩點,

 

首先是資料轉移,其實以我個人的觀點,我覺得資料是比程式重要的多,所以,資料的遺失比程式損毀更讓我懊惱,因此,如果新軟體沒有沒有提供平滑、無縫的轉移工具,很難讓我放棄原先建立完整的資料,想像一下,假如你的 Outlook 收信程式已經建立 100 個或更多的好友名單,此時如果有一套名為 Turbo Outlook,功能完整、安全性極佳但無法將原先的資料作移轉,我想一般使用者想到要重建好友名單就會怯步,更遑論成為你的長期用戶,頂多只是吸引一些玩家使用。

 

第二點是軟體的易用性,他提到工程師和使用者的不同觀點,如下:

"開發員或許認為盡可能地重複利用程式碼很酷,但使用者才不關心究竟是Linux沒有包含必要的相容元件,還是Mozilla沒有在某一小版的 libstdc++作好相容的工作。一般使用者期望能夠下載軟體、安裝,然後立刻使用。要求他們瞭解複雜的系統庫和核心相容性問題,是送他們離開的最快途徑。"

 

他說的相當的好,一般使用者重視的是能否趕快解決問題,所以,他才不在乎你的內部運作或架構,因為,他們不懂 domain knowledge 也不在意。但是,工程師的觀點則是較為重視架構、效能,而常忽略軟體的易用性,我個人的經驗是,會發生這個盲點大多是因為自己不是軟體的使用者,所以,他不了解操作三個步驟完成一個工作和操作兩個步驟完成一個工作的差異,如果你是使用者一定會說"怎麼這個流程設計的這麼差啊!"。另外,易用性方面也需要向資料轉移一樣,將使用者的操作流程移轉,舉個例來說,如果你有用過 Borland C++ Builder 你就會知道,他有提供一個 Microsoft Visual C++ 環境的配置,讓你的操作和 VC 一樣,使得VC開發人員可以快速的在 Borland C++ Builder 上完成他的工作,所以,一個好的軟體應該能夠在資料和操作流程上相容舊有的軟體,當然功能面也有其創新之處,我想就能夠吸引廣大的使用者群。

 

 

Read Full Post »

分離與耦合

近來工作上的技術已經能夠掌握,也比較能夠以自己的設計思維來設計系統,另外,也因為發現Javascript可以使用OO來設計(雖然不像C++嚴謹),所以,我一直再嘗試將部分常用的元件以 Javascript 來包裝,使得 DHTML 的設計可以如同Windows設計上靈活彈性。舉個例子來說,如果我需要一個按鈕和一個標籤,我可以利用CButton 和 CLabel 類別來完成,如下:
 
<label for = ‘btnAdd’ id = ‘lblMessage’></label>
<input type = ‘button’ id = ‘btnAdd’>
<script type = ‘text/javascript’ src = ‘OOHTML.js’></script>
<script type = ‘text/javascript’>
<!–//
var btn = new CButton(‘btnAdd’);
var lbl = new CLabel(‘lblMessage’);
btn.setText(‘hello’);
btn.OnClick(
  function (){
    alert(‘hello, javacript OO’);
  }
);
lbl.setText(‘click button’);
//–>
</script>
 
 執行結果
設計一個簡單的程式,點按鈕就會出現訊息 ‘hello, javascript OO’
從這個簡單範例中可以看到,這個程式的設計和一般 Windows (ex: C#)上的設計風格很相像,當然Windows上有 Form,上面的範例沒有,基本上我也實作了 CForm,不過還尚未達到我的想法,但仍堪用如下
<form id = ‘frmTest’>
 <fieldset>
  <legend>OO測試</legend>
  <label for = ‘btnAdd’ id = ‘lblMessage’></label>
  <input type = ‘button’ id = ‘btnAdd’>
 </fieldset>
</form>
<script type = ‘text/javascript’ src = ‘OOHTML.js’></script>
<script type = ‘text/javascript’>
<!–//
 CFormEx = function(id){
  this.base = CForm;
  this.base(id);
  var btn = this.getButton(‘btnAdd’);
  var lbl = this.getLabel(‘lblMessage’);
  //var btn = new CButton(‘btnAdd’);
  //var lbl = new CLabel(‘lblMessage’);
  btn.setText(‘hello’);
  btn.OnClick(
    function (){
   alert(‘hello, javacript OO’);
    }
  );
  lbl.setText(‘click button’);
 };
 var aform = new CFormEx(‘frmTest’);
//–>
</script>
 
 
 
以上的範例只是說明,我個人覺得相關元件包裝成類別後,可以有效的重複利用,協同作業也會比較方便,開發上也較為彈性。而且元件包裝後,要組合建立一個新的元件也更容易,以我目前案子中常用的日期選擇(由三個ComboBox組合),我以 OO 的方式包裝成 CCalendar,我使用上只需要
var aDate = new CCalendar(‘begnDate’);
aDate.initComponent(); // 產生 UI
aDate.setToday();// 將日期設定為今天
alert(aDate.getValue()); // 取得目前的日期 yyyy/mm/dd
 
var aDate2 = new CCalendar(‘endDate’); // 第二個 Calendar
aDate.initComponent();
 
上面的範例是連同 UI 的部分一同包裝,使得設計上可以輕易的建立多個相同物件。充分達到’重複使用’的效益。且包裝後的網頁大小也能縮小,在網路傳遞所需的頻寬也能降低。
 
上面說明包裝後所帶來的效益,但是負面影響呢?
第一個副作用也是一般OO的副作用"效能",不過我覺得這個問題會漸漸的不存在,因為Javascript是屬於Client端的技術,且現在的硬體技術又相當的發達,這個OO的效能將會逐漸不存在。
 
第二個是元件的設計需要花費而額外的時間來設計,不過從長期的角度來看,這個投資是值得的,但是有個前提是這個元件的重覆使用率很高,如果使用率不高,是否需要發費時間去特別包裝城物件,這個是需要評估的。舉個例來說,如果你只是需要點選按鈕時將網頁導向 http://www.google.com.tw,是要採用下面哪一個呢?
1. 寫一個繼承 CForm 的類別,並在其中包裝這個按鈕
2. 直接使用 CButton 包裝這個按鈕
3. 用傳統的 DHTML 寫法,<input type = ‘button’ onclick = ‘document.location.href=http://http://www.google.com.tw’&gt;
 
從開發時程的角度來看是 3 最快/2次之/1最慢。但是從系統維護的角度來看,1是最具有彈性/2次之/1最差。所以,並沒有那一個好那一個差,只是很單純的看你的考量如何。
 
分離好還是耦合的好呢^^
 

Read Full Post »

軟體工程是啥~

我不是資工科班畢業,對於軟體工程不甚了解,但是基於個人興趣的理由,自修相關的專業,目前也在從事這方面的工作。進入公司已經將近半年了,也負責公司的一些專案,一直有一些感想。看到專案中的有些程式都有一些不錯的設計,可惜其他的人沒有發現而未沿用,真的是頗可惜。

我是不懂軟工,不過對於程式寫作也有好長一陣子了,我的經驗告訴我,沒有結構化的程式,維護和修改是備感艱辛,另外,由於專案的程式都混和多種語言,所
以,使得維護和修改更加困難,由於沒有像 Microsoft Visual Studio
一類的IDE,所以,每一次的修改都是一種痛苦的煎熬。使得我不太想修改舊有的程式,而想自己重寫一份… 啊~
這是大部分人的想法吧。不過,重新設計也是有風險,如非必要我不會如此做 -_-b

回到主題吧,我想公司裡面應該有許多科班畢業的專業人士,為什麼都沒有人把這些寫的很棒的程式碼進行整理呢?或是設計的好一點或是設計的好一點,怎麼程式
都像義大利麵一樣糾纏再一起呢?恩~
可能時間不夠,或是…不過,目前既然是我接手,為了讓未來的日子輕鬆些,目前我持續的再將相關的程式碼收集成類似 C/C++
的函數庫,以達到程式碼重複利用和減少錯誤發生的機率,並進而達到工作效率的提昇。我想這是很基本的工程概念吧。可是,為什麼產品會設計成這樣ㄋ~

算了… 留給主管去煩惱吧…. 我只是個微不足道的工程師…. ^^

Read Full Post »