Welcome!
Thank you for visiting the home page of Sunergeo Systems, Inc. I have operated this consulting practice since 1998, providing a wide variety of software development solutions to customers of all sizes.
Recent Posts
Innovation Lacking? Try FedEx Days…
Innovation – it’s the bread and butter of any tech-oriented company. If you’re not doing it, your products, services, and ultimately your company are regressing. Without innovation, you on the surest path there is to dinosaur state. I’ve read a lot of things about what large companies do to foster innovation. 3M, for example, allows employees to have every Friday to work on anything they want, regardless of whether it’s related to any current project. I recently came across another such innovation-fostering practice being employed by a large scale software vendor called Atlassian.
The idea is quite simple, but very powerful. Allow a select group of employees to participate in a competition for creating the most innovative feature. The catch? It must be fully shippable within 24 hours. Hence, the term FedEx Days. Very clever! And from the results they report at Atlassian, far more than just clever. They’ve been able to achieve some very sophisticated feature improvements based on this model. Apparently, the combined elements of competition and a fixed time constraint are key ingredients to achieving that innovation spark that’s often missing on extended projects.
So, if your team is stuck in a rut, consider giving this approach a try. You can offer real prizes (free beer, cash, trophies), benefits (additional vacation days, prime parking spot, name on the company newsletter), or just good old fashioned bragging rights. Lots of potential here, and it doesn’t have to be expensive.
PS: For a great demonstration as to why this works, check out this video!
Napoleon Hill and the Knowledge Economy
“He had never heard that more gold has been mined from the brains of men than has ever been taken from the earth.” This statement was made by Napoleon Hill in his seminal classic Think and Grow Rich
The hope which Mr. Hill so generously points out to the readers of his time is the same hope that is available to us today, despite persistently high unemployment, a stagnating economy, and the ineffectiveness of governments around the world to do anything about the economic woes that continue to plague us. What is this great hope? It certainly is not government benefits. It isn’t even better education or job training. This hope consists of two key ingredients – DESIRE and FAITH. And these ingredients are not restricted based on race, gender, color, creed, disability, age, or any other limiting factor of which we are prone to complain. They are literally free to all.
Mr. Hill had no way of knowing how men like Steve Jobs or Bill Gates would transform the world. These men, and others like them, generated literally billions of dollars in wealth for themselves and people all over the world from one simple raw material – the incomprehensible power of ideas. And these are a just a couple of examples – volumes could be written containing the stories of thousands of others just like them. Consider this question: Which has produced more wealth – the diamond mines of Africa, or the digital ecosystem that was created by the advent of the Internet? It’s not even close! Far from running out of resources, we stand on the shores of a vast digital ocean that has only begun to be explored, much less mastered.
So, the next time you are tempted to allow a little laziness to slip in and excuse it away by blaming the bad economy, remember this statement from Napoleon Hill. And remember that others have faced far worse times than we, and not only overcame, but built tremendous fortunes and lasting legacies. You are without excuse – the DESIRE and FAITH that empowered Andrew Carnegie to build his empire, or Henry Ford to build the V8, or Steve Jobs to revolutionize the way we consume media – these ingredients are freely available to you and I today. Let’s settle it right now, and determine to tap into that vast resource of ideas. The solutions to our worldwide economic woes are no further away than that grey matter between our ears. Let’s get to work!
A Simple TDD Tutorial – Part IV
The name of my first test is IndexShouldThrowIfStartDateIsInvalid. I am using convention to declare what I expect the test results to be. It is very important that tests be this singularly focused. I am not testing all the parameter validation at one time, since order depence can result in subtle bugs. I’m also not simply skipping input validation, assuming that it will be handled later. I’m explicitly testing my input validation from the very beginning. Once you get into the flow of doing this kind of testing, these tests only take a few minutes to write, but their benefits continue throughout the rest of the life of the project.
So, here is the finished code for this first test:
Very, very simple! Unit tests should not be too long. If they are, then it’s probably because you’re testing too many things. So, just as the test name implies, I’m feeding my controller bad data intentionally, and then checking the results of how my controller handles that data. I expect to get an exception, so let’s look at the controller code:
Since I know the MVC framework will handle creating a DateTime object from the data passed in via the query string using a parameter of the same name, I really only need to test whether or not a date was passed. My controller logic requires a start date, and an end date, and the end date must be later than the start date. So for this first condition, I check for an empty date. If I received an empty date, I throw a special JsonException. You can see that in the catch block for JsonException, I do the following:
- Log the exception – all exceptions should always be logged
- Set the status code to be returned to the ajax call, letting the javascript know an exception occurred
- Return a JsonResult view, containing the exception to be passed back to javascript
I also include a default catch block to handle any unexpected exceptions in the same way.
With this done, my test will now run and pass.
That concludes one iteration of the process. I can now check this code in! It will not break the build, it’s legitimate (though incomplete) code. Repeat this process for the remaining conditions, such as:
- Test the end date parameter
- Test that start date and end date are correct with respect to each other (i.e. end date comes after start date)
- Test that a valid logged in user initiated the request.
After all of the tests for bad data conditions are finished, the last thing to do is write a test for the valid case. With all of these steps completed, you now have a solid, reliable, repeatable way to test this controller. When it comes time to refactor this controller, you can do so with confidence, knowing that this path through the code will always be exercised automatically when the code is checked in to the central repository.