Extensible Messaging and Presence Protocol (XMPP) (formerly named Jabber) is an open, XML-based protocol originally aimed at near-real-time, extensible instant messaging (IM) and presence information (e.g., buddy lists), but now expanded into the broader realm of message-oriented middleware.[2] It was developed by the Jabber open-source community in 1999. Built to be extensible, the protocol has been extended with features such as Voice over Internet Protocol and file transfer signaling.

XMPP PROs

• Decentralization - like in email; anyone can run their own XMPP server and there is no central master server.
• Open standards - the Internet Engineering Task Force has formalized XMPP as an approved instant messaging and presence technology under the name of XMPP, and the XMPP specifications have been published as RFC 3920 and RFC 3921.
• Long History - XMPP technologies are used since 1998. Multiple implementations exist and are supported by companies like Sun Microsystems and Google.
• Security - XMPP servers may be isolated from the public XMPP network (e.g., on a company intranet), and robust security (via SASL and TLS) has been built into the core XMPP specifications.
• Flexibility - Custom functionality can be built on top of XMPP.

XMPP CONs

• Presence data overhead - XMPP currently has a large overhead in delivering presence data to multiple recipients.

• In-band binary data transfer is inefficient - Because XMPP is encoded as a single long XML document, binary data must be first base64 encoded before it can be transmitted in-band. Therefore any significant amount of binary data (e.g., file transfers) is best transmitted out-of-band, using in-band messages to coordinate.

How to Query XMPP Server

cmd>nslookup
Default Server:  XXX
Address:  8.8.8.8

> set q=SRV
> set noverbose
> _xmpp-client._tcp.gmail.com.

References

• XMPP wiki page (this article contains excerpts from it)
• XMPP Standards Foundation
  • Clients
  • Servers
  • Libraries

show tables;

Other show statements

Table creation script:

show create table %tablename%;

In an oversimplified manner, CQRS separates commands (that change the data) from the queries (that read the data). This simple decision brings along a few changes to the classical architecture with service layers along with some positive side effects and opportunities. Instead of the RPC and Request-Reply communications, messaging and Publish-Subscribe are used.

If we go deeper, Command-query Responsibility Separation is about development principles, patterns and the guidance to build enterprise solution architecture on top of them.

Such enterprise solutions aim to be:

• Scalable
• Focused on the business rather than the technology
• Can grow to handle complex problems without growing development costs
• Adapt to changing business requirements
• Efficiently integrate with other software and systems
• Benefit from the cloud computing
• Inherently handle multiple users

While going for these goals, CQRS attempts to solve problems of:

• Performance bottlenecks and scalability
• Concurrency conflicts, their resolution and prevention
• Data staleness
• Complexity of the design, development and maintenance

Related links:

• CQRS introductory video.
• Clarified CQRS paper by Udi Dahan.
• DevTeach Video
• DDDD, CQRS and Other Enterprise Development Buzz-words

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Related Links:

• defined parameters and return arguments;
• calling conventions;
• usage limitations.

For example, here's how a piece of Twitter REST API looks like:

• Twitter REST API Method: statuses update
• URL: http://twitter.com/statuses/update.format
• Formats: xml, json, rss, atom
• HTTP Method(s): POST
• Requires Authentication: true
• API rate limited: false
• Parameters: ...
• Response: ...

There are a few categorizations of APIs in the software development world.

Web APIs define interfaces for interacting with various web sites and services in the Internet. These APIs usually use Hypertext Transfer Protocol (HTTP) requests for passing around data represented in JavaScript Object Notation (JSON) or Extensible Markup Language (XML) formats.

Twitter REST API, mentioned above, is an example of such Web API.

Operating System APIs represent low-level methods exposed by the operating system (OS) that could be used by software applications to integrate with it. Windows API (or Win32) and POSIX definitions are among the most known examples.

Software APIs are usually exposed by software vendors willing to provide integration capabilities for their products.

Here's the simplest example of Virtual Machine - Windows 7 running Windows XP in a VM to provide backwards compatibility for the older applications:

Here's another example - Sun VirtualBox running Ubuntu x64 server within Windows 7:

These were the examples of Operating System Virtual Machines. Another type of VM is Application Virtual Machine, that runs applications and scripts in an isolated virtual environment. Examples of that would be Java VM or .NET Framework VM.

VMs and Software Development

Virtual Machines are getting very important and widely used these days. This happens due to the improvements in hardware and virtualization capabilities along with the numerous benefits offered by the technology.

Some of usage scenarios include:

• Quality Assurance teams get the ability to test applications, their deployments and upgrades more efficiently. Testers don't need to have multiple OS and installation configurations available any more. A set of VM files (that are easy to share) is a replacement for that.

  Additionally, it is quite easy to configure continuous integration to run actual integration tests within differet virtual machines (emulating various OS and setup configurations), thus providing a better code coverage and issue detection.

• Software Developers could try out latest changes and various multi-server deployment configurations within virtual development environments.

• Cloud service providers could sell finely-grained computing capacities to customers in form of the VM slices. Customer is able to configure his Virtual Machine any way he wants.

  Should they want to change hosting provider, they just need to move a single VM from one environment to another.

• For complex enterprise applications (spawning multiple machines and server roles) virtual machines provide high-level separation of concerns, simplifying software evolution and maintenance.

• It is really easy to launch multiple virtual machine clones from one VM file. This simplifies scaling and cloud bursting scenarios for organizations.

Related links:

• Virtual Machine on Wikipedia
• Development server meets virtualization
• Configuring Virtual Development Environment

Simply put, Agile Software Development is a group of software development methodologies that work quite well when:

• projects are not mission-critical;
• business requirements change extremely fast;
• there are great developers available;
• development teams are small;
• development culture and mentality favors self-organization and self-learning.

In other words, Agile works quite well in situations when some unique software project has to be delivered really fast in order to seize the market opportunity. This works because Agile software methodologies allow development teams to adapt quickly to the rapidly changing business requirements. This happens because of:

• short development iterations allowing to start getting feedback early in the project's life-cycle and incorporate it into the product fast by delivering working software repeatedly and in a timely manner;
• continuous integration helping to reduce development friction and improve quality of a rapidly developing project in self-organizing environment;
• feature-driven development focusing development on delivering features (functionality) bringing real business value to the client (and the project);
• lean software development laying out common principles for efficient software development process;
• eXtreme Programming pushing lightweight software development methodologies to the extreme.

Long-term planning (along with some other formalities of a totally controlled project management process) is mostly sacrificed in favor of the flexibility, fast delivery and self-organization. In such a situation we still have to maintain high quality of the project deliverables (while reducing the resource consumption). This is achieved with the help from:

• test-driven development - provides foundation for the Continuous Integration and facilitates change while maintaining stability of the software project;
• pair programming - improves code quality and allows to have more efficient knowledge sharing.

Related Links:

• Agile Software Development on Wikipedia
• Lean Software Development on Wikipedia
• Scrum on Wikipedia
• Planning poker on Wikipedia
• eXtreme Programming on ExtremeProgramming.com

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Here's how it works.

Any program could be logically separated into distinct units (in object-oriented programming the smallest unit usually being a class). Developers, while coding these program units, also create tests for them (code blocks containing some assertions and expectations about units). These tests could be used to rapidly verify behavior of the code being tested.

When some other developer introduces new units or changes something in existing units, he can run all the tests available for the program and verify that everything is still operating as expected. Usually running unit tests is a fast operation (less than 30 seconds), so developers are encouraged to do that often.

Here's how unit test suite looks for the Lokad Shared Libraries project (running all 176 tests for the primary assembly takes just 3 seconds):

If unit tests indicate that something has gone wrong, then the root of these problems could be detected rather quickly (since failing tests point directly to the misbehaving unit).

Unit Testing is extremely important for software development, since delivering projects efficiently without unit testing is nearly impossible. There are software development practices depending on unit testing:

• Test-Driven Development (TDD) - software design method requiring developers to write tests before writing code (this may sound strange, but it works)
• Continuous Integration - software development practice that allows to isolate some bugs in time by automatically running unit tests after each change to the code.

There are some additional benefits of unit testing:

• it facilitates change - developers are encouraged to refactor and change code, since they have a way to rapidly verify that program units still behave as expected.
• a good unit test is living documentation for the code, since it describes how the code is expected to behave;
• unit test is a good way to communicate over issues in the code and distribute work between multiple developers.

It is important to keep in mind, that unit tests only facilitate change by testing individual code units. They do not guarantee that the entire program will be free from bugs.

Here's the simplest unit test in C#, using NUnit framework:

[TestFixture]
public class CalculatorTests
{

  [Test, ExpectedException(typeof(DivideByZeroException))]
  public void Divide_by_zero_should_throw_exception()
  {
    new Calculator().Divide(1, 0);
  }

  [Test]
  public void Adding_actually_works()
  {
    var result = new Calculator().Add(1, 15);
    Assert.AreEqual(16, result);
  }
}

As you can see, a unit test is simply a class that contains methods checking behavior of some Calculator class. This test class is sometimes also called test fixture or test suite. In this snippet above test methods are decorated with a special attributes that are used by NUnit framework to recognize them, run as needed (i.e.: within an automated build) and print results.

Although this unit test suite may look extremely simple, it does not have to stop there. Here are some advanced usage scenarios that simplify development of complex enterprise applications:

• setup a temporary database before unit tests start up and then check all data access routines against this sample database;
• have a test suite that executes every hour against methods in your web services, verifying that they are alive and processing data properly.
• use non-deterministic reproducible tests that verify behavior of your class in various unexpected situations, reporting back when something goes wrong;
• use unit testing framework to write code quality tests, that check and enforce some guidelines (i.e.: every controller class should be immutable and have name ending with Controller).

Related Links:

• Continuous Integration
• Test-Driven Development
• Using Lokad Rules to Simplify .NET Unit Tests
• How to Use SystemUtil to Write .NET Code With Testable Sleep and Time Calls
• Shortcuts for NUnit Exception Expectations
• Unit Testing on Wikipedia

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

The simplest usage of versioning is - you can easily go back to the previous working version of your files, should you mess something up with the latest changes.

Changes could range from fixing a typo in a text file up to a huge refactoring in a software project, spanning hundreds of files. Each change usually has name of the person introduced it, time of the change and an optional description message.

Version Control Systems became an essential part of software development due to the following benefits:

• collaboration - a team of developers (which could be distributed geographically) may be working on the same set of files at once without interrupting each other's work;
• change management - changes can be inspected, reviewed or rolled back as needed; if you need that App.config file the way it was on May 17, 2008 - no problem;
• tracking ownership - every change is associated with the name of the person, so we know whom to give kudos to or ask questions;
• tracking evolution - every change is associated with a short description, so you just need to pull a change log of some class to see how it evolved and who did what;
• branching - it is possible to create a copy (branch) of the entire project for some specific purpose (i.e.: prototyping or developing a fix for the important customer) without disrupting development workflow;
• continuous integration - ability to split evolution of a software project into incremental changes allows to run all sorts of checks and tests against each incremental change in a continuous manner.

Language

Common terms:

• Repository - database server that contains all files and their history.
• Working copy - local version of files on somebody's machine. It may contain local unversioned changes.
• Trunk - home folder for some project within the repository. It usually contains all the latest changes.
• History (or ChangeLog) - a list of changes that were done to a file or folder since it was created.
• Latest (or Head) - latest available version of some file or folder.
• Revision - another word that means current version of file or folder.

Common operations:

• Check out - first operation required to work with any repository. It involves creating working copy that mirrors some folder on the server (usually that's trunk).
• Commit (or Check In) - sending your local changes back to the server, so that other people can get them as well.
• Update - updating local working copy to have all the lasted changes that were committed to the server since the last time you've checked it.
• Revert - discard all your local changes to the working copy.
• Diff (or Change, Delta) - differences between two versions of the same file; or an operation involving actually looking up what was changed between two versions.
• Create patch - automatically create a file that describes all the changes that were done to the working copy (basically containing all diffs). Then these changes could be reviewed by somebody else and committed to the repository.

Advanced operations:

• Conflict - that happens when somebody else changed the file, while you were working on it locally.
• Resolve - to fix contradicting changes by reviewing and manually merging them (VCSs can automatically resolve majority of the conflicts).
• Tag - to place a human readable label on some revision (i.e.: when releasing a product); or a noun representing such a label.
• Branch - to start a separate line of development over some old revision (i.e.: when fixing bugs for the previously released version).
• Merge - bringing together changes from different sources (i.e.: when applying a bug fix from some branch to a trunk).

How it looks

Here's how usage of Version Control Systems looks like.

Checking out the trunk of Autofac IoC project:

Browsing through the revision history:

Looking at some revision in detail:

These screen-shots show TortoiseSVN, which is a widely-used open source software for accessing Subversion repositories. Here's the bigger picture featuring some popular Version Control Systems:

• Subversion - cross-platform open source VCS with great User Interface implementations (TortoiseSVN is the most known implementation for Windows shell integration).
• Git - open-source VCS for distributed development that does not require a central server, yet lacks a convenient UI.
• Mercurial - yet another distributed open source version control system which is less popular than Git (5 times less popular, if you trust Google).

Related Links:

• Continuous Integration
• Version Control System on Wikipedia

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Once the produced code passes unit tests, it could be refactored and cleaned up. Developer will be able to ensure code staying stable in the process, by running unit tests frequently. Next iteration could be started afterwards.

Writing a test before the actual code and its refactoring helps to achieve higher quality, because:

• it forces developer to refine code contracts before working on the implementation;
• it forces developer to make and keep code easily testable. This requires loose coupling and a separation of cross-cutting concerns;
• presence of unit tests gives developers more psychological freedom to experiment with the code and refactor it; managers get lower risks related to introducing high-level changes to the project.

There are some limitations of the TDD:

• badly written or simply brittle tests can create a tremendous maintenance overhead and hinder any code evolution;
• complete code coverage by unit tests creates a false perception of security and may result in less QA than needed;
• unit tests written by the same developer tend to have similar blind spots that may actually require testing.

Unit Test Code Coverage

One of the most important metrics in the Test-Driven Development is unit test code coverage. It could be calculated automatically and indicates percentage of the code that is executed while unit tests are running.

Although code coverage does not indicate quality of the unit tests, it is still a good measure of code testability. It is a common practice to set a certain code coverage threshold (i.e.: 80%) and enforce it within the continuous integration scripts. This way, if a developer commits a significant amount of code without unit tests, this is likely to break the build, forcing him to concentrate on testing his code.

Test-Driven Development plays well along with Component-Driven Development, since both of these approaches favor doing design before the actual implementation.

Related links:

• Unit Testing
• Test-Driven Development on Wikipedia
• Testing MVC Controllers with Mock Containers
• Using Lokad Rules to Simplify .NET Unit Tests
• How to Use SystemUtil to Write .NET Code With Testable Sleep and Time Calls
• Shortcuts for NUnit Exception Expectations
• How to ensure that complex methods are covered with tests
• Writing .NET code analysis rules as unit tests

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

• Services are provided on-demand; customers can pay for them as they go, without the need to invest into a datacenter.
• Hardware management is abstracted from the customers.
• Infrastructure capacities are elastic and can easily scale up and down.

There is a powerful economic force behind this simple model: providing and consuming cloud computing services generally allows to have far more efficient resource utilization, compared to self-hosting and data center type of hosting.

This is especially true for bursting into cloud scenarios when cloud consumers use elasticity of the cloud services to handle any spikes they might get. More information is available in article Why is cloud computing important for us?.

Obviously, consuming raw hardware capacities may be too hardcore for some consumers that merely want to have a scalable storage. So it is natural that cloud computing services already got some diversity around them:

• Infrastructure as a Service (IaaS), where customer gets raw hardware resources (i.e.: virtual machines with OS of choice). Examples:

  • Amazon Elastic Compute Cloud - part of AWS that offers scalable Xen-based virtual machines.
  • Mosso - .NET or LAMP web sites, Storage and Linux-based virtual servers. People complain.

• Platform as a Service (PaaS), where service provider builds a platform to simplify solving some technological tasks. This simplifies life for the customer, but also comes with a lock-down cost. Some providers:

  • Microsoft Windows Azure - .NET driven and Microsoft-owned cloud infrastructure, which is behind Amazon in some areas.
  • Amazon Web Services - collection of scalable infrastructure pieces for building your cloud application.
  • Google App Engine - Python-based cloud framework.
  • Amazon Elastic Map Reduce - Apache Hadoop hosted on Amazon cloud services (EC2 and S3)

• Software as a Service (SaaS). At this level everything is way more simple for the customers to consume, since they are provided with actual services generating business value to them. Service providers handle all the technological complexity and provide the support as needed.

From the development perspective, cloud computing is a brand new field (which is especially true for the .NET world). So there are no established patterns and pactices in the field yet. However, common development guidelines tend to work quite well:

• Component-Driven Development with Inversion of Control Containers
• Test-Driven Development
• Continuous Integration for the projects
• Separation of Cross-Cutting Concerns

Related links:

• Cloud Computing article series
• Why is Cloud Computing important for us?
• Cloud computing: a personal review about Azure, Amazon, Google Engine, VMWare and the others by Joannes Vermorel
• Cloud Computing on Wikipedia

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.