Secret Lab builds world-class iPhone, iPad, iPod touch, and Android apps and games, and offers iOS developer training in Australia.
Beneath the relatively placid surface, a battle is raging among iOS developers.
On one side, we have developers who use the built-in visual interface development tools for constructing their screens. On the other, we have the code purists, who insist on entirely generating their interfaces from code.
Storyboards have a number of important advantages:
- Seeing your design means thinking visually
- Storyboards let you see how apps flow together
- Storyboards are the only way to use segues, which are a marvellous way to handle the transitions from screen to screen.
Apple vigorously promotes the Interface Builder and the use of Storyboards, but there's a surprisingly large number of developers who insist on not using them. One famous example is Google, who, as of 2012, apparently forbade the use of storyboards and XIB files, as well as checking in .pbxproj files (that is, the actual project files used by Xcode to organise where files go.) The reasoning provided is that merging these files is too much of a challenge.
Google aren't the only ones insisting that storyboards aren't a good idea. There are dozens of examples of developers promoting this viewpoint, and here are the most common arguments we see.
"Programmers should code, and not do visual design. You should know how views work from the ground-up, and being able to code your interface is more extensible."
A good programmer knows more than just than their specialty. The argument that programmers should only focus on the written component of their apps implies a separation of skills that simply isn't workable in mobile apps: if you're making an application that relies on the user holding a screen in their hand, deliberately not thinking visually means that you'll be more likely to not catch small visual problems in your app's design.
There's a lot to be said for understanding views and view controllers from the ground up, for the same reasons as understanding any other topic in programming: knowing as much as possible about what's going on behind the scenes makes it easier for developers to make more advanced use of the technology. However, this isn't an argument for avoiding the Interface Builder - understanding how views work doesn't require that you manually create them in your code.
"Creating re-usable views is harder. Also, custom views are hard to see in IB, they're just white boxes."
Another common argument against using storyboards is that using custom views is harder. For example, if you've got a view controller that needs to use a custom selector view of some kind, embedding a view that you've designed in a XIB can be a pain.
- Using the Interface Builder doesn't mean that you have to use the Interface Builder for everything. You're still free to embed a custom view, set its class, and then provide a
loadViewmethod for that class to manually create the view hierarchy for that class.
- Embedding view controllers using container objects is straightforward. If you need to embed a collection of views elsewhere, or if you want to break out the logic of a screen into multiple sub-units, use the Container View object to break out a collection of views into a separate view controller.
A related argument that we see is that custom views just look like empty white boxes in your view controller's designs. Technically, that's true - if you drag in a generic UIView, and set the view's class to your own, it'll still appear as a generic white box. However, this argument against storyboards ignores some important facts:
- Unless you care about the contents of your custom view, seeing a preview of your view isn't a requirement for constructing the rest of the screen. Positioning and sizing the view on the screen is the most useful feature, and that's what you get.
- A number of important, Apple-provided views also appear as empty boxes. The point isn't that you get to see the content, but rather that positioning and arranging the view in the screen is significantly more straightforward.
"Auto-Layout sucks, and doing the layout yourself is easier to understand."
Auto-Layout has received a significant amount of criticism since it was introduced, and many developers argue that the older method of struts and springs (as well as defining frame rectangles for each view) is easier to understand.
This was a fair criticism - in Xcode 4, constraints were a huge mess, and it was very difficult to understand how re-repositioning a view in the Interface Builder would affect the constraints.
However, Xcode 5 and iOS 7 has simplified this considerably. You no longer receive a soup of vertical and horizontal blue lines, and controlling the position and size of views using constraints that you design in the Interface Builder is simple and straightforward.
"Using storyboards means designing your interfaces in Xcode, which is slow and crashy."
Xcode doesn't have a great reputation for stability, it's true. However, the time lost to re-launching Xcode after a crash is miniscule compared to the amount of additional time you'll take designing, testing and debugging your layout code.
(Xcode's still the worst IDE ever built, but that makes it no different to every other IDE.)
"Dealing with lingering outlets leads to crashes."
It's a common situation: you link a view to a class using an outlet; later, you decide you don't need the outlet, so you delete it from your code. You run the app, but the view still wants to connect to the now-deleted outlet. Your code crashes. You scream with rage.
This is a reasonable criticism - Xcode should at least provide a more visible warning that the property is missing. However, it's nowhere near enough of a reason to forswear ever using it.
This is the only valid major criticism, and is the major one that causes organisations to ban the use of storyboards and XIBs in their codebases.
However, starting with Xcode 5, the Interface Builder is getting better and better at detecting merge conflicts. When a merge results in structurally valid XML but an invalid storyboard, Xcode will attempt to repair what it can: for example, if merging two versions results in an object connecting to an outlet that was removed, Xcode will notice it, and correct it.
Part of the problem, from a human perspective, is that dealing with merging two versions of a storyboard means working with XML, which is text; normally, working with storyboards is a visual task, but when there's a problem, you have to jump down to text and interpret what the XML actually means.
The XML used by storyboards, however, is actually pretty straightforward. Each view controller is an element that contains its subviews and other components (such as gesture recognizers or segues), and references to other objects are done with short alphanumeric strings. If there's a conflict, it's generally because two developers both inserted views into the same view controller - in which case, it's about as straight to recognize and fix as it is to fix a merge conflict in code.
Storyboards and XIBs are one of the most powerful and flexible tools that you get as part of the iOS developer tools, and shunning them means you lose both flexibility and features. If you're avoiding storyboards for personal reasons, we strongly recommend that you give them a try. If you're avoiding storyboards in your team because of the risk of merge conflicts, get some practice in fixing merge conflicts - they're easier than you think.
If you have any comments, email us!
Yesterday the Go South Awards were announced in Hobart. The Go South Awards is a competition to design and develop an amazing new app, of any kind, for Tasmania.
The competition has some really solid prize money, and looks like an excellent opportunity for app developers and students hoping to make their mark! Check out the Go South Awards website (built by our friends at Ionata and onetonne) for more information.
We're really excited to announce an intensive 2-day iOS developer workshop in our hometown, Hobart. The workshop is organised in conjunction with ACS Tasmania.
The workshop is designed for existing programmers (of any sort) who want to learn iOS development, or iOS programmers who want to get up to speed with the latest techniques for building iPhone and iPad apps. It teaches the very latest public iOS developer tools and features.
Brisbane and Melbourne iOS developer training is also currently open for registration.
We're really excited that Play School Play Time for iPad, an app we built for the Australian Broadcasting Corporation, is a finalist in two categories of the 20th AIMIA Awards!
We're thrilled that Secret Lab is in such good company again this year! Previously, in the 19th AIMIA Awards, Play School Art Maker for iPad, also built by Secret Lab for the ABC was a finalists in "Effectiveness", "Best Application for a Tablet", and "Best Children's", and in the 18th AIMIA Awards, Foodi for iPad was a finalist in "Best Cultural or Lifestyle", and Play School Art Maker for iPad was a finalist in "Best Application on a Tablet or Mobile".
Recently, we were also thrilled to win a Tasmanian ICT Industry Award for 2013, for our work on innovative apps for kids!
Welcome back! If you haven’t read the first part of our animation basics trilogy, you should check it out! This second article is about Timing!
So, if Spacing determines how quickly or slowly something moves, what is there left to call timing? A lot of the time (ha ha), timing is the functional time requirement of your subject. For example, when animating a boxer throwing a punch, you must make the timing quick enough to accurately convey the speed of the punch: too fast and we miss it, too slow and he looks silly. Another example would be interfaces, which need to move quickly into place in order to be practical.
This is something most people know how to do instinctively, or can easily adjust for when a mistake is obviously too slow or too fast. Where timing gets interesting is the way choices in timing can affect multiple elements moving together.
As mentioned in the Spacing article, where Spacing is the placement of instances through time, Timing is the distribution of time across defined instance points, or keyframes.
Real World Imitation
All good animators spend a great deal of time looking at real-world reference footage. Animal motion, the motion of objects under gravity: stones, balls, feathers, objects halted by a rope. Using natural timing at least as a starting point will cause objects to appear much more real. The closer the timing of an imaginary object mirrors a counterpart in reality, the more readily a viewer will accept it, irrelevant of how ridiculous the subject itself is. For example, an animated desk lamp that moves with the timing of a real, living creature can be more easily believed by an audience than a hyper-realistic figure which moves sluggishly or haltingly.
Where spacing demonstrates path of motion and slows and starts at a micro level, the wider choices about where objects move at what times is determined at a macro Timing level. These two concepts do blur quite a lot at their borders; I think of timing as requirements and spacing as the flair of a motion.
If one were listening to a drum which kept steady 4:4 time it would become very boring very fast. But with a second instrument playing a melody, or a second drum playing a different beat, interesting new combinations arise and we’re enjoying contrasts in timing. In terms of animation, this means that monotonous or homogenous motion across multiple objects is going to look bland, and a dynamic and heterogeneous cascade of objects moving at different speeds and in different styles, whilst requiring a little more effort on the part of the animator, will look much more interesting!
This isn’t always desirable, as often an audience is required to concentrate on something that isn’t moving, and in those situations a panoply of motion cues isn’t going to be advantageous.
Imagine a car driving around a corner (and our spacing is evenly distributed around the corner as we’re recklessly not slowing down), I guess you could say that this would be our Primary animation (an object appearing to move on it’s own initiative/by it’s own power). If the car has a trailer though we might call the motion of the trailer Secondary animation (an object’s motion that is separate from, but mostly determined by a primary object).
The other forces acting on the trailer might be gravity, it’s own momentum, the elasticity of the tether to the car, and if it were a lighter object, such as a flag, wind might be another factor. A flag on a stick, long hair on someone’s head, the tail of a kite, an injured arm hanging loosely from someone’s shoulder, even your clothes on your body are all examples of a secondary action linked to, caused by, but not identical to, a strong primary motion force.
This linked or tethered motion often provides a nice timing contrast, and good use of secondary animation both accentuates and deepens a motion and makes it much more interesting and attractive to a viewer. In fact, the emergent action of an object under forces is often more interesting than the primary motion. In touchscreen interface motion, the primary motion could be considered to be the gestures of the user and the interfaces move as secondary action.
Some people like to call this overlap, and the definitions get very messy when you’re talking about it in terms of secondary animation or two parts of one object, but what it really means is two parts of the same object moving in a similar (or even identical) way at different times. This helps to separate the objects, and adds a lot of interest to the motion. Inversely, regular timing can unite otherwise separate objects.
These two groups are composed of identical frame instances, just presented out of synch by one and two frames for the staggering effect.
Cycles are a really interesting technique, particularly as an economy measure. An animation cycle is where a sequence or motion may be looped and reused more than once. The difference between a ‘Cycle’ and a ‘Loop’ is that a cycle may only apply to one component, whereas a loop generally applies to everything that is displayed.
One of the most well-known uses for this technique is the “run cycle” where a character’s two steps loop seamlessly to create the illusion of an ongoing running action, when in reality the animator has obviously only been required to animate two steps.
The main difficulty in making viable cycles is preventing your audience from really seeing too much of the “seam” where the cycle repeats. In many cases there won’t be a seam: a spinning object, for example, could be said to loop from any point in it’s rotation. But more complex motions, like a character jumping, or running, often lend themselves to a logical starting point.
Keeping away from dead stops and overly regular spacing will help, obviously repeating frames will sit as a kind of afterimage in the viewer’s mind as the animation cycles. Where cycle economy becomes really powerful (infinite, really) is when there are several cycles working together, all with different lengths. Take this simple example.
Okay now brace yourself for some maths: Two cycles (with different timing) are playing in the next example, and the total length of the animation is double the longest of the two cycles. Despite doubling the on-screen time of the animation, technically we’ve only really stolen twelve frames for free here (24+36=60). But this is with two relatively compatible cycles.
If I had added another really short cycle with an uneven number of just five frames, the animation as a whole would not have truly looped until unique frame number 360, stealing us 295 frames for free and making the largest and most terrible gif ever to be displayed on the Internet.
This is great for long animations of spinning logos, but also useful for things like water ripples, cloud motion, shifting colours across an object. Extending cycle lifetime is the strongest way to avoid obvious repetition, and joining cycles like this is the cheapest way to extend overall cycle lifetime.
With the use of procedural animation, we can control these cycles just as we control loops in code: randomised frame segment orders, dynamic particle generators, and so on. Using these techniques, we can extend these cycle times dramatically, or infinitely, for no extra ‘drawings’ and close to zero extra effort. Eased rests, cycles and code-assisted animation are where an intelligent animator will be able to save the most time/money.
Join us next time for the final episode in this animation basics series: Spatial Distortion!
Recently the Secret Lab was connected to the National Broadband Network (NBN). For our overseas readers, or those not following along in Australia, the NBN is an Australia-wide project to upgrade our telecommunications infrastructure. The NBN originally planned to offer fibre-to-the-premises (FTTP) to the majority of Australians, and fixed wireless and satellite connections to rural areas; when the federal government changed in September, as part of the new government policy a review into the possibility of changing from FTTP to fibre-to-the-node (FTTN) and other technologies commenced. That review is still ongoing. Either way, our office is now connected to FTTP, at the speeds of 100 Mbit/s down, and 40 Mbit/s up – a big step up from our previous ADSL2 connection, which maxed out at 23 Mbit/s down, and 0.9 Mbit/s up (we had basically the best ADSL2 connection you could get in Australia). FTTP NBN is one of the most transformative, impactful things that could have happened to us. Here's why.
We're, primarily, a game development studio, and we also teach iOS development. We build games for iPads, iPhones, Androids, Macs, and PCs. Games require lots, and lots, and lots of large asset files, sound files, music files, and the like. Most of the games we build are for clients. We also write training material, and create large instructional videos. This means, on a daily basis, we have to upload and download a lot of data around just to get anything done – often we need to upload between 3 GB and 30 GB in a day; this was impossible with ADSL2.
What did we do? We sent hard drives, or USB flash drives, through the postal service, or we left uploads running overnight in the faint hope that they'd successfully complete while we slept; worse still, and most deleterious to a small business – we resorted to expensive Telstra 4G LTE, which can upload between 5 Mbit/s and 10 Mbit/s at a cost of ~$50 AUD per 4 GB or so, so our upload went up relatively quickly but cost a fortune in doing so.
This was not sustainable. We can't run a game development studio for very long like that, as it's simply too stressful/expensive/time consuming/unproductive. Until the NBN came along, our only other options for a useful connection – primarily for uploading – were expensive HFC cables (if it was even available where our office is, which is debatable), expensive high-latency satellite options, or expensive and complicated bonded solutions (routing multiple connections together into a single connection). If we wanted to remain competitive, keep our working capital healthy, and keep our internal IT maintenance administrative requirements low (our IT requirements consist of one of us rebooting the router as needed!), then none of these options were suitable.
The NBN, via FTTP, gives us a speedy 100 Mbit/s down, and an absolutely vital 40 Mbit/s up, and it gives it to us at a price equivalent to what we'd pay for a copper-based and all-but-useless for uploading ADSL2 connection. We can upload amounts of data that would have previously taken overnight, if we could do it at all, or required us to spend ridiculous amounts of money using 4G LTE technology, instead of resorting to the postal service and hard disk drive. We can move faster than we could before, since when one of us is using Skype to talk to a client we don't have to pause all our downloads and uploads, and stop checking code into source control since – thanks to having a 100/40 connection at our disposal – Skype no longer breaks down if something else is happening on the network. We don't have to raise our prices, since our broadband connection is both usable and cost friendly to a small business, and we no longer have to pay for extras such as hard drives to post, or Telstra 4G. Best of all, we no longer have to even consider leaving Tasmania – a beautiful place to live and work – solely because we couldn't get the connectivity we would have needed to make our business more effective, sustainable, and better equipped to make new games and software.
Realistically, we don't care what technology the remaining NBN rollout is delivered by, but we don't believe that the plan currently suggested by the coalition government can deliver an NBN that will truly serve Australia, and offer the same opportunities and capabilities to Australia, the way that FTTP has changed our business in the few short weeks we've been connected. Disturbingly, the majority of the published material from the current government regarding their NBN plans does not mention upload speed at all – upload is the most transformative aspect of FTTP for us.
We don't object to communication minister Malcolm Turnbull's strategic review of NBNco, or the new government's efforts to ensure NBNco and the activities around the rollout are more transparent to the public (such as making the maps available representative of the actual state of the build) – these are all good ideas. We are concerned, however, through sheer bloody mindedness, and to perhaps save a few dollars in the short term, or complete the rollout faster than the previous government suggested it would be done, that the current government might end up rolling out the remainder of a network with a technology that will not serve as a truly useful, future-proof, and transformative to business (and homes as well) series of tubes.
We're especially concerned that FTTN, the apparent frontrunner technology candidate for the coalition's revised rollout, is considered a stop-gap technology, is prone to be interrupted through weather, and that countries that have previously deployed FTTN (such as Germany, New Zealand, and the United Kingdom) are replacing/upgrading their networks to FTTP. If we rolled out FTTN in Australia, we'd already be behind many other countries with similar requirements and socio-economic status to us.
Feel free to email us with your thoughts, or questions.
Update on 20 November 2013: We're especially concerned given Ziggy Switkowski, the new Exectutive Chairman of NBNco, doesn't have the foresight to see why 100 MBit and faster broadband speeds could be useful to households.
We're absolutely thrilled to have won a TASICT award last night at the Tasmanian ICT Industry Awards for 2013. We won the "Best Software Product" award for our work on innovative apps for kids. Thanks to TASICT, TasmaNet for sponsoring the particular award that we won, and Michael Ferguson for presenting the award to us. Congratulations to all the other amazing nominees and winners: Elan Projects, Jobric, CGI, ISW, Vodafone, Anittel, Kingborough Council, UXC Eclipse, Ionata Web Solutions, Synateq, Acrodata, Aurora Energy, and RBF. Thanks also to the event sponsors: Autech, Fuji Xerox, Insight4, Aurora Energy, HP, Hays, Anittel, and the Tasmanian Government.
Don't forget to check out Malcolm Turnbull's recorded message, regarding the NBN, on YouTube (thanks, Josh Deprez!)
Developed by Secret Lab for the ABC, Play School Play Time for iPad has hit the App Store this week! Let us know what you think!
This app contains some of the most interesting and complex use of Core Animation that we've ever done, and we're proud of how it's turned out. You can grab it from the App Store here, if you're in Australia, or here, if you're elsewhere!
Update! As of 25 September 2013, the Play School Play Time app hit Number 1 in the App Store!
We're incredibly pleased to be involved with National Science Week in Australia again this year. After building an app for the Tasmanian events last year, we were asked to create an app for the whole of Australia this year.
At OSCON this year we were interviewed by Rachel, Senior Editor for O'Reilly Media, about mobile game development and the state of the industry! We're working on some interested game development-related material at the moment, and can't wait to share them with you. In the mean time, check out the interview on YouTube:
We normally shy away from doing link posts on the blog, but these links were just so interesting/useful that we couldn't not share them:
Some links/information for those of you who are interested:
- Final APK (suitable for installing) of the OSCON 2013 app we built
- GitHub repository for the code from the tutorial
- The tags, corresponding in order to the start and finished states for the application: talk_listing_start, talk_listing_end, schedule_start, schedule_end, day_list_start, day_list_end, navigation_start, navigation_end, data_end, tabs_end, theme_start, theme_end, navigation_refresh, talk_listing_update, themeing_finished
- You can switch between these tags by using git reset --hard followed by git checkout and the name of the tag you want. Note that you will lose changes.
Slides are available on Speaker Deck:
If you have any questions or comments, please get in touch!
We ran our game design workshop at OSCON 2013 this year! Thanks to all who came - we hope you had an excellent time! Here are links to the books and papers we talked about at the end of the presentation:
- Squire, 2006. From Content to Context: Videogames as Designed Experience
- Schell, 2008. The Art of Game Design
- LeBlanc, Hunicke and Zubek, 2004: MDA: A Formal Approach to Game Design and Game Research
- Koster, 2004. A Theory of Fun for Game Design
If you have any questions or comments, please get in touch!
Animation techniques are usually discussed in terms of human figures. However, character animation is a very complex field, harnessing knowledge of physics, natural animal motion, conscious and unconscious physical decision-making of humans, body language, drawing and rendering styles as well as various acting styles - and that’s all before we’ve even set the figure in motion.
This introduction into animation will attempt to cut through all of that obfuscating, jargon-strangled mess, and get to the real nitty-gritty of animation: animation as it applies to ANYTHING that moves, be it a figure, a rocket ship, a bouncing ball or an interface component. Animation is both the art of bringing the lifeless to life, and the science of constructed motion, and neither of those things require a human figure or drawing skills of any kind!
Disney lists 12 principles of animation. In no particular order, they are:
- Squash and stretch
- Anticipation, Staging
- Straight ahead action and pose to pose
- Follow through and overlapping action
- Slow in and slow out
- Secondary action
- Solid drawing, and
ALL of this is interesting, but MOST of this is related to drawing. I’m going to whittle and compress these down to three headings, and three separate articles: Spacing, Timing, and Spatial Distortion.
In this article, we’re going to look at the first of these: Spacing.
Spacing and Timing are very closely linked concepts, and it can be a little tricky to mentally extricate them. Richard Williams (in The Animator's Survival Kit) describes Timing as the time between the bounces of a dropped coin, and Spacing as the movement of the coin between bounces.
What this means is that if we have only one second to move an object from A->B, spacing is how we choose to move it within that timeframe. For example, if an object moves for one second, at 24 frames per second, that means I have 24 instances of the object to place across that timeline.
Sometimes, that timeframe will be open-ended, but our choices on where/how to move objects from frame to frame will still matter. Unless you’re working with some sort of amazing analogue animation device, you will be distributing objects across discrete projected frames, so your choice in how to place them should be deliberate.
Here are a few of the myriad techniques.
Eased motion. Easing is the most commonly used form of spacing, and most animation software packages have some sort of in-built easing function that allows both easing IN and easing OUT. When easing is performed automatically by software rather than defined manually, we call it “tweening” rather than “inbetweening”.
Easing means distributing spacing so that one or both ends of a timeline are compressed, meaning that an object will move smoothly out of an old position or smoothly into a new position. You can use both at the same time to give a sense of the effects natural momentum. The important thing to remember about easing is that it exists independent of timing. The number of frames does not change, just their spacing!
Anticipation/Follow-through About the only thing that moves in a straight line on regular spacing is robotic components. Even then, they’re more interesting if there’s an ‘accent’ to the way they start and finish their motion- anticipation before the motion and some sort of follow-through at the end. All human motion involves anticipation to a certain degree, we move backwards before we move forwards, left before right, etc. It’s only a slight motion, but it’s always present.
So before we move an object anywhere, it can make sense to prepare, or to spin our wheels a little first, and once we reach our destination, maybe there’ll be a little overshoot and compensation! You can take it further away from the keys - that is, the start and end points of the movement - for a ‘heavier’ effect, or make the motions faster for a springy light motion.
Arcs Technically, this is a separate issue to spacing, but it bears mentioning anyway, and here’s as good a place as any. In the real world, most things move, to a lesser or greater degree, in arcs. Even if you move along a straight line with your hand, it’s because your arm makes an arc, and your elbow and wrist make more arcs to compensate. Thrown stones, leaping tigers, ocean waves, arrows and even bullets will all arc with gravity.
Afterimages. When spacing gets distant and the moving object is very distinct from it’s background, we sometimes see afterimages. One or more frames of the animation stand out, and leaves a kind of remembered image on your eye. This isn’t usually much of an issue if the animation is only seen once, but in a cycling animation it can make your afterimage-causing frames obvious: it reminds the viewer that they’re looking at a device that can only display images one at a time, rather than a smooth transition that can trick them into thinking that they’re looking at analogue motion.
Anyway, there are a few things we can do to beat this. Using a faster framerate (may not be practical depending on device rate/intensive rendering technique) We can play out our spacing so that there’s no such abrupt frames; if something’s moving really fast, it can sometimes be advantageous to skip these ‘afterimage’ frames. The other thing that we can do is to employ blurs, smears and distortions to negate the jarring visual contrast between object and background, which we’ll cover in later posts in this series!
Join us next time, as we take a look at how timing influences how we see animation!
This weekend we were at PyCon Australia 2013 in Hobart! Once again, it was very exciting to have a technology conference in our city. So exciting, in fact, that we sponsored the conference WiFi network. You're welcome! (We attempted to troll our friend --- conference coordinator Chris Neugebauer --- by setting the WiFi password to AskChris, but it backfired in that everyone asked us, rather than Chris. Better luck next time!) Our friends from the Australian Computer Society (Tasmania) also sponsored the conference.
Highlights of the conference were the three keynotes: Alex Gaynor, Mark Pesce, and Tennessee Leeuwenburg. Alex spoke about the nature of software engineering, and its relationship to art and science. Mark, during a brilliant dinner keynote, spoke about the Internet of things, and his new venture: MooresCloud. Tennessee discussed the use of tools for problem solving and communication. All three keynotes were highly enjoyable, alongside the sessions, and we highly recommend watching them as they become available on PyCon Australia's YouTube channel.
Exceptional conference coffee was again supplied by Ritual Coffee Tasmania. Although we didn't sponsor the coffee this year, it was as tasty as last year --- we can't wait to get a bag of beans to enjoy in the office.
Lightning talks were also highly enjoyable, as well as CodeWars --- a devious and irreverent coding competition devised by our friend and frequent collaborator Josh Deprez. This year, Paris from Secret Lab, and another friend and frequent collaborator Tim 'McJones' Nugent hosted the event. We're sure that we thoroughly confused all those who participated. It was pleasing to inspire a room full of conference-goers to chant "Bovril! Bovril! Bovril!"
We spent a lot of time hacking on the Holiday by MooreCloud, a fabulous set of very open and very hackable Christmas lights. Over the course of a few hours of coding (and harassment of Mark), Secret Lab and friends managed to build a script to make the Holiday respond to sound levels, a CPU activity display, a one-dimensional game of life style game, and a native iOS interface to the Holiday. It was all great fun, and we highly recommend that you order a Holiday while it's a little cheaper (they ship in November); it really is one of the coolest, most fun and inventive gadgets that we've seen in a while.
Our friend, Frank Sainsbury, was the life of the conference (as usual), delivering a surprisingly meaningful lightning talk on helping others, as well as (also as usual) entertaining everyone with his wigs, and assorted props.
Next year, PyCon Australia will be in Brisbane. We're looking forward to it! All our photos from PyCon Australia this year can be found on Flickr. Congratulations to Chris and his team for another successful world-class technology conference.
Also, huge thanks to Rex Smeal for his fantastic art work for our conference poster.
Once again PyCon Australia is being held in our hometown of Hobart, Tasmania, and one again we're sponsoring! We had an excellent time at PyCon Australia last year, and we're really looking forward to learning about the latest developments in Python, how to make games in Python, what not to do with Python, how to test with Python, security and Python, transitioning to Python, and much, much more! Congratulations to our friend and frequent collaborator, Chris Neugebauer (conference coordinator), for putting together such a a great show.
If you haven't registered for PyCon Australia yet, we strongly recommend you do! It's sure to be a blast.