Why NoSQL?

Today, three interrelated megatrends – Big Data, Big Users, and Cloud Computing – are driving the adoption of NoSQL technology. More and more organizations recognize that operating at scale is better achieved on clusters of standard, commodity servers, and a schema-less data model is often better for the variety and type of data captured and processed today.

Features of NoSQL:

• Simplicity of design
• Horizontal scaling
• Finer control over availability
• No schema
• Support structures: key/value, graph...
• Embedded documents and arrays reduce need for joins as in relational SQL, which is key for high performance and speed.

Developers want a very flexible database that easily accommodates new data types and isn’t disrupted by content structure changes from third-party data providers. Much of the new data is unstructured and semi-structured, so developers also need a database that is capable of efficiently storing it. 

A NoSQL database is the type of database that can handle the sort of unstructured, messy and unpredictable data that our system of engagement requires.

For example, a document-oriented NoSQL database takes the data you want to store and aggregates it into documents using the JSON format. Each JSON document can be thought of as an object to be used by your application. A JSON document might, for example, take all the data stored in a row that spans 20 tables of a relational database and aggregate it into a single document/object. Aggregating this information may lead to duplication of  information, but since storage is no longer cost prohibitive, the resulting data model flexibility, ease of efficiently distributing the resulting documents and read and write performance improvements make it an easy trade-off for web-based applications.

NoSQL is not built on tables and does not employ SQL to manipulate data. It also may not provide full ACID (atomicity, consistency, isolation, durability) guarantees, but still has a distributed and fault tolerant architecture. The NoSQL taxonomy supports key-value stores (dictionary structure), document store, BigTable, and graph databases. Redis is one of the most popular key-value store.

NoSQL is gaining momentum, and is supported by Hadoop, MongoDB, DynamoDB (Amazon Service) and others.

Reference: 

• http://www.couchbase.com/why-nosql/nosql-database
• http://www.zdnet.com/what-is-nosql-and-why-do-you-need-it-7000004989/

Different Types of Software Design Principles

Software design principles are a set of guidelines that helps developers to make a good system design. The most important principle is SOLID principle. The key software design principles are as:

1. SOILD

   It is combination of five basic designing principles.

   1. Single Responsibility Principle (SRP)

      This principle states that there should never be more than one reason for a class to change. This means that you should design your classes in such a way that each class should have a single purpose.
      Example - An Account class is responsible for managing Current and Saving Account but a CurrentAccount and a SavingAccount classes would be responsible for managing current and saving accounts respectively. Hence both are responsible for single purpose only. Hence we are moving towards specialization.

   2. Open/Closed Principle (OCP)

      This principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. The "closed" part of the rule states that once a module has been developed and tested, the code should only be changed to correct bugs. The "open" part says that you should be able to extend existing code in order to introduce new functionality.
      Example – A PaymentGateway base class contains all basic payment related properties and methods. This class can be extended by different PaymentGateway classes for different payment gateway vendors to achieve theirs functionalities. Hence it is open for extension but closed for modification.

   3. Liscov Substitution Principle (LSP)

      This principle states that functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
      Example - Assume that you have an inheritance hierarchy with Person and Student. Wherever you can use Person, you should also be able to use a Student, because Student is a subclass of Person.

   4. Interface Segregation Principle (ISP)

      This principle states that Clients should not be forced to depend upon interfaces that they don’t use. This means the number of members in the interface that is visible to the dependent class should be minimized.
      Example - The service interface that is exposed to the client should contains only client related methods not all.

   5. Dependency Inversion Principle (DIP)

      The Dependency Inversion Principle states that:
      1. High level modules should not depend upon low level modules. Both should depend upon abstractions.
      2. Abstractions should not depend upon details. Details should depend upon abstractions.
      It helps us to develop loosely couple code by ensuring that high-level modules depend on abstractions rather than concrete implementations of lower-level modules. The Dependency Injection pattern is an implementation of this principle
      Example - The Dependency Injection pattern is an implementation of this principle

2. DRY (Don’t Repeat Yourself)

   This principle states that each small pieces of knowledge (code) may only occur exactly once in the entire system. This helps us to write scalable, maintainable and reusable code.
   Example – Asp.Net MVC framework works on this principle.

3. KISS (Keep it simple, Stupid!)

   This principle states that try to keep each small piece of software simple and unnecessary complexity should be avoided. This helps us to write easy maintainable code.

4. YAGNI (You ain't gonna need it)

   This principle states that always implement things when you actually need them never implements things before you need them.

What do you think?

I hope you will enjoy the design principles while designing your application. I would like to have feedback from my blog readers. Your valuable feedback, question, or comments about this article are always welcome.

Source: http://www.dotnet-tricks.com/Tutorial/designpatterns/RPW2250513-Different-Types-of-Software-Design-Principles.html

How Friction Slows Us Down

(Source: http://securesoftwaredev.com/2013/01/28/how-friction-slows-us-down/)

I once joined a project where running the “unit” tests took three and a half hours.

As you may have guessed, the developers didn’t run the tests before they checked in code, resulting in a frequently red build. Running the tests just gave too much friction for the developers.

I define friction as anything that resist the developer while she is producing software.

Since then, I’ve spotted friction in numerous places while developing software.

Friction in Software Development

Since friction impacts productivity negatively, it’s important that we understand it. Here are some of my observations:

• Friction can come from different sources.
  It can result from your tool set, like when you have to wait forPerforce to check out a file over the network before you can edit it.
  Friction can also result from your development process, for example when you have to wait for the QA department to test your code before it can be released.
• Friction can operate on different time scales.
  Some friction slows you down a lot, while others are much more benign. For instance, waiting for the next set of requirements might keep you from writing valuable software for weeks.
  On the other hand, waiting for someone to review your code changes may take only a couple of minutes.
• Friction can be more than simple delays.
  It also rears its ugly head when things are more difficult then they ought to be.
  In the vi editor, for example, you must switch between command and insert modes. Seasoned vi users are just as fast as with editors that don’t have that separation. Yet they do have to keep track of which mode they are in, which gives them a higher cognitive load.

Lubricating Software Development

There has been a trend to decrease friction in software development.

Tools like Integrated Development Environments have eliminated many sources of friction.

For instance, Eclipse will automatically compile your code when you save it.

Automated refactorings decrease both the time and the cognitive load required to make certain code changes.

On the process side, things like Agile development methodologies and the DevOps movement have eliminated or reduced friction. For instance, continuous deployment automates the release of software into production.

These lubricants have given us a fighting chance in a world of increasing complexity.

Frictionless Software Development

It’s fun to think about how far we could take these improvements, and what the ultimate Frictionless Development Environment (FDE) might look like.

My guess is that it would call for the combination of some of the same trends we already see in consumer and enterprise software products. Cloud computing will play a big role, as will simplification of the user interaction, and access from anywhere.

What do you think?

What frictions have you encountered? Do you think frictions are the same as waste in Lean?

What have you done to lubricate the frictions away? What would your perfect FDE look like?

Please let me know your thoughts in the comments.

Check out other article: Using Continuous Integration to Reduce Project Friction

JotForm - Platform for building/hosting user forms

While I was looking for a sample building a Feedback feature, I came across an exellent solution for this feature. There is already a provider that build all sorts of forms, including Feedback forms. It works just like Facebook which provides a platform for features "like/share...".

I wonder why I was looking for a way that re-invent the wheel. Here is the service:
http://www.jotform.com

This is an add-on service for every Web apps. With this platform, you can create any form you like. You can drag and drop any kind of controls just like you do things visually in .NET IDE.... Overall, you can do any custom design as you wish. That's cool!

For form templates, there are Feedback form, CV Submission, Product Order Form, Payment Form, Event Registration...


Obviously, the founder has a great idea for this kind of service. In the modern Web generation nowadays, thíng are connected all together. Trying to integrate the mashups, controls and add-on services to make your Web thrive is an efficient solution ever.

Truong Pham,