When developers responsible to UX

While browsing in a mobile eCommerce site, I found something I haven't seen before and which I think quite amusing.
I guess that how web sites would have been look if developers would be responsible for UI.. :-)
 

Pay attention to the number the counting start with. :-)

Know your audience

Recently I've look into this blog statistics and saw the usage by browser type.
I was surprised to see that IE has less than 9% share.

Yes ! less than 9 percent.

The second surprise hit me when I looked in the usage by operating system.
Here MS has 53%.

Few years ago, when Firefox just arrived, the trend of MS losing its power just began, however, MS was still the dominant player.

That made me wonder if we are already in a time where MS empire lost its power or is it just a mirage..?

After a quick search I've noticed there are significant differences between sites.
For instance, in w3schools.com, another developer oriented site IE was ~18% . I guess we could find the opposite statistics on mainstream news oriented sites.

It appears that each site has it's unique characteristics based on its audience.

So I guess now it is the right time to put the famous quote "There are Lies, damned lies, and statistics", so whenever there is an opinion about the current market share in the browser domain, always try to find the origin and source and try to see if there is reference about the audience that research is based on. It might make the whole difference.

I know it sounds obvious, however, as developers, when we think about new feature to develop, we tend to think in the terms, concepts and examples we borrow from our daily activities, such as the browser type, standards to use, etc..  and assume our clients will catch that gap sometime..

So my advice is that next time just stop a bit and ask yourself who your audience is?

Try to have some statistics on them, so you'll have facts and not speculations and your opinion will be less biased.
(do it at least till IE will indeed be 9% share in the mainstream as well.. :- )

Spring 3.1 Release Train is complete

On March 14, 2012 SpringSource and VMware announced (and here) that the Spring 3.1 Release Train is complete.

The following is now fully support Spring 3.1 (with some changes in bullets)

• Spring Integration 
• Spring Security 
• Introduce session "validation" strategy instead of having invalid session check directly in SessionManagmentFilter  
• Remove internal evaluation of JSP EL
• Support HttpOnly Flag for Cookies in Servlet 3.0 Environments
• Allow HttpSessionSecurityContextRepository to have different session key for different instances
• Spring Batch 
• Spring Data 
• Support for locking
• Support for @IdClass in entities
• Support for LessThanEqual and GreaterThanEquals, True/False keywords in query methods
• Added CDI integration for repositories
• Improved parameter binding for derived queries for null values
• Spring Mobile 
• iPad is now recognized as a mobile device
• Split out Spring Mobile's WURFL integration into a separate project
• Added DeviceUtils and SitePreferenceUtils for convenient lookup of the 'currentDevice' and 'currentSitePreference', respectively.
• Simplified packaging by collapsing the device.mvc and device.lite sub-packages into the device root package
• Spring for Android  
• Android Auth - support for Spring Social & spring Security
• Updated RestTemplate to be compatible with Spring Framework 3.1
• Added support for Basic Authentication
• defaulting to standard J2SE facilities (HttpURLConnection) in Gingerbread and newer, as recommended by Google

Wish you an easy upgrading!

Mobile domination war

Recent article outlined the patent war that occur in the mobile arena.

It's clear that every company in this market understand the importance of  this market.
IMHO, the company who will dominant this field will be the next Microsoft (in terms of influence, leadership and standards setting)

source:
 Regulatory, Anti-Trust and Disruptive Risks Threaten Apple’s Empire
Adam Thierer Forbes,
4/08/2012
 http://www.forbes.com/sites/adamthierer/2012/04/08/regulatory-anti-trust-and-disruptive-risks-threaten-apples-empire/

Judgement day weapon for circular autowiring dependency error

On recent post I demonstrated a way to resolve circular dependency error.
However, sometimes, even the mentioned solution  is not enough and redesign is not possible.

I would like to suggest a solution of Dependency Injection which will be as much loyal as possible to the Spring IoC way and will help to overcome the circular dependency error.

This means that we will have a single class that will have a reference to all the classes which need to be injected and will be responsible for the injection.

I'll try to walk you through the steps.

Assuming we have the following service classes which cause the circular error:

@Service
public class ServiceA{

@Autowire
ServiceB serviceB;
@Autowire
ServiceC serviceC;

}

@Service
public class ServiceB{

@Autowire
ServiceA serviceA;
@Autowire
ServiceC serviceC;
}

First step is to remove the @Autowire annotations, so we will move the wiring responsibility out of Spring hands.

Second step is to create a class which will hold a reference to all the classes to inject.
Such as:

@Component
public class BeansManager{

@Autowire
private ServiceA serviceA;
@Autowire
private ServiceB serviceB;
@Autowire
private ServiceC serviceC;

get...
set... 
}

Third step is to create an interface name Injectable with method inject.

public interface Injectable{
public void inject(BeansManager beansManager);
}

Forth step is to set each service class/interface to implement the injectable interface.

e.g. :

@Service
public class ServiceA implements Injectable{

ServiceB serviceB;
ServiceC serviceC;
//method to inject all the beans which were previously were injected by Spring
public void inject(BeansManager beansManager){
this.serviceB =  beansManager.getServiceB();
this.serviceC = beansManager.getServiceC(); 
}

}


Fifth and final step is to set the BeansManager to be ready for the injection.
But take a moment to think -
It's obvious that we need  a reference of all the classes which need to be injected in the BeansManager, however, how can we make sure that the following sequence is maintained:
1. All Service classes are initiated
2. BeansManager is initiated with all the services injected by Spring
3. After BeansManager initiated and exist in its steady state, call all the service classes which need injection and inject the relevant service.

Step 3 can be achieved by a method which executed after constructor finished (via @PostConstruct annotation), however the big question here is how to make sure the BeansManager is initiated last? (after all the relevant services are initiated)
The trick is to have @Autowire on the Injectable set. This way Spring will make sure that:
a. All the injectable classes are subscribed to the BeansManager for the injection
b. The BeansManager will be initiated last (after all injectable services are initiated)

public class BeansManager

//This line will guarantee the BeansManager class will be injected last
@Autowired
private Set<Injectable> injectables = new HashSet();

//This method will make sure all the injectable classes will get the BeansManager in its steady state,
//where it's class members are ready to be set
@PostConstruct
private void inject() {
   for (Injectable injectableItem : injectables) {
       injectableItem.inject(this);
   }
}

}

Make sure you understand all the magic that happened in the fifth step, it's really cool.

Note:
If you think on a way to implement even more generic mechanism that will achieve the same, please drop me a note.

Good luck!

acknowledgement:
http://stackoverflow.com/questions/7066683/is-it-possible-to-guarantee-the-order-in-which-postconstruct-methods-are-invoke