One person's opinion on funding NZ internet industry development So, I went to a session on Internet Peering at foocamp, and I heard John Houlker from NZTE talk about peering and “other industry development ideas”. And I ended up writing this little piece of reactionary spit: What really disturbed me was a dude from New Zealand Trade and Enterprise talking about getting around this by subsidising internet start-ups. First of all he dismissed as nonsense the idea that "
The government presence at baacamp was impressive - two ministers attended, each of whom were not only giving talks, but listening to the feedback they were being given, and - dare I say it - engaging in thoughtful interchange on topics. I was highly impressed to hear Judith Tizard’s idea on what official information government should release - speaking happily of opening everything not restricted by the privacy act as raw feeds, even if the departments involved have strong opinions to the contrary.
On the registration form where it asked, “describe yourself in three words/phrases”, I was “Lost for words”. The other questions were, “name three people that you think should have been here, and their e-mail addresses” and “what would you bring back from the future?” For a technical conference, that the sample (of about 2) forms I looked at both said “World Peace” was a cool little sample of the vibe.
Alright, off to Kiwi Foo Camp (baacamp), which is being held in a ‘secret’ location north of Bombay. I am taking three talk topics along - one on Linux Containers, the merging of systems like OpenVZ and Linux-VServer, a second talk on version control systems in part based on a four part series I posted to use.perl (part 1, part 2, part 3, part 4), and discussions with the bazaar developers.
Mocking objects using testify mock objects Go already has a built-in system for building mock objects: interfaces. Most testing libraries that implement mocking work by temporarily “monkey patching” functions and passing in dynamic objects which do nothing. In go, you would typically define an interface that describes the object that your library deals with. Your test script would deliver a simple version that doesn’t do anything except perhaps collect information on its interaction with the code being tested.
Aiming to have your logs legible by more than just the technical team can focus you on making sure to log things that don’t require a deep working knowledge of the innards of the code. This is useful for new people to be able to figure out the context of the panic. # Don’t be afraid to make a new context for each iteration in a loop if each item you are processing in the loop is a complex business object; one of the most annoying things that can happen with a logged error is that it is something generic like “no rows found” / It’s good to have correlated log events, that is single log events emitted that have as many correlation IDs attached as possible.