I have heard the car metaphor many times before - you know the one - “are we building a ford, or a ferrari?”. But that metaphor though has never really sat well with me - I couldn’t relate to it, and everyone always says “oh no, we are building a ford” and then proceed to describe the bells and whistles. Lately, I have started to look at other metaphors, and I have found one that is currently working for me.
I love tiny types. I love how they make me feel, how they make me laugh, how easy it is to understand what is going on when they are around. The one annoying aspect, however, is when they have to cross application boundaries. Whenever you need to persist them, or present them onto the screen, in order to get to the value, you usually expose the underlying wrapped primitive. This always feels so icky reaching into them and stealing their values. But, on my current project, we up with some neat ideas as to how to rob our tiny types for their precious.
Ok, so I am doing a little happy dance right now, because I managed to get pagination into our application in less than a day. It is not your traditional pagination: where you specify the page number (and if you are lucky enough, also the page size). I find no real user meaning behind this.
Code Contracts is one of the new features in .Net4.0 which brings a little bit of formal specification to .Net applications. As someone who has a background in formal specifications I thought it might be interesting to see what this new tool offers .Net developers.
I have been getting my speaking voice ready, and now I am getting set to use it. This week, I am speaking about how to integrate with other systems in my talk titled The Three Pronged Approach To Integrating Systems at Scandinavian Developer Conference 2011 in Gothenburg, Sweden. I am also running a conversation corner about feedback. If you want to follow what is going on, the hash tag is #scandev.
Do you like TED? I have been enjoying the TED app on the iPad lately, and I recently saw the TED talk given by Sheryl Sandberg, Facebook’s COO - Why we have too few women leaders.
I have just finished watching Shelly Correl’s talk on How Gender Stereotypes Influence Emerging Career Aspirations, a video filled with really great research to back up what I have been thinking about of late. I don’t want to summarise too much, I would say go and watch it, but for the main highlights…
How often do you get to work on completely isolated systems? It is seemingly more and more common that your system needs to talk to another system to function, whether that be a legacy system, an external API or even one that has not been developed yet. Every system that you talk to adds risk to your project; technical risk, quality risk and delivery risk. But never fear - help is at hand.
In my last post about working with integration points I described how I use anti-corruption layers (wrappers) to hide away any warts of the integration point. In this post, I will explain how I used these wrappers to help develop against an integration point which was also under development.
On my last few projects we had a requirement to integrate our application with another system. Adding to this complexity was the fact that these other systems where also still being developed. I learned a few tricks on the first of these types of projects which really helped the latter projects which I shall share with a wider audience here.
There is something about the phrase Non Functional Requirements that I don’t really like. It’s the Non bit which gets me - I think that word makes them feel unimportant and therefore there is no pressing need to explore how they will affect the system. I have seen on many projects teams procrastinating in defining how the “NFRs” will affect what they are building - usually in the metrics around performance.
The English language is a very complex beast which can easily strike confusion in the most unsuspecting moment. Take, for example, the word “lollies”. Did your mind immediately jump to a bag of gummy bears, redskins, bananas or milk bottles that you get from the garage? Or instead did you start thinking of a frozen dessert on a stick? If you thought the former, then, like me, you probably are Australian. Because the English term for it is sweets, and the American version is candy (although I doubt that they have such wonderful lollies as bananas and milk bottles). And the frozen-dessert-on-a-stick - thats an iceblock for me!
I was going to start this series off talking about filters and the way that connections are made in your brain, but after hearing about the lap dances at the Taiwan Yahoo! Hack Day, I thought I might begin with addressing the issue of low attendance at conferences.
A few weeks ago, I was fortunate enough to attend JAOO, an awesome conference for software developers, architects and PMs, for one day. How did I get to? Well, a few weeks before the conference, the organisers Trifork noticed that while conferences usually have around 5-10% women attend (and that is considered good), JAOO only had about 3.7%. So, the organisers did a really cool thing…they decided that for any full paying pass that you bought, you could bring a person of the opposite sex free for a day! They also added a Women in IT meeting to their user geek night. As a result, they managed to get a whopping 14% women attendance!
There are many template engines that you can choose for the generation of views in your mvc application. The problem with most of the them, however, is that they are too permissive. These turing-complete engines allow for many complex constructs within the template, which begin at simple if statements and for loops, and expand to complex object traversal. While these permissive languages are intended to offer great flexibility, in reality they promote bad practices. Allowing logic to permeate your view is bad for many reasons: firstly, the code in views is rarely tested; secondly, the separation between the models and the view blurs and business logic creeps into the view.
Refactoring a piece of code can be such a thrilling experience when it’s finished, but at the same time can also act as the blackhole of time. Recently, I have been observing how other people refactor, watching their looks of happiness when they finish it and also their despaired faces when they have realized they have spent a week trying to add one new argument to their method.
A few weeks ago, my good buddy Christian Blunden and myself presented at a London Geek Night. For us, it was quite fun and I hope people not only picked something up from it but also had a good time. The presentation was recorded and should be on skills matter so check it out if your interested (she says cringing at watching herself on video).
In Coding Tip no27 I explained how I rarely like to use booleans to represent states, and prefer to use an enum. Now that I have all nice little enums everywhere, another pattern that I see emerge is that I want more from my enum than just a value: perhaps other values associated with it, or actual behaviour. These enums then get converted into fully-fledged objects (ie classes) in the system with a very simple refactor.
I had a very interesting discussion with Jen Smith today about the differences in approach to faking objects during testing. As a result, I am finally putting down my thoughts on the matter.
I have been on a few projects now where we have used ORM libraries to help store our data (eg ActiveRecord for Rails, Hibernate (and it’s variants), Castle’s ActiveRecord for .Net). On these projects, we have used the domain models and the ORM models are the same.
On my recent project, I have noticed a resurgence in a pattern that I have seen many times previously: where a field which is represented as a
booleanneeds to evolve to represent more than just two values (
false). The number of times that I have encounted this makes me believe that you should always start with
enum, regardless if the values are
false, just to make your life easier down the line.
The classic log-in story is often the story that new-to-agile-ist assume you need to develop first. In fact, it is often the last story that should be developed.
Around my neck of the woods, I have been having a theoretical debate with my colleague Dan Bodart as to the best method signature when it comes to collections of data.
After a few days of introspection, I have finally decided to post about my reactions to the now infamous Perform like a p0rn star presentation and it’s aftermath.
YouTube is offering you a great new experience to watch your clips with.
There has been quite a lot of discussion on mailing lists that I am on about what it means to be RESTful. It has occurred to me that the reason for many of these discussions is that people only hear tidbits about REST and therefore draw wrong conclusions about it. Here is my understanding:
Recent psychology research into how a role model impacts careers indicates that women need female role models more than men need male role models. This research highlights the need for female role models in the IT industry in order to positively impact the careers of the few women in it, and also attract more women into the field. One problem however, is that the profile of most women in the industry is very low - after all, when you attend a conference, how many speakers are female?
If there is one thing that I hate about how a lot of Agile projects are run is the notion that you need to sign up to deliver certain stories/ a certain number of story points for an iteration. I find this to be detrimental on so many counts.
Pair programming may feel quite strange and frustrating to those new to it. (I guess it can feel strange and frustrating to those who have been doing for a while). I gave a brown bag session to a group who were just starting to embrace pairing to try and help them overcome some of their frustrations. Here are my notes from the session.
I have been reading Malcom Gladwell’s Outliers, and in it he discusses the events which lead to plane crashes. Gladwell explores the plane crashes of Korean Airlines to demonstrate that cultural legacy is important to understand success factors. One interesting point he explores is the communication required in the cockpit between the captain and the co-pilot.
Stand-up meetings are a healthy part of the daily routine. They are a useful forum to keep everyone up to date with the happenings of the team, escalate any blockers that may have arisen and set direction and focus for the days activities.
that an agile team in possession of good practices, must be in want of a better way of doing things.
I am not a huge fan of the iteration-based retrospectives that people usually run. These are the retrospectives in the format where you write about
I have just finished watching the special features of Surf’s Up on the DVD and I was struck with a thought that software development is somewhat similar to making a movie, and if you allow me to draw the parallels, you can see that Surf’s Up was created in a very Agile way.
The question a lot of people (especially software architects) ask when adopting TDD is how does Architecture fit in the whole Test Driven Design paradigm.
This is part of a conversation I had this week with my pair (in the conversation, I am A and he is B) as we were working on a new story. He, like many others, has been trying to do TDD but it wasn’t until we had this conversation that he began to understand what I was talking about in my last post - that Test First does not drive out good design, but Test Driven Development can.
I have been helping my current client introduce TDD, and in doing so explaining principles such as single-responsibility, encapsulation and intention revealing names. As I said in my previous post Test first does not magically improve the code base, but you need to concentrate on writing good tests to help you drive out good design. This is my list of what I think characterises a good test (although I don’t think its definitive - I am sure I have missed some things out).
Those starting out on their XP or Agile journey often hear supposedly enlightening phrases touted by those in the know like “TDD will lead you to better, nicely encapsulated, decoupled code” which leaves them scratching their heads. They are scratching their heads because they understand the benefits of adopting these practices, but they can’t see how to actually apply them in their situation.
If you haven’t heard of Australia’s plans to censor the internet, let me be the first to inform you. The current government has a plan “to force all Australian ISPs to implement server-based filtering systems to block access to ‘child pornography’, ‘X-rated material’, ‘violence’, ‘prohibited’ material, ‘inappropriate’ material and ‘unwanted’ material on a secret blacklist compiled by a government agency”.
I like celebrating on successes, whether it is making a test pass, finishing a task on a story or finishing the story itself. I also love celebrating what we have achieved in an iteration. If we complete 15 story points in one iteration - Great :). If we completed 20 points in the last iteration, well it was still great - we added 15 points worth of value to the application.
Someone shared an observation with me today regarding the way ThoughtWorkers talk when referring to classes. Apparently, we say “this guy” a lot; as in “this guy has the responsibility for that action”.
An annoying part of writing a test is the amount of setup an object can need in order to use it within the test.
There is no denying that finding a women working in the field of information technology is a rare occurrence. At my current client, I have only seen 1 women in a sea of male developers; it was a similar story at my previous client. Luckily for me and my kind, ThoughtWorks wants to change this.
At the conclusion of a lot of projects, we conduct retrospectives in order to gain a deeper understanding of the success factors of the project, discuss what could be improved and how to incorporate these into future projects.
I like recursive algorithms, and I like trees (I mean the data structure, not the perennial wooden plant - of course I like them too). So today, I was very glad when I had the chance to implement one on my current project.
At the moment, it seems quite vogue to say your company is Agile. But what does it really mean?
The comments on my last post about acceptance tests have made me think a little more about testing, particularly the value in specifically declaring the type of testing you are doing.
I came across an article the other day about ten easy ways to attract women to free software projects. I am not quite sure what to make of it. All the suggestions seem to me to be very obvious. Is this because I am in the demographic they are trying to target, or is it because I work in an agile environment, where processes are continually improved?
There - I said it. Heresy. But, I am yet to be sold on their value.
I am often asked how to pronounce my surname. It’s not too difficult, but for your benefit, I will now attempt at a phonetic guide to my last name.
I love ReSharper. It makes life in Visual Studio such a breeze. You are just so productive in it, with all of its navigation tools, code completion and automatic refactorings. I tried to use Visual Studio without ReSharper the other day - it was so impeded that I swapped computers after about 5 minutes work (mind you - when I swapped, I redid the work in about 30sec).
Often, I see tests like the following:
Around ThoughtWorks, there is much discussion about test strategies. The arguments range from setup vs inline; named vs anonymous; mocks vs stubs; high level vs unit level, and everyone has their own preferred techniques. While a lot of people talk about the virtues of either side, I wanted to talk about using test names wisely.
There are 3 very handy list functions which make dealing with lists a breeze:
Reduce. I have come to the belief that not everyone understands their power, so I will attempt to explain it.
Lately, I have had the opportunity to add some pretty funky usability behaviour on websites thanks to JQuery and some UI Plugins.
When designing your code, it is important to model the business domain. However, how do you know you have modelled the right domain? Sometimes you need to look beyond the domain objects, and see what you are actually implementing.
subscribe via RSS