Fundamentals

The fundamental concept behind Swarm is that we should “move the computation, not the data”.
The Swarm prototype is a simple stack-based language, akin to a primitive version of the Java bytecode interpreter. I wanted the proof of concept to be quick to implement, while demonstrating that the concept could work for a popular runtime like the JVM or Microsoft’s CLR.
Update (Sept 17th 09): Swarm is now implemented as a Scala library, so you program in normal Scala, rather than a custom stack-based library as with the prototype described here.  It uses the Scala 2.8 Continuations plugin to achieve this.  See end of blog post for further information.

The Prototype

The prototype is implemented in Scala, and I will use snippets of Scala code below, but a knowledge of Scala won’t be required to understand the rest of this article. I chose Scala because I wanted to learn it, and because its rich semantics tends to make coding easier and faster than Java (my normal language of choice).
As with the JVM, there are three places to store data in the Swarm VM: the stack, a local variable array, and the store. The stack is used for intermediate values in computations, data here tends to be very short-lived. In the prototype it is implemented as a List[Any]. The local variable array is for data that is used within a block of code (its implemented as a Map[Int, Any]).

The “Store”

The “store” is somewhat analogous to the JVM heap. It is used for long-term storage of data, indeed, in an actual implementation it may be persistent, and/or transactional, but in the prototype it is in-memory. The store contains “objects”, each of which is a list of key-value pairs. The values may be references to other objects. The store is implemented as a Map[Int, Map[String, Any]].

Read more: Hypergraphia Indulged

Links to this post

Tags: Programming

Hibernate's Criteria is a very comprehensive API which provides the user alot of flexibility to write dynamic queries. But of course nothing is perfect. I came across a situation where i had to truncate a date field in order to get the correct result set without considering the time portion. While going through the Criteria API I did not find anything which allowed me to do this. And hence in the path for a solution i found out that Criteria allows for plain SQL syntax to be included which i thought was a big plus point because it gives the developer the flexibility without restricting him/her just to the API.
The following code depicts the way you can incorporate plain SQL to your criteria API.

DetachedCriteria testCirteria = DetachedCriteria.forClass(Employee.class);
SimpleDateFormat dateFormatForSearch = new SimpleDateFormat("dd/MM/yyyy");
Calendar joinDate = empSearchDTO.getJoinDate();
if (joinDate != null)

Links to this post

Tags: NHibernate, SQL

As my experience we always close to the latest technologies as we have one step ahead on web development techniques as HTML5. HTML 5 is the advanced version of  HTML.  HTML 5 is giving  new techniques and advanced features/structure in designing. These new features and tags makes designing very easy to create a web page.
CSS3 and HTML 5 are capable of revolutionizing the way we design websites. Both include so many new features and functions that it can be hard to wrap your head around them at times. HTML5 is giving web designers and developers new capabilities that were things of fantasy with previous versions of HTML. Web pages will now be more semantic with the use of structure specific tags. The inclusion of native support for things like rounded corners and multi-column layouts are just the tip of the ice berg.
When saying about HTML5, developers mean the new semantic structural tags, API specs like canvas or offline storage, new inline semantic tags, etc. HTML5, in fact, is aimed at creating a comprehensive markup language for front-end development, able to provide qualitative information on the different elements of the page. But to help make some sense of what’s new and essential in HTML5, you could review some helpful and indispensable HTML5 tutorials that go over many of the major HTML5 aspects and new standards.

How to Make an HTML5 iPhone App
A Marriage Made in Heaven? HTML 5 and CSS3
HTML 5 and CSS 3: The Techniques You’ll Soon Be Using
When can I use…

Read more: Tutorial lounge

Links to this post

Tags: HTML5, Web-programming

In this blog I have done at many articles on Normalization and Denormalization, but I have never put all of the arguments together in one place, so that is what I would like to do today.
There are links to related essays on normalization and denormalization at the bottom of this post.
This blog has two tables of contents, the Topical Table of Contents and the list of Database Skills.

The What and Why of Normalization

Normalization is the process of designing tables so that each fact is stored in exactly one place. A "fact" in this case is any detail that we have to keep track of, such as a product's description, a product's price, an employee's social security number, and so forth.
The process is all about figuring out what tables you need and what columns each table will have. If we are talking about an employee's social security number, then we can guess right from the start that will have a table of EMPLOYEES, and that one of the columns will be SSN. As we get more details, we add more tables and columns.
The advantage of normalization comes when your application writes data to the database. In the simplest terms, when the application needs to store some fact, it only has to go to one place to do it. Writing this kind of code is very easy. Easy to write, easy to debug, easy to maintain and improve.
When the database is not normalized, you end up spending more time writing more complicated application code that is harder to debug. The chances of bad data in your production database go way up. When a shop first experiences bad data in production, it starts to become tempting to "lock down" access to the database, either by forcing updates to go through stored procedures or by trying to enforce access to certain tables through certain codepaths. Both of these strategies: stored procedures and code paths, are the actually the same strategy implemented in different tiers, they both try to prevent bugs by routing access through some bit of code that "knows what to do." But if the database is normalized, you do not need any magic code that "knows what to do."
So that, in brief, is what normalization is and why we do it. Let's move on now to denormalization.

Denormalization is Harder to Talk About