Wednesday, May 27, 2015

Is it 'NoSQL' or 'Not Only SQL' ?


It was a compelling realization to answer myself what NoSQL is. While attending a training session on 'Cassandra Performance Tuning', there was a mention that Cassandra was a NoSQL database. Even with a good experience on NoSQL databases like MongoDB (document), Neo4J (graph) and InfluxDB (time series), I never gave a serious thought on NoSQL concept. With CQL (just like SQL), Cassandra is just like any SQL (relational) database. That made me think what really NoSQL is.

On a serious reflection, we can find that it is never No SQL, but Not only SQL. But, with a detailed consideration, it is not at all about SQL. It's about data modeling and more of data principle. The normal SQL (relational) database has a tabular data modeling to accomplish ACID and JOIN with normalization. Moreover, due to the tabular data modeling, the structured query language can filter columns in a table. On the contrary, NoSQL database is distributed implementation, mostly compromising consistency in CAP theorem and sacrificing ACID. The main difference I noticed is that the NoSQL query filters only rows (not columns) in the big data. That's why generally people make the distinction between relational and non-relational databases (not SQL and NoSQL). However, there are some non-relational databases that support ACID and JOIN, called NewSQL databases.

There are many implementations of the NoSQL (non-relational) databases in terms of their data modeling. As each of them has their own use cases and a detailed analysis on them are not in our scope, few examples for the sake of it are Column (Cassandra), Document (MongoDB), Key-Value (CouchDB), Graph (Neo4J) and Multi-model (OrientDB).

In a nutshell, it's not about the query language being used, how databases are categorized, but about the modeling. When you have non-relational database with ACID, it's called NewSQL and otherwise NoSQL. In relational data modeling, the data storage is a black-box to the user, concealing the interns of the structure, giving an interface of a structured query language. On the other hand, non-relational (NoSQL or NewSQL) database exposes the data structure to the user, providing flexibility of interface and scaling. Beware! Freedom always comes with a price. The developers (users) are given power with more responsibility (need of knowing interns) and long learning curve!

Friday, May 1, 2015

AngularJS & SemanticUI: Made for Each Other

It’s just couple of years back that I started working on AngularJS, putting aside my JSF and Primefaces reluctantly. As everyone, I had no other choice, but used Brootstrap as CSS framework and thought that was how HTML theme worked. That was true with the pages in static nature. However, the exploration of client-side frameworks and responsive sites with hand-held devices, I was forced to explore for alternatives. It was an eye-opening way of theming a JavaScript-powered web page with relatively new and vibrant framework called SemanticUI. With my peripheral and horizontal technology stack and experience, I’m not an expert to write this blog. However, it’s an outpouring of my wow experience with AngularJS and SemanticUI.

It is needless to say AngularJS has an edge over competitors. When I switched from ExtJS to AngularJS, I began to marvel at the modularity and flexibility. The simplicity lies in making static HTML tags dynamic. The ‘Model-View-Whatever’ framework model allows to separate presentation logic from business logic. I love the directives and two-way-binding of it. Since the discussion on the pros and cons of AngularJS is not in the scope of this write-up, any kind of analysis on the use cases of AngularJS is left totally up to the reader. However, the simplicity and flexibility of AngularJS (not prescribing a specific application architecture or set of patterns) leads to the confusion of selecting the library of user interface components. This is where I can help you.

Are you in a dilemma of what CSS framework to use with AngularJS? Try SemanticUI, simply because both of them share the same philosophy. SemanticUI is literally semantic. It treats words and classes as exchangeable concepts. Classes use syntax from natural languages like noun/modifier relationships, word order, and plurality to link concepts intuitively. It makes dynamic styling. When it joins hands with AngularJS’ two-way-binding, it’s marvelous. Intuitive Javascript is another aspect that makes it closer to AngularJS. It uses simple phrases called behaviors that trigger functionality. Any arbitrary decision in a component is included as a setting that AngularJS binding can modify dynamically. Another feature that makes it stand out from the competitors is its simplified debugging property. Performance logging lets us track down bottlenecks without digging through stack traces.

The write-up neither compares and analyzes all competitors, nor claims to be a comprehensive answer to the question. Nevertheless, it’s just an attempt to subjectively echo how AngularJS with SemanticUI eases the web developer life. As I don’t want make it drier with code snippets and use cases, let me conclude underlining the point that both AngularJS and SemanticUI share the same philosophy and complement each other. SemanticUI needs not be the best theme framework, but it’s the better half of AngularJS. May be coincidental, but true – they are made for each other!

ഇന്ന്

ഇന്നലെ യെ കുറിച്ച് വ്യാകുലപ്പെടുന്ന നാളെ യാണ് നമ്മുടെ ഇന്ന്!