pgt » open source

Using Speed Tracer on a Mac

P.G.Taboada — Wed, 09 Dec 2009 20:03:08 +0000

Speed Tracer on a Mac

I finally got Speed Tracer running on Mac OSX. Just in case you missed the news: GWT 2.0 was released yesterday and brought a nice friend called Speed Tracer.

The tool itself is written in GWT (funny, don’t?) and works as an Chrome extension. Since Chrome for Mac is beta and does not have support for extensions we nee to use use Chromium.

There are postings on how to get extensions running on Chrome for Mac, but I preferred to use a Chromium build.

Speed Tracer is a Google Chrome extension that helps you identify and fix performance problems in your web applications. It visualizes metrics that are taken from low level instrumentation points inside of the browser and analyzes them as your application runs. Using Speed Tracer you are able to get a better picture of where time is being spent in your application.

Thanks to pohl (irc chat on ##gwt) for the hints.

So here we go:

1) We need some Chrome build that has “extensions enabled”. I used this one here, but you might try any other newer one.

2) Install Speed Tracer.

3) Start Chromium with the required command line parameter.

This part is the only real tricky one if you are not a geek… ;-)
From the Terminal you can start Chromium manually by executing the following…
/Applications/Chromium.app/Contents/MacOS/Chromium --enable-extension-timeline-api
… or you simply rename the bin to something else and place a script that does the command line magic for you.
I renamed Chromium to Chromium-bin and created a Chromium named script file that contains:
#!/bin/bash
exec "${0%/*}/Chromium-bin" --enable-extension-timeline-api
Don’t forget to make the script file executable…

That’s it. Now you can visit some ajax-funny site (google wave, google maps, google mail, google docs, you name it) and test drive Speed Tracer.

Good luck!

News from the GWT development front

P.G.Taboada — Sat, 17 Oct 2009 10:07:20 +0000

There have been some quiet updates in the last days on the GWT development front.

First and most important is that the GWT development team has released a milestone towards GWT 2.0. The milestone release can’t be found on the main page, and it was not mentioned in the official GWT blog.

This milestone provides early access (read: known to still be unfinished and buggy) to the various bits of core functionality that will be coming in GWT 2.0

One of the known issues on the group posting states that the actual Google Eclipse Plugin does not work with this release, because it won’t accept this build as a GWT distro. This comes from the fact that GWT 2.0 is missing the platform dependent jars. This comes from the fact that GWT 2.0 is introducing OOPHM, replacing the old “hosted modus” by the new “developer modus” where we can use a set of browsers with a plugin instead of the one bundled with the GWT release:

We’re going to start using the term ”development mode” rather than the old term “hosted mode.” The term ”hosted mode” was sometimes confusing to people, so we’ll be using the more descriptive term from now on. For similar reasons, we’ll be using the term “production mode” rather than “web mode” when referring to compiled script.

Specially interesting for the Mac users, there has also been a quiet update for the Google Eclipse Plugin solving the issue, where we could start the new OOPHM developer modus from eclipse to start “watching the beachball”.

The point is: from now on, we can start using GWT 2.0 and explore the new features. We have both: an official milestone release and a working Eclipse plugin. Development infrastructure problems resolved, stays the question: should we use a milestone build? This question is not so easy to answer.

First, if we believe what speakers told in the Google IO 2009 sessions, the Google teams using GWT (ok, let’s name them: AdWords development team, Google Wave development team) are using GWT build from trunk.

How can that be? How can anyone use something build from trunk that is undergoing such changes?

Well, this is called a “solid development process” and “discipline”. If you have a look at the GWT sources and at the commit statements, you will notice that:

commit statements have the name of the reviewer.
Take a moment to think about it.
many developers have their own branches where they to their stuff. Only reviewed changes are commited (integrated) to the trunk build. So, the trunk moves from one consistent (reviewed) state to the next one.
Take two moments to think about this…

Second, GWT is more a compiler than a runtime library, and it would not be the first time we use beta compilers during development.

Back to the question: can we use a milestone or even a trunk build?

Yes – I think yes, we can. As long as the GWT team continues working they way they have been for the last months, trunk, milestone and beta builds have an unmatched quality status. Just my 2 cents…

Eclipse Galileo SR1

P.G.Taboada — Thu, 24 Sep 2009 16:42:55 +0000

I just started downloading the SR1 release of Eclipse Galileo. According to bugzilla, there were 241 bugs fixed with this release.

Can’t wait for the download to finish to check if Eclipse is working better on Snow Leopard…

W-JAX 2009 Vorträge

P.G.Taboada — Tue, 22 Sep 2009 09:54:21 +0000

W-JAX 2009

Die Konferenz für Java, Enterprise Architekturen & SOA

Die W-JAX ist die Konferenz für ganzheitliches technisches Know-how im Enterprise- und Webumfeld. Hier kommen die besten Experten Europas zusammen, um ihr Wissen und ihre Erfahrung an die Teilnehmer weiterzugeben. Durch ihren einzigartigen Mix an Themen verleiht die W-JAX alljährlich der Java Enterprise Community die entscheidenden Impulse.

Google Web Toolkit – Making a Better Web 2.0
Speaker: Papick G. Taboada

Mit Adwords und Google Wave sind die ersten großen GWT basierten Anwendungen von Google erschienen. Mit einem optimierenden Kompiler und pfiffige Codegeneratoren werden mit GWT maßgeschneiderte JavaScript Anwendungen erstellt, die Entwicklung findet allerdings in Java statt. In dem Vortrag werden Konzepte, Neuigkeiten aus 2.0 und die aus Adwords gewonnenen Architektur “Best Practices” vorgestellt.

SpringSource dm Server: Fitness für die Webanwendungen
Speaker: Agim Emruli, Papick G. Taboada

Java-EE-Webanwendungen tragen Deployment-bedingt eine große Menge an Bibliotheken mit sich. Mit OSGi werden dank einem standardisierten Modularisierungskonzept neue Wege gegangen. Lernen Sie in der Session die Möglichkeiten der Modularisierung in Java-EE-Webanwendungen auf dem OSS SpringSource dm Server kennen, damit schwergewichtige und monolithische Deployments der Vergangenheit angehören.

EDA in der Businessintegration
Speaker: Christian Dedek, Papick G. Taboada

Integrationsszenarien mit ereignisgesteuerten Architekturansätzen in Java umsetzen? Dieser Vortrag bietet Ihnen eine Einführung in EDA und Complex Event Processing (CEP) und stellt den Zusammenhang zwischen EDA und SOA her. Darüber hinaus veranschaulicht er die Architektur und den Aufbau von Esper und zeigt CEP-Einsatzszenarien.

HTML Editor for Eclipse

P.G.Taboada — Mon, 21 Sep 2009 12:19:11 +0000

Thanks for the tip:

Amateras HTML Editor for Eclipse

EclipseHTMLEditor is an Eclipse Plugin for HTML / JSP / XML / CSS / DTD / JavaScript editing. This plugin is required by StrutsIDE and FacesIDE.

HTML/JSP/XML/CSS/DTD/JavaScript Highlighting

HTML/JSP Preview

HTML/JSP/XML Validation

Contents Assist

Wizards for creating HTML/JSP/XML files

And many more powerful features…

Works fine with Eclipse Galileo.
I am using it now along with the Google Eclipse Plugin for GWT development/ training.

It is all about the cloud…

P.G.Taboada — Tue, 11 Aug 2009 07:14:18 +0000

It is the cloud game. First Google brought itself into the java cloud computing game by adding Java support to the AppEngine. It was a tripple release: GWT, Java for AppEngine and the Google Eclipse Plugin. A few days later Amazon EC2 (Elastic Cloud) announced to be running IBM Java EE products.

And yesterday we saw the announcement (twit1) that SpringSource will become a department in VMWare (twit1, twit2, twit3). This is the next player in cloud computing looking for Java technologies.

And, IMHO, this is the most interesting “marriage” of Java technology and cloud computing for the enterprise customer as we know today:

SpringSource has been the innovation motor in the Java universe for the last few years, and many of us were hoping they would find some way to monetize their efforts soon and succesfully,
enterprise customers *do* have their own hardware infrastructure, often only lacking cloud computing software and knowledge.

So is this deal saving SpringSource on a long term and making VMWare even more interesting for the enterprise customers?

But while with VMWare it is all about the enterprise customer, with SpringSource it is all about the open source community – this is their strength.

We should be thankfull to see SpringSource in good hands, but somehow I am eager to see how the open source community will profit from the VMWare and the SpringSource team-up. VMWare is not known for open source products, but they offer some products for free. Wonder if it will be possible to setup a full working cloud environment on a free/ OSS basis.

OSS ist keine Freikarte…

P.G.Taboada — Mon, 10 Aug 2009 16:23:06 +0000

Habe es soeben erlebt. Einem bekanntem wurde eine neue Homepage “angeboten” – alles super, hier und da Eye-Candy, viel besser als die statische Homepage vom Freund, etc. etc.

Die Software – die auf dem Server läuft – ist OSS (Open Source Software), damit ist alles klar!

Ja klar, ein CMS ist eine feine Sache. Schnell ist die Homepage mit Inhalten gefüllt und es sieht dank der schönen Skins die es ja irgendwie immer gibt auch noch schick aus. Aber nur weil es OSS ist, warum sollte dann alles klar sein? Support und Weiterentwicklung ist nur gegeben solange eine Community da ist und diese nichts schöneres zum spielen gefunden hat. Struts galt sehr lange als das “de-facto Standard” und spielt heute keine Rolle mehr bei Neuentwicklungen im Java Umfeld.

Das Problem: Software muss gewartet werden (nun, die statische Homepage nicht). Unglücklicherweise muss in PHP geschriebene Software aus mir unerklärlichen Gründen sehr oft aktualisiert werden. Auf neue Funktionalität kann man oft verzichten (die Homepage funktioniert doch!), aber gerade die Updates die Sicherheitslücken stopfen müssen schnellstens eingespielt werden. Oh, mein WordPress meldet auch schon wieder ein Update – und genau hier sehe ich das Problem bei den “einfachen” Webseiten:

Entweder ich kann dafür sorgen, dass meine “einfache” Homepage regelmäßig und rechtzeitig aktualisiert wird,
oder ich nutze SaaS und mache es zum PAL (Problem Anderer Leute),
oder ich bleibe bei der statischen HTML Seite.

Unter SaaS verstehe ich das Hosten nicht durch einen Freund, sondern durch einen Provider, wie zum Beispiel WordPress.com oder andere Anbieter.

Und dann sollte man auch eine Software verwenden, die nicht gerade am Ende des Lifecycles ist:

OHLOH zu Joomla

TCP Monitor the easy way

P.G.Taboada — Wed, 01 Jul 2009 05:48:25 +0000

TCPMON Monitoring window

Every once in a while I need to have a look at what is going over the wire. Since it is not my day-to-day job (it normally just works fine), I never had the time to search for the tools available.

I remember my first steps with Axis a long time ago. It had a tool called tcpmon – remember? Whenever I needed a tcp monitor I just startet the tcpmon of the old Axis laying around somewhere on my disk.

Recently someone asked me for a tcpmon tool – and after googling I quickly found the project on java.net:

TCPMON

tcpmon is an open-source utility for monitoring the data flowing on a TCP connection. tcpmon is used by placing it in-between a client and a server. The client is made to connect to tcpmon, and tcpmon forwards the data to server along-with displaying it in its GUI.

Webstart launch jpnl file for tcpmon

The real nice part is the jpnl webstart launch option.

Just click on the link and webstart will start the tcp monitor.

SpringSource Produktivitätsoffensive

P.G.Taboada — Sat, 09 May 2009 09:11:19 +0000

Diese Woche haben wir zwei großartige Nachrichten aus der SpringSource Ecke bekommen:

STS

Bei STS handelt es sich um eine Eclipse-basierte IDE, die bisher nur den “Enterprise- Kunden” vorbehalten war. Es ist die Zusammenstellung von Spring IDE und andere Plugins aus der SpringSource Softwareschmiede:

Key Highlights von der Produktseite:

Greater Productivity

OSGi Made Easy

Developer Onramp to Virtualization

Task Focused Development

Guided Learning

Bei Spring Roo handelt es sich letztendlich um die Umsetzung von Rod Johnsons Aussage:

“We (the Java EE Community) are not picking the low hanging fruits“

Und damit hat er recht: wir haben mit Java EE sehr mächtige Frameworks, scheitern aber kläglich daran, daraus ordentliche “full stack application frameworks” zu bauen. Die Quittung haben wir mit “Ruby on Rails” und Konsorten bekommen: erst haben wir sie belächelt, dann diese für Prototypen eingesetzt. Jetzt lautet es “success stories” aus allen Ecken. Mit Spring Roo bekommen wir ein “full stack application framework“, das diesmal aber in Java mit Java Tools und Technologien umgesetzt wurde (Maven2, JPA, JUnit, Spring MVC, Spring Security, u.s.w.).

“Roo delivers productivity without compromise. Spring Roo melds the development advantages that have emerged in dynamic frameworks with the robustness, reliability, performance and familiarity of enterprise Java. Roo is designed for developers that want to build Java applications faster than ever without having to learn a new language or syntax. Roo is designed to be incorporated into the majority of development environments including visual development tools and utilizes the widely understood implementations of relevant standards.” (Quelle: http://www.springsource.org/roo)

Die Spring Roo Seite verrät zur Zeit sehr wenig – nicht einmal, wie man Spring Roo aktuell runterladen kann. Hier muss man die Blogosphäre aus dem Umfeld im Radar haben:

Ich habe das Gefühl, dass die Java-Gemeinde endlich aufatmen kann, denn jetzt hat man eine Alternative zu Ruby on Rails, Grails und Co. Es wird sich zeigen, wie tief Spring Roo in den Kinderschuhen steckt, und ob SpringSource “den Kampf” an einer weitere Front aufnehmen kann. SpringSource scheint wieder die OSS Community entdeckt zu haben (die Community darf sogar bei der Namensfindung mithelfen), und spielt zu meiner Freude die Karte gross aus.

Creative Commons

P.G.Taboada — Mon, 27 Apr 2009 17:27:30 +0000

Man kann es toll finden.

Oder auch nicht…

Why Photographers Hate Creative Commons

Bin über Twitter drüber gestolpert.

Stop this “my support is better than yours” discussion!

P.G.Taboada — Sat, 30 Aug 2008 10:46:07 +0000

Ok, someone is making money with support.
Ok, someone is not contributing to OSS.
But wait – is offering support not exactly that? Contributing to OSS by doing the dirty work no one wants to do?

That’s why I do not agree entirely with the label “parasites”. It is not easy to offer support, IMHO it is a Job that no one likes to do. I don’t know if it is true for everyone – but I am very happy to be a developer and not to be a support guy.

It just happens that it is exactly this job is actually needed, and hence, can be monetized.

Don’t tell me that those few developers really contributing to an OSS project have time to provide support as it is required today.
Don’t tell me that somebody not contributing is not capable to offer support. If you really believe that, you don’t understand what it means to offer support.
Don’t tell me that developers can offer better support.

So even if all OSS developers start working 24h a day (I am sure many already do) – would they be supply enough service to cover the demand? How many people do need support, now many contributors do we have?

I remember reading somewhere on a OSS page: “great support by the community”. What does this mean? Easy to tell: we can’t or we won’t offer support.

I believe that neither Spring nor any other OSS product would have come that far without the many consultants and supporters we have working very hard today. So someone is monetizing support? Fine! It will open the doors for enterprise OSS acceptance. Is someone offering training for OSS technologies? GREAT!

Does it feel like it is stealing work? No it is not.

Sure – we live in interesting times. Don’t have a working business plan for your successfull OSS product? I tell you what: go offer support for it. But be warned: it is hard work, it is mostly badly payed, it does not scale, and you will stop working with computers and start working with people.

Good luck!

SpringSource announces an application plattform

P.G.Taboada — Mon, 05 May 2008 07:51:54 +0000

SpringSource recently announced the Spring Aplication Platform, and this announcement is generating a lot of fuss. Google has recently launched the Google App Engine. From an Java enterprise developers point of view it is shamelessly easy to use, deploy, etc. Well, unfortunately it only takes Python apps for now, but it is stated that there will be more languages supported in the future. But it’s Google again putting its finger into the Java EE wound (first GWT with webapps, then Android shaking the Java ME world, and now App Engine showing how runtimes should look like).

Looking at Googles App Engine I thought how nice it would be to have the deployment, packaging and runtime of Java EE applications redesigned. Those deployment descriptors really suck. As it seems (heard it at the Jax from speakers “off the record”) Java Dynamic Modules and Java Superpackages aren’t going to make it into the next Java relase – Java 7.

From this point of view, the Spring Application Platform is bringing fresh air into the Java EE development. The Java EE dream of a runtime didn’t come through. Modularization got lost somewhere in the way. Packaging and deployment is a nightmare, and tools didn’t solve the problem. Since Java EE 5 is being adopted very slowly and Java EE 6 is really far away, this is surely the best time to drop in an alternative. Well done. Though beeing an alternative, there seems to be some level of commitment regarding Java EE deployment support.

IMHO the real shock came with the change in licensing terms. We are used to SpringSource licensing their products under the Apache 2 license. The license is clear and accepted by most companies. The Spring Application Platform is licensed under the GPL. GPL is, IMHO, the most misunderstood license we have in the OSS. I do not have nothing against the GPL, I only have a problem with the different interpretations. And if a license can be misunderstood, how can we rely on it? I won’t start another blog about how GPL works – please go read the GPL and the GPL FAQ, it’s worth it. A nice reply from Will Hartung about GPL on the TSS thread can be found here.

Does nobody actually, you know, READ these licenses?
Users who change GPL code have absolutely no, zero, zippo, big bagel, goose egg obligation to give back to “the community”.
I can take this code, make all the changes I want, sell it to my customers, and you can come knock on my door saying “I want the code, it’s GPL! Give me the code!” and I can nod and smile knowingly and tell you to pound sand. “Give me $100K and I’ll give you the software.

Thanks Will. It’s beautiful.

Rod argues that if someone takes the code, makes changes and starts selling it, this someone will, sooner or later, have to provide the source code to a major number of customers and hence the changes will be available for the community, especially for SpringSource. Rod, I hope I did quote you right, sorry if I didn’t.

Another great statement from Will comes a few postings later:

But you certainly aren’t going to take back contributions that don’t have at least shared copyright, because as soon as that happens you can’t relicense the whole under something other than GPL. So, there’s not a whole lot of value to the community there.

Later Rod makes a nice statement about what’s ok:

1. Using the platform to run closed source applications is OK. This immediately covers the vast majority of companies and developers who are end users. This would cover for example, software use by companies like Google, banks, media companies etc.
2. Modifying and extending the platform and “hiding” (closing) it is OK, unless you redistribute. So if you modify it in your own company, or you modify it and distribute your modifications in GPL open source, that’s OK. If you modify it and distribute a closed source product including those modifications, that is not OK. This would exclude Oracle, for example, from modifying the server and redistributing it as a closed source product. We believe this is a Good Thing.
3. It is fine to run closed source applications on the platform. Whether you can redistribute them as one closed product (bundling the platform) would depend if they constituted a derivative work.

I liked this one too:

Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law!!! ha ha
Lets stay technical please, even though it clearly doesn’t pay !!!

This is perfectly showing how GPL, although commonly used in OSS projects, is really badly misunderstood by people.

IMHO GPL licensing was a bad idea. SpringSource targets the enterprise, the enterprise dislikes GPL, that’s a fact. Linux seems to be the exception to the rule. It’ nice to see how SpringSource understands GPL – but this understanding is not binding. What if someone wakes up next week and says – “oh sorry, I think we have to rethink our GPL understanding….”

GPL, GWT, GXT, FSF, confusion

P.G.Taboada — Tue, 29 Apr 2008 09:51:20 +0000

I really believe that switching to GPL did more harm then good. A forum thread of more than 50 pages is no good sign…

It is quite hard to tell how GPL works for web applications. Does sending html/css/javascript code to a browser mean I am conveying the application to the user?

What is the application in this case? As far as I remember I deployed a war file. Is my user getting the war file? Is he able to deploy the aplication? What about all of my server side business logic and settings that never get to user?

I think that what developers at GXT are demanding is wrong. As long as this isn’t clarified, GXT is a “no go”.

Or does someone want to buy a commercial license that only works on an unreleased version of GWT for a Proof-Of-Concept project? My customers definitely not.

LGPL, dynamic linking and Java

P.G.Taboada — Sun, 27 Apr 2008 12:00:00 +0000

Just came across this one:

It has always been the FSF’s position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as “hereditary.” So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications.

To use a GPLed library in a product, you need the Classpath Exception:

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

If you don’t directly link to GPLed code (e.g. using JMS, SOAP or similar communication approaches) it seems to be enough to provide installation instructions, so the user can deploy the GPL libraries himself. You have to provide bridge code licensed under compatible licenses to make this possible. If your code only compiles if a given GPL library is available in the classpath (import statements, use of derived classes, etc), then you must license your code under the GPL as well…

Short talk at the Jax 2008: Android

P.G.Taboada — Wed, 02 Apr 2008 08:27:51 +0000

Steffen and I will be talking at the mobility day about Google’s mobile platform Android:

Google Android: Uncanny Valley – unheimliches Tal? Google Mobile für Java Entwickler

Im November 2007 stellt Google ein Handybetriebssystem namens Android vor. Das entsprechende SDK für Android-Applikationen ist Java-basiert, kommt mit Eclipse Plug-in, hat Bibliotheken für openGL, Bluetooth oder USB und produziert Java Byte Code. Ausgeführt wird dieser allerdings nicht auf einer JavaVM. Der Vortrag zeigt die Möglichkeiten des neuen Ansatzes in einer Welt fern von JCP-Standards.