Int this and after this following post I would try to make you able to create your first project in Ruby on Rails. I will cover this topic from scratch. I hope you will find this useful.

So, here wo go.

To understand ROR we should first know what is Ruby?

Ruby is an open-source, multi-paradigm, interpreted programming language

Open Source
We called any product an open source when the code of that product is available for free. We can use it, modify it, and reuse it for their purposes and the improvement of that product. The benefit of open source is chiefly that you get a lot more minds working on a project than a proprietary project.

Multi-Paradigm
Ruby is a multi-paradigm language because it doesn’t constrain to a single programming mindset; you can use any of the aforementioned programming (OO, procedural etc…) paradigms with no problems in Ruby.

Interpreted
If you’ve used something like Assembly, Pascal, Fortran, or C/C++, you’ve used a compiled language. “Compiled” means that you’ve had to run your code through a little compiler and it spits out some sort of native code that will run without any sort of interpretation by the computer other than by the operating system itself. This can become time consuming as your project grows larger and larger, and sometimes can even be a severe hindrance to productivity. But on the other hand, Ruby is an interpreted language, which means that there is an interpreter that reads your code and then emits native code to the operating system.

Ruby on Rails is a framework that makes it easier to develop, deploy, and maintain web apps.

All Rails applications are implemented using the Model-View-Controller (MVC) architecture. Java developers are used to frameworks such as Tapestry and Struts, which are based on MVC. Rails applications are written in Ruby, a modern, object-oriented scripting language. Rails take Ruby to the limit, extending it in novel ways which make a programmer’s life easier. This makes our programs shorter and more readable.

The design of Rails was driven by a couple of key concepts: DRY and convention over configuration. DRY stands for Don’t Repeat Yourself—every piece of knowledge in a system should be expressed in just one place, A place often suggested by the conventions of the MVC architecture—and then move on.

Convention over configuration is crucial, too. It means that Rails has sensible defaults for just about every aspect of knitting together your application. Follow the conventions and you can write a Rails application using less code than a typical Java web application uses in XML configuration.Back in 1979, Trygve Reenskaug came up with a new architecture for developing interactive applications. In his design, applications were broken into three types of components: models, views, and controllers.

Model:The model is responsible for maintaining the state of the application. Sometimes this state is transient, lasting for just a couple of interactions with the user. Sometimes the state is permanent and will be stored outside the application, often in a database. A model is more than just data; it enforces all the business rules that apply to that data. For example, if a discount shouldn’t be applied to orders of less than $20, the model will enforce the constraint. This makes sense; by putting the implementation of these business rules in the model, we make sure that nothing else in the application can make our data invalid. The model acts as both a gatekeeper and a data store.

View:The view is responsible for generating a user interface, normally based on data in the model. For example, an online store will have a list of products to be displayed on a catalog screen. This list will be accessible via the model, but it will be a view that accesses the list from the model and formats it for the end user. Although the view may present the user with various ways of inputting data, the view itself never handles incoming data. The view’s work is done once the data is displayed. There may well be many views that access the same model data, often for different purposes. In the online store, there’ll be a view that displays product information on a catalog page and another set of views used by administrators to add and edit products.

Controller:Controllers orchestrate the application. Controllers receive events from the outside world (normally user input), interact with the model, and display an appropriate view to the user. This triumvirate: the model, view, and controller-forms an architecture known as MVC. Figure below shows MVC in abstract terms.

Summery:
In this post you seen that what is Ruby and Rails. Basic concepts of Rails and MVC architecture. In next post I will tell you Active Recored, OR Mapping , Action View and Controllers in detail. Thank you for your intrest.

10 Reasons for IT Project Failure

In an IT industry a people are angaged more in Project planning and analysis of of the requirements in early stages of a project. Apart of that IT projects fail often. The simple reason which generally comes out of a failure project is the technology. But in most of the cases it is not the technology. At the core of a failure project it is the project management is all over.

According to Jeff Monteforte, owner of Exential, an independent project management consultancy in Cleveland, Ohio and Mimi Ho, Robert Francis Group analyst - The Top 3 problems are lack of executive support; changes to project scope and the lack of change management; and failure to establish user expectations which leads all to often to unrealistic deadlines.

followinf are the 10 most common pitfalls to successful project completion according to Ms.Ho:

1. Undefined or poorly defined project requirements
Project managers should collaborate directly with key project stakeholders to define specific detailed project requirements and deliverables. Defining specific project requirements is necessary to maintain alignment of project tasks to desired business outputs, as well as to ensure that projects have clear and specific project objectives established.

While this step may seem obvious, many companies will skip this stage and go right to solutions to jump start a project. Business and/or IT executives assume the requirements (such as controls, dashboards, data, dependencies, functionality, integration, metrics, outputs, and workflow) are met without performing any confirming analysis.

These projects tend to fail and the companies usually encounter over spending, project restarts, rework, and/or unmet expectations.

2. Lack of project planning
Once the requirements are known, then conducting thorough, upfront project scope planning is an essential next step to help project managers and stakeholders accurately and clearly define project scope.

It is important for people to understand that there is more than one way to achieve the requirements and that scope and cost vary by approach. Project scope management is therefore necessary to develop reasonable project estimates, enhance the management of customer and stakeholder expectations, and mitigate project risks such as cost overruns and schedule delays.

Project managers should establish and standardize a scope management process to develop concise project scope statements and credible budget and schedule estimates.

3. Lack of or poorly developed budget forecast
Thorough research and preparation is necessary to develop a reasonable budget estimate. Many companies will skip this step or just do a very rudimentary estimate due to the amount of work needed to complete the task.

Some companies that do not maintain internal archives of project costs turn to external consultancies to acquire external spending/budget information on companies that have completed similar projects in a similar market.

Using the estimated budget, project managers should collaborate with stakeholders to help further refine the project scope and final deliverables. Project managers should use their initial budget to base actual spending plans as well as to proactively track spending and respond quickly to potential issues to prevent shortfalls in the budget.

4. Lack of stakeholder involvement
Project managers should ensure that primary project stakeholders are involved with the project from the beginning and throughout the entire project. This is crucial to ensure that visions are properly communicated, defined, and verified.

It is very common for project efforts to be delegated to staff that do not have sufficient knowledge or understanding of the desired effort. As a result, projects are defined incorrectly and the projects delivered do not meet the expectations of key stakeholders.

5. Lack of executive support
An IT project can be highly political and may end up involving an excessive number of unnecessary or incorrect participants. IT executives should seek ongoing senior management endorsement and enforcement of the planning process to keep the effort on track and to minimize pushback from line of business (LOB) managers.

Support from senior management and staff involvement are both needed to drive and keep the effort focused and moving. Ownership of the project must be shared to satisfy the demands of user management. IT executives must convey this message to senior management to retain involvement and participation.

6. Frequent or large changes to project scope
Scope changes can significantly impact the cost, schedule, risks and quality of the entire effort. Project managers should watch out for early and frequent changes to the project scope.

While scope is defined early in the planning and estimation phases, there are valid reasons for change. For example, a stakeholder may acquire additional insight into a problem during the course of the project or external market conditions and/or government regulations can drive requests that extend beyond the initial project scope. However, changes to project scope can also occur as a result of developing a poor initial scope document.

Project managers must ensure that adequate time is spent on defining and refining the work effort directly with key stakeholders.

7. Lack of change management process
Project changes will occur. However, uncontrolled changes and insufficient change management processes will increase the probability of project failure. A formal and structured change management process is necessary to ensure effects of any changed requirements are properly analyzed, prioritized, and balanced according to the project's budget, schedule, and scope.

Project managers should consistently and publicly take a phased approach to projects, so that users understand that not all changes must be completed for the current release. This will help acceptance of trading off specific desired changes for faster availability of greater functionality. This will also help reduce the impact of change onto the project, and allow for cost and time
containment.

8. Failure to establish appropriate client/user expectations

Disputes often occur as a result of mismatched expectations. Missed project targets will cause delays, rework, and additional project spending. Setting user expectations is necessary to establish a baseline of what and what not to expect from the final deliverable.

Project managers should work with key stakeholders in establishing and prioritizing project requirements as well as reviewing budgets and schedules. Additionally, all people involved in the project effort should have periodic joint sessions, to ensure the same communications on project expectations are received by everyone.

This process helps keep users involved and abreast of the project's status, as well as minimizing the potential for misunderstanding of project expectations between stakeholders.

9. Unrealistic deadlines
Stakeholders want their projects completed now. In some harsh environments, they may question IT's commitment and effort. IT executives and project managers must work with stakeholders to help them understand what is possible with the level of incumbent IT resources.
Project managers should collaborate with key stakeholders in defining reasonable project schedules and deadlines to ensure that business conditions and requirements are met and better manage expectation levels.

Project managers will need to ensure that project cost, scope, and time are optimally balanced to achieve the desired deliverables and the desired time. Effective planning and monitoring are necessary to help develop a strong start for the project. However, project managers must remain aware and anticipate change as re-planning is necessary throughout the project.

10. Insufficient resources
Required resources are often underestimated and scheduled inaccurately. Companies often encounter problems with resource allocation, as many companies to do not spend sufficient time on resource scheduling and proper management.

In fact, it is very common for companies to overestimate the on-boarding of staff to a project, which immediately causes the project to be late and in trouble, impairing IT's image with LOB managers and executives. In addition, resources are often utilized ineffectively, especially when individuals are required to support multiple projects concurrently. Insufficient resource supply
will cause delays and impact overlapping projects.

Project managers should plan according to the established project schedule estimates and work with concurrent project schedules to help ensure that resources are properly scheduled.

Note: This article originally appeared on CIOUpdate.com

SOA & WOA

Service Oriented Architecture

It is an architectural design pattern that concerns itself with defining loosely-coupled relationships between producers and consumers.t is an architecture that relies on service-orientation as its fundamental design principle. In an SOA environment independent services can be accessed without knowledge of their underlying platform implementation. These concepts can be applied to business, software and other types of producer/consumer systems.

Every business comprises core and non-core functions. The core functionality doesn't change very frequently and the non-core changes very frequently. For example, the retail store will always sell goods and this will be one of the core functions, but the way it will sell the goods might differ with time and market needs, etc. These are the non-core functions which change very frequently.

In the software industry, it is very much desirable that the functions which changes frequently should be decoupled by the functions that changes frequenly. So, SOA will be a segregation of the core business functions into independent services that don't change frequently.

Service-oriented architecture (SOA) is an architectural style where existing or new functionalities are grouped into atomic services. These services communicate with each other by passing data from one service to another, or by coordinating an activity between one or more services.

SOA through Web Services

SOA can be acheived through Web Services. The major objective of a web service is to create a functional unit available from outside the system or from internet via standard internet protocol. There are three major roles that SOA building block can play:

Service Provider

Service provider is who is actually providing the service. The system which wants to be accessible from outside over internet.

Service Broker
The service broker, also known as service registry, is responsible for making the Web service interface and implementation access
information available to any potential service requestor.

Service requestor
The service requestor or Web service client locates entries in the broker registry using various find operations and then binds to the
service provider in order to invoke one of its Web services.

Web Oriented Architecture

WOA is a Web Service style of implementing SOA but the focus is on the REST,an increasingly popular, powerful, and simple method of leveraging HTTP as a Web service in its own right.

It is very clear that WOA is nothing but a SOA implementation using REST. That means people who are doing WOA is doing SOA.

WOA term is coined by Nicholas Gall and according to him : " WOA is an architectural style that is a substyle of SOA based on the architecture of the WWW with the following additional constraints: globally linked, decentralized, and uniform intermediary processing of application state via self-describing messages or In short WOA = SOA + WWW + REST ".

Since WOA is a substyle of SOA (ie it imposes additional constraints above and beyond those imposed by SOA), you may be interested in Nicholas definition of SOA:

" An architectural style in which certain discrete functions are packaged into modular, shareable, distributable elements ("services"), which can be invoked by consumers in a loosely coupled manner or in short SOA = modular + distributable + sharable + loosely coupled. "

The End of Tier-Based Computing - SBA

Today in the technology space new ways (SOA/Grid Computing) are emerging to create linearly-scalable systems at lower cost. But these architectural ways are not aligned with the existing tier bases application model, which by definition central and static.

SBA (Space-Based Architecture) is the new approach to transforming existing tier based applications into linearly and dynamically scalable services.

SBA represents a new model that combines and integrates distributed caching (“Data Grid”), contentbased distributed messaging (“Messaging Grid”) and parallel processing (“Processing Grid”) into a powerful new computing paradigm.

These new middleware components are implemented on top of a distributed shared memory space that provides a common platform for clustering, high availability, location transparency and consistency services across all tiers.

The power of spaces comes from not having to separate various parts of an application into discrete physical runtimes — and then wiring those together in complex, hard-to-scale, and performanceconsuming tangles of middleware. A space doesn’t care if an application has been “tiered.” Whether it has or not, the same program code will instantiate multiple times on the same machine or on multiple machines automatically — and even dynamically - in response to runtime parameters like CPU utilization.

Instances communicate through the space, just as if they were talking to middleware. In fact, they can use the same middleware APIs they always have — except now the middleware’s role has become virtualized, meaning that all physical message and data exchanges are handled transparently by the space.

Why We Need it:

Today the environment and and requirement for the distributed applications are changing. Processing the high volume of information at fast rate and low cost is not possible by adjusting the existing architectures to the requirements. Most of the architectures are based on the assumptions of the network capacity and and the memory available which are not true for the current scenario.

Due to large scale, low cost memory resources and new networking technologies like infiniband calls the change in the current middleware components to leverage these changes and enable applications to exploit the potential of previously unavailable resources to address the growing business need.

SBA

SBA is based on the Tuple Space model.The tuple space represents a logical shared address space via which distributed applications share information, coordinate actions (workflow) and deliver messages using a very simple set of APIs for manipulating objects in shared memory. In late 90s, Sun Microsystems introduced a specification named JavaSpaces™, which is an object-oriented implementation of the Tuple Space model.

SBA is a logical architecture that combines the different patterns mentioned above - caching,
messaging and parallel processing - for building high- performance, stateful SOA applications. SBA is aimed at providing a broader conceptual architecture and is not restricted to the JavaSpaces API.

Components of SBA

An application built on the principles of space-based architecture typically has the following components:

• Processing Unit – the unit of scalability and fail-over. Normally, a processing unit is built out of a Plain Old Java Object container (POJO)
  

• Virtual Middleware – a common runtime and clustering model, used across the entire middleware stack. The core middleware components in a typical SBA architecture are:

Messaging Grid:
Handles the flow of incoming transaction as well as the communication between services

Data Grid
Manages the data in distributed memory with options for synchronizing that data with an underlying database

Processing Grid
Parallel processing component based on the master/worker pattern that enables parallel processing of events among different services

• POJO-Driven Services Model – A lightweight services model that can take any standard Java implementation and turn it into a loosely coupled distributed service. The model is ideal for interaction with services that run within the same processing-unit.

• SLA-Driven Container – The SLA-driven container enables the deployment of the application on a dynamic pool of machines based on Service Level Agreements. SLA definitions include the number of instances that need to run in order to comply with the application scaling and fail-over policies, as well as other policies.

Architechtural Mistakes

In the Software industry the most critical task is to create a design an application or a solution for a problem. This design or solution ensures that the application will will run under the most of the known circumstances for an software application. It also ensures that system will provide requires functionality, availability, security and performance for its stack holders.

Eoin Woods, one of the IASA Fellows posted an article about the top ten software architecture mistakes - mistakes that are too often. Brief excerpts of the ten points are below:

1. Scoping Woes. "This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality...It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation?"
2. Not Casting Your Net Widely. "A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention."
3. Just Focusing on Functions. "…unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful."
4. Box and Line Descriptions. "There are two reasons why the [single, all inclusive] huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean."
5. Forgetting That It Needs to be Built. "Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working."
6. Lack of Platform Precision."…its no longer sufficient to simply say that you “need Unix and Oracle” when specifying your platform. You need to be really precise about the specific versions and configurations of each part in order to ensure that you get what you need. This will allow you to avoid the situation where you can’t deploy your system because someone has helpfully upgraded a library for one part of the platform without realising that it means that something else will no longer work."
7. Making Performance and Scalability Assumptions. "Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming. This will all help to increase confidence that there aren’t any performance and scalability demons lurking in your design."
8. DIY Security. "A mistake made in many systems over the years has been to try to add security into the system using “home brew” security technology. Be it custom encryption algorithms, a developer’s own auditing system or an entire DIY access control system, locally developed security solutions are rarely a good idea. While most of us think we could probably whip up a clever piece of security technology in no time, we’re usually wrong."
9. No Disaster Recovery. "The key to getting resources to implement a DR mechanism for your system is to be specific and quantify the cost of system unavailability in a number of realistic scenarios. If you can also estimate the probability of the scenarios occurring then you can use these two figures to convince people that DR is important and to justify a certain level of budget to implement it."
10. No Backout Plan. "Make sure that whatever happens during the deployment of your system or upgrade that you have a documented, reviewed and agreed backout plan to allow you to restore the environment to its state before you started deployment."

Eoin Woods is a software and enterprise architect at UBS Investment Bank.