If you're interested in functional programming, you might also want to checkout my second blog which i'm actively working on!!

Monday, March 29, 2010

Scala traits

Let us first step back and look into Java interfaces. A Java interface typically is defined as a thin interface, meaning it only describes the minimal required methods to get the work done. The main reason is that the more methods an interface defines, the heavier the burden becomes for the implementer of that interface.

The real issue though is that in Java an interface itself can't provide any concrete implementation.

Let me explain this by a concrete example.



You should agree that isLast() could easily be derived using hasNext().

In java we cannot put actual implementation code in the interface all concrete classes implementing this interface need to do so or extend from a abstract class which implements isLast().

Scala traits are comparable to java interfaces. They describe methods which an object should implement but they can provide concrete implementations themselves.


So in scala the best practice is to write only a few ABSTRACT methods and enrich the interface with a lot of concrete methods implemented based upon these abstract methods.

Like a Java interface a Scala trait can also have NO constructor parameters. In Java a class can implement multiple interfaces using the 'implements' keyword. An interface itself can extend 1 other interfaces using the 'extends' keyword.

In Scala you can extend a Trait using the 'extends' keyword. This would mean you also implicitly inherit from the trait's superclass. But you could also mix-in the trait using the 'with' keyword.

A nice example of implementing a very thin abstract interface (toXML and fromXML) extended with concrete rich interface methods is shown below.






The output on my console:


Another big advantage is that traits are stackable through linearization used by the scala compiler.

... TODO: workout some examples

Friday, March 26, 2010

the beauty of control abstractions in SCALA - part 3

This time i decided to test out SCALA's xml API... again it's pretty impressive how easy it is to save or load xml.

For testing purpose i made modifications to 'FileComponent.scala' and 'TreeComponent.scala'. I added 2 methods:
- toXML
- saveAsXML

TreeComponent.scala



FileComponent.scala


FileComponentTest.scala



Output: d:/tmp/filetree.xml

SyntaxHighlighter

Yesterday my blog was unusable during the whole day due to the fact that i'm using hosted files for formatting my code snippets. I really like syntaxhighlighter a lot since it allows me to copy and paste directly in this editor without having to escape ampersands, greather then or less then,....

Anyway... it seems like Alex Gorbatchev made a switch from hosting the source files on a private server to the amazon cloud. So the cloud should in theory be able to upscale and downscale when the request load increases dramatically. Just to be sure however i downloaded a private copy and uploaded them to my google docs account which has 1gigabyte of room left... Next i had to share all individual files and generate the links. But what i actually wanted to share is that if you have a blog and you want to host custom javascript/css files instead of completely polluting your blog master template...this is one way to do it.

Cheers,
Robby Pelssers

Thursday, March 25, 2010

the beauty of control abstractions in SCALA - part 2

Ok... after i got my first sample working i was keen on further abstracting the code.

Thanks to excellent input from Luc Duponcheel and Tony Morris the following code shows how you can further abstract the previous article with the help of implicits.


TraversableComponent.scala:


FileComponent.scala


FileComponentTest.scala


Now the only thing missing is a predicate which will be used to determine if the file should be printed or not....

some use case...
if file-extension is .xml
if filename contains "test"


To be continued....

the beauty of control abstractions in SCALA

I still think it's hard to get a good grip on everything SCALA has to offer but the more I experiment with SCALA, the more excited i get.

Just for fun I wrote a little standalone object named FileUtils. It has 3 methods which respectively print recursively all files/directories, only files or only directories.

If you start coding conventionally you might end up with something like this:



But if you watch closely the methods are practically the same except for the check which is done before i print the file to the console... And because of this i have to call the same method recursively.

It took me a while to understand how control abstractions work but here is the refactored version.




Think of how this will influence your life as a developer... no more unnecessary code duplications because of some minor differences.

Cheers,
Robby

Thursday, March 18, 2010

Creating dynamic watermarks with SVG

My customer wanted to show a watermark which should be dynamically created based on the data (xml) which was processed with xslt. The end result is a nicely styled html page. (see image below).


In order to achieve this result I automatically pulled out my SVG knowledge which would allow me to create images dynamically. Since not all browsers are able to render SVG i used Cocoon's batik block to serialize the svg image to png.

I'll shortly show that this can be easily accomplished with Apache Cocoon 2.2.

First make sure you add following dependencies to your block:




Next in line you will need to create some SVG template for your watermark:


A next step is writing some flowscript function which sets the jx transformer context:


We also need to make some sitemap adjustments:



And finally i need to add the background image dynamically based on content within my stylesheets:



And to finalize the positioning etc i made some css adjustments:

Monday, March 15, 2010

SCALA actors

Threads are still a complex topic to get right in Java due do
-racing conditions
-dead locks
-shared state

Scala borrowed the Actor model from Erlang where messages are send to an Actor and the Actor decides based on the Message send (case) if it will process them

I wrote some simple SCALA classes in order to test Actors.

First i wrote a abstract class Job which implements a execute method.


Next i wrote 2 implementations PrintJob and SumJob which resp.
- prints a string
- print the total of a list of numbers





The JobActor itself handles 3 cases:
-case Any
-Job
-"exit" command



So to finally test the JobActor I wrote a little script which invokes the JobActor with several cases:



The output on my console is as expected:

Monday, March 8, 2010

Creating executable jar file with Maven 2

This article explains very shortly how to create a simple executable jar file using maven2.

First step is to create a new maven project:


Before importing the project into Eclipse we run following command inside the newly created myproject folder:


Now import the project into eclipse and open the pom.xml which will look like


Also the maven archetype already created a App.java whose main method prints "Hello World".

So now it's matter of defining in our manifest that we want to execute the main method of this java class.


First add a new source folder "src/main/resources". Inside this folder create a new folder "META-INF". Inside the META-INF folder create an empty file "MANIFEST.MF".

Make following changes to the pom.xml like below:


Now we can package our jar file from the command line:


Now go into the target folder where you will see the newly created myproject-1.0-SNAPSHOT.jar.

From the command line issue following command:


This will output Hello World! to the console.


However, keep in mind that when your project depends on multiple 3rd party jars, you definitely should take a look at
- maven-assembly-plugin
- maven-shade-plugin