Blogging. Again.
I like The Ten Commandments of Blogging, mostly because it has a few bits in it that push for a style of writing that I want to adopt in yet another blogging incursion: one that lies between tweets and articles.
And, yes, sod all the “build a niche audience” crap. Blogging is about self-expression, not about writing for an audience or driving traffic.
I also realise I only just “got” Dave Winer.
Serendipitous twitter
Besides keeping me current via @bbcnews, Twitter is becoming my main source of serendipitous web surfing.
Some of this week’s finds:
- The scale of the American $15 trillion debt
- You are not the web designer. I am the web designer.
- The most awkward 404 Not Found page on the Internet
And, my own contribution:
In transit
I haven’t posted anything since January. Anyway, I’m still alive. But, not kicking, though, as I’d need lots of energy for that. Which I don’t have, because I’ve been on a death march these past few weeks.
Anyway, I’m off to new software development adventures. More to come later.
And, Happy Easter, too!
The K.I.S.S gear
BECAUSE sometimes I want to be in the picture even if there is nobody apart from me who can operate a camera.
Because it runs on normal AA batteries and fits in my jeans pocket.
Also, because the asking price was just £5.
My "new" Fujifilm FinePix A370.
Eddy.
Whine of the week
CAN YOU tell I had a bad week at work?
Hi all,
Having spent most of the last three days doing releases and having to work around issues that shouldn’t happen, I think I’ve earned the right to some moaning.
Here goes, with some rules of thumb that should make all our lives easier.
#0 – Put your changes in source control
If they are not in VSS or TFS and are confined to your machine, they are not completed to anyone but you, regardless of how hard you’ve worked on them. It’s that simple.
#1 – Commit code that works.
Code that is checked in should have been tested and should work. “Tested” means merged with what was already under source control, compiled, and tested.
This involves getting the latest code, merging, compiling, testing, THEN checking in your changes. Manual merge is preferred to automated resolution when conflicts are found. This means, looking at the lines of code that are conflicting, finding out why the conflicts exist (were the lines changed because of some other requirement that was implemented by another developer?) Do not assume that the code coming from the server can be replaced.
#2 – Commit code that works (again)
This goes for stored-procedures and database scripts too.
Don’t be tempted to change scripts directly on the database. It takes time either way, so instead of typing a script directly in SQL Management Studio, check out the corresponding file from source control, make your changes, copy the content to SMS, run the script, and test the changes. If the script fails your tests, go back to the file and make more changes there. Rinse and repeat. Once the script passes the test, check it back in source control if it can go in on its own.
IF THE SCRIPT IS A DEPENDENCY to some code, check them in together. This is to prevent the situation where code comes to rely on database scripts that are not available yet. If the code and script are under different source control databases, for either one add a check-in comment referencing the changeset of the other; that will ease resolution of problems when they arise.
#3 – Do not check in commented code
Code comments are fine, commented code isn’t. Commented code is old and not needed, get rid of it.
If we need the history of a file, we can turn to the source control database.
#4 – Some mistakes are not mistakes
Sometimes it is blatantly obvious that something has not been tested. A typo on a keyword, for example, says a lot about how much, if at all, something has been tested.
#5 – Don’t take shortcuts
Well, sometimes shortcuts are necessary and OK when you know where you’re heading, but always strive to use the full duration that you have estimated for a piece of work. Use time left over for some extra testing or improving the code. If your work overruns, ask for extension with a valid reason, even if just to say that you did not appreciate how much effort was required. When shortcuts work, everyone is happy, but when they fail, you get blamed for them. And NEVER BASE ESTIMATES ON SHORTCUTS
That’s it, folks. Rant over.
Eddy.
« Newer — Older »
Powered by WordPress and Eddy Young.

