Blog Objective

This is a blog that attempts to make life easier by noting down the author's accrued knowledge and experiences.
The author has dealt with several IT projects (in Java EE and .NET) and is a specialist in system development.

23 May 2013

Use Case Realisation in UML

This is a sample of a use case realisation (design-level) for a use case “View the Dashboard”.
The implementation uses ASP.NET MVC and the design is documented in the following UML diagrams.
This is an experiment whereby I produced the design in UML for a new developer to implement the use case.

The following Sequence Diagram documents the initial web request to display the empty Dashboard.
Initial Request
The following Sequence Diagram documents subsequent web requests to display the search result.
Retrieval Request
The next Sequence Diagram specifies the implementation of DashBoardCntrl::retrievePlanListFromCache.
DashBoardCntrl__retrievePlanListFromCache
The final is the View-Of-Participating-Class (VOPC) diagram for this use case realisation.
VOPC

15 May 2013

When is a Sequence Number Not Sequential?

A sequence number or an identity column guarantees the following:

  1. Number served is unique.
  2. Number served is sequential (ascending order) - Identity columns guarantees this; sequence number in Oracle RAC mode doesn't, unless ORDER is used.
However:
  1. It does not guarantee the sequence is gap-free
  2. Sequence number/ identity columns do not partake in transactions
Number loss/ gaps happen due to the following:
  1. Served number does not get utilised (typically due to transaction rollback)
  2. Server restart/ failures - database servers tend to cache sequences in memory for performance reasons. E.g. Oracle Sequence number set-up to be CACHEd in memory.
Serialization appears to be the only solution. However, serialization would be non-scalable and would incur a huge performance impact.

07 May 2013

Psychology Behind Dishonesty

An appreciation to why people are dishonest.
Flash version can be found here.

Psychology Behind Dishonesty

09 April 2013

How to determine if you've been blocked by a WhatsApp contact

According to the legal clauses in WhatsApp, such blocks have been made non-deterministic to protect privacy.

However, by experimentation, you'd notice the following when you've been blocked:
  1. unable to see the "online" or "last seen" of the contact. Described here
  2. messages sent to the party does not get delivered - indicated by 1 tick instead of 2
  3. unable to create a group with the party - An error message appears "Error while adding participant... not authorized to add this contact"
The first 2 indicators are explained in WhatsApp's FAQ. Of interest is:
We have made this intentionally ambiguous in order to protect your privacy when you block someone. Thus, we cannot tell you if you are being blocked by someone else, since this is a violation of that person's privacy 


However, the 3 indicator above (not mentioned by WhatsApp) appears to be a very strong indicator that you've been blocked by the contact.

08 April 2013

HTTP Redirection

According to the HTTP specs, there are a number of HTTP codes used to redirect browser clients.
 
  • 301 Moved Permanently: Permanent redirect. Document has moved permanently, future requests to use the redirected URL instead. Response is cacheable. Modern browsers change the HTTP method to a GET with the exception of IE (which preserves HTTP HEAD, DELETE method).
  • 302 Found: Temporary redirect. To be superseded by 303 and 307. Response may be cached if headers allow for it. Most modern browsers treat this as 303 with the exception of IE (which treats it as 307).
  • 303 See Other: Request should be redirected to a GET regardless of the original request method. The response must not be cached. Supported by all modern browsers.
  • 307 Temporary Redirect: Temporary redirect. Request should be redirected to the redirected URL. The original request method is to be preserved and a POST request should be re-posted. Response may be cached if headers allow for it. Supported by all modern browsers except Opera 11.5. If the request method is non-idempotent (e.g. POST, PUT, DELETE), Firefox and Opera would prompt the user for confirmation that the form data would be resent to another location.
Tests on existing browser found here.
Some references: HTTP specshere