Passionate developers love to write clean code and make it more beautiful all the time. They call this Refactoring. In my experience refactoring is often misunderstood and is sometimes even used as an excuse to spend lots of time on improving the code structure. It is very tempting to learn more about how to make that particular piece of code even more readable, maintainable and elegantly. This then results in less developing of new features. How could we handle this?
Did you ever needed to have a group of option in which just one item could be selected, but the user did need to have the option to deselect any chosen option in HTML?
It can’t be done just by HTML checkboxes or radio buttons and the user experience of a select with options isn’t sufficient.
We did have to provide such a solution in a recent project.
Have you ever tried to change something? In (part of) an organisation, or maybe in yourself? How successful was it? How did you accomplish this feat?
According to this great little book called Switch, you most probably have addressed three significant areas: the rationale, the emotion, and the environment. The authors Dan and Chip Heath call these: the Rider, the Elephant, and the Path.
On the 8th of December I participated in the Global Day of Coderetreat 2012. I attended the one that was organized by two colleagues Bart Bakker and Marco Beelen at the iPROFS office in Haarlem. This event focuses on the fundamentals of software development and design by intense practicing.
The Sunday after the SCNA conference a code retreat was held at 3 locations in Chicago. I attended the one at the 8th Light office, hosted by Corey Haines.
Code retreats are really awesome! With global day being in a week from now I like to tell a little about code retreats and why you want to join us on global day. Read more…
On Saturday September 15, I attended a free workshop about continuous delivery by Robert Chatley, in Amsterdam. This workshop was organized by Ugly Duckling.
Continuous delivery is most about getting feedback much faster than with traditional (i.e. conservative) delivery strategies. Traditionally releasing is error-prone and time consuming, and often quite stressful. Teams and project managers want to release as few times as possible because it is so hard. The agile mindset teaches that if something is this hard you should it more often (practice it) so that you get better at it. Continuous delivery adopts this mindset and is about removing the bottlenecks from the delivery process, so that you can deliver in minutes rather than hours (or sometimes even days), at any time. Read more…
Using mock Liferay 6.1.1 services in a unit test.
When you are developing components, which interact with Liferay services, you will want / need to use mocks for those services.
In previous versions of Liferay the best strategy for this was to use the LocalServiceUtils in your production code and provide the mocks by setting that mockLocalService on an instance of the LocalServiceUtil.
For instance: To use a mocked GroupLocalService you needed to do the following in your test setup:
GroupLocalServiceUtil groupLocalServiceUtil = new GroupLocalServiceUtil(); groupLocalServiceUtil.setService(mockGroupLocalService);