Heikki Uljas

Most efficient way

2013-11-25T00:00:00-08:00

The most efficient way to implement something is to realize that you don’t have to.

You could ask the “Why?” question and figure out that something is not needed at all.

Or you could find out that there already exists a solution for you problem.

Formatting in play scala templates

2013-08-06T00:00:00-07:00

While play1.x had rich support for formatting with javaextensions in play2 we rely on what scala language can provide us.

Formatting numbers

Probably the most convenient way to format numbers is to use the scala Strings format

@* left padding zeroes *@
@("%03d".format(7))

@* leading spaces *@
[@("% 4d".format(11))]

@* with 2 decimals *@
@("%.2f".format(1123.345566))

@* with locale *@
@("%.2f".formatLocal(Locale.US, 1123.345566))

generates

Formatting dates

format also works with dates

@* just time *@
@("%tT".format(1312180002230L))

@* date *@
@("%tF".format(1312180002230L))

@* date and time *@
@("%1$tH:%1$tM:%1$tS.%1$tL %1$tY.%1$tm.%1$td".format(1312180002231L))

converts our timestamp to

09:26:42

2011-08-01

09:26:42.231 2011.08.01

Formatting strings

For string formatting we use the functional power of scala

@* lower case *@
@("AbC".toLowerCase)

@* upper case *@
@("aBc".toUpperCase)

@* capitalize *@
@("abc".capitalize)

@* capitalize each word *@
@("The quick brown FOX jumps over the lazy dog"
    .split(" ")
    .map(_.toLowerCase.capitalize)
    .mkString(" "))

converts them to

abc
ABC
Abc
The Quick Brown Fox Jumps Over The Lazy Dog

Searching for the perfect DAO pattern

2013-06-07T00:00:00-07:00

I really liked the way the database access was simplified to static methods in the data object in Play framework version 1.x:

MyModel found = MyModel.findById(id);

I wanted to achieve something similar in my current project. My starting point was a common helper class which contained the database specific implementation:

class DatabaseHelper {
    public static <T> findById(String id, Class<T> type) {...}
}

MyModel found = DatabaseHelper.findById(id, MyModel.class);

Static methods

My first attempt was a base class with static methods:

class BaseModel {
    public static BaseModel findById(String id) {
        return DatabaseHelper.findById(id, getType());
    }
}

So now I would only have to implement the getType with reflection and be done with it. Well easier said than done. Since the static context of the base class has no knowledge of the implementing class I have no way of getting that class with reflection. In play 1.x this was done with runtime code generation which I don’t want to use because of its drawbacks.

Okay so maybe I could use generics somehow?

class BaseModel<T extends BaseModel> {
    public static T findById(String id) {
        return DatabaseHelper.findById(id, getType());
    }
}

Well this doesn’t even compile because the type variable T cannot be accessed from the static context since it has no knowledge of the actual instance of the class defining the type argument.

Normal base class

Since static methods are out of the question what could we do with a base class with non-static methods?

class BaseModel {
    public BaseModel findById(String id) {
        return DatabaseHelper.findById(id, getClass());
    }
}

class MyModel extends BaseModel {}

MyModel found = (MyModel) new MyModel().findById(id);

We can get rid of the cast with generics

class BaseModel<T extends BaseModel> {
    public T findById(String id) {
        return DatabaseHelper.findById(id, getClass());
    }
}

class MyModel extends BaseModel {}

MyModel found = new MyModel().findById(id);

Sort of there but I still don’t want to create a new instance of my model.

Encapsulation to the rescue

Okay so since direct inheritance is out of the question maybe we could use encapsulation somehow?

class BaseModel {}

class BaseDAO<T extends BaseModel> {

    private final Class<T> type;

    public BaseDAO(Class<T> type) {
        this.type=type;
    }

    public Class<T> getType() {
        return type;
    }

    public T findById(String id) {
        return DatabaseHelper.findById(id, type);
    }
}

class MyModel extends BaseModel {
    public static final BaseDAO<MyModel> DAO = new BaseDao<>(MyModel.class);
}

MyModel found = MyModel.DAO.findById(id);

For a finishing touch lets get rid of type parameter with some reflection:

class BaseDAO<T extends BaseModel> {

    public BaseDAO() {
        this.type = (Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
    }

}

class MyModel extends BaseModel {
    public static final BaseDAO<MyModel> DAO = new BaseDao<>();
}

And with this and some code in our class we get what we wanted:

class MyModel extends BaseModel {
    private static final BaseDAO<MyModel> DAO = new BaseDao<>();

    public static MyModel findById(String id) {return DAO.findById(id);}
}

MyModel found = MyModel.findById(id);

Happiness!

New start, new layout

2013-04-26T00:00:00-07:00

So after a year I’m starting to write my blog again. A lot has happened since my last post: new exiting job at Rovio, learned new stuff and gained some weight ;).

And what better way to start than with a fresh layout!

Well it’s just the jekyll bootstrap default one, but I can’t be arsed to do any design now so it’ll have to do!

Little unzip utility - In Java

2012-03-30T00:00:00-07:00

It’s always fun when you bump into a problem you haven’t encountered before.

This time I had a database dump file that was so large that I had to zip it. And since I wanted to unzip it in Java I had to find out how it’s done.

Well it turned out to be pretty straight forward, here’s the gist:

Spring controller monitoring aspect

2012-01-12T00:00:00-08:00

I wanted to monitor our Spring MVC application with Jamon. We rely on the use of the @Controller annotation so aspects seemed like the right way to go.

After some digging on the documentation I came up with the following aspect:

Now I just needed to enable autoproxying with

<aop:aspectj-autoproxy />

line in my application context file and all my controllers started showing in Jamon!

Unshredder challenge part 2

2011-12-06T00:00:00-08:00

After my first solution to unshredder challenge I started working on the bonus part of the problem: auto-detecting how wide the uniform slices are.

My plan was pretty simple:

for each vertical column of pixels X[i]
    calculate distance D[i] = distance(X[i], X[i+1]
Dmax = sort D desc
for each slice width W
    M = number of borders with slice width *W*
    P = number of borders in the first *M* elements of Dmax with slice width *W*
    return w with max(P / M)

The plan worked otherwise great except that slice width 256 (2 slices) maximized my P / M. I fixed that by returning the first W that exceeds a given threshold.

The result is the following python code:

Links

sources

Unshredder challenge

2011-11-16T00:00:00-08:00

My good friend +Zsolt Szasz challenged me to the unshredder challenge. I decided to try something different this time and solve the problem using python.

Setting up

So my first task was to setup python and the PIL image library on my windows machine. I had python installed but the PIL installer couldn’t find it, so I had reinstall python. After that I did a quick check:

>>> from PIL import Image
>>> quit()

No errors so I was ready to go!

Learning python as you code

I had used python a bit earlier but honestly too little. So this was a nice chance to learn some more. Luckily they had some sample code to get started with.

After fixing some syntax issues from my copy-paste, I had a the example program running and producing the image seen below!

First solution

It took me 2-3 hours to get the image unshredded.

I used the nice python tutorial a lot and getting used to the syntax took a while (no semicolons! no curly braces!). But I found python to be really easy and powerful language!

Here’s the solution, not very elegant but pretty readable IMO ;).

Better solution

I have updated my solution with a solution to the bonus challenge.

Links

sources

Facebook cookie server side authentication

2011-11-15T00:00:00-08:00

In this example I show how to validate a user’s facebook session in the server side using the fbsr cookie created by the FB javascript API.

I use the following, basic html to initialize the login button.

The facebook login will in this case create a cookie named fbsr_[your facebook application id] which is in the form of signed request consisting of two parts:

[mac sha256 signature].[base64 url encoded json]

Now I can validate the cookie on server side by signing the second part of the cookie with my facebook secret and making sure that it matches to the first part. To get the json data I just have to json decode the second part of the cookie.

Here’s code that I use to do it in Java:

So now we have json object in the format of:

{ 
  "algorithm" : "HMAC-SHA256",
  "code" : "2.AQDC1d-ZE90999-6.3600.1321387200.1-676786217|X1VAtqRDS_3NR6lduKISj50Uozw", 
  "issued_at" : 1321381928, 
  "user_id" : "12345678"
}

In order to get the access token, we need to request from the graph api using the following request:

https://graph.facebook.com/oauth/access_token?
client_id=[facebook application id]
&redirect_uri=
&client_secret=[application secret]
&code=[code from the json]

Note that you need to include an empty redirect_uri parameter in the request for it to work. From the response you get the actual access token, which you can use to get more information about the user.

You can find a simple example application here.

Drive by performance testing

2011-11-08T00:00:00-08:00

Typically the performance tests are run by a specialist who runs his tests for a day, sends his report and then drives away. And you, the poor developer are left with a plot chart illustrating some weird performance issue you haven’t the slightest idea what is causing it.

Now it doesn’t have to be like that. Just be prepared!

Use performance monitoring in your code

Add measurement into the important parts of your code and enable seeing the reports in runtime. I have used Jamon in Java development with great success.

Run your own performance tests

By running your own tests you can fix all the silly mistakes before the official tests are run. Focus on covering the critical parts of your application.

Participate in the official performance testing

If you have proper monitoring in place you should be able to analyze and fix the issues as they are found. It is also the only way to analyze the really weird ones.

Fun with javascript and canvas

2011-10-15T00:00:00-07:00

I had this crazy idea of putting some canvas animation into the layout of this new site. The idea didn’t fly, but I managed to create this quite nice animation of stars:

Here’s the code:

Blogging in github is like writing code

2011-10-15T00:00:00-07:00

My old blog with it’s text area bound interface felt really disconnected from the code related topics I wanted to write about. But this git thing feels already much more natural, it feels like writing code. Or perhaps it’s because I’m doing this in vi. ;)

Managing database with play carbonate

2011-04-04T00:00:00-07:00

Managing the database is important aspect of modern application development, typically done with database migrations. I used migrations before I started working with play so naturally the first module I wrote for it was a database migrations module with my favorite migrations library, Carbon Five Migrations.

The initial version of the module was really basic and after a twenty or so models created and equal amount of copy-pasted create table statements I got this idea of updating my module with the Hibernate schema update. And the result is the play-carbonate module.

Remember that the schema update is just a tool. Always check the SQL it generates!

Setting up

To add this module as dependency of your application, add it to the dependencies.yml file:

require:
    - play -> carbonate {version}

Next configure the database and add the carbonate path in to the application.conf file, I am using play id local-mysql and database play-test:

%local-mysql.db=
%local-mysql.db.url=jdbc:mysql://localhost:3306/play-test
%local-mysql.db.driver=com.mysql.jdbc.Driver
%local-mysql.db.user=root
%local-mysql.db.pass=
%local-mysql.jpa.ddl=none
%local-mysql.carbonate.path=conf/migrations

Now our carbonate module is configured and ready to use.

Usage example

Now lets consider a simple model shown below

We run the the following play command with our play id local-mysql to generate a new migration file under the conf/migrations folder:

play carbonate:new --%local-mysql
Please give description for you migration:
simple model
21:00:18,136 WARN  ~ Changes from schema update:
create table SimpleEntity (id bigint not null auto_increment, age integer not null, isEternal bit not null, name varchar(255), primary key (id)) ENGINE=InnoDB DEFAULT CHARSET=utf8;
21:00:18,138 WARN  ~ New migration file created ~/code/test-app/conf/migrations/20110404220338_simple_model.sql

Now we can check the generated file

To run the migration we just start our play application:

play run --%local-mysql
22:08:20,709 INFO  ~ Running migrations from path conf/migrations
22:08:20,757 INFO  ~ Migrating database... applying 1 migration.
22:08:20,758 INFO  ~ Running migration 20110404220338_simple_model.sql.
22:08:20,812 INFO  ~ Migrated database in 0:00:00.250.

Now we want to change our model and add a SimpleCategory to our model:

So after the change we run the command again

play carbonate:new --%local-mysql

ending up with a migration looking like this:

Note that errors in migrations are easier to manage if you split every SQL statement to its own migration file.

To apply the migration we just run our application again:

play run --%local-mysql
22:19:28,016 INFO  ~ Running migrations from path conf/migrations
22:19:28,058 INFO  ~ Migrating database... applying 1 migration.
22:19:28,059 INFO  ~ Running migration 20110404221245_added_category_for_the_entity.sql.
22:19:28,439 INFO  ~ Migrated database in 0:00:00.380.

Localizing your play application with @messages

2011-04-01T00:00:00-07:00

I wrote this module to help me with the localization of our application. I used to have similar tool in our old struts based system, so I first copied it to play and later rewrote it all together. I even forced myself to learn regexp, which I have been trying to avoid so far ;).

Setting up

To add this module as dependency of your application, add it to the dependencies.yml file:

require:
    - play -> carbonate {version}

Then you need to add the module routes to your application conf/routes file:

   *    /    module:messages

Now once you restart your application you can access the tool at http://localhost:9000/@messages

Example 1: Managing existing keys

This is the tab where you can modify the existing keys, keys that are found in sources and messages. Header section has selection for the language to edit and another for the language to compare to. Keys can be removed by checking the remove check box.

The keep check box is reserved for valid keys that the tool doesn’t find in the sources, for example keys that are generated in code.

Example 2: Localizing new keys

New keys are those keys that are found in the sources but are not yet localized in the messages file for the selected language.

Since we are not sure about the first key we click on the key to check the sources. From the sources we can see that this key is in fact part of a generated key. We choose to ignore this key, meaning that it will no longer be shown in the new keys list in any language.

After save we can find the key in the ignored keys section. Ignored keys are saved in the messages.ignore file.

Example 3: Separating generated keys from obsolete keys

Obsolete keys are those keys that are in the messages file, but cannot be found in the sources.

We mark keys that are valid with the keep check box. These keys will be added to the keep list and will be displayed among the existing keys. The keep list is saved in messages.keep file.

Keys that are old can be removed by checking the remove check box.

References

You can find the sources at github here https://github.com/huljas/play-messages.