Category Archives: Uncategorized

7 Languages in 7 Days: Day 1 – Java (1/7)

Intro

Getting Started

Let’s start with the 800lb gorilla in the room, Java. Why Java? Well, let’s start off with the fact that it’s got a ton of community support and documentation everywhere. If you Google a programming problem, chances are within the first three results you will see an example using Java. There is also a plethora of amazing editors available. A good editor is not a replacement for knowing the tools available in a language, but it can help you in learning.


Continue reading

7 Languages in 7 Days: Intro

Why should any developer learn more than one programming language?

This is an interesting question. Let’s think of it this way: Does a carpenter only use one type of saw? Does a mechanic only have one type of wrench? No. In short the answer is, as craftsmen of code, we are only as good as the tools that we know how to use; and programming languages are those tools. When it comes down to deciding on what language it is that you want to learn, the question you need to ask yourself is this. What type of developer do I want to be?

Continue reading

Acceptance Testing presentation at Iowa Code Camp

I had the opportunity to present at the eleventh Iowa Code Camp on June 8, 2013.  The title of my presentation was “Easy Acceptance Testing.” The purpose of the presentation was to discuss an acceptance testing framework that Source Allies, Inc. developed for a client while working on a large scale web application.
I started the presentation with a discussion on the various types of software testing. Then I focused the discussion on acceptance testing.  I discussed some of the disadvantages and advantages of acceptance testing that I have observed.  I discussed some of the various tools available for acceptance testing like Cucumber, Fitnesse, and Selenium.  Finally, I demonstrated a generic version of the acceptance testing framework we developed for our client.  The demonstration was executed against a randomly selected website to show how easy it is to create acceptance tests for a web application using this framework.
The framework is written in Groovy and uses Selenium.  It takes advantage of some of the language features of Groovy such as Closures and Delegates to simplify the formation of test cases.  The test cases are defined in an XML format so that they can be easily changed.  The framework also supports nesting test cases inside other test cases.
The presentation slides and generic framework code is available for download on GitHub at http://github.com/cecilgwilliams/

I had the opportunity to present at the eleventh Iowa Code Camp on June 8, 2013.  The title of my presentation was “Easy Acceptance Testing.” The purpose of the presentation was to discuss an acceptance testing framework that Source Allies, Inc. developed for a client while working on a large scale web application.
Continue reading

Getting Started With Camel: Marshalling

In my last post on Camel, I spent some time introducing you two of its biggest players, the Context and the Route, by means of a simple problem – processing data coming in via file. If all we had to do was move the file, we could call our job done and move on, but what if we need to do something with that information?

Here’s a quick recap of our problem from last time.

  1. User puts file in directory.
  2. System reads file from directory.
  3. System breaks each line into a separate record.
  4. System processes each record.
  5. System archives the file.

I’ve marked off steps 1, 2, and 5 since we already took care of them with our simple implementation of the File Transfer pattern. Steps 3 and 4 offer us an opportunity to explore the Message Transformation Enterprise Integration Pattern (EIP), which covers interactions between systems that don’t share a common API (e.g, our file and a Java-based API that takes a plain-old-java-object (POJO)).

The Exchange

EIPs run on messages. They are read, sent, manipulated, and stored based on the individual needs of the system, and Camel’s API follows suit nicely. Remember our FileMover, the simple route we defined to grab a file out of a directory and park it somewhere else?

@Component
public class FileMover extends SpringRouteBuilder {
    @Value("${camel.ride.app.output.directory}") 
    private String outputDirectory;
 
    @Value("${camel.ride.app.input.directory}") 
    private String inputDirectory;
 
    @Override
    public void configure() throws Exception {
        from("file:" + inputDirectory).to("file:" + outputDirectory);
    } 
}

We already covered that this little route is building a connection between two of Camel’s EndPoint classes, but what happens in the middle? To start, Camel builds an Exchange, which will facilitate the transfer of a Message from one endpoint to the other. The exchange contains all the interesting bits and pieces of your message. You can get at this content several ways, but the simplest by far is with a Processor.

The Processor Interface

Attaching a Processor to an Endpoint is an easy way to hook into a route and see what is going on because a Processor has one method, process, which takes an Exchange.

@Component
public class SimpleProcessor implements Processor {
    @Override
    public void process(Exchange exchange) throws Exception {
        System.out.println("There is an exchange going on.");
        System.out.println(exchange.getIn().getHeader("CamelFileName"));
        System.out.println(exchange.getIn().getBody());
        System.out.println(exchange.getIn().getBody().getClass());
    }
}

All that’s left now is to inject this processor into our File Mover route.

@Component
public class FileMover extends SpringRouteBuilder {
    @Value("${camel.ride.app.output.directory}") 
    private String outputDirectory;
 
    @Value("${camel.ride.app.input.directory}") S
    private String inputDirectory;
 
    @Autowired
    private SimpleProcessor simpleProcessor;
 
    @Override
    public void configure() throws Exception {
        from("file:" + inputDirectory).process(simpleProcessor).to("file:" + outputDirectory);
    }
}

The above class gives one example of how we can solve our remaining steps, by grabbing the Body of the In message and breaking it into different objects, but there are better options, namely letting Camel marshal (or transform) that object from it’s incoming format into something we can use.

Marshalling to Spring Managed Beans

Camel’s marshalling functionality allows us to transform the data coming from our file in a variety of ways. For this example,
we’ll look specifically at comma-separate-value (CSV) file processing, but there are others available, most notably the ability to marshal to and from XML.

In a simple world, we might be handed a CSV file containing the following data:

John,Smith
Sue,Anderson

As you might guess, the values in this file represent the first and last name of a person. If we were to use a processor, like our example above, we would need stream the contents of the file and build Strings for each of the fields in our CSV, and then set them on the appropriate POJO. Instead, we’ll let Camel do the work for us, so all we have to worry about is getting a list of Strings for each row.

CSV processing is a separate module in Camel. To use it, add the following to your Maven POM file.

<dependency>
     <groupId>org.apache.camel</groupId>
     <artifactId>camel-csv</artifactId>
     <version>${camel.version}</version>
</dependency>

Before we hook CSV processing into our route, we’ll need a bean to do something with the results. The Person class used here is just a POJO with a first and last name field.

public class CsvToPersonProcessor {
    public void process(List&lt;List&gt; csvRows) {
        for (List csvRow : csvRows) {
            Person person = new Person();
            person.setFirstName(csvRow.get(0));
            person.setLastName(csvRow.get(1));
            doSomethingTo(person);
        }
    }
}

One thing that’s a little odd here is the process method, which takes a list of a list of Strings. Why that particular method signature? The answer lies within Camel’s CSV library. Each row in our csv file is going to be broken into a list of Strings, and that list is going to be added into another list, so what you have at the end of the marshalling process is a list of all the rows from our CSV file. Yes, this means that your whole file will be in memory at once, which is bad, but hold on a second while we look at our new route definition, because we’ll get to that problem in a minute.

@Component
public class FileMover extends SpringRouteBuilder {
    @Value("${camel.ride.app.output.directory}")
    private String outputDirectory;
 
    @Value("${camel.ride.app.input.directory}")
    private String inputDirectory;
 
    @Override
    public void configure() throws Exception {
        from("file:" + inputDirectory).to("file:" + outputDirectory)
                    .unmarshal().csv().beanRef("csvToPersonProcessor", "process");
    }
 
}

Like before, we are picking up a file from one directory and moving it to another, but now, at the end, we are unmarshalling the CSV and sending the results to the process method of the bean we defined above. And like I said before, it’s going to do the entire file by default. So now, we need to stop doing that, before we run out of memory.

@Component
public class FileMover extends SpringRouteBuilder {
    @Value("${camel.ride.app.output.directory}")
    private String outputDirectory;
 
    @Value("${camel.ride.app.input.directory}")
    private String inputDirectory;
 
    @Override
    public void configure() throws Exception {
        from("file:" + inputDirectory)
                .to("file:" + outputDirectory)
                    .split(body().tokenize("\n")).streaming()
                    .unmarshal().csv()
                    .beanRef("csvToPersonProcessor", "process");
    }
 
}

In the class above, we are splitting the body of the message on each new line, and then streaming the result to the CSV unmarshalling process we had before. The big change here is that now our CsvToPersonProcessor is going to be invoked one time for each row in the CSV, which means our looming memory issue is gone.

Before I wrap everything up, you probably want to know what to do about the pesky column headers that come along with many CSV files. These are dealt with through an instance of the DataFormat interface injected into the marshalling/unmarshalling portion of your route. You are welcome to roll your own DataFormat, but the camel-csv module also includes a CsvDataFormat class which, as it turns out, you were using the whole time with your call to the csv() method. All you need to do is break it out as a variable, flip the “skipFirstLine” property, and inject the DataFormat into your unmarshal call.

@Component
public class FileMover extends SpringRouteBuilder {
    @Value("${camel.ride.app.output.directory}")
    private String outputDirectory;
 
    @Value("${camel.ride.app.input.directory}")
    private String inputDirectory;
 
    @Override
    public void configure() throws Exception {
        CsvDataFormat format = new CsvDataFormat();
        csv.setSkipFirstLine(true);
 
        from("file:" + inputDirectory)
                .to("file:" + outputDirectory)
                    .split(body().tokenize("\n")).streaming()
                    .unmarshal(csv)
                    .beanRef("csvToPersonProcessor", "process");
    }
 
}

It’s probably worth noting here that because we were using Camel’s Java DSL for all of the above examples, we didn’t need to make any additional changes to the XML snippet we defined last time.

What’s Next?

Our problem is solved, but what happens when things don’t go according to plan? In my next post, I’ll cover some of the error handling techniques available in Camel. The full source for the code above, including test coverage, is out on the marshalling branch of the camel ride repository on GitHub. Go crazy.

A Basic Canvas

Over the weekend I decided to play around with the new html5 element canvas.  The canvas allows you to paint images in the browser that previously was done with flash.  Canvas is fairly straight forward and only requires a basic knowledge of html and javascript.

I decided a good start would be to try and make a thunderstorm in order to show the animation bit of canvas.  In this article I will describe what I did and the issues that I had along the way.  Finally at the end I will provide a working example with all of the code.
Continue reading

IRC Reporter

Recently I was asked to make a bot for a local user group.  The bot would simply report new events into the topic of an IRC channel.  After the bot was created I decided to write an article about it and publish the code.  The code and article  can be found here: http://www.dsmwebgeeks.com/2012/09/creating-an-irc-bot-stephen-dunn/

Basically the bot will constantly check the sites rss feed and then see if there are any valid changes for the topic.  If a valid change is found then it will quickly update the topic.  I used the TCL scripting language since it is allowed by an eggdrop bot.  I hope that you read it and find it useful.

Multi-Step Forms in Django

Forms in Django seem to be a relatively advanced topic if you want to do anything outside of models.  Case in point: I had to develop a multi-step form in django that would spit out a certain result.  There were only two forms that the user needed to fill out, but the second form had to change what fields it had based on the input from the first form.  Also, the form did not save anything to the database; it just created a file for the end user to download.  To solve this problem, I did research.  A lot of research.  And like any good technical topic, the information I needed was all over the place on the Internet.

Continue reading

Next Step in Agility

I often find that teams that have adopted Agile practices quickly plateau. They often start by scheduling a daily stand up, planning in iterations, take time for a retrospective, and modify their estimation process. These are common first steps in the agile adoption process. Teams have varied success and commitments to these practices but nevertheless these are the low hanging fruits in the Agile adoption journey.
Continue reading

Learning a new Language

I attended a No Fluff Just Stuff Symposium a few weeks ago. One of the main emphasis during the weekend was learning new languages that are available on the JVM. While there are a variety of reasons that we need to take time to learn new programming languages, one of the most profound is learning to think about problems differently.

Paradigm Shift

When I entered the development scene I was immersed in Object Oriented programming. As a result, I tend to think of good design in objects. A few years ago I began to learn and apply Groovy. With closures I was able to bleed into the realm of Functional programming. This gave me a small taste of a new paradigm. I thought of new ways to solve problems that I couldn’t see with Java. I can only imagine how much more I could learn if I developed exclusively in a Functional language for several months.
Continue reading

Spring Injection with @Resource, @Autowired and @Inject

Overview

I’ve been asked several times to explain the difference between injecting Spring beans with ‘@Resource’, ‘@Autowired’, and ‘@Inject’. While I received a few opinions from colleagues and read a couple of posts on this topic I didn’t feel like I had a complete picture.

Annotations

Annotation Package Source
@Resource javax.annotation Java
@Inject javax.inject Java
@Qualifier javax.inject Java
@Autowired org.springframework.bean.factory Spring

In order to explore the behavior of each annotation I fired up Spring Tool Suite and started debugging the code. I used Spring 3.0.5.RELEASE in my research. The following is a summary of my findings.
Continue reading