"It's just a small site, how hard can it be?"

"I thought you could do it for me as a favour. It's not a complicated site."

"This would take me an afternoon, but I don't have time, can you do it for me?"

Have you ever heard these comments before? Have you heard ones that are similar? I've been hearing them a lot in the last few weeks and it's starting to get to me.

I have just had a chat with a mate who is also suffering this pain, and that conversation is what inspired me to write this, the first random rant in a while.

Let me start by saying that building software is hard. Building quality software is harder. I've been in the industry for 10 years now, and I can say with a certain level of confidence (and perhaps a little bit of authority) that it's harder than most people think -- particularly business users, clients and lots of family and friends.

Let me follow that on by saying that websites are software (no way!). That puts them in the "hard" basket. Every site, even if it's a static page with some simple content, comes with its own set of challenges -- and those challenges are rarely understood by anyone who hasn't experienced the pain of building software.

The point of this post it to give a little bit of exposure to some of these issues. I hope that this post gets read by those people who have plans to have some sort of software built but haven't really got a clue what's involved.

Requirement Issues

Let's be fair ... you don't know what you want. You think you do, but you really don't. You have an idea for something that will either make your life easier or "be really cool", but as far as actually thinking about how it would function ... ? You haven't done that at all.

Here lies the first of the big stumbling blocks. You want a website, because "everyone has a website these days" for almost everything. Started a new business? You must have a website! Released an album? You must have a website! Had a child? You must have a website! Never had a website? You must have a website!

Before you dive headlong into the quest to find the person to build the site for you, have a good long think about what it is you want that site to be. What is its purpose? What content is required? Will it be dynamic? Will it be static? Will it be data-driven and require a Content Management System? Do you want other people to submit content? Do you want to have the facility available for readers to add their own comments? Will it be product driven and need the ability for people to buy stuff directly from the site? Do you need it to work on all browsers? Does it require access via a mobile phone or hand-held gadget?

These questions need to be answered well before any design is even contemplated, let alone structure and technical architecture. Do yourself and your site development team a favour. Think long and hard about what you want, and while you're doing that, ponder what possible issues you might face. The more issues you think of now, the cheaper it will be to build the site that fits your needs. Not just that, but you'll reduce the "scope on a rope" which results in the blowout of timelines and budgets.

Design Issues

We're coming to the end of 2008 and yet people still don't realise that development is not the same as design. Ask yourself the question: if design is part of development, then why do people make a living out of website design? The answer is simple: It's a big job, and it's very hard to do it right. I'm a developer, and I feel that there are very few (if any) areas of development that I couldn't do well in (yes, I'm arrogant ;)), but I can tell you this for certain: I am not a designer. Dan will no doubt appreciate that comment

It's true, I am not a designer. I can not design websites. I can do the technical desing, the architecture and the implementation. I can not do the design. Creating the right design for a website isn't an easy thing to do. I can tell you when people get it right, and I can tell you when people get it wrong. I can't tell you why

So, again, do yourself a favour. Get a proper web designer with a great portfolio of projects and go through the ideas you have with them. They will end up providing you an interface which makes sense for what you're trying to do. Do not fall into the trap of assuming that this part of the process isn't important. Yes, up front the cost most appear higher, but in the long run you will not regret it.

Technical Issues

Stumbling block number 3 is the lack of understanding of the technical issues. It's no surprise though, considering that most people wanting sites are not technical in nature. While it's fine for a client to not have (or want) an understanding of the technical issues, it's certainly not fine for them to ignore the fact that they even exist. Sticking your head in the sand and saying things like "well you'll figure it out" or "isn't that what I'm paying you for" doesn't really cut the mustard, particularly when you haven't thought about what you want in the first place.

When building websites there are all kinds of technical hurdles to leap over. To name a few...

• Platform - I think most of the non-techie readers will have no clue of what I mean here. The platform is what the site runs on. That is, the operating system, the runtime, the software that supports it, etc.
• Cross-browser compatibility - The biggest issue in any Internet-facing website is cross-browser issues. Not all browsers were made equally. Each and every one has its own set of quirks, and the people responsible for building the interface to the site need to cater for all these quirks. If they don't, then they may alienate a subset of potential readers which would do damage to the site's potential traffic and income. DO NOT underestimate how painful this can be. Yes, there are tools out there which apparently take care of these issues for you, but let me tell you that most of the time they fail too. Be prepared for a great deal of work to go into making your site look and behave on the same on a variety of browsers. As a small side-note, some browsers actually behave differently on, say, Windows compared to how they would on, say, Mac OSX.
• Secure payments - Sounds easy right? "I just want the ability for people to enter credit card details and pay for stuff." Unfortunately it isn't that simple. You have all kinds of issues to worry about if you want that to happen directly in your site. You have to set up SSL, you have to arrange for a proper payment portal to site behind your site and handle the requests. You need to make sure your site is set up in such a way that any malicious users can not buy stuff without paying, nor have honest users' information compromised and shared. There are other options, such as PayPal and Amazon, but these facilities operate externally and won't appear "incorporated" in the site.
• Accessibility - You've done well if you already know what this is. In short, it refers to your sites ability to be read by people who are visually impaired who use devices such as screen readers. If you want your site to be fully accessible, then expect a great deal more effort to be involved. Your site needs to be structured in a special way and it needs to be fully compliant with a markup standard (such as HTML 4.0 Transitional).
• Hosting - This issue comes with a stack of other issues that most people don't even think about (sometimes even developers!). Do you have your own host? Do you have a shared host? Dedicated host? Do you need it in your own country? Do you need Windows or Linux? Do you need email facilities? Do you need SSL? Do you need a CDN? Choosing a location for your site is affected by so many things. For example, if you're looking for a fully secure site which keeps track of user details and sensitive information (such as credit cards) then a shared hosting solution is an EPIC FAIL. In case the reason isn't obvious I'll tell you. If you use a shared host, then the entire machine is only as secure as the weakest account. If another site, owned by someone else, is compromised then the attacker owns the box which contains YOUR sites as well.
• Database - This isn't just about which one to use. It's about how to use it. Databases are underestimated and often misunderstood. It's very easy to do databases wrong. This is a real kicker for those applications that are very database heavy. In particular, applications which require complex relationships and/or deep searching capabilities. If your application relies on an insanely speedy, distributed database or is search-heavy, you had best get yourself a DB guru ... and be prepared to pay for them! A recent example with some interested details was recently posted on StackOverflow, go have a read!
• Traffic - If you're aiming to build a site that isn't going to be used often or doesn't have a great deal of content, then this might not be so much of an issue. But if you have a site that is going to be bombarded with traffic, don't expect your first cut of your system to, er, cut it. I once heard a semi-famous man say "Everything is fast for small n", and he's dead right. In development and testing, your app will probably fly. But under load, with thousands of people hitting it at the same time, it may just keel over and die. Be prepared to face this problem in the development stage.
• Maintainability - I left this one last because it's a little verbose and somewhat random. So many things can affect the maintainability of the site. The main problem here though is that in general, the idea of maintenance after a site has been developed is far from anyone's thoughts. Maintenance is where you'll spend most of your cash long term. Minimising the potential issues during development really is key to making a site which isn't going to cost the earth to maintain or enhance. The most common cause of highly unmaintainable websites is "Little Johnny" (LJ). LJ is the bloke that someone knows through a friend of a friend, or through the family. He's the guy who "knows stuff about computers". Of course, that means that he can <sarcasm>build commercial websites that are flexible, secure, fast, extendible, easy to maintain and that WORK</sarcasm>. In all seriousness, you might know someone who knows something about computers, but if you're serious about your site, then get someone who knows what they're doing. You'll pay more in the long run for someone who doesn't. Either that, or take one of your employees, and put them through a course so that they can learn how it's done. To sum up, if you want to reduce the cost of maintenance there is a lot of work involved, and your developers need to know what they're doing. Be prepared for a lot of work in this area.

Testing Issues

Testing? What's that?

It's frightening that even in Enterprise software, testing is generally an afterthought. Recently I was fortunate enough to be part of a team where testing was a huge part of the development process. It was really good and the result was a seriously higher quality application.

Developers do not know how to test their own code properly. Sure, they can write unit tests, and they do some form of manual functional testing on a daily basis while they're building the software. This is not the same as having a full test plan and suite of tests to verify the quality of the application.

Do yourself a favour, spend some of your budget and get some testers in. They will put your application/site through its paces instead of your users!

Deployment Issues

Once you've worked with a development team, you'll become very familiar with the following phrase:

It works on my machine.

It's something that you'll hear constantly

The point here is that it is very common for things to work in the development environment, but end up breaking when deployed to a production environment. Deployment is another often overlooked area of the process. When it is considered, it's underestimated.

Be careful. Here be dragons. Before you get stuck, speak to someone who knows what they're doing.

Support Issues

So you've managed to ship your application. It's online, it's deployed and it's running. But something goes wrong. The site breaks every now and then. Users are having issues with the payment portal. People using Firefox on Mac OSX can't sign in. Reports are coming back with incorrect values.

Do you have a plan in place to handle these requests? Do you have a bug tracking system? Do you have a support team ready to handle requests? Have you kept any of the development team on board to help you with the support issues?

Generally, the answer to all of these questions is: no. My advice would be to make it a yes. Put a plan in place to help you with the teething issues once you've gone live. Trust me, there will be issues.

Conclusion

I hope that the target audience have a little more visibility of the issues that are faced when building websites (and software in general). I hope that they learn from it and take some of the advice and do proper preparation before undertaking a development project.

Finally, I really do hope that it stops some of you from coming out with the comments listed at the start of this post

As always, feedback and comments are welcomed and appreciated. Cheers!

The last time it happened I wasn't able to get any sites to respond. I ended up popping some manual DNS server entries into my router which I had archived in a "welcome" email that I had received when I first signed up for my Internet account. These worked well for a while, but eventually ended up going offline and so I had to look for another option.

Enter OpenDNS. A free DNS service with a stack of features that anyone can use. I'll go over a few of them.

First up is Content filtering. What a fab idea! Offsite content filtering that stops dodgey and unwanted stuff before it even hits your modem. OpenDNS supports content filtering in a couple of ways which makes it really easy to generally filter out particular sites and content.

The content filtering mechanism is quite extensive. You have the option of choosing a predefined "filtering level", each of which defines a set of site categories which will be filtered out for viewers on your network. The options go from Minimal, which simply blocks known phishing sites, through to High which covers everything from porn and illegal activities to video sharing sites.

There is also a Custom level which allows you to choose the categories that you want filtered. This is the long-hand version of the predefined levels mentioned above, which is great as it let's you pick and choose if you want finger-grained control.

Lastly, as far as filtering goes, you have the option of allowing or blocking sites as a hard rule. This is handy if you know that a particular site is getting caught in your filter but you know for sure that it's safe. This happens surprisingly often, so having a whitelist is very handy. Being able to block a stack of ad sites before they even hit your browser is also a winner, hence the blacklist feature is great too.

Thankfully OpenDNS supports IP address auto-update. Over time, you'll no doubt get different IP addresses from your ISP as your DHCP leases expire or when you reconnect your modem to your service. Given that OpenDNS needs to have some way of determining who you are, IP address really is the only way. So to help keep OpenDNS up-to-date with your current IP (and hence, keep applying your filtering rules), there is a client application that you can have running in your system tray which contacts the service periodically and makes sure that it has the latest IP. While this is a great idea it's a bit crap that you have to run a client application. It's a shame that they didn't decide to support the use of another dynamic addressing system such as DynDns.org (lots of modems have built-in support for updating services like DynDns automatically).

For those who like to make their services feel cosey, OpenDNS supports customisation of various bits of functionality. For example, you're able to change the logo picture (this is more of an interest to site admins). You can also modify messages that are displayed when sites are blocked for various reasons. For those of you on home networks, specifying more meaningful messages for those, shall we say, "less technical" family members will no doubt be beneficial in reducing the number of support calls.

Network shortcuts are another nifty feature. A network shortcut is essentially a bookmark which works across the entire network. All you have to do is specify a name for your shortcut, and the site that it redirects to, and you're done. Once the shortcut has been saved, all you have to do to get to the site is type in the name of the shortcut. When the DNS request is made, OpenDNS looks for any shortcuts by that name that exist in your list, and if found, it will redirect the user to the appropriate site. Groovey!

At first you don't believe it, but OpenDNS is surprisingly quick. I wouldn't say that I have conducted a huge set of performance tests and benchmarks, but I would say that it by far outperforms my ISP's DNS servers as far as responsivity is concerned. Not just that, but it works. I am yet to see a DNS lookup fail requiring me to retry.

The final redeeming feature of OpenDNS is that it's constantly updated and secure. Flaws in the DNS system, for example, have already been patched. This reduces the chances of you dealing with an insecure DNS server (such as the one sitting at your ISP) and ending up at a site that might be a little unsavoury.

To sum up, I really think OpenDNS is a great service. It's fast, feature-rich and very handy. For anyone with a family/kids or a need/desire to filter out some of the f**ked up content that lives on the web (such as this site ;)), this service is for you. Give it a spin!

This is an issue when dealing with third-party libraries that are not signed. Sometimes you'll be lucky enough to be dealing with vendor that is happy to provide a set of signed assemblies, other times you won't. If your scenario fits the latter (as a recent one did for my colleagues and I), you need to sign the assemblies yourself. Here's how.

Note: delay signing is not covered in this article.

Scenario 1 - Foo and Bar

Foo is the component that you're building which has to be signed.
Bar is the third-party component that you're forced to use that isn't.

Grab Bar.dll and project along with Foo.dll and project to see a source sample.

You'll notice Foo has a .snk which is used to sign Foo.dll. When you attempt to compile Foo you get the following error message:

Assembly generation failed -- Referenced assembly 'Bar' does not have a strong name

We need to sign Bar in order for Foo to compile.

Step 1 - Disassemble Bar

We need to open a command prompt which has the .NET framework binaries in the PATH environment variable. The easiest way to do this is to open a Visual Studio command prompt (which is usually under the "Visual Studio Tools" subfolder of "Visual Studio 200X" in your programs menu). Change directory so that you're in the folder which contains Bar.dll.

Use ildasm.exe to disassemble the file using the /all and /out, like so:

C:\Foo\bin> ildasm /all /out=Bar.il Bar.dll

The result of the command is a new file, Bar.il, which contains a dissassembled listing of Bar.dll.

Step 2 - Rebuild and Sign Bar

We can now use ilasm to reassemble Bar.il back into Bar.dll, but at the same time specify a strong-name key to use to sign the resulting assembly. We pass in the value Foo.snk to the /key switch on the command line, like so:

C:\Foo\bin> ilasm /dll /key=Foo.snk Bar.il

Microsoft (R) .NET Framework IL Assembler.  Version 2.0.50727.1434
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembling 'Bar.il'  to DLL --> 'Bar.dll'
Source file is ANSI

Assembled method Bar.Bar::get_SecretMessage
Assembled method Bar.Bar::.ctor
Creating PE file

Emitting classes:
Class 1:        Bar.Bar

Emitting fields and methods:
Global
Class 1 Methods: 2;
Resolving local member refs: 1 -> 1 defs, 0 refs, 0 unresolved

Emitting events and properties:
Global
Class 1 Props: 1;
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully

Bar.dll is now signed! All we have to do is reopen Foo's project, remove the reference to Bar.dll, re-add the reference to the new signed assembly and rebuild. Sorted!

Scenario 2 - Foo, Bar and Baz

Foo is the component that you're building which has to be signed.
Bar is the third-party component that you're forced to use that isn't.
Baz is another third-party component that is required in order for you to use Bar.

Grab Baz.dll and project, Bar.dll and project along with Foo.dll and project for a sample source.

When you attempt to build Foo you get the same error as you do in the previous scenario. Bear in mind that this time, both Bar.dll and Baz.dll need to be signed. So first of all, follow the steps in Scenario 1 for both Bar.dll and Baz.dll.

Done? OK. When you attempt to build Foo.dll after pointing the project at the new Bar.dll no compiler errors will be shown. Don't get too excited

When you attempt to use Foo.dll your world will come crashing down. The reason is because Bar.dll was originally built with a reference to an unsigned version of Baz.dll. Now that Baz.dll is signed we need to force Bar.dll to reference the signed version of Baz.dll.

Step 1 - Hack the Disassembled IL

Just like we did in the previous steps we need to disassemble the binary that we need to fix. This time, make sure you disassemble the new binary that you created in the previous step (this binary has been signed, and will contain the signature block for the strong name). Once Bar.il has been created using ildasm, open it up in a text editor.

Search for the reference to Baz -- this should be located a fair way down the file, somewhere near the top of the actual code listing, just after the comments. Here's what it looks like on my machine:

.assembly extern /*23000002*/ Baz
{
  .ver 1:0:0:0
}

This external assembly reference is missing the all-important public key token reference. Before we can add it, we need to know what the public key token is for Bar.dll. To determine this, we can use the sn.exe utility, like so:

C:\Foo\bin> sn -Tp Baz.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 3.5.21022.8
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key is
0024000004800000940000000602000000240000525341310004000001000100a59cd85e10658d
9229d54de16c69d0b53b31f60bb4404b86eb3b8804203aca9d65412a249dfb8e7b9869d09ce80b
0d9bdccd4943c0004c4e76b95fdcdbc6043765f51a1ee331fdd55ad25400d496808b792723fc76
dee74d3db67403572cddd530cadfa7fbdd974cef7700be93c00c81121d978a3398b07a9dc1077f
b331ca9c

Public key token is 2ed7bbec811020ec

Now we return to Bar.il and modify the assembly reference so that the public key token is specified. This is what it should look like after modification:

.assembly extern /*23000002*/ Baz
{
  .publickeytoken = (2E D7 BB EC 81 10 20 EC )
  .ver 1:0:0:0
}

Save your changes.

Step 2 - Reassemble Bar

This step is just a repeat of previous steps. We are again using ilasm to reassemble Bar.dll, but this time from the new "hacked" Bar.il file. We must use the exact same command line as we did previously, and we still need to specify the Foo.snk for signing the assembly. To save you having to scroll up, here it is again:

C:\Foo\bin> ilasm /dll /key=Foo.snk Bar.il

Microsoft (R) .NET Framework IL Assembler.  Version 2.0.50727.1434
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembling 'Bar.il'  to DLL --> 'Bar.dll'
Source file is ANSI

Assembled method Bar.Bar::get_SecretMessage
Assembled method Bar.Bar::.ctor
Creating PE file

Emitting classes:
Class 1:        Bar.Bar

Emitting fields and methods:
Global
Class 1 Fields: 1;      Methods: 2;
Resolving local member refs: 3 -> 3 defs, 0 refs, 0 unresolved

Emitting events and properties:
Global
Class 1 Props: 1;
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully

Open up Foo's project, remove and re-add the reference to Bar.dll, making sure you point to the new version that you just created. Foo.dll will not only build, but this time it will run!

Disclaimer

"Hacking" third-party binaries in this manner may breach the license agreement of those binaries. Please make sure that you are not breaking the license agreement before adopting this technique.

I hope this helps!

UAC has been a nagging frustration for a lot of Vista users, and has also been a joke to the Apple fans as well:

Yeah, I laughed too.

But I didn't really give UAC any credit. I didn't think about why it was there, all I thought was that MS were being stupid. That was until a couple of days ago when I was thinking about it (don't ask me why ).

After deliberating on it for a day or so, trying to come up with the motivation behind it, this landed in my RSS feed reader and made it clear. MS are taking a hit in the hope that devs will sort their shit out!

Windows users have had a long history of being administrators of their own machines by default. In general, most users do not login using an account with low levels of privileges. In Windows it has been too much of a pain in the butt to get anything done if you don't. Is that the fault of MS and Windows? Yes it is, but it's not their fault alone.

Looking back through history, developers who write software for Windows haven't really been particularly brilliant when it comes to being mindful of security. This is something that needs to change. Some really basic applications, office applications, editors and even games have require administrator privileges to run. It's no wonder that everyone decides to give themselves an admin account. Why would you want to face constant issues with security when all the things you're trying to use need the elevated access?

The fault lies with the developers. They need to get into the habit of writing software that doesn't require elevated privileges. UAC is part of MS's effort to force the plebian developers to sort their shit out. By the looks of it, it's beginning to work. It's a brave move on MS's part, as pissing off users to force developers to be mindful of security is not necessarily the smartest thing to do. Vista has enough pitfalls as it is without having something that's designed to being annoying popping up in your face all the time.

Let's hope the trend continues. In a perfect world it'd be fine to have something like UAC running all the time, so long as it doesn't appear all the time!

Note for those who care: sorry for the poorly written post I couldn't be bothered fixing it up, it's late and it's time for bed!

I've requested a partial restore of content from our web host so that I don't have to go through the pain of adding all the content again. Hopefully it'll be back up soon.

I'm not happy, but I only have myself to blame. Whatever you do, unless you're grabbing from the official WordPress plugin repo, make sure you check out the contents of the plugin before you attempt to install it!

I have bitched in the past about how activation is a pain in the neck. But that example is nothing like what 2K Games have recently inflicted on the buyers of their latest creation, Bioshock. Rather than throw a few links to a bzillion blog and forum posts that have covered it already, let me just give you the short version:

1. Bioshock comes with SecuROM.
2. It requires online activation before it can be played.
3. It can only be activated twice.

On the surface this might not sound so bad, but when you think about it a little deeper it becomes obvious why this is such a pain in the arse.

SecuROM has a bit of a reputation amongst gamers, and not a good one at that. Most people who fork out the dollar to purchase a game don't want to be harassed afterwards. SecureROM does a good job of exactly that - harasssing. It usually requires you to insert the CD/DVD of the title while you play it. Again, this isn't a biggie for most people. But for a lot of gamers, changing CDs and DVDs constantly is annoying. I'd go as far as to say that it shits them up the wall! (yup, that one's for you, Vorlath, if you're reading ). If you buy the game legally, and you install the game legally, you should be allowed to play it legally without having to muck around with the discs.

Activation of games is fairly commonplace these days, but I don't think that's a good enough reason to enforce it on the buyer. In the case of Bioshock, the SecuROM activation does some sort of hashing of your hardware and operating system information before passing it to the Mothership for archiving. If you install it on another machine, the process happens again. Each time your hardware or operating system changes, you end up with a new "fingerprint". According to 2K Games, you're allowed two of these "fingerprints" against a given serial number and that's it. Do you think that's reasonable?

Before giving your answer, make sure you consider all the possible scenarios that might result in the need for reinstallation. Such as ...

• ... Windows biting the dust due to malware.
• ... hardware biting the dust for any reason.
• ... the need to put the game on a different machine which has higher specifications and hence can provide a more enjoyable gaming experience.
• ... the game refusing to run on a certain version of Windows (cough Vista cough).

There are probably more reasons as well.

2K Games are saying that it's possible to uninstall the game before reinstalling on another machine and everything will continue to work fine. That's all well and good so long as you can uninstall the game. What happens if your machine is fried? Fat chance of uninstalling a game from a hard disk that burnt to a cinder. Good luck removing software from a machine that's been trashed by some nast virus. If any of the above does happen to you, then you're in for a rough ride convincing the support team to allow you to reinstall past your 2-installation limit.

I'm one of those people who frequently rebuilds their machine. When I do, I don't uninstall every bit of software before wiping and starting again. Usually the disks are repartitioned and the OS is reinstalled. I don't think twice about it. I don't think I'm the only one who would end up suffering because I forgot to uninstall a game that I know I have the original discs for.

Let's consider the long term issues that might arise from a mechansim like this. What happens when 2K decide that they've had enough of supporting Bioshock, and users require help with their activation? Simple: the users are left high and dry.

If you think buying a copy of the game through Steam is going circumvent this level of protection, think again. Steam not only has its own security in place to prevent piracy, but it also delivers the SecuROM anti-piracy gizmos that you get in the boxed version. So you're not safe.

There are already reports of people in strife due to this stupid level of control. Legal users of the software are unable to play the game because they've been forced to reinstall operating systems, or try on different machines because of the hardware requirements of the game. This is just crap. If you buy the software, it shouldn't come with a stack of crap which prevents you from being able to use whenever and wherever you want.

What makes this worse is that those people who do pirate software do not have to put up with this kind of crap! They download, install and play. That's it. No tales of woe. No activation issues. No concern of not being able to reinstall on a beefier machine. Nothing. The pirate is the winner, not the legal consumer.

I take my hat off to 2K for being monumentally stupid. You've tarnished an arguably amazing game with your stupid anti-piracy antics. You've also managed to piss off half of the game playing population...

.. and that's before we take into account the widescreen issue.

Edit: Have a read of this, this and this if you want to see what other people are saying.

This is quite an interesting issue. Digg are obviously in a position where they have to remove anything that may be considered an infringment of copyright, otherwise they could be subject to hefty lawsuits which could result in the site being closed (have a read of this for a bit more information), but by the same token it almost goes against their whole business idea - sharing information that people want to have shared in a democratic fashion.

At the end of the day, the encryption key is just a bunch of numbers, and most people have a problem with the idea that a bunch of numbers can be patented/copyrighted. I have to say that I agree with them. A number is a number, it exists in so many forms, and can have so many meanings. Trying to prevent people from posting these numbers is a waste of time. There are some smart people out there using some pretty funny and clever ways to post the number without actually stating that the number is the encryption key - which is perfectly legal.

Regardless of the politics, the cat is out of the bag. And from this point on, the 'Net community will no doubt be pushing to spread this number as far and as wide as possible.

What are your thoughts on this?

Edit: Kaz just sent me this awesome link. I wonder if they'd have the power to rip the shirt off your back?!

Edit 2: So, the masses have been heard! Digg has changed its tune and will no longer be attempting to stop said key being shared. Hats off to them for taking a stance. The thing is, whether they try to stop it or not, the encryption key will not be removed from the web - it's out there, and people won't let it be brushed under the carpet.

Edit 3: Couldn't resist posting this, it's bloody awesome (I'm talking about the pic).

I have no reason to find his claims outrageous, since he's quite clearly experienced in this area (he was 15 when he cracked CSS after all), so it looks like Apple have got themselves an issue to deal with. It'll be interesting to see if they take steps to stop him and his new DoubleTwist venture from taking off, or releasing any information/software pertaining to the crack.

Check out this SMH article for a bit more info.

So this begs the question: Is this going to be a tool which allows hackers to get acceess to bugs in software a heck of a lot quicker? I believe so. Is that a bad thing? No, I don't think so. In fact, it'll teach developers (the hard way) that they need to be aware of security issues well before they release the code - which can only be a good thing as it should have a positive affect on the software.

As a small side note, there can also be some embarrassing snippets revealed which will make the big names cringe. So, maybe this will also teach developers to be a little more professional!

The latest one that fired up a bit of thought was his post on guarding against SQL injection attacks. The information posted very handy, and is something that I would assume most web developers already know, but it made me wonder how many devs out there are actually aware of these kinds of issues while they're building their applications.

I starting hacking code together from a young age, and I've written my fair share of code that I hope to God never made it onto the web I'd like to think that over the time that I've spent reading, writing and working I've gained a pretty good coverage of the code security issues that are faced when building all kinds of applications - though I'm sure I have a stack more to learn! One thing struck me though, and that was that almost none of this stuff was covered during my course of formal study at University.

I transferred to different Unis during my time as a student, and out of the 3 that I went to, none of them had any form of code security as part of the core syllabus. Sure, there were special subjects that you could take which focussed on things such as this, including SQL injection, buffer overflows, etc, but you actually had to choose the subject out of a stack of others to get a good amount of exposure to the principles.

As time goes by, it becomes harder and harder for the developer to get themselves into trouble when writing code due to the nature of the languages and the support that you get via the accompanying frameworks - but we do manage to find new and startling ways of creating holes in our softy that the malicious and crafty can exploit.

So I do think that learning at least the basics of code security (particularly in web-based environments) is something that every developer should do. Sure, if you're using C# you might not have to worry about buffer overflows. If you're not using an SQL back-end, you won't have to worry about SQL injection. Regardless of the application and language, there are always different ways in which you can slip up. Coverage should be mandatory in courses at any formal education centre so that budding developers are aware of those issues before they hit the streets. To me, this is as obvious as having English and Maths as mandatory subjects during school if you're going to work as a coder!