Posts Tagged ‘ review

[轉載]如何有效地報告錯誤

轉載自: Tung's Blog


遇到任何問題時, 看看這篇文章, 照上面說的做給自己看看, 很多問題可能就這樣子解決掉囉~

  • 作者: Simon Tatham, 專業及免費軟體程式師
  • 翻譯:梅普華

介紹

寫過供大眾使用軟體的人可能都收過一份以上的爛錯誤報告. 有啥都沒講的報告(這個程式不會動), 有不合理的報告或資訊不足的報告, 也有提供不正確資訊的報告. 還有一些報告查到後來不是使用者自己攪錯, 就是其他程式惹禍, 或是網路斷線等等.
Read more

[轉載]程式設計之道 (THE DAO OF PROGRAMMING)

轉載自: 網路郵件


第一部 寂靜虛無篇

大師如是說:"學會從程式抓蟲子之後, 就可以畢業了"

1.1 節

  • 寂靜虛無中有奧秘, 不動不靜, 乃程式之源, 吾無以名之, 故稱之為程式設計之道.
  • 若道至大, 則作業系統至大; 若作業系統至大, 編譯程式亦然; 若編譯程式至大, 則應用程式亦復如是, 是故使用人大悅, 世有和諧存焉.

1.2 節

  • 程式設計之道無遠弗屆, 雖晨曦微風而返.
  • 道生機器語言, 機器語言生組譯程式.
  • 組譯程式生編譯程式, 於是萬餘語言存焉.
  • 各語言有其目的, 均表達軟體之陰陽; 其在道中亦各得其所.
  • 但若能避免, 就不要用COBOL 寫程式.

1.3 節

  • 太初有道, 道生時空, 故時空乃程式設計之陰陽.
  • 程式員不悟道則時空永不敷使用, 悟道者恒有充份時空完成目標.

1.4 節

  • 上智程式員聞道而行之, 中智程式員聞道而求之, 下智程式員聞道而笑之.
  • 若無笑聲則無道矣.
  • 至高之聲難以聽聞.
  • 前進就是後退之路; 大智總是晚成; 每一個完美的程式仍有BUG.
  • 道在所有知識之外.

Read more

[轉載]傳統編輯對部落格新手的寫作建議:一個呼籲

轉載自: 老貓學出版


這半年來台灣的部落格風潮,可說是越颳越興旺,許多優秀的傳統媒體寫作者,大量轉移寫作平台,開始建立自己的部落格。但這時我卻發現「會寫作」和「會寫部落格」之間,還有著相當的落差。許多人有非常棒的學養和見解,可惜文章貼出來卻讓人難以卒讀。

不是因為見解不深刻,也不是因為文筆欠優美,而是因為文章讓人「看」不下去──文章密密麻麻,版面沒有考慮「易讀性」,讀者眼睛疲勞,讀來自然備感痛苦。你等於加設了一道辨讀文字的關卡,擋在讀者理解文意之前,讀者還沒來得及思考你說了什麼,一上站先就被缺乏易讀性的版面打敗了。

部落格是個「一貼上就發表」(post and publish)的出版工具,從寫作到發表,沒有任何距離,不像傳統媒體,中間還有一個叫做編輯的傢伙,幫你調整段落、設定格式,讓你的文章印成鉛字以後,你越看越滿意。

Read more

[轉載]13個改善EQ的方法

轉載自: 網路郵件


1.別急!慢慢來

當妳面對失敗或頹勢時,千萬別慌了手?而大發雷霆,試著將注意力放在「就算功敗垂成,至少妳學到了……」諸如此類的積極想法上,它會很神奇地舒緩緊繃情緒,做出正確的判斷和反應。

2.承認自己錯了,別人對了

認真傾聽別人的觀點和意見,並且勇敢地面對錯誤,絕對是EQ指數向上跳躍一大步的指標。

3.別被輕易收買

隨時都在面對誘惑的人生,得學會明察秋毫,因為小惠的背後可能要付出極大代價,比較安全的應變是,說些「謝謝你的提議,我會仔細思考。」、「這個條件很誘人,值得考慮。」等等好聽話,然後改變話題,讓對方知道妳真的需要時間好好思考,此舉將使妳重掌控制權,不致於做下以後會讓妳後悔莫及的決定。

Read more

[轉載]生活的價值

轉載自: 網路郵件


有一個乞丐,他的整個右手臂斷了,樣子挺可憐,誰見了都會施捨。

有一天,他來到一個農戶人家行乞,女主人叫他先將門前的一堆磚搬到院子後。

乞丐生氣地對女主人說:「你明明看到我只有一隻手,卻讓我搬磚頭,這不是存心捉弄人嗎?」

沒想到女主人自己蹲下來,故意用一隻手搬起磚頭,來回走了一趟,然後對乞丐說:「我一隻手能搬,你一隻手為甚麼就不能搬?」

乞丐無言以對,硬著頭皮用他那一隻手慢慢搬,整整幹了兩個小時才搬完,累得滿頭大汗。

Read more

兩個跟 "鉛筆" 有關的 FLASH 動畫 *

動畫一

動畫二

[轉載]軟體開發的新生活運動

轉載自: 愛德華日誌


不曉得是幾十年前從 "歷史" 還是 "生活與倫理(現在小學還有這門課嗎?)" 唸到的,那個在現代聽起來有點八股的新生活運動。我倒不是要在此強調復興中華文化,講究禮義廉恥,四維八德。只是新生活運動所推行的:「整齊、清潔、簡單、樸素、迅速、確實」六項生活記律,倒是與近代軟體開發思潮所標舉的簡易之風不謀而合。
Read more

[轉載]給浮躁的軟體業同仁

轉載自: 開發者俱樂部


給浮躁的軟體業同仁(1)

我只希望知識掌握在更多中國人的手裏!

中國有很多小朋友,他們十八、九歲或二十齣頭,通過自學也寫了不少代碼,他們有的代碼寫的很漂亮,一些技術細節相當出眾,也很有鑽研精神,但是他們被一些 錯誤的認識和觀點左右,缺乏對系統,對程式的整體理解能力,這些人,一個網上的朋友說得很好,他們實際上只是一些 Coding fans,壓根沒有資格稱為程式員,但是據我所知,不少小網路公司的 CTO 就是這樣的 coding fans,拿著嚇人的工資,做著嚇人的項目,項目的結局通常也很嚇人。
Read more

[轉載]軟體工程師縮短工時

轉載自: CNet


微軟軟體設計工程師Adam Barr最近常和家人共用晚餐。但以前可不是如此。90年代末期,Barr忙於工作,往往無法準時下班,和妻子小孩共用晚餐,那時每週平均工作50至60小時,若碰到截止日期逼近,加班更是家常便飯,有時甚至一連數週每週工作70小時。

現在Barr固定早上8:30上班,5點下班。他說:「對這種朝九晚五的上班模式,微軟已能睜隻眼閉隻眼,不跟員工計較。以前絕非如此。」

Barr能更常和家人一起享用晚餐,凸顯軟體界工作形態出現變化:越來越多員工不再超時賣命工作。根據美國勞工部的統計,軟體出版界員工(多半是電腦專家)去年平均每週工作36.4小時,低於2001年的41.4小時。

原因之一可能是靠達康(dot.com)致富的誘因大幅褪色,再者是工程師願意更用心經營工作之外的生活。當然軟體公司漸漸學會如何提升專案管理的效率也 是其一。其實一些軟體業者坦言,員工日以繼夜超時工作反而有損產能。Atlantic System Guild的顧問Tom DeMarco說:「經常加班的公司,往往浪費許多正規上班時間。正常上下班之所以優於加班,在於工作產能高。」

Read more

[轉載]資料庫表單及欄位命名規則實例

轉載自: Neo’s Blog


今天大概把幾種常見的資料庫命名方式給整理了一下。

1.資料庫表單(Table)名稱:

單複數皆有人使用,如 products、product。

美國人命名比較喜歡依照口語習慣來用複數命名,知名的 OpenSource 軟體像 phpBB、OSCommerce、In-Link、pLog 皆是以複數命名。而 Moveable Type 則是少數使用單數名命的軟體,台灣人也是單數命名居多。

2.資料庫欄位名稱:

使用 MySQL 的 Opensource 軟體比常見整批性的加前綴(Prefix) 在欄位裡面,如 products 表單中的「產品名稱」,可能就會命名為「products_name」而 Microsoft SQL Server 則是以純欄位名稱居多,如產品名稱就直接取叫「name」了。

前綴的命名有「語意導向」跟「實用導向」二種,所謂語意導向以口語的習慣來命名,像 products 是產品的集合(複數),裡面的每個產品是單數,所以用產品名稱為例就是「product_name」。

而實用導向常見的就是以表單名稱做為前綴,如前例在 products 裡的產品名稱欄位就會命名為「products_name」,如此做的好處是程式會非常清楚每個欄位是從哪個表單抓出來的。但是缺點是在程式裡面語意不清,看起來會很不習慣。

然而大部份的欄位前綴字元還是以語意導向為主,若要使用實用導向,最好表單名稱採用單數(如 Moveable Type),否則像 OSCommerce 的全員複數,感覺程式在用名字就很奇怪,如程式明明就是只抓一筆產品名稱出來,看到 products_name 就覺的既不是複數,而且文法上也不通,意義上反而比較像 product’s name。

3.大小寫:

Microsoft 的命名方式喜歡單字第一個字母大寫,如 OrderDetail。而 MySQL 比較常見全部小寫,單字中間加底線的命名方式,如 order_detal。這跟資料庫的字元大小寫敏感度預設值有關,MS SQL Server 預設是大小寫不分,MySQL 則是大小寫視為不同欄位,所以統一小寫比較不容易出錯。

return top