Properties with non public setters sometimes make sense – until a unit test requires an object to be set up in a specific state. I don’t want to make the setter public just because of the tests, so I wrote a small helper function that can call non public setters.
The helper returns the object itself, to allow a fluent syntax inside member initialization expressions and uses a lambda to select the member (I do like compile time checking whenever it’s possible).
This is actual code I wrote last week using the helper. It’s part of a set up of an object collection used for unit tests.
Orders = new List<order>
OrderId = 983427,
}.CallNonPublicSetter(o => o.StatusId, OrderStatus.Confirmed),
OrderId = 18956,
}.CallNonPublicSetter(o => o.StatusId, OrderStatus.Delivered)
The helper is implemented using reflection to access the property to bypass the protection level of the setter.
Telerik JustCode is a Visual Studio extension that helps with code navigation, error checking, test runs and more. It’s still Visual Studio, but with slight improvements all over that makes the everyday coding easier.
While many coders claim they can’t live without certain productivity or refactoring tools I’ve never been one of those. I’ve never felt any need for productivity tools to Visual Studio, but when Telerik offered me to try JustCode I decided to give it a chance. I installed it and just continued developing as usual, except that there were these new fancy features all over.
Go to File
I quickly got my first favourite command: Go to File.
Ctrl+Alt+G brings up this neat little tool that gives a quick navigation to a specific file. Note that typing in
Employers ask for elite performers, but they should be careful – they could get what they ask for… If they find an elite performer, do they have the elite organization required to match the new hire?
I recently read a great post by Kelly Sommers: Challenge Addiction. I’ve been following Kelly on twitter for some time and I do read her blog posts. To me it is clear that she really is a challenge addict, but not only that: She’s probably one of the smartest programmers on this planet. She should be a dream for any team to hire. Unfortunately I think many teams would quickly find it a nightmare to have her on the team. That’s not because of Kelly – but because of the team.
I’d better make it clear that I’ve never met Kelly and definitely not worked with her. I can’t even say that I know her online, more than what I get from following her on Twitter. Nevertheless her post is what inspired me to write this one. This post is not specifically about her, but rather about what it means to bring a challenge addict on the team.
$(this) in jQuery callbacks? I’ve used them extensively, but never really paid attention to them until after I wrote the posts on what
this is handled in jQuery and how
$(this) is bound to the current element in jQuery event handler callbacks. The findings were not surprising, but rather show that jQuery is a well designed library.
The findings are simple:
this is a reference to the html DOM element that is the source of the event.
$(this) is a jQuery wrapper around that element that enables usage of jQuery methods.
- jQuery calls the callback using
apply() to bind
- Calling jQuery a second time (which is a mistake) on the result of
$(this) returns an new jQuery object based on the same selector as the first one.
Let’s a have a look at how jQuery handles those cases internally.
Keeping track of the backlog in a Scrum project is a challenge. It quickly grows to hundreds of items that are in various state of readiness for inclusion in a sprint. In my current project, we’ve setup a Kanban board to help managing the backlog and make our backlog grooming sessions efficient.
I think that in many ways the product backlog and the product owner role are Scrum’s weak spot. Scrum brings order to the development process and sets clear demand on the specifications input into the development process. That helps to make visible what we developers have known all the time: It isn’t our fault that projects screw up, because we can’t do a good job on bad requirements. So with Scrum having helped to make the requirement problem visible to everyone it’s time to address the requirements handling.
In my current project, there are a number of distinctive steps that a product backlog item goes through.
- A new request from someone is noted as a product backlog item.
- The PO decides to trash it right away, or to go forward with more detailed analysis.
- The PO (or a BA helping the PO) makes an analysis.
- The product backlog items is presented to the developers in a backlog grooming meeting.
- The developers have questions and send the item back for further detailing.
- The developers approve the item and make an estimate of the entire product backlog item.
- Only items approved by the developers are eligible for inclusion in a sprint at the sprint planning meeting.
To keep track of this process we use a Kanban board.