The project layout

I’ve set up my project folder layout and it looks like this:


There are many project folders, but we don’t need to worry about it because maven will look after the building for me. Lets have a closer look at the each of the project folders


The beans folder will contain a whole bunch of EJBs that do a bit of logic, factories, utils etc. It’ll the place to put the EJBs, keeping in mind that we don’t need to have beans implementing interfaces, I’m going to try do away with the interface classes all together – they mostly are just bloating the code base anyway.


This is a very important project, this is our “APIs” that will be shared with 3rd parties. Although they can use my webservices using their own client, it’s a to have a client written for you that you just use. Amazon have done a super job of providing client libraries and really should be something to release to the world. This is just not for 3rd parties though, I’ll be using within my own beans to make webservices calls (more on why this is a good and bad idea in another blog when I’ve got around to actually writing client code).


I’m all for not using entities in my project, I’m starting to side with the fact web like services are actually hindered by entities, but that is another topic for another day. For now, this will be here readily available in case I find it too much of a burden.


This is where all the real SQL queries will live. I’ll be using JPAs connection pooling (ie. the entity manager) to call a bunch of native queries. In the bigger abstract picture, you can see this a ‘the database’ for the application, so if I change from mysql to something else, only this project will ever need a bit of a re-write.


This is where the implementations of the restful web interfaces will be written, also a bit of behind the scenes magic will happen here. It will mainly call out to the beans to do all the work.


This is a very basic and very simple project to keep the data objects that are used to and from external sources via the web service. If you will, it’s the java objects that represent the JSON that is passed between client and web service.


The interface classes are sitting outside of the web project because we might use those interfaces in a client or another version of our services. Also, it allows us to expose and show off that one project without worrying about actually code going out in the case we want other people to implement or extend the interfaces. Might be a bit overkill but I’m going to stick with it.


This one is a bit of experimentation for me. This is where other services that exist outside of a web call will exists. This includes some cron jobs, back end shortcuts, reports, monitoring and the such. I could have put all this into the beans project, but I want to try keep client facing code and internal facing code implementations as separate. Webservices will use the beans or REST calls if needs.

Web test

I have an idea that unit tests, in the bigger picture of things, are not really something I’m going to go for. I’ll be using the junit framework to run integration like tests from this project. This project may even become a Chaos Monkey.


Lastly, the ear project that is just there to package everything into a nice single file.

It looks like serious overkill of project folder structure for sure. I think in long term having smaller projects will help keep separations of layers and groups code with the same objectives together is a way to go. Let see how it turns out.

Working from home

So yahoo has now sparked the whole “is it better to work from home debate”. Yahoo! CEO┬áMarissa Mayer has thrown down the gauntlet and is now going to enforce people to come into the office. And I agree, you need people to be in the office, but could this be a very bad thing?

The cost of working from home

Ultimately, this what it’s all about, and this is all speculation and assumption on my part but lets have a look at the costs of working from home. First, and most “soft” topic is that there is a claim (from bosses) that working at home encourages people to slack off. This is just purely from a person point of view, there is no hard and fast rule about peoples behavior at home. Some people are slackers, some are not. It’s very hard to evaluate a persons productivity in the week.

Something more measurable is the cost of “group thinking” – where you feed off each other and get help from each other to solve problems effectively. There is a cost to working alone in my profession. Big cost is the lack of knowledge sharing, from “hand over” type knowledge to simple things such as information on daily bug fixes (eg. “you can’t just write a method to deny access because customer A needs access still”). Bugs, miscommunication and disjointed work can be hugely costly.

Another soft cost is no accountability to product. It’s so easy to ignore the fact there are other people involved when you never see them. This happens in the office too, those remote satellite office people who mysteriously get your number. I feel nothing for them and there problems, and I think that could happen while working from as well. Perhaps even more so because of the possible attitude of “don’t bring that attitude to my home”.

There can also be the problem of not having access to company resources, or even being the victim of the “don’t bring that attitude to my home” when you need some help. Company resources can be wonderful, free calls to other work people will be missed if you are at home. Sure, there is Skype, but not everyone has it available all day.

So these are some major impacts that can happen on your products, your service and timelines. It can be pretty damning to a company.

The good things about working from home

With the bad, comes the good.

Home work can be more productive. If you take into account the time saved in traffic, and the stress saved involved in commuting every day – you get happier employees. Happy employees are productive employees. Also, the range of people you can access increases dramatically – you can now hire a very talented someone who lives very far away. Considering the shortage of talented and skilled programmers out there, it’s possibly a good thing. Also, it’s an added incentive to get the best to stay with you.

Another cost saving side is office space, network costs, internet costs, lighting, safety and every thing that comes with running an office. Offices are expensive. Having a workforce at home gives that person much more space and comfort than a company could offer.

Another double edged sword is that when people work from it starts to blur the lines of when work starts and stops. You can get people being productive during times they wouldn’t normally be productive. Such as the 30min to 1hr that they would normally be stuck in traffic they are instead doing some hard work. The double edge comes in that it may start to make home feel like work and demotivate. Used responsibly people can be much more productive and willing to help out while outside of normal work hours, provided it’s in moderation of course.

Depending on the persona and home environment you’ll also fun less unnecessary interruptions. I’ve found that interruptions are devastating to my productivity and the main reason I’m much more productive at home.

So which is better?

Neither and both. It really depends on the size of the company, the product, the people, work environment. Although, what I will say about this whole topic is that if you have people that are passionate and committed to what they do (ie. They love what they do) they will find what makes them most productive, and that’s what you’re looking for. Enable people to be most productive in a way that fits them.

No really, which is better?

If someone can work from home, a combination of working at the office and at home. When you need to be at home for reasons let them be at home but encourage them to come to the office as much as possible (at least 50%+ of the week) by making the office a nice place with nice people and resources.