A thought on fast parsing

Regular parsing process is simply de-serializing entire message to an object. Then this object would be passed to upper layers to process…

The problem with this approach is that we have to parse all fields in the message in advance, which we mostly don’t use. With the exception of displaying the message, any particular layer in  back-end message processing would mostly look at few fields in the message to filter/re-route/discard…

In a performance system,  we should parse on needed basis only. How do we do this? To best explain, I’ll use the below analogy.

Assuming each incoming message is printed on 8×11 paper, the input parsing fields will be printed on a 8×11 transparent film (because needed fields at any particular layer doesn’t change from message to message). We then superimpose the transparent film on the paper and we can extract needed field easily and bypassing all other fields.

At different layers, we need to parse different things; thus, we need to have mutiple transparent films.  Upper layers may need results from lower layers. Careful design of the transparent film is needed to avoid duplicates. Results should be stored in a hash table to quick lookup later by upper layers.

A thought on fast parsing

S.O.L.I.D. Object Design Principle

I attended a NDDNUG about SOLID. It’s pretty interesting.

What is SOLID?

S.O.L.I.D. is a collection of best-practice object-oriented design principles that you can apply to your design to accomplish various desirable goals like loose-coupling, higher maintainability, intuitive location of interesting code, etc.  S.O.L.I.D. is an acronym for the following principles…

To learn more, check out this blog:

S.O.L.I.D. Object Design Principle

A thought on code review

Code review was a scary concept for me in the beginning. After years of seeing bad codes coming back to haunt me, of fixing bugs causing by simple avoidable mistakes such as copy/paste mistake, I learned that code review is not only useful but only a must-have procedure for quality software development. Driven from that view, I made suggestions to management. It took awhile but eventually I’m grateful that management formed code review group  and I was selected to the group. Here are my thoughts on code review process. 

In order to have a good code review process, you must have a standard code guideline and a code review checklist:

  • a standard codign guideline: there are a lot of them on the internet. Just google them.
    Code convention includes
    code style (space/tab, brackets, comments…),
    naming convention (camel case or underscore for each word,  class/function/variable name prefixes if any…),
    standard coding practices (avoid goto, buffer overflow, dangling pointer,… )… 
    Notes: It should be customized to your organization to maximize effectiveness. 
  • a code review checklist: Not all code reviewers are created equal. Some are more detail or  thorough or senior than the others. This checklist standardizes the process and helps everyone review faster. It specially helps junior programmers learn coding better.
    Notes: It should be customized to your organization to maximize effectiveness. 
    1/ Did programmer add comments per guideline?

    30/ Are newly added classes/functions neccessary? Can existing classes/functions be refactored to meet requirement?


Funny blog on code review

Google code style guide

A thought on code review