Google自訂搜尋

目前分類:囉唆~ (162)

瀏覽方式: 標題列表 簡短摘要
就在剛剛,我終於終於終於終於終於找出為什麼會出現錯誤的原因了
原因就是,幹!lib/底下少兩個檔案!
1. authenticated_system.rb
2. model_extensions.rb

剛剛跑去svn,也沒看到這兩隻檔案
hacking code也沒看到會產生這兩隻檔案
generate後,也沒產生這兩隻檔案!!!!!

不知道是Bill Katz有改版還是怎樣
他的sample抓下來,跟他release的版本,好像有些許不同?
吼!


in app/controller/applications.rb:

class ApplicationController < ActionController::Base
  include AuthenticatedSystem
end

要使用必須加上這個
沒有加的話,會產生undefined local variable or method
加上去,少了authenticated_system.rb的話
會產生uninitialized constant AuthenticatedSystem什麼的

真是該死
終於好了..
開始開發拉XD
不過得先去睡覺...

Night all...

For piggy:
  別太傷心拉... >"<

hechian 發表在 痞客邦 留言(0) 人氣()

我好像有蠻多問題的... 囧
全文轉貼至:http://blog.xuite.net/gmi279/ourbaby/7949932

知識分子「英年早逝」問題,一直受到社會各界的廣泛關注。一代精英因過勞累而英年早逝,對家庭,對社會都帶來了巨大的損失。同時,也為中年人過度透支,拉響了要關注身體健康的警報。

   「過勞死」即過度勞累導致的死亡。國際定義「過勞死」是因為工作時間長,勞動強度加重,心理壓力大,存在精疲力竭的亞健康狀態,由於積重難返,將突然引 發身體潛在的疾病急性惡化,救治不及時而危及生命。據報導:日本每年約有1萬人因過勞而猝死。猝死又稱急死,醫學定義為:1小時內不明原因的突然死亡都屬 於猝死。相當一部分人是在睡眠中發生,尤其是凌晨2點~4點,其中80%的人都是由於心臟問題引起的。「過勞死」和「猝死」發生病因和時間上有所不同。 「猝死」發生從出現不適到死亡的時間非常短,而「過勞死」可能因心血管疾病或是腦出血引起,它不是短時間突發,通常會持續一段時間或幾小時甚至幾天。「過 勞死」和「猝死」發病都有提前預知症狀,遺憾的是被眾多的發病者所忽視。「過勞死」和「猝死」一般在發病前都會有短暫的胸前區劇烈疼痛的心絞痛的典型症 狀,或是覺得咽部哽噎不適,吞東西費力;還有人會有伴有出汗,出現3~5分鍾的胸悶,最常見的預兆是渾身無力,胸悶。而這些症狀常被中年人所忽視,尤其是 有心血管疾病自己不知道。更多的中年人則認為身體好,即使過度透支體力偶感不適,認為休息一下便沒事了,殊不知這些疾病先兆被疏忽,使之付出了生命的慘重 代價。

  所以,定期健康體檢對於中年人來說並不是一件多餘的事,並且工作、學習要勞逸結合,避免過度勞累。「過勞」的表現主要是不能安靜下來,日常有慢性致病因素積累而難以消除,也不易用咖啡等興奮劑緩解,尤其應引起大家注意的是:「過勞」是疾病的前奏。

  研究者認為:在這27項症狀和因素中佔有7項以上,即是有過度疲勞危險者,佔10項以上就可能在任何時候發生「過勞死」。同時,在第1項到第9項中佔兩項以上或者在第10項到18項中佔3項以上者也要特別注意,這27項症狀和因素分別是:

  1.經常感到疲倦,忘性大;

  2.酒量突然下降,即使飲酒也不感到有滋味;

  3.突然覺得有衰老感;

  4.肩部和頸部發木發僵;

  5.因為疲勞和苦悶失眠;

  6.有一點小事也煩躁和生氣;

  7.經常頭痛和胸悶;

  8.發生高血壓、糖尿病,心電圖測試結果不正常;

  9.體重突然變化大,出現「將軍肚」;

  10.幾乎每天晚上聚餐飲酒;

  11.一天喝5杯以上咖啡;

  12.經常不吃早飯或吃飯時間不固定;

  13.喜歡吃油炸食品;

  14.一天吸菸30支以上;

  15.晚上10時也不回家或者12時以後回家佔一半以上;

  16.上下班單程佔2小時以上;

  17.最近幾年運動也不流汗;

  18.自我感覺身體良好而不看病;

  19.一天工作10小時以上;

  20.星期天也上班;

  21.經常出差,每週只在家住兩三天;

  22.夜班多,工作時間不規則;

  23.最近有工作調動或工作變化;

  24.升職或者工作量增多;

  25.最近以來加班時間突然增加;

  26.人際關係突然變壞;

  27.最近工作失誤或者發生不和。

  針對如何擺脫過度疲勞,一些專家開出如下處方:

  消除腦力疲勞法:適當參加體育鍛鍊和文娛活動,積極休息。如果是心理疲勞,千萬不要濫用鎮靜劑、安眠藥等,應找出引起感情憂鬱的原因,並求得解脫。病理性疲勞,應及時找醫生檢查和治療。

  飲食補充法:注意飲食營養的搭配。多吃含蛋白質、脂肪和豐富的B族維生素食物,如豆腐、牛奶、魚肉類,多吃水果、蔬菜,適量飲水。

  休息恢復法:每天都要留出一定的休息時間。聽音樂、繪畫、散步等有助解除生理疲勞。

  科學健身方法:一是有氧運動,如跑步、打球、打拳、騎車、爬山等;二是腹式呼吸,全身放鬆後深呼吸,鼓足腹部,憋一會兒再慢慢呼出;三是做保健操;四是點穴按摩。

 

hechian 發表在 痞客邦 留言(0) 人氣()

說真的... 真的很感慨
在一堆人擁護微軟的同時
有沒有想過,OpenSource帶來的效益是什麼?
看過我其他的文章的人,應該知道
我以前玩過VB
後來走向PHP,玩PHP跟PHP/TK PHP/GTK
也走過Perl,Perl/tk
後來再走向Ruby(其實我摸Ruby比摸PHP早,只是Ruby在之前很少關心)
現在沈浸在Ruby內,不可自拔XD

不要拿OpenSource的東西文件很少來搪塞,來當作是理由
OpenSource的文件為什麼少?不!它根本就不少!相反的還有可能多!
之前回去以前的高中,跟電腦老師聊了一下
他說,微軟的文件很多阿
可是我反駁:"中文文件多,不代表文件多,相反的,Linux在網路上隨便Google都是文件"(當時在談Linux)

我相信在短期內(至少這幾年內)英文文件絕對更新得比中文文件快!
而身為一個開發人員,看英文是在所難免的!
接觸OpenSource,你可以得到更多的東西!
看看Rails,跟任何一個東西比起來,生產力我相信一定最高
你還可以隨心所欲的去改它的原始碼,變成最適合你的工具
PHP可以,JSP呢?ASP?ASP.NET?

現在,Nitro!,這是影片:http://www.nitroproject.org/videos/nitro.html

Nitro又更加簡單!
我相信Ruby on Rails影響到很多人
cakePHP、Nitro等等好用的工具都出來了
這些,全部都是Open Source的產物
然後,Nitro這麼棒!DHH(Rails的作者)有可能坐以待斃嗎?NO!我相信他會去翻Nitro的Source,然後在未來的版本作更新!
因此,Nitro也有可能在Rails中看到影子!
不過我相信多少有些.. Nitro出來也有段時間了(晚Rails兩個月多吧?)

Ubuntu Linux出來之後
又多了Kubuntu、Edubuntu、Xubuntu
還有其他的
而我之前原本打算向Ubuntu-TW的Leader:BlueT尋求協助
製作Rubuntu (Ruby Ubuntu)
可是... 我還沒來得及跟BlueT說這件事情,剛剛在Railscn的Gtalk群組上有人發了這個Link:http://brainspl.at/articles/2006/02/16/rubuntu-is-almost-born
我暈了...=  =

不過,這也印證了Open Source的好處
好在哪?好在我可以自由的做出、分享適合我的東西!
好在我可以讓我工作方便的東西!
好在.. 這個社會可以透過Open Source的截長補短的能力不斷進步!

hechian 發表在 痞客邦 留言(0) 人氣()


hechian 發表在 痞客邦 留言(0) 人氣()

這網站看起來真不錯:P
網址:http://demo.script.aculo.us/

裏面有幾個不錯的Demo
而且都有釋出原始碼

用Rails真的很快Orz..
像是第一個範例
Autocompleting text fields (basic)

程式碼兩行(一行在view,一行是controller)就搞定

第二個也是扯
上面
To:那邊輸入A
CC:輸入B
輸入一個字後先等著不要離開,它就會出現suggestion了..

hmmm... 真是好玩!

hechian 發表在 痞客邦 留言(0) 人氣()

不是我在說... 這種人還真夠機車的= =..


影片網址:http://failover2.cdn.hinet.net/xuite/1/6/4/1/12240006/blog_359532/dv/7318459/7318459.wmv


hechian 發表在 痞客邦 留言(0) 人氣()

去死拉!!!
Getting Start貼完就給我出事情喔=   =
阿?你問我出啥事情?

自己看上面=  =

hechian 發表在 痞客邦 留言(0) 人氣()

文章引用至


Getting Real 是 37signals 最近出版的一本電子書, 內容探討開發 web application 的方法及經營策略. 蠻顛覆一般傳統軟體工程所學的. 聽說已經賣了 6000 多本, 大家當做求取新知看看吧!

大致把書上 Table of Content 放上來, 相信看完後你們會有一些新想法!

  1. 起跑線
    • Build Less(少功能, 少人開發, 少廣告…), 了解你的問題? 自己投資
    • 要在時間及預算內完成, 些許的彈性(減少你的功能)
    • 找個敵人給自己. 不要把它當雜務事
  2. 保持苗條
    • 越是苗條越容易改變, 不要混亂. 降低你的變動成本
    • 只要 3 個員工就可開始(RD, designer, sweeper)
    • 要能接受限制, 你的計畫就不會失控, 還有就是樂於當你自己
  3. Priorities
    • What’s the Big Idea, 忽略細節吧
    • It’s a Problem When It’s a Problem
    • Hire the Right Customers, 慢慢擴充, 做個堅持己見的計畫
  4. Feature Selection
    • 一半就夠了, 但要好的那一半
    • 開始說 “No”, 你處理的來嗎?, 讓使用者自己想解決方案, 忘記 Feature Requests 吧!
  5. Process
    • 開始寫程式及 demo 結果, 反覆的修正更改, 開始把想法寫出來, 不要有 “設定/Preference” 功能,
    • “完成啦”, 直接進入網路世界測試
  6. 組織運作
    • Unity, 要有單獨(不被打擾)的時間
    • 開會絕對是毒蘋果, 慶祝你計畫上可能的小小勝利
  7. 員工
    • 僱用少一點人或晚一點開始雇人
    • 做事而不是高談, 不要掩飾你的熱情
  8. 使用者介面設計
    • 一切從使用者介面開始, 從中心畫面開始往外
    • 要考慮正常使用, 新增時空白及錯誤時的畫面, 要有一致性
    • 使用者介面才是你的著作權
  9. 寫程式
    • 用少少的軟體(可以依賴 opensouce), 快樂至上, 讓程式自己說話,
    • 你寫的程式可能是負債, 要小心謹慎
    • 讓資料可以透過 RSS, API 和世界連結
  10. Words
    • 沒有 Functional Spec
    • 不要寫常常過期又沒用的文件,
    • Tell Me a Quick Story, 給你的計畫命個名
  11. Pricing and Signup
    • 免費使用, 使用者容易加入及取消
    • Silly Rabbit, Tricks are for Kids
  12. Promotion
    • Hollywood Launch, 建立一個網站能介紹你的產品
    • 利用 Blog 的力量, 早早提供一些消息吸引大眾, 追蹤你程式內 log
  13. Support
    • 讓開發人員感受 Support 的痛苦, 免訓練即可用(也不用 manual, 只要有 online help & FAQ)
    • 快速回答問題, 不用害怕跟客戶說 “No”
    • 善用 Forum
  14. Post-Launch
    • 每月可以調整一下程式, Keep the Posts Coming, 讓程式更好而不是 Beta
    • 所有 Bugs 要分輕重緩急, Ride Out the Storm, Keep Up With the Joneses, Beware the Bloat Monster, Go With the Flow

軟 體/網站人員應該對這些新看法覺得蠻有趣的, 看到專案市場常常有人在抱怨, 但有一些人已經開始採取另外的作法. 不像現在軟體公司養那麼多人, 都快要進入恐龍級了, 為了獲利只得外包到人工便宜的地方, 不然就是壟斷那塊市場, 或許他們是因為網路公司的背景, 讓他們有如此不同的看法吧! 這些理念及經營手法多少可以從 37signals 及一些新興的 web 2.0 網站看出來

 

hechian 發表在 痞客邦 留言(0) 人氣()

跟網友聊天
他羨慕我,有一群黑友

黑友?我想我得澄清一點..
不!我們不黑!
我們在追求什麼?有人知道嗎?
或許方法錯了
或許你們思想錯了

我們真正在追求的
是自身的極限
知識的盡頭

熱愛技術不是一種錯
為什麼會黑?
知識,不是只有人家給予
也不是自己去找尋
而是鑽研!

有一個環境,我感受到它有弱點
我模擬不出來.. 你總不可能叫我直接mirror你整台主機吧?
因此,我開始鑽..
成功我幸,失敗我命
我不會因為失敗而瘋狂攻擊
We are not the crackers!

什麼叫黑客?
什麼是黑站?
入侵、破壞,這就是黑客嗎?
入侵不是目的、破壞不是嗜好
目標是:得到不同的思維

前面有障礙,我該怎樣將障礙移除?
前方的障礙,要怎樣繞過去?
在學習的,不是得到權限後怎樣惡搞,那太無趣了不是嗎?
過程是享受、結果是成就
我們要的是成功後的知識
知識就是我們的目標

如果你把Hacking當成炫燿的手段
很抱歉,去找Crackers學習吧...
Hackers不會太歡迎你..
就算是Black hat Hackers也不會..
因為他們也是以追求知識為目標(雖然手段有點.. 不是那麼溫柔)

重複一句話...
We are not the crackers!
我相信...
Wikipedia中... 會告訴你..

"What is Hacker...."

Oh.. by the way...

Hacker的含意很多唷:P

hechian 發表在 痞客邦 留言(8) 人氣()

那天..
我看到朋友的MSN
狀態讓我感到很無言..
說真的,我這個作朋友的不知道該怎樣跟他說..
他狀態上這樣打著...





『薏仁做事薏仁湯,小叮做事小叮噹』

我咧!@#^$&&(T%*&^^(^(咧....

hechian 發表在 痞客邦 留言(2) 人氣()

哈,上禮拜六同學會,我拖到現在才寫
Orz.. 忙咩,不好意思...=  ="

嗯.. 前一天晚上,天讚召開緊急會議
紀豪居然沒有訂到位...=  =
哈,這下爽了!剛好威序線上,就叫他跟他哥說一下,明天改到麥當勞。
第二天,就開始舉辦同學會拉~
嗯.. 在我看來,同學都沒啥變嘛
除了建華變瘦(結果像台灣黑熊)、國全變高(嘿.. 帥哥)、我變胖(我知道錯了...)
除此之外... 都沒變耶@@"

嗯=  ="
糟糕,我該寫什麼=  =""


hechian 發表在 痞客邦 留言(2) 人氣()

文章授權模式: CC-BY-SA
http://creativecommons.org/licenses/by-sa/1.0/
文章來源:http://blog.istudio.idv.tw/archives/000204.php
文章內容:


本篇是翻譯自 Casey Kochmer 的「USING XHTML IN JSP, ASP AND PHP WEB SITES」一文。因該文原網址已遺失,我只貼上我之前看完後稍加整理的部份。

原則:

  1. HTML 標籤統一用小寫,千萬別動到大寫英文字母。
    ex. 錯誤的示範:

    ,

    (印象中某 M 牌出品的「前頭頁」會犯這種錯誤)
    ex. 正確的示範:
    ,

    ,

    (印象中另一個 M 牌出品的「織夢者」會自動用這個正確用法)
  2. 別亂擺 HTML 標籤。有的瀏覽器還是可以看到正確內容,但在 XHTML 中可是會出問題的。
    ex. 錯誤的示範:



  3. hi
    很明顯地, 放錯地方了,但有的瀏覽器還是排除萬難秀出了表單。通常只有手賤的網頁設計者才會犯這種錯誤。
    ex. 正確的示範:

     
       
     
    hi

    很明顯地,這次都放對了地方,也能確定所有的圖形介面瀏覽器都讀得到正確的表單。用網頁編輯器的,或是細心一點的網頁設計師都辦得到。
  4. 所有屬於該標籤的屬性,其指定值一定要加雙引號。
    ex. 錯誤的示範:
    action 這個屬性,其指定值 test.htm 應當用雙引號括起來。
    ex. 正確的示範:
        看!被雙引號括起來的 test.htm 是符合 XHTML 規定的指定值了,很棒吧!
  5. 所有的標籤都是封閉性的。
    ex. 錯誤的示範:

    這是一段示範

    一段錯誤的示範

    標籤門戶大開,不合 XHTML 規格;
    雖然看起來合法,但我們還是需要他自閉(?)來滿足 XHTML 規格。
    ex. 正確的示範:

    這是一段示範
    一段正確的示範

    標 籤要有頭有尾,這是一定要的原則。至於像
    啦, 這種本來就是單獨存在的標籤呢?當然你可以再加個
    或 把內容給關起來,只是有人研究過單獨用
    會讓網頁處理速度快一點(吧?)
  6. 在一個標籤中,同樣的招式不能對聖鬥士使用兩……同樣的屬性不能出現兩次。

寫法:

  1. 第一行一定要是這個標籤:!(註)
    這個標籤將告訴瀏覽器這個網頁是如何描述 XHTML 規格。有下列三種:

    1. 若要寫一個「純」XHTML 的網頁,請用這個。

    2. 若要寫個能與大部份 HTML 4.01 相容(就是一般常見的舊網頁標準)的網頁,請用這個……大概也只會用這個了吧 XD

    3. 若要寫一個有框頁的網頁,請用這個。
  2. 第二行一定要用 這個標籤,並在裡面加上 xmlns 這個屬性。
    例子:
        上 面的 xmlns 是指 XML 文件(以後有空再去了解吧)使用的腳本(大概是這樣解釋的吧…有錯再來改)是 http://www.w3.org/1999/xhtml(別亂改), 而這個 XML 文件(好啦,XHTML 是 XML 的一種)用的語言是萬國碼(utf-8)。
  3. 在 XHTML 中一定要加入 這個標籤。<br /> 例子: <pre><html><br />   <head><br />     <title>網頁標題
     

         
         
         
  4. 標籤一定要有一個 action 屬性,指定接收資料的網頁。
    例子:
        
  5. 關於網頁上與樣式∕排版有關的標籤,如
    等等都不該再使用,改以 CSS 語法設定。
  6. 所有文字內容都要包在標籤內。
    例子:

    我被包圍啦

    如上例,「我被包圍啦」被

    包圍,就符合 XHTML 的規格。
  7. 所有行內標籤內都不能含有區塊標籤。
    例子:

     
       
             
     
    這是個完全錯誤的例子

    超鏈結標籤是個行內標籤,不能將區塊標籤給包起來。
  8. 所有的 標籤都要有個 alt 屬性,作為圖檔的說明。例子:
        alt="Tux,電腦界的救星,拯救長年被 M$ 帝國壓榨的可憐電腦使用者" />
    這樣一來,使用文字瀏覽器或圖讀不出來時,就會出現打給 alt 屬性的內容,最起碼可以讓人知道這張是在這裡是要秀什麼的。
  9. 所有的 這樣使用 CSS 語法,可以讓整個背景變成黃色,只要不用底圖的話。
  10. 以前的 HTML 語法允許屬性的指定值單獨存在,現在不行了。要使用這個指定值,就用同名的指定值當作屬性。
    例子:
    公雞
    在以前(HTML 4.01 規格)中,這樣做時會出現一個已經勾選的 check box(勾選框),但在 XHTML 中我們要改成這樣:
    公雞
  11. 使用 這個例子中,是將 javascript.js 這段 javascript 抓進網頁中。當然,這樣子並非完全符合 XHTML 規格,但你不會想知道合乎規則的寫法的 XD

  12. 以上兩大項目,給大家參考,也給我自己速查 :-)

    註:其實第一行應該是 XML 文件宣告。
    例子:

    「version="1.0"」表示這是依循 XML 1.0 規格,「encoding="Big5"」表示這份文件的文字編碼為大五碼(正體中文)。


    hechian 發表在 痞客邦 留言(0) 人氣()

    從http://www.walei.net/entertain/index.html看到

    本文轉錄自 taiwan.cnet.com

    Becky Roberts ‧郭文興譯  2006/07/28 2006/08/04

    一個資訊專業人員跟我們分享她生涯中最糟的幾個經驗,以及從這些事件中學到的教訓。

    我們在職場上至少也有一兩個難堪的經驗,不管是因為漫不經心造成的系統嚴重損毀,在同僚間表現失態,或是把專案搞砸。IT專家Becky Roberts決定不打自招,把他工作生涯中最糟的狀況,以及她從這些經驗中學到的教訓與大家分享。

    在過去的十六年中,我的工作是要使人類可以跟電腦一同和諧運作,我曾發生過一些嚴重的糗事,至今在我回憶的時候仍會忍不住想鑽到地洞裡。這些我犯過的錯大 略可以分為三類:技術上、政治上以及生涯規劃上的錯誤。以下就不照特定順序,將我犯過最誇張的錯以及所學到的教訓與大家分享。

    1: 不小心把副總裁的檔案殺了,同時沒有備份

    我甚至不記得我是怎麼弄的。我不只是把檔案刪了之後沒有發現,甚至在重新格式化的當下才想到犯了錯。我緊張地花了三十分鐘來決定我要怎麼處理這個狀況。我 應該要說謊然後推諉負責嗎?我甚至沒辦法把責任推給誰,因為整個公司的資訊部就只有我一個人。還是我應該要像個白痴一樣原封不動把他的電腦還給他?「檔案 還在喔,我把電腦還你了。」總之我想到的辦法沒一個可行。最後,我直接走到他的辦公室,然後把電腦還他然後自己招認:「我搞砸了。我把你的檔案全刪了,然 後再也沒辦法把資料救回來。這完全是我的錯。」這時一陣靜默。然後他只說了:「好吧。那妳下次要小心點。」就沒事了。我幾乎要跪下來親他的腳,我鬆了一口 氣的程度,就跟我覺得自己像個超級大白痴一樣的嚴重。

    學到的教訓?備份備份備份!!除非電腦至少有一份備份,否則不要進行刪除、搬移、更改、更新、重寫或格式化的動作。在那之後我就沒有大量損失檔案的經驗。

    2: 更改公司的發薪系統,以至沒人拿到加班費

    這是在美國中西部一家陶藝工廠發生的事情。發薪系統是一個工作站上的Basic程式。公司打算實行一個新的薪水計算規則,而我的任務就是去正確更改這個系 統。我在備份程式上做了需要的改變,然後試跑了一下。它的邏輯似乎正確無誤。我把程式跟老闆看,也得到他的讚許。他說他打算將下個發薪期開始實際使用。然 後我問它公司有沒有測試用的系統。當時我在該公司只工作了兩個月,對公司的系統並不熟。他笑了一下然後說沒有。

    兩週後,公司產生一陣騷動,因為員工打開信封看到一些很糟的事:沒有加班費,沒有,沒有,沒有就是沒有。老闆看我臉色慘白,便叫我直接趁早滾回家。

    學到的教訓?這是很糟的一課。顯而易見地,我犯了一個程式錯誤,需要好好改進我的程式技巧。但我是否應該早點意識到我的程式能力對於這份指派的工作仍有不 足,同時試著拒絕呢?我的確對於將未測試的程式拿來執行表達了不安,但可能我的態度應該要更強硬。也許從這個意外中所學到最重要的教訓,是要在工作面談 時,儘可能問清楚公司的硬體配置,然後避免進入一些沒有完善硬體的公司。

    3: 使用Exchange的試用版

    那時我是一個新聘員工,在一個只有兩人的資訊部門工作,被指派的計劃是安裝微軟的Exchange軟體。該公司當時原本使用的是一個文字介面的免費電子郵件系統,但因為它實在太難用,所以沒什麼郵件需要從舊系統轉到新系統,因此它只是一個簡單的安裝工作。

    我弄來一個Exchange的試用版,然後把它安裝並進行設定,最後選定了一小群使用者做為測試對象。我從公司所有使用者中徵求有意願測試新郵件系統的 人,然後很快的這個「測試」群組就包含了公司所有人。使用者創立自己的資料夾,收件夾,也輸入了連絡人。然後我訂購了Exchange的正式版本授權,我 打到微軟去,得知一件恐怖的事實,就是沒有辦法從試用版轉換到正式版,然後在九十天後試用版就要停止運作。那天是第八十八天。不用說,我接下來的四十八小 時都在打電話給微軟的技術專線,然後試著用正式版來取代試用版,搬移資料以及更改使用者設定上面。那可以說是個巨大又痛苦的混亂狀況。這個狀況的唯一好處 是他是一個學習的好機會。

    學到哪些重要的教訓呢?

    # 在確定軟體到期後不會停止運作之前,不要冒然使用試用版本

    # 設定一個專案計劃,然後切實執行。我根本不應該把整個公司的人放進測試群組。

    # 與使用者多加溝通。同時根本不該允許他們對測試的系統變得逐漸依賴。

    # 在歸屬新系統的責任以前,要確保相關人員接收良好訓練。

    4: 把備份看成例行公事

    主機的備份是我的責任。我設定了備援主機,同時每天都儀式性地更換備份磁帶。當第一次有使用者要求回復檔案時,我發現那個檔案所在的資料夾已經超過三個月 沒有成功備份。更糟的是那個有問題的檔案從來沒有備份過。我壓抑了把錯歸疚在軟體上的衝動,承認那是我個人的輕忽,也向那位使用者致歉。然而他也沒有完全 領情。

    學到的教訓?

    # 永遠不要把備份看著例行公事

    # 每天仔細檢查備份的記錄

    # 定期測試資料回復功能

    # 設定一個時程,定期檢查備份成效

    5: 獨占某項特定知識

    雖然在公司裡擁有唯一無二的知識技能似乎讓你出現飯碗十分有保障的幻覺,有時也會成為耽誤你個人生活的負面影響。在我職業生涯裡面有一些場合,我讓自己處 於那種情況。因為自己未將知識分享,讓我在與家人相處的週末常常被打斷。電話整個晚上都在響,甚至整個假期都在響,最誇張的是,在我開完大腦手術後的六個 小時,電話就直接打到加護病房來。

    學到的教訓?文件、分享與訓練。有時候在一個小公司裡,或是要實作某計劃時,獨佔某個特定知識是幾乎不可能的。但隨時注意保持警覺,可以讓你把風險降到最低。但就算提供了正確的文件,有時候一個較沒經驗未受訓練的他人也可能為公司帶來危險。

    6: 沒為自己留好必要文件

    除了沒有好好把工作程序記成文件,讓知識可以分享,我也多次自以為可以記住,而沒有完善記錄工作程序或相關設定,而最後害苦了自己。當處於壓力下工作,或 是使用者已經迫不及待時,往往很容易就急就章,然後不在意地對自己說,到狀況解除後再記錄相關文件。不幸的是緊急事件往往一連發生,然後記錄文件的動作就 被忘記,直到你在某個緊急事件裡面需要它的時候。

    學到的教訓?其實我還是持續遇到類似狀況。但在趕時間時我會先存下螢幕畫面,然後記個幾行字,在緊急狀況結束時,要記錄完整文件時,我仍不免會有所耽擱。

    7: 在專案開始時沒有建立指揮權

    這數年來,我曾擔任過各式各樣實做、升級、系統轉移計劃的專案負責人。除了最近一件專案之外,所有的專案都可以說成功在時限前完成所需目標。然而該件失敗的專案也不是特別沒有執行效率或是壓力較大。

    在之前我從未發現在專案開始時建立自己指揮權的重要性,因為不同團隊的每個成員都尊重。最近的專案是在一個分層負責架構的公司所進行,我的團隊有幾個同 事,我的上司,幾個經理還有一個副總裁。一個較資深的專案經理建議我特別召開一個會議來確定我對團隊的成員到底有多少指揮權。我認為這是件不需要的事,然 後很快就嘗到苦果。

    專案有許多要在特定日期完成的流程,但儘管我儘可能地與負責的團隊成員溝通,他們往往也會提出反對「我週五要休假,我老闆同意的,」「我今天不能做那個東西,我必須要做這個。」我負起整個專案的成敗責任,然而卻沒有任何權力去保障他的成功。最後專案無法趕上預定時程。

    學到的教訓?只要是我現在處理的任何專案,其第一步都是建立我所需要的指揮權。如果這還不能保障專案的成功,我必須要不顧一切地要求更多權力或是建議更高層的專案經理來處理。

    8: 對員工寄出漫不經意的電子郵件

    公司的一名員工寄信給我一份她電腦的龐大問題清單。我沒有任何惡意地簡單回了信給她,說她可以直接考慮換台新電腦。然後我什麼都沒想地,把她的問題加到我 當天的工作清單裡。幾分鐘後我跟我老闆還有我老闆的老闆被緊急叫到某個會議上。當我走進門時我還印了我給該員工的回信以做解釋。

    我整個一頭霧水地表示我不知道發生了什麼事。我老闆表示那個員工被我的電子郵件氣翻了,因為她把我輕率的舉動解讀成我沒有認真看待他的問題或想要解決。我十分驚訝短短幾句不經意的笑話可以被整個誤解。我被指示要對該員工道歉,同時立刻排除她的問題。

    學到的教訓?

    * 不要嘗試在電子郵件裡搞笑或自做聰明;單純陳述就好。

    * 對求助訊息要有標準的處理流程。

    * 常常提醒使用者你只要收到發出的求助,就會儘速處理他們的問題。

    9: 沒有有效利用免費訓練或是認証的機會

    每當我更新我的履歷,準備尋找新工作時,我都很後悔沒有一些正式的證照來襯托我實際的經驗。尤其若當我想離開的公司有相關政策,無論各層級員工工作是否相 關,都有免費考照政策時,更是一件氣人的事情。這曾讓我無法申請到一些想要的工作,而這些工作只要有相關的證照就可以簡單地申請到。

    學到的教訓?善用所有免費受訓的機會,就算受訓沒辦法抵扣正式上班時間也一樣。


    hechian 發表在 痞客邦 留言(0) 人氣()

    不要再被騙了
    中華電信的一堆優惠專案
    比別家電信業者的沒優惠差沒多少錢
    可見別家電信業者的優惠比你用中華電信還要划算!!

    另外,電路費!!!
    電路費繳給中華電信(當然其他的電信業者也要繳電路費)
    網路月租費繳給中華電信
    連國外的速度比龜爬還要慢...=  =
    這種網路品質你要嗎!!!?

    請各位看看這篇文章:http://www.wretch.cc/blog/ppkeigo&article_id=5614462

    各位親愛的中華電信用戶您們好,想知道為什麼連無名很慢嗎?
    原因很簡單,老天要你們速速轉換電信用戶,讓家裡可以省多一點的錢!



    hechian 發表在 痞客邦 留言(2) 人氣()

    都是我的錯
    是我惹的禍
    It's all my fault..

    希望是我的錯覺
    感情依然是沒變
    變質的感情,我也不知怎樣挽回
    或許放手是最好的決定

    傷心也是我自己
    離開,妳會較開心
    過去的幸福也許如雲煙
    過往再也無法追回

    如果還有次機會...


    愛妳..

    hechian 發表在 痞客邦 留言(0) 人氣()

    哇呼.. 雛形是出來了
    版面不能看(!)

    大致上是還好
    在開發的過程中,沒有遇到太大的問題
    而且在這次開發的過程中我又釐清了很多東西
    對Rails的操控又更加熟悉了

    其實Rails的開發真的很簡單
    一個rails project建立好後
    修改config
    建立Controller
    連去Database建立Schema、Tables
    建立Model
    使用Scaffold
    OK~ 基本的東西出來了

    接著再修改一些東西
    還有rhtml的修改、版面配置
    這樣就完成一個Web Application

    其實在這整個過程中
    寫的程式碼真的不多
    我相信比用PHP還要節省更多時間

    過幾天再丟到網路上吧...


    hechian 發表在 痞客邦 留言(0) 人氣()

    我想我或許已經想到我該走哪條路了
    回想以前,剛從網頁開始走入資訊這條路.. 夢想當一個程式設計師
    漸漸的,發現到這只是一個夢想,因為我不太喜歡爆肝的感覺...
    開始往多方面去嘗試了解學習專研...
    這也玩那也玩,玩到最後什麼都知道,什麼都不精通

    不過,比較熟的還是那個.. 沒錯!
    就是網頁設計!
    其實說熟網頁設計也不盡然.. 我比較熟Coding..
    嗯,Web Application開發真的很有趣

    如果用PHP開發,也許我還不太想要走這條
    可惜Ruby on Rails出現了...
    Ruby on Rails真的很不錯..
    一個十幾歲的小鬼,獨自一人在兩個禮拜內寫出CMS
    扣除掉吃飯睡覺上課洗澡跑出去打球把妹的時間,也有一個多禮拜吧?
    PHP、JSP、ASP高手們寫給我看...

    由於是用Ruby開發出來的Framework
    所以承襲了Ruby:"簡單原始碼"的優點
    小弟的另一個Blog:CFC on Rails將會近期內補上文章:)
    敬請期待XD


    (據說最近無名小站要徵才,徵求Ruby on Rails能手耶XD)


    hechian 發表在 痞客邦 留言(2) 人氣()

    嗯...
    最近幾天感覺還可以
    可是講TCP/IP時,感覺不怎樣好..
    很緊張,會抖="=
    還把Token Ring當成Ring來講=  =..

    還出了事情
    回家時又坐錯車
    煩死了...

    hechian 發表在 痞客邦 留言(0) 人氣()

    可能要修正我的觀念了...


    評論:20年前的今天(星期一)我辭去MIT(麻省理工學院)的工作,開始開 發一套稱為GNU的自由軟體作業系統。雖然我們從來沒推出一套真正可用在生產上的完整GNU系統,不過現在卻有另一個衍生的GNU系統廣為大眾所採用,只 是多數人並不知所以然。自由軟體(free software)不是免費的(gratis),它所表達的是用戶可自由執行程式、研究程式碼、做修改,甚至重新散佈,至於要免費或收費則並無限制。

    我的希望是藉由自由作業系統打出一條永遠免受封閉式專屬軟體的限制。非自由軟體往往對用戶做出種種限制,我曾深深體會到這種模式醜陋的一面,因此我決定逃脫出來,並讓大家也有機會跳出來。

    不自由的軟體隱藏著一種反社會的體制,禁止大家共同合作與社群分享。通常你看不到原始碼;你不知道裡面到底有哪些愚蠢的漏洞。即使你不喜歡,你也不能動手修改。最慘的是,你不能與他人分享。禁止軟體分享在本質上就是切斷社會的關連,與世隔絕。

    現在,市場已經有一大群用戶在使用GNU、Linux與其他自由軟體。成千上萬的使用者更希望加以延伸,立志要說服更多電腦用戶「採用自由軟體」。但「採 用自由軟體」這句話是什麼意思?這是代表逃脫專屬軟體的枷鎖?還是只是同時多安裝一套自由軟體就算了?我們希望讓大家真正享有自由?或者僅是要他們加入我 們的工作?換言之,我們究竟是希望為自由而奮鬥?還是看到用戶數節節上升就以此自滿?

    有時我們很難察覺這之間的區別,因為在很多情況下兩者似乎無甚差異。你試圖說服他人使用一套自由程式時,或者要他們安裝GNU/Linux作業系統時,不管以哪一種目標都可達到同樣的行為。不過,在某些情況下,這兩種目標卻又會造成截然不同的行動。

    例如,當有人推出非自由的驅動程式、或者資料庫、編譯器等用在GNU/Linux系統時,我們應該感謝這些開發人員大力相助我們的系統嗎?還是我們也應該把這些也等同視作跟其他專屬軟體一樣,都是一種誘人的陷阱,讓我們受到束縛,我們必須加以解決?

    若你是以增加自由軟體受歡迎度為目標,若你只是說服周遭用戶撥出點時間來用自由軟體,那你或許就認為這些非自由程式對於此一目標相當有幫助。我們也很難不 承認這些程式多少助長了GNU/Linux的熱門程度。若自由軟體社群是以GNU或Linux普及化為目標,那我們對於任何可相容執行的程式都該予以喝 采,不管這些是專屬與自由軟體。

    但若我們的目標是自由,那一切就為之改觀了。用戶若繼續使用非自由程式就無法達到自由的境界。若要解放電腦世界的公民,我們必須將所有不自由程式都加以取代,而非接受。這些非自由程式對於我們社群而言並非貢獻,他們反而誘使我們繼續沈淪在不自由的境界中。

    開發自由軟體通成有兩種動機,一是因為沒有其他程式可用,可惜的是一旦接受了非自由程式就等於消滅了此一動機;另一個則是渴求自由的意志,這會激勵大家撰 寫自由軟體來取代不自由的程式。在這種情況下,動機是唯一的支撐,只要大家勇於使用自由程式,即使許多技術還無法與不自由程式相比,但這就足以鼓勵自由開 發人員繼續努力寫出更好的程式。

    這些不自由的程式可不是小問題。要開發出自由的替代品是個浩大的工程,說不定要花上許多年。這些工作還需仰賴未來的電腦高手,也就是現在的年輕人,那群還未對自由軟體心生嚮往者。我們現在該怎麼做才能說服這些年輕人未來能秉持這樣的意志來完成此一工作?

    若要強化我們社群的未來,那就需要讓大家能更瞭解自由的真諦,教導大家認識不自由的軟體絕不可接受。只有真正重視自由的人才能長期抵擋得住這種誘惑。(陳奭璁)

    Copyright 2004 Richard Stallman
    本文歡迎全文轉載,無須稿酬,但需保留此段告示。

     

    hechian 發表在 痞客邦 留言(0) 人氣()

    文章轉貼自:http://www.vixual.net/wikka/wikka.php?wakka=Archive2005041201


    看了下面的這篇文章,深有感觸,棗子碰到的問題也是我們大多數程式設計師的通病,也許我們大多數人都只是在做一些比較小型的軟件,對軟件運行的效率不在 乎,就算對速度和效率在乎的也可能是一些在資料庫操作方面的。大家看完了,也許會有很多感想,但這只是我同意棗子的個人觀點。

    做為一名大四的學生,我面試過不少的單位,有成功的也有失敗的,但是對我來說所有的失敗在某種意義上都是一種成功,特別是我下面寫的這些,寫這篇文章的時 候,我已經簽了南京的一家軟件公司,但是想起今年 2 月 21 日我面試蘇州台灣的IT公司的經歷聯想到我們現在學習程式設計的一些情況我真的深有感觸,這次面試使我深深的體會到了失敗但也收穫了很多。

    我要說的將分成三部分:

    1.是我面試的具體經過
    2.是由面試想到的
    3.現今我應該做的

    當然這些話很大程度上是我個人的意見,不可能完全得到大家的贊同,所以在某些觀點上如果哪位朋友覺得跟我的有很大出入,請不要介意,也不要對我攻擊,就當我沒有說過,歡迎和我聯繫共同探討這些問題!

    1.面試經過

    大約在年前我接到了台灣瑞晟 (Realtek) 蘇州公司的面試通知,通知我 2 月 21 日到蘇州工業園區面試,接到面試後的幾天我把一些專業課溫習了一遍,特別是 C++ 和數據結構,由於大學幾年裡,我一直專研這些方面,加上通過了高級程式設計師的考試,對於一些常用的算法我差不多也達到了爛熟於胸的地步,當時的感覺是如 果問了我這些方面的問題我應該是沒有問題的!

    21 日那天我被安排在 4:30 面試,由一位技術人員單獨給我面試,在問了一些簡單的問題之後他給我出了一道程式設計題目,題目是這樣的(由於具體面試的題目比較煩瑣,我將其核心思想提 取出來分解成了兩個獨立的簡單的問題,有可能問題分解的不當,請大家見諒,實際面試了一個的問題但比其複雜很多,而且涉及一些高等數學變換):

    1) 寫一個函數計算當參數為 n(n很大) 時的值 1-2+3-4+5-6+7......+n

    哼,我的心裡冷笑一聲!沒想到這麼簡單,我有點緊張的心情頓時放鬆起來!於是很快我給出我的解法:

    long fn(long n) { 
    long temp=0;
    int i,flag=1;
    if(n<=0) {
    printf("error: n must > 0);
    exit(1);
    }
    for(i=1;i<=n;i++) {
    temp=temp+flag*i;
    flag=(-1)*flag;
    }
    return temp;
    }

    搞定!當我用期待的目光看著面試官的時候,他微笑著跟我說,執行結果肯定是沒有問題!但當 n 很大的時候我這個程式執行效率很低,在嵌入式系統的開發中,程式的運行效率很重要,能讓CPU少執行一條指令都是好的,他讓我看看這個程式還有什麼可以修 改的地方,把程式優化一下!

    聽了這些話,我的心情當時變的有點沉重,沒想到他的要求很嚴格,之後我對程式進行了嚴格的分析,給出了改進了的方案!

    long fn(long n) { 
    long temp=0;
    int j=1,i=1,flag=1;
    if(n<=0) {
    printf("error: n must > 0);
    exit(1);
    }
    while(j<=n) {
    temp=temp+i;
    i=-i;
    i>0?i++:i--;
    j++;
    }
    return temp;
    }

    雖然我不敢保證我這個算法是最優的,但是比起上一個程式,我將所有涉及到乘法指令的語句改為執行加法指令,既達到要題目的要求而且運算時間上縮短了很多!而代價僅僅是增加了一個整型變數!

    但是我現在的信心已經受了一點打擊,我將信將疑的看者面試官,他還是微笑著跟我說:「不錯,這個程式確實在效率上有的很大的提高!」我心裡一陣暗喜!

    但他接著說這個程式仍然不能達到他的要求,要我給出更優的方案!天啊!還有優化!我當時真的有點崩潰了,想了一會後,我請求他給出他的方案!然後他很爽快的給出了他的程式!

    long fn(long n) { 
    if(n<=0) {
    printf("error: n must > 0);
    exit(1);
    }
    if(0==n%2)
    return (n/2)*(-1);
    else
    return (n/2)*(-1)+n;
    }

    搞笑,當時我目瞪口呆,沒想到他是這個意思,這麼簡單的代碼我真的不會寫嗎,但是我為什麼沒有往那方面上想呢!

    他說的沒有錯,在 n 很大很大的時候這三個程式運行時間的差別簡直是天壤之別!

    當我剛想開口說點什麼的時候,他卻先開口了:「不要認為 CPU 運算速度快就把所有的問題都推給它去做,程式設計師應該將代碼優化再優化,我們自己能做的決不要讓 CPU 做,因為 CPU 是為用戶服務的,不是為我們程式設計師服務的!」

    多麼精闢的語言,我已經不想再說什麼了!

    接著是第二個問題:

    2) 他要求我用一種技巧性的程式設計方法來用一個函數實現兩個函數的功能 n 為如:fn1(n)=n/2!+n/3!+n/4!+n/5!+n/6!

    fn2(n)=n/5!+n/6!+n/7!+n/8!+n/9! 現在用一個函數 fn(int n,int flag) 實現,當 flag 為 0 時,實現 fn1 功能,如果flag 為 1 時實現 fn2 功能!他的要求還是效率,效率,效率!

    說實在話,如果我心情好的話我應該能給出一種比較好的算法,但我那時真的沒有什麼心思再想了,我在紙上胡亂畫了一些諸如 6!=6*5! 的公式後直截了當的跟他說要他給出他的答案!

    面試官也沒有說什麼,給出了他的思路:

    定義一個二維數組 float t[2][5] 存入 [2!,3!,4!,5!,6!],[5!,6!,7!,8!,9!] 然後給出一個循環:

    for(i=0;i<6;i++) { 
    temp=temp+n/t[flag];
    }

    最後得到計算值!

    呵呵,典型的空間換時間的算法!

    這些總共花了 50 分鐘的時間,還有十分鐘我就跟他很隨意的聊聊天,聊了一些程式設計以及生活的問題,那時的我已經很放鬆了,因為我知道這次面試結果只有一個:失敗。

    5:30 的時候面試官要我等通知,於是我離開了他們公司。這就是面試的整個經過!

    2.由面試想到的

    真的是很失敗啊!我記得那天下好大的雨,氣溫也很低,我邊走邊想,從 5:30 一直走到 7:30,全身都濕透了,又冷又餓,但是我只是一直走,腦子裡面充滿了疑惑,我也想讓雨把自己淋醒!看到這裡有些朋友可能覺得那些面試題目不算什麼如果讓 自己做的話肯定能全部答對,我肯定相信你,因為我從未懷疑過中國程式設計師的能力,我認為中國有世界上最好的程式設計師,我也從未認為自己是高手,所以我 做不出來不代表中國程式設計師比台灣或者別的地方的程式設計師差,所以我就從我的角度,我的所見所想來談一些感想:

    不錯全世界都有優秀的程式設計師,中國也不例外,但是我疑惑的是:到底中國和台灣或者國外的優秀的程式設計師的比例到底是多少?台灣我不知道,中國 100 個程式設計師裡有幾個是優秀的呢?

    我根本算不上,從上面的表現就足以說明一切了!是 1 個?5 個?10 個?50 個?這個數字我不敢亂猜,恐遭網友一頓痛罵,那麼我們國內有多少人學習計算機呢?拿我們學校來說,計算機 97 級 4 個班,98 級 5 個班,99 級 10 個班,2000 級 17 個班,人多了,老師怎麼辦?我們學校的做法是讓研究生上課,然後呢?補考一抓一大把,大把大把的補考費落入了學校的口袋,還說現在的學生素質低!

    真是好笑,我都不知道學校這麼做是為了什麼,為國內培養大量的程式設計師嗎?學生們能真正學到計算機知識嗎?好了,我敢講,在我們學校學習程式設計學生和優秀程式設計師(注意我指的是優秀,只會編幾個糟爛程式的人算不上)的比例應該是 100:0.1。

    在這種比例下雖然我們中國學習程式設計的人鋪天蓋地,但是想想有多少個人能真正為中國軟件業發展作出貢獻,有多少人能真正寫出優秀的程式名揚海外!

    我從學習程式設計以來,不管是自學還是老師指導,從來都是解決問題就好,編出程式來就行,我的疑惑是:我們有真正的強調過程式的效率,程式的質量嗎?我們有仔細分析過我們寫的東西,看看有沒有可以改進的地方,看看有沒有簡單的方法來達到同樣的目的呢?

    我捫心自問,我發現,我從來沒有對我寫出來的程式進行過優化,最多就是進行詳細的測試,然後 Debug,但是這就足夠了嗎?

    這些天我偶爾發現我曾經寫過的一個遊戲,那是一年前我剛加入 www.vcroad.net 做為其中一員時候,感覺應該拿點東西出來,然後花了一個星期的時間寫出來的!

    程式不算複雜,但是用到了不少數據結構的東西,也用到了一些精彩的算法,加上 windows 的界面和遊戲的可玩性,寫完後受到了不少好評,我當時真的很佩服自己!

    但是現在看呢:沒有一句註釋,好多醜陋的函數名,比如:void chushihua(),好多沒有必要的變數,可以用簡單語句完成工作的我使用華麗的算法,大量使用全局變數...

    說不好聽的話,六百多行的程式除了能運行之外就是一陀屎!

    如果一年前我能聽到一些反面意見的話,大概我能早一點覺悟,但是自從原代碼在網站發佈以來聽到的都是讚美之詞,沒有一個人向我提出程式改進的意見,這又說明了一個什麼問題呢?很值得思考啊!

    還有一個疑惑是:我們說的和做的真的一樣嗎?

    我在學校的時候曾經受學院指派承辦過一個計算機大賽,請了一個老師出決賽的題目,主要是一些算法題目,這個老師可能是我上大學以來唯一敬佩的老師了,從程 式調試到打分,對於每個程式都仔細分析其時間效率和空間效率,然後綜合打分,四十個人的卷子,老師從下午三點一直調試到晚上十點,在有些寫的精彩的語句後 還加上批注。

    我真是高興很遇到這樣的老師並且和他做深入的交流,但在事後,卻發生了一件不愉快的事,在比賽中獲得第二名的學生找到我,說他程式全部調試成功應該給他滿 分,並且應該得第一,我說不過他,最後調出了他的原程式和第一名的原程式對比,不錯,兩個程式都運行的很好,這時,那個同學開口了:「我的程式寫的十分簡 捷明瞭,僅僅數行就完成了題目要求,而他的卻寫了一大堆,為什麼給他的分多過給我的分。」

    我當時很是氣憤,如果不是老師負責的話,那麼現在第一名和第二名的位置真的要互調了,拜託,不是程式的行數越少程式的質量就越高,我記得我跟他大談這方面的道理,最後說服他了!

    哈哈,但是我,只能說說而已,我不知道還有多少人一樣,說起來頭頭是道,但心裡卻壓根就從未重視過它!

    3.我打算做的

    其實那天我想到的遠不止上面那麼多,但是我不想再說了,因為我猜想看這篇文章的網友大概都有一肚子的感想,一肚子的抱怨,借用這篇文章發洩可不是我想達到 的目的,在上面我把自己罵的一文不值也不是妄自菲薄,但是在某些方面我真的做錯了,或者說是偏離了正確方向,現在是矯正方向和重整旗鼓的時候了,就像我前 面說過的,我相信中國有世界上最好的程式設計師,我也相信我的水準不會一直保持現狀,我現在就收拾起牢騷真正的實幹起來!

    真的很巧,就寫到這裡的時候我在網上偶爾發現了這篇手冊,我不知道這暗示著什麼,但是我想如果我照下面這個基本原則一直踏實做下去,我一定會實現我的理想 - 一名優秀的軟件設計師!

    (下面這些文字不是我的原創,是我偶爾在網上發現的,我真的很幸運能看到這些,這篇文章也隨著下面的文字而結束,我真心的希望您能從這篇文章中得到啟發,這篇文章歡迎大家隨意轉載,您可以不寫作者是誰,但是請您寫上 ww.vcroad.net 原創,謝謝您的支持)



    作者:金蝶中間件公司 CTO 袁紅崗

    不知不覺做軟件已經做了十年,有成功的喜悅,也有失敗的痛苦,但總不敢稱自己是高手,因為和我心目中真正的高手們比起來,還差的太遠。世界上並沒有成為高手的捷徑,但一些基本原則是可以遵循的。

    1.紮實的基礎

    數據結構、離散數學、編譯原理,這些是所有計算機科學的基礎,如果不掌握他們,很難寫出高水準的程式。據我的觀察,學計算機專業的人比學其他專業的人更能 寫出高質量的軟件。程式人人都會寫,但當你發現寫到一定程度很難再提高的時候,就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學 OOP,即使你再精通 OOP,遇到一些基本算法的時候可能也會束手無策。

    2.豐富的想像力

    不要拘泥於固定的思維方式,遇到問題的時候要多想幾種解決問題的方案,試試別人從沒想過的方法。豐富的想像力是建立在豐富的知識的基礎上,除計算機以外,多涉獵其他的學科,比如天文、物理、數學等等。另外,多看科幻電影也是一個很好的途徑。

    3.最簡單的是最好的

    這也許是所有科學都遵循的一條準則,如此複雜的質能互換原理在愛因斯坦眼裡不過是一個簡單得不能再簡單的公式:E=mc2。簡單的方法更容易被人理解,更容易實現,也更容易維護。遇到問題時要優先考慮最簡單的方案,只有簡單方案不能滿足要求時再考慮複雜的方案。

    4.不鑽牛角尖

    當你遇到障礙的時候,不妨暫時遠離電腦,看看窗外的風景,聽聽輕音樂,和朋友聊聊天。當我遇到難題的時候會去玩遊戲,而且是那種極暴力的打鬥類遊戲,當負 責遊戲的那部分大腦細胞極度亢奮的時候,負責程式設計的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候,我會發現那些難題現在竟然可以迎刃而 解。

    5.對答案的渴求

    人類自然科學的發展史就是一個渴求得到答案的過程,即使只能知道答案的一小部分也值得我們去付出。只要你堅定信念,一定要找到問題的答案,你才會付出精力去探索,即使最後沒有得到答案,在過程中你也會學到很多東西。

    6.多與別人交流

    三人行必有我師,也許在一次和別人不經意的談話中,就可以迸出靈感的火花。多上上網,看看別人對同一問題的看法,會給你很大的啟發。

    7.良好的程式設計風格

    注意養成良好的習慣,代碼的縮進編排,變數的命名規則要始終保持一致。大家都知道如何排除代碼中錯誤,卻往往忽視了對註釋的排錯。註釋是程式的一個重要組 成部分,它可以使你的代碼更容易理解,而如果代碼已經清楚地表達了你的思想,就不必再加註釋了,如果註釋和代碼不一致,那就更加糟糕。

    8.韌性和毅力

    這也許是「高手」和一般程式設計師最大的區別。A good programming is 99 weat and 1 ffee。高手們並不是天才,他們是在無數個日日夜夜中磨練出來的。成功能給我們帶來無比的喜悅,但過程卻是無比的枯燥乏味。你不妨做個測試,找個 10000以內的素數表,把它們全都抄下來,然後再檢查三遍,如果能夠不間斷地完成這一工作,你就可以滿足這一條。 

    hechian 發表在 痞客邦 留言(2) 人氣()