find . -empty -type d | xargs –replace=EMPTYDIR touch “EMPTYDIR/.empty”

This will put an empty file named “.empty” in every empty sub directory from where you’re standing.

Please make sure that you copy the line correctly. There is an double hyphen before xargs’s replace parameter and regular double quotes around the touch argument.

Anyway, this finally pushed me to have a look at alternatives. I’ve been wanting to try out Mercurial for some time now and this pushed me over the edge. My first impression is really good! I obviously have to spend some time getting used to the distributed model, but it seems like it might be worth it. Everything was looking rose red until I figured out that it doesn’t support tracking of empty folders!? It does make sense when I think about their architecture built up around sha1 sums, but I still think that it’s strange. I often create a directory structure before I start coding. The workaround seems to be creating empty files inside each folder, which sounds a little annoying to me.

That’s it for now. Man it felt good to shout and scream a little about Subversion!

Even Grails support is coming along with support for Grails 1.1. Rumors has it that even debugging is supported now! Nice work!

Basically you have three choices when it comes to  embeddable Java LDAP servers (at least open source). First of you have Sun’s OpenDS, they have a page dedicated to Tips and tricks for writing unit tests. I have to say that I’m not very impressed by OpenDS. Don’t take me wrong it might be a fantastic LDAP server, but it certainly does not give me the feeling of being very embeddable! First of all the documentation refers to a mysterious class TestCaseUtils. I’ve checked builds from version 1.0.something to 1.2.something without finding it. The second drawback is that OpenDS is like a flesh-eating-configuration-monster sent back in time to kill the spirit of any developers getting near it. It comes with a 2000+ lines ldif config file, which is supposed to work for servers running embedded as well. It would be nice if they could provide a minimal configuration file for embedded use. To me it complained a lot about errors in the bundled schemas. Oh that’s right you need to set up a directory structure for config files, schemas and locks. Again, not very embeddable!

The second and third choise is ApacheDS. You have the newer version 1.5. with support for fancy things like triggers and stuff and you have the older 1.0 series. Both LDAPv3 compatible. The project is very well documented and they even maintain something they call Apache Directory Studio, which is a graphical LDAP GUI based on Eclipse. Very nice! If you don’t need the fancy stuff implemented in the 1.5 series I really recommend that you go for the older 1.0 series for your unit testing. You’ll find jars in Maven repos and it’s really simple to get started. It just works the way you expect it to! Just follow this guide and you will be unit testing your LDAP code in no time.

At the time I’m writing this 1.5.4 is the newest version of the 1.5 series. They have a guide for doing unit testing with 1.5 as well, but due to some problems it won’t work with 1.5.4 so you’ll have to build the trunk for your self or track down a Maven snapshot repo (good luck!).

Happy testing!

http://www.w3.org/2005/Incubator/emotion/XGR-emotionml-20081120/

You could obviously change your methods access modifier from private. By making it public you’re breaking encapsulation and by making it protected you’re making your API less intuitive. Don’t do that.

Another way to go about this is to create a new class that’s extending the one with your private method

I find the easiest and most convenient way achieve unit testing of private methods is reflection. Some of the features the Java reflection API offers is access to private fields and invocation of private methods. This sounds like something useful for our problem, by using reflection we’re able to test our private methods without making any changes to our classes.

class TestSubject {
 
	/**
	 * For some reason we want to unit-test this method
	 */
	private int adder(int numberOne, int numberTwo) {
		int answer = numberOne + numberTwo;
		return answer;
	}
}

This is the method we want to test, here is how we go around to actually do it:

TestSubject subjectInstance = new TestSubject();
Class testClass = subjectInstance.getClass();
 
// Find the method. getDeclaredMethod will give you any methods from that
// class whether it's public or not where getMethod only will give you
// methods with public access. The first argument is obviously our method's name,
// where the next arguments are the formal types of the adder methods parameters.
Method adderMethod = testClass.getDeclaredMethod("adder", int.class, int.class);
 
// Method is a sub class of AccessibleObject if we don't call it's
// setAccessible method we'll get an IllegalAccessException when we
// try to invoke it on our object.
adderMethod.setAccessible(true); 
 
// Invoke the method on our instance of TestSubject
int answer = (Integer) adderMethod.invoke(subjectInstance, 2, 2); 
 
// assert answer = 4

It’s more or less just to plug it into your testing framework of choice and you’ll have unit testing of your private methods.

But hey! Do you really want to unit test your private methods? Doesn’t it give you that bad feeling in your stomach. You know the feeling you get when you’re code smells a little? I mean, a part of the reason for those methods being private is that they’re subject to change.

It’s the oldest oo rule in the book, hide the inner working of you’re classes so you later can change the inner workings of the class without exposing any change to your clients. What you really want to do is to unit test the public methods using those private once. If you find that difficult it might be a little hint that you should consider changing your design a little in order to improve it’s testability.

Why did I bother showing you how to unit test private methods if I consider it bad practice? Well, sometimes when I’m working on complicated things I like to unit-test private methods while working on the class. And there might be situations where unit testing of private methods is the right way to go. Just be careful so you’re not writing a lot of tests you’ll waste a lot of time maintaining later!

Relevant Java API: Class, Method and reflect.

Happy coding!

By default it draws implementation of interfaces and inheritance and if you add some tags / annotations to your JavaDoc it will draw composition, aggregation, dependencies and navigable relationships as well. There are some undocumented options as well. I’ve used the Netty source code as a reference as it seems to be the project maintainer of Netty that’s behind ApiWiz (shoot me if I’m wrong).

I’m in progress of uncovering some of the undocumented features. If someone knows something I appreciate a comment below.

Example from the Netty project

Update: After digging through the source code (gotta love open source!) I found the documentation missing from the web page! This documentation shows how to add labels to the edges.

apiviz.uses
<FQCN> [<sourceLabel> <targetLabel> [<edgeLabel>]]
 
apiviz.has
<FQCN> [oneway] [<sourceLabel> <targetLabel> [<edgeLabel>]]
 
apiviz.owns
<FQCN> [<sourceLabel> <targetLabel> [<edgeLabel>]]
 
apiviz.composedOf
<FQCN> [<sourceLabel> <targetLabel> [<edgeLabel>]]

FQCN is short for “Fully Qualified Class Name”.

I wanted to know whether it was possible for Hudson to build the project each time someone commits to SVN. It turnes out that there is two possibilities, a) Hudson can poll your version control server or b) you can use subversion hooks to notify Hudson of commits. Since we don’t like polling we’re going for the push method! Ps! I assume that you’ve already configured Hudson to pull updates from your SVN server and build the project.

In your svn repository folder you’ll find a “hooks” folder containing a lot of .tmpl files. As you might have guessed we’re using post-commit.tmpl.  If you’re on Linux create a new file called “post-commit”, make it executable with chmod +x post-commit. Fire up your favourite browser and find the configuration interface for your project inside Hudson. Check the box saying “trigger builds remotely” and write your secret token in the text box. We’re going to need that token when we’re setting up our hook script.

It’s time to edit our post-commit file. I used something like this:

#!/bin/sh
wget -b http://your-hudson-url:8080/job/your-project-name/build?token=your-secret-token > /dev/null

Now after every commit subversion will execute this file and Hudson will build your project automaticly!

Klassiske eksempler fra programvarens verden er Winamp og Nero. Winamp var et meget enkelt program for å spille av mp3′er, en oppgave den utførte meget bra. Da de lanserte versjon 3 med pompøst brukergrensesnitt og mer funksjonalitet mistet de populariteten så godt som over natten. Nero var et program som var veldig bra til å brenne cd plater, akkurat det man forventer av et brenne-program. I det de lanserte oppfølgeren på flere hundre megabyte med “fancy” brukergrensesnitt, lyd og videoredigering, coverdesign og sikkert mye mer sluttet programmet å appellere til de som faktisk brukte det.

Moralen: Aldri velg form over funksjonalitet! En ting, om det er et dataprogram, en bru, en heis eller hva som helst: Det skal gjøre èn ting og den ene tingen skal gjøres bra!

http://www.vg.no/reise/artikkel.php?artid=522394