And now on Twitter

December 3rd, 2008

Bite sized thoughts need a bit sized format, and now you can follow me on Twitter. Hope this will be the last two-line blog post.

EclipseCon 2009 submission

November 20th, 2008

In the spirit of transparency and openness, the submission process for EclipseCon 2009 conference is very refreshing. As the main site says

The selection is done transparently and in the open. Specifically, all submissions are made through our submission system. Everyone in the community (including you) is invited to review the submissions, ask for more information, provide comments and critiques – just as everyone in community is invited and encouraged to do for Eclipse bugs and features.

I have just submitted a proposal to talk about our experiences in developing a visual designer for form-based applications, built on top of rich Eclipse tools such as the core platform itself, as well as JDT, EMF, GEF, VE and JEM. The proposal is called “On The Shoulders of Giants: Harnessing the Power of Eclipse Enterprise Ecosystem“, and you are more than welcome to leave comments on the entry. Here is the abstract:

Code reuse in large projects is not just a trendy buzzword. If you can build upon solid, evolving and well tested foundations that are developed and maintained by committed teams, you have much less code to test, integrate and support. The Eclipse Ecosystem is a prime example of an extremely rich foundation for building enterprise grade applications, and this talk is going to show the diverse, yet interoperable technologies that allow businesses to concentrate on their specific requirements without reinventing the plumbing layers.

A part of a larger client-facing offering, Amdocs Smart Client Designer is an advanced visual designer that allows seamless collaboration between designers and developers in creating complex business form-based applications for Support Call Centers in the telecommunication industry. Harnessing the power of such technologies as JDT, GEF, EMF, JEM and VE has allowed us to dramatically reduce the effort to build the basic blocks of the tool (such as persistence, code generation and java syntax tree manipulations). In addition, core platform features such as task and job managers, builders, natures, markers and many more are enabling user-centric asynchronous business flows in a clean, simple and maintainable way.

Building on top of a vibrant and evolving ecosystem has been a pleasant experience, further strengthened by a recent migration to Java 6, Eclipse 3.4 and the latest version of the dependent plugins. In addition, we are going to talk about the “Eclipse way” of designing the flows, where the existing core features guide the design process to facilitate familiar flows and simpler implementation.

If you are developing a large Eclipse-based offering, or considering Eclipse as the vehicle for your next enterprise-grade tool, come to our session to hear about our experiences in this area.

Trust is hard to build and easy to destroy

November 13th, 2008

What, why, when and how – these are the questions that shape the communication between the product developers and their users. Different teams choose different levels of opacity regarding these four questions, and making the answers more opaque over the time leads to a building frustration among the community members. This has been one of the major reasons behind my post on the current state of core Swing, and allow me to further explore this area.

Open-sourcing Java during the JavaOne 2006 and the announcement of OpenJDK project was hailed by Sun as the new era for Java, where everybody can lend their hand in shaping the future of the Java platform. Specifically in the client area, the summer of 2006 has supplied Swing developers with such gems as Chris Campbell’s entry on soft clipping, Chet Haase talking about Java on Vista, official birth of JSR 295 and JSR 296, as well as lively discussions on the SwingX painters and layers. Those have been exciting times for me personally, as they showed a renewed and well backed interest in the Java client side development.

Unfortunately, the last eighteen months have been quite disappointing. The level of openness (or transparency, if you will) set in the summer of 2006 was not a genuine and lasting commitment to the community, which has been effectively shut not only from participating in the decision making process, but in following it as well. And this brings me back to the four questions – what, why, when and how.

The how is perhaps the easiest one, and Java has always been shipped with the matching source archives. This has allowed the users to understand not only how the specific piece works, but also how to work around the specific bugs in order to achieve the required functionality. Even if the internal technical design documents (if any are present) are not available to the community, the full source code is an excellent reference guide to a deeper understanding of the platform and becoming a better Java developer in the process.

The answer to when allows bigger projects to estimate timelines for the different technologies, both existing and emerging. In this area, Java has not been a great success over the last three years. The new 18-month release cycle for major versions (announced at JavaOne 2005) which would have Java 6 ship in summer 2006 and Java 7 to ship in early 2008 has failed, without any explanation or apology. While the main reason for “slipping” Java 7 is the great work that has gone into Java 6 update 10, we still don’t even have the umbrella JSR for Java 7.

The answer to what allows estimating the functionality for the different technologies in coming to decide which one to use. Will we have a cross-platform Swing web browser component in Java 7? Will we have a public Swing API for translucent and shaped windows in Java 7? Will we have a public Swing API for playing, manipulating and producing video streams in Java 7? Will we have binding layer for Swing applications in Java 7? Will we see modern Swing components such as pivot table or date picker in Java 7? Withholding answers to these questions has been a normal practice for the past eighteen months, and this opacity has resulted in quite a few disappointed advocates of the toolkit.

The answer to why defines the level of trust between you and your community. You can be extremely opaque, not only making your decisions behind closed doors, but also presenting them as the only right way. You can be somewhat translucent and write about the reasons behind the decisions, even when the decisions themselves are made without any input from the community. Or, you can be extremely transparent and have the community participate equally in shaping and moving the platform forward.

Different projects will differ in their level of opacity. One-man open source projects are different from commercial companies that are frequently judged by revenue stream and monetization. You have the extremely opaque Apple and somewhat translucent Microsoft. On the other hand, you have an incredibly open Mozilla that already has 61 posts on its aggregator since the beginning of this week. And in between you have projects such as Qt Labs that are engaging in early feeback cycle about emerging functionality in their toolkit.

The last two examples (Mozilla and Qt Labs) show a continuous level of commitment to the two-way communication with their users. Is this coming from the developers? Is this coming from the management? Does it matter at all to your developer users?

If you’re starting a blog about the product and then abandon it after a few weeks, why start it in the first place? If your project has the word “open” in it and then you want to suppress the discussion about the planned features, why bother pretending? Do you really want to hold all your cards close to your chest if you’re trying to compete against a formidable opponent, especially when many of your pre-announced features are already in his well established offerings? Can you afford keeping the potential developers out of the loop instead of using the power of dev-to-dev blogs to build up the excitement? Is it beneficial to your project to hide behind the “open source you can help us instead of whining” mantra, when my chances as a potential outside contributor to add significant new functionality (as opposed to fixing a bug) are almost non existant?

And lastly, can you justify being “heads down” in development / testing to create a void to be filled with rumors, conjectures, interpretations and wild guesses?

20 design blogs for UI developers

November 6th, 2008

This blog is about putting pixels on screen. If i need to choose between getting a bunch of finished images from a graphics designer and hand coding each and every pixels in the code, you know my choice. We must, however, acknowledge our limitations and strive to better our understanding of what a good design is. Only exceedingly few have equal talent and passion for both design and programming, but the rest of us can at least try and learn from the best minds on the other side of “the fence”.

Below you will find links to twenty design sites and blogs that i currently follow. Unfortunately, the lack of time has me use an RSS reader, and as such a site that does not publish full article feeds is simply not going to make it. This might weed out a few good sites, but that is an unfortunate consequence of the information deluge age that we are living in.

The sites are listed alphabetically – click on the banner to visit the site and to subscribe to its RSS feed.

1. 84 Bytes