AIR on FC 11

YAY!!! Got AIR installed on my laptop!!! It's strange that Adobe refuses to publish a 64 bit version of AIR. Had to do a lot of R&D (another word for googling ;-) ) to find out the hacks required to get it working.

Adobe's official site has instructions on how to install it on FC-11 From this site got the hint to replace all *i386* packages with *i586*.

It's wierd that you need 32 packages to run AIR. What a pain!!! But it works. I got the Yammer client working, and will now once again try to get Tweetdeck working!

Update:

Tweet deck is working too! :-)

handling the apparent slowdown

Recently an ex-co-colleague put in an email questions that I do believe are on the minds of a number of people and that I've been asked a couple of times already...

• How do you see the current market scenario?
• Is there any opening in java/j2ee?
• Also is it advisable to switch in this time frame, when companies are doing employee cuts?

 Good questions.And below is my Rs. 0.02...

 

In any scenario, it best to be where you know there is a need for your particular skills. In the current scenario of a slowdown, I'd suggest looking at it as an opportunity. This is the time to do the tihings you always wanted to do but were unable to find the time for it.

 

So as a few examples

• this is the time to get that certification you've always been putting off
• this is the time to do that bit of R & D on the new technologies you've been dying to give a spin
• this is the time to join that open source project and contribute to it, not only with code, but maybe with feature suggestions, bug reports, reviews, etc.

On the job front, I wouldn't say that the market is down, quite the opposite! The market is hot but it's very choosy. Hiring takes place only if you match 80%-90% unlike earlier where even a 20% match was enough to hire a person. While it makes landing a job a little time consuming, it does mean that a job is more secure, as once hired there is a genuine need you statisfy and hence less likely to be laid off!

 

So my advice would be, do not panic and use this as an opportunity! And whatever you do, create a report. A simple blog, or a one page word doc which will be the additional proof that you've done something constructive. This will help not only you but also the organisation you work in.

 

What do you think?

 

Design Patterns - Creational Patterns

I finally began a long overdue task of upgrading my design skills by reading the book Design Java. During this process I'll start another series to summarise my readings.

The book is based on another well know book by the Gang of Four but with a focus on implementing the original 23 design patterns in Java. Very rightly, it starts by highlighting the importance of design patterns today as:

1. Design patterns describes the communication between objects
2. They are recurring solutions to recurring problems, thus enabling reuse of solutions to common problems
   

Design patterns are divided into three categories, viz.,

1. Creational Patterns: Cover the cases for object creation
   
2. Structural Patterns: Compose groups of objects into larger structures
3. Behavioural Patterns: Defines communication and data flow between objects in a system

Another thing I liked is the way the book highlights the learning pattern for design patterns.

1. Acceptance: You accept that it is an important part of your work. I'm past this point and that's why I'm here! ;-)
2. Recognition: This is the learning stage where you begin to recognise the patterns, both the problem and solution patterns
3. Internalization: This is where you apply your knowledge.

These three steps aren't specific to the learning of design patterns but in fact are the general steps to learn anything and everything. It's an internalised process but knowing the explicit steps helps in understanding the process.

Two things to remember when using any design patterns are:

1. Program to an interface and not an implementation: This principle is the at core for reducing dependence on an implementation. Programming to an interface allows implementation to change with time for any reasons, e.g., better algorithms, newer technologies, newer frameworks, etc.
   
2. Favour Composition over inheritance: While this is not what we are taught in the OO theory, in reality favouring composition over inheritance eases up decoupling many a time. When I was first told this by one of my previous team leads (Irfan Mohammed), I thought he did not know what he was talking about! However, now I'm older (and hopefully wiser) and have realised the wisdom in his words then. I now go on preaching the same thing to everyone I meet!
   

Creational Patterns:
Creational Patterns are used when we need to handle special cases while creating new objects. The simplest way to create objects in Java is to use the new operator. However, many a time, special cases need to be considered and Creational Patterns may be used to solve them.

These are the five Creational patterns.
Factory Pattern
Creates different implementations for an abstract class or interface based on the input parameter(s). The client is unaware of the implementation being returned. If the implementation is changed, only the factory needs to be changed and the remaining part of the client is not affected.

From a previous post, I've also highlighted the benefits of using a static factory instead of calling the constructor directly. This is a variation on the Factory Pattern and I'd like to re-iterate to use the new operator only inside a Factory.

Abstract Factory Method
The Factory pattern applied to the Factory! Creates different factories that in turn provide different implementations for an abstract class or interface based on the input parameters.

Singleton Pattern
The Singleton Pattern is probably the most well know pattern. It's aim is to create a single object for a given class. There are a number of ways to do this in Java of which I favour the following:

• Creating a static implementation

Use a private constructor to prevent object creation.
The methods and data within the class are static

This pattern doesn't create a single instance and can still fulfill the requirement of having a single point within the system.

The downside to this is that the object is not dynamic, meaning it cannot be passed around nor can it implement any interfaces. It is best suited for utility classes.

• Factory that ensures only a single instance is returned

This has two flavours. An external factory or an internal static factory method. In both cases the factory ensures that an object instance is created only if one doesn't exist or returning the already created instance.

I favour the factory pattern over using static implementations because it is a bit more flexible and reduces the static coupling that the first method mandates. The additional benefit of the latter is that it can easily be extended to provide a pool of objects or to remove the singleton requirement if found necessary later.

Builder Pattern
From what I understand, the builder pattern and the factory pattern are different parts of the same coin.

The Factory or Director is used to create the Builder objects.

When the factory creates instances that are more complex in nature and which in turn build different implementations even though the interface implemented is the same. In terms of a UI, the builder is responsible for constructing different views or different UI to represent similar data in different representation based on a slight difference in the data. The book gives an example of using the Builder Pattern to create multi-select list of items a group of checkboxes if the number of items are three or less or a multi-select listbox if there are more than three items. The Factory decides which builder is to be created based on the data sent to it.

Prototype Pattern
The Prototype Pattern is largely used to create copies of an object. This is useful when the object creation is expensive. For example a database lookup or network call is required to populate and create an object. However, the same data in the object may be required to be manipulated or represented in different ways. Again an example from the book is of creating the prototype object after a database file lookup. Then creating a copy of the data a sorted list.

The book also talks about the default Java method for creating object copies, i.e., the clone method, and rightly highlights the common pitfalls of the clone method. IMO, the first rule for the clone, method is don't use it! But there are times you can't avoid it, and one has to be extremely careful in implementing an override.

Secondly, just overriding the clone method results in a shallow copy, i.e., all mutable referenced objects are common to both the prototype and the clone. If this is not desired and one needs a deep-clone Java does not really help you and you have to implement it yourself. Up until I read this book, this meant going through the complete object graph and recursively calling clone on every referenced object. But, the book highlight a simple cheat, use serialisation! It's so neat and elegant. Use a ByteArray to serialise the prototype using the ObjectOutputStream and then deserialise the object to create a deep-clone using the ObjectInputStream. Simple! Neat! Few lines of code! But it does have it downside, viz., every object in the graph must be Serializable.

The caveats for the prototype pattern is mainly it's impact on performance. While creating the copies of the prototype relatively cheaper than creating instances of the prototypes, there still is an expense of doing a deep- pr shallow-copy. Every instance retrieved of the prototype is always a copy which in turn will have a hit on performance.

My 2 paise here, especially in cases where read-only information is required, it would make sense to return an immutable interface to the object or an immutable clone if possible. But then this is a creational pattern and the reason one would use it is to create mutable instances of objects that are expensive to create from scratch. But I couldn't resist documenting my thoughts... (after all it is my Blog...uh... Blikki) :-D

Summary
To summarise this blog entry, I've gone through the first section of the book and looked at the creational design patterns, viz.,

1. Factory
2. Abstract Factory
3. Builder
4. Singleton
5. Prototype

Of these I think Factory is the basis for all creational patterns and the rest are really subtle extensions of it. And this is how I'll remember them:

Factory creates objects. If the objects created are factories in their own right then the top factroy is an Abstract Factory.If the objects construct something like UI etc., then the objects are Builders. A Singleton is a Factory returning only one instance of the object while a Prototype would be one that creates copies of an object.

Five creational patterns all linked with the core pattern The Factory!