Groovy and Grails releases in the last months appear so often that it is really easy to miss them. Starting with Groovy: it’s current version is 1.7.4, and the maintenance updates from this branch bring little more than bugfixes, so the below list contains mainly the changes introduced in 1.7.0:

• anonymous inner classes – for Java compatibility

• nested static classes – functionality exists, but it is best to use static nested classes if any

• added annotations on imports, packages and variable declarations – this allows for instance to declare dependencies with Grape within your code

• more readable asserts output with Power Asserts

• AST Viewer and AST Builder to facilitate the use of AST transformations

• Groovy Truth expanded – every class now can customize the way it is evaluated to boolean by implementing its asBoolean() method

• batch updates using sql.witchBatch() and sql.withTransaction()

• numerous improvements in testing, collection methods, GroovyScriptEngine, Groovy console and other

More on this, especially the exact behavior and limitation of nested classes in Groovy 1.7.0 Release Notes.

Unlike in Goovy, in each of Grails 1.3.x branch releases new features are implemented. Its current version (1.3.4) uses Spring 3.0.3. With 1.3.0 and the following quite a few changes were made:

• GORM:

  • dirty checking for domain classes with .isDirty() and .isDirty(’fieldName’) methods

  • Hibernate derived properties – domain class property value can be now calculated from a formula; here is a nice post on derived properties themselves.

  • named queries can be combined – nested within another named query, chained one by one or made more specific by supplying additional conditions when invoked

  • .find() and .findAll() query results can now be cached

• GSPs:

  • default layout – if defined, it will be used by all pages that do not explicitly declare to use one

  • <g:join> tag concatenates strings separating them with a specified delimiter

  • <g:unless> tag is a handier version of negated <g:if>

• filters

  • the order in which filters are executed can be specified

• testing:

  • upgraded to JUnit 4

  • TagLib testing allows to test custom tags that use the pageScope property

• plugins

  • classes, views and templates provided by plugins can be overridden

  • inline plugins don’t have to be plugin-packaged before use

• dependency management:

  • you can specify plugin repositories you want to use in BuildConfig.groovy

  • publishing plugins on Maven compatible repositories

  • declaring plugin dependencies with the IvyDSL

• every-day use:

  • script name typo detection in command line

  • when creating artifacts suffixes like *Controller, *Service are now added only when user hasn’t supplied one

  • multiple HTTP proxy configuration

  • grails doc –-pdf exports generated documentation to PDF and –-init generates a documentation template

Grails release notes for more details:

http://www.grails.org/1.3 Release Notes

http://www.grails.org/1.3.1 Release Notes

http://www.grails.org/1.3.2 Release Notes

http://www.grails.org/1.3.4 Release Notes

As for IDEs – having used Netbeans and Spring Tools Suite lately I must say, that the latter is a long awaited improvement in Groovy/Grails free IDE support. There is still a lot to be done, but at the moment syntax highlighting works quite well, code completions gives some hints without making you wait for ages, and even refactoring works sometimes .

An opportunity to make our first steps in Germany emerged about a week ago, when we were invited by the Wielkopolska ICT Cluster to participate in Berlin-Wielkopolska 2010 Forum, a first conference of collaboration between these two regions.

As nearly everything what is made for the first time, the conference wasn’t surprisingly successful. On the other hand I managed to establish some interesting local contacts and people enjoyed the idea in general – so it could be good start for more future events of this kind.

I have never been to Berlin, even though it is closer to Poznan than Warsaw is (it was shocking for me when I discovered it)! No borders now so travelling was smooth and easy.

It turned out that schedule is so tight we weren’t able to see some more of Berlin. At least we had chance to see a bit more of the most modern technology park in Europe (as Germans say) – one I can tell, they have invested there a lot! It’s called Adlershof and it’s astonishing how fast it grows. I discovered that they’re open for cooperation and they’re kind of forced by the law to reply to my enquiry so it is good news for me – I will definitely take advantage of it.

I hope we’ll find some proper business partners in Germany this year – hopefully the process began.

Minimize HTTP Requests

• connect javascript files  and
• use css sprite

Minimize transferred data.

• Minimize css, js and html files,
• use gzip compression
• use caching – for elements that do not change often use header expires,set it for one year
• optimize jpegs- you can often  make then 50 % size smaller without any visible loss. You can do it  by using tools like JpegTran or Smush.it
• optimize png – use png8 when possible

Check also Best Practises for Speeding Up your website

Strongly recommend  to use tools below

• Firebug – tool for web developement
• YSlow analyses web pages and suggests ways to improve their performance
• PageSpeed gives you hint how to optimalize loading time for your webpage
• JpegTran  optimizes jpg
• Smush.it  optimizes all jpgs at once

First session I was interested in was lead by Andy Budd. Persuasive Design: Encouraging Your Users To do What You Want Them To Do. Andy told us  how  our natural behaviours are used  to make us buy the product.  He went through some persuasion techniques used by advertisers, brands, supermarkets and other people. There is scary amount of those…

He gave examples how those techniques are used in real world and online. Most of us is so used to appearance and behaviour of popular websites that we do not realize that those tricks are used almost everywhere on web !

• Trust in authority – Professional look- white, blue green for webpage of respected medical companies
• Layout and Positioning – using colors, size, positions to emphasize what you would like your user do on your website
• Social Proof – People prefer services where there is already many users- make at least the impression that your service is popular
• Loss Aversion – Last day of promotion, only till the end of the week you pay for our service half price
• Likeability and Gifting – Make people to like your service by for example giving them scores, good rates – people like being rewarded somehow , they like to get sth free : Pay 20 and get 5 for free!
• Reciprocity

Nice study – go via amazon, basecamp, facebook  etc and   check what they did to make us do what they want

The speaker of second session Marek Kasperski concentrate on people behaviour on webpage. The tiltle of this session was Mental Models.  He was giving  advices how to make UI most friendly for users,  there was many  issues he  mentioned, most examples were about e-commerce. he showed proper and wrong designs. Below some facts I remember:

• mind is selective, always trying to find only exact information  and it’s blind for the rest (Banner blindness)  Help users  find what they want – by contrast colours, good filtering of information, group similar information)
• when you design your website try to think like future user
• use colours culturally directed for your website users
• do not leave user with no information when  long response

I bought his book Projektowanie stron WWW (as far as I know only in polish language), I will know more.

Speed Tracer jest dodatkiem do przeglądarki Google Chrome, który umożliwia analizę wydajnościową aplikacji webowych (nie tylko tych tworzonych w GWT). Speed Tracer pozwala na bardzo dokładne przyjrzenie się działającej aplikacji, wliczając w to np. obserwację zdarzeń JavaScript’owych. Zamiast wymieniać następne funkcjonalności narzędzia Speed Tracer, lepiej obejrzeć krótki (1:40) tutorial, gdzie wszystko jest bardzo ładnie pokazane. Warto zwrócić uwagę na naprawdę rewelacyjny interfejs aplikacji (zrobiony oczywiście w GWT ).

Myślą przewodnią nowej wersji GWT są szybsze aplikacje webowe. Szybsze zarówno w sensie szybkości ich działania, jak i szybkości developmentu. Lista zmian i nowości jest naprawdę duża. Zwrócę więc uwagę tylko na te najważniejsze (moim zdaniem).

Wersja 2.0 zdecydowanie poprawia cykl edycja/odświeżenie przez wprowadzenie tzw. development mode, który pozwala uruchomić w trybie debug projekt GWT w dowolnej przeglądarce, a nie jednej, dedykowanej (jak to było wcześniej). Oznacza to, że nareszcie można używać Firefoksa albo Chrome’a przy tworzeniu aplikacji GWT, a wraz z nimi -- pakietu ulubionych rozszerzeń na czele z Firebugiem . Nie obeszło się przy tej okazji bez zmiany Google Plugin for Eclipse, którym teraz można całkowicie kontrolować development mode z poziomu naszego ulubionego IDE . Jeszcze trochę z ciekawostek: development mode działa przez sieć. Można więc “przypiąć się” do zdalnej sesji przeglądarki. Wydaje się to szczególnie przydatne dla Linuksiarzy, którzy mogą tylko zgadywać jak wygląda ich aplikacji w IE pod Windows. (Nawet z GWT pewnych rzeczy się nie przeskoczy…)

Kolejna wielka zmiana, która dla mnie osobiście wydaje się być szalenie interesująca, to wprowadzenie nowego, deklaratywnego sposobu konstruowania interfejsu użytkownika o nazwie UiBinder. Założenie jest takie, by uczynić łatwą (a przy okazji trochę wymusić) separację warstwy widoku od logiki aplikacji. Pomysł polega na tworzeniu dwóch plików dla każdego komponentu warstwy prezentacji. Aspekty widoku zawarte są w pliku .ui.xml, który stanowi “mieszankę” normalnego HTML’a oraz komponentów widoku (ang. widgets). Sama implementacja logiki aplikacji pozostaje natomiast w osobnym pliku .java. Pozwala to na bardzo wyraźną separację tych dwóch zagadnień i np. bardziej efektywną współpracę programistów oraz web designerów. Dodatkowo, w czasie kompilacji sprawdzane są wszystkie referencje między powyższymi plikami, więc nie ma mowy o żadnych literówkach i tego typu błędach. Naturalnie, Google Plugin for Eclipse wspiera to rozwiązanie w 100%, wliczając refactoring, uzupełnianie kodu itd.

Najnowszy Google Web Toolkit wprowadza również tzw. layout panels, pozwalające na dokładne rozmieszczenie elementów w obrębie strony. Nie ma co ukrywać, że używając HTML i CSS jest to duży problem, który najczęściej wymusza użycie pewnych “sztuczek”. Nawet we wcześniejszych wersjach GWT czasami trzeba było pokombinować, żeby coś wyglądało tak jak trzeba we wszystkich przeglądarkach. Nowe rozwiązanie bazuje tylko na standardzie CSS, co ma dać layout nie tylko bardziej stabilny i przewidywalny, ale również szybszy (znane są dość spore problemy wydajnościowe przy zmianie rozmiaru okna przeglądarki we wcześniejszych wersjach GWT). Layout panels, jak łatwo się domyślić, doskonale sprawdzają się w połączeniu z UiBinder.

Kluczową nową funkcjonalnością w GWT 2.0 jest programowe rozdzielanie kodu (ang. code splitting). Polega to na wskazaniu (w kodzie źródłowym), które komponenty muszą być wczytane “z góry” i są konieczne do załadowania aplikacji, a które można doczytać chwilę później. To tak trochę jak oglądanie filmu na YouTube: nie trzeba przecież wczytać całości, żeby rozpocząć oglądanie. Moim zdaniem to świetne rozwiązanie. Mamy do czynienia przecież z aplikacjami webowymi; tutaj nie może być poczucia, że coś jest “instalowane”. Taką aplikację otwieramy i już ma być; każąc użytkownikowi czekać 15 sekund na pojawienie się pierwszego ekranu, możemy go łatwo stracić. Świetne wyniki tutaj uzyskał zespół Google Wave. W chwili obecnej skompilowana, pełna funkcjonalność tej aplikacji to “ważący” prawie 1500 kB JavaScript, który trzeba przecież ściągnąć od razu. Dzięki zastosowaniu rozdzielania kodu, początkowo użytkownik ma do pobrania 200 kB (a po kompresji już tylko 80 kB), a reszta jest “dociągana” w czasie, gdy zastanawia się gdzie by tu kliknąć. Różnica właściwie o rząd wielkości! Częściowo zasługa w tym również nowej wersji kompilatora, który tak czy inaczej “odchudza” kod nawet o ponad 20%. Można bez problemu skompilować starsze aplikacje. W moim ostatnim projekcie w GWT dało to oszczędność 14% (właśnie sprawdziłem ) tak po prostu, bez dotykania kodu źródłowego.

Z mniejszych zmian, nastąpiło ulepszenie mechanizmu paczek (ang. bundles). Teraz zamykać w paczki można nie tylko grafiki, ale pliki dowolnego rodzaju. Jest również specjalny rodzaj paczki dla plików CSS, który automatycznie optymalizuje dołączone arkusze stylów.

Podsumowując, GWT 2.0 wydaje się być znaczną aktualizacją tego produktu. Poprawiono zarówno efektywność pracy z technologią (co w konsekwencji zmniejsza koszt tworzenia oprogramowania), jak i wydajność samych aplikacji. Google Web Toolkit niewątpliwie potwierdza swoją mocną pozycję na rynku nowoczesnych technologii front-end’owych dla aplikacji webowych. Dla mnie osobiście, jest to już od dawna faworyt w tej kategorii, który coraz bardziej rośnie w siłę. Gorąco zachęcam do pobrania nowej wersji biblioteki i przyjrzenia się wprowadzonym zmianom. Zainteresowanych kieruję na stronę produktu.