Archive
YAGNI Doesn’t Always Apply
YAGNI means You Aren’t Going to Need It. It’s a software development philosophy that suggests features should not be added until a customer (or product owner) asks for them. Many times, you really aren’t going to need it, but if you apply YAGNI incorrectly you may get yourself into a bit of trouble and your code may begin to smell…
Software Developer and Evolution Conference 2010
Looks like this October i’ll be making my way east out to Winnipeg where I have the opportunity to present two sessions at the Software Developer and Evolution Conference. I’m very excited as not only will this be my second conference of the year that i’m presenting at, it’s also going to be my first time in Winnipeg. If you know of any fun family things to check out in Winnipeg please leave a comment!
My first session is about self organizing teams, participating on and leading. There’s a lot of things to think about when it comes to creating and fostering self organizing teams. I plan to talk about some of them from the perspective of a manager and leader, as well as a team member on the team. I’m also coming up with a good exercise that I hope will be fun and help illustrate my points.
The second session will be on iterative development. I did this session at the Prairie Developer Conference in Regina, and i’ve used the feedback I received from the attendees there to refine the presentation to hopefully be even better, and i’m also incorporating an exercise in to this one as well.
I’ll probably be making more posts on those two topics in the coming weeks, so check back for more.
Self Organizing Teams, a new take on Hiring
If you won the lottery, the person is exactly what you were looking for, has all the right skills, fits in with the rest of the team, and is paid fairly according to their skills. Now go log in to your online banking app and check if you’re a millionaire……….No? I didn’t think so, because as it happens, most of us have never won the lottery 
http://agileshoptalk.wordpress.com/2010/08/19/self-organizing-teams-a-new-take-on-hiring/
Demonstrating Responsibility
Just about a year ago I attended the Agile 2009 conference in Chicago where I had the opportunity to take part in a half-day workshop with Christopher Avery. It was here that I was first exposed to his Responsibility Process which inspired me to write the post Operating from Above the Line shortly after. I was hoping to run a similar workshop at Point2 to demonstrate Avery’s idea, but I couldn’t garner enough interest from a large enough group to make it worthwhile.
Fast forward a year and coincidentally enough Avery’s Responsibility Process came up as a topic during a staff engagement workshop championed by our Director of Human Resources. As it turned out some of the Responsibility Process posters also started showing up on walls throughout the office, but without context people didn’t know what to think of them.
Following the staff engagement discussion I was approached to run a workshop that would help to demonstrate the Responsibility Process to our Sales, MLS, and Syndication teams. I was very excited to do this and planned to fashion it after Avery’s effective Agile 2009 workshop. It’s easy to get the gist of the Responsibility Process by reading about it, but the true benefit is seeing it in action.
The idea is to get people to work on a difficult task as a group that will likely result in failure, and keep track of behaviour during the exercise. For this particular workshop we had ten people so I split them up into two groups of four. The remaining two were to be my observers.
- The Builders’ Job: build a ten story, free standing structure using only a deck of cards and a small amount of fun tack in fifteen minutes.
- The Observers’ Job: listen to the builders and take notes of any phrases that sounded negative.
Anyone who has tried to build a house of cards probably knows that reaching ten stories is nearly impossible. One group managed to get to seven, while the other group’s unorthodox design proved to be….well, good in theory. But as you guessed the point of the exercise was not to actually build a structurally sound building, but to surface behaviour that fit into the different states of mind on the journey to responsibility.
- Lay Blame
- Justify
- Shame
- Obligation
- Responsibility
Here are some examples of the phrases that were recorded by our observers.
- I already know who’s fault this is.
- We don’t have the right materials
- Someone else do it. I’m too scared to go on.
- We don’t have enough time.
After writing each of the phrases recorded by the observers on a whiteboard I started to explain each of the states of mind of the Responsibility Process. Once everyone had a basic understanding we grouped each phrase into its appropriate state. Some were easy to categorize while others were more difficult which in turn spawned some excellent debate. What I found to be the most beneficial was real life examples brought forward by some as to when they may have been in one of these states recently.
We left the workshop understanding the premise behind Avery’s Responsibility Process, but were aware that this was only the first step. As individuals it is up up to us to make the effort in identifying our states of mind when we encounter conflict, and do what we can to move as quickly as possible to the next level. Now having ten people at Point2 aware of the Responsibility Process, we could lean on each other for support when learning to identify what state we were operating in. And as a company having as many people operating from above the line seems like the responsible thing to do.
We survived ÜberConf!
This NFJS conference was intense with a lot of good speakers. Sean, Brian and I started ÜberConf 2010 in Denver with a 
relaxing Monday evening of dinner with a KeyNote on Challanges and Directions in Java Virtual Machines by Dr. Cliff Click. Following the keynote was a meet and greet party with delicious Hors d’oeuvre and free beer. It all sounds great and easy? That’s just the beginning.
The real hard work started on Tuesday. The sessions went from 8am – 10pm. Yup, 6 great 1.5 hour sessions in a day. Our brains were overloaded with information and code snippets. Dr Cliff Click finished both of his sessions (The Art of Benchmarking and Fast ByteCodes for Funny Languages) earlier. He offered bonus talks on The Pauseless GC algorithm and Towards a Scalable Non-Blocking Coding Style. Rather than 6 sessions, I had the great opportunity of attending 8 sessions in a day instead.
With so much going on, we could have easily turned into zombies before the evening sessions. However, the two evening sessions (Mike Richard’s session on the Art of Messaging and Venkat Subramaniam’s session on How to Approach Refactoring) that I had attended were gold. The speakers kept the adrenaline going with lots of great jokes (e.g. “Commenting out code during refactoring is like leaving a dead rat on the table”) and interesting titbits.
In a nutshell, funny speakers, great material, delicious food and beautiful weather (29 degree celsius), we can’t complain. Now it’s time to go home, go through the notes to recap what we have learned and use it well.
Prairie Dev Con 2010!
Chris from P2 Presenting at PRDC10
Since this was the first time a big software conference had been hosted in Saskatchewan, the organizer, who works primarily with Microsoft technologies, used many of his contacts from within that community to put together a good list of speakers. Now that the conference has been run once and had a good attendance, the hope is for next years conference that we can attract speakers on a more wide range of technologies such as as Python, Django, Scala, and document style databases such as MongoDB.
Since Point2 has been doing a lot of interesting work with new technologies, I hope for next year we will be able to put on a number of talks to offer a more well rounded list of topics for next year.
Overall, I was really impressed with PRDC10 and I am looking forward to seeing it happen again next year!
It’s Time to Ante Up and Go All In
Mark Hollman and I are heading on an adventure in the city of sin. What is this adventure you may be asking yourself, well it is the 2010 Better Software Conference and Agile Development Practices Conference in Las Vegas, Nevada June 6 – 11th. The conference is hosted by Software Quality Engineering, a consultancy firm that “offers education, publications, and real-world expertise to help you advance your software practices”. Our mission is to absorb as much information while in Vegas and make sure it doesn’t stay there.
I am very excited for a two day workshop that is new to this conference in 2010. I will be attending the Business Analyst Workshop on Monday/Tuesday. This workshop focuses on knowledge and skills that make a business analyst successful. The sessions are going to be highly interactive and provide me with practical takeaways I can use as soon as I am home in Saskatoon. I also will be attending a session on “Testing with Real Users—User Interaction and Beyond” by Seth Eliot and other sessions related to business analyst work. I hope to absorb all the information I possibly can and turn it into further blog posts and presentations for my coworkers at Point2.
Mark is excited for all of the sessions he will be attending and hopes that he can bring back tools and techniques that will help Point2 improve our process’s and collaborations between teams and departments.
Hopefully at the end of a tiring, but fun filled week of learning, networking and riding New York New York Roller Coaster, Mark and I can get some sleep. If you’re going to be attending the conference, or think there is something we should see or do while in Vegas – leave a comment!
“There’s just no quiet in Vegas” ~ Barry Manilow
By: Devon McGeary
Django’s assertRedirects little gotcha
Something we’ve be trying to pay more attention to with our newest green field development projects is the running time of our unit test suites. One of the projects was running ~200 unit tests in 2 seconds. As development continued and the test case number grew, it started taking 10 seconds, then over 30 seconds. Something wasn’t right.
First challenge was to determine which were the slow running tests. A little googling found this useful patch to the python code base. Since we are using python 2.5 and virtual environments we decided to simply monkey patch it. This makes verbosity level 2 spit out the run time for each test. We then went one step further and made the following code change to _TextTestResult.addSuccess:
def addSuccess(self, test):
TestResult.addSuccess(self, test)
if self.runTime > 0.1:
self.stream.writeln("\nWarning: %s runs slow [%.3fs]" % (self.getDescription(test), self.runTime))
if self.showAll:
self.stream.writeln("[%.3fs] ok" % (self.runTime))
elif self.dots:
self.stream.write('.')
With it now easy to tell which were our slow tests we set out to make them all fast again. As expected the majority of the cases were an external service not being mocked correctly. Most of these were easily solved. But there were a few tests where we couldn’t find what hadn’t been mocked. Adding a few timing statements within these tests revealed the culprit. The Django frameworks assertRedirects method.
def assertRedirects(self, response, expected_url, status_code=302,
target_status_code=200, host=None):
"""Asserts that a response redirected to a specific URL, and that the
redirect URL can be loaded.
Note that assertRedirects won't work for external links since it uses
TestClient to do a request.
"""
if hasattr(response, 'redirect_chain'):
# The request was a followed redirect
self.failUnless(len(response.redirect_chain) > 0,
("Response didn't redirect as expected: Response code was %d"
" (expected %d)" % (response.status_code, status_code)))
self.assertEqual(response.redirect_chain[0][1], status_code,
("Initial response didn't redirect as expected: Response code was %d"
" (expected %d)" % (response.redirect_chain[0][1], status_code)))
url, status_code = response.redirect_chain[-1]
self.assertEqual(response.status_code, target_status_code,
("Response didn't redirect as expected: Final Response code was %d"
" (expected %d)" % (response.status_code, target_status_code)))
else:
# Not a followed redirect
self.assertEqual(response.status_code, status_code,
("Response didn't redirect as expected: Response code was %d"
" (expected %d)" % (response.status_code, status_code)))
url = response['Location']
scheme, netloc, path, query, fragment = urlsplit(url)
redirect_response = response.client.get(path, QueryDict(query))
# Get the redirection page, using the same client that was used
# to obtain the original response.
self.assertEqual(redirect_response.status_code, target_status_code,
("Couldn't retrieve redirection page '%s': response code was %d"
" (expected %d)") %
(path, redirect_response.status_code, target_status_code))
e_scheme, e_netloc, e_path, e_query, e_fragment = urlsplit(expected_url)
if not (e_scheme or e_netloc):
expected_url = urlunsplit(('http', host or 'testserver', e_path,
e_query, e_fragment))
self.assertEqual(url, expected_url,
"Response redirected to '%s', expected '%s'" % (url, expected_url))
You’ll notice that if your get request uses the follow=False option you’ll end up at line 34 in this code snippet which will kindly check to make sure the page you are redirecting to returns a 200. Which is great, unless you don’t have the correct mocks for that page setup too. Mocking out the content for a page you aren’t actually testing also didn’t seem quite right. We didn’t care about the other page loading, it had it’s own test cases. We just wanted to make sure the page under test was redirecting to where we expected. Simple solution, write our own assertRedirects method.
def assertRedirectsNoFollow(self, response, expected_url):
self.assertEqual(response._headers['location'], ('Location', settings.TESTSERVER + expected_url))
self.assertEqual(response.status_code, 302)
Back to a 2 second unit test run time and all is right with the world again.
Dustin Bartlett
Tales from Vegas, Part 1: James Gosling’s Keynote
A few weeks ago I had an opportunity to go to The Server-Side Java Symposium, an annual event for Java aficionados held in Las Vegas, Nevada. What happened there will not stay there, however.
I found a few interesting things out, and I’m going to try to share them over the course of a few blog posts, in case anyone out there is interested, and so I can find them later for myself as well.
TSSJS is not about vendors, it’s about technical info, so there were only a few “booths” from the handful of commercial sponsors of the event, one of which was, inevitably, Oracle. Given the Sun acquisition, a question on the mind of many developers has been “what’s Oracle going to do for/with/to Java?”.
It’s a legitimate concern, and indeed a complex question with a number of complex answers – but one of my reasons for being in Vegas was to get some of the answers.
The keynote presentation at TSSJS was by James Gosling, the “father” of Java. As everyone no doubt reading this already knows, he’s subsequently left Oracle, for undisclosed reasons. That, to me, lessens the impact of his remarks somewhat, as I suspect he knew by the time we heard him speak in Vegas that he’d be on the way out the door, but he still had a lot of interesting things to say.
About 800 people were in the room, I estimated, to hear the keynote. Interestingly enough, Gosling’s position at Oracle was “Client Software Group” VP. I generally don’t think of Java as having much to do with “client” software, personally, so that in itself was informative.
He had an image of the Java mascot (the little delta-shaped guy) wearing a snorkle in a fish tank, a play on the “Soracle” name mash-up.
In any case, the keynote touched on what’s happening in the Java world. He emphasized the wide spectrum of devices on which Java is found, and how networking ties all of these devices more and more into a cohesive whole.
Some stats were mentioned: there are about 15 million downloads per week of Java, and something like 10 billion (with a “B”) Java-enabled devices of one sort or another out there in the wild, perhaps 1 billion of which are Java-enabled desktops. By any metric, Java is a huge success, and is in many ways more popular in the rest of the world, especially Europe, than it is in North America.
100 million of those devices are are TV devices, and on top of all it are about 2.6 billion Java-enabled cell phones.
Conclusion: It’s not going away, soon or quickly.
A site like the Apple App Store existed for Java apps 7 years before Apple’s app store – but it was in Japan.
There are 5.5 billion smart card devices Java-enabled out there – the V3 standard actually has a servlet container in it – U.S. military dog-tags apparently now use this standard.
The Amazon Kindle is a Java device, under the skin.
Gosling proffered a definition of success: being completely invisible, people just get stuff done.
There are something like 6.5 million professional Java developers out there, 800 thousand of which are in India. Most colleges have a Java course requirement, modifying the old saw of “write once, run anywhere” to include “learn once, work anywhere”.
After this deluge of interesting stats, Gosling moved on to discuss the next big thing in Java, in his opinion: Java EE 6, the foundation for next-generation enterprise software. The spec was approved November 30th, 2009.
There are two major flavors of JEE6 – the “full” profile, with everything, and the “web” profile, with EJB3 “Lite” and just the most frequently used specs, not the more obscure stuff.
A major emphasis in next-generation Java development is modularity: making hard problems easier by breaking them into a number of less-hard problems. Major endorsement here for OSGi.
As far as Gosling’s concerned, the correct amount of XML required is exactly none Many developers in the room agreed with him, and it’s now possible with JEE6 and it’s powerful annotations.
Much of the benefit of dependency injection and resolution that Spring provides has been baking into the core Java EE platform now, and much of the pain of EJB has gone away. In fact, one of the most painful parts of EJBs, CMP Entity Beans, is no longer supported by the spec at all, in favor of JPA.
Glassfish V3 is the JEE6 reference implementation, and it’s OSGi-based.
Then it was demo time: Gosling (with some help from a couple of developer types) fired up Netbeans and Glassfish and did some show and tell of the coolness of JEE6.
We saw a webapp deployed – with no web.xml, no WEB-INF directory at all, everything annotation-based and dependency-injected at the proper times. We saw a stateless EJB auto-deployed to via an OSGi bundle into the container in less than a second, direct from the IDE. No boilerplate, no config, no reams of XML files to bolt it all together, just code and go.
We saw that same app preserve session state even when it was redeployed, which was very cool (a counter was showing the number of hits to the page – code was changed and redeployed, and the counter kept incrementing – and no, it wasn’t stored in a client-side cookie, it was in the session).
I noticed that all the Oracle guys were using Macs, incidentally.
Gosling notes that JEE6 shouldn’t just be one version number past JEE5 – it’s more like JEE 60 in comparison
Saw the @Schedule annotation, where a bean can be scheduled for execution with cron-like ease, but all within a JVM.
Gosling noted that Felix was the web container under the skin of Glassfish.
We saw the @Observes annotation being used – a way to register listeners without any code or configuration. It was noted that Swing could benefit enormously by this pattern.
Then we saw a demonstration of Glassfish’s web console. The “web profile” of JEE6 doesn’t include JMS by default, so the example shown was adding that support by installing a new bundle in the running container. Two clicks and it was done. A GUI admin console can be added for any bundle, including your own bundles.
Gosling then wrapped up with an overview of some of his personal projects, and then took some questions. He also mentioned a new “app store” for Java that’s in the works, to be coming on “store.java.com”. It’s in the final stages of work now, apparently.
That was the end of the first keynote of TSSJS. In the next few posts I’ll talk about some additional sessions that my associate and I attended, and some of the other good stuff we learned.
Homer Simpson’s Guide to Software Development
For some time during my early development career, I would get great satisfaction from coding an intricate and sophisticated solution to a problem. Complicated problems yield complicated solutions, don’t they? That sense of a job well done, looking at a nested recursive, highly optimised algorithm that would fill three pages but get the job done super fast.
Then I’d go home and relax, with the knowledge that I’d really earned my wage that day. I’d kick back, relax and watch my all time favourite show, The Simpsons. The perfect end to a perfect days coding.
Over time, I’ve begun to change my outlook in many ways. One of the most significant ways as far as my software development career is concerned though, is that I have become the Homer Simpson of software development.
This is all a little cryptic, so let me explain. During the multitude of Simpson’s episodes, Homer has spoken several pearls of wisdom. The one I hold dearest to is “If something is hard to do, it’s not worth doing at all”. This is my mantra when coding, as my coworkers will grumpily attest. When writing code, if I start seeing that it is getting complicated, or I try explaining it, and find it hard to verbalise, then the code is wrong. I’ve come to see complexity as a sign that I’ve gone wrong.
Another Homer gem, ‘You tried your best and you failed miserably. The lesson is, never try’. I see this as another statement that if you have to work really hard to code the task you are working on, and you are stuck elbow deep in code with no idea how to get past the current hurdle, then give up! You are almost always going the wrong way.
Software that is hard to write is also hard to understand, maintain, extend etc. I have come to love that eureka moment when I spot the obvious answer to the seemingly hard problem. The simpler the solution, the happier it makes me. This means that I could expect any member of the development team to be able to look at the solution I’ve implemented, quickly understand what it is doing and why, and then be able to add features to it.
So, Homer Simpson, thanks for being a great mentor.
By: Chris Tarttelin
Share on Facebook
Recent Discussions