Knowledge Collection: September 2012

Monday, September 24, 2012

Malaysia Second Hand Car Website

motortrader（种类比较多容易找）
http://www.motortrader.com.my
emotors（容易找车少）
http://www.emotors.com.my/
ontheroad（车多又容易找）
http://www.ontheroad.com.my
autoworld（这网车很少）
http://www.autoworld.com.my/aw/dealer/EngHuat/
Mudah（里面很多东西车又多）
http://www.mudah.my/
lelong（买二手东西多二手车比较少）
http://www.lelong.com.my/
carlist（这网站车多又好找）http://www.carlist.my/
topmark（种类少，找车没又小图看没甘方便）
www.topmark.com.my
8carcar(是一个很不错的二手车网站）
www.8carcar.com/
e-kereta(二手零件比二手车多）
www.e-kereta.com
carworld（车不多找不方便）
http://carworld.my/
kereta（比较不整齐的二手车网）
http://www.kereta.org/
star-motoring（不方便的二手车网站）
http://star-motoring.com/
thecar（可以看看的网站）
http://www.thecar.com.my/searchcar.html
zerotohundred(车都有不少也可以看看新报到）
http://www.zerotohundred.com/
carmarket（网站没但是没么车）
http://www.carmarket.com.my/
eoaauto（这网站有进步的空间车不是很多）
http://eoaauto.com/
wemotor（好网站车很多又好找）
http://www.wemotor.com/
autoworld（这里的二手车的功能说的很清楚不错）
http://www.autoworld.com.my/

Source Reference

Tuesday, September 18, 2012

REST and HTTP Status Codes

One of the key values of REST is that you are using a universal API known as HTTP. Because of this you must try to understand the way that HTTP wants you to deal with this. And how does HTTP want me to deal with this issue? By using an HTTP Status code.

The first line of an HTTP response is the status line – HTTP clients look to this line to understand the outcome of their request. It isn’t just a matter of errors, there are many different response codes you could return or encounter when invoking RESTful services. (For more information on the Status-Line see the HTTP spec, section 6.1)

       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

The status code comes from a long list of codes, according to the spec, the list of codes is extensible but you should follow the model based on the categories of errors

      - 1xx: Informational - Request received, continuing process
      - 2xx: Success - The action was successfully received,
        understood, and accepted
      - 3xx: Redirection - Further action must be taken in order to
        complete the request
      - 4xx: Client Error - The request contains bad syntax or cannot
        be fulfilled
      - 5xx: Server Error - The server failed to fulfill an apparently
        valid request

Even so, I would not go about creating custom HTTP status codes. Instead I would try to use the commonly used status codes listed in section 10 of the HTTP spec.

REST equivalent of SOAP faults

The designers of SOAP had exceptions in mind when they created SOAP faults. Previous distributed computing environments (DCOM, CORBA etc.) did not have a model for propagating exceptions across boundaries. SOAP came along 10+ years after these technologies a time during which exceptions became accepted as a better way of dealing with errors. Many SOAP stacks (WCF being the prime example) will catch an exception, turn it into a SOAP fault and pass it along to the client side which will unpack the message and throw an exception on the client side.

SOAP faults are different than HTTP status codes because they are always errors and there is no taxonomy of errors, just whatever you want them to be. In other words, the “error protocol” is application specific.

In REST HTTP status codes are common and they are not always errors. However the errors do fall into 2 categories 4XX (Client) and 5XX server errors. Now let’s consider some common scenarios where you must deal with errors and status codes.

Error Scenarios

The first class of errors you must consider are (4XX) client request errors. Generally it means that the server rejected the request for some reason.

Get or Update record that does not exist

Client does an HTTP GET for a resource ID that does not exist in the database. On the server you might call into the data layer to update a record an get a KeyNotFoundException (like I did in the video). What happens if you do nothing? Well WCF will catch all unhandled exceptions and return a status code of 500 - “Internal Server Error”. This is not what you want, because it implies that the problem is a server problem.

In this case you should return a HTTP status code of ~~400~~ 404 “Not Found” (edit – 3/25 – thanks Clemens!)

10.4.1 400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

Here is some code that processes a GET request by looking it up in a dictionary. This is the fixed version of what I showed in the video. As you can see I’m converting an exception into a status code by throwing a WebProtocolException.

[OperationContract]

[WebGet(UriTemplate = "/{id}")]

SessionData GetSession(string id)

{

    try

    {

        return _sessions[id];

    }

    catch (KeyNotFoundException)

    {

        throw new WebProtocolException(

            HttpStatusCode.NotFound);

    }

}

Add a resource with missing or invalid data

Client does an HTTP POST with missing or invalid data in the request body. The server attempts to validate the request and rejects it because of the invalid or missing data. The HTTP status code should be 400 – Bad request

Server Processing Errors

Suppose that the request is valid, the resource exists and for whatever reason (concurrency or some other processing error) the server cannot complete the request. Then what?

10.5 Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.

You should return a HTTP status code of 500 along with some text to let the user know what is happening (if you want to). Here is an example of code that would do this kind of processing.

[OperationContract]

[WebInvoke(Method = "PUT", UriTemplate = "/{id}")]

SessionData UpdateSession(string id, SessionData updatedSession)

{

    try

    {

        if (!_sessions.Contains(updatedSession.ID))

            throw new WebProtocolException(HttpStatusCode.BadRequest);


        if (!_sessions.IsValidSession(updatedSession))

            throw new WebProtocolException(HttpStatusCode.BadRequest);


        return _sessions.Update(updatedSession);

    }

    catch (TimeoutException)

    {

        throw new WebProtocolException(HttpStatusCode.InternalServerError,"Update session timeout",null);

    }

}
 
 
Source Reference

股市心得编

（一）牛市不要过于乐观；熊市不要过于悲观!

牛市不要过于乐观 -- 通常会高档进货！
熊市不要过于悲观 -- 通常会杀到低价！
大牛市要悲观 -- 通常卖到好价！
大熊市要乐观 -- 通常捡到便宜货！
牛市不要过于乐观；熊市不要过于悲观！-- 投资第一招！

（二）投资 vs 投票！
由于我是一个长期投资者，所以我投资股票的另一些标准是：
我不投资在会因为某政党执政，而会引起 LICENCE 更新问题的股票如：博彩股及酒类股。
加上我个人觉得：投资赚钱不应损人利己，所以烟草这类有损人体健康的股票，也被我排除在外。
就算这些股票股息佳，业绩佳，我也放弃了。。。
因为股海浩瀚，只怕没钱。。。不怕没股票让我投资。。。

（三）是偏见？是经验？
我是个长期投资者，我选股的其中两个标准：
我不投资某族群为大股东的股票。
我不投资某政党为大股东的股票。
因为路遥知马力。。。某族群，某政党的股票似乎经不起时间的考验。。。
就算这些股票容易获得 projects...
就算这些股票容易投机获利。。。。
我总是没信心。。。
我喜欢的是凭真本事的公司。。。

（四）事不过三---在股市的应用：
古人有云：事不过三，意思是：事情不会连续发生超过三次。
根据我个人的观察：事不过三的道理，在股市里应用之妙，存乎一心！
股市连续大起三天，通常会技术调整！
股市连续大跌三天，通常会技术反弹！

（五）股市顶部，底部的基本判断：
好消息出尽，量大价不起，顶部不远矣！
坏消息尽出，量大价不跌，底部已近矣！
所谓一叶落而知天下秋。。。股海亦是如此矣！本人才浅学疏，以上仅供参考，输赢自负！

Reference Link

Friday, September 14, 2012

Enable WCF tracing

Tracing mechanism in Windows Communication Foundation is based on the classes that resides in System.Diagnostic namespace.Important classes are Trace, TraceSource and TraceListener.

Following are the steps to enable tracing in WCF:

1. Configuring WCF to emit tracing information/Define Trace Source, we have the following options:

System.ServiceModel
System.ServiceModel.MessageLogging
System.ServiceModel.IdentityModel
System.ServiceModel.Activation
System.Runtime.Serialization
System.IO.Log
Cardspace

In configuration file, we will define a source to enable this configuration as follows:

<source name="System.ServiceModel.MessageLogging">

2. Setting Tracing Level, we have the following available options, we need to set this tracing level to available options other than default "Off":

Off
Critical
Error
Warning
Information
Verbose
ActivityTracing
All

In configuration file, we can choose above values for switchValue attribute as follows:

3. Configuring a trace listener

    For configuring a trace listener, we will add following to config file.
   <listeners>
                 <add name="messages"
                 type="System.Diagnostics.XmlWriterTraceListener"
                 initializeData="d:\logs\messages.svclog" />
      </listeners>

4. Enabling message logging

      <system.serviceModel>
         <diagnostics>
            <messageLogging
                    logEntireMessage="true"
                    logMalformedMessages="false"
                    logMessagesAtServiceLevel="true"
                    logMessagesAtTransportLevel="false"
                    maxMessagesToLog="3000"
                    maxSizeOfMessageToLog="2000"/>
         </diagnostics>
    </system.serviceModel>

logEntireMessage: By default, only the message header is logged but if we set it to true, entire message including message header as well as body will be logged.
logMalformedMessages: this option log messages those are rejected by WCF stack at any stage are known as malformed messages.
logMessagesAtServiceLevel: messages those are about to enter or leave user code.
logMessagesAtTransportLevel: messages those are about to encode or decode.
maxMessagesToLog: maximum quota for messages. Default value is 10000.
maxSizeOfMessageToLog: message size in bytes.

Putting all this together, configuration file will appear like this.

---------------------------------------------------------------------------

<system.diagnostics>

<add name="messagelistener"

type="System.Diagnostics.XmlWriterTraceListener" initializeData="d:\logs\myMessages.svclog"></add>

</listeners>

</source>

</sources>

</system.diagnostics>

<system.serviceModel>

<messageLogging logEntireMessage="true"

logMessagesAtServiceLevel="false"

logMessagesAtTransportLevel="false"

logMalformedMessages="true"

maxMessagesToLog="5000"

maxSizeOfMessageToLog="2000">

</messageLogging>

</diagnostics>

</system.serviceModel>

---------------------------------------------------------------------------

Note: In this case, information will be buffered and not published to file automatically, So, we can set the autoflush property of the trace under sources as follows:

<trace autoflush ="true" />

Source Reference