/// <summary>
/// Gets the constant value.
/// </summary>
/// <param name="exp">The exp.</param>
/// <returns></returns>
public static object GetConstantValue(this Expression exp){
...
}
I found this code in an open source project. It kinda looks like a joke, but it’s not.
Sometimes you can identify bad code without reading it at all. If you have big arrows forming in your code you should reconsider your solution. It usually indicates a high cyclomatic complexity (i.e unredable code). Can you see the arrow ?
I was just skimming thru the ASP.NET MVC code and found this little nasty guy.
You should never widen your interface to enable unit testing. Doing so is a code smell, and there is (almost) always a better way.
[SuppressMessage(
"Microsoft.Usage",
"CA2227:CollectionPropertiesShouldBeReadOnly",
Justification = "Property is settable so that the dictionary can be provided for unit testing purposes.")]
protected internal ModelBinderDictionary Binders {
get {
if (_binders == null) {
_binders = ModelBinders.Binders;
}
return _binders;
}
set {
_binders = value;
}
}
I do quite a lot of javascript and C# programming. Linq is one of the greatest things in C# and I was missing it in javascript, so I figured I could just implement what I needed. It took about one minute. Here is how I could improve some of my code:
var a =[];
for (var i = 0; i < elements.length; i++) {
a[a.length] = {
name: elements[i].name,
id: elements[i].id
}
};
return a;
becomes
return elements.select(function(item) {
return {
Name: item.Name,
Id: item.Id
};
});
and
var res = [];
for (var i = 0; i < ids.length; i++) {
for (var j = 0; j < this._currentList.length; j++) {
if (ids[i] == this._currentList[j].Id)
res[res.length] = this._currentList[j];
}
}
return res;
becomes
return this._currentList.where(function(item) {
return ids.contains(item.Id);
});
The actual implementation I call Blinq (e.g.) Bjarte Linq :p
if (Array.prototype.where != undefined)
throw new Error("Duplicatte method definition on Array");
Array.prototype.where = function(match) {
var a = [];
for (var i = 0; i < this.length; i++) {
if (match(this[i])) {
a[a.length] = this[i];
}
}
return a;
}
if (Array.prototype.select != undefined)
throw new Error("Duplicatte method definition on Array");
Array.prototype.select = function(selection) {
var a = [];
for (var i = 0; i < this.length; i++) {
a[a.length] = selection(this[i]);
}
return a;
}
if (Array.prototype.contains != undefined)
throw new Error("Duplicatte method definition on Array");
Array.prototype.contains = function(obj) {
var len = this.length;
for (var i = 0; i < len; i++) {
if (this[i] === obj) { return true; }
}
return false;
};
Not alot of code really.
Nitpickers corner: LINQ-like implementations of Javascript already exists, but when it takes me a minute to implement I don’t go about learning a new framework to get the job done :)
This one goes out to all you who are spending valuable time to figure out where the heck you can find these methods:
ActionLink and BuildUrlFromExpression you can find in the MVC Futures:
<%@ Import Namespace="Microsoft.Web.Mvc"%> <% =Html.ActionLink<HomeController>(x => x.Index(),"Go home") %> <% =Html.BuildUrlFromExpression<HomeController>(x=>x.Index())%>
Strongly typed RedirectToAction you can find in MvcContrib
using MvcContrib; return this.RedirectToAction(x=>x.Index());
You can also read Phil Haacks uber lame exuse for not putting this inside MVC at the end of this post
I am very impressed with the user interfaces Apple has on it’s products like iPod and the iPhone. Apple really do set the standard. Apple does have some really crappy software as well. The one that constantly annoys me is iTunes. But that’s not a problem Apple. I can forgive you for one mistake. However, what I got this morning when I tried to update my iTunes didn’t please me at all. As we all know when we get an software update we just press next, next and then we’re OK. Apple has realized this as well and is deliberately trying to push some software to you that you DO NOT WANT. This is not acceptable.
The problem is easy to fix. They could just have left the check-boxes unchecked.
Obviously I’m not new to this behaviour. A lot of non-user friendly companies does exactly the same thing. But Apple? Come on. You are supposed to be the usability guys.
The way to create great software is to think about the user experience from the users perspective. Nobody wants an extra browser or a mobile-something application installed when they are just updating their software.
Hopefully you, my readers, don’t do this kind of crap to your customers. Or do you ?
Later.
We (the team) just had a chat about some ideas we should follow when it comes to source control and code ownership. Here is a short summary.
”Shared code ownership: ” To ensure that more than one person is familiar with a certain part of the code base we have shared code ownership. This will make the team more flexible, and making change easier. It is always allowed to refactor code to make it better. It is actually required to prevent the code base from deteriorating over time. That said, there might be people who knows more about the code base than you do. Also, somebody else might be working with the code right now. ”Consult before making radical change.” Communication is always important.
”Check in early, check in often: ” The code is what is in source control, not what is on your computer. By keeping the code in isolation on your computer you are setting yourself (and the team) up for big trouble. By updating(first) and checking in (second) often, you prevent merging and communication problems. Partition your current work into sub problems, and check in when each feature is created or updated. Work on one problem at a time. If you find yourself working on 10 features, where each one is impossible to check in, you are doing it wrong. It’s a code management anti-pattern. The philosophy behind this is simple. Problems are easier to fix right after they occur. In a day, or a week, solving the problem becomes exponentially harder. Considering this philosophy, keeping the code on your machine to avoid problems MAKES NO SENSE !
”If the code isn’t checked into source control, it doesn’t exist”
Write tests for the expected behaviour and your usage of the code. This will ensure that new features and refactoring is compatible with existing usage.
“Standard” is what we do right now (or should do). The standard can be changed as we find better ways to solve our problems. However, we should all follow the current standard.
The other day when I was up in the mountains in my cabin, I suddenly started thinking about development processes and rapid feedback loops. I sat down to write about it, and here is the result:
There is a saying “culture eats strategy for breakfast”. It’s true. I have seen it in action.
Introducing a new process often requires changing the culture in the company. This is hard or impossible. Radical change creates too much friction. Working with the existing process and modifying it slowly is the most feasible route. Identify your goals and see how you can slowly modify your existing process to achieve the goals.
Let assume that building software faster and with better quality is a good idea in your context. It usually is. Let’s say this is our goal, assuming that it in the end will lead to more profitability.
I firmly believe that to create maintainable software there is one term that is more powerful than all others. That term is rapid feedback loops (RFL). Rapid feedback loops is the common denominator of all agile processes. The only process I know of where RFL is not a central concept, is the waterfall model. It is not the details of the agile processes that make them succeed. It is the fact that they all embrace rapid feedback.
Test driven development tells us every minute if our code works. Continuous integration tells if our code is working in the bigger picture. Integration tests checks whether we are fulfilling the product requirements. Periodical demonstrations and conversations with our customers tell us if we are building the right product. It’s all about getting feedback. If you are writing bad code, or creating the wrong features, feedback nudges you back on the right track. Design reviews can prevent architectural erosion. You need feedback as soon as possible so that you don’t waste time working on the wrong thing. Working on the wrong thing is expensive.
Feedback is a good thing if the feedback you are getting is correct. If it’s not you have a problem. We can usually trust well written unit tests. Integration tests are harder, because they are only correct if they are actually testing a feature we need in the end product. We need to constantly check with our customer that we are on the right track. The customer might be wrong, so we re-check on a continuous basis.
If you want to improve your current process you should start looking at your feedback loops. Slowly introduce feedback on all levels. You don’t need to pick Scrum, XP, RUP, Lean, Kanban, Crystal Clear or ScrumBut. However, you should know roughly what they are about. This way you can pick from a toolbox of practices and make them fit into your existing culture.
I don’t believe in picking an out of the box process if it will crash with your current company culture. However I really do believe in feedback loops and you should introduce them slowly into your current process. There is obliviously more to creating a smooth software machine, but feedback is a key concept.
Peace.
Here is my ITunes export of podcasts I listen to. Most are software or “software business” related. I hope it’s helpful. Have I missed some crucial ones ? Tell me on twitter or in the comments :)
BTW, I just removed the StackOverflow podcast from the list. It was taking “brain dead” to another level :)
I just finished the book Crush It! by Gary Vaynerchuck. It’s about how you can make a living using social media and doing what you love to do. In the book he summarizes my own philosphy in a couple sentences
Can’t argue with that…
I give it a 4 out of 6. If I had finished it a year ago I might have given it a 5 or 6. It all depends on what kind of books, blogs and shows you have devoured before you read it. To me it wasn’t a lot of mind blowing stuff in there. Still, it’s worth reading due to the passion Gary brings to the subject. Get the audio book, and you will see what I mean :)