Ryanlowe

Here’s another solution to a problem I’m hoping to get Googled: If you’re running an Ant build.xml file in Eclipse, the <junit> task will not work by default. If you attempt to use the <junit> task with a fresh install of Eclipse, you will receive the following error message:

BUILD FAILED: [ECLIPSE_DIR]\workspace\[PROJECT_DIR]\build.xml:208: Could not create task or type of type: junit.

Ant could not find the task or a class this task relies upon.

This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
– You have misspelt ‘junit’.
Fix: check your spelling.
– The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Fix: declare the task.
– The task is an Ant optional task and optional.jar is absent
Fix: look for optional.jar in ANT_HOME/lib, download if needed
– The task was not built into optional.jar as dependent
libraries were not found at build time.
Fix: look in the JAR to verify, then rebuild with the needed
libraries, or download a release version from apache.org
– The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
– The task is not an Ant core or optional task
and needs to be declared using <taskdef>.

Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath

Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.

The <junit> Ant task is an optional task and this is the standard Ant error message when Ant cannot find the supporting code for an optional task. Ant includes support for the tasks themselves, but not the internal code that actually does the work.

So you need to find a copy of junit.jar, the code that does JUnit work, and tell Ant where it is. The easiest way to do this is to go to Window –> Preferences, Ant –> Runtime. In the Classpath tab click on Global Entries and then Add External JARs….

Eclipse already has a copy of JUnit, so in the dialog find your Eclipse plugins directory ([ECLIPSE_DIR]/plugins/) and go to the JUnit plugin (presently org.junit_3.8.1) and select junit.jar. Now all of your Ant scripts will know how to do the <junit> Ant task.

I moved the Recent Comments section to the bottom of the left column so that they wouldn’t unreasonably stretch the middle column.

You definitely can’t think of all of the ways people can break your software ahead of time … don’t even try, just let them use it.

As someone that has used strongly typed programming languages for most of his short career, I’m finding it hard to grasp the advantages of weakly-typed ones.

Paul Vick makes a good point when he says that generics make strongly typed languages even stronger, and this seems to go straight against the new wave of weakly typed languages like Python and older ones like Smalltalk.

It seems somewhat related to the enabling vs. directing thread that was going around recently. Strongly typed languages direct you down an inflexible path: you may only assign a value of type A to a variable of type A or one of its superclasses or interfaces. Once you do that it may be painful to change the type later in the code because you have to edit all of the types. Weakly typed languages enable agile processes where a value’s type may change often and variables don’t have type. Good unit testing with weakly typed languages prevents programmers from making mistakes with types.

Refactoring support in IDEs like Eclipse digs into this advantage of weak typing though. If I can change the strong type of a variable everywhere in the code with one action then isn’t this the same difficulty as changing a weak type except now I have a more rigid type contract? If the tools enable the same type flexibility as weakly typed languages wouldn’t a strongly typed language be better?

Maybe I need a few examples. I haven’t seen the light yet.

One of the key things no one seemed to tell us about SWT was that it ran in one thread by default. This has the unfortunate side-effect of freezing the GUI completely when you call a lengthy method from an event handler. This may seem like a big duh! to some people but I don’t recall Microsoft Visual Studio GUI event handlers requiring explicit threading. It seems like a definite control versus ease-of-use tradeoff.

This is exactly where a university education falls short: practical information. We covered the basics of threads in second year but even then we only brushed on it briefly, and never with a GUI. When you step in and try to use SWT in a production environment you’re completely clueless. No wonder the application was thrashing so badly, geez. Now because I’m using another thread the GUI is as smooth as silk.

The mutator event listeners that I implemented all cascade on the same thread: from the mutator to the controller to the model to the view when a change is made by a mutator. You want to call the mutator methods in a new thread from a GUI event handler so that the GUI won’t freeze. When the listeners are notified that the mutator made a change when it gets back to the view it throws SWTException because you tried to access/modify the GUI objects from a thread that is not the SWT thread — the same one doing the mutating also notifies and handles the listening.

So the last listener method (which still runs on the mutator thread) in the view has to notify the SWT thread that it wants to make a change. It does this by passing a Runnable object to SWT’s display object
public void itemRemoved(final ModelEvent me)
{
final TableViewer tableViewer = this.viewer;

if (tableViewer != null)
{
display.asyncExec(new Runnable()
{
public void run()
{
tableViewer.remove(me.getItem());
}
}
}
}

Notice the way that Runnable interface’s run() method is implemented inline. The objects that I used in the inline (tableViewer and me) must be final (constants) or the compiler will complain.

There were two separate ways I got around that. First, the me object was passed as a parameter to the listener method that contains this inline object. So I just made the parameter final in the method header. Second, the viewer changes in the object that contains this inline object, so before I make the inline object I just make a new final copy of it to tableViewer and use it instead of the non-final version.

Note that having the asyncExec() call in the view (actually it’s the TableViewer’s content provider) puts all of the SWT code togther in the user interface, rather than having some below it the GUI talking to the SWT thread which would increase coupling by putting SWT objects in the application code.

If you want to see how I implemented threading in AudioMan, it’s in the CVS repository under the project AudioManPoint2. There are all kinds of race conditions now because methods that should be synchronized, especially in the repository, aren’t yet. I’ll be working on that this week — I just wanted to see if the asyncExec() call worked, and it does.

I took my hands off Eclipse for a bit and thought about AudioMan’s architecture, specifically the Data Abstraction Layer (DAL) and wrote up a whole section on it. I grouped the methods of the DAL package into classes so that they are easier to manage/isolate, instead of having one large singleton class. I definitely welcome your comments.

The key to the new Data Abstraction Layer is the notion of models and mutators. A model is a bunch of data that the user interface displays in views and mutators are functions that change the models.

AudioMan is a bit more complex because the mutators don’t actually change the models directly, they change the repository and the files. When the repository changes the models are updated indirectly. As well the files can be modified outside of AudioMan so when the models are refreshed the files have to be checked. Add formatting to that and you have my brain turning to mush until I forced myself to write it all down. Now it looks pretty manageable.

Warning label (complete with symbol!) on a bottle of Stewart’s Orange N’Cream Soda:

CONTENTS UNDER PRESSURE. BOTTLE MAY BURST OR CAP MAY BLOW OFF CAUSING EYE OR OTHER SERIOUS INJURY. POINT AWAY FROM FACE OR PEOPLE, ESPECIALLY WHILE OPENING.

I don’t know how they expect you to drink the thing …

I guess I’m going to have to get used to wearing jewelry. 🙂 The Iron Ring ceremony was last night and I have a pinky ring on my left hand. For those that don’t know, engineers in Canada wear the ring to symbolize their obligations to the engineering profession and to society.

The ceremony made me reflect about what it means to be an engineer in the software industry. I think our project management professor said it best when he compared software engineering to early civil engineering. A lot of bridges fell down for hundreds of years but over time things matured. For better or worse, they don’t make us stand under our “bridges” any more when the first heavy load passes over them.

So even though our lives are safe these days, software engineers shouldn’t fall back on the fact that the profession is new as an excuse to make poor software. Like the civil engineering profession did, they should continue to improve the quality of the software they write and the processes they use to write it.

I’m liking the blog w/ MiniBlog format. Like I was saying to Jim the other day, it lets me post the articles and media stuff that I like while keeping my main blog free of short posts. As you can see most of my recent blog posts have been a few paragraphs long and that’s definitely an inprovement.

I took the bold date titles out and the MiniBlog doesn’t dominate the eye like it used to. It’s just a little less dominant than the main blog, which is good.

I’ve noticed not a lot of people are commenting on the MiniBlog though — maybe because people didn’t know that the [0]’s were comment counts. That’s understandable because it’s not a very good visual cue but I’m pretty real estate-limited with what I can put in there. I added a title attribute to the comment links to give a tooltip but it’s still not that great. What I’d like to do more is make a MiniBlog post and then make the first comment myself, which may help start discussion like regular blog posts do.

Update 13:11 You’re right Jim, it does look a lot better on a CRT. Outside of changing my colour scheme to something with more contrast I don’t really know what I can do about that. 🙂 I will make sure that the text is readable even if the table boundaries aren’t visable.

Being mainly a Java/Eclipse developer I’m finding it quite hard to move to .NET/C#. You see, Eclipse has spoiled me and given me all of these wonderful features that I can’t get in Visual Studio .NET. I’m wondering why I ever wasted my time hand-editing my code all of these years. Here’s the run-down on my issues:

1. C# is Java. There, I said it. It’s Java with different words and some extra stuff like Properties. Everything is the same but named differently. How convenient. It’s a lot like the difference between C# and VB.NET but a little more so. The upside is that I get to say I know two languages for the price of one and a half.

2. Refactoring. Holy crap, I’m screwed. I can’t use an IDE without refactoring any more — I get completely frustrated. “What do you mean I have to change the name of this function myself in all of these files??” Global search and replace? Ick.

3. Code Indenting. The Eclipse indenting isn’t perfect either but at least it doesn’t trip over itself when you go one line too far down and go back up. Oops.

4. Code Completion. Right in there with indenting. Give me the end bracket/brace, damnit! I don’t want to type it.

5. Code compiling. Compile my code as I write it so I can see mistakes, please. I hate recompiling my project every single time I want to check for errors. I’m not typo-free (or else I’d be a secretary).

6. Unit testing tool integration. For the love of Pete help those poor NUnit saps put unit testing right in Visual Studio. Why do I have to switch back and forth between apps and find the compiled executable I want to test. Integration integration integration. It’s all about saving small increments of time (remember time motion studies?) … if I have to switch 200 times a day between apps and that takes 5 seconds, there’s 4000 seconds! Six and a half minutes and a hundred times more frustration.

7. CVS integration. How can a modern IDE survive without code repository integration? … and I’m not talking about Visual Source Safe here, CVS is the minimum. Eclipse’s CVS integration is beautiful. Copy it. Please.

That’s it for now … believe me, there will be more. I’m kind of exaggerating my exasperation for comedic (maybe?) effect but only a little bit. It’s a seriously sad situation here.

If you know how to solve any of these problems, let me know! I’m using the original version of VS.NET (2001, I guess).

I’m tempted to go into detail how the blackout affected this technophile’s life but … it didn’t. I decided to desert my home province for the electricity of Quebec. I’ve been to Montreal a few times but never in a situation where I could do what I wanted (twice with parents and the other time with a drunken bus tour, but that’s another blog … so my friend and I walked up and down St. Catharine Street waiting for the concert to start …

… oh I didn’t mention the concert? Radiohead at Parc Jean Drapeau!! After going to see Red Hot Chili Peppers in May, this concert was a lot different. To be fair it was an outdoor concert so I should have expected it to be more like Lollapalooza or something.

Before the concert they played a rock-reggae blend band from CD I’d never heard before. Stephen Malkmus and the Jicks was the sole opening act. They were alright, nothing too special or original, so I don’t have much to say about them. 🙂 It was hard to see the stage, because the sun was setting right behind it so I mostly just listened.

Half the crowd wandered around until Radiohead came on. A lot of pot was smoked, which wasn’t a big surprise I guess … you could see wafts of it coming off the crowd … we drove home that night reeking of pot and we didn’t smoke.

Unlike Lollapalooza, there were no beer tents. Beer was served in the audience and everywhere courtesy of our friends at Molson. Not too many people were drunk either. The typical Radiohead crowd isn’t going to get into a drunken riot like say, hmmmm, a drunken Limp Bizkit crowd. So I guess no one was worried about it.

Radiohead came on about 8 o’clock and started out playing songs from the new album (see the set list). The newer songs were faithful to the album versions, which was kind of disappointing … I like to see some creativity on live versions. However, the way that the album was recorded (quickly and less-produced than Kid A or Amnesiac) meant that the songs sound more like the live versions they practised before recording I guess. They have years to improvise the new songs.

The older songs they played were improvised mostly by Thom and Johnny. Thom’s dancing was incredible — he has so much energy on stage. Sometimes it was full out dancing and other times it was gyrating at the mic or his patented head-bobbing. Johnny went into some wildly improvised solos with strange guitar effects. The other guys even cut Johnny off, when he soloed too long — which started the crowd chanting Johnny’s name in appreciation.

They used looping a few times to create backgrounds sounds. At the start of the song Thom would sing a few words into the mic and they’d be mixed (sometimes unrecognizably) into the background of the song, like you’re watching/hearing the song being “assembled”.

My favourite song of the night was an up-tempo version of “Everything is in Its Right Place” during the second encore. Before that, the crowd sang the chorus to Karma Police so well (and loud) that Thom decided to sing the chorus again a capella with the audience, which was cool.

The crowd never got wild, even in front of the stage during songs like 2+2=5 or Just. They were mostly subdued and relaxed … but I guess that’s the typical Radiohead fan for ya. Half of the concert was slower stuff from HTTT, Kid A and Amnesiac. Don’t get me wrong, I didn’t expect people to go crazy … it was just different from other concerts I’ve been to.

So it was definitely worth the money — a jolly good show. The t-shirts at 40 bucks a pop were not though. I will definitely see them again …. maybe they will come to Ottawa next tour.