Month: May 2011

After reading the announcement of the Beta release of JavaFX 2.0 some people in the blogosphere started to blame Oracle for making it available only on Windows. I work on MAC computers too, but don ‘t want to get into the Windows vs. Mac vs. Linux flame war. I ‘m OK with JavaFX starting on Windows version first (about 90% of software developers use Windows). My concern is that JavaFX remains in a permanet “almost ready ” state. I was able to afford being an early adopter with JavaFX 1.0, but not this time.

I ‘m waiting to hear a clear message from Oracle explaining WHY a startup or an enterprise development shop should switch from whatever RIA solution they use to JavaFX 2.0.

I ‘d like to see a comparison chart of JavaFX 2.0 with Flex, Silverlight, HTML5 showing where the strength of JavaFX is. Being that rich UI component library, fast communication with the server side, or a set of tools that makes software development more productive. Why Oracle Marketing and PR keeps silence? The roadmap has a number of statements mentioning improvements here and there. Improvements of what? Of JavaFX 1.3 that has never seen the light of the day (I mean the real-world use)?

Today, the main target for any RIA platform should be consumer facing (smart phone/tablet-ready) applications, not the enterprise segment where most of the users are happy to see the data in any form (grey screens with rectangular grids and forms still rule over there). I want to see a seemlessly installable runtime for JavaFX applications.

Give a brand new computer to your grandma and ask her to visit a Web site that includes a JavaFX 2.0 applet. Will she be able to complete the process of installing the runtime? If you think I ‘m asking for too much, repeat this grandma test with any Web site that contains Flash or Silverlight content.

Sun Microsystems first announced JavaFX four years ago. Now it ‘s in Oracle ‘s hands, but they ‘ve yet to show any impressive commercial application developed with this tool.

The Summer of 2011 is almost here, and Farata Systems has started working on the agenda of our fourth (!) annual symposium. But if the first, second, and third events were covering various aspects of enterprise development with Adobe Flex, this time we “ll cater to the wider audience and will rename it to Fourth Annual Symposium on Enterprise Software. The reason being that we are using so many different technologies in our daily work, that it “s just wrong to present ourselves as a Flex development shop.

Every year we start with putting together a list of suggested topics that Farata “s engineers want to present on. Here “s what we have so far (it “s subject to change):

Yakov Fain wants to deliver the following two presentations:

1. Networking WebSockets – the most interesting offering of HTML5

2. Hands-on Java EE 6 – the no-slides demo of programming Java with the current server-side technologies

Victor Rasputnis is heavily into Android these days and may talk about:

1. Squeezing Adobe AIR, BlazeDS, and Java inside Android

2. Something introductory about productive way of development for Android

Anatole Tartakovsky is obsessed with tablet devices and might talk about this :

1. Case Study: A salesman with Adobe AIR and a Tablet

2. Maintaining a single code base for Android and iOS applications

Possibly, yet another Viktor from Farata will talk about the automation of the functional testing of UI in Flex applications.

Now comes a one million dollar question. Who is this seminar for? This is a one-track/one-day event. In the past three years this event was aimed at Enterprise Flex developers. But what “s the profile of \an attendee who would want to hear all of the above? I “d call such a person a Current Enterprise Software Professional. This can be an enterprise architect or a developer from a startup. These days no one can survive by committing to any single programming platform. To become current, a technology stack of a seasoned professional must include more and more tools each year.

As usual, we “ll keep the price for this event anywhere between $100 and $150 just to ensure that random people won “t be in the room, but those who care can afford it. This amount will cover our expenses on renting a meeting place, serving lunch, and paying for the beer after the formal part is over.

The registration page will be up next week, and the event will take place in early August at the same venue in New York City. Meanwhile, we “d appreciate your suggestions regarding the content/organization of this event.

When your organization starts looking for offshore Java developers, one of the most important concerns is if the developer can stay focused on work. And this is when Google Trends can become handy. Here ‘s a simple logic. Vast majority of the Java programmers are young males. What young males care about the most? You got it: sex. Go to Google trends entering just these two words: java, sex. Or just click on this link. Got the picture?

Based on this diagram don ‘t even think of hiring Java programmers from Warsaw or Delhi. Bangalore is the place to go! I ‘ve yet to decide on how to interpret the data from Japan, China, and Russia. While the Java/Sex ratio looks good there, but the pool of resources seem very limited. Do you agree with my scientific approach?

Google trends can give you some interesting food for thoughts, really. For example, my colleague Valery entered the following three words there: Obama, Osama, iPhone. The results are amazing – see for yourself.

Google Trends rules!

Christophe Herreman, a Java developer from Belgium made the following twit today:

“At the supermarket, and I once again seem to have picked the wrong lane… I wonder if there is a strategy for this. rdquo;

Being a member of the Java community myself, I feel obligated to offer my approach to making this very important decision that every Java developer has to make on a weekly basis.

First, I need to make a statement: out of all APIs I like Java Message Service (JMS) the most. IMO, JMS is the right way of architecting loosely coupled and reliable distributed applications. I explained this five years ago in the fifth article of my dissertation titled “Yakov “s Gas Station “. BTW, last week, I joined a project at a financial company and was pleasantly surprised learning that the trading application was build using just JMS, JNDI, and JDBC without the use of any other frameworks.

Now let “s go back to the supermarket scenario, and I “ll show how the understanding of messaging concepts can help you in picking the right lane.

1. In message-oriented middleware (MOM), messages are being placed into queues (think food items placed on the moving belt at the cash register).

2. In MOM systems we create message listeners that have to drain the queues and process messages (have to pick the items from the belt and scan their bar codes).

3. Ideally, the message queue (the belt) has to be empty ndash; each object put in the queue is immediately picked up by the listener. But in a real world, the speed of adding messages to the queue (placing items on the belt) may be higher than the speed of draining the queue. In this case we can add another listening thread or increase the size of the pool of Message-driven beans if a Java EE sever is in use.

4. The number of people (message senders) waiting in lines to each cash register (a queue) in a crowded supermarket is about the same. The message load (the number of items in the baskets) is also similar.

5. So what become the most important in the entire process? You got it – the speed of draining the queue.

Here “s comes the answer: picking the lane with the faster message listener is the holly grail of the consumer “s decision at a supermarket.

Christophe, the next time you are going to do your food shopping, spend about 30 seconds watching the cash register workers, and then pick the lane with the fastest one. As simple as that.

Actually, you need to know about yet another important messaging term, so-called poison messages. Say, your JMS listener is expecting only text messages, but for some reason a message of a different type (or the corrupted one) got into this queue (e.g. an item without the bar code). Then the process will become dependent on how efficiently such exceptional situation is being processed. In messing systems you can attempt a certain number of the redelivery attempts, and if this won “t help, the message goes into a dead-letter queue. In the supermarket they call the manager. Unfortunately, even I can “t predict in which basket the item without the bar code is located or which customer is planning to engage into a fight proving to the cashier that her expired cereal coupon should be accepted anyway.

I hope this life hack will save time to millions of Java developers, most of whom work for food these days. If you are not familiar with the Java messaging, I highly recommend to purchase my latest book Java Programming. 24-Hour Trainer, where I explain MOM and JMS in the lesson 30. Sorry for the shameless plug.

Enjoy your next shopping!