Designing Cloud Based Systems – 3. Scalability, Performance and Software Engineering
By Abhijat Vatsyayan (5) on February 3rd, 2010

Scalability and robustness

Since a very compelling business reason for using cloud computing is the ability to scale on demand and when needed, using the best practices and guidelines for designing large scale  distributed systems is a good starting point. While academia has a preference for   distributed transactions, ACID properties, and all kinds of consensus protocols, you are better off with loosely coupled systems where nodes will eventually reach a consistent state (as opposed to waiting for all nodes in a very large system to  reach a consistent state before proceeding). Considering the state of existing systems, loosely coupled self healing self regulating systems should be preferred over system with exotic distributed transactional properties and consensus protocols. Continued »

Designing Cloud Based Systems – 2. System Integration and Development Considerations
By Abhijat Vatsyayan (5) on January 22nd, 2010

Enterprise Application Integration

You need to consider how your system integrates with other systems in your organization. Clouds are good but one-off systems that use cloud but do not integrate with existing systems will diminish the payoffs of using a cloud.

You need to consider how your system and its data get integrated with existing data. This may need to be done both ways. Without access to existing data or data created and maintained by your cloud based system, you will again limit the potential of your system under design. Continued »

Designing Cloud Based Systems – 1. Introduction
By Abhijat Vatsyayan (5) on December 23rd, 2009

Definitions and architecture

I am not a big fan of using definitions as a starting point.  In technology many useful and successful concepts have escaped definition. People still argue about what exactly is an object in an object-oriented system.  There is no scarcity of definitions for software architecture. The internet cannot be pinned down to a simple definition. A definition, however, it is still useful in certain contexts. Continued »

.NET Reflection: The untouchable? No, not at all.
By Vikas Burman (1) on October 18th, 2009

I am a big fan of .NET reflection. However most often you will hear more of critics than praise. The biggest of all “It’s slow.” Web is full of cautions and warnings telling you not to use it. Some will go as far as saying that if you care for performance, do not even think about using reflection. If you go on and read beyond the highlight points, you will realize that a large percentage of these warnings and cautions are discussing a particular scenario where some developer failed to get what s/he was trying to achieve. And while being judgmental with the experiment a generalized statement like this comes up as an end result. Continued »

Cloud Computing Series: Exploring the Google App Engine Java Runtime Environment
By Ram Kripal Prasad (3) on September 23rd, 2009

Various Cloud FormationsGoogle recently released a Java runtime environment for their App Engine platform. As a software development organization, this offering is of special interest to Nagarro, as it offers several advantages over competing cloud hosting environments. Hosting a Java application on Google’s infrastructure provides automatic scaling and load balancing, a feature that is of interest to a number of our software product development ISV customers. To better understand the issues and risks, we conducted an internal exercise to assess the technical effort required to port an existing application to the Google App Engine for Java (GAE-J). Continued »

Google Web Toolkit for Rich Internet Applications –A Java Programmer’s Experience
By Nitin Sood (1) on May 14th, 2009

Recently, I have been working on porting a Struts and uPortal based legacy application to GWT. This work was initiated a year ago to replace an unappealing, non-responsive and slow user interface of the legacy application. Another key requirement was to make the client side technology stack lighter. Use of multiple client side technologies (Struts, uPortal, JSP, Tag libraries, Java Script, configuration files, CSS, XSLT) made it difficult to make even simple UI changes. Continued »

Application programming in the era of multicore processors
By Abhijat Vatsyayan (5) on April 15th, 2009

Computer chip manufacturers cannot keep on increasing the clock speed indefinitely to make their processors faster. They seem to have already reached the limit (on clock speed) and have started putting multiple Continued »

Ruby vs. Java
By Bill Kayser (9) on February 4th, 2009

It’s not that we don’t have enough people offering opinions on what is a better language.  It’s just that some of us never tire of discussing it.  There are so many perspectives, so many arguments, and so many people willing to   Continued »

The Usability of Programs, Part 2 of 2
By Bill Kayser (9) on October 22nd, 2007

Here are some other principles of UI design that apply to program design:

Reduce Cognitive Load. This guideline in UI design is about minimizing the amount of things a user has to know in order to be able to use a tool effectively. Likewise, a programmer shouldn’t have to subclass five different classes just to effect one small change to an application. For instance, I often find that in order to add a new behavior interactive application I may have to learn the logging framework, the undo/redo mechanism, the localization framework, and the validation framework–on top of whatever complicated hierarchies exist in the model and views. Things usually reach this state when developers anticipating future needs and striving for reusability and generality in their frameworks end up sacrificing simplicity and, ultimately, usability.

Continued »

The Usability of Code, Part 1 of 2
By Bill Kayser (9) on October 12th, 2007

Not long ago Ken Arnold wrote an article for Queue magazine called Programmers are People Too. In it he talks about applying the principles of User Interface Design to the design of APIs. It turns out the practices of Human Factors and Usability Engineering have a lot to offer the implementors of public APIs and frameworks. Think of an API as the “user interface” of a larger programming model. Users are application programmers and the usability of the API is judged not just by it’s richness, but on the ease of use and learnability of the API. It’s not sufficient to address usability with thorough documentation any more than it’s sufficient to compensate for a bewilderingly difficult user interface to a mobile phone with a five pound user manual.

Continued »

Programmers as Channel Surfers
By Bill Kayser (9) on October 2nd, 2007

If a program is to be a work of literature, then where does that leave object-oriented programs? In the era of functional decomposition, programs were built around algorithms and data structures. They executed in a single thread as a sequence of steps and subroutine calls, not unlike a story. Our object-oriented programs, on the other hand, don’t have such a fixed path of execution. Whether server or client applications, they start up multiple threads and make heavy use of message passing and asynchronicity. The essence of a program is not in a sequence of steps and subroutine calls but in the subtle relationships between classes spread across many frameworks and subsystems, relationships such as inheritance, aggregation and collaboration. So how does one read a Java application like a story? The whole idea of object oriented programs seems at odds with literate programming.

Continued »

The Literacy of Programs
By Bill Kayser (9) on September 30th, 2007

Bill1

What is the purpose of a computer program?

Your colleagues and you all write software.  You generate software prose on a daily basis, crafting these artifacts called programs, line by line.  You utilize a common language that you all agree upon, a language which bears scant resemblance to a spoken language.  So what is it that you are creating?  What is the purpose of these lines of code?

You might say a program elaborates how a computer is to execute an algorithm.  It describes what the system should do and how to do it.  As programmers, we are the narrators and the computer is our audience.  That’s basically what we were taught in our very first computer class.

Continued »