Day two of Saastr 2018 got off to a better start than day one with noticeably less people looking lost and annoyed! The day kicked off an hour earlier providing the opportunity for attendees to take in more content and get their money’s worth.
On day one, logistical problems almost threatened to ruin the SaaStr party – bottlenecks around every corner, wobbly wifi, ultra-low-key signage, not so much standing in line as standing in huge clumps of people. But we had just enough agility and resilience to stay focused on some excellent content.
The vzaar team have touched down in San Francisco to attend the biggest SaaS conference on the planet – SaaStr 2018.
Developers occasionally move away from coffee and backlit monitors to venture outside. These occurrences are more common than you might think and are often referred to as “lunch time”. Other times developers will leave the comfort of their desks altogether and head out into the world, in order to meet other, like-minded, individuals. Bath Ruby Conference is one such event.
Some of you may know me as, “Lawrence the support guy” or other (less wholesome) sobriquets. However, I’ve also been coding in my spare time for a couple of years. Brilliantly, over the past few months, I’ve been coding more and more around the office too; working alongside our development team and straddling two worlds. Support and development.
With that brief bio divulged I can now tell you about Bath Ruby Conference. My first development conference! Needless to say, I was very excited and wanted to share the experience.
The Bath Ruby Conference Experience
For those of you who don’t know, Ruby is an object-oriented, dynamic, language. It’s one of the younger languages out there and was originally published in 1995. It gained widespread exposure ten years later, with the popular Ruby on Rails web framework; around which vzaar is built.
That all adds up to make Ruby a young language, primarily focused on web development. However, referring to it in such a way doesn’t really do it justice
The best thing about Ruby (and there are a lot of really good things about Ruby) is the community. It’s all about sharing, collaboration and making everyone a better programmer. Conferences highlight that better than anything. Take our first talk of the day as an example: it wasn’t a high-level discussion of how to approach a particular problem, it wasn’t a comparison of tools or methods. It was a talk about a children’s book, designed to get kids coding.
Linda Liukas is a Ruby developer from Finland, who began a KickStarter project in 2014. Her goal was to create “Hello Ruby”, an illustrated book based around the adventures of a young girl called Ruby. “Hello Ruby” was intended to introduce kids to the logic of the Ruby language, in a fun and engaging way.
At present Linda has exceeded her $10k by miles, raising $380k for the project over the past year. Listening to her speak was motivational to say the least. It’s great to see someone completely focused on giving kids the ability to make cool stuff, with an audience so enthusiastic about seeing that happen.
That concept – engaging the world around you and helping others engage with programming – is something which became a bit of a theme. And, I must say, a damn good one at that.
Like me, Saron started coding about two years ago. She went through a coding Boot Camp and, having survived it, now works with ThoughtBot. It sounded like her experiences were often much like my own. Sitting up late into the night, trying to work out why the computer won’t do what I’m telling it to do.
Keen to share these experiences, Saron tried help us think about how we learn and the steps we take towards gaining expertise. In particular, how we can help others with that experience.
The short answer: read code. Lots of code. Good code, bad code, and anything else you can get your hands on. More importantly though, do it in a group. Get together with some friends in the same boat, read it together and share your thoughts. It’s not often you can say this but, “it will make you a better person”.
To help everybody achieve that collective learning experience, Saron has also created #CodeNewbies, a Twitter chat which runs every Wednesday at 9pm (EST), to help newbies discuss what they’re doing and receive support from the community.
Another common theme for the day was making everyone a better programmer. Looking at how we think and why we engage with problems the way we do.
Tom explored mathematical abstractions and how thinking about them can make us better programmers.
It’s probably best if I show you an example, so you can see what I mean. What’s the sum of all the numbers from one to ten (i.e. 1+2+3+4+5+6+7+8+9+10)? The answer: fifty-five!
Ok, so how about all the numbers from one to a thousand? What would you get if you add all those up? A long and boring sum would certainly be one answer. Just imagine: 1+2+3+4+5+6….. +98+99+100….+742… Urgh.. To save your sanity, you’d need a better method.
Finding that better method, as Tom would tell you, is exactly what mathematics is meant to do. In this case, there’s a simple mathematical rule, which was discovered by Carl Friedrich Gauss. You can use to work it out the answer very quickly. It’s just…
…. where n is the number you’re counting up to (in this case 1000).
That, Tom says. is exactly what all good programmers should be doing. Looking for patterns and coming up with rules. Letting logic doing all the heavy lifting and leaving clean, short, elegant code.
This also serves as a reminder to every programmer out there, who had an awful time with maths at school. Maths is cool and will let you do cool things quickly, when you apply it properly. When you remove the fear and the stigma, it is just a incredibly powerful and elegant tool. Check out the slides here, if you’d like to know more.
Of course, as you’d expect from a programming conference, there were some more meaty discussions too. The general focus was looking at how we code, the way we write, and how we can write better. The goal being cleaner, more elegant, more logical code.
Ben’s a brave guy to say the least. His talk centered around refactoring some simple code, which he demonstrated in real-time. That’s no mean feat, when you’re standing in front of 400 people. Particularly when some of them are truly impressive thinkers.
This demonstration finished with a look at dependency injection. Dependency injection is, at the risk of being a little tautological, a more flexible method for handling dependencies. Rather than objects creating their own dependencies, they receive them from elsewhere. The idea being that, in detaching an object from its dependencies, you can freely reuse them elsewhere and, as the project grows, end up with more concise, readable code. There’s a good blog, summarising the idea, here.
Entitled “Here be Dragons”, Katrina’s talk would definitely win any prizes for animation. Katrina showed us some truly terrible code, illustrated with pixel-art, and we all had a good chuckle.
Of course, writing terrible code is something we’re all guilty of from time to time (I’m told this is an understatement). Katrina highlighted it to talk us through common mistakes, some debugging techniques, and some more elegant solutions.
Finally, I’ve been saving the meatiest subject for last. Sandi’s talk was certainly the most involved of the conference and I’m certain that this summary will not do it justice.
Like Ben, Katrina, and Tom, Sandi focused on methods for writing good code. In particular she focused on what nil is in Ruby and ways of handling it.
nil is an object which adheres to it’s own rules. So let’s say you’ve got a group of objects, which you’re performing an action on. That action’s going to be tailored towards the objects you’re expecting to receive.
Then your method hits a null value and BOOM!
NoMethodError: undefined method 'some_method’ for nil:NilClass
There’s a great discussion of this over at Sandi’s blog, where you’ll find the writing much more concise than this rambling, mixed, summary. She explores the problem further and what it leads to, then offers an elegant solution: a null object pattern. There the blog ends but, at the conference the talk continued.
In it’s simplest terms a null object pattern provides attributes to nil. Giving it characteristics, which will allow it to interact with your methods more elegantly. Here’s an example from Wikipedia, to show you what I mean.
Massive disclaimer: the above example uses conditional logic and I’m not entirely sure Sandi would approve.
Last but not least, I can’t finish up this blog without mentioning the lightning talks. For those of you who haven’t come across the concept of lightning talks before, imagine the conference equivalent of an open mic session. People just volunteer and then talk about a subject of their choosing for up to five minutes. Nothing highlights the creativity, diversity and all-around madness of the community better!
I don’t have time to run through them all, so I’ll leave you with this…
… these guys have written a program containing a synthesizer, in Ruby. Not just any synthesizer either. It’s a synthesizer which you interact with via code… in real time! Their lightning talk involved no talking whatsoever. Just a laptop and some phat beats :-)
And one more thing….
A masshoosive shout out to the guys at Eastern Eye in Bath. The team went out for dinner there last Thursday. I challenge anyone to find a more ornate Indian restaurant!
Last week the brilliant Corrina Stegner from Casual Films joined us to talk about “How To Make The Most Of Your Video Budget”. In her 4 years at Casual Films, Corrina has produced hundreds of films with budgets ranging from £2,500 to £250,000. Whether it be a 2D animation, stop frame, talking heads or something more creative, she believes there’s always a way to make your budget work. Corrina’s client’s include EY, Bloomberg, Tesco, HSF, Roche, Rolls-Royce and Breakthrough Breast Cancer to name but a few.
Corrina walked us through 6 typical scenarios clients face when juggling budgets. Here are her tips for making sure you spend your money wisely (plus a video round up at the end)…
Scenario 1: “My subject is really boring and I don’t really have much to spend. What can you do?”
We get this question a lot from clients who are searching for a better way to engage their employees during health and safety training, for example.
The key thing here is that the obvious choice isn’t always the best one. It can be very tempting to try and cut the costs by just filming a talking head of your health and safety manager. But the thing is that’s still going to cost you money, plus it’s not going to be engaging – and this was the very reason you decided to go with video in the first place!
Something that works really well here is to use animation. This will bring a humorous visual to punctuate what can often be a fairly dry script. And, animation doesn’t necessarily have to cost a lot.
Top Tip: Use one character throughout the animation. This means you can reuse this single asset throughout the whole animation, instead of having to create new content for every scene.
Scenario 2: “The story I need to tell is really long, but I need to retain interest”
Generally speaking, we encourage people to reduce the length of their videos. As a rule of thumb we try to keep promotional videos to less than 90 seconds; otherwise people just don’t tend to watch all the way to the end.
That said, there are situations where a longer video might be necessary. A career video perhaps. Or if you’ve got a long company history. The problem is that if you use a talking head, while admittedly cheap, the reality is your video will get boring. On the other hand, a more engaging animation will just get really expensive because of how long it needs to be.
Top Tip: Vary the visual. You could, for example, use hand drawn illustrations which will bring the benefits of animation, without the associated costs of computer generation.
Scenario 3: “We just need content. We have gaps to fill on the website but we can’t afford to do anything too complex. We don’t want it to be rubbish though”
This is particularly common for businesses doing a website redesign. Their design includes video components, but by the time they are ready to make the video they’ve already spent a large chunk of their budget elsewhere. In this scenario we encourage people to use just one creative device in the edit to add a bit of interest.
Top Tip: Intersperse B roll with your main footage. Typically with talking heads we’ll do a two camera set up which gives us some behind the scenes type stuff which is really, really simple to get but instantly makes the video more watchable.
Scenario 4: “We’re a charity so we don’t want to spend a lot…but we need to generate maximum return”
The key thing here is that the video HAS to be functional. Before you start to craft the creative, you need to be really clear about what the goals are. Often you don’t often need a big glossy film to meet those targets. The video’s form really comes second to its function.
Top Tip: We tend to use the real people who work for the charities rather than spending money on actors. To get a relaxed performance out of these employees it’s really important to spend a bit of time chatting to them before hand and getting to know them as a human being. This will help them feel more comfortable when the camera starts rolling. And remember, editing can work wonders!
Scenario 5: “We’re a global business and we need to include everyone”
It’s not very cost effective to send a crew around the world to film everyone in all your offices. User generated content can be a great way to get around this. Give your employees some cameras and set them loose. But, beware! It is super important to teach your employees how to make good quality UGC, otherwise you might end up with completely unusable footage. And that’s just a waste of their time filming it, and your time reviewing it.
- Make sure there’s enough light
- Make sure the camera is close enough to hear you over any background noise
- Think about framing – the camera shouldn’t be too close, or too far away. Try and get the head, plus shoulders, in shot
- Keep the camera steady. You don’t want to make the viewer vomit!
- Tee up each shot – don’t just switch location without an explanation
Scenario 6: “We don’t have much money but we’d like to make a video that’s really fun”
The beauty of a brief that basically tells you to have fun is that you get to go a bit crazy with it. And quite often you don’t actually need a big budget for this – you just need to get a bit creative. In our experience, budget limitations actually breed creativity so it can work to your advantage in this case.
If you’d like to make a video with Casual Films drop the team an email here.