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

Nuff said, let’s get down to some code. Basic android stuff is really easy to grasp and I wasn’t entirely “new” to it so coding went without big problems. One thing I missed was Dependency Injection – which I learned to love thanks to JEE – esp. Spring and Guice. But fear not – here’s how you can use DI – using Guice – in your android apps:

Just get the RoboGuice and Google Guice (the NO-AOP version) JARs and attach them to your project. Next, you’ll have to configure your “Application” in your AndroidManifest.xml:

The “android:name” specifies the “Application” class your app will use. This will be used by android as the “Application” instance, which would otherwise be just an plain old android “Aplication” – this is an common class for all your Activities and Services, you can do some global setup stuff here etc. And thats wat we are going to do right now:

We’re extending the GuiceApplication here, it’s provided by RoboGuice and allows us to easily add GuiceModules to our app – which then will be used in dependency resolution as they would normaly in any DI framework. If your interested, thats the ClassHierarhy we hooked into:

Ok, done. Now let’s setup Guice. It’s pretty straight foreward we bind interfaces to implementations Guice should use. If needed we could do some more interesting bindings (by our own annotations etc) but I don’t need such setups in my app so just such an module is ok:

And you’re ready to go. Now you can inject all you want in constructors/setters/fields, for example like this:

Please note that normally to obtain an SharedPreferences instance you would have to be in an Activity and get it like this:

Another nice thing RoboGuice allows us to do is injecting relations from our view.xml’s into our Java sources – which reminds me a little of GWTs UiBinder, but a little reversed, as in GWT the view has all the ui:field=”blaField” and here we use R.id.* to pass and get those references… The overall feel and look stays quite the same I guess – variables linked to XML objects in the layour. :-) Anyways, here’s how this linking looks like without DI:

And now the version using RoboGuice:

Much cleaner in my opinion, and it introduces less places we have to remember changing when our UI Object changes from an TextView ro an WebView for example… It’s also possible to inject Strings and other resources this way.

Oh and by the way, the project I took the code samples and learned all this stuff on is on my GitHub, here.

I’ve been coding an simple RESTful “ip to country” conversion service. I’ve decided to put it up to appengine – so that everybody may use it freely even if I’d change my server etc… And if looked quite nice the first day – buw when I got to do some “real stuff” app engine started to get in my way, here’s a quick rundown of the problems I’ve found with appengine:

1. I need to download and update the ip<->country database every few days. I’d use an GZIPInputStream and BufferedReader to get the file I was interested in and update the database. Did appengine allow me to use such an simple aparoach?
   1. pro: appengine provides a very nice cron-like mechanism. So I just had to create an cron.xml in WEB-INF and this part was ready to go! This was in fact easier and more fun than in classic Spring + Open Symphony Quartz.
   2. con:I checked if this tactic was OK with the JRE whilelist and checked the Quotas – http://code.google.com/appengine/docs/quotas.html#UrlFetch, “seems ok” – I thought – “nothing about per connection limits, only daily quotas.”. After writing the code, I discovered that even though on the main quota page there was no word about per connection limits, in fact there are such quotas, but a little more hidden: http://code.google.com/appengine/docs/java/urlfetch/overview.html Max request/response sizes are capped at exactly 1MB.
      As my gzipped file is around 1.1MB, appengine killed my simple idea… I’d have to split the file into separate ones – on another server, and then fetch the separated files onto appengine.
   3. con:The mentione CRON mechanism is quite funny. You don’t call methods but URLs – and they are normally called as if one would launch them from the browser – thus, traffic and “max time” quotas do count there as well. So rather than calling an method, as you’d do with OpenSymphony – you create an Servlet that does all the work. This may me both good, and bad… You cound do all the CRON stuff by hand if it got out of sync etc… I didn’t really like it, and as mentioned… When doing my “big batch database update” the servlet would simply timeout…
2. Let’s talk about the dataStore. As you all probably know… AppEngine does not provide and “database” per se. It’s not relational and has quite some limitations. BUT! That’s quite ok, as it’s very quick and very very scalable! And most of the time… Do you really need all those fancy relations? ;-) It was an ideal place to hold my super simple data: “ip region = country” mapping in a persistent way. “Another nice thing on appengine for this application I’m going to write.” – I thought. Was I right?
   1. pro/con: Not really… I used JPA but JDO (which is prefered by appengine from what I’ve seen) also works nice on GAE. The setup did run quite ok while I was running tests on my local machine. Deployment is also an breeze and I didn’t have to use any complicated dependencies to get it running – “yay, no maven!”. You just have to enchance the classes you want to make persistent (just as hibernate does).
   2. con:The problems started when I wanted to clear my datastore. Nothing easier than that, right…? “delete from BlaBla” and we’re done. Yeah, but not on GAE. As even the “max rows a query touches” are limited – to 500. So there I am, with my 100.000 rows, and I have to delete them in 500 rows per query… Of course I can’t call this in an loop – as the timeout quota would get in my way and kill the app.From what I’ve seen, people do solve this using a CRON task that calls this “clearDatabase” servlet until it’s  done – ugh, not a nice solution but I can’t think of any other solution :\
   3. con:The only query I need to do in this app is basically:

      SELECT range FROM RemoteIpData as range
                   WHERE range.ipFrom <= ?1
                     AND range.ipTo >= ?2
      #and this would always return 1 entry!
      

      And guess what… AppEngine does not support multiple “less/more than” operands in one query! If you think hard about what BigTable is, it does make some sense. More information about “GQL” can be found here: http://code.google.com/appengine/docs/python/datastore/gqlreference.html All the restrictions about the Queries you can do are documented here – some are really counter intuitive when you come from an RDBMS enviroment… Ah well ;-) Oh, and yet another great link about GAE limitations.

      Having this limitation, really sucks for my normally “super simple query”, and I’d have to change the data structure somehow or do some awful 2 queries and then combine them in Java (omg teh terrorr… :<). So, while developing on appengine, keep in ming – simple things might turn out quite complicated due to the nature of BigTable. If you know all the limitations when designing the system and not while finishing it, you’ll be a happier man… ;-)

   4. neutral: Primary keys can’t be Integers etc, as AppEngine uses it’s own “Key” type. :-)
3. Having that all said. Appengine’s administration panel is quite ok. And the not-so-newly-added log search etc are really fine tools. Something an plain old tomcat can not offer. On the other hand, the limitations can really be a deal breaker! My app was really fairly simple, and yet appengines quotas managed to really get in my way. Keep this in mind while thinking about using it. You may also try Amazon’s cloud or CloudForce from SalesForce etc… They all do offer a quite less restrictive enviroment.
4. If you’re interested, deployment does take about 5-7 minutes before the new version is visible on the web – so don’t panic if you’re still seeing the old version after deploying the new one.
5. My opinion about GAE…? (semi serious ;-))

“Screw you clouds, I’m going /home!”
(intended southpark pun)

I’ll finish this project using my ol’ pal, Tomcat6 which I’ve already got running for netbeans.edu.pl (but that was an grails app).

I’ve also decided to use Spring, which I didn’t really need on appengine – as the only thing I was doing was so small that all the logic was around 10 lines in the servlets… But if using hibernate and all the other “real” JEE stuff, I felt I’d need to “do this right” so I’ve decided for Spring 3 and Maven2… I’ll try to build this project from gradle soon too!

ALSO! If interested in an more experienced programmers view on appengine (I’m still a novice), go and read this blog post about GAE on Sławek Sobótkas blog. All in all we seem to agree that the limitations can be an pain in the a… ;-)

The source for the appengine version is on my github account. I’m porting it to an plain old tomcat environment and will post this version there too when it’s ready to run (tomcat deployment is somehow hell with such apps for me… Any tips are really welcome :-))

So… Which button is the confirm one…? Yup, the colors are screwed up! I guess that’s becouse they didn’t think that someone could have a dark OS skin that would also skin the buttons dark. Ah wel… Thankfully I use Firefox 3.5 and the Stylish extension! Using this extension you can override a websites CSS styles, and that’s just what i did. The following code can be used to fix all the input button colors:

Notice the !important at the end of the color attribute, that’s what forces this setting to be “final”. Let’s check if the changes fixed our problem…

Ahh… much better!