User stories - WHO wants them, WHAT are they and WHY use them?

User stories are a popular technique for capturing high-level requirements. User stories provide the rationale and basic description of a new feature request. The following format is the most recognizable user story template:

As a <WHO>
I want <WHAT>
So that <WHY>

Agile teams adopting the user story technique often struggle with questions such as: WHO are user stories produced for? WHAT do good user stories look like? WHY maintain user stories instead of more detailed requirement specifications? To answer these questions – I will recycle the who/what/why template of user stories.

WHO WANTS USER STORIES?

• Project stakeholders: these individuals want an easy method to pin ideas to the product backlog. With user stories - ideas don’t need to be defined in detail – the user story will provide a “placeholder for a conversation”.
• The end user: teams that are able to elicit requirements directly from end users can use this technique to facilitate the discussion and documentation of feature requests. What does the user want to do? Why?
• Project Manager/Product Owner: when grooming the product backlog – user stories are much easier to prioritise than detailed requirement specifications. User stories provide a non-technical, concise summary for the product team to decide the primacy of a feature.

WHAT ARE USER STORIES?

• Definition: User stories describe the desired interaction/dialogue between a user and the system. User stories provide the user’s rationale for a feature.
• Typical format:
  
  1. AS A [actor/user role] – this can be referred to as the WHO section. Who wants this feature? The user could be a generic actor (e.g. AS A user of the website), or a specific user role (e.g. AS A frequent business traveler), or even another system (AS A BACS payment system). Actors can be identified by internal discussions within the project team – identifying user roles may require more sophisticated analysis (e.g. profiling activities by the marketing department, transaction analysis, industry segmentations etc).
  2. I WANT [feature/action] – this can be referred to as the WHAT section. What does the user want? The user will typically want the system to perform a new behaviour e.g. I WANT the ability to track an order, I WANT to pay for orders using an AMEX card, I WANT to cancel an order without any hassle.
  3. SO THAT [benefit] – this can be referred to as the WHY section. Why does a user want this functionality? This section provides the justification/benefit of the feature.

• Characteristics of good user stories: the INVEST acronym is frequently used to describe attributes of a good user story:
  1. Independent
  2. Negotiable
  3. Valuable/Vertical
  4. Estimable
  5. Sized Appropriately/Small
  6. Testable

WHY USE USER STORIES?

• Requirements as an emergent property: user stories provide the Business Analyst with a springboard for analysis. A single user story (e.g. AS A price sensitive user, I WANT to be able to cancel my order, SO THAT I do not get charged by the bank for exceeding their overdraft limit) can lead to multiple scenarios for the BA. What is the happy path of this user story? What are the edge cases (e.g. what if some of the items were reduced as part of a promotion)? What are the business rules (e.g. full refunds are only provided up to 3 days from when the transaction was processed)? Requirements should emerge from user stories (not vice versa) - all requirements should have a user justification.
• Maintenance of the backlog: the detail of a feature is abstracted a level below user stories. In addition – user stories should have few/no dependencies (refer to the INVEST acronym) – this means that user stories are lightweight additions to the product backlog and are therefore easy to maintain.
• Available for discussion: user stories should be understandable by business users/end users/developers/all team members. User stories facilitate cross-role discussions and encourage open communication between various project silos.
• Trees and forests: Working at a detailed level can occasionally mean that some requirements are not identified. User stories provide a way to mitigate the probability that user journeys are missed by the team.

User stories provide the team with a method to capture and discuss high-level requirements. Good user stories follow the INVEST acronym and provide the user’s justification for a new feature. Within Scrum/Agile teams – user stories provide an abstraction of requirement details – this facilitates maintenance of the backlog and provides the team with a “placeholder for a conversation”.

Hybrid Memory Cube spec makes DRAM 15 times faster

The three largest memory makers - Micron, Samsung and Hynix; announced the final specifications for three-dimensional DRAM, which is aimed at increasing performance for networking and high-performance computing markets. The technology, called a Hybrid Memory Cube (HMC), will stack multiple volatile memory dies on top of a DRAM controller. The DRAM is connected to the controller by way of the relatively new silicon VIA (Vertical Interconnect Access) technology, a method of passing an electrical wire vertically through a silicon wafer.

The logic portion of the DRAM functionality is dropped into the logic chip that sits at the base of that 3D stack. That logic process allows to take advantage of higher performance transistors ... to not only interact up through the DRAM on top of it, but in a high-performance, efficient manner across a channel to a host processor. This logic layer serves both as the host interface connection as well as the memory controller for the DRAM sitting on top of it. The DRAM is broken into 16 partitions, each one with two I/O channels back to the controller. Each Hybrid Memory Cube - there are two prototypes - has either 128 or 256 memory banks available to the host system.

The first Hybrid Memory Cube specification will deliver 2GB and 4GB of capacity, providing aggregate bi-directional bandwidth of up to 160GBps compared with DDR3's 11GBps of aggregate bandwidth and DDR4, with 18GB to 20GB of aggregate bandwidth.

The Hybrid Memory Cube technology solves some significant memory issues. Today's DRAM chips are burdened with having to drive circuit board traces or copper electrical connections, and the I/O pins of numerous other chips to force data down the bus at gigahertz speeds, which consumes a lot of energy. The Hybrid Memory Cube technology reduces this task to make the DRAM drive only tiny TSVs which are connected to much lower loads over shorter distances. A logic chip at the bottom is the only one burdened with driving the circuit board traces and the processor's I/O pins.

The interface is 15 times as fast as standard DRAMs, while reducing power by 70 percent! The beauty of it is that it gets rid of all the issues that were keeping DDR3 and DDR4 from going as fast as they could. For example, instead of having multiple DIMMS (which can range from one to four) on a motherboard, you would need only one Hybrid Memory Cube, cutting down on the number of interfaces to the CPU.

The HMC has defined two physical interfaces back to a host system processor: a short reach and an ultra-short reach.
The short reach is similar to most motherboard technologies today where the DRAM is within eight to 10 inches of the CPU. That technology is aimed mainly for use in network applications and has the goal of boosting throughput from as much as 15Gbps to 28Gbps per lane in a four-lane configuration.
The ultra-short reach interconnection definition is focused on a low energy, close-proximity memory design support of FPGAs, ASICs and ASSPs, such as high-performace networking, and test and measurement applications. That will have a one to three-inch channel back to the CPU, and it has the throughput goal of 15Gbps per lane.

Link: http://www.infoworld.com/d/computer-hardware/hybrid-memory-cube-spec-makes-dram-15-times-faster-215620

REST and SOAP

REST (Representational State Transfer) and SOAP (Simple Object Access Protocol) represent two different styles for implementing services. Technically, REST is an architectural pattern built with simple verbs that overlay well on HTTP. While REST architectural principles could be applied with protocols other than HTTP, in practice REST implementations are used in conjunction with HTTP. SOAP is an XML-based messaging protocol that can be used with any communication protocol, including HTTP.

The main difference between these two approaches is the way that the service state is maintained. With SOAP, movement through different states can be accomplished through interaction with a single service endpoint, which may encapsulate and provide access to many operations and message types. With REST, a limited set of operations is allowed, and these operations are applied to resources represented and addressable by URIs (HTTP addresses). The messages capture the current or required state of the resource. REST works well with Web applications, so you can take advantage of HTTP support for non-XML MIME types or streaming content from a service request. Service consumers navigating through REST resources interact with URIs in the same way as a human user might navigate through and interact with Web pages.

While both REST and SOAP can be used with most service implementations, the REST approach is often better suited for publicly accessible services or cases where a service can be accessed by unknown consumers. SOAP is much better suited to implementing a range of procedural interactions, such as an interface between layers of an application. With SOAP, you are not restricted to HTTP. The WS-* standards, which can be utilized in SOAP, provide a standard and therefore interoperable method of dealing with common messaging issues such as security, transactions, addressing, and reliability. REST can also provide the same type of functionality, but you must often create a custom mechanism because only a few standards currently exist for these areas.

In general, same principles can be used when designing SOAP based interactions as you do for stateless REST interactions. Both approaches exchange data (the payload) using verbs. In the case of SOAP, the set of verbs is open ended and is defined by the service endpoint. In the case of REST, the set of verbs is constrained to preset verbs that mirror the HTTP protocol. Guidelines when choosing between REST and SOAP:

• SOAP is a protocol that provides a basic messaging framework upon which abstract layers can be built, and is commonly used as an RPC framework that passes calls and responses over networks using XML-formatted messages. 
• SOAP handles issues such as security and addressing through its internal protocol implementation, but requires a SOAP stack to be available.
• REST is a technique that can utilize other protocols, such as JavaScript Object Notation (JSON), the Atom publishing protocol, and custom Plain Old XML (POX) formats.
• REST exposes an application and data as a state machine, not just a service endpoint. It allows standard HTTP calls such as GET and PUT to be used to query and modify the state of the system. REST is stateless by nature, meaning that each individual request sent from the client to the server must contain all of the information necessary to understand the request since the server does not store the session state data.

Design Considerations for REST
REST represents an architecture style for distributed systems, and is designed to reduce complexity by dividing a system into resources. The resources and the operations supported by a resource are represented and exposed as a set of URIs over the HTTP protocol. Consider the following guidelines when designing REST resources:

• Identify and categorize resources that will be available to clients.
• Choose an approach for resource representation. A good practice would be to use meaningful names for REST starting points and unique identifiers for specific resource instances. For example, http://www.contoso.com/employee/ represents an employee starting point. http://www.contoso.com/employee/smithah01 uses an employee ID to indicate a specific employee.
• Decide if multiple representations should be supported for different resources. For example, you can decide if the resource should support an XML, Atom, or JSON format and make it part of the resource request. A resource could be exposed as both (for example, http://www.contoso.com/example.atom and http://www.contoso.com/example.json).
• Decide if multiple views should be supported for different resources. For example, decide if the resource should support GET and POST operations, or only GET operations. Avoid overuse of POST operations if possible, and avoid putting actions in the URI.
• Do not implement the maintenance of user session state within a service, and do not attempt to use hypertext (such as hidden controls in Web pages) to manage state. For example, when users submit requests such as adding an item to a shopping cart, store the data in a persistent state store such as a database.

Design Considerations for SOAP
SOAP is a message-based protocol that is used to implement the message layer of a service. The message is composed of an envelope that contains a header and body. The header can be used to provide information that is external to the operation being performed by the service. For example, a header may contain security, transaction, or routing information. The body contains contracts, in the form of XML schemas, which are used to implement the service. Consider the following guidelines when designing SOAP messages:

• Determine how you will handle faults and errors, and how you will return appropriate error information to clients.
• Define the schemas for the operations that can be performed by a service, the data structures passed with a service request, and the errors or faults that can be returned from a service request.
• Choose the appropriate security model for your services. Avoid using complex types in message schemas. Try to use only simple types to maximize interoperability.

5 Cloud Computing Email Services for Enterprises

Cloud services dynamically balance itself to meet the needs of its users, and because of the fact that the service provider supplies the necessary hardware and software, the need for self-deploying a company resource is simply uncalled for.
Cloud Email Services are pretty different from the normal provisions, as they offer larger storage and better security. Another serious advantage in using a cloud based email service is the option for transferring corporate data from one place to another. These services take the full advantage of cloud computing benefits to maximize capacity utilization, improve IT flexibility and responsiveness, and minimize cost.

1. Google Apps:
Google Apps is a service from Google providing independently customizable versions of several Google products under a custom domain name. The service features a number of functionalities for Gmail, Google Groups, Google Calendar, Talk, Docs and other sites.
Businesses consider Google Apps to be reliable, secure and powerful. Applications like Gmail, Google Calendar and Google Docs, not only reduce the IT costs, but also help employees to work in a more efficient manner.
Google Apps for business is free for 30 days, $5 per user account and month thereafter or $50 per year. Google Apps for Education is free and offers the same amount of storage as Google Apps for Business accounts. Another notable feature is that the service offers an average 25GB of email storage per employee.

2. PanTerra Networks:
PanTerra Networks are one of the major providers in cloud based unified communication services. It has a perfect combination of unified solutions with Software-as-a-Service (SaaS) service, recommended for small and medium sized enterprises. The service provides businesses an option for adding and deleting seats at their will, making a fixed cost of communications for SMBs.
WorldSmart, PanTerra Networks first product, integrates voice, conferencing video, messaging, email collaboration, fax and call center services into a single solution with a common user and administration portal.
In 2010, the company introduced a 100 percent browser-based version of WorldSmart (WorldSmart 4.0), eliminating any on-premise hardware or client software requirements and storing all communications in the cloud.

3. Cisco WebEx Mail:
Cisco WebEx Mail is recommended for companies who are bearing the extra burden of email management and migration issues. Cisco WebEx Mail helps enterprises to concentrate more on their strategic projects, as the service train employees to adapt to ever changing organizational needs.
Another important feature of Cisco WebEx Mail is the inclusion of advanced migration tools. The solution also interoperates with email infrastructure as well as archiving and security solutions which obviously minimize disruptions during the transition to a hosted email solution.

4. VMware Zimbra:
Zimbra Collaboration Suite (ZCS) is a groupware email server and web client created by Zimbra, located in Palo Alto, California, USA. The service provides better enterprise flexibility and integrates services such as email, contacts, calendar, sharing and document management plus mobility and desktop synchronization to users on any computer.
The collaboration suite is built upon advanced web applications and the server is built on open standards and superior technologies, so as to provide unrivaled user scalability and lower overall total cost of ownership (TCO).
The company was purchased by Yahoo! in September 2007, and subsequently acquired by VMware on January 12, 2010.

5. IBM Lotus iNotes:
LotusLive is a suite of business networking and collaboration cloud-based services hosted by the IBM Collaboration Solutions division of IBM. The integrated services include social networking for businesses, online meetings, file sharing, instant message, data visualization and e-mail.
LotusLive iNotes is a web-based e-mail and calendar service. It uses the messaging assets that IBM acquired from Outblaze, a Hong Kong-based online application service provider. The service provides web based email services that equip employees with real time email access from a web browser and internet connection. In addition to a web-based interface, all e-mail accounts are enabled with POP, authenticated SMTP and IMAP capabilities for use with e-mail clients such as Lotus Notes or Microsoft Outlook.

Opensource Javascript Framework : Ember.js

JavaScript – an indispensable part for developing websites and web pages, whether that is simple pages or professional website. Nowadays, JavaScript frameworks become more powerful and more specialized; they can do many things in just a few basic steps. A Javascript framework is a library of pre-written javascript controls, functions and methods that make it easier for the developer to quickly and accurately produce cross browser compliant code. Example popular frameworks are: YUI, ExtJS, Prototype, MooTools and of course, jQuery.
The massive growth in rich, JavaScript-heavy web applications has lead to a huge array of frameworks designed to help us build apps. There are so many that it can often be difficult to choose which best suits our needs. Most frameworks follow roughly what's known as an MVC pattern: model, views and controllers. Models deal with data, fetching it from databases and returning it. Views then display the data, and controllers link the models and views together.

Ember.js

Unlike the other javascript framework, Ember.js does a lot of work for us, such as code to update the view when model data changes. Ember's main features are its data binding; obejcts in Ember can bind properties to each other, so when a property changes in one object, the other is kept in sync. Another is the ability to define functions on an object that can then treat as properties.

Ember also has more traditional controllers. Views (usually written in Handlebars) provide ways of attaching certain buttons or links to Ember controller actions. Ember.js also gives us helpful tools for managing the state while developing the interactive web applications, in a way to scales the applications.

Getting Started

Below are the core concepts that one need to understand before getting started development of Ember.js app.

Templates
A template, written in the Handlebars templating language, describes the user interface of your application. In addition to plain HTML, templates can contain:
    Expressions, like {{firstName}}, which take information from controllers and models, place them into HTML, and automatically keep them updated.
   Outlets, which are placeholders for other templates. As your user moves around your app, different templates can be plugged into the outlet by the router. You can put outlets into your template using the {{outlet}} helper.
    Views, which are responsible for handling user events. You can put views into your templates using the {{view}} helper.

Views
A view is embedded inside a template and is responsible for translating primitive events (like clicks, taps, and swipes) into semantic events that have meaning to your application and are sent to the controller.
For example, a view might translate a click event into the more meaningful deleteItem event, which would be sent to the controller. If the controller does not implement the deleteItem event, the event will be sent to the current route.

Controllers
A controller is an object that stores application state. Templates are connected to controllers and translate the current state of the controller into HTML.
Controllers often act as representations of models for templates. In these cases, the controller passes the properties of the model to the template, and can transform or augment the model to present it in a way the template is expecting.

Models
A model is an object that stores persistent state. This is the data that your application operates on and what gives it value to your users. These objects are usually loaded from your server, then saved back when changes are made on the client.
Usually, you'll use Ember Data to translate the raw JSON payloads delivered by your API server into full-blown Ember.js objects with associations, computed properties, and more.

Router
The router is the object responsible for managing application state.
When your user starts your application, it will look at the URL and make sure that the right set of templates is displayed, as well as pairing those templates with the right model objects.
As you move around the different states of your application, the router automatically keeps the URL up-to-date. Users can save the URL and re-enter the application at this state later, or share the app in its current state with others.

Reference: http://emberjs.com/

Visual Studio Solution Files

Solution and project files are an essential part of working with Visual Studio. A solution is a grouping of one or more projects that work together to create an application. The project and status information pertaining to the solution are stored in two different solution files. 

Solution Files

The first file that Visual Studio creates is the ".sln" (solution) file. This is text-based file and can be placed under source code control and shared between users. This file stores information about the projects that make up this solution, source control settings, and other global settings that apply to all of the projects in the solution. The .sln file contains text-based information the environment uses to find and load the name-value parameters for the persisted data and the project VSPackages it references. When a user opens a solution, the environment cycles through the preSolution, Project, and postSolution information in the .sln file to load the solution, projects within the solution, and any persisted information attached to the solution. Each project's file contains additional information read by the environment to populate the hierarchy with that project's items.

The second file is the ".suo" (solution user options) file, which stores user settings such as the location of your breakpoints. This file is stored in binary format. As this file contains user-specific information, it cannot be placed under source code control. The solution user options (.suo) file is a structured storage, or compound, file stored in a binary format. It is a hidden file in the same path as the .sln file

TIP: The simple resolution for the error "The project file has been moved renamed or not on your computer", is to delete ".suo" file. Visual Studio will create a new one when you open the solution and save it when you close the IDE. By deleting the file, you will lose any of your user-specific settings like breakpoints.

ASP.NET MVC

ASP.Net MVC provides an alternative to Web Forms for building web applications on the .Net platform. As an alternative to Web Forms, ASP.Net MVC takes a different approach when it comes to structuring web applications. This means user won't deals with ASPX pages and controls, postbacks or view state, or complicated event lifecycles. Instead, user has to define controllers, actions, and views.

Benefits of ASP.Net MVC

• Closer to the protocol
  While ASP.Net Web Forms attempts to completely hide the stateless nature of HTTP, ASP.Net MVC doesn't. The model is also drastically simplified - gone are the complex page lifecycle events of Web Forms, and the abstractions over HTTP are minimal.
• Separation of concerns
  While ASP.Net Web Forms tightly coupltes the user interface to its code-behind, ASP.Net MVC encourages a design where the user interface (the view) is kept seperate from the code that derives it (the controller).
• Testability
  By separating applicaiton logic from the user interface, ASP.Net MVC makes it easier to test individual components in isolation. Unlike Web Forms, MVC controllers do not have a direct dependency on the infamously untestable HttpContext class and instead rely on an abstraction, which makes it far easier to write automated unit tests.

Whats new in ASP.Net MVC 3/4
MVC 3 and 4 comes with many improvements and several new features in addition to the new dependency on .Net 4. These new features include

• The Razor view engine
• Package management with NuGet
• Improved extensibility
• Global action filters
• Dynamic language features
• Partial page output caching
• Ajax improvements
• Enhancements to the validation infrastructure
• Mobile templates
• Web API