Friday, February 27, 2015


Did you know?
 The Raspberry Pi sprang out of a desire by colleagues at the University of Cambridge’s Computer Laboratory to see a return to the days of kids programming inexpensive computers. The rise of expensive PCs and games consoles put paid to the BBC B, Spectrum and C64 generation of home programmers, leading to applicants for computer studies courses lacking the necessary skills.
The basic concepts behind the Raspberry Pi were to make it as affordable as possible, supply only the basics and provide it with a programming environment and hardware connections for electronics projects. The Pi is a series of credit card-sized single-board computers, which runs a modified version of Linux called Raspian with Wheezy Raspian being the preferred option for newcomers to the device. Raspian runs directly on an SD card and provides a command-line interface for using the operating system.

The original Raspberry Pi and Raspberry Pi 2 are manufactured in several board configurations through licensed manufacturing agreements with Newark element14 (Premier Farnell), RS Components and Egoman.

Fig: Raspberry Pi (Model B)

Programming the Pi
There are two programming languages supplied by default with the Pi: Scratch v1.4 and Python. They both have shortcut icons on the graphical desktop. Scratch was designed by Lifelong Kindergarten Group at the MIT Media Lab as a firststep in programming. It uses tile-based language commands that can be strung together without having to worry about syntax. Commands are split up into easy-to-understand groups and dragged onto the scripting area. Sounds, graphics and animation can be added. Projects can be saved or uploaded to the Scratch website and shared for remixing by other users.
The other language is Python v3.2.3 which starts with a Python Shell. Python is an interpreted language, where commands are read and implemented one line at a time. The high level commands and data structures make it ideal for scripting. The previous version of Python is still quite popular and has more development aids, so is also supplied. The icons for these are IDLE 3 and IDLE, which stands for Integrated Development Language for Python.

The Pi Store
The Pi Store isn’t just home to apps and tools to help you use your Raspberry Pi. There’s also a selection of home-grown video games to get your teeth into, that are developed by the Raspberry Pi community.

Monday, February 9, 2015

CQRS (Command Query Responsibility Segregation) Pattern

Command–query separation (CQS) is a principle of imperative computer programming. It was devised by Bertrand Meyer. It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, methods should return a value only if they are referentially transparent and hence possess no side effects.

Command Query Responsibility Segregation (CQRS) applies the CQS principle by using separate Query and Command objects to retrieve and modify data, respectively. CQRS Pattern segregate operations that read data from operations that update data by using separate interfaces. This pattern can maximize performance, scalability, and security; support evolution of the system over time through higher flexibility; and prevent update commands from causing merge conflicts at the domain level.

CQRS is a pattern that segregates the operations that read data (Queries) from the operations that update data (Commands) by using separate interfaces. This implies that the data models used for querying and updates are different. The models can then be isolated, although this is not an absolute requirement.
Compared to the single model of the data that is inherent in CRUD-based systems, the use of separate query and update models for the data in CQRS-based systems considerably simplifies design and implementation.
The query model for reading data and the update model for writing data may access the same physical store, perhaps by using SQL views or by generating projections on the fly. However, it is common to separate the data into different physical stores to maximize performance, scalability, and security; as shown in Figure.
The read store can be a read-only replica of the write store, or the read and write stores may have a different structure altogether. Using multiple read-only replicas of the read store can considerably increase query performance and application UI responsiveness, especially in distributed scenarios where read-only replicas are located close to the application instances. Some database systems, such as SQL Server, provide additional features such as failover replicas to maximize availability. Separation of the read and write stores also allows each to be scaled appropriately to match the load.

When to Use this Pattern
This pattern is ideally suited to:
  • Collaborative domains where multiple operations are performed in parallel on the same data.
  • Use with task-based user interfaces (where users are guided through a complex process as a series of steps), with complex domain models, and for teams already familiar with domain-driven design (DDD) techniques.
  • Scenarios where performance of data reads must be fine-tuned separately from performance of data writes, especially when the read/write ratio is very high, and when horizontal scaling is required
  • Scenarios where one team of developers can focus on the complex domain model that is part of the write model, and another less experienced team can focus on the read model and the user interfaces.
  • Scenarios where the system is expected to evolve over time and may contain multiple versions of the model, or where business rules change regularly.
  • Integration with other systems, especially in combination with Event Sourcing, where the temporal failure of one subsystem should not affect the availability of the others.
This pattern might not be suitable in the following situations:
  • Where the domain or the business rules are simple.
  • Where a simple CRUD-style user interface and the related data access operations are sufficient.
  • For implementation across the whole system. There are specific components of an overall data management scenario where CQRS can be useful, but it can add considerable and often unnecessary complexity where it is not actually required.

Event Sourcing and CQRS
The CQRS pattern is often used in conjunction with the Event Sourcing pattern. CQRS-based systems use separate read and write data models, each tailored to relevant tasks and often located in physically separate stores. When used with Event Sourcing, the store of events is the write model, and this is the authoritative source of information. The read model of a CQRS-based system provides materialized views of the data, typically as highly denormalized views. These views are tailored to the interfaces and display requirements of the application, which helps to maximize both display and query performance.
Using the stream of events as the write store, rather than the actual data at a point in time, avoids update conflicts on a single aggregate and maximizes performance and scalability. The events can be used to asynchronously generate materialized views of the data that are used to populate the read store.
Because the event store is the authoritative source of information, it is possible to delete the materialized views and replay all past events to create a new representation of the current state when the system evolves, or when the read model must change. The materialized views are effectively a durable read-only cache of the data.

Friday, January 30, 2015

Codenamed "Threshold" : Windows 10

An update to Windows 8, codenamed Threshold, a "wave of operating systems" across multiple Microsoft platforms and services, scheduled for release around the second quarter of 2015. The goals for Threshold was to create a unified application platform and development toolkit for Windows, Windows Phone and Xbox One (which all use a similar Windows NT kernel). It was speculated that Threshold would be branded as "Windows 9". But Threshold was officially unveiled during a media event on September 30, 2014, under the name "Windows 10".
  • Windows 10 designed with enterprise customers in mind
  • One converged Windows platform
  • Designed for the way you live and work
  • Helping protect against modern security threats
  • Managed for continuous innovation
  • Windows 10 helps keep customers secure and up to date
  • Enabling management for every scenario
  • An app store that is open for business
Window 10 Features:
User interface and desktop
Windows 10's user interface changes its behavior depending on the type of device and available inputs, and provides transitions between interface modes on convertible laptops and tablets with docking keyboards.
Online services
Windows 10 incorporates Microsoft's intelligent personal assistant Cortana, as introduced on Windows Phone, It is implemented as a search box located next to the Start button.
Multimedia and gaming
Windows 10 will provide heavier integration with the Xbox ecosystem: an updated Xbox app succeeds Xbox SmartGlass on Windows, allowing users to browse their game library (including both PC and Xbox console games), and Game DVR is also available using a keyboard shortcut, allowing users to save the last 30 seconds of gameplay as a video that can be shared to Xbox Live, OneDrive, or elsewhere.
Update system
Windows 10 will be serviced in a significantly different manner from previous releases of Windows. By default, users receive critical updates, security patches and non-critical updates to the operating system and its functionality as they are released, but can optionally opt out of or delay the installation of non-critical updates.
 Other cool stuff:
  • Start Menu is Back
  • New Task View
  • Snap Assist helps you snap windows
  • The Command Prompt Got Way More Than Just Ctrl-V
  • Notifications Are Getting a Makeover
  • Pin the Recycle Bin to The Start Menu and Taskbar
  • Explorer Has a New "Home" With Your Most-Used Folder Locations
  • Keyboard Shortcuts Make Virtual Desktops Super Easy to Use
  • File History is Now Its Own Tab in Properties
  • Windows 10 Universal apps, apps now float on the Desktop

Friday, January 2, 2015

Welcome 2015

Along with all the new hopes and promises
that the New Year would bring
Hope it also brings us a lot more opportunities
New Aim, New Dreams, New Achievements
Everything Waiting for You
Forget The Failures, Correct Your Mistakes
Surely Success is yours.
Wish you a Happy New Year 2015!

Monday, December 22, 2014


Ember.js is a framework that enables user to build “ambitious” web applications. That term “ambitious” can mean different things to different people, but as a general rule, Ember.js aims to help user, push the envelope of develop code for the web, while ensuring that application source code remains structured and sane. Ember.js achieves this goal by structuring an application into logical abstraction layers and forcing the development model to be as object-oriented as possible. At its core, Ember.js has built-in support for the following features:
  • Bindings - Enables the changes to one variable to propagate into another variable and vice versa
  • Computed properties - Enables to mark functions as properties that automatically update along with the properties they rely on
  • Automatically updated templates - Ensures that GUI stays up to date whenever changes occur in the underlying data
With the combination of these features along with a strong and well-planned Model-View-Controller (MVC)  architecture results into a framework that delivers on its promise.
Below image shows the internal architecture of Ember framework:
Ember.js application includes - a complete MVC implementation, which enriches both the controller and the view layers, and Ember Data enriches the model layer of Ember.js.
  • Model layer - Built with an ember objects
  • View layer - Built with a combination of templates and views
  • Controller layer - Built with a combination of routes and controllers

Saturday, November 29, 2014

Wednesday, October 29, 2014

Representational state transfer (REST)

Roy Fielding generalized the Web’s architectural principles and presented them as a framework of constraints, or an architectural style in his Ph.D. dissertation. Through this framework, Fielding described how distributed information systems such as the Web are built and operated. He described the interplay between resources, and the role of unique identifiers in such systems. He also talked about using a limited set of operations with uniform semantics to build a ubiquitous infrastructure that can support any type of application. Fielding referred to this architectural style as REpresentational State Transfer, or REST. REST describes the Web as a distributed hypermedia application whose linked resources communicate by exchanging representations of resource state.
Representational state transfer (REST) is an abstraction of the architecture of the World Wide Web; more precisely, REST is an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
The description of the Web, as captured in W3C’s “Architecture of the World Wide Web” and other IETF RFC documents, was heavily influenced by Fielding’s work. The architectural abstractions and constraints he established led to the introduction of hypermedia as the engine of application state.
The idea is simple, and yet very powerful. A distributed application makes forward progress by transitioning from one state to another, just like a state machine. The difference from traditional state machines, however, is that the possible states and the transitions between them are not known in advance. Instead, as the application reaches a new state, the next possible transitions are discovered.
In a hypermedia system, application states are communicated through representations of uniquely identifiable resources. The identifiers of the states to which the application can transition are embedded in the representation of the current state in the form of links.
Example of hypermedia as the engine for application state in action

REST - An Architectural Style, Not a Standard ,while REST is not a standard, it does use following standards:
  • HTTP
  • URL
  • XML/HTML/GIF/JPEG/etc (Resource Representations)
  • text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

Principles of REST Web Service Design
  1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services.
  2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:
        Note the verb, getPart. Instead, use a noun:
  3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
  4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.
  5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.
  6. Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details.
  7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.
  8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.