Wednesday, October 6, 2010

Why Google's Go is a Bore

Why Google';s Go is a Bore

Great critic of Google's go language.

Monday, September 20, 2010

Subjective technical decisions

Saw an interesting discussion today on what points to cover when evaluating what software language to use. I threw a few points in and it was pointed out that half of them were very subjective to measure. How would one get a team to agree on such points?

This got my brain ticking as to all the subjective choices programmers make every day and the effects it has on others. We adopt 'standards' within a team to try and keep some sanity in it all. Coding standards is the most familiar to avoid future arguments about where a brace should be. And coding standards an a good example because they're defining all the small things. I'd love to see a coding standard that states: "Write tests first".

We argue over decisions that don't have a large impact either way. It's very easy for me to say Java is annoying and I'd rather C#. But with very little experience in either language it'd be hard for me to defend that view against an experienced Java or C# developer who disagrees. Faced with such an argument my first instinct would be to dig in my heels and fight it out. But I have to suppress that feeling because I know in the end I could be productive in either language. And if the people I'm working with would be happier with one over another then that will add to our productivity too. There is a very strong human element in this decision that cannot be separated from all the technical and objective considerations.

I think I'll come back and re-read this post next time I get drawn into a git vs mercurial debate.

Tuesday, July 27, 2010

Introduction to Agile Development

I'm doing a presentation for the Sydney PHP group

As a sneak peak you can see my presentation as I write it

Tuesday, June 1, 2010

App stores are good for games

By now I think most gamers have bought something from an App-store. Steam, Xbox live Marketplace, iTunes or whatever.

Furthermore I think a lot of people have bought games from places like Apple's app-store but do not consider themselves gamers. So app stores are all the rage now and with Steam now available on the mac it becomes the de-facto PC place to buy games. proprietary platforms all will come with their own. It's seen a boom in independent and low budget games going through a huge surge in market that hasn't been seen since the shareware days.

But even more so for games than other software. Look at the statistics from apple's apps and you find games are number 2 in size. Second only to books which may get kicked out now apple has their own iReader system. So all these app stores regardless of platform or format are a boon for games.

But why games? Honestly I'd love to know myself. There's something about open source that has made it difficult for games to get traction but hasn't been a problem for lots of other software. So this paid model allows lots of wanna-be-game-developers to give it a try with minimal investment and risks. Combine that with the affordable luxury of buying a game for a few dollars instead of over a hundred and you have a thriving marketplace. And good on them! I look forward to seeing where this goes.

Monday, May 31, 2010

Are mocks/fakes reusuable?

Programming 101 states:
Don't copy and paste code. If you find yourself doing something repetitive then do it right so you can reuse the same code. Functions, classes and even separate files all serve this end.

Now that I'm writing tests all the time I often find myself creating Mocks. Mocks are where you tell code to use a pretend version of some functionality instead of the real one. It could be because the real one does something you don't want in your tests (writes files, reads a database) or it could be that you've got some messy legacy code you can't to pull into your tests (yet). There's other reasons too but you get the idea.

So if I make a Mock version of a class it makes sense to try and share that with everyone else that might be trying to test with that same class. Or does it?

That assumption has some serious flaws that I'm only now starting to understand. And here's a few:

Behaviour you need to test may be completely different to the next guy

So I might be doing a mock file reader. And I might just want to send it some text just to get my code moving and doing stuff. But the next guy might be dealing with something far more critical and wants to simulate all the error conditions of a file being missing, failing to read, failing part way through a read, etc etc.

So if we're both developing using the same mock and re-examine my code in a few weeks I'm going to find this horribly complex tool of which I'm only using the most simple part there of. Now no doubt there's some great work in this complex mock and it may be very useful for future testing work. But for my little class that just wants to read some text it's complete overkill and potentially makes my tests more complicated to understand than they need to be.

All is not lost at this point. I could use inheritance to have my simple mock a parent of the advanced mock and break things down that way. But it's possibly I could very quickly write a brand new mock and ignore the advanced one in shared code. Since my mock may be no more than a handful of lines of code that may be the appropriate approach. To create a mock that is not shared with all the other tests.

You may be writing a complex fake as a library interface

Now even though it's complex it's still going to be limited and focused to what areas your code needs to be tested for. If it's shared with another project/executable that needs to talk to the same library there may be very little overlap. Again this can lend to an overly complex interface. It can get worse if your code is dealing with the 2.2 library and the other is still using the 1.8 library.

But of course if there is significant overlap on complex interaction then it makes perfect sense to share that code. So there's no hard and fast rules here.

You're mocking out legacy code

For me this is a common reason to mock. But may prove to be best reason not to share mocks. Essentially you need a long term goal of not mocking this code. It may not always work out. If the legacy code in question never changes then it may never end up being something you can pull into tests.

So since the long term goal is to remove the need for mocks you're only encouraging tests to keep using the mocks by sharing them. If a mock is already a complex suite of interactions and fake behaviour and you need to add some new behaviour it's not going to occur to you that it may be easier to use the real production code. The mock will continue to grow and be implemented long after the production code it's mocking has changed and its true usefulness has expired.

So after all this I'm still learning how to make mocks. Writing my own at least seems pretty quick and easy even without a mocking framework like gmock or cmock. But it's been a hard and slow lesson to learn that I shouldn't be aiming to put all this work into a kind of mock library.

Friday, May 21, 2010

Just one more X

What is it about human psychology that makes this such an effective way to keep people paying attention. It's the most obvious in games. There's always 3 or more short term goals you're aiming towards. Just this one fight. Just until the next save point. Just until I get 10 of this item.

It works for other things. Tasks at work (go on, admit it!). Novels with short chapters.

Is it possible to transfer this fantastic power to other things in life? Cleaning the house (just dust one more cupboard). Exercise (just one more lap). Often not. Why is this?

The human brain is a stupid but fascinating thing

Friday, May 14, 2010

The Code Dump - Stop Apologizing for Your Code

The Code Dump - Stop Apologizing for Your Code

Heh heh... code dump... I think I'll have to return and read some more there.

Tuesday, April 27, 2010

Monday, April 19, 2010

As journalism turns cheap

Cheap journalist turn to the "social media" for stories

ABC The Drum Unleashed - Stand by your tweets

Thursday, April 15, 2010

A brief history of Javascript

Javascript is the ugly duckling that is now ruling the internet. It's now a fully grown ugly arse duck! But you'll respect it because it got a lot right where corporations have failed.

Back in 1996 I heard how Netscape was coming out with a new version 2.0 that would include Javascript. Apparently in a deal with Sun Microsystems they renamed it from Livescript and it would allow programming to be embedded into HTML and run in the browser instead of on the server.

At this time Netscape defined the web. If you browsed webpages you used netscape. Sure it crashed a lot. Yes it ran out of memory when some punk decided a page with 12 frames would be cool. But if you used anything else you were missing out on the full glory of the web. So when Netscape said they were doing something cool for the internet you listened with equal interest, excitement and doubt.

Sounded like a toy. Netscape already messed up websites with the damn <BLINK> tag. Sure you could have some nice effects like a live clock or a image changing on a timer. But they'd just be gimmicks that no one would care about in time. Java would let us all write proper applications for browsers. How wrong we were...

The next 5 years was a mess. Java proved to be a dog. Never lived up to it's promise as it ate up memory and cpu like a glutton and never did anything fantastic. Sure you can get some nice Java programs no but in the late '90s there was two camps. Newly trained Java engineers getting high salaries from companies who believed the shit Sun was putting out promoting the language like the second coming. And people like me waiting for it to die in a fire because it was frankly crap.

And in that time where was Javascript? It was a toy. Used more by adverts trying to get in your face than any serious programmer. Microsoft's IE and it's half arsed 'jscript' as well as Netscape's own sporadic support for Javascript made it useless for any serious programming. There was nothing you could do to get it to run consistently across browsers.

Then over the last decade a push for web standards finally got a hold. The DOM interface became a standard and there was something javascript programmers could latch onto. Suddenly you could manipulate the page in real time in a way that worked across all modern browsers. It was taken more seriously but still didn't get much traction. Until some smart people realised you could use it to make asynchronous requests.

Ajax was a word thrown around for a while. It took some digging to find out what it meant. And even then it wasn't clear why it was useful. Then like an explosion on the internet it all became clear in one app. It was 2005 and the internet changed thanks to Google Maps.

Rarely does one website change the entire direction of internet growth and development. Suddenly everyone wanted Ajax style programming and that meant they had to learn Javascript. With that one hit it became clear you could now write applications not just websites.

Now it's taken for granted. If you try and create an interactive website without the application style interfaces Javascript can bring you'll be considered slow and clunky. Thanks to browser improvements Javascript is running faster than ever and can be more secure than flash. Javascript is running on mobile phones! To think it used to crash my computer 10 years ago.

Tuesday, April 13, 2010

Move over Java, I have fallen in love with JavaScript

Move over Java, I have fallen in love with JavaScript

Or as I would say: Move over strictly typed languages with slow compilers. But that doesn't have the same ring to it.

Tuesday, April 6, 2010

C++ sucks part two

You like speed? C++ will not get any faster

Because C++ support for multi-threading is lackluster. You've pretty much got to roll your own carefully constructed tools to avoid even the most common mistakes multi-threading can introduce.

"What about C++0x?" I hear you say. Screw that! Sure a lot of the stuff being proposed is a huge improvement. But it's been sitting around since 98. When am I going to see this in a compiler? When can I use it? I'm slowly dying here as processors get more and more cores.

To write a program in C++ today is to write code that will never run faster. Or will probably crash trying.

You like speed? C++ build times will feel like riding the bus

Builds are sooo slow. While trivial programs can build from scratch in seconds. Typical programs can take minutes to build from scratch. Complex programs can take so long to build it's usually farmed off to servers to do a 'nightly build'.

Let's do some math. Assume a program takes 2 minutes to build and maybe due to crappy makefile handling the programmer does 10 clean rebuilds a day (on average). If programmer is paid $40 an hour then he's paid about $300 a year just to run "make".

You like clean code? Good luck because header files suck

Why in C++ do we have to define all our class functions twice? Because if we try and inline them we just make the builds take forever. Every change to a header file can trigger scores of files to rebuild. If you've got a key file like a render it can chain hundreds of files to rebuild just from adding a comment.

So we carefully construct our header files. Fill them with forward declarations and carefully define our class interfaces in the hope we wont ever have to touch the header file again.

But of course interfaces change all the time. We're constantly adjusting things and kicking off painfully slow builds. Or in a rush to get things working including other header files only to chain up even more slow builds in the future.

But frankly we don't even want header files. A computer could figure out the interfaces for a class. But why doesn't the compiler do this for us in C++? It's just a dumb language that wants you to hand hold it through the build process.

Thursday, April 1, 2010

I love a good car crash

Internet's not special, says communications minister

The screech of tires. The smashing glass.

Great. Now I have to be certified.

Thanks to you bastards who went out to become certified scrum/xp/agile dicks. Do I need to go so far as putting CSP after my name?

Wednesday, March 31, 2010

C++ sucks part one

This is going to be too much to fit in one post. So lets start with the most provocative.

I'm over Constructors and Deconstructors

It's such a staple of OOP and yet I could seriously do without them now. If you're like me you learned these are great places to create/delete required objects, open/close files and all that stuff. But it just causes trouble.

Here's a typical example:

anotherObject = new AnotherObject();
fileHandle = open("configfile.xml");
delete anotherObject;

Great! What could be wrong with that? We'll there's two things.

1. You want to customise things in a child class
Ideally you shouldn't need to mess with the parent. Maybe due to some rules on shared code you can't change the parent (easily). But if you want anotherObject to be CustomObject and use a different filename you end up with this crap:

MyObjectChild() : MyObject()
delete anotherObject;
anotherObject = new CustomObject();
fileHandle = open("myfile.xml");

Ugh. It's terrible! You'd never do this on a normal 'virtual' function. You'd just not call the parent. But with a constructor and deconstructor you don't have a choice.

2. You're running unit tests
Don't tell me you're not writing tests! But you don't want the object opening a file. That means you have to mess with a file just to run a test case. And perhaps CustomObject does stuff you don't want too. But you can't change it to never construct. Both will happen no matter what you try and do with a child class. So you're in the shit now.

So what can you do?
I'm half tempted to replace my constructors with a macro (except they're evil) as they are all starting to look like this:

MyObject(AnotherObject * _anotherObject, int _fileHandle) :

There's times when the construction order wont let you do that. But then you have to pass in a factory object and that can open a whole new can of worms.

Most of these problems are common to OO languages. But it's just one reason why C++ sucks.

Saturday, March 27, 2010

I'm sick of ret-cons

Blah blah Han shot first blah blah.

This was brought to my attention yesterday!

Like WTF!? The ending was pretty vague anyway. You get to the surface with things blowing up. Cut to music. Why is there even a need to change to and re-capture?

Why is there this growing trend of writers going back and reworking their story? It's not like there's a Homer's Odyssey (revised edition). I'm sick of it. Let it sit. Write a NEW story.

Thursday, March 25, 2010

Embrace change or fail and wonder why you wasted your time

Ok so I mentioned how I've been getting my head around TDD and Agile recently. I'm kinda late to the game since I only discovered it 2 years ago with a presentation by Uncle Bob in Chicago. So it's taken a lot of reading and talking to get to the point where I am now. But I'm also carefully watching trials others are doing and making notes about those who succeed and those who fail.

So time to talk about the interesting one. The failures. Let's break them down to some common archetypes.

I'll keep coding the same way and make some token effort with planning cards.

Yeah you suck. You've got to change your ways! The order you do things isn't going to be the order you always did it. You've got to talk to the customer/designer/whatever and let them talk about what's most important. That's your new order! Don't spend for ever building some backend database bullshit. You may not even need it by the end. The whole design may change and become something unrecognisable. You're building yourself waste. Stop wasting time and money! That's the customer's job.

Waaah! TDD is hard! Why can't I just write my code. This is taking too long.

Yes it's hard. Especially if you've never done it before. So is programming. Just deal with it! You'll get better just like you've gotten better at every other programming thing you've had to learn. At least I hope you get better, otherwise is this the right job for you? And don't kind yourself you're writing some trivial bit that doesn't need tests. All big systems started as a small trivial system. You want to be able to change that big system with confidence right? Then write tests. Unless you're stuck for an hour trying to figure out how to test it then you've got no real excuse.

LOL. We're agile. Except for the TDD part.

No you're not! That's the most important part! Having to deal with changes all the time is not what makes you "agile".

Screw all this shit. I've been doing this for years! Don't tell me how to do my job.

Screw you! Everything can be done better. Everyone can learn. There is no such thing as perfection and you're just being an arrogant prick by even suggesting you are. I'm the only perfect one!

Wednesday, March 24, 2010

Should video games be addictive?

Now keep in mind I don't think games are addictive like drugs are. That's a rant for another time perhaps. But they are designed to keep you playing and playing and playing. Now for most people this is not a problem. You choose when to play and when not too. It's something you enjoy in moderation.

But some weak minded fools will ignore their significant other, stop showing up to work (or whatever) and allow personal hygiene to lapse.

Now you have never done that. I have never done that. But perhaps like me you've played a game just a little bit more. Just one more level. Just one more fight. Just let me hand in this gopher. Next thing you know the morning sun is streaming in the window. What happened?

You just had a damn good time! That's what happened. Stop freaking out. We've done it with that extended edition of Lord of the Rings. We've done it with a good novel and short chapters (just one more!) And we've done it drinking too much with friends. Get over it. Enjoy it. And wear sunglasses to work/school!

Will games get more additive? I sure hope so! I want games to get better. Games have been pretty good for a long time. If anything they're less addictive because it's easier to get a short burst of play out of them. People just don't have that much time to spend.

Tuesday, March 23, 2010

Stephen Conroy is not Satan

That statement is probably getting two types of reactions.

a) Who is Stephen Conroy? Well if you live in Australia then all your internets belong to him. But otherwise you may as well stop reading.

b) He is too! Okay you're the ones I want to talk to. You're wrong and you're wasting your time getting upset about Internet censorship.

Let me lay out the facts as I see them (read: opinion and opinion cannot be wrong no matter how much you disagree).

He's not evil he's just stupid
There's nothing really wrong with that. Lots of politicians are stupid. Some of the best have been morons! I'm very fond of the saying "Never assume malice that which can be adequately explained by stupidity" so I'm applying it here. He thinks he's doing a great service to Australia. Finally we'll be protected from all that nasty stuff that we were not supposed to be seeing anyway. Finally the internet has reached maturity where such things are possible. Or at least that's his thinking. But there's no point making personal attacks while the other side are no better.

The plan is doomed anyway
So you may as well let it play out. If it gets implemented several things will happen:
  1. Telstra will increase charges by $2 a month
  2. Important people will find their favourite porn site blocked
  3. Some insignificant but controversial (euthanasia? people smuggling?) site will be blocked and cause an uproar in the papers
  4. Polling will show great disapproval with the plan (now that the public knows what it really means to them)
All this may happen within days of the filter being put in place. And like other things the government of the day will pull out the system before the opposition can make it a policy and win some votes.

So don't worry about it. It'll all fall apart like every other attempt to "control" the internet. Australian governments don't have the conviction of China or Iran.

A brief introduction

And then I'll get into my first rant.

I'm some guy who thinks about stuff. Stuff you probably don't care about but I'm going to tell you anyway! Now I don't think I'm going to cure cancer or create world peace but it'd be nice if I could make the world a little better. Stuff I'd like to talk about will focus on:

I've always been a game player and am fascinated in how one designs a game. Yes it's mostly computer games these days and even then it's mostly consumed by World of Warcraft.
Shut-up you in the back! We all have our vices and I'll avoid sniggering at your hentai collection if you leave my level 80 mage alone.

Only 2 years ago I was introduced to this weird concept of Test Driven Development and the broader concept of Agile. Programming has been part of my life since I was eight. When I haven't been doing it professionally I've found myself doing it more in my free time. So it's nice that after 20+ years to suddenly learn something very new.

To me you are all young whipper-snappers that don't know a good thing when you've got it. Yes I've been lectured by people who used the internet back when you had to use computers with out screens (or whatever they called them back then). So I'm in turn going to lecture you about the time when the web was young. And why it's such a horrible mess now that fills your inbox with spam. And why I love it and would have it no other way.