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 ;)

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:

This Saturday we’ve (the Software Craftsmanship in Cracow guys) organized a Code Retreat, right after AgileCE. We’ve invited Corey Haines to join us and facilitate this meetup, and later on even Alexandru Bolboaca AND Maria Diaconu joined us in facilitating the event and so it got even better :-)

Corey doing the introductional Keynote

Before we start, just a quick reminder what a CodeRetreat actually is (for the sake of everyone reading this blog not knowing what the hell I’m so excited about ;-)). The rules are really easy, take a bynch of passionate programmers, put them in a room for 1 whole day and tell them to code the game of life. There are about 6 sessions, where each time you’d pair up with another person and code away. After 45 minutes you have to delete the code you’ve written, then after a 15m pause to talk about your results you find a new pair and code it again from scratch. It’s important to embrace the code deleting part – it’s somewhat like catharsis… :-) No matter how bad (or great) the code you’ve written was, on average in 22.5 minutes it will go away :-)  The idea is to embrace that you most probably won’t finish the problem in time, so you can just focus on honing your skills in TDD, pairing, IDE usage and generale code style and skillz. There’s no better way to learn these skills than to confront them with someone else’s – that way you both can learn new tricks or find out why some ol tricks you used actually suck :-) In the end of the day, you’ve become a better programmer… and will hopefully take these new skills into your workplace and improve the code quality there :-)

Happy hacking!

The response to our CR was really amazing. We’ve had quite a few sponsors – LunarLogic, AppliCake, ABB, Sii… and the PolishJUG helped out as well as it could with organizing the whole thing :-) Oh, and I hope you’ve seen our nice website created by Olga from LLP? The interest from participants was equally big – all places where “sold out” in just about 3 hours… ;-) We where around 50 people in total and I think that’s a perfect number of coders for such an event. Some coded in Java, some in .NET and others in Ruby or Python, oh and there was an Objective-C and Scala team too. One of the nive things during a CR is being able to try out a new language, so the Ruby guys where really overflown by people wanting to try Ryby for example ;-) I’ve spent the rest of my sessions (4/5) coding in Java and just once had to lay hands on Eclipse… ;-) During one session I tried out ruby (ルビ) with Adam from SCKRK, which was fun as I did read some books/articles about it and really enjoyed the BDD that rspec uses. I also noticed that scala test seems to have derrived from it (or the other way arround :p)… :-)

The 2nd room was also full

After two sessions we had nice long lunch, to relinquish our coding skills and ideas (we’ve ordered from thaisty). And then a next set of 3 sessions followed. This time more focused on experimentation etc. For example one session we managed to not use if’s and for’s at all (sigh, upto one place but the time ran out then..). Google Guava was a great help there :-) On another sessions we’ve focused on Mockito and the more advanced mocking techniques such as parameter catching etc… In the end we really knew how much over engeenired it was but nevertheless it was really interesting to learn and play with these thoughts – that’s what CR is about.

1

Final Wrap Up

Later on we’ve sent out a questionary on how much you enjoyed the CR and the response was also really positive. We’ll think about coffee next time – promissed. :-)

Stanley just pulled in my quick gallery commit to our website git repo a moment ago, so you can now visit coderetreat.sckrk.com/gallery and look for yourself on the pics :-) They’re fetched from my picasa so if you’d rather download them all from there, please do so :-)

Group Photo

All in all… I’m really happy and proud to have been part of this event. It’s really been one of a kind and I hope all of you feel the same way about it. Well, it would certainly seem so after the opinions on the final wrap up and questionary later on. :-) So, once again, thank you for participating and see you soon on most major coding events :-) (ps: GeeCON is one of them).

Well, that was all nice and cool but git (other DVCS have this too) has a lot more to offer! :-) Today we’ll look into git bisect and how to automate it’s execution using maven to look for a commit that breakes something. You may run ANY SCRIPT and even write your own and git will use it to test if a commit is “bad” or “good”. Ok, but let’s slowdown a little… What git bisect basically does is performing an binary search, between a range of commits you specify looking for “the first bad commit” you you can easily find what caused the bug and fix it. You can drive it by hand and after starting git bisect just test the commit by hand and tell git if it’s good or bad by “git bisect bad” “git bisect good”. Git is smart enough to find what commit he should “git checkout …” next to perform a binary search based on your anwsers.

Today we’ll learn how to make git cooperate with maven and find the first commit that introduced a test failure. See bellow for the full workflow you showcasing this:

Ok up until now we’ve just created a simple repository we’ll be running the tests on. Let’s tag this state as “yeah it’s working here” just so that I don’t have to remeber the SHA-1 of this commit.

And now we’ll run a script that does some random commit action, just so that bisect has a lot of commits to work on.

The tests are still passing… time to change that! We’ll break the build with the following commit. And then generate yet another 50 commits to “hide it”… ;-)

Ok the test’s fail now. But suppose you didn’t know which commit introduced the bug (in our case made the test’s fail). You’d have to guess which one, or check them all or just work it out by looking at your current repository state. But since you’re doing small commits and do them often – it’ll be great if you found out which commit caused this failure. As it’s preferably small, it’ll be very easy to find out what change caused the build to fail. No is the time to use git bisect!

We’ve started bisect, and told him which commit we’re sure is working and which we’re sure is failing. Git will now checkout a commit he found “somewhat in the middle” and will continue to bisect (binary search) the commit history based on wether a commit is “good” or “bad”. We could just tell it git by hand by doing “git bisect good/bad” etc. But let’s git bisect run a script to do this for us :

Yeah, we’ve found our failing commit :-) You could use any script you want here, it just has to return 0 if git should think it’s a “good commit” and “not 0″ if it’s a “bad commit”. I’ve even seen runners written in PHP running or spellcheckers – you name it… :-) Ok but how does this magical script that we’ve just run look like?

Whoa, that’s simple… :-) Keep on git hacking guys! See you soon, with some more git or java tips… :-) Oh and I’ll post my presentation (holefully with video) from SFI soon, so keep an eye out! :-)

PS: Yup, the code retreat we’re (SCKRK with a little help from the PolishJUG) organizing got “sold out” after just 3h… ;-) Be sure to take a look and be quicker next time! http://coderetreat.sckrk.com

As I’m coding quite a lot GWT and JS has also become quite powerfull in the last years I enlisted the training to learn more about JS optimalization and add some more tricks to my toolbox. Also some real life use scenarios would be very welcome. Turns out Tanadu (a polish “heroes-like” browser game) was implemented 100% in plain JS. Which is quite shocking and as we later agreed on developing such code can really be a pain in the neck. “Use GWT” would be my anwser to such an use case I guess – you wouldn’t loose the refactoring tooling Java gives you and could still fallback to JSNI if really needed. Did the “training” meet my expectations? Yup. Want more details? Read on… :-)

It was really fun and I’ve even (and unexpectedly) met a friend of mine with whom (and one other developer) we’ve paired up and were coding a JS Mortal Kombat in JavaScript for those two days. We’ve learnt how to use CSS3 *-animation, *- transition and other cool new features (well, most of them “webkit only” but very cool nevertheless). Then we’ve coded a little and went on to dinner ate Jeff’s where I’ve lead the group to :-) Sadly dinner took a little too much time and we had less time to code than Poznań during their meeting a few weeks ago.

By the way… MVC in JavaScript is quite weird (hey, most of the teams ended up with GodObjects anyways! ;-)), as is any acting “hey, let’s just say we can have classess and inherit them blabla…”. We’ve seen quite a few examples on how to emulate OOP in JavaScript which was both: really weird and interesting at the same time. In the end, the thought “if you have no type system, in the end you develop your own” seems really true here. I believe this was said by someone from twitter about their Ruby code, which had a hell lot of assertions in it just to be sure “abc is really of type AbcType”. That’s why I’m more for Scalas apparoach than Groovy’s or Javascript/Ruby/Php, but I’m not that advanced in Scala yet to judge it as “super perfect”… ;-)

MK in Javascript using Node.js

On the next day we implemented the serverside stuff, using node.js and socket.io for the clientside wich worked really well I have to addmit. Although I’m still wondering how I’d handle auth/security to be _really_ secure using such server instances (“nodes” ;-))… Finally our game had a very nice and developed state machine for all basic mortal kombat moves (including high/low punch etc, how much such state is blocking and which sprite to use for it, jumping etc.). As this state manipulation took most of our time, our server didn’t support an infinite number of players as some other implementations did but as a trade off they didn’t have any combo/move logic in their games :-) Of course the game was playable (well, “almost playable” – both players think they’re “on the left”, but we’d fix that very quick if needed… ;-)). A quick finishing talk touched some performance tweaks – quite some we should have used in mSejf etc – so I feel a little smarter than before :-) Sadly we didn’t talk too much about TDD using JavaScript which may be really a good idea (ugh this loose typing can make you mad sometimes… ;-)).

Our mortal kombat game ;-)

What could be definitely improved is the internet connection (well, “organization” as a whole I guess) as we had quite a lot problems with it (choose a hotel which is no noob in terms of IT meetings :-)) and the lead’s knowlage about git. Since it’s quite an deep tool, and we’re not here to focus on it but on JavaScript some quick info about how to use it and more developers who aren’t using it the first time in their lifes would have been really helpful. But fear not, I’ve helped out all the teams with learning git and all merges, push/pull flows and other weird problems :-) So it became quite an hybrid training where some of the participants learnt quite a lot about git :-) Some may actually like it in spite of the difficulties we encountered in our very chaotic flow during our hack sessions… :-) On the other hand, any way of introducing git to new people is a good thing, but I fear some may expierience some discomfort/distrust to a tool they’ve just “learnt” on a “fly by basis”, from… well, me – another participant. ;-)

From my perspective it was a great and fun meeting and I’d like to attend more such meetings, sharing the same  formula, or slightly improved. What I loved was of course the hacking and fun of working in a team + teaching people git… :-) If you’re hungry for some team coding you may want to checkout one of the upcomming meetings or wait for SCKRKs + PolishJUGs “Code Retreat” that we’ll be announcing really soon… :-)

PS: I’ve pushed our game implementation (less than 8h of real coding (rest of the time was talking/presentations/eating etc ;-)) to github, here: https://github.com/ktoso/mk-javascript so you may want to take a look. Event out of pure curiosity :-)

UPDATE
The plugin is now available from Sonatype Nexus!

    
        sonatype-releases
        Sonatype Releases
        https://oss.sonatype.org/content/repositories/releases/
    

END OF UPDATE

Now I’ll be a bit lazy and just paste the README I’ve prepared for maven-git-commit-id-plugin on github.

  git clone git://github.com/ktoso/maven-git-commit-id-plugin.git maven-git-commit-id-plugin
  cd maven-git-commit-id-plugin
  mvn install

   <?xml version="1.0" encoding="UTF-8"?>
   <project xmlns="http://maven.apache.org/POM/4.0.0"
            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <modelVersion>4.0.0</modelVersion>

       <groupId>pl.project13.maven</groupId>
       <artifactId>my-git-plugin-sample-app</artifactId>
       <packaging>war</packaging>
       <version>0.1</version>
       <name>my-git-plugin-sample-app</name>
       <url>http://www.blog.project13.pl</url>

       <parent/>

       <dependencies />

       <build>
           <!-- GIT COMMIT ID PLUGIN CONFIGURATION -->
           <resources>
               <resource>
                   <directory>src/main/resources</directory>
                   <filtering>true</filtering>
                   <includes>
                       <include>**/*.properties</include>
                       <include>**/*.xml</include>
                   </includes>
               </resource>
           </resources>

           <plugins>
               <plugin>
                   <groupId>pl.project13.maven</groupId>
                   <artifactId>git-commit-id-plugin</artifactId>
                   <version>1.0-SNAPSHOT</version>
                   <executions>
                       <execution>
                           <goals>
                               <goal>revision</goal>
                           </goals>
                       </execution>
                   </executions>
                   <configuration>
                       <prefix>git</prefix> <!-- that's the default value -->
                       <dateFormat>dd.MM.yyyy '@' HH:mm:ss z</dateFormat> <!-- that's the default value -->
                       <verbose>true</verbose> <!-- false is default for this -->
                       <dotGitDirectory>${project.basedir}/../.git</dotGitDirectory> <!-- required, you have to specify this path -->
                   </configuration>
               </plugin>
               <!-- END OF GIT COMMIT ID PLUGIN CONFIGURATION -->

               <!-- other plugins -->
           </plugins>
       </build>
   </project>

 git.branch=${git.branch}

 git.build.user.name=${git.build.user.name}
 git.build.user.email=${git.build.user.email}
 git.build.time=${git.build.time}

 git.commit.id=${git.commit.id}
 git.commit.user.name=${git.commit.user.name}
 git.commit.user.email=${git.commit.user.email}
 git.commit.message.full=${git.commit.message.full}
 git.commit.message.short=${git.commit.message.short}
 git.commit.time=${git.commit.time}

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean name="gitRepositoryInformation">
        <property name="branch" value="${git.branch}"/>
        <property name="commitId" value="${git.commit.id}"/>
        <property name="commitTime" value="${git.commit.time}"/>
        <property name="buildUserName" value="${git.build.user.name}"/>
        <property name="buildUserEmail" value="${git.build.user.email}"/>
        <property name="commitMessageFull" value="${git.commit.message.full}"/>
        <property name="commitMessageShort" value="${git.commit.message.short}"/>
        <property name="commitUserName" value="${git.commit.user.name}"/>
        <property name="commitUserEmail" value="${git.commit.user.email}"/>
    </bean>

</beans>

package pl.project13.maven.example.git;

import org.codehaus.jackson.annotate.JsonWriteNullProperties;

/**
 * A spring controlled bean that will be injected
 * with properties about the repository state at build time.
 * This information is supplied by my plugin - <b>pl.project13.maven.git-commit-id-plugin</b>
 *
 * @author Konrad Malawski
 */
@JsonWriteNullProperties(true)
public class GitRepositoryState {
  String branch;                  // =${git.branch}
  String commitId;                // =${git.commit.id}
  String buildUserName;           // =${git.build.user.name}
  String buildUserEmail;          // =${git.build.user.email}
  String buildTime;               // =${git.build.time}
  String commitUserName;          // =${git.commit.user.name}
  String commitUserEmail;         // =${git.commit.user.email}
  String commitMessageFull;       // =${git.commit.message.full}
  String commitMessageShort;      // =${git.commit.message.short}
  String commitTime;              // =${git.commit.time}

  public GitRepositoryState() {
  }

  /* Generate setters and getters here */
}

<context:property-placeholder location="classpath:*.properties" />
<import resource="classpath:/git-bean.xml"/>

 @Controller
 @RequestMapping("/git")
 public class GitService extends BaseWebService {

     @Autowired
     GitRepositoryState gitRepoState;

     @RequestMapping("/status")
     public ModelAndView checkGitRevision() throws WebServiceAuthenticationException {
       ServerResponse<GitRepositoryState> response = new ServerResponse<GitRepositoryState>(gitRepoState);
       return createMAV(response);
     }
 }

 {
     "branch" : "testing-maven-git-plugin",
     "commitTime" : "06.01.1970 @ 16:16:26 CET",
     "commitId" : "787e39f61f99110e74deed68ab9093088d64b969",
     "commitUserName" : "Konrad Malawski",
     "commitUserEmail" : "konrad.malawski@java.pl",
     "commitMessageFull" : "releasing my fun plugin :-)
                            + fixed some typos
                            + cleaned up directory structure
                            + added license etc",
     "commitMessageShort" : "releasing my fun plugin :-)",
     "buildTime" : "06.01.1970 @ 16:17:53 CET",
     "buildUserName" : "Konrad Malawski",
     "buildUserEmail" : "konrad.malawski@java.pl"
 }

Dzisiejszy wpis będzie o znanej i generalnie dość znanej i mającej wiele zalet metodyce Design By Contract. Temat “wypłynął” ponownie dla wielu javovców tym razem dzięki wydaniu biblioteki  CoFoJa (o którym właśnie będzie ten post) przez dwóch pracowników Google przy ścisłej współpracy z autorem pierwowzoru tego projektu. Dlaczego jednak nietypowy tytuł posta – “trzeźwe spojrzenie”? Ponieważ w odróżnieniu od niektórych nie oceniam technologii na podstawie “wow factor” a realnej używalności. Gotowi mini review tego toola? No to lecimy… :-)

Contracts For Java

Na początek warto rzucić okiem na googlowy blog gdzie ogłoszono premierę tego narzędzia oraz oczywiście samą stronę domową projektu CoFoJa. Oczywiście na samym przekierowaniu nie poprzestanę więc zaczniemy od mini definicji od strony użytkownika metodyki design by contract. Jak możemy przeczytać chociażby w pragmatycznym programiście metodyka ta ma dość spory potencjał i ciekawe możliwości – generalnie chodzi o określanie “kontraktów” na naszych metodach. Zakładanie kontraktów ma pewną wyższość nad pisanie testów jednostkowych ponieważ możemy kontrakt założyć na interfejsie a wszystkie implementujące go klasy będą z nim związane

Kontrakt może na przykład zapewnić:

• wykonanie danej metody tylko i wyłącznie wtedy gdy przekazane jej argumenty spełniają pewne kryteria (w kontekście CoFoJa byłoby to @Requires)
• zagwarantowanie spełnienia pewnych warunków po opuszczeniu metody (w kontekście CoFoJa byłoby to @Ensures ewentualnie @ThrowEnsures jeśli chcemy mieć kontrakt na rzucenie wyjątku)
• zagwarantowanie ogólnych warunków na konkretnej np. klasie (@Invariant)

Ok, skoro znamy podstawowe building blocks (zaczerpnięte skądżeby inąd niż z Eiffla oczywiście) zobaczmy jakieś przykładowe poadnotowane nimi API:

A teraz praktycznie

Najlepiej jest chwilkę się w niego wgryźć, powinien być stosunkowo zrozumiały. Nie chcemy nigdy mieć ujemnej ilości bananów – spowodowałoby to złamanie kontraktu. Podobne przykładowe kontrakty wejściowe/wyjściowe widzimy na metodach oraz jeden mały tip: metoda old() jest dostarczana automagicznie i oznacza “starą wartość tego wywołania” czyli przed wykonaniem metody na którą zakładamy ten kontrakt. Poza tym mamy tutaj do czynienia w sumie z zwyczajnym kodem Java który niestety jest wewnątrz stringa… Świadomy programista zapewne już ma zapaloną lampkę alarmową, że to będzie nie refaktorowalne i bez sensu… Na pocieszenie dodam iż kod Java zawarty w tych stringach faktycznie jest “kompilowany”i jak coś popsujemy składniowo, kontrakty się nie skompilują i dostaniemy normalne informacje jakby to się nam nie kompilował normalny “nasz kod”. Co do wygody refaktoringu… Na szczęscie korzystam z porządnego IDE (IntelliJ IDEA) i takie “problemy” mnie nie dotyczą ;-). Wybrałem inject języka Groovy do tych stringów aby parser składniowy nie dziwił się pojawienia się metody old() “z nikąd”: Problem z “nie podpowiadaniem metod” jak i “nie da się refaktorować” jak widać został od razu wyeliminowany :-) Hooray for JetBrains. Poszukajmy jednak kolejnego problemu z tym API… Tak jest, @ThrowEnsures jest trochę brzydki a nie koniecznie musi być cały w stringu. Jak działa obecnie? Przekazujemy mu listę stringów gdzie parami występują “wyjątek” + “warunek kiedy ma zostać rzucony”. Chętniej zobaczył bym to w formie podobnej do poniższej (tylko szybki szkic taki), a wy?

Ok czas na uruchomienie kodu z “włączonymi kontraktami”… I… niestety nie okazało się to takie trywialne na obecnym etapie projektu. Niestety trzeba sobie ręcznie poustawiać processowanie adnotacji (norma, tutaj się niewiele zmieni) jednak trochę problemów nastarcza mi obecnie widoczność klas/pól dla CoFoJa w intellij. Classpath (dla procesora) zdaje się być ustawiony poprawny oraz jego klasa jak i inne opcje też jednak nie dochodzi do poprawnego przeparsowania wszystkich reguł. No cóż, może jutro się uda – tymczasem odsyłam do poradnika dla użytkowników Eclipse gdzie to członek społeczności sprawnie poradził sobie z tym problemem :-)

Trzeźwe spojrzenie: “Czy obecnie warto?”

Pozostaje pytanie… Czy warto się zainteresować CoFoJa jak i samym DBC? Pytanie jest chyba równie ogólne jak “czy warto meta-programować?” także wprost odpowiedzi nie udzielę. Miejmy jednak na uwadze że jak na razie używanie CoFoJa nie jest zbyt wygodne a adnotacje można by jeszcze trochę poszlifować. Trzeba by jeszcze rzucić okiem jak stoimy z integracją tego z Maven – aby normalnie testując bądź klikając sobie po projekcie te kontrakty mogły się przydawać. Sama idea jest ciekawa i jakby integracja z narzędziami była wygodniejsza – a może od razu pluginy do IDE – można by się nad tym porządniej zastanawiać. Jak na razie projekcik odkładamy ten projekt spokojnie na półkę “worth watching” i liczymy na rychłe wydanie 2.0. :-)

PS: Jeżeli interesują Cię takie jak i inne ciekawe metodyki i sposoby tworzenia pięknego, czystego kodu, zapraszam serdecznie na co 2 tygodniowe spotkania SCKRK gdzie obecnie dyskutujemy w formie “reading club” nad Domain Driven Design :-)

So… Since I’ve started using git-svn at work, I do have an possibility to make things better now! The answer lies in client-side-hooks and git aliases (“custom commands”). First let’s write this as an simple bash script, that we’ll locate in the .git/hooks/ folder:
It’s a fairly simple script, so I wont bore you explaining it in detail – if in doubt, feel free to ask. We only need to place this script as “.git/hooks/pre-commit” and make it executable and git will take care of the rest for us. Oh and in case you’re wondering where that org.eclipse.jdt.core.prefs came from. It’s created by eclipse into the .settings folder when you check some option to “use formatter per project” – that’s the only time I had to fire up and click around in eclipse to get it’s formatter running “headless”. Ok, let’s check if it works…

Yup, you can agree or not with the formatting rules – but what matters is that the whole team decided on it and that we keep it consistent throughout the whole project. This hook will definitely help with this. :-) Step two for me was changing this into a git command, so that I wouldn’t launch eclipse each time I just do some quick local commiting. The solution is to drop the hook idea (although it’s quite nice) and create an custom git command. We do this by doing an alias like that:

git config --global alias.eclipse-formatter '!~/git-hook-eclipse-formatter'

The !command alias support is with us in git since 1.5.0 and it enables us to launch any program/script as an git command. Great, just what I wanted! Let’s now see what this command really did:

As you can see, adding an alias is as simple as adding it to your ~/.gitconfig or, if you want to setup the alias “per project”, to .git/config – pretty cool, ay? Also, this command will be included in bash-autocompletition suggestions! :-)

That’s it for today… happy hacking!

Łukasz Lenart – “Nie samym kodem programista żyje”

Łukasz’s presentation was not a technical one this time. He talked about how to be/become an effective programmer. A nice tip he noted was to carry a notebook and note your ideas in it – i sometimes try to but did find myself forgetting some “amazing idea” due to the lack of discipline in carring such notebook (yeah, an paper-notebook… :-)) so it’s definitely something worth reminding. He also talked a little about Kaizen, ZenToDone and the Pomodoro Technique which all kinda share the same idea but explain it a little bit differently. I also was quite happy to find out that I’m not the only one that gets slown down in development when actually being in the company – with lots of stuff happening around me. Admit it – we all work more productive when there’s noone bugging us ;-)

The most notable tips where the “alone-zone” (as explained in REWORK (good book, I recommend it)) which is really great and I love it, but sometimes it’s hard to enforce – coding is usualy team work, ain’t it..? Using multiple desktops – and monitors at best, to seperate your work space from fun space. Cutting oneself off from the internet is, while extreme, very effective by the way. I noticed it quite a few times – there’s simply nothing distracting you – same goes for anything that might take your attention. By the way, I’m not really convinced about Pomodoro – what if you get into an v. nice flow and then the pomodoro snaps you out of it? I guess it may be more targeted at people working at bigger companies – not as myself in an small nice team and nowadays, mostly from home.

All in all he warmed up the audience perfectly and let’s hope some of theese tips help us become better programmers… :-)

• //TODO: watch on parleys.com
• //TODO: download slides
• download video

Konrad Malawski – “Git (tak. po prostu.)”

The PJUG guys asked me to tell a little about git and I happily agreed to do it – thus, my first “public presentation”. Firstly I’d like to explain why the slides where so “weird”. It’s because I wanted them to be something like an “break”, and most of the session was live terminal typing. They were all hand drawn by me and my girlfriend, then scanned and recoloured in GIMP. Took a few evenings to prepare them, but I hope they where quite memorable, fun, and did point out the important aspects of what the next topic would be about – an 3 headed dragon as symbol for lots of HEADs in an git repo etc… ;-)

Click to show presentation

I’ve been preparing the flow of all examples before but during the presentation I missed out a few steps and made a some stupid mistakes (see my previous git post on this blog ;-). Well, it wasn’t anything world breaking I guess and I’d really like to thank the audience for such great support. We strayed a little of the path I’ve prepared sometimes, but that’s ok as it was interesting to interact with the audience during an presentation – not just stand there and “praise git to zee heavnz” ;-) Such interaction is something I (personally) really like in presentations, even if they break a little due to this :-)

All in all, we managed to go through all of git’s basic features and in the end even mentioned rebase – which can be used to change the history of ones commits (there’s also the very useful git commit –amend), detached-HEADs and git-svn, which I didn’t use before as I feared a little to make a mess in the company svn-repo (and in all “my” projects I’m using git, so I never felt the need to use git-svn). Some guys sucessfully used it and really recommended it, thus… here I am, doing git svn dcommits on an daily basis… :-) I’m glad to have also learned something from this presentation, not just “showed what I had to show” :-) Now just a few links to very good resources about git:

• A Successful Git Branching Model
• Very good video tutorial on git
• https://git.wiki.kernel.org/index.php/GitFaq
• http://git-plumbing-preso.heroku.com – internals
• https://github.com/ – free opensource project hosting
• and of course: http://git-scm.com/documentation

After the presentation I made an small sms-contest where you could win an PJUG tshirt for guessing what github’s mascot is called like. I hope it was an nice positive accent to finish the session. Next up was the pizza and then 2 more Łukasz’s… :-)

• //TODO: watch on parleys.com
• download slides
• download video

Łukasz Żmudziński – “Project Lombok – Cause We Hate Boilerplate!”

Lombok, if you didn’t see it before is this -> http://projectlombok.org/ It’s a “total hack”, as the author describes it (and he’s right ;-)) but it allows some funny compile time hacks while writing Plain Old Java Code. Łukasz showed us around all the annotations which Lombok provides and how they work, what code exactly would be generated by them etc. The most “let’s you write less code” annotation would be @Data, which at compile time would cause Lombok (…here comes the important part:) to write the source for all setters, getters and toString hashcodes etc – so javac in the end, thinks it’s just compiling plain odl java… Here’s a link on how it works: Data.html The funny part about it is that it’s an compile time tool – much similar to Spring Roo in that aspect if you ask me -  and what it actually modifies is the AST (AbstractSourceTree) that javac then uses to generate it’s bytecode… So no bytecode magic – just how I’d call it… source code injection during compile time? Yeah, weird stuff.

And if you ask me not really something I’d be using all over the place. Sure it’d spare me the writing of some getters and setters and some more tricks but in the end, it’s a problem for not supported IDEs. (How do you explain IDEA that this class really *will have* an setBla() method…?) While NetBeans and Eclipse do have plugins to enable them to unserstand lomboks annotations. It’s not really enough – what about static code analisis tools? They’d go nuts with code that calls methods which dont exist in the source etc :-) Nevertheless if was a fun topic and it definitely is an quite funny javac hack, but if I’d be desperate for such features… I’d go polyglot coding with groovy or scala etc… :-)

• //TODO: watch on parleys.com
• download slides
• download video

Łukasz Czerpak – “Testy jednostkowe i integracyjne w przykładach”

By now you probably noticed it… There where almost only Łukasz’s presenting on this Camp…! :-) Łukasz Czerpak’s topic was about, generally speaking, TDD. He focused (as the title suggests, if you can read polish ;-)) on unit and integration tests. The border between them is sometimes a little blury, but the definitions he have were nice and clear – 1 class = unit, long setup involved = integration. It’s as easy as that, yet sometimes during discussions with other coders these sometimes get confised. Next he went on to some examples of how TDD is useful and finally to a lot of code examples. As he’s using EJBs at his day job, this part was mostly covered – and very interesting (for me, who’d usually just use spring and be done with it).

The mocking framework he used in his examples was of course our Polish Mockito… :-) It’s really great and lot’s of fun to work with, unlike some other mocking frameworks out there. Although easymock would take the 2nd place if I’d were to make an ranking. I’ve also seen a little JMock but it doesn’t “feel good” – but if youre interested in pure “what X can do”, they all do offer the same things, so why bother with some cluttery syntax? :-)

Next, Łukasz showcased using glassfish as an embeded container which definitely is on my “good to know” list and then continued on to an very awesome JBoss library: Arquillian [arquillian homepage] (see? It’s so cool I even had to mark it bold ;-)) It’s an lib which enables you to deploy (yes, “deploy” – perfect word choice) EJBs or even whole archives to an testing enviroment – which would then be started using an embeded container, although as seen on their homepage, they also support remote containers… interesting! Here’s another nice usecase of it: http://ocpsoft.com/seam/cdi-powered-unit-testing-using-arquillian/ The presentation was really well prepared and most probably the high

• //TODO: watch on parleys.com
• //TODO: download slides
• download video

That’s all folks!

We’ll be doing another JavaCamp in the near future (January perhaps…?). But for theese few weeks now we’ll be focusing on the upcomming GeeCON 2011 (Cracow) and kickstarting it’s call for papers (yay, I’m it’s author ;p). And if you’re interested in seeing all recordings on parleys.com and not just as videos – stay on your toes, because after Devoxx we’ll upload them there – I’ll update my blog then and we’ll write an quick news about it on java.pl In the mean time, you can go take a look at these and the previous (javacamp #4) recordings on camp.java.pl – which I just quickly set up to allow you guys quick access to the movies…

Yup, that’s all I think… see you on GeeCON || JavaCamp #6! :-)

If you code in Java, you most probably use (you really should use) some dependecy injection mechanisms. They’re really great and take care about all the setup that need’s to be done before you can move on to your coding. The same thigh applies to testing, you’d rather write:

Than use the new operator, or worse, perform some super weird setup to build this object. If you use spring, you’d write an test like this to make it support Spring’s DI:

That’s all you need to make your tests properly autowire all components they’re using. So far so good – probably nothing new here, and nothing complicated. So let’s move on to some “super big data set” that needs to be tested, over the same flow over and over again. We’ll use an super conplicated example to showcase what I mean:

Ok, that’s obviously stupid… :-) So, how do we deal with repetitive tests, that need some bigger dataset than just this email example (given here because it’s short and good enough for our example test)…? We’d use @RunWith(Parameterized.class), the class would then look something like this:

Ok, that’s a nice way to make your code in the tests smaller yet have an nice overview through all of your tested data. Each array will be inserted in the constructor, and then ran as an seperate test – with each dataset. Nice, isn’t it?

Ok, but what if we want to have both Spring’s DI and an @Parameters “test data provider”…? Can you spot the problem? Yup, JUnit4 can only have ONE @RunWith annotation, and it doesn’t accept multiple runners. Which totaly makes sense when you think about it, but then there is our special case of DI, which really doesn’t change the way an test wotks, it just makes setup easier… All that said, here’s how to use both spring and parameters in your Junit4 tests:

That’s it :-) We do what the spring Runner would do for us, instanciate an application context and prepare it – that’s when the DI happens. Note that we cant use another runner annotation, but we can as usual specify where to find the appContext.xml’s.

That’s all, hope this will prove useful to some of you :-) Keep your tests clean!

PS: Warning, most of this code was written in wordpress, it may contain minor spelling errors ;-)