ars-codia

Android 4 GWT and SOP

noreply@blogger.com (Raphael) — Tue, 24 Jan 2012 10:34:00 +0000

My company and me just released the first version of our GWT mobile iOS / Android App crossover project. It's a cross plattform gwtp App using our own AppRig mobile framework (to be released at some point).

https://market.android.com/search?q=kunstwegen

I already talked about Android and its browser. I think Android's webkit is really lightyears ahead of iPhone's webkit in terms of stability and feature support.

We had to overcome several problems to make it run without any Problems on Android devices from 2.0.

Just recently I tried the App on Android 4 and - boom - our app doesn't work there. The reason was that Android 4 throws a SOP on the filesystem.

Not sure if this is a bug or feature, but you have to add an xs linker
linker to make it run...

Hope that helps anybody - took us a while to figure this out...

Android Big Bug Browser

noreply@blogger.com (Raphael) — Mon, 23 Jan 2012 23:53:00 +0000

Did I already mention that Android has a really bad browser?

I mean seriously. WebKit is known to be one of the best html engines out there. Safari is built on that, Netflix uses it for their platform dependent development. And it boasts a great mobile Webkit used on iPhone / iOS.

And Google did something smart: They are using the very same WebKit for their Android.

But.

Android's browser has so many bugs and runs absolutely unstable. I experienced a lot of bugs in 2.3 series (strange layout issues as well as muti touch issues). Even more bugs on Android 3 (Some websites just crash the browser reliably wtf?). And - just recently - I tried Android 4.0.3 - only to discover that they introduced a same origin policy for file:// . Is that a feature or again a bug?

I really don't know.

iOS on the other hand? Rock solid for years now. It's such a huge difference.

What the heck is going on?

Lion tweaks for developers

noreply@blogger.com (Raphael) — Mon, 23 Jan 2012 23:40:00 +0000

I just upgraded my dev machine from Snow Leopard to Lion.

Hmm. The good news is that Lion is pretty similar to Snow Leopard / Leopard. The only difference is that Apple tries to mimic iOS on a Mac via Mac App store / Launchpad and a huge amount of mouse gestures.

It think that's crap and introduces a lot of stuff that's not needed on a dev machine.

But it's simple to make Lion a great dev machine:
- Make sure you format your disk using a filesystem that preserves upper / lowercase of filenames
- Install macports (mercurial, git etc)
- Install Java (simply open "Java preferences" and click on install)
- Show all files in Finder: defaults write com.apple.Finder AppleShowAllFiles YES
- Disable dashboard: defaults write com.apple.dashboard mcx-disabled -boolean YES
- Spaces and expose is now called Mission control. Not much changed, but you should deactivate the automated rearrangement of spaces according to usage
- Apple changed the scrolling direction up down becomes now down up. I get the point it's now like dragging on a TouchDevice - but still - I changed it back to the old value.
- Mac also hides the scroll bars automatically. Wtf? If you are coding: Turn it on ;)
- XCode comes now via the Mac App Store (But only as installer...).
- The two finger wipe left / wipe right gesture completely screws up nice browsing. I turned it off.

The whole upgrade took around 2hrs. Back for good... ;)

GWT Firefox 9 Plugin

noreply@blogger.com (Raphael) — Sun, 22 Jan 2012 19:40:00 +0000

Alan Leung just released a new xpi for Firefox. What a pleasant surprise. GWT dev mode is superfast. Never saw it that fast and stable. Much better than on Safari or Chrome right now (from a Mac perspective).

Thanks Alan!

http://www.mediafire.com/?831pp1kk5p8kgjd

Languages and fun

noreply@blogger.com (Raphael) — Sat, 21 Jan 2012 20:08:00 +0000

That's a hilarious video: https://www.destroyallsoftware.com/talks/wat

i18n and design

noreply@blogger.com (Raphael) — Thu, 19 Jan 2012 17:25:00 +0000

Ever wondered why Google layouts forms in a way that they are horizontally stacked? Hmm. It's simple... the reason is i18n - right-to-left left-to-right in particular.

Great post about Google's internal i18n guidelines:

http://googlewebmastercentral.blogspot.com/2011/09/internationalization.html

Play! eclipse drop-in - for even better eclipse support

noreply@blogger.com (Raphael) — Thu, 19 Jan 2012 13:00:00 +0000

I just recently learned that Play Framework features a simple drop-in for eclipse. Well - actually I new that such thing existed, but I thought it's too complicated to install. But just the contrary.

Installation is really simple - everything is already bundled with your play distribution. It's a jar (at support/eclipse) that you simply copy into the eclipse/dropin folder.

After installing the droping you get:
- syntax highlighting of application.conf
- syntax highlighting in html views (but eventually the html editor from Eclipse WTP is better)
and best:
- syntax highlighting and simple jumping from your routes file to the implementing classes and methods. That really speeds things up.

If you did not yet install the droping you should do it now :) It's really a productivity boost and simple :)

More:
http://www.playframework.org/documentation/1.2.4/ide

Why Google Web Toolkit is a fantastic idea - Part 3: The future of GWT

noreply@blogger.com (Raphael) — Fri, 30 Dec 2011 10:29:00 +0000

Still Alive by Social Distortion on Grooveshark

And the times have changed my friend
I’ll be here to the bitter end
Social Distortion - Still alive

Intro
Part 1 Showed you a lot of examples where GWT is actually used
Part 2 outlined use cases and pros / cons of GWT.

This Part 3 will talk about the future of GWT.

GWT - a solid basis for my web apps
We are using GWT in various setups since GWT 1.6 internally. From really small projects up to bigger projects where around 50 people are working in several teams on the very same GWT project.

GWT never let me down. I especially like that GWT is super flexible, allowing regular HTML and CSS markup since UI Binder came into being. It is a fantastic technology and does a great job transforming Java developers into Javascript Ninjas. It provides type safety, a super great ecosystem and a first class tool chain (Eclipse, Maven, Java libs, Jenkins etc). This makes it possible to develop "fat client Ajax clients" with a lot of people Jenkins.

Google calls this "Web apps". And GWT is perfect to develop those web apps. I cannot imagine 50 people working on the same javascript-only codebase. But - I am sure this is working...

Google plus, closure and doubts about Google's support for GWT
...and it is working. In Mid 2011 it became a bit quiet regarding GWT (at least I felt that way). There were severe problems with the dev mode regarding the latest Macbrowser generation that nobody at GWT seemed to notice [4]. And it became a bit too quiet at the GWT mailing list. Then Google Plus was released. And it used: Closure [3]. Damn.

That hit. But it became even worse.

What's that dart thing all about?
Some weeks later Google announced Google Dart. A new kind of language and a possible replacement for Javascript [2].

So there is stood. Some years of GWT experience. And no idea where we'll go.

I like change - when I am in control
To be honest: Technology changes. The way we used to write Java code 5 years ago is completely different to what we do now. Javascript will change. The way we use the web will change. I am PRO change. I like change. I even like some kind of insecurity because it keeps us moving. But still - I wanted to know what's going on.

Regarding Dart and GWT
I think Dart is not a good idea. I especially don't like the mixed static / dynamic type system. Not something I would use. I also don't like yet another coding syntax. What's the point? So my bet is: Dart is academic and will be dead soon. Or - it will be an intermediate step to translate stuff into Javascript.

It's also interesting to read Oliver's post a the webkit mailing list when Google asked if Dart could be implemented by Webkit:
Oliver says:
This is an academic exercise as it doesn't match webkit's goal of being a standards compliant engine, and also has dubious advantage even when supported. [1]

Regarding Closure and GWT
I think Closure is just great. For javascript coders. But if you want to turn Java developers into Javascript ninjas you can't give them closure. Give them GWT and they will be happy. I guess this is what happened inside Google. Some teams just prefer the Java side of things - those teams use GWT for their projects. Others are great Javascript coders - Closure is a natural fit. Dart? Yea. Still no idea where the place for that is... I don't think Closure will replace GWT or the other way round. Both make sense for a company like Google.

Why GWT's future looks bright - evidence
I began collecting intelligence about GWT. What the heck was Google's plan with GWT?

Evidence from Dr Fibonacci aka David Chandler (Google GWT team)
David Chandler told me that GWT is used in a huge amount of projects internally (at a time when only the AdSense client was visible outside). Convincing. I wrote about our telephone call briefly here [9].
David also outlined this in written form via his blog (check out the comments) [8]:
Hi Raymond, it’s much too early to discern what may happen. Google uses GWT in over a thousand projects internally, whereas Dart is brand new. Google continues to invest in GWT and will continue to support it for a long time to come because it is used so widely within the company. So no, Google is certainly not putting all its eggs in the Dart basket.

Evidence from Eric Clayberg (GWT Google team)
The reply of Eric Clayberg to this G+ post [5] sates that I can assure you that GWT is not "dead" at all. Not even close! Quite the contrary. Aha.

Evidence from Bruce Johnson (Google)
Bruce Johnson writes at the GWT blog says that GWT will be supported a long time and that GWT and Dart are close allies in the fight for web apps [6].
This leaked Google doc highlights that GWT and JScompiler are on a merger and can be easily integrated into Dart in the future. While this is cool - it also highlights that GWT will stay for a long time if Dart fails. And even if it does not fail there is migration path in terms of tools.
What is the future of the JSCompiler and GWT?
JSCompiler and GWT were already on a merger path. This effort gives us a
direction for that unification around the Dash language. We will actively
support teams for a long time on the current generation of JSCompiler and
GWT and provide fantastic co-existence and migration tools to Dash.

Conclusion
- GWT is the very best web app (aka best ajax fat client) dev tool for for Java developers.
- GWT is here to stay for a long time.
- Hooray!

[1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html
[2] http://en.wikipedia.org/wiki/Dart_(programming_language)
[3] http://code.google.com/closure/
[4] http://ars-codia.raphaelbauer.com/2011/07/mac-safari-505-does-not-work-with-gwt.html
[5] https://plus.google.com/u/0/112745976227102540584/posts/MjZgFK6gjLq
[6] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[7] https://gist.github.com/1208618
[8] http://turbomanage.wordpress.com/2011/10/10/first-thoughts-on-dart/
[9] http://ars-machina.raphaelbauer.com/2010/12/why-future-of-google-web-toolkit-looks.html

Why Google Web Toolkit is a fantastic idea - Part 2: Use cases for GWT

noreply@blogger.com (Raphael) — Thu, 22 Dec 2011 20:20:00 +0000

Reach for the Sky by Social Distortion on Grooveshark

Reach for the sky because tomorrow may never come.
Social Distortion - Reach for the sky

Part 1: Who is using GWT?
Part 2: Use cases for GWT
Part 3: The future of GWT

There are Pros and Cons for anything. You won't here me saying: "GWT is the best thing in the whole wild world. Please marry GWT". En contraire. GWT is a great technology. But you have to know when it makes sense to use GWT. And when not.

GWT is a toolkit.
Means 100% degrees of freedom. But also means 100% complexity if you don't know what you are doing. GWT is just a cross compiler from Java into Javascript. At the end everything you write becomes Javascript. With all limitations of Javascript. You can reuse large parts of the Java eco system including a lot of libraries and the standard Java libraries. Still. You have to know what libraries to use.

Based on Java and it's ecosystem
Is Java as syntax an advantage? Well. Guess we can discuss that for a very long time. But at least we can agree that Java's ecosystem is a huge advantage. Maven as build- and also as library management tool. JUnit as Unit testing framework. Bug checking software like findbug and checkstyle. And most prominently: IDE's like Eclipse, Netbeans, IntelliJ. And even more important: By basing GWT on Java we automatically have statically typed types - allowing all IDE's to use code completion and error checking while you type.

While Java might be strange at some places (anonymous inner types making stuff a bit complicated to read) - it is well worth all cons because of the great ecosystem. No other language I know can deliver that.

Big projects - tested code - productive teams
If you imagine 10 teams working on a Javascript based fat client it sounds strange. At least to me. I know that Javascript is great. I also know that there are great Javasscript hackers out there.

But my personal experience with Javascript and affiliated languages is that it becomes a mess when more than 1 person works on it. JQuery is great to enhance a html site. But a whole fat client written in Javscript? No way. You have to test your stuff. You want to reuse code. You want to use real tooling. And you don't want to have a loosely coupled mix of server side html technology and javascript + page reloads.

Using GWT you can make your team productive for free. You are automatically use proven tools from the Java world that drive the biggest projects.

Once codebase to rule them all...
A productivity boost also is the usage of the same language on client and server side. NodeJS and a javascript client for instance. Or - GWT on the client side and Play! on the server side. Play! is a great and agile framework for the development of web applications. The great thing are fast turnarounds, concise error reports and a fully integrated testing stack. If you combine both - Play and GWT you get a really productive experience for your programmers. All is Java. Same tooling everywhere. I outlined an exemplary setup in Part 3 of the series.

... and go "app" mobile
By designing a stateful Html client you already have almost everything to get you whole app offline. There is a clearly defined point where the client talks to the server. And even better - you can take that client (including all compiled source, css, html) and repackage it via eg. gwt-phonegap and publish it on popular stores. We did this successfully for the Android store and Apple's App store. There are even some great widget libraries that allow you to use widgets that really look "mobile" for your plattform. M-GWT is an example, but there are others, too.

If you think about what it would cost to maintain two or more codebases (iPhone, Android and a web application) it becomes clear that GWT really really rocks.

Points to be aware of
If you are using a "separate" client and server logic you will lose some productivity that integrated approaches will deliver (RoR, Play!...). You need clearly defined endpoints, you cannot simply use models inside your views.

The good thing is: If you design your app like a service. With the server being just the endpoint to deliver your data (JSON, RCP etc) it will be much easier to test your server and omit spaghetti code. It's a classcial trade-off. But if you want to write a reasonable big application I would want to rely on a nicely tested service.

The other thing to consider is SEO. GWT is javascript. If your site is Javascript your html will be empty and there will be nothing for a search crawler to index. But Google released a hashtag crawling approach that solves this. And the cool thing is that Bing supports that approach, too. I wrote about it briefly here. Downside is, that you need a headless browser on your server. You must consider this while planning your app.

GWT cool things
A simple listing:
- Code splitting: GWT automatically splits your code into small pieces that will be loaded automatically
- Code optimization: GWT optimizes your Javascript code.
- Debugging: You can debug your code using your favorite Java IDE.
- Tooling support: Use Java's toolchain (described in more detail above)
- Great ecosystem: Gin (dependency injection), GWTP (MVP framework), GWTQuery (jQuery clone that's even faser than the original jQuery), resty-gwt for connecting to restful APIs.

Example projects where GWT rocks
GWT in my opinion excels when it comes to "web apps". The definition if a web app is really hard. Think of GMail, think of Google Docs, think of Facebook. Think of LinkedIn. These are all huge sites that do feel more like a Desktop Application than like a bunch of html pages being loaded. You just entered the world of stateless web clients.

Google uses this notion in many of their projects. Pros are: Great user experience. Faster response times. Great developing experience. Independent of server technology. Rendering outsource to client.

GWT is one of the technologies that is especially great when used in such a scenario.

Part 1 already showed you a lot of examples for those kind of web apps.

Continue with Part 3 and learn why the future of GWT looks bright.
http://ars-codia.raphaelbauer.com/2011/12/why-google-web-toolkit-is-fantastic_30.html

GWT and strange gwt-unitCache directory

noreply@blogger.com (Raphael) — Wed, 07 Dec 2011 10:24:00 +0000

You can use GWT using the built in Jetty as webserver.

But you can also combine any webserver, GWT (configured by maven) and the dev code mode. That's what we do - we use Play! as webserver and GWT and it's dev mode on top. I only can recommend the setup.

However, since GWT 2.4 we are getting a strange gwt-unitCache that is generated into our deployment directory. gwt-unitCache contains a lot of files we do not need. It is configurable somehow, but it did not work out for us. Check out http://code.google.com/p/google-web-toolkit/issues/detail?id=6397 for more infos.

So one simple solution is to delete the directory after running install.

Using Maven it is really simple:

http://code.google.com/p/google-web-toolkit/issues/detail?id=6397

That's the plugin config:

<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<filesets>
<fileset>
<directory>../YOUR_DEPLOYMENT_DIRECTORY</directory>
<includes>
<directory>gwt-unitCache/**</directory>
</includes>
<followSymlinks>false</followSymlinks>
</fileset>
</filesets>
</configuration>
<executions>
<execution>
<id>gwt-unitCache</id>
<phase>install</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>

GWT snipplets: Centering vertically and horizontally

noreply@blogger.com (Raphael) — Tue, 06 Dec 2011 09:14:00 +0000

Sometimes you want to center stuff horizontally and vertically.

This is really simple using GWT's HorizontalPanel and it's Alignment Constants.
Here is the ui binder based code:

<g:HorizontalPanel width="100%" height="100%">

<g:cell horizontalAlignment="ALIGN_CENTER" verticalAlignment="ALIGN_MIDDLE">

<g:HTMLPanel>
<p ui:field="label" class="{style.text}"></p>

</g:HTMLPanel>
</g:cell>


</g:HorizontalPanel>

Why Google Web Toolkit is a fantastic idea - Part 1: Who is using GWT

noreply@blogger.com (Raphael) — Mon, 05 Dec 2011 07:45:00 +0000

Machine Gun Blues by Social Distortion on Grooveshark

I just left your town, took all your loot,
bought a pink carnation and a pinstripe suit,
a hopped-up V8 Ford and some two-tone shoes
Social Distortion - Machine Gun Blues

Intro
This series of blogposts will convince you that GWT - Google Web Toolkit is fantastic. It is not only fantastic but is fun to use and will save your company a lot of money.

Part 1: Who is using GWT?
Part 2: Use cases for GWT
Part 3: The future of GWT

Who is using GWT?
The first question when seeing a relatively new technology is: Who is using it? Is it stable? Can my new project be made with GWT? Is GWT a good long term investment?

GWT at Google
GWT is developed by Google. So let's check which projects at Google are using GWT:

AdSense and AdWords: http://www.google.com/adsense/
Just to be clear: Google is making almost all of its profits from AdSense / AdWords. And they are using GWT for their single most important application. Means there is at least some trust in GWT's capabilities - to be modest ;)

Google Offers: https://www.google.com/offers
Google Currents Producer: https://www.google.com/producer
Google Flights: http://www.google.com/flights
Google Hotelfinder http://www.google.com/hotelfinder
Google Moderator: http://www.google.com/moderator/
Google Groups: http://www.google.com/groups
Google Takeout: https://www.google.com/takeout/
Google Pagespeed: https://developers.google.com/pagespeed/
Google WebFonts: http://www.google.com/webfonts
Google Blooger Admin: http://www.google.com/blogger
Google Code Api Project: https://code.google.com/apis/console
Google Apps Script (for UI)
Google Apps Script Editor
Google Fusiontables: https://www.google.com/fusiontables/DataSource?dsrcid=2049253
Google Checkout Store Gadget (in Chrome WebStore)
Google Webmaster Tools: https://www.google.com/webmasters/tools/home
Orkut (Google's Brazilian Social Net): http://www.orkut.com/

GWT abroad
There are also a lot of projects and companies that began using GWT. Some of them:
PlayN - The basis of Angry Birds for Chrome - http://code.google.com/p/playn/
Gerrit: http://code.google.com/p/gerrit
Google Wave. "follow" popup in Google Buzz (discontinued)
https://www.rara.com/
JBoss JBPM Console: jbpm console.
http://www.ovirt.org/
Angry Birds Chrome

Summary
There are two interesting things.
1. GWT is used A LOT by Google. And this is for sure only the beginning. GWT is here to stay for a long time. And GWT works for projects of any size and for projects with any priority.

2. You do not recognize GWT. GWT is invisible. And that is a strong point and a thing to understand when talking about GWT. You can layout, design, do whatever you want to do with your GWT app. It's just a toolkit. Well. A great toolkit to be precise. But think of Google Flights or Google Deals - don't they just look great? Well - I do think so.

URL encoding howto

noreply@blogger.com (Raphael) — Thu, 17 Nov 2011 07:46:00 +0000

Just recently I came across the question how to represent the following url correctly:
http://mydomain/user@otherdomain/bucket of tears (@ and spaces not yet encoded).

I had a case where a 3rd party library translated this into
http://mydomain/user@otherdomain/bucket+of+tears

But wasn't replacing space with + -- used for query parameters? After some investigation I found out that the correct path is: http://mydomain/user@otherdomain/bucket%20of%20tears

On the way I found two great posts you should not miss if you do anything with URLs:
Stéphane Épardaud from Lunatech: http://www.lunatech-research.com/archives/2009/02/03/what-every-web-developer-must-know-about-url-encoding
KLORTHO: http://sinophibe.blogspot.com/2011/07/proper-url-encoding-and-decoding.html

How to write a custom Callback Filter for RestyGWT

noreply@blogger.com (Raphael) — Tue, 15 Nov 2011 12:20:00 +0000

RestyGWT [1] is one of the coolest libraries when you want to connect a GWT client with a RestFul interface.

This post will explain how to implement your own dispatcher and callback as RestyGWT filter.

First of all: Why would you want to implement your own dispatcher and callback?
- Do caching on the client side - only execute real calls to the server if the result is not cached.
- Do automated transmitting of XSRF tokens
- Do handle security errors - eg forcing a redirect to a login url when RestyGWT gets a Authentification error.

So there are a lot of reasons why it makes sense to put some logic in between sending and contacting the server. That's what the dispatcher is supposed to do.

RestyGWT allows us to apply a filter chain (so you can apply more than one "check" to the dispatcher) what is pretty cool. Using a filter you can chain a XSRF token sender, caching and other filters.

In my case I wanted to make sure my GWT client gets redirected to "/login" when a 403 status response is received. Theoretically, You can do the checking in the MethodCallback, but a custo callback is better as it allows you to use one central position to do so.

For that we need three things:
1. A custom methodcallback, that checks for a 403 (Forbidden).
2. A filter that sets the callback
3. A bit of configuration (done via GIN)

1. The ForbiddenDispatcherCallback looks like that:

public class ForbiddenDispatcherCallback implements RequestCallback {
 protected RequestCallback requestCallback;

 public ForbiddenDispatcherCallback(Method method) {

  this.requestCallback = method.builder.getCallback();
 }

 @Override
 public void onResponseReceived(Request request, Response response) {
  
  if (response.getStatusCode() == Response.SC_FORBIDDEN) {
   
   //make a hard redirect to login page
   Window.Location.assign("/login");
   
  } else {
   
   requestCallback.onResponseReceived(request, response);
   
  }

 }

 @Override
 public void onError(Request request, Throwable exception) {

  requestCallback.onError(request, exception);

 }

}

2. The The dispatcher filter simply continues the chain, but adds our ForbiddenDispatcherCallback in between.

public class ForbiddenDispatcherFilter implements DispatcherFilter {

    
 @Override
 public boolean filter(Method method, RequestBuilder builder) {
  
  builder.setCallback(new ForbiddenDispatcherCallback(method));

  return true;
 }

}

3. Configuration is really simple if you use Gin. Important is:

      final FilterawareDispatcher dispatcher = new DefaultFilterawareDispatcher(); 
        
        restServiceProxy.setDispatcher(dispatcher);   
        dispatcher.addFilter(new ForbiddenDispatcherFilter());

The complete configuration looks like:

public class ServiceModule extends AbstractGinModule {

    String URL_PREFIX_RUNNING_ON_SERVER = "/api/v1/";

    @Override
    protected void configure() {
    }

    @Provides
    @Singleton
    public ApiService provideApiService() {

        ApiService apiService = GWT.create(ApiService.class);
        RestServiceProxy restServiceProxy = ((RestServiceProxy) apiService); 
   
        restServiceProxy.setResource(new Resource(URL_PREFIX_RUNNING_ON_SERVER));
        
        final FilterawareDispatcher dispatcher = new DefaultFilterawareDispatcher(); 
        
        restServiceProxy.setDispatcher(dispatcher);   
        dispatcher.addFilter(new ForbiddenDispatcherFilter());

        
        return apiService;
    }
}

And that's it. This we just wrote a filter for RestyGWT that does a hard redirect when it receives a 403.

Thanks to Hiram and the RestyGWT committers. And pansen for providing the filter chaining feature :)

[1] https://github.com/chirino/resty-gwt

How to implement a secure authentification system for Play on App Engine

noreply@blogger.com (Raphael) — Fri, 11 Nov 2011 10:11:00 +0000

The problem:
A lot of our apps are running on Google App Engine (GAE). Unfortunately GAE only supports https via their appspot domain [1]. That will change in the future, but right now it is not possible plus it will be expensive once it's in place.

In practise - that means that when a user comes to http://www.sciplanet.com/login and wants to login - all password stuff goes over the line unencrypted. That's totally not acceptable.

So let's fix that.
A little constraint: The user should (almost) always use and see in his browser bar http://www.scisurfer.com . For marketing issues, because of the brand. Because of the short name. Telling all users to use https://sciplanet-hq.appspot.com would be not that great idea I guess.

So what we are doing is:
- When a user wants to login at scisurfer.com/login she gets redirected to https://sciplanet-hq.appspot.com/login that handles everything in a secure way.
- A session is granted for https://sciplanet-hq.appspot.com

That's nothing special apart from the not magic redirect.

The next thing to solve is to transfer the session from http://sciplanet-hq.appspot.com to http://www.sciplanet.com . We cannot simply hack the cookie because of security constraints implemented by browsers (what is a good thing by the way).
So the solution is: When we are at https://sciplanet-hq.appspot.com/login and everything is fine we are storing a token in memcache that lives for one minute. We then redirect to http://www.sciplanet.com/login/token_auth?token=TOKEN . If the token is valid for the user and in memcache we put the user into the session and the session is authentificated on http://www.sciplanet.com .

All api calls, and everything else on http://www.sciplanet.com now works as expected, but no password was ever transmitted over the line unencrypted. Mission accomplished.

We are talking by the way about signed user sessions of Play.

I extended the library I am maintaining at http://code.google.com/p/play-siena-user/ with the necessary code.

Simply put the following two variables into your application.conf:
playsienauser.regularUrl=http://www.sciplanet.com
playsienauser.secureUrl=https://sciplanet-hq.appspot.com

and all session signing on both domains is done for you :)

Feedback always appreciated! Drop me a line :)

[1] http://code.google.com/appengine/kb/general.html#httpsapps

GWT project layout - Part 3: Integrating GWT frontend and restful Play backend

noreply@blogger.com (Raphael) — Wed, 19 Oct 2011 08:38:00 +0000

Part 3 extends the setup described in Part 2 (Maven and GWT) [3] to the server side.

We are following the best-practise of using Maven for building our GWT application. Maven is really cool, because it allows for:
- simple management of libraries
- simple upgrading of libraries / switching to a new GWT version
- simple testing of application
- nice integration into continuous build process (jenkins and such)

Nice. Now we got a GWT client running on the client side. But what about the server side?
GWT offers 2 RPC mechanisms that are based on Java servlets. While these RPC mechanisms are great in principle I do not like them because they are 100% proprietary [1].

When it comes to http and communication the coolest non-proprietary "technology" is REST. Well - REST IS http I guess ;) So why not use POST GET DELETE PUT and a json generation machine on the server and a rest-eating GWT client to exchange data?

Killer combination if you ask me. There is a great REST library for GWT called resty-gwt [2]. It makes parsing and defining REST endpoints a super-simple task.

I was looking around quite a while for finding a suitable server technology. I simply did not like Java servlets and J2EE. If you have to restart your server to see the actual changes you just implemented you end up being not productive. GWT's development mode is quite fast, but then always having to restart your server? Nay.

I tried a lot of backend technologies and stacks (Rails, Grails, Roo, etcpp), but I ended up using Play! Play is a mainly Java framework, so you can use your favorite IDE to write code. It is stateless - meaning you can change code, hit reload and see the new results - fast turnarounds - yea! And almost all of the framework is statically typed (it's Java after all). Plus it features a nice mechanism to define routes and convert objects into Json representations. Nice.

Key benefits of Play are:
- Play has superfast server turn- arounds. Change something, reload and boom you can continue developing. Yea!
- Simple definition of restful and human readable routes
- Simple conversion of Objects to Json

General benefits of the GWT + REST + Play approach:
- Simple switch of frontend and backend technology. GWT will be dead at some point, Play will be dead at some point, but http will stick around for some time to come...
- You design your application as a service, what is incredibly useful when you want to test or extend your application. It is just way cleaner having nice url schemes to identify and alter data (than eg RPCs).

I recently held a presentation about the concept. And I also implemented a fully working demo project.

Check it out and free to try it and send feedback :)

Presentation is at: http://goo.gl/E1KJ8
Demo project is at: http://goo.gl/XeUEE

[1] http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html
[2] https://github.com/chirino/resty-gwt
[3] http://ars-codia.raphaelbauer.com/2011/01/gwt-project-layout-part-2-large.html

Styling GWT's Splitlayoutpanel

noreply@blogger.com (Raphael) — Mon, 17 Oct 2011 15:36:00 +0000

Styling GWT's SplitLayoutPanel is quite simple using the UiBinder facility.

In your ui.xml simply set an @external .gwt-SplitLayoutPanel-HDragger and style it accordingly. @external turns off selector obfuscation, so that .gwt-SplitLayoutPanel-HDragger stays .gwt-SplitLayoutPanel-HDragger.

As the Splitpanel's properties are sometimes hardcoded we need !important.

<ui:style>
@external .gwt-SplitLayoutPanel-HDragger;

.gwt-SplitLayoutPanel-HDragger {
width: 5px !important;
background: grey;
}
</ui:style>

GWT and invisible LayoutPanels

noreply@blogger.com (Raphael) — Wed, 12 Oct 2011 15:35:00 +0000

Sometimes these funny LayoutPanels are invisible.

Just stumbled upon that several times while porting old code.
The solution is simple: LayoutPanels need RequiresResize in their parent widgets. If one widget in the hierarchy does not implement it properly you'll get strange results...

For instance invisible or only partly visible LayoutPanel. LayoutPanel under a SimplePanel is such a case.
LayoutPanel under LayoutPanel works just fine.

The same is true for a LayoutPanel under a RootPanel - does not work. LayoutPanel under a RootLayoutPanel works.

Thanks to Hilbrand Bouwkamp for pointing that out: http://stackoverflow.com/questions/6740617/gwt-layoutpanel-size

Android cheat sheet

noreply@blogger.com (Raphael) — Mon, 22 Aug 2011 14:02:00 +0000

Storing log files:
./adb logcat -d > myfile

Starting emulator with bigger partition size:
./emulator -avd testing -partition-size 1000 -scale 0.8

Android emulator partition size

noreply@blogger.com (Raphael) — Mon, 22 Aug 2011 13:36:00 +0000

When you need more partition size this command line comes to the rescue:

./emulator -avd testing -partition-size 1000 -scale 0.8

gives you 1 gig of size for the app you want to test...

Wow - iOS 5 gets garbage collection

noreply@blogger.com (Raphael) — Tue, 16 Aug 2011 14:21:00 +0000

Now this is really interesting.

Objective C aka iOS aka Mac OS X gets a garbage collection (sort of). They call it Automatic Reference Counting - and it's driven by the compiler [2]. Cool. LLVM seems to drive this change and I can only welcome it :)

Managing references yourself is great. Theoretically. But in reality it's number one reason for bugs and slow performance of your apps. The compiler / Garbage collector can do that way better than you in almost all cases.

Apple says that:
Automatic Reference Counting

Automatic Reference Counting (ARC) for Objective-C makes memory management the job of the compiler. By enabling ARC with the new Apple LLVM compiler, you will never need to type retain or release again, dramatically simplifying the development process, while reducing crashes and memory leaks. The compiler has a complete understanding of your objects, and releases each object the instant it is no longer used, so apps run as fast as ever, with predictable, smooth performance. [1]

[1] http://developer.apple.com/technologies/ios5/
[2] http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting

Mac Safari 5.0.5 does not work with GWT developer plugin

noreply@blogger.com (Raphael) — Wed, 27 Jul 2011 14:55:00 +0000

In short: Aaaaaahhhhhhhh!!!!!!!!!!!

Seems that the latest Safari update is incompatible with GWT developer plugin. Sure - there is still Firefox and Chrome. But Chrome is too slow and therefore absolutely unproductive - and Firefox has no Webkit engine. Especially if you are working on a Mac and a lot in mobile (often webkit) development you are f*****.

Personally - I cannot really understand why Google's GWT team did not tell "us" this in advance. Plus - I thought that all Googlers are using Macs - so - aren't they hit by this equally hard?
If so many teams at Google are using GWT internally - isn't that a huge problem for Google?

Or - is GWT in decline and nobody gives a damn if a popular browser on a popular platform is supported?

I don't know for sure. Activity around integration of mobile features let me think that GWT is under active development. But again - if you are developing for mobile platforms and want to have a more or less reliable dev platform you need Safari. And Safari dev support is broken for now - strange.

There is a way round as described in [1].
Grab an old version of Safari 4 [2] or 5 [3] - grab Pacifist [4] and simply extract Safari.app to a location you like. It works like a charm.

But that is only a workaround. Be sure not to use the old Safari in the real world as it contains severe security problems.

[1] http://groups.google.com/group/google-web-toolkit/browse_thread/thread/b8827956a9b13bfb
[2] http://support.apple.com/downloads/Safari_4_0_3
[3] http://appldnld.apple.com.edgesuite.net/content.info.apple.com/Safari5/041-0564.20110413.Fi9pb/Safari5.0.5SnowLeopard.dmg
[4] http://support.apple.com/downloads/Safari_4_0_3

Backups of Google App Engine Data

noreply@blogger.com (Raphael) — Tue, 26 Jul 2011 10:32:00 +0000

First of all the following advice only works for data stored as entities in the gae datastore. It does not work for data stored in the blobstore [1].

First of all you need to do two things:
1. Download and install the latest GAE Python SDK (YES - even if you are using GO or Java).
2. Make sure you have a handler that provides the remote_api as endpoint (A servlet in web.xml in java called com.google.apphosting.utils.remoteapi.RemoteApiServlet).

Then you are ready to download your data.
A full dump / restore as (as far as I can tell) proprietary sql goes like this:

appcfg.py download_data --filename=FULLDATA.sqllite --url=http://liveum-server.appspot.com/remote_api

appcfg.py upload_data --filename=FULLDATA.sqllite --url=http://liveum-server.appspot.com/remote_api

But - at some point you want to change data, so it makes sense to backup and import data as yaml / csv. That's also easy to accomplish.

First of all you have to generate a definition file for your entities.

appcfg.py create_bulkloader_config --filename=bulkloader.yaml --url=http://liveum-server.appspot.com/remote_api

This generates a file called bulkloader.yaml that contains all necessary information to download / upload and transform it from / to a format you can save on disk.

In the generated bulkloader.yaml you can find a lot of "TODO"s. Make sure to correct them. Mainly by selecting "csv or "yaml" as connctor.

If something is wrong the command line tool will tell you :)

Downloading and uploading is then as simple as:

Downloading:

appcfg.py download_data --application=MY_APP_ID --kind=MY_KIND --url=http://MY_URL.appspot.com/remote_api --filename=MY_FILENAME --config_file=bulkloader.yaml

Uploading

appcfg.py upload_data --application=MY_APP_UD --url=http://MY_URL.appspot.com/remote_api --filename=MY_FILENAME --config_file=bulkloader.yaml

Please note that you have to specify which Kind (entity type) you want to backup. So - make sure to iterate over all you entity types using a custom script.

That's it... You can find more at Google's tutorial [2]

[1] http://stackoverflow.com/questions/2593756/is-there-a-way-to-backup-everything-in-an-app-engine-blobstore
[2] http://code.google.com/appengine/docs/python/tools/uploadingdata.html

Play framework selenium tests and Result of expression 'this.getCurrentWindow' [undefined] is not a function.

noreply@blogger.com (Raphael) — Thu, 14 Jul 2011 11:02:00 +0000

I am currently checking out Play Framework, and so far my experiences are 100% positive. Finally a rapid web application development platform worth the name.

After trying out the (excellent) test support I frequently ran into the following exception when running selenium tests:

Result of expression 'this.getCurrentWindow' [undefined] is not a function.

The funny thing was that selenium tests ran sometimes. Sometimes not. Sometimes they failed.

And the problem was:
I used http://127.0.0.1:9000/@tests instead of http://localhost:9000/@tests

So. Using localhost works 100% (and play also tells you to use localhost on the command line). My failure :)

Mercurial branching workflow

noreply@blogger.com (Raphael) — Wed, 06 Jul 2011 12:57:00 +0000

Todd: What's up?
silence
Todd: No one?
silence
Todd: Self five for the big dog!
(idea stolen from nicog)

Some time ago I blogged about a great working git branching workflow [1 and 2]. I've used this workflow for a larger project for almost 1 year now. And I am very happy. It just works.

The basics:
- Have a master branch (master)
- Have a develop branch (develop / or in mercurial maybe better: default)
- Have feature branches (feature-*)

Worflow:
- Features branches branch from develop and merged back into develop
- The develop branch is merged back into master at a given time (eg end of a sprit)

Please check out [2] for details.

Right now I am starting a new project and our new DVCS will be mercurial. I don't want to go into the details - but it will be mercurial. Period. In fact I don't care. Both mercurial and git are super capable. They are great and just so much better than every non-DVCS.

Ok. So let's see how to convert that workflow to mercurial.

First of all I am going to use so called mercurial named branches. No. You don't have to clone your repository to another directory to branch. Many people say that - but it is not true. You can easily switch inplace. And that is everything you need to know.

My cheatsheet:

Basics of inplace namend branches (nothing special in fact):

# list branches:
hg branches
# create new branch locally
hg branch BRANCHNAME
# dont forget to commit something before pushing
hg commit -m"commitmessage"
# then you want to publish your branch so that your colleagues can work and see 
# your great branch
hg push --new-branch
# and your branch is online

Merging your branches:

# get another branch
hg up master
# and now merge your funny changes
hg merge FEATURE_BRANCH_NAME
# and commit your stuff
hg commit -m"my funny merge"
# and push your changes
hg push

Cleaning up after your:

# change to old branch
hg up -C MY_OLD_FEATURE
# mark it as deleted
hg commit --close-branch -m 'close branch - not longer needed'
# push changes to your "central" repository (bitbucket eg)
hg push  # the branch will not longer be listed there

More on cleaning:
http://mercurial.selenic.com/wiki/PruningDeadBranches

[1] http://ars-codia.raphaelbauer.com/2011/01/git-branching-workflow.html
[2] http://nvie.com/posts/a-successful-git-branching-model/