The point is missed

Museum of public mistakes and unfinished projects

Poju4s – an attempt to make JUnit a bit more Scala friendly

leave a comment »

Recently I felt like going back to basics of testing in Scala. There are some fine testing frameworks for Scala that I recommend that you use. Never the less I started thinking about what it would be like to make JUnit more Scala-friendly rather than rolling an entire new framework. Since I came down with the flu anyway I had some time when I was neither unconscious nor watching movies when I could toy with the idea. Long story short: I started the poju4s project on github here.

Poju4s obviously stands for “Plain old JUnit for Scala”

It is not much yet and it has some distance to go before being really useful but I think a few sparks of elegance have found their way into the code (or that is just the fever talking). Anyway, before I understand better than to make this stuff public. Without further due… here it is for what its worth:

Read the rest of this entry »

Written by johlrogge

March 11, 2011 at 4:52 pm

Posted in junit, poju4s, repl, scala

Tagged with , , ,

Why I don’t like Maven

with 15 comments

More than two months ago I tweeted something like “As if this day didn’t already suck Maven 3 was released”. I got a reply from @kirean73 “Mind sharing your experiences with Maven?”. Fair question. As it takes more than 140 characters I decided to write a blog-post about it. And since I did not have time to do it there and then I asked @kirean73 to remind me after a month had passed. A month ago I got the reminder but this post turned out to be really hard to write. Mostly because there is nothing seriously wrong with Maven…

I’ve been looking forward to write this post for some time. I really don’t like Maven but I realized that I don’t exactly know why. It will be useful to explore that. I don’t want this to be just another of the many maven rants out there. I’ll try to be fair but I also reserve the right not to think that some things are good  even if I can’t present a better alternative :) This is a subjective post.

Read the rest of this entry »

Written by johlrogge

December 14, 2010 at 7:22 pm

Posted in build tools, java, PMS

Tagged with , , ,

There are no best practices

with 4 comments

Last week I had a good retweet day. As always when that happens, I said something cocky and over-simplified. I blame 140 characters; the perfect excuse to simplify things to become more edgy. This time the tweet was:

I hate best practice. If you follow best practice you will end up with Maven, SVN and programming in java (the language) #rest_my_case

I was promptly corrected by @jchyip (Jason Yip):

@johlrogge That’s equating “common practice” to “best practice” which is a very common failure mode. Popularity != best option.

He couldn’t be more right. In fact, I have often felt that what is marketed as best practice is often common practice with a more attractive label. The two are confused a lot. It sort of makes sense too, I mean – if everyone is doing it, it must work. Right? If it wasn’t the best then why would everyone do it? Granted it will probably work just fine, but will probably not be the best, so don’t call it that. Assuming that excellent software development is rare, then best practices should also be pretty uncommon. Given this, you probably shouldn’t be doing what everyone else is doing, if you are going for “best”.

Read the rest of this entry »

Written by johlrogge

July 22, 2010 at 6:28 pm

Posted in Agile, methods

Loggingtools in Scala

with 20 comments

UPDATE: As John pointed out in the comments the trait did not really work as expected. I updated it with the code I actually have in my project. How I ended up posting a different thing on my blog I don’t know but it sort of has to be me :). This code is tested with slf4j-api-1.5.0. I think some newer version makes it possible to do this without the temporary objects involved in the form of arrays. I will look into that later.

My pet-project is becoming more and more Scalafied and I’m starting to wonder why I ever thought it was important that I should be able to use it from java-applications. Given my detachment from Java some mental barriers are falling and I am adding new strategies to my active toolbox. Today I created some simple traits that I thought would be worth exploring in a blog.

Here we go, logging with slf4j is something I’ve done a lot. I found myself sprinkling a lot of this around in my code:

import org.slf4j.{Logger, LoggerFactory}
...
class SomeClass {
   private val log = LoggerFactory.getLogger(getClass)
   def aMethodThatLogs  {
      log.debug("This is a value: {}", 4711)
   }
}

Nothing new (unless you never saw slf4j before in which case you should check it out now wether you program in Scala or Java. The code so far is not dependent on scala other than syntax-wise.)

What I keep forgetting about

Scala has traits, it’s easy to forget that traits are more than just interfaces. Over the years I’ve gotten pretty used to not being able to add any generic functionality other than via composition or inheritance.

Thinking out of the java-box I created this little trait:

import org.slf4j.{Logger, LoggerFactory}

trait Log {
 private val log = LoggerFactory.getLogger(getClass)

 def trace(message:String, values:Any*) = 
     log.trace(message, values.map(_.asInstanceOf[Object]).toArray)
 def trace(message:String, error:Throwable) = log.trace(message, error)
 def trace(message:String, error:Throwable, values:Any*) = 
     log.trace(message, error, values.map(_.asInstanceOf[Object]).toArray)

 def debug(message:String, values:Any*) = 
     log.debug(message, values.map(_.asInstanceOf[Object]).toArray)
 def debug(message:String, error:Throwable) = log.debug(message, error)
 def debug(message:String, error:Throwable, values:Any*) = 
     log.debug(message, error, values.map(_.asInstanceOf[Object]).toArray)

 def info(message:String, values:Any*) = 
     log.info(message, values.map(_.asInstanceOf[Object]).toArray)
 def info(message:String, error:Throwable) = log.info(message, error)
 def info(message:String, error:Throwable, values:Any*) = 
     log.info(message, error, values.map(_.asInstanceOf[Object]).toArray)

 def warn(message:String, values:Any*) = 
     log.warn(message, values.map(_.asInstanceOf[Object]).toArray)
 def warn(message:String, error:Throwable) = log.warn(message, error)
 def warn(message:String, error:Throwable, values:Any*) = 
     log.warn(message, error, values.map(_.asInstanceOf[Object]).toArray)

 def error(message:String, values:Any*) = 
     log.error(message, values.map(_.asInstanceOf[Object]).toArray)
 def error(message:String, error:Throwable) = log.error(message, error)
 def error(message:String, error:Throwable, values:Any*) = 
     log.error(message, error, values.map(_.asInstanceOf[Object]).toArray)
}

Using it is now a matter of:

import johlrogge.Logging
...
class SomeClass extends Object with Logging {
   def aMethodThatLogs  {
      debug("This is a value: {}", 4711)
   }
}

It’s not a huge difference but I kind of like the with Logging and the lack of boilerplate code in the class-body.
I also like that I can drop the log. part of the logging.

Traits are on the menu

Of course this my wetted my appetite for traits. And it didn’t take long before an opportunity arose. How often have you written code like this in java:

long startTime = System.currentTimeMillis();
AValue value = doSomethingTimeConsuming(parameter);
log.debug("SomethingTimeConsuming took {}ms to complete", System.currentTimeMillis()-startTime);
return value;

I was about to repeat the process in Scala when I thought: function… pass by name… and then… TRAIT!

To make a long story short: Enter Timing:

trait Timing {
  def time[T, R](f: => T, res:(T, Long) => R):R = {
    val startTime = System.currentTimeMillis
    res(f, System.currentTimeMillis - startTime)
  }
}

How this beast came to be:

  1. I realized that the timing-code in the java-example could measure anything given that anything given that anything was executable. And thats what pass by name is for.
  2. I realized that sometimes you want to have the timed value, sometimes you want to log it as a side effect. So, a second pass by name function made sense. The res-function that takes the timing-value and does whatever it likes with it.
  3. You may want to return the timervalue, the result of the timed function, both or something completely different. So I made the result type generic and different from the result-type of the timed function.

How to use it:

import johlrogge.Logging
...
class SomeClass extends Object with Logging
                               with Timing {
   def aMethodThatTimesAndReturns =  {
      time(timeConsumingMethod(4711),
              debugMs("The timeConsumingMethod generated {} in {}ms", _:SomeValue, _))
   }

   def debugMs[T](message:String, result:T, spent:Long):T = {
    debug(message, result, spent)
    result
  }

   def timeConsumingMethod(interval:Int):SomeValue =  {
       Thread.sleep(interval);
       new SomeValue
   }
}

Pretty neat. Of course you can compose all kinds of pre-packaged res-methods. The point is that time becomes reusable and you don’t have to log. You could for instance update and return a data-set for a graph that you’re plotting somewhere else in your code. We have abstracted away timing.

Just so you know

If I would mind that anyone cut and pasted the code I wrote in this post and even make money from it (like thats going to happen) I wouldn’t post it on the net. I hope that the code is useful and/or inspires someone in some way. So use it however you want and have fun!

Written by johlrogge

June 27, 2009 at 5:20 pm

Posted in scala

Tagged with , ,

Do you dampen or amplify?

leave a comment »

Today I rediscovered a thought I had months ago and forgot about. I was talking to a team-member about software development in general and frameworks  and processes in particular. What I’m about to write is just a theory and a thought model that seems useful to me. If you are looking for hard facts then this post is not for you (sorry).

I have this idea that all practices we apply are somewhere on a scale from dampening to amplifying. Did I hear a WTF? I’ll try to explain…

Read the rest of this entry »

Written by johlrogge

March 30, 2009 at 9:45 pm

Posted in Uncategorized

More Scala and SWT

with 3 comments

In general when you have a good idea you’re not alone. I started getting traffic from another blog. Dave Orme has developed an interesting framework: XScalaWT. According to the acknowledgements in his blog he found some of my ideas useful to his framework. I haven’t tried it yet, it looks similar to my DSL but his framework is much more complete and he solved the interaction part too. Check it out, it looks very promising!

Also, to my great surprise someone uploaded my source to github here. There is even a Maven pom now to build and run the thing.

I thought I’d share the links since the showed up in my statistics. Enjoy :)

Update: Randin pointed out that the link to xscalawt was broken so I changed the destination. Also Randin thought this link seemed interestong so I provide it here aswell.

Written by johlrogge

February 26, 2009 at 10:13 pm

Posted in scala, SWT

Buy me a Beer :)

with 11 comments

/*
 * The file is licenced under Revision 42 of the Beerware Licence.
 * <joakim.ohlrogge[at]agical.com> wrote this file. As long as you retain this
 * notice you can do whatever you want with this stuff. If we meet some day,
 * and you think this stuff is worth it, you can buy me a beer in return.
 * -- Joakim Ohlrogge
 */

Read the rest of this entry »

Written by johlrogge

January 28, 2009 at 10:29 pm

Posted in scala, SWT

Tagged with ,

Follow

Get every new post delivered to your Inbox.