From C++ to C#

Designing .NET Class Libraries: API Usability學習新的語言,一直是身為軟體工程師不可躲避的宿命與責任。而微軟的C#,更是身為視窗系統研發的我們,必須學習的一個新技術。最近除了學習將VisualStudio的Porting之外,C#應該是讓我們進入.Net Framework 最快路徑。這裡提供幾個鏈結關於C#:

See How Visual Studio 2005 is Tested

Patrick’s Article is talking about bug reporting best proctice. Somehow in the such big project like Visual Studio .NET IDE. They usually MedDog to do testing case management. A good and sysmantic testing case can find bug more easier.

There are some link about:

  1. Introduction to DevDiv’s Test Case Management System
  2. Investigating a test case failure in the lab
  3. _Analyzing a Test Case Failure _
  4. _Finding and Logging a Bug _

You can find other link in vs2005news’s WebLog and Got Dot Net can find some useful information.  About ASP .NET you can reference this document to find more information.

小遊戲–舌頭保齡球

toneBollow.JPG

這個遊戲傳給同事,到也有很多同事在努力拼這個分數~~真不愧是保齡球社的,連遊戲保齡球也打的不賴

Naming convensions

Designing .NET Class Libraries: API Usability

Naming is alway difficult thing for me. But when look the speech which Brad Abrams  talking about naming convension, I think he provide more detail situation what we have to do when we need naming our variables. Some interesting about this speech as bellow:

  • “Google test”: he just talk about avoid abbreviation. He say you can use google to test the abbrebiation.
  • About casing rule: Just use camelCase in parameter naming,otherwise use PascalCase. (I think this rule give me some help)
  • Do not use underscore:  Do not use it when naming. Just like Some_Variable~~
  • Don’t use Hungarian Notation: Brad Abrams also talk about although Hungarian Notation is usefull in the past, but according the IDE progress more and more. Microsoft already ban their engineer using Hungarian Notation. So~~ in the public API do not use it, just use it in your function implementation(if you still want to use it).

There still have some great speech in the Designing .NET Class Libraries. You can choose what you interest topic and watch it online.

RIA是什麼? 舊有網頁程式不好嗎?

10X10.JPG

網站: [最有名的RIA網站10X10](http://www.tenbyten.org/10x10.html) > >

看見Patrick這篇文章裡面稍微提到RIA(Rich Internet Application),基於對網路程式小小有研究,所以跑去給他GOOGLE一下、找到些蠻多的資料,可以先看愛德華的文章,看看RIA到底是什麼??也可以看阿修的部落格裡面關於RIA網站的介紹,當然d.cat的網站也要去看看。

現在所看到一些RIA的網站,大多還是使用flash來當作開發的平台,不論是移植性與對應性都還算是很高的,很久以前也就覺得或許以後的程式都有可能使用網頁來當作一個基礎平台,在上面建立出相關的服務或是所需要的功能。當然,這樣的前提之下,即使不使用flash,只要注意好http的特性(connectless),我想光是PHP、ASP也已經可以寫出許多相關的程式。

逛了逛幾個關於RIA的網站,想到以前在接CASE的時候。不論費盡口舌跟店家說服一些網頁功能上的功能、一些會員機制的突破、一些網路行銷的概念,都比不上讓他們看到虛擬實境的環場動畫。也因為之前在開發利用網頁版的POS系統上遇到了許多網路程式先天上較難以突破的缺點,在此講幾個跟大家分享一下:

  • 對於相關硬體的支援:針對POS系統而言,使用者通常會要求的是,賣場機器能多低廉就多低廉、能快速結帳就快速結帳~~~於是最好是只要一台電腦、不要有任何滑鼠、鍵盤。這對於當初的設計環節上相當的困難,所以不過我們後來使用BarCode Scaner加上許多Java Script來抓取螢幕上的輸入,作為網頁程式的點選流程,來解決關於這邊的問題。
  • 庫存資料的Write Protect Lock:雖然POS系統對於資料庫的限制比較少,一個庫藏的貨物少了,一定是在店面,所以這個部份比較少,但是由於無法建立連線、加上連線品質不一定穩,使得資料庫的LOCK變成一個比較需要考量的因素。一但鎖定了,就必須要小心可能需要透過別的鏈結來解除鎖定。既然One Phase Lock都那麼困難,所以要實現資料庫的Two Phase Lock 也就更加的困難了。
  • 像魔鬼般的”上一頁”與”重讀”:實作網路程式的時候,除了擔心鏈結被使用者偷看到以外,最怕的大概就是怕使用者無冤無故按上一頁或是重讀(Reload)。對於這樣的程式,要預防使用者的任何一種意外狀況,比起一般的應用程式都要難上許多,這些地方除了設定網頁失效外,多使用cookie 也是很好的一個方式。
  • 儘量寫出cookie free的網站:我想,這跟上一點是相當的衝突,因為那個時候必須要考慮使用者可能拒絕紀錄cookie,所以使用了相當多的隱藏資訊(當然隱藏資訊越多~~~就越怕上一頁),這是一個trade off,必須要捨其一去考量。

嗯嗯~~~講了一堆,如果換成現在的RIA來思考(以Flash)為例,也就免除省略"上一頁"與"Cookie”的問題。

本站開始支援 “Google Adsense for Search”

google_adsense.JPG

最近在瀏覽網站的時候,無意間在其他人的Blog中看到Google的廣告(Google Adsense),也去申請了一個來玩。他會根據你現在文章內容,顯示相關的廣告出來,並且記錄下點閱次數,支付你酬勞。算是不錯的小小福利,不過目前不支援繁體中文,真是可惜~~

若你是使用簡體中文或是英文為主的網站,申請一個來補助吧~反正Google的廣告一向都不會太礙眼

BTW:我申請了AdSense For Search 以後在個別網頁會看到一個Google的Search Bar如下所示~~~

[ ![Google](http://www.google.com/logos/Logo_25wht.gif)](http://www.google.com/)