January 30th 2012 · Read More · No Comments
Sleep matters, a lot.
Sleeping properly, and knowing when to take breaks keeps down the errors you make and makes you more productive in the long run. When you’re tired you make mistakes, then you need to spend more time trying to fix your mistakes. Thus needing to work longer, and possibly sleeping less.
Proper breaks away from the computer refreshes you a lot more than browsing slashdot for a while.
The quality of sleep matters too. If you sleep on the floor or on a sofa in the lab, you’re not going to feel as rested as when sleeping in a quiet place where you feel secure and comfortable, like your own bed.
I think that people who try to power their way through their way the entire 48 hours are going to crash at some point, but before they crash they will make a lot of mistakes and bad decisions.
We spent about 22-24 hours out of the 48 having breaks, and that left us feeling well rested most of the time. This showed in the quality of the code that we produced, there were very few bugs present.
Concepts have to be interesting.
It’s pretty simple: if it doesn’t appeal to people, why would they want to play it? It nobody wants to play it, why are you spending time and effort making it?
KISS is the best rule ever.
Keep it simple, stupid. Advanced game concepts and add ons can wait. Focus on getting the basics sorted and make sure they’re interesting. Everything else is gravy.
This means that you have to figure out what the basic concepts are and that you have to prioritise. If you’re not clear on what you want to do, paper prototype.
The first evening of the global game jam, we never wrote a single line of code or made any art work. Instead, we spent some time setting up computers and getting to know each others better and trying to figure out each others strengths and weaknesses. We spent the main part of the evening figuring out the game concepts and what was important to us. We prioritised. We broke it down into small blocks. We put lots of stickies on a white board. When we were too tired, we went home and slept, coming back the morning after with fresh ideas and a sense of purpose. We were ready to start making a game.
Testing is important.
As soon as we had something that was vaguely resembling the game, we asked for people to come and test it. We watched their reactions, we listened to their comments, we argued with each others and we learned a lot. We could then incorporate that into the product.
And we kept having people testing. Thanks to that we knew what worked and what didn’t.
What we should have realised when we were doing it was that anything several of our testers was complaining about should have been prioritised. We didn’t prioritise a graphics complaint, and for a long time, the main feedback we got was that they didn’t like the graphics of a game entity. We should have changed that quickly and hopefully received more valuable feedback instead.
Communication is very important important.
Some of the teams I saw were not as good at communicating within the team. This showed in the end product. If you can’t agree within the team, take a break and figure out how to resolve your differences. If you can’t agree on directions, toss a coin. Don’t spend a lot of time pursuing different goals. It wastes time and wastes efforts that are better spent in one direction.
Keep people happy.
When I’m unhappy I’m not productive. Try to make everyone feel happy, appreciated and valued. Listen to their opinions and react to them. Encourage them to take breaks when they are tired and start to get grumpy.
Development process
Have one. Even if it’s just figuring out how you do things and how you communicate. Make sure you can define your board.
We had a big whiteboard where we kept track of what we wanted to do and who was doing what. It was easy to tell what was sorted and we got visual feedback as we went along. It might have been a bit agile and kanban inspired.
February 23rd 2011 · Read More · Comments(3)
Recently I needed to count the number of lines I had updated in a file compared to the original. After reading the man page for diff, playing around with it and thinking a bit I came up with the following command:
diff -y <original> <new> | grep -E "\||<|>" | wc -l
January 17th 2011 · Read More · No Comments
I’ve migrated the blog to a new host. Hopefully nothing is too broken. I might have lost some comment spam in the process, but that’s hardly a bad thing.
Also: Hi there spider!
September 12th 2010 · Read More · Comments(4)
I have a few hosts that I have enabled X-forwarding by default to. A while ago it suddenly started to take a very long time to connect and log in to the remote machines.
A bit of digging and googling made me realise that the culprit is in fact xauth, which didn’t make much sense to me at first. A bit more googling led me to this blog post. The post explains that in the 10.6.3 update changed the way that the local X display is referred to. Normally the first local display is reffered to as :0 but in the update Apple changed it to org.x:0. This is bad because xauth things the org.x is a domain name and tries to resolve it. The blog post suggests stripping out the org.x part and creating symlinks to the existing unix socket, but I don’t really like that solution because it creates extra symlinks.
I came up with a different, although possibly more ugly and hackish solution. It’s unlikely that x will become a topdomain in the near future, so performing the following in a terminal will make the DNS lookup succeed and always point to the local computer instead of timing out.
sudo echo "127.0.0.1 org.x" >> /etc/hosts
It’s important that there’s two greater then signs or you will overwrite the file instead of appending to it.
April 2nd 2010 · Read More · Comment(1)
Started a batch of Brewtec’s Bock. Making 21 litres instead of 23. Might have pitched the yeast slightly warm, thermometer tells me 30 degrees. Range of yeast is 18-28. I hope that’s not absolute min and max. Initial gravity is about 1037. Kit says it will be done at 1005.
Beer fridge is set to 19.5 degrees C.
I intend to use bulk priming at bottling and put most of it in 0.75l bottles if I brewed more I’d definitely switch to kegs.
August 16th 2009 · Read More · No Comments
I went to the Hamilton Gardens today and took some new photos. The light was pretty weird, a very bright day but still overcast.
Normally I’d say that overcast can be pretty good for photography, but I had problems with getting my motifs underexposed because the overcast sky was so bright.
It did however give me a very good lesson as to why the camera’s JPG with auto white balance can be crap compared to shooting pictures in raw.
May 16th 2009 · Read More · Comment(1)
I’ve spent this and the last weekend soldering together a bunch of circuitry that I can use to control my beer brewing process. I have built three calibrateable temperature sensors and two circuits to drive two different relays. There will then be connected to an Arduino that will be the brains.
The temerature sensors will be used to measure the temperature around my beer and the relays will be hooked up to the fridge that the beer fermentation will be taking place. The other relay will drive a lamp that I can use to heat the inside of the fridge.
I am planning on either making a webpage or an instructable showing exactly how it’s all done and set up some kind of github or sourceforge project with the code for the Arduino.
August 27th 2008 · Read More · No Comments
Multithreaded Python scripts doesn’t always respond to signals. This is because it is not defined which thread will receive the signal. Also, it seems that if a thread is sleeping the signal might be interrupted altogether. The sympton of this that I saw the most often was that the script deadlocked and had to be killed.
Activestate contains a more thorough discussion of this together with code for a signal handler that catches SIGINTS and aborts the process.
August 24th 2008 · Read More · No Comments
Sometimes they turn ripe and taste more of bananas. To me that’s a bad thing. I don’t really like bananas. I just eat them because they’re a decent snack between meals.
I figured that I would like them a lot more if someone would make bananas a bit crispier and make them taste like apples. Then I might actually enjoy eating bananas 
Maybe I should write an article about it and try to get it published in Waikato Times. Hopefully that would encourage a farmer to do investigate the chances of crossbreeding. If they succeed with creating a new fruit I think they should be called “bapples”.
July 7th 2008 · Read More · Comment(1)
There’s been a lot of questions what it is I am going now, and I’ve decided to try to write a bit about it.
The official title of my work is “Using machine learning to detect events in traffic flows”. What this actually means is a bit more complex
A traffic flow is basically the traffic which is generated by someone interacting with something on a network. It can be someone checking their email, browsing the web or using Bittorrent. It is the actual flow of information exchanged between the parties, not the actual data. Events is relatively self explanatory, they’re when something happens in a traffic flow. Detecting this accurately is actually very difficult, and there’s been a number of specialized methods developed to do this. The biggest problem with these methods seems to be that they’re bad at adapting or detecting all types of events.
Machine learning is that when you use specialized algorithms which are used to teach computers to wade through big amounts of data and either classify it or find out what’s interesting about it (This is just a part of what it actually contains, but for this explanation, it’s good enough.). What’s really important to keep in mind is that the computers are trained to work with the data and that they can also learn from experience.
What I will actually be doing is to combine all of this. I will look at traffic flows and then investigate the best ways machine learning can be used to detect these events. I will also attempt to classify different types of traffic, such as web browsing, emailing and so forth.
The research I’ll be conducting will be within the limits of an autonomous control system for networks which detects problems, comes up with possible solutions, simulates them and then implements the solutions. My work will hopefully only be used to detect problems And for those of you who wonder, I do not look at packet payload. In fact, I do not even have any payloads in my test data. That makes encryption useless to defend against this kind of classification