Category Archives: Java

Java, Programming, Python, Scripting, Web Applications, Work

JMeter or The Grinder, so which one is better, like?

Or for the benefit of Google: Apache JMeter versus The Grinder. Fight!

A while ago I got paid to put these two tools head to head and I think it’s been long enough that the people who put up the money will have got the benefit now.

I had used The Grinder in a previous job where it had done excellent service finding out what level of peak load our site could handle. It was convenient in that you script it in Jython because Jython was our chosen scripting language.

JMeter on the other hand was a whole new thing to me. It is a kind of graphical programming interface where you drop controls into a tree structure and the framework generates threads that run through the tree generating interactions with the target application via things like HttpClient.

The scripting versus component structure is a pretty major difference between the two and is probably one of the key things that is going to help you choose between two products that are both, to be honest, pretty mature, capable pieces of software.

If you don’t feel comfortable with Python or Jython then Grinder is likely to be out. JMeter is much more friendly to non-programming testers. However this decision isn’t as clear as you might think, JMeter actually includes Javascript functions, access to BeanShell and its own expression language. As we created more complex traffic simulations we found ourselves having extremely complex expressions that often mixed a scripting language with an expression evaluation. In some ways The Grinder is more honest in telling you up front that you are going to have to program some of this stuff yourself.

Another big differentiator is in reporting, if you need to generate reports then JMeter is a much better choice as it has components that collect and collate information and you can dump data to XML for XSLT transformation into pretty much any output format you want. It is also possible to run JMeter headless once you have the test scripts so it is possible to encorporate it into a continuous integration process. Debugging slightly flaky applications is much easier with JMeter because you can easily capture a lot of result information and then just delete the data gathering component once the test flow is working.

A lot of the functionality of both products overlaps: they can both be used a browser proxy and be used to capture scripts as a user “drives” around the site. These captures are likely to form the basis of your test plans unless you have a very clear URL scheme with little session state.

Both use thread pools to generate load and both tend to get blocked on your application before they max out their local machine (although both are capable of using 90% of memory and CPU). JMeter has a few nice options around randomly ramping up the thread activation (recreating a spike in usage more closely). The Grinder tends to give more bang for the buck as its runtime is very simple and minimal.

Both are also capable of using distributed agents and collating the data from these agents back to the coordinator.

In many ways there isn’t a “bad” choice to be made between them. So what might sway your choice one way or another? Well JMeter is an Apache project and that might make a difference for some people as you have all those good things like project governance and a good chance the project is going to continue to be developed and enhanced. JMeter was also the only project to have a test suite last time I checked out both code bases.

The Grinder does have one unbeatable quality in my opinion and that’s flexibility. When you look at the features listed on the websites you might think that JMeter does all this cool stuff with HTTP, SOAP and POP3 and the like and that The Grinder is comparatively light in the feature set.

The opposite is actually true, as The Grinder website points out the The Grinder can test anything with a Java API. There really is no limit to what you can make it do or how you can execute your test plan. In fact most of the things I’ve complained about with The Grinder are fixable from within the test scripts  (what I am really complaining about is that some things like capturing HTML output per run is something that should be available as part of the standard package). On the other hand I felt that creating a new JMeter component was actually quite tricky as you have to deal with both the GUI aspects and the actual functionality you are trying to create in your test component.

If you really want to have total control of your concurrent volume testing then The Grinder is probably the best product for you.

Perhaps the last topic for consideration is The Grinder’s use of Jython. Python is a great language and you get a lot of power for some very concise code. Just as some people are going to find it off-putting others are actually going to find it very compelling.

Okay so yet another weak “horses for courses” post on the InterWeb. Perhaps the easiest summary to end on is that your test teams will probably take a shine to JMeter while your developer teams who are also building scale tests are probably going to like The Grinder; unless they dislike Python or learning a new language.

Standard
Java, Programming, Software

Programming to Interfaces Anti-Pattern

Here’s a personal bete noir. Interfaces are good m’kay? They allow you to separate function and implementation, you can mock them, inject them. You use them to indicate roles and interactions between objects. That’s all smashing and super.

The problem comes when you don’t really have a role that you are describing, you have an implementation. A good example is a Persister type of class that saves data to a store. In production you want to save to a database while during test you save to an in-memory store.

So you have a Persister interface with the method store and you implement a DatabaseStorePersister class and a InMemoryPersister class both implementing Persister. You inject the appropriate Persister instance and you’re rolling.

Or are you? Because to my mind there’s an interface too many in this implementation. In the production code there is only one implementation of the interface, the data only ever gets stored to a DatabaseStorePersister. The InMemory version only appears in the test code and has no purpose other than to test the interaction between the rest of the code base and the Persister.

It would probably be more honest to create a single DatabaseStorePersister and then sub-class it to create the InMemory version by overriding store.

On the other hand if your data can be stored in both a graph database and a relational database then you can legitmately say there are two implementations that share the same role. At this point it is fair to create an interface. I would prefer therefore to refactor to interfaces rather than program to them. Once the interaction has been revealed, then create the interface to capture the discovery.

A typical expression of this anti-pattern in Java is a package that is full of interfaces that have the logical Domain Language name for the object and an accompanying single implementation for which there is no valid name and instead shares the name of the interface with “Impl” added on. So for example Pointless and PointlessImpl.

If something cannot be given a meaningful name then it is a sure sign that it isn’t carrying its weight in an application. Its purpose and meaning is unclear as are its concerns.

Creating interfaces purely because it is convenient to work with them (perhaps because your mock or injection framework can only work with interfaces) is a weak reason for indulging this anti-pattern. Generally if you reunite an interface with its single implementation you can see how to work with. Often if there is only a single implementation of something there is no need to inject it, you can define the instance directly in the class that makes use of it. In terms of mocking there are mock tools that mock concrete classes and there is an argument that mocking is not appropriate here and instead the concrete result of the call should be asserted and tested.

Do the right thing; kill the Impl.

Standard
Java

Playing around with Neo4J and Groovy

After hearing about Neo4J at Ruby Manor I decided to have a play around with the graph database but for me playing doesn’t mean creating a whole Java project anymore. Since using Python/Ruby/Scala I want to be doing it in an interactive session.

I had quite a few issues getting Neo4J to run but the summary is that for convenience you want all three jars from the distribution in your classpath and you pass a String representing a directory path to the EmbeddedNeo constructor. Once you do have it running make sure to shutdown the database on an exception otherwise you will have to shutdown the JVM (i.e. close the whole Groovy Console session) to unlock the underlying file resources.

Okay so once you have the right jars you can now start playing around with Neo4J. I immediately felt that the library is actually quite heavy with a lot of ceremony to get things done. Some of the feedback I have been hearing from Neo Technology and the Neo4J list is that Neo4J is more of a low-level infrastructure component that is meant to be wrapped up in higher-level APIs.

Working with Groovy it should be possible to cut that ceremony down a bit and put a nicer front-end on things. The first thing I’ve tried is using closures to execute code in Neo database and transaction contexts.

If you have the three jars in your .groovy/lib directory you should be able to run this script from the Groovy Console and have it create a node in your directory. It will be the same node each time but I have some ideas for using builders for both nodes and traversers (which allow you to search the graphs) and I am going to work on (and post) them later.

Standard
Java, Programming

Splitting Loot with Scala

Over the last couple of days I have been trying to implement the Sharing Problem (Ruby Quiz #65: Splitting the Loot) in Scala. So far I have implemented the greedy pick algorithim and still need to implement a recursive solution that will brute force the edge cases.

However on the way I think I have picked up some important lessons. You can see the code for yourself in the GitHub project related to the problem and the solution (it’s in the Scala directory) but I will be highlighting some of the code in this post.

This was the first set of Scala I’ve done that was actually an attempt to use some of the functional aspects of Scala rather than just porting Java code in a more or less literal and imperative way. After struggling a little bit with the implict return and list concatenation I implemented the greedy heuristic. This is what it looked like (link to the code file).

import gems._

package splitter {

  class LootSplitter

  object LootSplitter {
    def splitLoot(gembag: GemBag, shares: Int): List[GemBag] = {

      if((gembag.totalValue % shares) != 0) {
        return List[GemBag]()
      }

      val individualShareValue = gembag.totalValue / shares

      var partShares: List[GemBag] = List.make(shares, new GemBag(List()))

      gembag.gems.sort(_.value > _.value).foreach((gem: Gem) => {
        partShares = partShares.sort(_.totalValue < _.totalValue)
        partShares = List(partShares(0) add gem) ::: (partShares drop 1)
      })

      partShares
    }

    }
  }
}

I was struck initially by how compact this code was, you are looking at about 28 lines of code. However as I was looking at it I began to wonder whether it was concise or just terse. How is someone meant to interpret something like _.value > _.value? I showed it to a collegue and his first reaction was “I don’t know functional languages so I wouldn’t know what this means”.

This was exactly the kind of reaction I was afraid of because I have been converted heavily to the principal of readable code. Someone should be able to scan code and understand, in principle, what is happening here. If they don’t then the cost of maintaining that code is going to be higher and we have actually lost something in the concise syntax.

I decided to try and implement a readable version of the same file which added about 6 lines (only two according to GitHub!). You can read this version here but now I want to throw it open to the public. Is this version actually easier to read? Are things like the underscore variable actually part of the price of comprehending Scala?

In my rewritten version I use some of the nice features of Scala such as first order functions but you still have lines like this:

List(sortedBags(0) add gem) ::: (sortedBags drop 1)

I hope you are reading this as “add a gem to the first sortedBag and make a List of it and then add all the other bags except the first one to the new list” but I am worried that this is far from obvious. Is that because I’ve done something that isn’t idiomatic or is it because actually the operators and the library API are too obscure?

Scala represents a significant evolution of Java in terms of absorbing all the lessons learned during the evolution of the language. When porting Java code I feel far more comfortable with it than when I am trying to create new code that uses the core language libraries. I don’t want to evolve to a new set of problems and best practices that try to avoid them.

Standard
Java, Web Applications, Work

Better, Faster, Weaker

I went to the Developers and Startups Meetup last week (look it up on Meetup if you’re interested it was a good event). One thing that struck me was that all the entrepreneurs were mostly interested in PHP and Ruby on Rails (there was a significant rump of ASP and .Net which I can only put down to C#’s language hotness at the moment). Java in particular was poorly regarded.

I was intrigued by what was causing the negative vibe as while I can understand that Ruby on Rails is the new tech hotness I couldn’t really see the appeal of PHP over something like Java that has a decent stack that is practically free. Talking to a few people I got the sense that PHP was seen as a “getting things done” language. Something that got you to a tangible real product very quickly. Rails seemed to have much the same quality but I think a lot of people felt that Rails skills were more expensive and in a lot of cases they wanted a thin web layer over an existing service backend that already existed.

Of course both PHP, Rails and the Java Web Stack all make various compromises to do what they do. Where Rails is opinionated, Java probably isn’t opinionated enough. If you put all your code into page (Model 1 stylee) then I’m pretty certain that writing JSPs in J2EE 5 is probably as quick to put something together.

Of course one thing that hugely hampers Java as a productive web stack is the compile and deploy loop. There is none of the immediacy of something like RoR that allows you to make changes very quickly in response to feedback. The tradeoff is of course that the code needs to be interpreted and you have to add some kind of caching to avoid the performance hit of always having to evaluate code.

But given that there are a group of people who need to have code quickly so they can sell something to their customers or investors and that they are willing to make all kinds of compromises about scale and maintainance costs is the Java platform really out of the question? I ask this because I think I have been involved in quite responsive Java web teams where feature changes have been matters of days not weeks or months.

I think that perhaps the issue is partially just mental. Enterprise software development tends to take place in a risk-adverse environment where certainty or process is valued over rapid delivery. “Best practice” in this environment tends to sacrifice timeliness. In the smaller business space this might well be a practice turned into dogma.

That said though some Java Frameworks introduce major barriers to just getting stuff done. Any framework that forces you to produce XML based interaction flow is probably distracting you from generating functionality that people want and will pay for. Routing isn’t a trivial part of an application but that’s all the more reason to box clever with it. Any framework that doesn’t make it simple to inject services into classes is making life too hard. Ditto any framework that forces you to work with a particular Expression Language or Templating product.

I am wondering if what I am looking for is actually the weakest Java framework. Rather than having functionality for all circumstances (and having to configure and setup it all up) I want a very basic REST framework which I can then add templating and persistence according to my need. It still wouldn’t have the nice scaffolding of RoR but it would mean that each element of the web app would be absolutely vital to its function. Weakness would generate the power of vitality and reduce the obfuscation of bloat.

Standard
Java

Introduction to Gant

This post was started the day after a Geek Night, it was a very, very cool Night…

With every topic I wanted to talk more about it and I felt we didn’t have enough time to get all the buzz out but one thing that struck me was that not many people seem to have heard of Gant. This is a real shame as I have recently converted and therefore have all the zeal of the convert. This zeal leads me to try and convert those who have not seen the light (yet).

What is Gant? It is a Groovy wrapper around Ant tasks. Groovy comes with an Ant Wrapper so what’s the great shakes you might ask? When Gant handles all the target dependencies for the project. It is essentially the missing part of the puzzle that gives you all the Ant functionality and a lot more. Gant adds some methods to the base Groovy shell execution environment that allows you to say that a task A depends on task B.

Enough chat though let’s get on with some examples. Download the standalone gant installation and then invoke the gant script (for your environment) in a new empty directory. It will give you a moan about not being able to find a build.gant file. So let’s create one now.

My first gant file is on Pastebin, cut and paste into your build.gant (or retype it to really get the benefit).

Now when you call gant you should see Target A and Target B printed out in the order of their dependencies. Type gant b and just Target B should be printed.

To be honest this really is the core of Gant so it may seem trivial but it’s important to understand. After all if you have ever taken a crack at this Kata you will know that dependency resolution isn’t trivial.

So what should we take away from this small example? Well I think it is important to note that it is Groovy syntax, the attribute assignment in target is standard but note that we don’t need to quote the property on the left. The string is like the description attribute in standard Ant tasks.

The println call is not mapping onto Ant’s echo it is the Groovy println so all the normal stuff to do with GStrings (like interpolation) applies here. Similarly the block attached to the target is a normal closure.

Dependencies are listed by calling depends, why isn’t that in the target declaration like in Ant? Well because you can create a dependency at any point in the closure. That means you can dynamically define the dependency graph. Which when you think about it, is kind of mental.

I did not want to have a huge post so the next one is going to be about using that dynamic definition to DRY out my Gant file.

Standard
Java

Waiting for my Ruby Gems Bulk Update

One of the huge pains in the ass when using CRuby (MRI) RubyGems is that if you haven’t updated your gems in a while you can easily send your machine into a spin when you innocently type sudo gem update.

The message:

Bulk updating Gem source index

appears and then you just sit there… for hours… while gem… tries to parse… the yaml… which is obviously… much faster… than streaming… XML.

JRuby doesn’t seem to have the same issues, presumably something to do with the implementation not being so memory hungry.

Anyway if you are having this problem too you’ll be glad to know that a happy ending is possible via use of the –bulk-threshold parameter. Simply use a command line like the following and your low resource system will not actually process in chunks rather locking up your swap memory.

sudo gem update --bulk-threshold 10009
Standard
Java, Programming

Shtop! You’re copying the wrong JUnit!

I have been using JUnit 4.4 on my most recent project and this time instead of just licking around the edges I have actually being trying to use the features it adds. This time I have actually switched from using assertX to just using assertThat in combination with the various Hamcrest matchers.

I have also been using the Datapoint and Theory functionality for a mix of empirical testing (putting through a set of data that has proven problematic in the past) and also for creating shorter specific tests that tests a class of behaviour.

I haven’t used Assumptions yet but everything new I have touched has turned out to be solid gold. The only obvious lacking feature is something like RSpec’s Pending description, @Ignore is a bit rubbish really.

Therefore when I am looking at other languages (such as Flex’s ActionScript) I am really disappointed when their testing tools is actually a rather literal port of JUnit 3. Porting JUnit 3 is the act of a charlatan. It seems to be about finding the lowest common denominator that would allow you to wave some TDD colours rather than genuinely providing tools that developers need.

During the long hiatus between JUnit3 and JUnit4 was TestNG and in many ways I would rather that people used that as their template for a testing library. My current gold standard is RSpec though and I am not really seeing anything that ambitious in the “new” languages (except the very lovely Specs).

Often language teams leave library development to the “community” but if you are going to the effort of officially porting something why choose JUnit 3? The only reason I can find is that Java developers are familiar with it and that is just a rubbish reason, Java developers should get out of their comfort zone and move from JUnit 3 to 4 or TestNG. In fact since JUnit 4.5 has just been released this month why don’t you take the chance and plunge in before the month is out?

Standard
Java, Programming

Factory of Factories

I am convinced that Patterns are the new Anti-Patterns. As the joke runs, the GoF patterns show you how to write better C++.

One Pattern/Anti-Pattern that drives me up the wall are Factories. Or as the might often be better known: Constructors. After all if a Factory only constructs one type of thing it is no better abstraction that just putting the construction logic in the damn constructor.

Effective Java makes a better suggestion for Java coding that constructors like inheritance should be used sparingly. Instead of creating a whole new class for constructing instances just create static factory methods inside the class with appropriate names for the kind of construction being done.

This is neater, keeps related code closer and applies in a lot more situations. My rule when evaluating code is that an implementation of Factory actually has to create more than one type of object in a way that cannot be replicated by Dependency Injection to have value.

Not much code passes that test, not even my previous attempts to please the structural aesthetic of enterprise architects. In the past I have been as guilty of pattern abuse as anyone.

Standard