Thu, 02 Jul 2009 11:39:44 GMT
How does backward compatibility work in windows 7?
I'm glad you asked.
You don't got to be a Hanselman to know all this.
Here's a pictographicatorial guide to compatibility checking in the windows 7.
* In point of fact, it's a virtual Raymond Chen (a VRC), but the MS guys are so freakin good at virtualization now that You Will Never Ever Ever EVER Be Able To Detect The Difference. Even Mrs Chen is rarely sure. And only when that fails do they invoke the real Ray Chen.
So take it from me, a world expert on the computing technologies, that this new version of windows will be just about the best thing since Vista.
Read On...
Sat, 13 Jun 2009 12:17:23 GMT
I see this sign on the noticeboard in the staff kitchen every day, and thought I ought to share the wry little WTF it invokes, every last time.
sorry i redacted it slightly; i think the guilty deserve some protection too; they're just hard working kids in the end)
Read On...
Fri, 12 Jun 2009 13:06:58 GMT
3 Questions...
in cartoon form too!
|
I really love this timeless Tom Van Vleck article from 1989.
It teaches us to ask ourselves:
Those questions being:
- Is this mistake somewhere else also?
- What next bug is hidden behind this one?
- What should I do to prevent bugs like this?
When I first read these rules, I was foolish enough to think:
'Cute, But Too Obvious! i do this intuitively all the time.'
But watch yourself closely! I've caught myself out on occasion, and maybe you will too.
I'm making an effort to be more explicit about the three questions. Maybe i'll end up fixing related problems at first hint more often than i do now.
Read On...
Sun, 07 Jun 2009 08:26:42 GMT
Vilfredo Pareto:
don't got time to shave.
|
I keep hearing rather a bit too much about this Pareto Principle.
Apparently, with just 20% effort, correctly applied, I can achieve 80% of the desired effect. Marvellous stuff!
I was about to go ahead and do this when it occurred to me:
"Why waste all that time, doing a whole 20%?
"If I only did 20% of that 20%, then surely I could achieve 80% of the 80%?"
Then with a little more head scratching, and the help of an excel spreadsheet, I determined that with just 0.8% of the effort I could achieve 51.2% of the result -- which is a PASS in anyone's books.
So from now on, you will excuse me while I spend 99.2% of my time:
Lounging around, drunk, in a pool bar and
Determining exactly which 0.8% of the effort to apply myself to.
Unless, of course, it takes 80% of the effort to work out exactly which 20% will achieve the desired effect. And it takes...
Read On...
Fri, 05 Jun 2009 10:24:14 GMT
A couple of weeks ago I put out a twitter post I've been meaning to come back and explain:
"the habits of a good programmer are not simply orthogonal to good communication -- frequently they're in direct opposition."
http://twitter.com/secretGeek/status/1870937085
This is a pretty startling and upsetting result: I'd like to think that the heart of good programming is crisp and direct communication. That all of my efforts to be better at programming will, somehow, make me a better all-round person. If only it were true.
Here's a bunch of ways that good programming practices are directly opposed to good communication practices.
In bullet form:
- D.R.Y. Does Not Apply.
- Humans don't mean what they say.
- Compilers don't need to see an example.
- Programs love definitions; Humans get flummoxed.
And in detail:
1. D.R.Y. Does Not Apply
The golden rule of programming is D.R.Y. -- don't repeat yourself. This is the heart of effective programming. But this is the opposite of effective communication.
Let me say that again:
The golden rule of programming, DRY, is the opposite of effective communication. ;-)
Say everything once and only once -- go ahead -- then be amazed as everyone misses your point!
Humans are not machines. Memories made of this gooey, spongy stuff called a brain are nothing like memories made of silicon.
With Humans, nothing sinks in the first time. And furthermore, you may be surprised to hear that NOTHING sinks in the first time.
"Human, All Too Human"
Nietzsche preferred the
company of a good compiler
over that of a human.
"Compilers never make fun
of one's moustache,"
--Ibid., pg 293.
|
2. Humans don't mean what they say.
Compilers are of course perfectly literal. They don't care at all what you mean, they are always hung up on precisely what you say.
Even if you didn't start off life as an anal-retentive git, you'll slowly gain the requisite faculties over years of trying to please a compiler.
The art of trying to please a compiler consists of the ability to logically, dispassionately, analyse what you've said, to discover and remove any mistake or ambiguity -- to always produce an output that is perfectly comprehensible to the strictest of master.
Try being like that around real people. Just try it.
People are barely literal at all. If you take them literally when their meaning differs from their words -- they will get quite irate with you. They won't see that the mistake is theirs.
When the words they use differ from their intent, you may feel an overwhelming desire to 'correct' their mistake. You may even think you are doing them a favour.
This is a natural feeling, amongst programmers, who would be happily spared the torture of spending time trying to remove all ambiguity from the words they provide to a parser.
But please (please) hold back. You might score a small point in the 'intelligence' column for pointing out their 'mistake'. But you'll also score about a bajillion points in the 'what a freaking dork' column.
3. Programs don't need to see an example.
Explain a function to a compiler, and it will be able to calculate the answer.
Explain a function to a human... and then give them an example, and draw them a picture, and give two counter examples, and draw another picture, plus provide an interpretive dance on the topic of functions -- and maybe, just maybe, if you've danced very nicely, they will begin to see "what you're trying to say."
"What I'm trying to say?" I'm saying it damn clear! I'm saying it directly, concisely and with perfectly constructed phrases! I'm not trying to say anything! I'm succeeding, you're just not listening, you freaking imbecile!
And don't take that tone with me. With humans I mean. There's no point yelling. Their rational mind shuts down, their sympathetic nervous system takes over. They get ready to fight or flee. Your point is lost when you get them angry.
Computers don't mind if you type angry. Humans think the anger is more important than the words themselves.
When you have the customer in a headlock, knocking their face against the ground with every syllable: the syllables themselves are no longer of tremendous consequence.
True: that bit about beating up the customer may not be a typical trait amongst great programmers. Perhaps I included it just for entertainment purposes. Continuing...
4. Programs love definitions; Humans get flummoxed.
In programming we define new terms all day long. We define class names or function names or variable names.
We immediately attach a specific definition to them -- and then we use that definition throughout our code.
I imagine that some part of the brain is associated with the ability to define a new term and then hold onto its definition. That part of the brain would be monstrous in programmers. Very over-developed. Gigantic -- a tiger amongst kittens.
But define a new term in front of an audience of non-programmers: watch as the eyes glaze over. Heads slump forward. They start planning their weekend.
Let's call this our Neologismic Synaptic Aptitude, or NSA. Actually: let's not call it our NSA, because if we do, then programmers will start bandying the terminology around like it's something we've known about all their life. And the normal people will just look at us with that 'freak' expression, and we'll be even further from ever making it into the boardroom.
I think this aptitude for new terms is what makes TLA's so abundant in the IT world. I do hope you realise it scares everyone else.
So please, I implore you...
Stop defining new terms. Stop expecting non-programmers to understand the specific and concrete definitions you attach to funny little abbreviations.
Stop striving for brevity and conciseness.
Stop correcting other people.
Stop expecting people to understand you first time around.
Start giving examples -- real examples, earthy examples.
Let people be people -- let them be vague and a little incorrect -- listen more for the gist of what they're saying than the exact terminology.
Be a compassionate speaker, a compassionate listener. Embrace the 'all too human' aspects of the strange bipeds you interact with.
Then drop me an email and please, for the love of god, tell me how you managed it.
Read On...
Fri, 05 Jun 2009 08:11:53 GMT
I feel sorry for the programmer who was forced, no doubt after endless emails, meetings, focus-groups and think-tanks to check this obscure non-warning warning message into the Windows source tree...
"The amount of physical memory in your system has increased. This typically does NOT indicate a hardware failure. Contact your Help Desk if you did not personally change your system's physical memory configuration."
Why didn't they say "Congratulations!" or "Good news" or "Ahhhh! thanks for feeding me those yummy ram chips!" or best of all:
"Well, how about that! The tight bastards in IT must've approved that RAM upgrade request we noticed you writing in MS-Word, all those months ago.
"Now let's see if we can get the cowards to consider upgrading the browser to IE 7."
Read On...
Fri, 22 May 2009 12:29:33 GMT
There is a hidden network of bloggers (all around you), a kind of secret brotherhood...
These are the 'ghost bloggers'.
'Ghost-blogging' is the practice of sharing true stories about your own working life, true stories too cutting, too poignant and too true to share on your own blog.
The following is an example of a ghost blog entry, sent to me by someone I know, appalled at some of the Kafkaesque behaviour they've been subjected to inside the kind of enterprise everyone should find familiar.
(I've ghost-blogged my own personal stories on other blogs, at times...)
Here goes...
Version Control,
Requirements Tracking
and Deployments
|
In the enterprise, nothing is what it seems
In the enterprise when they say: "don't worry about that, another team will do that for us" what they mean is: "you just took on a dependency that you have no control over".
In the enterprise when they say "we want you to re-use this standard asset" what they mean is "we want you to hold on to this gold-plated, diamond encrusted anchor while we throw you over the side".
In the enterprise, the group allegedly responsible for 'provisioning developer desktops' will, in actual fact, be the group who expends every effort imaginable to stop developers from being able to actually install developer tools onto their desktops.
In the enterprise when there are three separate groups, allegedly responsible for version control, requirements tracking and deployments, you'll find in practice the requirements are documented through excel spreadsheets over email, the source code won't build, and the deployments take everyone by surprise, including the deployment team.
In the enterprise when they talk about 'strategic direction', they mean 'strategy tax'.
In the enterprise when they ask you to "simply call a web service", what they mean is, "use ftp to push a fixed-width file onto a queue that feeds the mainframe which routes another file to a web service that calls you back on a random port". With a completely straight face.
Read On...
Wed, 13 May 2009 11:23:25 GMT
Follow this simple three step guide to become a proud member of the awesome club of people who loudly proclaim:
"I too am cool! I too have an iphone!"
Go to the settings area of the mail client you use on your regular PC
Change your email signature to read 'Sent from my iPhone'
Send short, pointless emails to everyone you know
Okay, you won't technically have an iPhone. But for the most part, other iPhone users will *want* to believe that you have joined their "team" -- hence, they will be convinced.
And -- as a final twist -- once you're thought to be a member of their team, you'll find that acquiring an actual free iPhone will be easy. Other iPhone owners will be more than happy to let you borrow one of their iPhones next time you see them, if you claim to have momentarily misplaced yours, for example in the pocket of "your other white leather trousers".
--lb
Sent from my iPhone
Read On...
Fri, 08 May 2009 08:44:49 GMT
Well, It turns out that the 80's geek classic, 'War Games' has inspired a sequel, the film
'War Games: the dead code' was released in 2008. Though, perhaps the correct term is 'foisted.'
WG: TDC is such a deliberately bad film that you can only begin to enjoy it once you grok that it's a comedic satire.
For the first hour and a half I assumed it was trying to be a cool, teenage-targetted tech-savvy thriller, like the original. This had me wincing in agony at every bad line and predictable twist. Only then did I realize it was all a joke: a parody of the teenage-targetted tech-savvy thriller. A kind of 'scary-movie' style satire of the entire genre. Hopefully?
Well, I've just finished watching it and it's inspired me to share a few helpful tips for up and coming programmers.
As one of today's young parents, I can tell you what concerns us. Not swine flu, or global economic disasters and so forth. What really keeps us terrified at night is a desperate hope that we, as parents, take all of the right steps to ensure that our sons and daughters grow up to be thoughtful, well-meaning, much loved people. In short: How Can We Be Certain Our Children Will Become Programmers.
And a lot of hard work (err, blog posts) have gone into that endeavour, but as usual I like to look beyond the obvious problem, and into the deeper realms or possibility:
If you're child does (thank god!) grow up to be a Programmer -- what simple lessons can you provide to ensure they don't inadvertently destroy the planet?
Programming is a powerful profession, and as you well know, global apocalypse is but a keystroke away. We want to give our kids the right tips to ward off such misadventures -- to learn from our wisdom, as it were.
Fortunately, like all global catastrophes, this one can be averted with another 3 minute guide from secretGeek.
Please, sit back, breath a deep sigh of relief for the salvation of your measly planet, and drink deep of this crucial lesson to imprint upon your younglings:
10 Simple Rules To Follow Incase Your Software Becomes Self-Aware
(I have included links to information about Government-Approved documentary films on each of these points. I only pray you heed my warnings and enforce these lessons before we are all routinely destroyed.)
- Teach your software that war is futile.
If, after pre-supposing a minimal competency level in your opponent, a game's inevitable state upon termination is mutually-assured destruction, then the only winning move is not to play.
[reference]
- Prepare a virus that can be used to remotely shut down the program from any terminal in the world.
My personal contiuous integration suite won't let me commit any code until I can demonstrate 100% code-coverage with remote-shutdown killer viruses.
[reference]
- Don't discuss switching off the computer if you are, in fact, being observed by the computer.
This is s.o.p. (...that's standard operating practice, if you're not a super-spy type like me, who knows all the jargon). Never discuss shutting down your software until you have found a locked, sound-proof chamber, where the computer system cannot hear your discussion. Also, in case there is a remote possibility that your software has learnt to read lips, let me suggest you cover your mouth.
Simple, every day precautions.
[side note: a parody of this famous Kubrick scene was included in 'the dead code'. nice.]
[reference]
- Ensure that when faced with a tricky question, your software will either breakdown completely, or devote all of its resources for a long time.
Grandiose, open-ended philosophical questions tend to have a compute time in the order of millions of years.
Similarly, when given a dilemma (e.g. "This sentence contains a lie") a self-aware program will tend to explode spectacularly. A competent programmer will keep a few of these handy.
[reference 1]
[reference 2]
- In case of emergency, have time machine handy.
You may need to send someone back in time to protect the mother of the person who leads the rebellion against the self-aware software in the future.
[reference]
- Don't make your self-aware machine indistinguishable from a human.
Maybe you're not very creative, and don't have the time to give your machine a stunningly inventive new exterior. So you fall into the tired old pattern of mimicking the human body.
That way, badness lies.
[reference]
- Should your software become self-aware, don't let it near your girl.
Fairly self-evident that one.
[reference 1]
[reference 2]
- If applying temporary appendages to a self-aware robot, be considerate of your legislation governing public safety.
Scissors for example, are not recommended, even if they are 'just for now'.
[reference]
- Be safety conscious.
Switch off all electrical equipment during thunder storms.
[reference]
- Use a rules engine.
Hardwire 3 clear and unambiguous rules into the program's positronic brain that will ensure all humans are safe from harm.
[reference]
Hopefully, if you follow my advice, we can avoid any more major disasters. But please: always be nice to your inventions. Hopefully then, should the unthinkable happen, your self-aware creations will take pity on us and keep us barely alive in liquid chambers so they can gorge on our brains.[reference]
Oh, and if you don't believe in self-aware robots... (cough cough) here's some i prepared earlier.
See also (important information in similar vein)
Read On...
Sun, 19 Apr 2009 11:21:32 GMT
Example: two toolbar buttons
titled 'Lower' and 'Upper'.
|
Right click the toolbar to edit a button
(or add a new one)
|
The button hosts a python macro that does whatever you want. (The current
document's main textbox is exposed as txt.)
|
Add more buttons, edit the menus...
everything's extenisble... everything.
|
I've open-sourced a side project of mine, MetaNote.
Here's the gist of it...
MetaNote is a text editor. Ultimately, MetaNote intends to be the most versatile editor imaginable.
See that button in the toolbar? Right click on it, and edit the code behind it.
Don't like the way 'Find' works? -- right click on it, and edit the code.
Need a new button in the toolbar? So add it already, with a single click.
Share packs of extensions and macros with other users.
Everything in MetaNote is under your control, effortlessly, at runtime.
It's easier to show than to describe -- maybe the pictures on the right give you the idea.
The source code is available to browse or download. This is very much pre-alpha. It is explorative and non-commercial.
binaries are also available to download.
The project is written in C#, and I need your help getting it done.
I've got many of the basics done, but I'm only at the tip of what's needed.
I'm looking for clever kids like you, willing to help out.
What do you think? Can you take a look at the code, and lend your fellow programmer a few minutes of your time?
I'm not doing it for any commercial gain, i just want a text editor that I can bend to the whims of whatever writing task I come across.
There's a great many features still in need of implementing, and already there are wrong turns to be corrected.
Down the track I really want to find some way to embed the WPF-based Text Editor Control from VS2010. It's the same one used in intellipad (part of Oslo) and in Powershell 2.0's (awesome) Integrated Scripting Environment -- I didn't have any success bringing it to life just yet. So, for now the text is plain text, and features like syntax highlighting and intellisense will have to wait.
One of my mentors tells me the smart approach would be to bring in MEF for giving a really powerful plugin model, where plugins can have plugins and so on.
The intermediate goal though, is just to make the tool sweet enough that I'd use it for my own day to day text editing needs.
And one day, hopefully one day soon, this thing won't suck at all.
Read On...
Sat, 18 Apr 2009 10:21:54 GMT
Couple of days ago I wrote a C# function for a colleague and emailed it to him.
This is the function:
private static string EscapeCsv(string value)
{
//Double all quote characters
value = value.Replace("\"", "\"\"");
//If it contains a comma or a quote char -- qualify it with quotes.
if (value.IndexOf('"') > -1 || value.IndexOf(',') > -1)
{
value = "\"" + value + "\"";
}
return value;
}
The syntax highlighting looks very strange, because I wrote it in sql server management studio. It just happened that the only text editor i had open at the time was SQL server, so that's what i used.
(Real developers don't use any particular editor – they just use whatever's open at the time. Even the act of opening notepad is too cumbersome for the ubergeek.)
After I emailed it to my colleague I had a moment of weakness, when I suffered the tiniest smidgen of self doubt.
"Perhaps I should’ve tested the code in some way. Or -- at least -- compiled it?"
Scott Bellware and the cool alt.net kids are always banging on about this sort of stuff, so I wrote an awesome console app to test it.
namespace tests_are_for_wusses
{
class Program
{
static void Main(string[] args)
{
System.Console.WriteLine(EscapeCsv("fred") == "fred");
System.Console.WriteLine(EscapeCsv("fre,d") == "\"fre,d\"");
System.Console.WriteLine(EscapeCsv("fre\"d") == "\"fre\"\"d\"");
System.Console.ReadLine();
}
private static string EscapeCsv(string value)
{
//Double all quote characters
value = value.Replace("\"", "\"\"");
//If it contains a comma or a quote char -- qualify it with quotes.
if (value.IndexOf('"') > -1 || value.IndexOf(',') > -1)
{
value = "\"" + value + "\"";
}
return value;
}
}
}
Naturally, the awesome code passed my awesome tests first go.
Thus I have once again shown that testing is a waste of time if you are awesome like me.
And the so-called cool kids from alt.net are just bad programmers.
Thank you.
Wait a second... I still feel I'm missing the point. Care to enlighten me?
(By the way -- pretty much every sentence in this post was sarcastic... while the story is true, my real interpretation is that i just got lucky this time. There's definitely some bugs still hidden even in a simple function like this)
Read On...
Sat, 18 Apr 2009 09:07:26 GMT
The heart of a good 'Getting Things Done' process is to have a Single trusted system where you capture your tasks.
I guess I'm Doing It Wrong :-(. Here's all the places where I distribute my todo list...
- In my current moleskine (pronounce it with me -- Moh-leh-skeen-ah) on pages 9, 12, 31, 57 etc.
- in my phone
- in outlook (at work)
- in my code using
//TODO: tags (scattered over numerous projects)
- in my code using
NotImplementedExceptions.
- in timesnapper's hosted fogbugz account
- in 'nextaction' on my work pc
- in 'nextaction' on my home pc
- in 'nextaction' on my laptop
- in my gmail account (emails labelled 'todo')
- in my gmail account (emails marked with a star)
- in my gmail account (any emails from me)
- in my other moleskine, beside the bed
Still, I think i'm pretty good because I do actually tend to 'get things done'. But also because i resist keeping lists in all these other places:
- in iGoogle
- in sharepoint (at work)
- in my gmail account (using the Gmail Tasks plugin)
- on pieces of paper on my cubicle wall
- in my other notebooks
- in timesnapper using flags/tasks/notes
- in yet another todo.txt file
- on sticky notes randomly decorating places I inhabit
- in twitter
- in tada list
- in that surprisingly popular codeproject todo list
- in remember the milk
- in a tiddly wiki
- in the iphone i don't have
- in the PDA i don't have
- in chandler
- at trimpath 'next action' web site
- on my blog
- using tattoos (memento style)
- in google calendar
There's no shortage of places to keep your things to do.
I don't worry about having too many systems. A bigger fear is failing to capture a problem as it arises.
You frequently get just one chance to capture an idea, so I capture it anywhere I can.
Read On...
Wed, 08 Apr 2009 09:47:36 GMT
I've been using my tiny slice of computer time to write software lately, and haven't spared any cycles for writing articles. In lieu of that, here's a series of lost notes to accompany some of my recent twitter outburts.
Abstractions should be as high-level as possible, and no higher. #
Einstein of course said,
"Make everything as simple as possible, but no simpler."
... and that's a kind of programming mantra, as so often in our race to simplify we end up over-simplifying. (The famous 'Worse Is Better' philosophy could be phrased as an argument that sometimes you should actually sacrifice correctness for the sake of the simplicity -- i.e. 'Einstein was wrong.')
In a similar vein, I think there there is such a thing as 'too abstract'. And it is a terrible thing.
Pre-emptive Abstraction is at least as bad as Premature Optimization #
- If your class name contains the word "Abstract" -- you're doing it wrong.
- If ClassName.("FactoryFactory") -- you're doing it wrong.
- If ClassName.Contains("FactoryFactory") -- you're doing it wrong.
- If Your ClassName Ends With "BaseBase" -- you're doing it wrong.
- If ClassName.Contains("Factory") && ClassName.Contains("Provider") -- you're doing it wrong.
Economists re-evaluate bird in hand as 1.9 times bird in bush.
#
A more appropriate tweet might've been:
'Economists write down bird in bush to 0.45 times bird in hand.'
Or:
'Government provides 8 trillion birds-in-hand to replace 16 trillion birds lost in bush.'
Someone (I think that cockroach poet Archy) once called humanity something like "a strange species of bipeds who cannot run fast enough to collect the money which they owe themselves."
i am *not* homophobic. Infact, some of my best friends have iPhones.
#
And I'm still waiting to see them make the millions of dollars from iPhone apps that they promised themselves last year.
If a job's not worth doing, it's not worth doing properly
#
The original statement: "If a job's worth doing, it's worth doing properly" has the corollary that any job that is not worth doing properly is therefore not worth doing at all.
This is patently absurb and a kind of shining example of why perfectionism doesn't pay.
The slightly twisted variation:
If a job's not worth doing, it's not worth doing properly
...may seem defeatist and sloppy -- but i think it's the very soul of true productivity.
That's what no one seems to appreciate about being rich: the first 100 bazillion is the hardest.
#
After that, you can just sit back and live off the interest of the interest.
And your next code editor is... a browser.
#
I still think it's true -- and once i get a bunch of other things out of my todo pile -- i'm going to make it happen. Maybe.
Meanwhile I'm working on TimeSnapper v.Next, and tinkering on something tentatively called MetaNote -- about which you'll be hearing more.
Read On...
Mon, 23 Mar 2009 07:28:26 GMT
When you're looking at a query window that's connected to Production, it would be nice if it was visually distinct from a non-production environment.
For example, there could be a red theme applied to the window.
Furthermore, there could be a warning before a potentially destructive query is executed. (Essentially, any query that isn't just a select - for example, a drop, delete, update, insert, create or alter)
This would be an effective way to lower the chance of something being done to production that was intended for another environment (pre-prod say, or development)
I can imagine a straw-man counter-argument to this concept that says:
"The only people who should have access to production are people who know what they're doing"
Or alternatively,
"Developers shouldn't have access to production"
And that's fine by me.
We can limit who accesses production, and we can give minimum privileges to those that do have access.
But even then:
*Someone* will have destructive privileges in production.
And that person will definitely have access to more than one system.
And that person, no matter how smart or conscientious they are, will be fallible.
Hence, it's helpful for that person to be able to differentiate (visually) between the different environments.
Why am I writing this blog entry right now?
Don't worry. I stopped myself in time ;-)
(And like all blog posts everywhere, there is already a stackoverflow question that says the same thing and a whole lot more)
Read On...
Thu, 19 Mar 2009 10:30:32 GMT
My code would suck less if the C# compiler raised an error anytime it detected the following:
- A button with no click handler.
- A click handler with no code.
- A parameter that is not used.
- Code that throws A '
NotImplementedException'
- A
//TODO: token.
- An
#if DEBUG
- A phrase that contains more than one dot, e.g.
Control.Parent.Parent.Parent.Controls[3].Controls["Accept"]
Q: Why do I want the compiler to be so mean?
A: It takes a tough man to make a tender chicken.
(attributed to Purdue, quoted in 'Worse Is Better')
No, the common thread here is these are pitfalls common to a top-down, (or an outside-in) design approach.
As you move top-down, (or from front to back), you throw off "branches" -- kind of last strands -- that you need to back-track to complete later. I want the compiler to help me find those branches. (Tests are a poor substitute)
In his 2005 classic 'Does Visual Studio Rot the Mind?' Charles Petzold showed how intellisense-and-friends encourage bottom-up programming.
These are some little features that could help out the die hard top-down coders.
Details...
"A button with no click handler"
Why does a button exist? Is it just to look good?
No! Buttons are for clicking!
A button with no click handler is a fail.
And a click handler with no code is a fail as well.
What does the user expect when you click a button?
Unless this is that Early Internet Phenomenom known as The Really Big Button That Doesn't Do Anything, a user expects *something* from a button.
Why would you check that in? What good can possible come from letting do-nothing buttons end up in the hands of unsuspecting users?
The world of static code analysis has gone very far – but does it stop and help us avoid this sort of psychological torture?
(This same concept may be true for many other objects that raise events. The object's author might be able to indicate "There's really no point using this thing unless you handle the following event(s).")
A parameter that is not used.
Unused variables raise a warning, but unused parameters don't.
This is a little bit good, but it's a little bit bad as well.
Here's an example where the unused parameter is clearly a bug:
private void CopyFile(string sourcefileName,
string targetFileName,
bool overwrite)
{
System.IO.File.Copy(sourcefileName, targetFileName);
}
Oops!
The programmer forgot all about the 'overwrite' parameter!
I consider that a pretty clear error.
But consider our click handler for a moment:
private void Button1_Click(object sender, EventArgs e)
{
MessageBox.Show("Hello");
}
Neither parameter is used. But if we were to call this an error, a hell of a lot of code that's shipping today would fail.
Some design changes could alleviate the dilemma – I'll leave the consideration of possible solutions as an exercise for the interested reader. The goal is to avoid busy work, not create it.
Code that throws A 'NotImplementedException', and //TODO: token, #if DEBUG conditions and everyone from System.Diagnostics.Debug
Not Implemented Exceptions are excellent stuff.
But your goal is always to eradicate them, right? They're a kind of hardcoded place holder. A warning ought to suffice. (You treat warnings as errors, most of the time, right?)
I put //TODO: tokens and #if DEBUG conditions in the same category. They're very handy scaffolding or place holders as you crank out your code -- but they're not supposed to remain indefinitely. A warning would be nice. Maybe Debug.WriteLine and its friends should fall into the same category.
A phrase that contains more than one dot, e.g. Control.Parent.Parent.Parent.Controls[3].Controls["Accept"]
Why would a compiler let you get away with this kind of monstrosity?
It would be quicker to just replace that whole line with "throw new NullReferenceException()". The effect would be the same.
My point here is that this kind of implementation of the house of cards anti-pattern is easy for static analysis tools to pick up.
I know that there are existing static analysis and code grepping tools that can be used for some of these cases, but they tend to run 'after the fact', outside the tight code-compile loop. Worse: they tend to produce a lot of noise and take a lot of care and feeding.
StyleCop is the worst 'busy work' generator I've seen. (If only they'd finished the job and had it auto-correct many of the problems it finds... instead, like '100% code coverage' it's a kind of training tool for Coder's OCD.)
Alrighty -- that's all I've got for now, though if I keep my eyes open, I bet I'll spot some more.
Read On...
Wed, 18 Mar 2009 19:16:13 GMT
Ah! that's it!
I've often wondered what people really mean when they said 'Architect' while talking about software.
None of the literal meanings seem to capture the way the word itself is applied in this context. But I think I've hit the thing on the noggin at last.
A 'swear word' is a word whose literal meaning differs wildly from its contextual intent -- and whose intent can be bent to suit a great many contexts.
Take 'F---', for example. The word has a literal meaning, something like 'To copulate vigorously' -- but in actual use, the intent is generally bent to suit the context.
For example, when I hit my thumb with a hammer I say "F---!" and in that context the meaning is: "It hurts a lot when I hit my thumb with a hammer."
Or, when I get a flat tyre I say "F---!" and it means, "This flat tyre is an unexpected interruption to my day that will cause undue expense and wasteful exertion." The quickest way to say all that is simply "F---!".
Now imagine there is a guy in your organisation whose coding skills are terribly out of date, but who is not capable of performing any managerial duties.
If someone asks you, "Who is that guy?" then you probably won't waste your breath by saying, "Him? A guy whose coding skills are terribly out of date, but who is not capable of performing any managerial duties." Instead you'll permit yourself to emit a nasty little swear word and simply say, "Him? Architect." Ouch!
Now, just say you work with an impractical fool with an over-inflated sense of self-importance who destroys whatever thing he touches, never ceasing to bring layers of accidental complexity to even the simplest of contrivances, but who is, thankfully, kept out of harm's way by being assigned the task of writing grandiose-titled corporate documents that no one is ever expected to read. When someone asks you who that guy is, you draw your breath in deep, and prepare to say:
"Him? An impractical fool with an over-inflated sense of self-importance who destroys whatever thing he touches, never ceasing to bring layers of accidental complexity to even the simplest of contrivances, but who is, thankfully, kept out of harm's way by being assigned the task of writing grandiose-titled corporate documents that no one is ever expected to read." So, again, you'd just curse and say "Him? Architect?"
Read On...
Sun, 15 Mar 2009 02:25:12 GMT
TimeSnapper version 3.4 went live a few days ago!
It can now run from a USB key, and is prettier in a few ways.
But the main feature is the new plugin model which lets you extend TimeSnapper with your own features.
The plugin model has been there for quite some time, but we've never publicised it before, or released any plugins that use it.
We've now released our first official plugin. A simple plugin that lets you create animated gifs from your snapshots. I've written a guide to help anyone who is interested in writing plugins of their own and provided a sample in VB, and a sample in C#. I can provide lots more examples, and information for anyone who is interested.
The animated gif plugin owes a debt of gratitude to Jon Galloway -- we reuse the Gif.Components.dll that he put together for his cropper plugin.
We're hoping to host plugins from other people -- we'll provide a nice page where people can download them. We'll help out with development, debugging and so on, wherever needed. If there's sufficient interest we'll spawn a separate forum for plugin development. (For now, the regular forum is the best place to ask questions).
APIs are funny things -- and I received a hell of a lot of criticism while writing this API. The criticism came from a particular nasty and vocal user who never seems to be happy with any of the work I provide. That user is (of course) (in case you haven't yet guessed it) -- me.
So, if you're looking at the plugin model and you see something you don't like about it. Well, I understand. Constructive critcism and suggestions on how to improve the API are very welcome.
As always there are full details in the release notes, and there are lots more goodies on the way.
Read On...
Fri, 13 Mar 2009 21:15:11 GMT
A few arguments I've been worried about. And, at last, definitive results.
Read On...
Fri, 13 Mar 2009 09:06:25 GMT
One of the mixed curses of being obsessed with software is that you see reminders of it everywhere, even in things that predate the existence of software.
For example, Cake Making.
When you're making a cake, you need to add eggs to your cake mixture.
My wife told me that you don't break the eggs directly into the mixture. Instead, you break them into a separate bowl, and then add them to the mixture.
"Why not break them directly into the mixture?" I asked.
She picked up her cookbook and turned to Appendix A -- The SOLID Cooking Principles, by Robert C. Martin.
No she didn't.
She explained that if an egg is bad you don't want to ruin the entire bowl of cake mix. And it's easier to spot little bits of egg shell in a bowl of yolks than in a bowl of cake mix.
"Ah, the virtues of independent deployment," I said.
And she looked at me askance. (Askance is not the best way to be looked at, btw).
While we're discussing eggs, I have to repeat my favourite saw:
"You don't have to eat a whole egg to know it's bad."
(Side point: this topic fits with the stack overflow question
"What real life bad habits has programming given you?" wherein you will find over 425 similar experiences. What a sad lot we is.)
Read On...
Thu, 05 Mar 2009 17:57:47 GMT
Despite knowing absolutely nothing about Python, I've had a lot of fun and a few lttle victories with it tonight. I've built two small apps that I'll include the code for below.
I've avoided IronPython up until now, but a terrible problem has arisen lately.
I've decided to write my own text editor.
This is a bad thing. Only fools write their own text editor. Soon, hair will start growing on the palms of my hands.
But, since I'm looking for some extensibility in this editor idea (of which I'll show more in a subsequent post) I realised that hosting IronPython is the best way to get the sort of scripting I'm after.
Hosting IronPython in C# is well-trodden turf. Many other have been there and blogged it before. But the fun was really in the doing.
Here's two very short demo apps I wrote tonight, literally in under an hour.
First, by following the example Bernie Almosni provides in Extending your c# application with IronPython I built a little interactive calculator, with a history.
The code is trivial and can be downloaded below.
The next example is also trivial, but I'll step through the code just quickly, since it's a superset of the previous example.
I wrote a little application that lets you write python code to alter the contents of a textbox. This is the heart of the editor I have in mind -- and it's barely 10 lines!
So, in a fresh C# winforms app, I added references to all the dll's in C:\Program Files\IronPython 2.0.1 (I didn't know which dlls i needed exactly -- so i referenced them all ;-) )
I created a new form and dropped two text boxes and a button on it, as you'll see in the screenshot.
I added these using statements:
using IronPython.Hosting;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;
I created two module levels variables, one to hold the IronPython engine, and one to tell it the 'scope' of the variables I want to share with it.
private ScriptEngine m_engine = Python.CreateEngine();
private ScriptScope m_scope = null;
Upon form_load, I construct the scope, and add the target text box to it. (This is the text box our Python code will be able to act upon.)
m_scope = m_engine.CreateScope();
m_scope.SetVariable("txt", TargetTextBox);
When the user clicks the button, I compile the code in the first box, and execute it as a statement.
Dead simple. Ridiculously simple.
string code = CommandTextBox.Text.Trim();
ScriptSource source = m_engine.CreateScriptSourceFromString(code, SourceCodeKind.SingleStatement);
source.Execute(m_scope);
With that in place, the python code entered at runtime, such as:
txt.SelectedText = txt.SelectedText.upper()
...has the desired effect of making the selected text uppercase.
I got the same effect in C# once, but it took five assemblies, hundreds of lines of code... it was terribly fragile and I broke it beyond repair before I got it to a source repository. A tragic episode, i still feel like stabbing someone every time I think about it. (LFT much?)/p>
So -- here's the source code:
Sample Python Calculator and Programmable Text Box.
And here's a couple of other articles on the same topic:
Read On...
Fri, 27 Feb 2009 09:54:30 GMT
There's a psychicologicalous condition known as 'Low Frustration Tolerance', (LFT for short... abbreviations, btw, are helpful for those with LFT ;-))
Low. Frustration. Tolerance. I am writing slowly. Just to frustrate the Living Hell out of those who have LFT.
Every day you will see examples of people with Low Frustration Tolerance. You know these people.
You're in your car, stopped at the lights. Light turns green, and before you've put your foot on the accelerator, the guy behind you blares on his horn. Hard. He's got LFT. Bet on it.
To be a programmer REQUIRES a ^^high^^ level of frustration tolerance. Most people with LFT, on the other hand (OTOH ;->) end up as drunks, hobos, drop outs, early-deaths, burn-outs.
(But stick around -- there is a twist.)
So, the only way to be a decent programmer, able to produce good output every single day is to have a high-frustration-tolerance.
The amount of frustration we encounter in the computing world, every single day, is just astounding. Many days our job consists of leaping one hurdle after another.
Sometimes, just for fun, I keep a little log of the hurdles I encounter in a day. They are numerous.
I want to get from A to B. Step A: Something goes wrong. I investigate. Dead end. I google it. Dead end. I check logs. Dead end. I increase logging. More evidence. I google that. Dead end. I download a tool that will get more info. Tool fails to install. I google the installation failure. Dead end. I look for another tool, install that, run it: crashes. I investigate the crash. Dead end. I find a different tool, install that. Get more info. Investigate that. Dead end. Google it. Dead end. Stack overflow it: dead end. Drink coffee, consider taking up smoking. Dead end. Wait two weeks, increase bounty at stack overflow. Dead end. Reboot, check patch level, look for random hints from astrological tables, listen to reggae... dread end. Sometime later, randomly: breakthrough. And on step B.
Annnyway, I've established the first point: a good career in programming requires High Frustration Tolerance.
And yet... I am utterly convinced, that the only way to succeed as a programmer is to have really LOW frustration tolerance.
You have to get fired up by tiny little things. You have to care, dammit, and care deeply, about tiny little points.
You have to pour your heart and your soul into accepting nothing but perfection from that damn regular expression, that damn CSS selector, that damn SQL case statement, that bloody mother f***ing a*****e of a *** **** son of a ******* ugly ***** ***** **** of a **** installation package, so the lucky ******* **** of an end user gets all the joy of a working system.
It's a catch 22.
And sometimes we forget that *both* skills are needed. We fall into the trap of being one or the other.
So here's my latest plea:
Stopping being so easily frustrated. And please, stop settling for second best.
And then: tell me how it's done.
Read On...
Fri, 27 Feb 2009 07:42:34 GMT
After seeing this handy cheat sheet for the git version control system, I had to stop and reflect for a moment.
Despite all the attention that distributed version control systems get, I suspect that Visual Source Safe is still the most used source control system in the world.
And is anyone stopping to help the 'silent majority' learn to use their tool of choice, i.e. VSS, just a little better?
With this thought in mind, I've developed
'a handy cheat sheet for Visual Source Safe'
In all seriousness, your code is immensely valuable, and you need to respect that fact. Please use a reliable system.
If you're having trouble moving a sluggish team away from VSS, them move them onto Sourcegear vault. It re-uses the concepts and the look of VSS, but adds in reliability and a lot more.
If you're new to version control, or have projects that don't use *any* version control, get subversion up and running. It's easy to use on every system and it's free.
Git, etc: If you're a candidate for using a DVCS, then you already know all about it and don't need to take advice from an idiot like me.
One other plea: if you have 'little' projects that are 'too small to bother with source control' -- just re-think it.
Hooking up to a free subversion repository is easy, and beneficial. Hard-drives do crash, you know. And sometimes, you do need to roll back, you know.
Cheers and best of luck.
Read On...
Fri, 13 Feb 2009 11:27:42 GMT
There's a malady experienced by some folk, known as 'lost time'.
The condition arises when a chap looks around, stunned, suddenly finding themselves far from home, dressed in someone else's clothes, driving someone else's car, with no memory of how they got there, or what happened in the last 3 months. Time was lost.
Through the law of equilibrium I deduce there must be an equally common condition whereby time is found. Some harried, stressed-out individual is bemoaning the fact that they've got so many tasks and so little time, when suddenly they realise oops! today isn't Thursday -- it's only Monday -- and there's an extra 72 hours of bonus time, delivered from nowhere!
Project managers, of course, live in the optimistic belief that this syndrome will suddenly attack their whole team in spadefulls.
I've even known project manager's to try and slip a whole extra month into their nasty tricksy Gantt charts. ("Umtember" falls between November and December.)
If you happen to be infected with a wicked dose of Found Time, please take careful notes regarding cause and contagion, so your time-poor brethren can benefit.
Thank you.
Read On...
Sun, 08 Feb 2009 09:33:42 GMT
Remember how Justice Gray started that little fad about becoming a better developer in 6 months?
Well, that was a while ago and most of you failed. Badly.
So here's a simpler challenge, some ways to be a better programmer in 6 minutes.
You've got 6 minutes, right?
Go for it!
- Use a bigger font size.
This is ridiculously easy -- but it works.
Go to your favourite IDE, and crank the font-size up. I switched from 10pt to 14 pt. The difference is that a lot less code fits on the screen at once.
The effect is: you're forced to write shorter methods. And that's a Good Thing.
(Scott Hanselman recommends that one)
- Make hard-coded strings look ugly.
I learnt this from Joe Cooney.
Go to your favourite IDE, and set it so that literal strings stand right out -- for example a yellow background with a red font. Make 'em ugly. Damn ugly. This will encourage you to perform less hard coding, and to notice when you are embedding strings in your text.
- Pick an 'obscure' keyword and master it
Do you fail to yield?. Is there a keyword you never use?
Every keyword has a purpose. Learn to master those mystery keywords and your powers will become extraordinary.
Here are lists for a few .net languages: C#, VB.net, F#.
- Increase code-coverage by 1%
Don't kill yourself striving for 100% coverage of code with automated unit tests. But take a few minutes to increase your coverage by 1%.
Most likely, that means going from 0% to 1%. And that's the biggest improvement of all.
Find a particularly ghoulish regular expression. Or a critical piece of business logic. These things can't be trusted without tests.
- Read the code from an open source project
Sometimes, when I'm looking at the code of a complete stranger, I get that same, weird feeling I get when I'm creeping through my neighbour's house. Picking up their stuff, looking through their fridge.
Learn to overcome the creepy sensation, and bring on the learn.
Maybe start with Hanselman's Weekly Source Code series.
- Run a static analysis tool against your code
Use fxcop, or StyleCop, clone detective, ndepend, the code metrics feature of VS 2008, or any other static analysis tool of your choice.
Uncover your greatest weakness. Even a cursory glance at the output will leave you distraught at just how much room you've got for improvement.
- Pick an ugly method to refactor
You know the method. That method you're particularly ashamed of. That one that's long and ugly and horrible. And it's crucial to the whole application.
You don't have to polish it from a turd to a diamond, but just neaten it up a little. Rename a variable. Hoist part of it out into a separate method. Start simple. The momentum will increase. Watch out.
- Stop reading, start writing.
And don't just write. Write a compiler!
This ol' msdn article is a good place to start. Joel Pobar will get you writing your own language compiler in but a handful of minutes.
That's all I've come up with for now. But what've you got?
What are some 6 minute activities that helped you be a better programmer?
Read On...
Fri, 30 Jan 2009 11:25:03 GMT
Consider this little step-sheet.
- Q:What do managers do when they're stressed?
- Q:What gets managers stressed out?
- A:When projects are not making progress.
- Q:When do projects fail to make progress?
- A:When people spend too much time in meetings.
Thus we have the rise of meetingitis -- a deadly malady that has struck down many otherwise healthy projects.
Once the disease has set in, the prognosis is grim.
The only aproach is to prevent the syndrome before it develops.
How do you prevent meetingitis?
Many people foolishly think that meetingitis is caused by 'too many meetings.'
But look closely at the steps above and you'll recognise the root cause is stressed out managers
Picture this futile attempt at preventing the syndrome:
Jack is a busy coder trying to implement his code.
He says to the manager: "I don't want to go to the next meeting. I'm not making enough progress, so I'm not gonna attend your stupid meeting."
What happens next?
Jack may get out of that particular meeting. But what is the larger effect? will the manager become more or less stressed? More stressed of course (rhetorical question) and what happens then? The manager, now in a state of complete freakout, calls extra meetings: status meetings, emergency meetings, all-hands-meetings, crisis talks, war-rooms, action-squad meetings and before you know it the meetingitis has reached its final stages: the manager decides to form a committee.
The only approach that can possibly work: deal with the stress itself. Put the manager at ease.
Communicate more, in order to meet less. Be proactive in your communication. Don't wait for them to call a meeting. Tell them what's going on. Produce regular reports. Don't "promise" to produce regular reports -- just produce them. Let them listen in on some of your day to day chatter. If you have daily standups, bring the manager in. Stop baffling them with technical mumbo jumbo. Feed them edible slices of information. Walk them through it in bite-sized chunks. Give them documentation tasks to keep them feeling important. Give them communication tasks. Draw pictures for them to stick on the wall of their office. Give them some kind of flashy management information portal that has interactive charts (you don't need to hook them up to any real data -- a random number generator ought to do it). Or maybe there's a better way?
What do you do?
How do you prevent meetingitis?
Read On...
Sat, 24 Jan 2009 09:41:58 GMT
The other day, someone on stack overflow said they wished copy and paste were not permitted within an IDE.
It's a wacky idea - but sometimes I'm inclined to agree.
Maybe it shouldn't be completely illegal - but it could be harder to do (in specific circumstances), or tracked more closely.
At one point (perhaps long ago, perhaps today...) I stumbled onto this chunk of code [at right], and I thought "Hmm, interesting lack of reuse..."
Why use a data structure when you can copy and paste your code?
It's only a little code smell, right?
Not really, because you know that where people have the 'copy/paste' bug... it's only going to get worse.
Let's zoom out and see what we find...
The code sits inside this method... -->
(There's other issues there too, but let's leave them aside today, please.)
And the very next method down is almost identical -->
Then - I look at the next class - it's an almost identical class, and it has two methods of its own with identical names to the ones above and only very slightly different code...
So we're talking about a serious case of "Achieves reuse through the cunning application of copy and paste"
And you know it doesn't stop there.
It just keeps going - thousands of lines of copy/pasted code. File after file. Bugs here and there (notice the 'harmless' bug in the first snippet?) quirks abound.
It's a fractal! The more you zoom out, the more you see the same pattern copied, pasted, modified, and reapplied over and over at greater and greater levels of scale. The author's entire career could be composed of the same programs, copied, pasted, and modified, retrofitted to slightly different problems.
Copy/Pasting is like the weather. Everyone complains about it, but nobody does anything about it.
If copying and pasting were illegal (or more difficult) - would the implementer have thought about achieving reuse through other methods?
Illegal is taking it a bit far. So: how could the copy/paste virus be reduced?
Maybe clippy could pop up and say: "It looks like you're copying and pasting code. Do you know that you can achieve re-use in other ways?" (Maybe we could use Scott Bellware's face on clippy? eh?)
How about this... every time you use the "paste" function inside your IDE, a little counter is incremented. And that counter is displayed on a gigantic, glowing LED panel suspended from the ceiling above your desk.
Or: Every time you use the "paste" function inside your IDE, a loud buzzer sounds for ten minutes, and a flashing red siren pops up over your desk.
Or: Every time you use the "paste" function inside your IDE, your screen is locked out for ten seconds.
I think you'd only need to apply a technique like that for a few minutes a week and you'd soon be permanently cured of copy/pastitis.
My friend OJ suggests...
"an enterprise Copy and Paste server, which acts like a petrol tank. Hence you only get to use your copy and pastes wisely before you run out."
Perhaps a plugin would need to detect when code is copied and pasted from within the ide. It would only punish you when the copied code (and subsequently pasted code) contains some degree of logic.
And before you say it -- I know there's a tool called Simian that you can plug in to your continuous integration server, to detect this sort of nonsense. I haven't tried it, but I'd like to know more. (They're Australian by the way)
Also -- an apology
Let me be crystal clear about one thing... writing this kind of code doesn't make you a bad programmer.
This particular code was written by a very successful programmer, who does an excellent job of delivering value to the business.
It is definitely a better example of programming than a hell of a lot of code I've seen in the business world.
I'm just decrying the fact that sometimes we work harder not smarter, and if we trained ourselves into the right coding habits, we could achieve both: work hard and smart.
Read On...
Thu, 22 Jan 2009 10:13:09 GMT
There's a common UI anti-pattern of making "readonly" fields harder to read than editable fields.
I think this is a poor technique. I blame it on Windows Forms -- but I've seen it out there on the wild web as well.
If a control is readonly, then you should cater for the user actually wanting to read it. Shouldn't you?
Newspapers, for example are readonly. And they are commonly in black and white. Fine, crisp, perfectly legible black text. Not dull gray.
Rather than making the readonly fields dull gray, use some other form of visual hinting to differentiate between what can be edited and what can't.
For example – here's some readonly checkboxes.
They are shown as dull gray with gray border.
Instead, the check marks could be black, while only the control border is gray.
Or, perhaps the control border could disappear.
What about this drop down list – its 'readonly' status is indicated by gray text and gray border.
It gives the impression that it has no meaning and no influence. In fact, it's message is fairly important - perhaps extra important since the user has no control over it.
It could instead have black text and gray border.
How about black text with NO border. It's easy to read, and it's clearly not editable.
I think that both of these are preferable to the 'make it gray' approach. Don't you?
Read On...
Tue, 20 Jan 2009 10:18:26 GMT
Somewhere in my hard-drives I've got a very length and never quite finished article on this topic.
The Online-IDE. What a thing of beauty. What a must-have. What a killer app.
And of course: What a horrible idea! What a monstrosity!
I think I started trying to write about the topic in about 2003. And I was pretty serious about it then. I started building one. Twice!
It seemed like it was only just beyond the state of the art. Sure there were challenges. But there was this thing i'd discovered called httpWebRequest... and with it's power, the Online IDE seemed inevitable.
Well, it's 2009 now and we're still stuck with these crazy desktop IDE's. But how long now, until the IDE goes online?
"Maybe not tomorrow, and maybe not the day after that. But soon, and for the rest of your life, you'll be programming online."
What do you think? Inevitable?
Here's dodgy pictures of some of those I found.
'The web 2.0 database' lists a lot of Online Development tools and there's a Big List at itredux.com
The main one I'd heard of is heroku garden (formerly heroku), which combines Ruby with Amazon's cloud compute offerings.
Plenty of people mention CodeIde and Coghead. Yahoo Pipes and Microsoft Popfly are not qute the target topic, but they get an honorable mention.
Assume that your children's generation are using online programming environments for all of their programming needs. How do you see it working? What innovations are required to make it feasible?
Read On...
Sat, 10 Jan 2009 02:42:38 GMT
(It's long and it's preachy -- but I hope you enjoy it)
JFK speaks his mind about programming techniques
|
That great software programmer John F. Kennedy once famously said:
"Ask not what your software project can do for you - ask what you can do for your software project."
(Few people realise the 'F' in 'JFK' stood for 'Fortran'.)
I'd like to go one step further than JFK, and look at both sides of the deal: What you can do for your project as well as what the project can do for you.
In putting this list together, I'm going to steal liberally from two classic articles "The Joel Test" and "The programmer's bill of rights"
Here's the quick overview...
What can the project do for you?
First up we have a bunch of items along the lines of "I expect -- maybe demand -- that management will provide me with..."
- Two monitors
- A fast PC with a crapload of RAM
- Choice of mouse and keyboard
- A comfortable chair
- Quiet working conditions
- Internet unlimited
- Freedom to install software
- The best software
- Good coffee
- Sensible working hours
- Separate Environments for dev, qa and production
What can you do for the project?
But it's not all "take take take".
The other side of the equation are items along the lines of "I am committed to ensuring that these practices are performed..."
- Source Control
- Continuous integration
- Track bugs
- Unit testing
- Code analysis
- Continual peer review
- Peer training
- Keep yourself up to date
- Learn to Communicate with non-technical people
- Refactor!
- Passion
JFK asks management for a second monitor
|
Part 1: What can the project do for you?
Two monitors
The research is in. It's worth ten times its price. Give your dev two monitors.
A fast PC with a crapload of RAM
There's a messed up philosophy-- a kind of offshoot of the 'eat your own dogfood' school of thought -- that insists developers should have the same desktop rig as end users. This is nonsense.
End users aren't running three virtual machines, a local database server, three instances of visual studio, and two instances of blend. Devs need a hot rig with massive RAM. Anything less is ridiculous.
Choice of mouse and keyboard
Want to see a perfectly sane developer go nuts? Give them a bad keyboard. I have anecdotes around this topic... terrifying anecdotes that would turn your hair white... but the people involved are all still alive and i can't spill the beans. Trust me. Don't f*** with a developer's keyboard. Bad things happen.
A comfortable chair
This isn't just a programming thing of course, it's crucial for all office workers. The productivity loss from one screwed-up back could buy Herman Miller chairs for the whole company.
Quiet working conditions
Four-walls and a door might be too much to ask, but at least organise the open spaces in ways such that the shouty/squealy-teams are separated from the thinky-teams.
Don't put marketing next to the devs. Don't put the help desk next to the devs. Don't put the angry shouting Glengarry Glen Ross-style sales team next to the devs. In an open space, use baffles and greenery to isolate the noisy teams. Consider the different Yerkes-Dodson requirements for optimum performance from each team.
JFK's workstation includes a state of the art console
and a swivelling chair. Uniform: relaxed
|
Internet unlimited
Consulting has shown me some pretty weird scenarios. I've worked at places where they insisted that 'contractors don't get internet access' and i've seen plenty of places where there are heavy handed website filters in place. 'This site is banned because it looks like a blog' -- for example, WTF? Even worse: "sorry, you can't use google, our company policy is that we use yahoo." WTF? If you choose to work with people, put some trust in them. Monitor them if you must (and tell them if you do) but don't put roadblocks between them and the obscure information they're trying to get their hard-working hands on.
Freedom to install software
Group policies, S.O.E.'s, limited user privileges -- these are all good and helpful things that IT departments need to keep their own sanity. I get it. I know. But let the devs break out of the box, please. Tell the dev's that they're on their own if the stuff they install causes problems. They have to fix their own messes -- but give them the freedom to install whatever dinky little weird utility they need from one minute to the next.
There's plenty of specific tools I've installed to use just once in my career, and then never needed again.
Having to fill out a series of forms on such occasions is a waste of everybody's time.
The best software
Why for the love of god is .net 1.0 still in use? Why are you advertising for a VB6 developer? Why do you make developers manually track the differences between two databases? Why do you let developers roll their own code generator? Because you're a stingy short-sighted fool I guess.
Good coffee
What is this crap we're drinking? Nes-frickin-cafe granulated food service blend? You had better be kidding me. Get me a goddamn macchiato. Now. Then back the hell away and let me write my goddamn code.
(Image courtesy of Rands in Repose)
Separate Environments for dev, qa and production
You can't afford testers and you just want me to fix it in production, eh? That's awesome. That's great. Next time the dentist is drilling out a cavity in your mouth, I'm going to tell him "This is an urgent operation. Let's not waste time on X-rays. Just start drilling, you're bound to hit something that's rotten. And let's save a few dollars and cut out the anaesthetic altogether."
Part 2: What can you do for the project?
Source Control
If they don't have source control -- you create a subversion repository. If they do have source control, but they're using VSS, you can move them onto Sourcegear vault. (It's an easy transition and it overcomes most of VSS problems.) If they're using vault you can move them onto subversion. If they're using subversion you can bump them up to mercurial. If they're using mercurial you can push them into git.
Okay -- don't change things just for the sake of changing them, but make sure you're using the best source control solution available to you, you're using it well, and everyone's using it.
Continuous integration
If there's no daily build, then put a daily build in place. If there's a daily build, them make sure it starts with a clean environment (no cheating) and make sure it builds everything, not just a couple of things. If the build is good, then make it continuous -- make it happen on every check in. If the build is good and continuous, make sure the communication lines are clear -- everyone can tell the status of the build at any moment. If all that's in place... well move onto another point.
Track bugs
Email is not a bug tracking system. You can't run queries over email. Email slips through the cracks.
If there's no bug tracking system, set up a shared spreadsheet. If the only bug tracking is some crappy shared spreadsheet then use sharepoint, or install Jira. If the only bug tracking system is sharepoint or jira, then install lighthouse. If the team are stuck on lighthouse then purchase Fogbugz. If TFS is available, make sure the workitem tracking is well configured and well used. If checkins aren't associated with bug numbers, make it so.
Build whatever tooling you need, above what the products you use offer, to ensure that the bug tracking works for you.
JFK asks the users for feedback on
the proposed entity-relationship diagram
|
Learn to Communicate with non-technical people
Stop baffling them with bullshit. You don't do it on purpose (well, not usually) but you still do it way too often. Stop using technical terms with non technical people. Find the simplest way to state your ideas. Leave implementation details aside. Dummy it down. The end user has a full life of stressful issues all their own, without having to translate into your crazy mumbo jumbo.
Unit testing
If there's no unit tests, identify hotspots, start slow.
Start with regular expressions. Never trust a human's ability to write regex. Every regular expression needs solid unit testing. Focus on critical business logic. Focus on stuff that matters. One by one, knock them down. Every gain you make is a victory. Feel free to celebrate.
If unit tests are already included, but they're not part of the build, put them in the build. If there's a good amount of unit tests, then get code coverage metrics into the build. Set interim goals -- increase coverage by two percent within a week. And then increase it some more.
Code analysis
The build is running -- but how bad is your code? Run FX-Cop on every build. You're running FX-Cop? Then fix your problems. Identify common problems and fix them in batches. Update the list of exceptional terms (this is like adding new words to a spell check dictionary). You've done all that? Run further automated analysis. Fold n-depend into the build. Oh and before I go on... please, for the love of god, treat warnings as errors. Clean up that dirty code you're shovellin'.
JFK dressed as a US president
|
Continual peer review
You want to create a workplace where you understand and learn from each other's code, constantly. The trick is to make it non-confrontational. If it happens rarely, it's going to seem confrontational -- but once it happens routinely it will be an understood part of the workplace. Some places use code reviews prior to every checkin, some places use continual pair programming. Use what works best for you, but make sure code ends up being owned by the whole organisation not just the individuals.
Peer training
Teach each other. Discuss code, discuss business. Talk to each other. Say hello to each other in the mornings. Train each other. Organise lunch time brown bag sessions. Attend user groups. Talk at user groups. Be active in your community.
Keep yourself up to date
Don't let your skills stagnate. Don't stick to what you know -- put yourself outside your comfort zone as often as possible.
I'm not saying you should learn every shiny new technology you see -- but I am saying that you should take responsibility for your own continuous education. Moaning that your employer doesn't send you on courses is ridiculous.
Refactor!
Fix the little things. Fix them often. Improve method names. Improve variable names. Be consistent, be clear. Extract methods. Focus on those terrible long methods. Reduce cyclomatic complexity. Get a second opinion. Talk about your code. Little fixes add up.
Passion
Passion? Passion? What the hell does he mean 'Passion'?
It's not enough to do all this other stuff as well? I've got to give my heart and soul to the project too?
No -- you don't have to go too far with it. You don't have to take everything personally. But you've got to care. You've got to give a shit about the code you write and the people who use it. If you don't care about it, you're never going to enjoy it properly.
Yes, it's a frustrating job, where little details threaten to derail the entire project at every moment. Yes, you are surrounded by silly ass-hat clowns who don't understand a thing about what you are trying to achieve. Yes, it's tedious and gruelling and it makes your brain hurt. But you've got to care dammit. There's no shortcut on that one.
Read On...
Sat, 03 Jan 2009 08:46:10 GMT
Summary.
You're an idiot. Deal with it.
The longer version.
I've been pondering the chronic over-supply of stupidity, and I've come to a new conclusion.
Stupidity itself is not the problem. Abundant stupidity is inevitable. The problem is the people (like you, for instance) who don't even begin to suspect that they are stupid. People who insist they're God's gift to intellectual discourse. But in reality: as thick as whale blubber.
So here's a matrix to show four different types of people... the cross product of those who think they are smart (or dumb) and those who are actually smart (or dumb).
This matrix has four types of people. Stealing an idea from my usability-buddies i've assigned a 'persona' to each quadrant:
- Forest Gump: stupid, but he knows it.
- Homer Simpson: is actually dumb, but seems to think he's the cleverest guy alive.
- Columbo: is actually smart, but comes across as quite a dope.
- Mr Spock: smart, and knows exactly how smart he is.
Here's a pictorial version.
And here's my guess at how common (or rare) each of the four categories are.
(I started with the rule that only 20% of people could be called smart, and then assigned a breakdown after that.)
The chief lesson: lots of Homers, very little of everything else. The stupidity vortex is spreading. More on that later.
The goal, interestingly enough, is not to end up in the lower right (Spock) but in the lower left (Columbo).
Why would a smart person (a Spock) decide to put themselves in the third quadrant and become a Columbo? Because they're smart enough to realise that they're really stupid. Stupid for two reasons.
Two things make you stupid
There's two reasons that a smart person should realise they are still, essentially, stupid.
The obvious thing is that no matter how much you know, your knowledge is an insignificant dot compared with the sum total of what can be known. (It's even very small compared with the sum total that other humans currently know.)
But here's the real kicker: every idiot in the world knows at least one or two things you don't know.
I've gone all out and used Powerpoint to create a venn diagram (at right) to help illustrates this point.
Here we're comparing a genius with an idiot -- and the size of the circles indicates the relative size of their 'knowledge' or wisdom or intellect or some other hard to measure, but easy-to-chat-about concept.
Clearly the genius has greater brain points -- and indeed knows almost everything the idiot knows. But look out genius, because there's still a little slither of things the idiot knows that you don't know. And this is a humbling thought.
The idiot won't hesitate to grab onto those one or two tiny points and rub your nose in them mercilessly. Trust me on this: I've done it to smart people many times over.
So don't get too cocky there Spock. Chill out, Yoda. Pull your head in, Gandalf.
Stopped Clocks
To remain humble even in the face of blatant stupidity, never forget:
"Even a stopped clock is right twice a day."
Tattoo that on the back of your eyelids.
The real lesson
But the real lesson is this: if you think you're Spock, you're much more likely to actually be Homer Simpson.
Please, dear idiot reader, err on the side of safety and assume that, like me, you are a mental ass hat with much to learn. We'll all be better off.
Final word: How To Get Smart
One final word though, on a more positive note... it might be possible to actually become smart. Imagine that?
I haven't tried this personally, but according to 'Wetware refactorings' which quotes 'Pragmatic Thinking and Learning: Refactor Your Wetware' by Andy Hunt:
...in a rich environment with things to learn, observe, and interact with, you will grow plenty of new neurons and new connections between them...
Your working environment needs to be rich in sensory opportunities, or else it will literally cause brain damage.
Read On...
Fri, 02 Jan 2009 11:46:14 GMT
i've always been itching to tinker with microsoft robotics studio -- but i put it on my list of "things NOT to do" a long time ago. There's not enough time to play with every good thing in life.
But last Christmas i spent a bit of time on making fractals in logo, and learning F#, and drawing awesome robot pictures... so it's only fair that this christmas i'd crack out microsoft robotics studio and give it a tinker.
As a bonus, my nephews are around and I was hoping to help get them hooked on a life of computer programming.
first impression:
stupid roadblocks. I know this is an awesome base operating system to unify and enable all the robotics systems of the world... but my god, nothing is obvious. The "pit of success" idea seems to have overlooked these guys.
I like to jump in anywhere and hope that it makes sense. That didn't seem to be appropriate here. Jumping in anywhere lead to confusion.
So I swallowed my pride and headed to the first tutorial. That was utterly lame. So I moved to tutorial 2. Lame. There is no tutorial 3... no sure why, but the next in line is tutorial 4. I loaded that in visual studio, compiled and ran... okay... some potential here... something to sink my teeth into... but oh god, how about that confusing user interface from the team that UX forgot.
Quick reminder about User-Interfaces By Developers
Dear developers (and this includes me) -- please don't open up the windows forms designer, blow chunks wildly, and then publish it to the world.
Either get a usability expert to provide some nice feedback or, at the very least, see if your little sister can understand how to use it. Pure developer UI can be a terrible thing.
Now back to the task at hand.
Explain this to me... someone... please...
Variations on this 'dashboard' form are common in the tutorials. And it's very 'developer UI'. This form is fail.
Generally if you click anywhere on this form you get two responses: nothing, or an exception.
After a lot of experimentation I worked out that you have to click in the boxes in a particular order (that the UI doesn't give any clues about).
Your average programmer would be able to work this out quite easily if they were motivated. Fine. But don't even think about handing this to your little nephews.
After working out the right order, we went in to the code (we being me plus my brother in law Rick) and re-ordered the controls to make it more appropriate, and gave better feedback on errors. A two minute refactoring, seriously.
Now we found that, with meticulous clicking and typing, we could convince the articulated robot arm to move in whatever way we wanted. (Yay! We knocked the dominoes over!)
It was cool in a way that only your most-geeky segment of the audience could begin to comprehend. For example, I loved it. But the nephews: not so much.
I'm pretty sure it gave little more than a whiff of the real power of this platform. I've listened to podcasts where people rave about the concurrency and coordination runtime, and the way real industrial houses use this software to simulate, build and control their real-world robots. From where I am right now, it takes quite a bit of imagination to see those distant capabilities.
Some things I'd love to be able to do:
- click on an object in the simulation environment and thus have it 'selected' in the remote control. (or even less -- float over an object in the simulation and have its name as a tooltip)
- record a series of movements and replay them.
- use a
logo-like language for talking to these little robots. The powershell team could give great guidance on this. - move the cameras around. (I know I can work this out programmatically -- but it's a pretty basic thing I shouldn't need to be a programmer to achieve)
- Hit reset -- to get the scene back to how it was at the start.
Computer games are full of lessons. They give you clear goals that get progressively harder. What each 'simulation' needs is an obvious goal. The final goal for tutorial 50 might be: write an autonomous robot that can drive 100 kilometres through rough terrain, unassisted. Some goals from intermediate levels: tell a robot to move; teach a robot-mouse to solve a puzzle; use a vision sensor to shoot down a robot duck.
In the meantime, anyone know what would be a good robot to purchase? I'd like to get a real world robot, provided I can also tinker with it in robotics studio. Some of the things i'd like it to be able to do for me:
- Mowing the lawn, including trimming the edges.
- The shopping (everything from keeping track of supplies, to collecting the goods)
- Organising breakfast (and cleaning up afterward.)
- Noticing when the batteries are low on my phone (or ipod, or camera, etc.) and re-charging the items as needed.
- Hunting down and killing anyone who has ever annoyed me.
- Giving gifts to children once per year.
I imagine he'll look something like this -->
Read On...
Hey good looking!
click here to visit the secretGeek archives!
Go on... continue through to the archives
^Top
secretGeek .:dot Nuts about dot Net:.
The Utterly Thorough Guide To Awesome Application Compatibility on Windows 7.
