Camel Case Java

Many developers try to learn and implement design patterns and object-oriented principles but most of the time they fail. Many only know those principals but they don't know how to use them or they don't know what they are for. However, there is one principle that can help you from drowning. That is called Simplicity! Simplicity doesn't mean you do the first approach that comes to your mind. That's probably the simplest approach though! Simplicity means that you design a component and write the code in such a way that: Looking at the code, anyone can tell what it's doing Maintaining the code is easy and can be changed easily if needed Debugging is easy and you don't need a million of break-points in order to find the bug.  Writing unit test is easy and simple too. The call-hierarchy of the methods in your code is not infinite! If a part is broken and you have to fix it, you don't need to fix everything else. To make your code/component simpl

After many years of coding, debugging, designing and improving applications I came to this point that being a good developer is the key for an application as well as the development team to success. As for an application, good developers make it less problematic and easy to maintain as for the development team, they help others to learn efficient code. This helps to reduce the cost of application maintenance as well as the time of getting new developers up to speed. Many have got this wrong impression that a good developer knows more about design patterns and knows how/when to use them. But that's not the case. In fact, a lot of developers with a good knowledge of OOP and design patterns end up in overengineering the application. No matter what framework or solution you are using, a good developer still worths a million! They are the real assets of a software company or a development team. Now the question is who is a good developer and what makes them so special? Plea

Why do we need Unit Testing? There are two important reason : To test different scenarios and making sure the logic we have just written works as expected In case a developer is changing the logic in future, they notice whether they have broken the existing logic or not What Should Be Tested? Different scenarios: E.g. each if-else statement can be taken as a separate scenario Data that we expect to be changed within a method Possible exceptions that may be thrown What Does Not Need to Be Tested? Mocked data that we created as input data Any result from a third party API. E.g: Hibernate, Spring etc. Results from classes that are already tested in their own unit tests. Example public Employer save(Employer employer) { if (employer.getActivateFlag() != null ) { if (employer.getActivateFlag()) { employer.setStatus(Status.Active); } else { employer.setStatus(Status.Inactive); }

With Hibernate, enums can be easily mapped either by enum item name or the position of each item but what if you want to map it to a customized value? In my case, we have so many one-character long columns in our tables, representing flags, statuses etc. We have heaps of them. Writing UserTypes for each enum field is very boring and nasty job. As every where you see in internet, you need to keep a Map for each user-type in order to map those values to enum elements. So to avoid this, I ended up with something more clean, easy and more generic. Now imagine you have following enum: public enum PaymentFrequencyEnum { WEEKLY("WK"), FORTNIGHTLY("FN"), MONTHLY("MT"), QUARTERLY("QL"), YEARLY("YL"); private String value;     private PaymentFrequency(String value) { this.value = value; } } I've chosen two-letter code as value so that you understand m

Okay now I have to migrate a dozen of domain objects from OJB to Hibernate entities and since we still have to use hbm files as opposed to Annotation, this is no enjoying task... I found this XML Stylesheet from this website below but had to make some changes in order to get it working... so I thought it may help someone: Download XSL file here Original file can be found here but so far at this time which is 16th of December 2013 and 6:37pm, it's not working properly :) martindavidsson blog

I have worked with JSF for almost 4 years. First time when I had a chance to work with GWT, I was very excited. Like many Java developers I was like 'Wow I don't need to play with those bloody tags and elements and now it's pure Java code!!!'... I was so happy but my happiness didn't last very long. Programming is my passion. I hate writing codes that become a mess later and unfortunately this is what will eventually happen with GWT. The thing is you can't rely on reviews and features of a software or an API, in action everything goes different way. Specially when it comes to large scaled application and in an environement where everything is urgent and importnat... well, I think all software companies are the same in this regard... The fact is that in a team of developers not every one cares about best practices, design patterns and even if you have very experienced designer, solution architect etc, still you can't force the team to deve