In our example we’ll want to unmarshall a Cookie object from it’s string representation, a pretty typical task. In order to do that (for example with JAX-B), we’ll need a Class object we can pass to the deserializer – so it can work all the field mappings etc. Obviously the second example in Java just isn’t enough – we need the Class object, and just using <Cookie> isn’t enough to retain this type information. Scala obviously suffers from the exact same problem as it’s a JVM issue (type erasure, grrr!).

But even so, the above Scala code will work fine if we do some tricks in the method definition. We’ll resort to using:

• a second (implicit) argument list
• Manifest[T]

That’s a bunch of scary looking terms, but it’s actually quite easy. Let’s take a look at the definition of the Scala version of unmarshall.

First, let’s analyze the signature of this method. Obviously it’s parameterized method, thus we need the [T] in front of it. Next is the argument list, with just one argument – str, the string representation we want to unmarshall – easy. Now for the more fun part – the second argument list. Yeah, you can have multiple argument lists in Scala. “Why?”, you ask? For example in our case the second list is implicit – this means that the compiler will figure out and try to fill in these arguments with matching types it finds in scope. In the case of supplying a Manifest[T] it’s fairly easy – it will just create the manifest based on the T type, during runtime at the call site of the method, and pass it into unmarshall.

A Manifest[T] can be thought of like a “better” a Class[_] which contains full type information – so for example we wouldn’t loose the information contained in a List<Cookie> like we would with plain Java (where we would have to hack around this JVM issue via a TypeToken). Anyway, thanks to the Manifest we’re able to get the Class we need to get our unmarshalling done! Manifest.erasure contains the type we need. If you want to read more about Manifest, the ScalaDoc about it does a really nice job explaining how to use it.

— EXTRA for Scala Geeks —

You may have noticed the word “implicitly” appearing from time to time in Scala discussions. It’s a shorthand for accessing shorthand passed implicits. Let me explain this on our example – so instead of the code above we could do the following (which does the same thing):

So instead of creating a second argument list we say that the Type parameter T will be used as a Manifest. And then we can access it via the implicitly magic method. This approach has been made possible since Scala 2.8, due to how often the above pattern was discovered in real life code.
Anyway – it’s up to you which version you like the most.

The case is this: We have a common configuration (a bunch of scala objects) and some helper framework to help us in writing unit tests that integrate with the model. And then there’s the model obviously. If you’d like to allow people to use this test scoped helper framework, if should be in another project (which using maven conventions would usually be called something like “model-testing”) and it would be used as a dependency in the maven project which wanted to test some model related behaviours. The problem with maven here is that it would require us to put those helpers into a new project, and also… put the configuration scala objects into another projects – as they’d need to be shared among the helper utils, the model and all projects using both of them (the details about “why?” are a bit specific to the project, but depending on how it’s structured and how it should work that would be the way to go with maven).

Thank goodness we weren’t unaware of the excticing strengths that sbtr gives us, and instead of creating multiple projects we were able to got away with just exposing the test sources as classpath dependencies for the projects which would need the model. This can be done via:

All the magic is in the second-to-last line. It’s something sbt calls “per-configuration classpath dependencies“. And if explained in layman terms means “i want the classpath used in the lefthand project in the scope X to be used in the right hand project in scope Y“. So in our example we define that we depend on the model project (a Project instance), and declare that it’s compile classpath should be included in OUR compile classpath, and it’s test classpath should be included in our test classpath. You could do the same with “it” (for integration tests) for example… or for any other (so called) “Configuration” defined within sbt.

Using this we were able to avoid creating a “bazzilion” (a number which you can’t count to) of projects to achieve a simple goal – share test helpers. I’m getting more and more excicted about Scala and it’s tooling. As you can see SBT enables you to do some quite expressive and powerful things which would be impossible to do in maven for example. If there is any downside to SBT then it’s that the documentation is a bit chaotic, but the guys are really working on that, so I’m full of hope and optimism about it. :-)

As from what I’ve seen a lot of android apps still get written without dependency injection – which saddens me – static global variables or weird helpers still come up in apps I do security / performance / code quality audits for – so I thought that’s something I need to teach the general audience.

The conference is a 2 day event. Organized by 2 students from Politechnika Krakowska (and a few of their helpers of course), and it’s a free event. We, as Lunar Logic Polska, were proud to be one of the main sponsors of the event. I also personally helped out with a few tips etc, as part of the PolishJUG and KrakówGTUG. We also got some swag from the polish Google office which was a really nice gesture from them… :-) But back to the presentation! Here it is:

You can actually use RIGHT/LEFT and H controls in the above iframe to go through the presentation! Sources for it are available on my github.

From the audiences response etc, it seems that this one has been the cleanest, in the sense of “most fluent” presentation I’ve done up until today. I’ve also went into the code and showed off some minor details. In Intellij IDEA 11 of course – be sure to check it out if you’re an Android (or any kind of) developer! The productivity boost it gives you is “zomg wooot!” ;-)

I also really enjoyed the talks I was able to attend, and met some old (and possibly quite a few new?) friends. Hope to see you all again!

UPDATE!

This post has been awesomely mentioned by @roboguice :-)

UPDATE 2!

An awesome insider tip from within LLP I recieved today:

One guy told me that he was on an Android presentation by some long-haired guy and that it was really good, way better than the rest ;)

Thanks to this you’re able to commit always “refering to” some specific task. Using GitHub and Kanbanery such commits are linked back to the task on the board, which makes code reviews very pleasant :-)

As we’re using Kanbanery in our team, I’ll hopefully have some time and ideas to make this plugin even more useful over time :-) So in case you’re interested just download the plugin from your IntelliJ or head to github to look at the source code or vote for this plugin on it’s site.

Oh… Seems like I forgot to announce that I’ve also released a Android client for Kanbanery :-) Yup, that’s true, so got ahead and check it out if you’d like to. This one still needs some polishing, but the idea is to keep it in one codebase but develop for both, tablets and normal phones, so some things are a little bit tricky :-) I love to use it on my XOOM, but I’ll work hard to make the phone versions as awesome as the tablet one.

Launching application: pl.project13.kanbanery/pl.project13.kanbanery
.ui.activities.InitActivity.

DEVICE SHELL COMMAND: am start -D -n "pl.project13.kanbanery/pl.proj
ect13.kanbanery.ui.activities.InitActivity"

Starting: Intent { cmp=pl.project13.kanbanery/.ui.activities.InitAct
ivity }

java.lang.SecurityException: Permission Denial: starting Intent { flg
=0x10000000 cmp=pl.project13.kanbanery/.ui.activities.InitActivity } from null (pid=13301, uid=2000) not exported from uid 10061

The error is on your side and it’s a super simple one. You have an activity defined two times in your AndroidManifest.xml. Just remove the duplicate to get things rolling again ;-)

First install ruby, gem and god.

apt-get install ruby, rubygems
gem install god

Then paste this initscript into /etc/init.d/god: got init script. Configure it to use /etc/god/config.rb for example, and there do some minor setup (using ruby, yay) so we can get emails if something happenes:

And then all that’s left to implement is a watch, so create an /etc/god/watches/xvbf.rb. It’s using a nice DSL to configure how God should act when a process dies etc:

The code is pretty much self explanatory. We watch if the process Xvfb is running, and if not, after the grace period we restart it. Optional info email could also be sent using the notify property.

That’s it, have fun automating your build environments!

As the Sidewinder is an Microsoft keyboard, it obviously does all it can to not work at it’s full potential on GNU/Linux systems ;-) What my script does is watch for usb events, using usbmon, then it filters it searching for events from this keyboard, and then it filters out the discrete keystrokes for them. When such keystroke is found, we launch an bash script located in actions/S##.sh which can then do anything you want it to do – fire up intellij, or send keystrokes. I’d advice the second idea – use xdotool to send keyboard events, which you then map in Intellij or Netbeans or KDE/GNOME. Such keycode send looks like this:

xdotool key --clearmodifiers ctrl+shift+F1

That’s about it. I also wanted to thank some guys on github, who found my project and it really helped them out :-) Just to cite my fav email:

[...]
I’m amazed to see that somebody made this keyboard work under linux, I was beggining to lose hope. Great job!
[...]

Thanks for the feedback, it’s what keeps me going with opensourceing projects like this :-)

• Scala – the code is 100% scala
• Scala Parser Combinators – the “parser generation DSL” one might say, begind this parser. It’s very very amazing and pushing Scala to it’s best with some crazy implicit conversions flying around all the time :-)
• Scarg – a simple tool for handling command line parameters, it’s on github
• sbt – Simple Build Tool, let’s call it “what maven is for java” but with a Gradle-ish feel to it. A very nice build tool, actually my fav I’d say.
• Scalate – a template engine, which implements Mustache (which I used, as it’s a very clean lang, NO LOGIC in the view :-)) as one of it’s template languages
• and of course ScalaTest – as ‘thou shalt test thy code‘ :-)

It was a very pleasant expirience and I’m looking forward to implementing a 100% compatible Protocol Buffers parser in Scala… :-)

There is also a pdf I’ve written about this project but it’s not well written and in Polish (university requirements, bleh), but if you want to know more about Scala Parser Combinators, you can take a look at it here: doc @ github.com.

The project itself is of course Free Software and Open Source, licensed under the Apache 2 license, so feel free to fork protodoc-scala on github!

I’ll just quote the README from the github page for the rest of the description:

Oh, wait. That’s excatly what ProtoDoc is! ProtoDoc is a tool very much like JavaDoc, which scans your proto files and generates
an easily searchable and most informative website with all information about yout ProtoMessages.

It’s currently not production ready, and allows only for basic Messages to be parsed. But it should most probably be finished and fully working quite soon.

Live Demo
There is a live demo available here.

Coding notes

• ProtoDoc is build by sbt so if you want to help out hacking, first download Scala 2.8.1 and sbt :-)

Output screenshots
ProtoDoc takes this:

package pl.project13;

/**
 * This is a simple Message which has some Inner Message defined.
 * Also, note that it has a default value on the name property.
 */
message MessageWithInner {
    /**
     * A number is just a simple property
     */
    required int32 number = 1;

    /**
     * This can be a name of your likeing, the default value is "lorem ipsum" etc
     */
    required string name = 2 [default = "loremipsum"];

    /**
     * Whoa, this is a comment on an inner message!
     * ProtoDoc is so cool!
     */
    message InnerMessage {

        /**
         * This is a comment on an inner messages field, cool~
         * You may use it like this in your generated Java code:
         * setName("StringMyName");
         */
        optional string name = 3;
    }
}

and generates this:

Hooray!

Aparently some people did really like it, see tweets bellow :-) I also got feedback that “not yet real programmers”, that is students, didn’t really get what I was talking about. Well, most of them still uses SVN (well, if they do it’s a success anyways) as an SCP replacement so there’s not much they could complain in SVN about if they’re not making it work anyhow besides just storing files. :-) Some students apparoached me after the lecture and training (yeah, we also did a little git intro with laptops later on) and they were really fired up about it – even if not yet grasping git’s power, they felt something’s on and I am very happy to have invluenced even just a small group to such feelings and thinking.

I have been invited (via the Call for Papers I participated in) to present a polished up “Git. Tak. Po prostu.” speech at this years IT Festival. It was a really great opportunity to show lot’s of people (primarily students, and to-be-students but also some currently working people) the joy and beauty of Git. The event was really nice (it’s constantly improving, since the last few editions I think) and I’ve had some fun with my pal from work etc. I’ve also got to know some of the speakers – really nice guys :-) Anyways, find bellow the video from the presentation recorded by my newly met pal kzubik and the polished up slides (they’re a lot better than the previous ones).

Video:

The video is uploaded to Vimeo

Slides:

http://www.slideshare.net/ktoso/git-tak-po-prostu-sfi-version

Now, we all remember how painful it it to write good equals and hashCode methods, yet we really should implement them to make our collections work the way they should work (HashAnythings, Lists, Sets). So we sometimes use Apache Commons to implement these, or just leave the coding to IntelliJ or NetBeans. The problem with the second, code generating, solution is that it’s a hell of a mess. Don’t believe me…? Just a quick reminder then…

Now that we’ve remembered how painful it looks, let’s dive into JDK7: The full code would look like this (this time equals is also accepting subclasses of Test, the above example didn’t):

Note the Objects.hash() method, wich is really a lifesaver and also the Objects.equals() method which makes our code NullPointerException safe, which the previous version had to tackle by using ?:… And it read’s much nicer, Of course, you could skip the result variable, but I decided to do it like this for the sake of easy reading.

And here is it’s test:

Now that was nice wasn’t it? :-) Objects probably isn’t “the” killer feature that JDK7 has, but it’s a really nice addition, so let’s get to using it :-) The other utility methods in this class are:

• static <T> int compare(T a, T b, Comparator < ? super T> c)
  Returns 0 if the arguments are identical and c.compare(a, b) otherwise.
• static boolean deepEquals(Object a, Object b)
  Returns true if the arguments are deeply equal to each other and false otherwise.
• static boolean equals(Object a, Object b)
  Returns true if the arguments are equal to each other and false otherwise.
• static int hash(Object… values)
  Generates a hash code for a sequence of input values.
• static int hashCode(Object o)
  Returns the hash code of a non-null argument and 0 for a null argument.
• static <T> T requireNonNull(T obj)
  Checks that the specified object reference is not null.
• static <T> T requireNonNull(T obj, String message)
  Checks that the specified object reference is not null and throws a customized NullPointerException if it is.
• static String toString(Object o)
  Returns the result of calling toString for a non-null argument and “null” for a null argument.
• static String toString(Object o, String nullDefault)
  Returns the result of calling toString on the first argument if the first argument is not null and returns the second argument otherwise.

Hooray for small litle improvements :-) This class officialy get’s Duke’s thumbs up image: