Click here to view the embedded video.

First thanks to all who told me about DiceEQ issues with iOS4. It’s cool to see people actually using it. Since I have a 3G iPhone I didn’t immediately update to iOS4 and so wasn’t aware that anything was wrong. However, now that I am, the problem has been fixed and the updated version is out to Apple for approval. I’m hoping it’ll be out in the next few days. I’ll update you all when it is.

VortexPool appears to be working fine with iOS4.

Click here to view the embedded video.

In addition to shelves, several other things have also changed.  First you’ll notice that the logo at the top has gotten much smaller and the drawing area has gotten much bigger.  I have also taken the time to fix many bugs (most of them dealing with Internet Explorer) and improve performance accross all browsers, so hopefully you’ll find using Graphsy more pleasent.

As for the future, the next big updates will involve grouping objects together, creating tables. exporting graphs as PDFs, and sharing shelves among users. Let me know if you have any other ideas.

One of the things I want when the shelves system is done, is to release many different object that could be used in several different chart drawing projects. However when creating them I ran into a few bugs and performance issues. These are being sorted out right now.

In addition to those, I also began to clean up the UI elements. Some of the buttons did not look correct and consistent, so I am changing those as I go. I also shrunk the Graphsy logo to give more drawing room to the user.

I’m hoping to get all of the features done in about a week, so if everything goes right you should see a new and improved Graphsy version after that.

After this upcoming release, I will spend some time updating the videos, front page, blog, and the help system of Graphsy. In the mean time feel free to request new features or report bugs.

I feel like the trend to create better, more domain specific, tools will win out over the trend of teaching non-technical people software engineering and development practices.  I’ve met plenty of people who consider programming almost magic, they don’t understand it and do not really want to.  Even if there is a simpler solution to their problem, if it forces them to write a little bit of code, they will take the hard way out.

Having said that, these people still want to customize their working environment, they still want to optimize their process and create custom software experiences.  A really good example of a domain of software that enables users to do just that is CMS or Blogging tools.  They enable users to customize their process as well as the look of their site and content.  They are largely WYSIWYG and do not require one to ever look at the code if he doesn’t want to.  And, at the end, all of the user’s work is turned into code.

Creating software that makes it easy and fast to publish content to the web is arguably what has lead to the rise of Blogs.  We can now enjoy content from people who do not know, understand, or care about the technical side of things. And now, in addition to publishing software, there are more general tools being created.  These tools are designed to allow regular users to create their own applications with the same ease as publishing on the web. They are designed to create Mashups.

A mashup is an application that combines the features of several other applications into a single tool.  A great site to track mashups is ProgrammableWeb. Check it out to get a better idea of what mashups are all about.

The advantage of creating mashups is that the developer does not really need to create any specific feature of an application.  For instance, lots of mashups use Google Maps to present mapping information.  This lets developers to concentrate on their core competency and not try to recreate already existing services.  On top of that, by using something as popular as Google Maps, developers are able to leverage a well known interface and thus, make their own application feel more familiar to the user.

As we have been discussing so far, non-technical users want more freedom and control over their experiences with applications.  This is where mashups come in.  Because creating a mashup involves reusing features that one is familiar with, their creation seems like a natural fit for application users.  To that end, several mashup creation tool-kits have appeared.  Most notably Pipes from Yahoo, Popfly from Microsoft, and MashMaker from Intel. The first two are really just abstractions of the programming paradigm using graphical elements.  The third does something very different.

Instead of trying to simulate programming via block and arrows, MashMaker works as a plug-in into Firefox or IE.  It lets users annotate their data as they are browsing the web.  The annotated data can then be used as input into other services and the produced result can be insert back into the original page.  For example, one can specify which part of a CraigsList listing is the address and have MashMaker render a CraigsList page annotating all of the listings with a small map from GoogleMaps. You can find more information, including a demo video, as well as the plug-in itself, on the MashMaker site.

By restricting the domain and simplifying the problem, developers can create powerful tools that enable non-technical users to create custom applications and experiences.  In the case of blogging and mashup creation tools less is truly more.  This is more broadly knows as domain specific languages, but that’s a topic for another post at a later time.

Related articles by Zemanta

• Google Maps: 100+ Best Tools and Mashups
• See “What, Where, When” with this Flickr Mashup

When actually drawing shapes, you begin by clicking once on an empty spot, to select where the shape will start.  Then click again to draw the first edge of the shape.  Then, each additional click adds another edge. To finish drawing the shape, you have to click on the starting node.

The custom shapes have the same context menu as the regular shapes with one additional button.  In the lower left corner of the context menu there is a button to edit the shape.  By clicking on that button, or pressing ‘z’, you can edit the shape by moving, deleting, and creating new nodes.  All of those are accessible from the appropriate context menu.  A selected node can be moved or deleted it via its context menu.  Selecting an edge enables one to split it at the point of selection, again via the context menu.

The shape objects can be used in the same way as the regular shapes.  One can change their width and height, animate them, or change their color properties. Everything that can be done with regular shapes can be done with these “custom” shapes.

Next on the agenda is to create a way to group objects together and save them into libraries that could be shared with other users.  I’m still trying to figure out a good name for the library, right now I’m thinking shelf, but if you have any suggestions please post them in the comments or email me. I hope you guys like the new feature, as always let me know what you think.

To finish up here is a demo of the shapes:

Here is also a simple example of an embedded Graphsy animation. Hit play, followed by next:

The impetus for this feature came from wanting to write a post clustering and how it relates to software engineering.  I wanted to use Graphsy for illustrations, and then thought about using animations to demonstrate clustering.  Clustering and animations are a very natural fit, but Graphsy did not have that available.  So I figured I would create it.

As I started implementing the features I realized that it is going to be a bit more work than I originally thought.  A few things in the low levels needs to be changed to make room for it.  And, as I was creating it, the interface I wanted to use for it changed as well.  The feature has morphed from something really simple to something a bit more powerful, but hopefully still as simple to use.  I’m about half way there right now.  I’ve crossed most of the major hurdles already and can create some very basic animations.  What’s left is cleaning up the UI, adding build in and build out animations, and creating a player available in the embedded version of the graphs.

I hope to finish this in the next two to three weeks.  With a post about the features will also come a post about clustering to demonstrate the usefulness of Graphsy.  I hope people don’t mind me going off the path, but I really want to get Graphsy to a point where I use it as my main graph creation/editing tool.  It’s not there yet, hence the alpha and not beta, but hopefully it’ll get there in the next few months.

To set the ground for this post I first need to reiterate a message that has been heard from many other sources.  Code coverage can only tell you how bad your test suite is, not how good it is.  Meaning that if you have bad coverage you know something is wrong, but a high coverage number tells you virtually nothing.  This message seems obvious for many developers out there, but it’s not heard by a surprisingly large section of them.

I have been a teaching assistant for several undergraduate and graduate testing classes.  Every year when I grade their unit testing projects I always get several of them (about a quarter) that hand in tests with “good” coverage, but not a single assert statement to check the results of their tests.  This is even after I get up in front of the class and rant about the exact problem from previous years. Needless to say those students tend to do poorly.

So, if test coverage is not a good metric, how can developers measure the quality of their test suites?  I’m going to talk about one approach in this post, mutation testing.

What is Mutation Testing?

When testing code, developers want to confirm that the application does what it is supposed to do by trying a whole bunch of different cases where the end result is know.  Mutation testing applies a similar idea to testing the test suite by intentionally inserting bugs into the application’s source code.  If the test suite can’t find these bugs, then we know something is wrong.  We can further study the effectiveness of individual test cases by observing the number of mutations each test case can find.  If there are test cases that detect no mutations, then they need to be examined to find out exactly what functionality they are trying to test.

Now at this point I do need to say something that should be obvious.  Like most forms of testing, mutation can only show you the presence of problems, not guarantee their absence.  If mutations are found, it does not necessarily mean that the test suite is finding all bugs.  The goal of mutation testing is to give developers more confidence in their test suite, and, as we talk about the kinds of mutations automated tools do, you’ll see where the limitations of this form of testing are.

What Kinds of Mutations are There?

The mutations performed by automated tools are usually fairly straightforward.  They are not large logic changes, but instead small replacements of logical and arithmetic operators.  For instance, mutated code may replace the ‘+’ character by a ‘-’ character and vise versa.  It may change logical AND operators such as && to logical OR operators such as ||.  Mutation will also change comparisons such as == to < or > as well as swap increments like ++ for decrements such as –.  In some cases, mutation may also change constant values, change return codes, or even reorder case statements.

Developers need to be aware that some mutations may not really change the semantic meaning of the source code.  For instance, if a loop is incrementing an index value (i++) until a check (i == 5) is made, swapping the == comparator for >= will create an equivalent mutant. Meaning that in this particular case i == 5 will trigger at the same time as i >= 5.  Performing this mutation should not trigger a failure of any of the unit tests.  Some mutation tools will attempt to reduce the number of equivalent mutants, but their success rates will vary with every case.

What Code Should be Mutated?

One of the biggest reasons mutation has not been as popular as some think it should be is because it leads to a large number of mutant applications.  So, if the time to compile the application or the time to execute the test suite is long, developers have to be careful about how their applications are to be mutated.

A simple way to organize mutation testing is to first figure out how many mutants you have the time to test.  The formula for that is simple: int NumMutants = MutationTime/(CompileTime+TestingTime).  If we only introduce one mutation per version, mutation testing may not get you very far.  It is clear that for any non-trivial application we will have to do better.

It is not clear, however, just how many mutations should be introduced in a version.  Simply changing every operator that can be changed won’t do much good as a single mutation may always be caught as a bug, well before other mutations are even touched.  We need to do something smarter.

What we really want, is to introduce as many independent mutations as we can and run only those test cases that may be effected by those mutations.  This is exactly the information we get from coverage.  To target a test case we can study what code is covered by that test case and then introduce mutations, one at a time, only in that code.  Then, by separating the test cases into sets such that each test case in the set covers a different portion of the code, we can introduce mutations in the different regions.

For an example consider the following piece of code:

//SET UP
if(a == TRUE){
  //DO SOMETHING
}else{
  //DO SOMETHING ELSE
}

If in this case we have two test cases that both execute SET UP and then test case 1 executes DO SOMETHING, while test case 2 executes DO SOMETHING ELSE, we can introduce mutations in DO SOMETHING as well as DO SOMETHING ELSE, while keeping the rest of the code the same.  This way we test two different test cases.  If we mutate SET UP, both cases should fail and therefore detect that bug, introducing mutations in DO SOMETHING and DO SOMETHING ELSE in addition to mutating SET UP, will get us nowhere since the bug in SET UP will be caught first.

Thus, we have to be smart about where mutations are introduced.  Some mutation tools still take the simple approach of only mutating the code in one place and then executing the entire test suite.  When applying this technique, you may be able to reduce the amount of time spent by only running tests that cover the mutated code.  In addition if your setup allows for incremental compiling, or is a scripted system, your build time may be short as well.

What Tools are Out There?

Mutation testing is heavily dependent on the existence of tools.  Therefore I want to end this by pointing to a few of the ones out there:

• Jumble for Java
• Jester for Java and Pester for Python
• Heckle for Ruby
• Nester fo C#
• SQLMutation for SQL

If you know of other free tools please post them in the comments and I will add them to the list. Two other great resources to check out are Mutation Testing Online and the Wikipedia entry for Mutation Testing

The next feature I am working on is custom shapes.  I want to let users create custom shapes, combine them together into libraries, and share those libraries with others.  There is lots of work that needs to go into this, but I hope to have the basic creation tools available shortly.  Check out a list of features that were requested by other users, vote for your favorites, and add new ones at www.graphsy.com/request.

Since all of these updates, the tutorial videos are really getting out of date.  I’m going to spend some time this week updating them.  Hopefully I can get the object creation feature out in 2-3 weeks, unless work gets in the way again.

Anyway, here is a screenshot of the new feature.

New Color Picker