You can now install the Ruby Language and the Rails framework on your Windows PC (XP, Vista, 7) using the Rails Windows Installer from Wayne E Seguin
Probably the best metaphor I’ve seen to compare to what you’re actually doing as a software developer/programmer/code-monkey (I can go on, but I won’t).
I read a rant article the other day (I will update the link here as soon as I find it again) where the author was absolutely shooting down the use of the IN statement in queries, and proposing you rather use a JOIN and then compare fields in the WHERE clause.
I've been playing with some of the new features in C#, one of which being the var keyword. Which is not dynamic typing, it is just type inference. Meaning that the compiler will be assigning the type based on the value that you initialise the variable with when declaring it. And you have to initialise it with an actual value when using var.
After playing a bit, I discovered this little problem, which is probably just an incorrect assumption from my side, but I'm sure I'm not the only one that will make this assumption. If you look at this code sample.
I’ve found two views out there about writing good excellent code, that I absolutely have to agree with.
One is on CodingHorror, by Jeff Atwood, saying that writing code is just like writing, ultimately your co-software developers have to understand what your meaning was, and if they cannot figure it out, you’re doing it wrong.
In Jeff’s post there is reference to this post by Ned Batchelder, which basically gives you THE rule about removing dead code, which I have to admit, I’ve been breaking a big percentage of the time. From now on, in my quest for personal improvement, I will definitely be following both these guidelines.
What are your thoughts on writing good code?
In SSIS there are are two different types of script components. The Control Flow script, and the Data Flow script. These 2 use different ways of accessing package variables, which was a bit confusing the first time I used teh Data Flow script component.
In the Control Flow script component you access package variables in a similar way to how DTS used to do it.
However, trying this in the DataFlow script component only cause some compilation errors and nothing more.
After doing some searching, I eventually found the simple solution that was staring me in the face all along, I just never tried it.
In both cases you still have to tell the component which variables you're passing in on the property page.
Our office building's elevators recently went through an "upgrade" process. All the elevator mechanisms were replaced, and then they replaced the management system.
The new management system decides which elevator you'll be using when you push the button. It has a nice big arrow above the lift door that lights up while you're waiting, and then starts flashing when the elevator arrives, so the moment you push the button you know which elevator to go stand in front of. Only sometimes the system realises that the particular elevator is in use between other floors, and then switches to another.
At ground floor level they've installed a set of buttons for each floor in the building, and the system then lets you know which elevator will stop on your floor. The problem here is that most people don't even bother looking, and just storm into the first elevator that arrives. You just have to wait for the first stop before you can push your floor button again to make the elevator stop there.
I have no idea how the system calculates which elevator to use, but what I do know is that the average wait time has gone from 30 seconds to about 3 minutes. Surely the developers of the management system should have tested and timed the new system in a real building, preferably their own. Why try to predict which elevator to use if you can just stop the first one that comes past going in the right direction.
The insides of the new elevators look very nice, but they're still just as shaky as what they used to be. The only improvement I can really see here is that you can now switch off buttons that were pressed by mistake.
What I'm getting to here, is that, hopefully, when you get a brilliant idea for your system as the developer, you actually do some homework on the usability of the feature before implementing the changes into your production environment. I've seen many users hampered by a design decision a developer took, because it would be cool to design, instead of thinking what would benefit the users.
This parody/article just about sums up every project request I've ever received. I think I can use it as a generic project charter from now on.
Jeffrey Palermo wrote an excellent three part piece on how to speed up development. Well worth the read.