Amber (formerly JTalk)

Amber is a smalltalk engine and ide generating javascript for web development purpose... The IDE is embedded into the browser itself and the compiler is written in javascript upon jquery.

Its is a very nice language and I miss Smalltalk a lot (I stopped to write applications in Smalltalk 10 years ago) and after looked after many languages for the web, many translators for javascript, and so on, Smalltalk remains me how this language is pure, simple, well thought from the ground, and still in advance in concepts... IDEs in a browser exist in this language for many years (Seaside), and other frameworks are children of Smalltalk too (for instance Eclipse and eclipse orion today).
So why not thinking of Smalltalk again? I let you discover it by taking a glance to Amber.

What would we want more in Amber from now? Some tools we could find in Cloud9 for instance, ie configuration management, ... , or a connection with phonegap by integrating phonagap api inside the smalltalk browser, and eventually some components and a huge community behind Amber...

Thanks Nicolas Petton for this great tool.

Dart 1.0 M1

Dart 1.0 M1 (first milestone) will be available soon, almost one year later after the public presentation of Dart to the world.
Dart is more and more stable from the language specification point of view, and still evolves from the other points (libraries, tools, optimizations, compilation, js generation, ...).  Up to now, I was not completely convinced by this new google experiment, and I was still considering GWT as the best alternative to develop complex and efficient web applications, even more with the appearance of mgwt for the mobile market. 
I have continued to take a glance on the project nevertheless, and what I observe is that this project is getting better and better, and more an more people seem involved inside Google on the project. Unfortunately the community is still not large, especially if we compare with Go, the  other Google project (http://godashboard.appspot.com/project). 
Dart future is unsure, but can be said on the right path, and certainly would simplify the web development even on the mobile side.  It can be worth to go deeper inside it. 

DART

Here comes DART we spoke about fews weeks ago. You will notice the name of the site ;) : dartlang, like a wink to golang from the same provider, ie Google. You'll also notice on this blog the ability like with Go to write code online and to test it directly. Have fun discovering this new language dedicated to the web... or not...

(update) after a quick glance to the language, I'm a little bit disappointed ; I expected much more, and actually much more different... I took my dreams for reality ;) nevertheless, it is not a bad language, moreover if we consider it is at early stages of its new life...
We can see it like a javascript 2.0 enabling to better structure javascript code, which is not bad in fine. It will be nice to see in few months how Dart will be used by Google itself, how it will be included or not on android, how the dart2js translator will be fast and efficient enough to compete with GWT, if Dart is intended to work both on client and server side, if dart will be dedicated to the client side and Go to the server one, and so on...
A lot will depends also of the IDE... The GWT eclipse plugin is quite powerful today by enabling to develop web applications with all the power of a Java IDE (refactoring, references, code assist, ...). It is the key point for me, since Smalltalk...

(update2)

It already exists an inception of Dart IDE under the form of an eclipse plugin... to be built manually up to now. It is nice to have at the same time the language and the IDE...

App Internet

George Colony, Forrester Research's CEO, predicts the end of both traditional desktop and web applications. Those models would be replaced by App Internet applications. I agree totally with him, and moreover we can already say that App Internet applications are the present. The question is actually not to predict if App Internet applications will be the future, but on which basis these applications will be built.
What are App Internet applications finally? They are applications which merge different technics and which have in common to gather information from different source through internet in order to perform what they are built for. App Internet applications are kind of desktop applications which have to be connected to every kind of internet information in order to work properly (even if the off-line mode may offer the user to use the application when no connection is available...but for a short amount of time). AIR from adobe, Silverlight, JavaFX/Java, ..., are attempts today to achieve those goals. It is a first step. In my opinion, the future will be a combination of technologies like :
- HTML/CSS/JS (handwriten or generated)for the rendering, the gui
- a container enabling the GUI to interact with with the underlying system (java/javafx2, dotNet, phonegap, ...)
- REST or Web services API for communicating between App Internet Applications or between App Internet Applications and cloud oriented services (the ones from Google for instance)
- distributed storage like the one provided by Amazon or Google
We already started in my company to architecture our apps with the kind of material. We easily mix pure web applications with desktop applications through an internet bus based upon restlets. We merge also javafx and web, swt with web, and so on...
It is up to now a little bit empirical, but the overall pattern arise step by step...

Eclipse E4 incubator

Eclipse Ganymede is delivered and widely used.... But what is the future of Eclipse? With Ganymede we reached a point where adding functionnalities would not be enough to confront the future. This future which is already the present is a mix of old and new technologies, ie desktop applications, RCP applications, Light client applications, RIA applications, and so on...
We need from now an unified model enabling with a single paradigm to reach all the goals behind all these technologies. I think that Eclipse could try to achieve this target because of all the underlying technologies used into Eclipse like OSGI, good programming model, the community, ...
It is maybe also the goal that Eclipse 4, E4 for short, will have to take into account.
For this purpose, an incubator project has been initiated, whose the roadmap is the following.

Google Protocol buffers

We used to use xml or even json formats to exchange data through the network. It is standard, self-describing, well known by many people, and may even be defined by non-technical people.
When we need performances or even more security, we have to to find more efficient ways to exchange data. We could for instance use the object serialization of GWT for achieving this goal.
You also could use the Protocol buffer library developped by Google for C++, Java, C# or python.
This library is already used massively by Google itself.
The goal is to translate textual data into binary ones, and to simplify the way data are stored for accelerating compression/uncompression (Mashalling/unmarshalling).
I enjoin you to have a look on this library.

GWT ressources

VLC integration in GWT
It can be nice to integrate video in GWT vthrough VLC, the famous video/audio platform.
This tutoral explains ho to do this.

Jetty and GWT
"The Google Web Toolkit allows Ajax applications to be developed in java code using the traditional UI widget paradigm. The toolkit includes support for RPC, but not for comet style Ajax push.

Unfortunately GWT has not made it easy to use continuations within their RPC mechanism. Firstly they catch Throwable, so the Jetty RetryException is caught. Secondly they have made most of the methods on the GWT servlet final, so you cannot fix this by extension...."

GWT-Examples

"Example Eclipse Google Web Toolkit projects. These projects are working examples and have been tested before releasing them."

PureMVC Pipes

We've spoken previously about PureMVC, and especially its declination into GWT.
It exists an extension to PureMVC which is Called PureMVC Pipes...but it lacks some examples and tutorial about this. You can find here a good tutorial explaining what the purpose is.
Nevertheles, PureMVC may already be "complex" to use ; pipes don't simplify it :)

GWT libraries news

• OFCGWT is a gwt library over OpenFlashChart2 enabling developpers to display very nice charts in flash while continuing programming in java, and especially with GWT.A demo can be found here.
• GWT Mosaic is a highly usable, feature rich toolkit for creating Rich Internet Applications and an easy to use API.
• gwt-rolodex : displays a stack of images that you can flick through like a rolodex or a card deck
• The FT-GWT-Library 0.9.6 realease is also nearly out. The Calendar widget is espceially useful and nice.
• The cobgw project offers some interesting widgets too.
• The LightboxImage widget is a wrapper onto the lightbox.js library. It is nice.
• GWT2SWF enables a flash component to communicate with GWT.
• htmltemplatewidget is a quite old project but can be interesting for some kinds of use where templating is needed.
• gwt-dnd is a library which can be used when we need to make drag and drop.
• gwt_log is useful for logging information when testing the application.
• tatami : gwt library over the dojo js framework
• gwt-google-api : to access google applications through gwt
• gwt-diagrams : to provide diagramming capabilities to gwt
• gwt-ent
  
• gwt-datepicker
• gwt-s3 : allow applications to call Amazon S3 online storage services.
• gwt-validation : for field validation
• gwt-fabridge : allows scripting Flex and Flash files (swf) from javascript. gwt-fabridge wraps FABridge for GWT. It extends gwt2swf.

That's all for today!

RAP (Rich Ajax Plaform) 1.2M2

RAP is a web development plaform based uppon Eclipse and enabling development in a RCP (Rich Client Platform) manner, SWT being "only" replaced by RWT for Rich Widget Toolkit.
The concepts are really interesting and the architecture clever, based uppon server-side OSGI.
I'm not confident by now on the performances of applications developped with RAP, especially on loading and stress tests. But the basis seems good, and could obviously be improved in the future. Personally I would like to see GWT used instead of/in conjunction with qooxdoo, the js library used to implement RWT on the client side.
Concerning Qooxdoo, it seems that a quite similar project to GWT is available for the framework : QWT for Qooxdoo widget toolkit.

Restlets 1.1.0 is out

Good news ; the 1.1.0 version of the restlets framework is ready to download.
Here a panel of the new features :"

• Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation.

• Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo!
• One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach.
• New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser.
• New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies.
• Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available.
• New POP3 connector based on JavaMail to access RESTfully to remote mail boxes.
• New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance.
• New internal HTTP client and server connectors to simplify development phases (zero configuration"

A screencast is available for discovering the framework.

Smalltalk is going back

I've been fond of Smalltalk since 20 years but have not the occasion any more to develop with this great language/ide :-(
It seems that people after having tried java, c#, ruby, python, groovy, grails, ruby on rails,..., to solve their development problems reached conclusions that everything or almost was already thought, designed 30 years ago with Smalltalk.
Smalltalk is again in the front of door with Seaside, ther continuation framework firstly built in Squeak.
An IBM internal project still focus on Smalltalk for adapting Smalltalk to the eclipse platform through the STDT project.
I hope that Smalltalk will be back on the market, because it still the best architectured language ever.

For information, below can be found a list of Smalltalk providers :

• Cincom Smalltalk
• VisualAgeSmalltalk
• DolphinSmalltalk
• Smalltalk/X
• (old) Smalltalk MT
• and of course Squeak

"Sun gives Java a REST"

This is the title of an article on SDTimes I enjoin you to read.
We've spoken about Restlets in previous posts ; you also can take a look to the jersey project about REST implementation of the java JSR.
You can also have a glance to this comparison of REST implementations here.

GWT-RPC serialization with restlets

One of the major feature of GWT is the ability to serialize objects from/to client to/from server. It simplifies the communication between server and clients, but also improve data security by making the code readable with difficulty.
In the frame of restlets, or even more generally RESTFul applications, we focus more on scalability of the application and portability of the data which are exchanged. Nevertheless we may choose an architecture where communication betwwen server and clients could mimic the GWT-RPC one, ie by transmitting serialized objects through the network.
This possible by using some classes provided by the GWT framework. For instance :

* on the client side : SerializationStreamFactory, SerailizationStreamReader
* on the server side : RPC.encodeResponseForSuccess

Example :
1) on the client side

// Create the serialization stream factory
SerializationStreamFactory serializationFactory =
GWT.create(MyClass.class);

// Create a stream reader : the argument is the serialized string from the server
SerializationStreamReader streamReader =
serializationFactory.createStreamReader(aStringReturnedFromRestletCommunication);

// Deserialize the instance
MyClass aClass= (MyClass)(streamReader.readObject());


2) on the server side

String encoded =null;
try {
String encoded = RPC.encodeResponseForSuccess(MyClass.getMethod("aMethodName"),myClass);
} catch (SecurityException e) {
e.printStackTrace();
} catch (SerializationException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
return encoded;

Jersey, the other RESTful framework

We've spoken a lot about Restlets in previous posts... It was without counting on another RESTFul framework which begins to be widespread too, ie Jersey.
As said on their web site :
"Jersey is the open source (under dual CDDL+GPL license), production quality, JAX-RS (JSR 311) Reference Implementation for building RESTful Web services. But, it is also more than the Reference Implementation. Jersey provides an API so that developers may extend Jersey to suite their needs. The governance policy is the same as the GlassFish project. "

As I've currently an opened post -), I give you another link towards the Enunciate project which is also interesting for building web services, RESTful or not (rest, soap or RPC).

Python-gwt-rpc

For the ones who want to develop an application with GoogleApps, and who would also use their favorite GWT framework, there is a very useful project for doing this : Python-GWt-RPC..
Take a glance.

GWT/Google Gears/Restlets

This post is actually a question to the readers of this blog.
I would like to know if you already have tried to use GWT with Google Gears, and more especially if you've tried to used GWT-restlets with Google Gears...
While REST ressources can be cached and stored, I imagine that Google Gears could easily manage these ressources, and then GWT could benefit a lot of this feature to easily develop web application which could run locallyand/or remotely.
Have you experienced this?
regards

material :

• gwt
• gwt-restlets
• google-gears
• gwt google api

PureMVC web framework

When developping a web application, we all know that we have several parts to focus on ; presentation flow management, business rules development, data persistence, and so on... It is generally called N-Tiers architecture, N being function of the complexity of the application.
J5EE for instance aims to cover all the scope of web application concerns.
For the ones who don't want a all in one framework, or who develop with other languages than Java, it exists many "little" frameworks which focus on a particular part of the web application development problematics. It is the case especially of Struts, or Wickets, or Spring, etc...
This is in this context that the PureMVC framework occurs ; its scope is only to manage the presentation logics, ie how the developper has to design his application to manage views, actions, controls, ..., in the web pages. It is clearly a replacement of Struts and it is based uppon clear explained design patterns of the Gang of 4 : proxy, médiator, command, facade, observer ; five design patterns for building simple and well structured web applications from the presentation point of view.
The "plus" of the techno is that it has been derived for many languages : Php, Ruby, Java, Flex, ... We may even consider now developping an entire application in different languages (for instance Php and Java) with the same underluing concepts... It could be the case in a SOA approach, eg a web portal (public access) in Php which would focus on referencing, and in java/gwt for the business part of the application (private access).
Another interesting view is that it is ,by construction (it is only based uppon the use of design patterns, not libraries), compatible with other frameworks like Spring or Restlets...
For the best, I would like to make notice that PureMVC has been derived for GWT, ie indirectly for Javascript :-).
So let imagine the following global architecture :)

• GWT for the graphical part
• PureMVC4GWT for controls and UI logics
• Restlets for ressource access on the server(s)
• OSGI for managing component efficiently
  
• DB4O for storing data in database

Is it not a nice proposal? ;-)

Some articles and material about REST architecture

REST explained in few words.
Just a little post to make reference to three articles from Stefan Tilkov. Interesting!

1. a brief introduction to REST
2. REST anti-patterns
3. Addressing Doubts about REST

I recall also in mind that a great and simple REST framework in java exists : Restlets!!! It may even work with GWT too ; see the GWT-Restlet Module. You also can use Restlets with Groovy.

For the ones who want to use REST with Php, the following articles are also nice :

1. Php REST Server part 1
2. Php REST server part 2
3. Php REST server part 3

Balsamic Mockups

I discovered last week a quite interesting tool for developping UI Mockups : Balsamiq Mockup. It is a singular tool which has pleasant characteristics.
You have two modes of mockuping :

1. stand-alone way
2. collaborative way through a plugin in AtlassianConfluence or in Twiki

This second aspect is quite novative and valuable.
I've tried the tool a little, and have found it is quite easy to use and intuitive.
I only regret the lack of dynamics like with Axure... You only can develop sibgle pages not connected between them, which means you can't describe tha page flows.