Agile methods are often described as “common sense”. For this reason Ken Schwaber refuses being titled the Co-Creator of Scrum. Several software development practitioners such as Ivar Jacobson, Grady Booch, and James Rumbaugh all contributed to the set of principles that today form the Scrum framework.

However, having Scrum, XP, or any other method classified as common sense leaves a lot of room for interpretation by the individuals applying them. Thus, iteration planning efforts sometimes end up being superficial, not entirely committed to the system actors’ real goals. As a practical consequence, user stories are found reduced to single sentences hanging on the white-board.

It is clear that User Stories are not Use Cases or Requirement Statements, as detailed by Mike Cohn, and highlighted as follows. Firstly, use cases are generally written as the result of a long analysis, whereas user stories are written as notes that will be used to initiate further analysis conversations. Secondly, requirement statements make costs visible only when all of them have been formally written in a lengthy document, whereas with user stories a complexity estimate is associated with each story immediately. Costs are then easily calculated by taking into account the velocity of the team.

Nonetheless, developers should not underestimate the complexity inherent in each story, and complementary theory can be found on this topic. Ron Jeffries breaks down the stories into three aspects: Card, Conversation, and Confirmation.

Firstly, the card does not detail the story in depth, but successfully identifies it. Typically, team members and product owners adhere to the following template, popularized by Mike Cohn: “As an <actor>, I want to <action>, so that <achievement>”. Although advantages derived from using this template have been listed, other agile evangelists have proposed enhancements. Elizabeth Keogh, for instance, came up with a new user story format that better emphasizes business value. One way or the other, templating has been the common approach, and teams should adopt one that will fit in smoothly within their environment.

Secondly, conversation is the activity that communicates the requirement from customers to developers during the product and sprint planning. At this stage, details such as dependencies and barriers are mapped out. As depicted by Jeffries, the conversation is largely verbal, but is often supplemented with documents. It is important to bear in mind that good communication is a key success factor in any software development project, and none of the artifacts produced throughout the process may substitute that.

Finally, stories are verified through confirmation or, more specifically, acceptance testing. All criteria taking into consideration ought to be defined during planning phases as well.

Although the theory presented above brings some structure to the loose perception of user stories, the writing itself remains vague. So William Wake advocates that agile practitioners should INVEST in good stories and SMART tasks. Despite not being a particular fan of forced acronyms, I have to admit that some guideline will be welcome here.

Briefly, characteristics that form a good story description are the following:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

.
Hence, a story should be independent from others, negotiable between customers and programmers, valuable to customers, estimable in terms of complexity, small for the sake of understandability, and testable on account of readiness confirmation. Further studies suggest that “Small” should be replaced with “Sized appropriately”, as the bottom of the product backlog may contain items that are not fully understandable by the team yet, also known as Epics.

Tasks, in their turn, should be:

• Specific
• Measurable
• Achievable
• Relevant
• Time-boxed

.
So a task needs to be specific by addressing one particular point, measurable in order to be tested against the definition of done, achievable by the task owner, relevant to the story at hand, and time-boxed. This latter characteristic should not be perceived as a formal estimation in hours or days though, as it does not work. The raw material in Software Engineering is the developer’s own intellect, and nobody would be able to estimate its maturation time. The same applies to activities such as painting or novel writing. Civil Engineering, on the other hand, benefits from using raw materials that allow for accurate calculations, such as concrete and iron.

As a final note, during the planning, instead of defining longer iterations and allowing for bigger stories, you might be interested in giving the following set of constraints a try. SWAT has successfully built some of its software by adhering to them. Manageability goes through the roof!

• 5-day sprints
• 5-point stories, or less
• 2-developer teams, up to 4

.
In conclusion, a better organized agile planning is more likely to drive the team towards the goals identified by project stakeholders. Theories and guidelines have been proposed, and I suggest bringing these concepts to the table when starting a new agile project.

I must confess that Jono Bacon actually caught me by surprise. While I was following the creation process of the book (O’Reilly invited UG leaders to send feedback) I could have never imagined I would one day have something so useful for someone who deals with communities on a day to day basis. In this universe Jono is a well known figure, with vast experience in managing and participating in online communities, which credits him as a perfect candidate to write a book like this one.

A book about how to manage and live amongst virtual communities has all the elements to be a boring book full of “do’s and don’t’s”, in summary a very repetitive and unpleasant book. However Jono proves his understanding of the communication channels (important part of any community) right off the bat in the book’s introduction. Here he showcases his writing strategy, telling personal experiences. Building on top of this premise the author goes throughout the book presenting us with new concepts or strategies and following it up with a real life example from his and others’ experience in communities. This makes the book a delightful read, easy and flowing, the kind of book you can pickup anywhere and have fun while you plow through the pages, perfect for the everyday life of lines and waiting. I recommend loading it up on your e-reader if you got one.

The book is incredibly broad and valid for numerous roles inside every community, from managers to members, volunteers, to the regular Open Source developer. Each level of the community stands to gain from this book and even people who work with or use the community, such as marketing people, and activists who need to learn how to communicate and win-over the communities. Each chapter dives into a different and fundamental aspect, like communication, building buzz, measuring, events and handling conflicts.

Anyone who has ever managed a community and looks at this table of contents will surely have a few flashbacks of various moments in their experience, I know I for one identified myself in quite a few situations, from my motivation to participate in the PHP community to the conflicts and the experience of contributing to Open Source. I usually like to give more details of each chapter when I do reviews like this one, but in this case that feels like I would be cheating the reader from the amazing experience of having Jono lead you through his experiences and concepts, so i’ll not do it.

In summary, if you have any involvement with virtual communities, be it as a manager, member or just someone who interacts with them, this book should have its place in your shelf. Buy it, read it, enjoy it an have fun while you learn to take your community to the next level.

The Art of Community
Author: Jono Bacon
ISBN: 978-0-596-15671-8
Pages: 400
Year: 2009
Publisher: O’Reilly
On O’Reilly | On Amazon

As outlined in his talk, the very first question when developing for mobile is: what type of application do I want my product to have? Currently, there are three different types: Native, Web and SMS. Choosing one is based on the purpose of your project as well as the target audience.

• Native: used when the aesthetics of the app is very important. Native is recommended when you want to access a core feature of the device, like a camera or GPS. And, because of their app stores, Native apps have the added advantages discoverability and visibility.  The disadvantage with this type of application is fragmentation, i.e. you must write a different application for each device.
• Web: used when the focus is on distribution. Web apps are available on any device enabled with Internet access and there is no need to download. Considering testing and supporting, web applications have an advantage since they do not need to go through all the bureaucracy of the app store. Updates are also up and running instantly. The main disadvantage of web apps is sand-boxing.
• SMS: rare and only used in markets where internet access on the phone is not available or prohibitively expensive. SMS apps don’t offer discoverability.

Considering the above, Web applications are usually the best choice. They are cheaper to produce, more standardized and easier to distribute. According to Stark himself, “If you CAN build your app with HTML, CSS and JavaScript, then you probably should.”

In the second part of the talk, two interesting tools were demonstrated:

jQTouch

jQTouch is a jQuery plugin for mobile webkit browsers developed by David Kaneda. It Allows native animations, navigation and automatic customization of theme. Even if you will not actually using it in your application, it is a great tool for prototyping it.

To set jQTouch, you have to add in your page:

That means:

(1) adding hardcore structural design rules. This is required and you shouldn’t edit it
(2) add your theme style file. There are some options in jQTouch website or you can write your own
(3) initialize jQTouch after javascripts files are added. You can pass an object as a parameter with some values as icon and preloadImages

You can learn more from the jQTouch website or its documentation.

You can also see a quick overview in the video bellow:

PhoneGap

PhoneGap is a framework for building cross-platform mobile apps. Using it, you can still take advantage of core features in iPhone, Android, Palm Symbian and Blackberry. It’s been recognized as a game-changer and its source code has been downloaded more than 200,000 times! Web applications can now compete with native applications when functionality is the main requirement.

For more information, you can visit the PhoneGap website.

To learn how to install it, check the video bellow:

This is probably the most common argument against template engines. People often say “but PHP IS a template engine”. Proponents of template engines will then counter argue that the syntax is simpler, but in some cases this is just not true…

We use Smarty in one of our products and in retrospect, we would most likely not have chosen to use it if we had to do it all again. However, based on our requirements and design decisions at the time, it was probably the right choice for then. When we started out, we opted for a MVC architecture where controllers pull data from models and push the data as arrays to the view. The advantage of this approach is that it keeps the templates simple because you’re only ever printing the contents of variables and occasionally looping over a dataset.

As our product evolved and became more complicated, this process became tedious and inefficient. Objects had to be converted to arrays and passed to the view. Sometimes this included a hierarchy of child objects. Then we started implementing lazy loading and iterators, the benefit of which quickly evaporated when we converted all of our objects to arrays.

We decided to instead pass either the model objects to the view or to use view helpers. The view then calls methods on the model or loops over the iterator, preserving the original objects and any lazy loading. All was well again, but of course the views started getting more and more complicated. To refer back to the argument, our templates have now become as complicated as embedded PHP code in HTML would have been. Add of course the additional overhead of the template engine and the cost of learning yet another language and suddenly a template engine doesn’t make an awful lot of sense anymore.

The problem is that requirements, design decisions and technologies all shift and evolve over time. It is not possible to predict where your product will be in 2 years, 5 years or even a few months from now. As software engineers, we try to accommodate change as much as possible by building safeguards into our code. However, at the end of the day, we cannot predict the future so we have to make peace with the fact that continuous re-factoring is as much a fact of life as change itself.

The 12th edition of O’Reilly OSCON (Open Source Conference) took place from 19 – 23 July in Portland, USA. In its first few years OSCON’s main goal was to help big companies realise the value of open source. Since that dream has become a reality, OSCON now focuses on defining, maintaining, and extending the identity of what it means to be open source. It’s also an excellent forum for discussing what future possibilities lie ahead.

OSCON is usually organized as following: The first  2 days of the conference are made up of tutorials and summits. Tutorials last 3,5 hours and feature 2 different themes each day. For summits, you usually have 2 different topics to choose from (this year they were cloud computing and scala) and it lasts a whole day.

For the last 3 days there are 40 minute sessions happening simultaneously in 13 different rooms. In addition, the first hour of the day is filled with keynotes of 10 minutes each. You don’t have to attend both tutorials/summits and sessions as you can choose what you want to do when registering. Themes covered by the sessions include: business, cloud computing, community, databases, education, gvernment, health, java, mobile, perl, PHP, Python, Ruby and tools & techniques. And I won’t even talk about the unofficial activities.

I decided to go to OSCON this year for many reasons. Firstly the variety of subjects was really impressive. I have never seen a conference with so many quality sessions happening at the same time with such well known speakers as Chris DiBona, Sebastian Bergmann and Tim Bray. Sessions were really exciting, specially the ones talking about mobile development and javascript programming. And, last but not least, I have always been found of open source in general. I can honestly say that the conference definitely delivers – it was the best conference I’ve been to so far.

As always, there is some room for improvement. Simple things like indicating level of dificulty in sessions and tutorials. Some rooms were too small for sessions and lunch(!), but nothing too critical. I would recommend it to anyone I know and would be really happy to go back again.

Welcome

Board

Exibitors

Badges

Conference Website: http://www.oscon.com/
Slides from sessions and tutorials this year: http://www.oscon.com/oscon2010/public/schedule/proceedings
Photos: http://www.flickr.com/photos/oreillyconf/sets/72157624428101453/

“Drizzle is a community-driven project based on the popular MySQL DBMS that is focused on MySQL’s original goals of ease-of-use, reliability and performance. The Drizzle team is removing non-essential code, refactoring the remaining code, switching to a microkernel architecture (with well-defined APIs) and generally making Drizzle into a lean, mean query-running machine.”

One of the biggest drivers for the lean kernel and quick bootstrapping of Drizzle is to make it an ideal database to use on cloud architectures. It is important to note that due to this, windows compatibility was removed from Drizzle.

It is quickly apparent that creating a stripped down version of MySQL wasn’t their only goal as the system includes a comprehensive plugin architecture. This allows many options for integration.

Pluggable authentication allows you to use plugins to authenticate using something like LDAP or HTTP. A pluggable query filter allows you to block or filter queries before they get executed. With the pluggable query cache (still in development), you could even plug in something like memcache. Even SQL functions are pluggable, allowing you to write custom functions.

Drizzle can be installed using apt-get, RPM’s or can be easily compiled from source. Installation is made even simpler because there is no bootstrap step and no system tables that need to be created.

Starting up Drizzle is simple, with the only required parameter being the data directory: drizzled –datadir=/my/data/path

Plugins can be installed using apt-get and need to be enabled when starting up the daemon, for example: –plugin-add=md5,pbxt

Drizzle is still in alpha and major new changes are introduced on a daily basis, so its not quite ready for your production environment, but it’s certainly worth keeping an eye on this project.

For more information, visit the project wiki.

In actual fact, there are multiple layers within each section that can affect the speed of a web application and bottlenecks can occur at almost all of these layers. There are a few techniques that can be used to improve the application’s speed. In order to fully understand the reasoning behind these techniques, a better understanding of the way things work is needed.

To keep this manageable, this will be split up into a series of topics.

Networking Basics

To start off with, we can take a look at a very high level view of the protocols used in internet traffic.

There are 2 main protocols used on the internet – UDP (User Datagram Protocol) and TCP (Transmission Control Protocol). Depending on what is required, either one of these two is used.

TCP is optimised for accurate delivery, rather than fast delivery. There is a time penalty for ensuring that messages are arranged in the correct order and that lost messages are resent.  To guarantee the reliability of the packet transmission, TCP uses a 3 way handshake to establish TCP socket connections over the network.

TCP Handshake – Source

Host A (initiating host) sends a SYN(chronise) packet to Host B with a SEQ(uence) number attached). Host B will then send and SYN-ACK(nowledgement) to Host B. Host A will send an ACK to Host B. If all these steps go smoothly, a connection will be established. If a failure happens in the transmission of the data, the host can request the packet with the given sequence number again. The same sort of handshake is done to signal the end of transmission and tear down the connection. This is what is done with every new connection that is made and the establishing and tearing down process makes TCP a lot more bloated and time consuming than UDP. The TCP header is significantly bigger to allow it to handle all of these requirements.

TCP Header – Source

UDP behaves in the following manner:

UDP is the other major underlying communication protocol of the Internet. It does not use a handshake to establish a “connection”. The protocol retains no state information of messages sent. Packets are sent on a “best effort” principle. There is no final check to guarantee that the packet that was sent made it to its final destination.  As a result of this, the UDP header is smaller than the TCP header.

UDP Header – Source

Despite TCP being a lot slower than UDP, it ensures integrity and reliability of the datagrams and the bulk of applications on the internet require this.

Since most traffic requires the use of TCP, there has been a lot of work in trying to optimize the use of it. An interesting example of this is an initiative by Google called SPDY (pronounced speedy). Basically, the goal of this is to speed up page load sizes by overcoming some of the shortcomings of the current implementation of HTTP. These include:

• Allowing many concurrent requests to be run on a single TCP sessions. This will prevent the tear-down of the session and the creation of a new session for the next request.
• Add compression to the headers
• Add priorities to requests so that content that is considered more important is delivered earlier.

At the moment this only works on a beta Chrome client and an in-memory server that is capable of sending HTTP and SPDY responses. It should be noted, that SPDY is not meant as a replacement for HTTP, but it enhances it. All request-response functionality remains the same. More information can be found here

1. The page title.
2. The description of the page (found within the meta description tag) or an excerpt of the page containing the keywords you searched for.
3. The URL of the web page.

In Google’s ongoing pursuit of organizing the world’s information and providing users with a better search experience, they have now introduced even more information into the SERPS – Rich Snippets. So what exactly do these Rich Snippets look like? Before showing you examples of different Google Rich Snippets let’s look at what is required for a specific web page to be ‘rich snippet friendly’.

With rich snippets, webmasters with sites containing structured content—for example, review sites or business listings—can label their content to make it clear that each labeled piece of text represents a certain type of data: for example, a restaurant name, an address, or a rating. This information doesn’t affect the appearance of your content on your own pages, but it does help Google better understand and present information from your page. For example, it can be used to create rich snippets to be displayed on a search results page.

To ensure your site is rich snippet ready all you need to do is use any of the following structured data formats: microdata, microformats, or RDFa. These structured data formats allow machine-readable data to be embedded in HTML documents in an easy-to-write manner. They are designed for humans first and machines second and it will in no way change the look of your web pages, only give machines like Googlebot a better understanding of the data on your web pages. From an SEO perspective this could increase the CTR (Click Through Rate) to your site from the SERPs even though your site may not be first on the page.

Now let’s have a look at various forms of Google Rich Snippets using structured data formats:

Facebook Friends

View a persons Facebook Friends straight from Google SERPs

Reviews and Ratings

Avatar Ratings and Review Rich Snippet

LinkedIn Location and Job Title

LinkedIn Rich Snippet

Implementing structured data into your website will not require learning a new programming language as it uses simple attributes in HTML tags (often <span> or <div>) to assign brief and descriptive names to items and properties. Only a small amount of web development is required to enable your sites to displayed in Google SERPs with rich snippets included.

Its that simple – what are you waiting for?

In Graph 1, above,  we have a very simple graphical model.  X₁, X₂ and X₃ are random variables, representing events. Each node in the graph will be associated with such a random variable, and nodes are connected with a directed or undirected edge. The edges between the nodes indicate that there is a connection between the events. From the definition of a random variable, each X_i therefore has a number of realisations (observations of a random variable), each with a different probability. The joint distribution of the 3 variables is given, in this example, by

The probability distribution of X₁ may be given by

Using this probability distribution, we find that

Note that there are some properties and rules of probability that all probability distributions have to obey by, and thus also the functions, which may otherwise be arbitrarily chosen. In statistics there are two types of random variables: discrete (set of realisations is countable) and continuous (set of realisations is uncountable), but the theory that will be covered will remain true for both types, and thus we will only deal with the discrete case. 

For graphical models to be useful, there must be some independencies between the variables. For instance, imagine that X₁ is my grandfather’s genes, X₂ my father’s genes and X₃ my genes. Considering these, we know that my genes will depend on my father’s genes, which in turn is dependent on my grandfather’s genes. If we have no certainty as to my father’s genes, then to have any indication of my genes, we’ll need to know what my grandfather’s genes are. However, if we know my father’s genes, knowing my grandfather’s genes will be of no value, simplistically. So, my genes are conditionally independent of my grandfather’s genes, with that condition being that we know my father’s genes. When looking at the graphical model for this scenario, it is as in Graph 1. The edges between the nodes indicate the dependencies, and the arrow-heads indicate the direction of the dependence. This type of graphical model is known as a Bayesian Network (BN), since the edges are directed. BNs must be acyclic and are also known as directed acyclic graphs. There is another type of graphical model known as Markov Random Fields (MRF), in which the edges are not directed [the arrowheads fall away], and although the dependence is still indicated, there is not as much information as in a BN. However, MRFs have their own advantages, and there are probability distributions that can only be represented by MRFs and some that can only be represented by BN.  The two types can be converted to each other, with BN to MRF being more popular because it is easier.  The moral graph of a BN is the MRF that it will convert to, where after the probability distributions still need to be allocated.

The detail surrounding the interaction between probability theory and graph theory  are  lengthy discussions, if all factors are taken into consideration.  Thus, a quick summary is given.

For BN, the factor

will result in a graph having the connection Thus, in BN, the heads of the arrows point to the variable that is conditioned on (the variable who’s probability we want to find, given the other variables).

For MRFs, the factor will result in the resultant graph having the connection

Thus, in MRF, edges are drawn between variables that are found together in a factor.

There are three basic canonical graphs which graphical models are built up of. The associated joint probability distributions are

These distributions illustrate the three scenarios of conditional independencies – the one thing that is necessary in graphical models, seeing as if there are no independencies / conditional independencies, then using graphical models has no advantage over any other modelling technique. To see exactly why the variables are conditionally independent, one would have to go into detail discussing d-separation for BNs and graph separation for MRFs. The definitions of these techniques are:

d-separation:
If A, B and C represent groups  of nodes, then the nodes in group  A and group B are said to be conditionally independent of each other if, for every path between A and B,

• there is a node in C that is on the path between A and B where the arrows meet either head-to-tail or tail-to-tail, or
• there is a node that is not in C and none of this node’s descendants are in C that is on the path between A and B where the arrows meet head-to-head.

Note that the definitions of the different connections will be given in the next section.

graph separation:

If a group of nodes C separates the group of nodes in A and group in B, then the nodes in A and B are conditionally independent, given C.

The graph for the BN associated with

is

with X₂ having a head-to-tail connection, and for the MRF

Thus, from the definitions, X₁ and X₃ are conditionally independent, given X₂. This can be seen from the joint distribution as well.

The graph for the BN associated with

is

with X₂ having a tail-to-tail connection, and for the MRF

Therefore, X₁ and X₃ are conditionally independent, given X₂. Again, this can be seen from the associated joint distribution.

The last case to consider is when X₂ has a head-to-head connection, in a BN.
The graph of the BN associated with

is

and for the MRF is

From these graphs, it is clear that in the BN, X₁ and X₃ are conditionally independent, given X₂. However, this is not the case in the MRF, seeing as all the nodes are connected. It is this difference that causes information to be lost when converting from a BN to a MRF.

Although the probability theory was not covered in depth, a feel of how the probability theory and graph theory works together in a graphical model was introduced.

Many, including myself, saw the iPad as a “a big iPod Touch”. It took only a few hours of use to completely dispel that belief. The iPad manages to combine a great deal of hardware into a single well designed piece of electronics. Sitting in front of a desktop computer, I look around and notice that all the following is combined into one: screen, CPU case, keyboard, mouse, and in the next version of the device the webcam will be integrated as well.

How did they do this ? Well – the device has become controller, input mechanism and output mechanism in one. By integrating the screen, and adding motion, position and touch sensors, it has become possible to use software to control what the device does with the input it receives. It is not necessary for the sensor that registers keystrokes to be JUST a keyboard anymore  – it can morph into the tip of a paintbrush or a controller for a weapon in a game. Similarly with other components – the screen can become a window on the world, it can be a placid pond, it can be a web browser, a calculator, a paint palette.

Of course the iPad can be used in many ways – as an entertainment device for pre-packaged content such as movies and TV series, or as a device for consuming interactive entertainment in the form of games. It makes the (in my opinion ill-conceived) concept of netbooks immediately redundant. It is serviceable for use as a limited business tool. And yes – for many it is an adequate replacement for print media, in particular magazines and books.

This post is not about the iPad. I am using the iPad to demonstrate that a device with many sensors, and a catholic approach to receiving input, can be used as a generic tool. The hardware itself becomes a generic substrate which is given concrete expression by the software running on the device. The iPad is the first of these devices, a primal ancestor of what is to come. I predict that increasing miniaturisation and the eventual arrival of practical nano-technology and programmable biology, will make “generic” hardware a common reality in ways which we cannot foresee yet. The Internet of Things will be the operating system for all our software.

In summary – convergence means more than the universal consumption of media on IP based devices. In the medium to long term convergence will come to mean the universal configurability of all devices, to deliver whatever function we wish them to deliver.

Ten years ago something like the iPad would have been considered science-fiction. Today’s science fiction will be the must-have product in two year’s time.