Kudos to Apple ...
... for causing everyone to s**t their pants in anticipation of yet another Apple announcement
[2 Comments]The little things about IntelliJ
Yes, i know I just posted a mild rant on IntelliJ, but here is one of the reasons why I still like it soo much. IntelliJ 9.0.2 introduces a feature that allows you to resize a window without needing to use the mouse: Resize (tool) windows with keyboard
Its little things like this, and the ctrl-E feature, and the alt-home feature, and the ctrl-w feature, and the 3 panel merging, and all the refactorings, and the contextual JUnit test runner, and the live templates, and the scope based colorings, and the maven integration, and so on and so forth, that keep me using IntelliJ ... Its those little things that seem to just make me more productive. I just wished they would focus more on these sort of features that allow us to be more efficient in day-to-day activities, and less on gimicky features and flaky support for third party libraries ...
*sigh*... I'm slowing finding myself in a love-hate relationship with my IDE :(
[0 Comments]Whats wrong with IntelliJ nowadays?
Anyone noticed how bloated IntelliJ is nowadays? Seems like they are forgetting their core market (J2SE and JEE development) and are bloating it with third party support of stuff such as Flex and Grails, to name just a few.
I just updated to Intellij 9 and, among a list of problems, are 2 pretty serious ones: subversion updates and JUnit with JDK 1.3 support.
[Read More] [0 Comments]Got to use static factory methods more often
Most of us are used to creating new objects via a classes constructor. I think this stems from our first experiences of Java, where the simplest way for creating objects was simply to use a constructor.
However, just recently I’ve started to use the static factory method technique, as outlined in Joshua Blochs Effective Java (Item #1) whenever I need to create new instances. And, having done so a few times, I don’t think I’ll go back to using constructors directly except in the most trivial of cases.
[Read More] [2 Comments]Yet Another Argument For Testing
Recently I had to make a fundamental and far reaching change to a software system that I was building. I had to introduce a version column into all the database tables that our application was using. The reasons should be fairly self explanatory for anyone familiar with concurrent database access, and more specifically Hibernate (optimistic locking for those not in the know). One might argue that we should have done this from the very beginning, but regardless it only serves to illustrate my point.
Upon introducing the version column to all my tables I ran all my tests (unit, integration and acceptance) and found that there were about 3 integration tests broken and 10 acceptance tests. They were legitimate bugs that were found as part of the version column being required (Hibernate assumes that all entities without a version column are new values, and this was causing issues when updating records through the UI). After fixing these bugs I re-ran the tests again and all green. I checked in and all was happy in my software application...
... until I found out that about 1/3 of the application had actually been broken as a result of this change and the build was still green....
[Read More] [0 Comments]An Estimate for an Estimate
My PM came up with this gem yesterday morning at standup:
"I need you to estimate the time required to give me an estimate of the work remaining"
[Read More] [8 Comments]Project Managers should use their budgets to bid for resources
One of my colleagues currently finds himself torn between two projects. The one he is currently working on and the one he is supposed to be starting next week. Problem is that lack of resources have meant that both projects need him at the same time...
We came up with what we thought was a 'unique' way of addressing this. Developers should be put up for auction for projects within an organization :D Each PM has a set budget for each project, and uses that budget to bid for their desired developer accordingly. Obviously, the projects with the bigger budgets can afford to purchase more developers for greater periods of time. Projects with lesser budgets can still get developers but just fewer of them for fewer amounts of time. The budget on the project is obviously relative to the projects importance and scale within the organization.
This would follow the same model that many sporting clubs follow when bidding for players, and would solve any arguments about resourcing! If you don't have the cash, or are unwilling to put it up, then you don't get the developers you want!
Market forces at play! hahaha...
Obviously there are probably still some kinks that need to be ironed out before this actually gets applied to a real project =)
[22 Comments]Its in the project managers best interest that we stay at work
Write Proper Tests and Favour Descriptiveness over Succinctness
Descriptiveness is important when writing tests. When choosing the name of a test method, it is more important that it explains exactly what the test does, rather then being as short as possible. For example:
@Test public void shouldSendAnEmailToAdministratorsWhenAUserMakesAPayment
Even better, ignore the java standard camel casing when writing test method names to further improve the readability:
@Test public void should_send_an_email_to_administrators_when_a_user_makes_a_payment[Read More] [0 Comments]
This is how much time we have, so this is how much time it will take!!
Single Point of return is nice in Java, but essential in Ruby
A single point of return from a method has usually been a stylistic point that I try to adhere to when writing Java code. Single points of returns make code easier to follow as developers do not need to scan multiple return points to understand where the method may exit and under what conditions. So, is it really just a stylistic point or an essential tool in helping to achieve better quality software? The answer, I believe, is it is stylistic in Java, but essential in Ruby.
[Read More] [3 Comments]Its usually more trouble to do something properly than it is to do it half-arsed
A Ruby on Rails Builder Implementation
Creating test data can often require the construction of complex data object, usually with many dependencies that need to be created at the same time as the data object. The Builder pattern greatly simplifies the code required to create such objects, and the implementation of this pattern is especially easy in a dynamic language such as Ruby. The result is a highly customizable builder that allows your tests to create very specific and complex data structures with the minimum of code.
[Read More] [1 Comments]Test Fixtures in Ruby on Rails do not scale
I believe Test Fixtures in Ruby on Rails are, for the most part, evil.
The key flaws outlined in this post include:
- Test Fixtures create shared test data
- Test Fixtures are notoriously hard to setup non-trivial data
- Forgetting to declare a Test Fixture leaves the database in an unknown state
The solution outlined in this post:
- Use Test Fixtures ONLY for data that is absolutely common to the entire test suite
- Create data in setup methods
- Implement a builder pattern for complex data relationships
Code Responsibility, not Code Ownership
http://www.theregister.co.uk/2008/05/30/google_open_source_talk/
Basicly, whilst never explicitly stated, they believe in Code Responsibility, not Code Ownership. Summarized by this quote in the article:
"You have to discourage people from feeling like 'This is my module. I wrote this. Every change has to be approved by me,'" Collins-Sussman argues. "That's very dangerous for the project as a whole."
[0 Comments]