So, in order to revive this blog a little, I’ve written a thesis… :)

Code of the prototype resides on Github – backend & frontend.

In a nutshell: poster.pdf (presentation slides are available as well)

So long, and thanks for all the fish.

Here’s a little sort of template toy project regarding contemporary JVM-based REST APIs powering HTML5/JS SPAs:
https://github.com/robi42/boot-rest

Built with JDK 8, Spring Boot, Elasticsearch, Jersey 2, Gradle, Yeoman, Bootstrap, AngularJS, fun, and all that jazz…

PS: look ma’, no XML! :)

Update 2015: now with ES6 a.k.a. ES 2015 via JSPM/SystemJS…

Update 2016: these days, “isomorphic” Redux/React is all the rage on the FE side of things…
One may want to check out Este.js & co.
On the BE, Spring Boot’s playing nicely with Kotlin, and Spring MVC’s favourable to JAX-RS, IMHO.

After several years of programming Java while always keeping an eye on alternatives around, I’ve recently come to the conclusion:

Actually, there are just a few things still missing in the language these days which would render me a happy camper™ indeed (enjoying its mature ecosystem of libraries & tools).

Especially, since Lombok takes a lot of the general boilerplate code PITA away here (with useful features like convenient property accessors, hashCode/equals/toString impl., logging facility injection, …).

Also, Guava does a truly good job in enabling one to write more concise and robust code.

Plus, Java 7 brought at least some nice, welcome improvements in
→ try-with-resources, exceptions multicatch, etc.

Finally, modern DI with Spring 4 (or Guice) using javax.inject.* and Java config frees one from most needs for XML and, after all, a build sys beating Maven for real has yet to come.

So namely, here’s a personal wish list FTW:

• Pretty much everything coming up with Java/JDK 8 (sooner than later, hopefully) – particularly lambdas (at last…)
• More type inference (which the JVM is totally capable of); Java 7’s diamond operator’s definitely a good start there but, please, let me write val foos = ... (like in Scala…)
• Collection literals à la Python or C#, something like this would be really sweet:

1
2

     val foo = #{"bar": "baz"};
     foo["bar"] = "qux";

Pretty please. :)

PS: literal multiline strings, and so on and so forth, could be nice (but I can live without).
PPS: wouldn’t say no to optionally named function/constructor args, though.

Update 2016: these days, Kotlin’s the way to go, IMHO. :)

1

$ python -c 'import this'

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea – let’s do more of those!

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

This R&D project which I’ve finished recently is in its essence implementing an innovative way of visualizing Spotify music collection data. It’s mainly geared towards discovery of similar music related to the currently played tracks of a user. Technically, the project partially builds upon the foundation layed out with a previous labs project – here’s a report (PDF). Organisationally, it was done as a cooperation with Spectralmind and the MIR group of Vienna University of Technology.

Implementation

Basically, the app connects to Last.fm data for similarity computation with their (more or less) RESTful web service API via JSONP. In addition to that, Spotify’s desktop client plugin apps JS API is used pretty heavily. The graphics are rendered as interactive SVG through Raphaël.js. Plus, Backbone.js is applied as a mean to improve structure and, consequently, maintainability of the app. For layouting the animated visualization itself a force-directed spring graph algorithm implementation is employed which was orginally written within Google’s Caja project and now adapted + tuned for the specific use case here.

Functionality

In the beginning, the user sees the current track symbolized by a central blue bubble and a loading spinner indicating app activity. Here’s a screenshot:

After that, found similar tracks are arranged as red bubbles in a concentric circle around the central one. Again, a screenshot:

Here’s how the actual animated spring graph layouting visualization initially looks like:

And this is how it can look like when the animation finished rendering:

The history of played tracks is visualized as a diagonal, interactive sort of a time axis which can also be seen here:

Intuitively, clicking on a bubble plays the respective track in the Spotify audio player and triggers a visualization iteration, BTW.

Conclusion

The approach proved to be viable and it can be worthwhile indeed searching and discovering new music fitting to one’s individual taste in an entertaining way with this Spotify plugin app. Nevertheless, there are still numerous details where improvements and enhancements are possible. E.g., the graphics and visualization could be made more pleasant. Apart from that, also further tweaking connected to similarity computation could be done. Yet, as a research prototype demonstrating a proof of concept this is sufficient, it was fun building it, and possibly it’ll show up within a polished product in one way or another. :)

PS & FYI: Spectralmind is currently looking for Android developers – I’d recommend applying since they’re great folks to work with on interesting projects.

Here’re some tips for conveniently generating automated visual app stats from MySQL data.

Recommended toolchain:

• R + RStudio
• RMySQL + ggplot2
• *nix, cron + mailx & co.

Corresponding code bits to get one started:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

#!/usr/bin/Rscript

#install.packages('RMySQL')
#install.packages('ggplot2')

library(RMySQL)
library(ggplot2)
library(grid)


# PNG layout of plots helper.
vplayout <- function(x, y) viewport(layout.pos.row=x, layout.pos.col=y)


# Connect to DB.
dbUsername <- 'some_user'
dbPassword <- 'some_password'
dbName     <- 'app_stats_snapshot'
dbHost     <- 'localhost'

dbConnection <- dbConnect(MySQL(), user=dbUsername, password=dbPassword,
                          dbname=dbName, host=dbHost)


# Exemplary queries.
recordsPerDayQuery <-
  'select date(created_at) as Day, count(*) as Count from records where created_at >= "2012-1-1" and date(created_at) < date(now()) group by Day'

otherRecordsPerDayQuery <-
  'select date(created_at) as Day, count(*) as Count from other_records where created_at >= "2012-1-1" and date(created_at) < date(now()) group by Day'
# ...


# Query data and plot charts.
d1 <- dbGetQuery(dbConnection, recordsPerDayQuery)

xlabText <- '2012'; ylabText <- 'Count'
Records <- d1$Count
heading1 <- 'Records per Day'

plot1 <- qplot(as.Date(d1$Day), d1$Count, geom='line', color=Records,
               main=heading1, xlab=xlabText, ylab=ylabText)

d2 <- dbGetQuery(dbConnection, otherRecordsPerDayQuery)

Other <- d2$Count
heading2 <- 'Other Records per Day'

plot2 <- qplot(as.Date(d2$Day), d2$Count, geom='line', color=Other,
               main=heading2, xlab='2012', ylab='Count')
# ...


# Write data tables to mail text file.
mailTextFilename <- '/path/to/stats-mail.txt'

cat(paste('Hi,\n\n#', heading1, '\n'), file=mailTextFilename)
write.table(d1, file=mailTextFilename, append=TRUE,
            row.names=FALSE, quote=FALSE, sep=' | ')

cat(paste('\n#', heading2, '\n'), file=mailTextFilename, append=TRUE)
write.table(d2, file=mailTextFilename, append=TRUE,
            row.names=FALSE, quote=FALSE, sep=' | ')
# ...


# Make PNG with plotted charts.
png('/path/to/stats.png', width=1024, height=768)

grid.newpage()
pushViewport(viewport(layout=grid.layout(2, 1)))

print(plot1, vp=vplayout(1, 1))
print(plot2, vp=vplayout(2, 1))
# ...

dev.off()

1
2
3

# m h  dom mon dow   command
30 4 * * 1 /path/to/stats.r
0  5 * * 1 mailx -s '[Example] Stats' -a /path/to/stats.png stats@example.com < /path/to/stats-mail.txt

HTH.

Often, when developing a mobile app one wants to target iOS as well as Android (+ maybe MS’ OS).

Now, this basically means developing the app from scratch and consequently maintaining it at least twice on different platforms, written in different languages (Objective-C and Java, that is), using different sets of tools etc.

Cumbersome and potentially error-prone. Well, there’s a viable alternative:

With Xamarin one can write mobile apps targetting iOS and Android in C# using .NET (and native) libraries, sharing code (business logic, data & web service layers, utilities, …) while creating fully native UIs built on each platform’s own SDKs, providing access to all respective device capabilities.

In addition to that, there’s for example MonoTouch.Dialog making it easier and more fun to create table-based iOS UIs and for Android there’s a useful visual UI design tool within the MonoDevelop IDE. Plus, there’s Xamarin.Mobile aimed at exposing an unified API facade for accessing common device features. All interesting stuff when used sensibly.

Here’s some demo code (which is loosely based on samples from the recommendable book “Mobile Development with C#”) showing how mentioned shared layers could benefit:

1
2
3
4
5
6

public class Tweet
{
    public long     Id        { get; set; }
    public DateTime CreatedAt { get; set; }
    public string   Text      { get; set; }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class TwitterApiClient
{
    const string BaseUrl = "https://api.twitter.com/1/statuses/";

    public void DoWithTweetsForUser(string username, Action<IList<Tweet>> callback)
    {
        var webClient = new WebClient();
        var url = string.Format("{0}user_timeline.json?screen_name={1}",
                                BaseUrl, Uri.EscapeUriString(username));

        webClient.DownloadStringCompleted += (sender, e) => {
            var tweets = (from element in JsonValue.Parse(e.Result) as JsonArray
                let tweetData = element as JsonObject
                select new Tweet {
                    Id        = tweetData["id"],
                    CreatedAt = DateTime.ParseExact(tweetData["created_at"],
                                    "ddd MMM dd HH:mm:ss zz00 yyyy", null),
                    Text      = tweetData["text"],
                })
                .ToList();

            callback(tweets);
        };

        webClient.DownloadStringAsync(new Uri(url));
    }
}

1
2
3
4
5
6

var apiClient = new TwitterApiClient();

apiClient.DoWithTweetsForUser("robi42", tweets => {
    foreach (var tweet in tweets) // Just for demo purpose.
        Debug.WriteLine("Tweet from {0}: {1}", tweet.CreatedAt, tweet.Text);
});

And with .NET 4.5’s new async features landing in Monoland soon, related code will get even more convenient to write and handle.

Pretty neat, IMHO. What do you think?

A little project aimed at getting one up and running quickly with building a contemporary web app using Play 2 framework.

Contains a bunch of current web dev best practices and niceties, from latest Twitter Bootstrap (LESS) & Backbone.js to CoffeeScript with CommonJS modules support & proper JS bundling.

Here’re a couple of exemplary code snippets to whet one’s appetite:

1
2
3
4
5
6

{log} = require './utilities'

$(document).ready ->
  window.app = {}
  log 'Hello, world!'
  return

1
2
3
4
5
6
7

object Application extends Controller {

  def index = Action {
    Ok(views.html.index(Messages("app.name")))
  }

}

Get it on GitHub while it’s hot.