Scary but Fun
Scary but Fun
Our website runs on a pair of colo-ed web servers that get syncronised together by Application Center. Let's call the servers Andy and Betty (names have been changed to protect the innocent). Both sit behind a server iron that does load balancing.
Website updates get published to Andy via an automatic FTP service. That works fine, although it can be a little sluggish.
After the files appear on Andy, Application Center pops up and says 'Hey, time to copy some files and permissions over to Betty!'. And lo, the files are copied and Betty looks the same as Andy.
However, we have noticed recently that Betty has not been looking the same as Andy. Specifically, a number of zero-byte files have appeared on Betty, where their equivalent back on Andy are perfectly okay. Mostly these are GIFs and PDFs, but we have had a few important pages get zeroed out.
Unfortunately there's no evidence in the logs about why this is happening. It's not consistent, and we have not been able to replicate it. At the moment we're just letting the world see Andy, and Betty is invisible to the public. Andy is man enough for the job but we'd really like them both to work in partnership.
While we try to work out what's going on (with help from Microsoft), I've written a Windows service app that detects zero-length files. It monitors the file system and if any files become zero-length and stay that way for more than a few minutes, the administrators are alerted. It's a simple little app; if anyone wants to see it or have a copy, they're more than welcome. It's in C#.
If anyone can shed any light on our little problemette described above, we'll be very grateful.
I'm stunned. But this is what it said, so it must be true.
Which File Extension are You?
This is a word puzzle called a trackword. You have to find the 9-letter word hidden in the grid by tracking across each letter in turn up, down, across or diagonally. Can you figure it out? This one is fairly easy. Once you've figured out the trackword, see how many other words of 3 letters or more you can find using the same rules.
Anyway, I'm writing a component in C# that will generate a trackword grid from a dictionary, build a GIF of it and post it to my website each day. The component also has to work out all the possible words in the grid to allow users to check their solutions.
Problem 1) The grey background of the GIF always comes out in 16 colours or something. How can I get it to be high colour? I'm using this code to create it:
Bitmap newBitmap = new Bitmap(150,150,PixelFormat.Format64bppArgb);
Graphics g = Graphics.FromImage(newBitmap);
g.FillRectangle(new SolidBrush(Color.LightGray), new Rectangle(0,0,150,150));
// do some drawline and drawstring stuff
newBitmap.Save("trackword.gif", ImageFormat.Gif);
Problem 2) I've worked out an algorithm for scanning the grid and finding all the possible words in it, but it's not perfect. To be honest, it's all a bit Heath-Robinson. Does anyone know of any code libraries that do a similar kind of thing? I don't like re-inventing the wheel if I can avoid it.
Thanks all.
Just seen this post on David Findley's blog - a survey on the 10 reasons why software bugs occur. It's fun to do the survey but the main reason I'm referring to it is because it's a very succint encapsulation of the root causes of buggy software. Here's the list for quick reference:
10. Poor training. (coding, business analysis, tools, infrastructure etc…)
9. Laziness – the desire to use the easiest to implement solution.
8. Compromises made in req/design to meet delivery schedules.
7. Coding methodology failures such as bad or missing error handling.
6. Vague or incomplete requirements.
5. Misunderstanding of the requirements.
4. Poor design.
3. Misapplication of technology. (Components, products, techniques)
2. Lack of testing
1. Change: to requirements, infrastructure, tools etc., because it introduces the likelihood of all of the above to happen.
As David pointed out, each one leads to the next, all the way to #1.
But the story doesn't end there. As I pointed out in the title, Change causes bugs. What's the solution? Unfortunately the answer is not 'lock down requirements' or 'ignore new user demands'.
When you are developing an application you are providing a solution to a problem which may not be fully understood, clearly defined or unchanging. Does this mean you should ask everyone to stop doing business while you write the app? Of course not. The development team has to be able to continually adapt to changing requirements in a controlled manner, understanding the need for change, assessing the risks involved, determining the new priorities and plans and communicating these with the project team.
This is not an easy task.
Carl Franklin posts a hilariously furious response to some lazy blurb about how VB.Net programmers should be forced to convert to C#. I bet Carl had to wipe some spit off his monitor after that post!
Back in the days when men were men, women were women and packs of rabid C programmers mugged pale wimpy little VB3 hacks in dark alleys, there was a real difference between the languages. Nowadays it's just semantics. As one of the commenters points out, the MSIL comes out the same.
Me? I code in both. As a lifelong BASIC programmer, I'm obviously coding in C# at the moment - because I can. It's easy, no great shakes to move over. Don't forget to close your curly brackets.
I daresay I will be moving back to VB.Net before too long for reasons which will become apparent in the fullness of time.
Pat Helland, supported by Don Box and David Chappell, performed his own interpretation of American Pie at the end of TechEd Europe last week.
It has to be seen to be believed.
This is all in response to a Harvard Business Review article entitled 'IT Doesn't Matter' by Nicholas Carr. I'm sure that title is in no way designed to attract maximum attention to 27 pages of blurb which would have otherwise been largely ignored.
Bet Mr Carr didn't expect a response in the form of a plagiarised folk song. That never happened at the Debating Society.