What a whirlwind of a trip to Paris! The badgers are back in London after three days of meeting ReactJS developers, hastily starring cool GitHub repos, and having a few too many at the Frog. As a relative newcomer to React it was fascinating to hear about how much the ecosystem and community have grown in just a year.
Exploring Montmartre with the Red Badger team.
One mark of a good conference is just how badly it makes you want to grab your laptop and start coding, and React Europe certainly gave me itchy fingers. My list of new libraries and technologies to investigate will certainly keep me busy for a while but before diving in I’d like to look back at the conference: what was good, what could be better, and my hopes for React Europe 2017.
By far the best thing about React is the community. The sheer number of people building libraries and tools for the framework and its ecosystem is impressive. In part that’s due to the culture surrounding React development – to hear “celebrities” like Dan Abramov and Vjeux talk about the importance of humility and encouraging more people into OSS contribution was unusual and refreshing. I also liked that Facebook sent key members of its React, GraphQL, and Flow teams out to Paris — there’s no better way to hear about the future of a technical landscape than from its creators.
ReactEurope showcased several high quality, engaging talks. A couple of my favorites were:
Jeff Morrison’s deep dive into Flow — having used Flow on my last project I thought this was fascinating. I’ll also be the first to admit I got rather lost midway through. Impressive and interesting nonetheless, it’s one I’ll watch again with the pause button ready.
Jonas Gebhardt’s talk on using React to build better visual programming environments. Tons of programmers get their start in visual languages despite most of them being clunky and removed from more standard coding environments. Although just a prototype, the tool this talk introduced had great potential for improving CS education.
Bonnie Eisenman’s retrospective on React Native. Although not technical, I thought this talk was really important, especially to those new to the React community (like me). Out of every talk at the conference this was the one that made me want to get coding ASAP.
Andrew Clark’s talk on his Recompose library — immediately useful and interesting, I will absolutely be checking this out for my next project.
Laney Kuenzel and Lee Byron’s talk on the future of GraphQL. I haven’t had the opportunity to use GraphQL yet but this talk was well delivered and nailed the balance between accessible to beginners and interesting to experts. I can’t wait to try it out.
And a major thanks to all the presenters for being so humble and open to questions about your work.
Excellent use of emojis by Dan Abramov.
What Could Be Improved
Although I really enjoyed React Europe there were definitely some things I found frustrating throughout the week. Starting with the least important, coffee and wifi were in short supply! This was annoying but I was still impressed with how smoothly the whole thing ran overall — catering for 600+ attendees is very challenging.
Next year, I would like the conference to run multiple tracks in smaller spaces. It seemed difficult for the speakers to engage the whole (gigantic) room. Especially if you happened to be seated behind a pillar watching a screen, it felt like you may as well be at home in bed watching the livestream. There was also no alternative event to attend if you weren’t interested in a particular talk.
Over the course of the conference, I started to wonder if React is actually a large enough domain for a multi-day event like this one. Very few talks introduced new React paradigms or techniques. Most of the talks could be categorised as either something about GraphQL, something about React Native, or a demo of someone’s new React library. A lot of these were interesting, but after two days, repetitive. Personally I think something like a functional web programming conference might have more value than a React-specific one. However, a major part of the conference was getting to meet React’s developers and creators which for me was the highlight of the conference, and not something I’d want to miss out on.
And of course my final wish for the next React Europe is a higher percentage of women attending and speaking. I’m used to being a minority in tech but the gender ratio at React Europe was probably one of the worst I’ve ever experienced. In any case, I very much appreciate that the conference had a code of conduct which is step one in making events more accessible to women. Hats off also to some really fantastic women who spoke — Lin Clark, Bonnie Eisenman and Laney Kuenzel all did a stellar job.
Overall I had a lovely time and met some incredible people. Hope to see you all next year!
Red Badger are hosting the 1st React conference in London next March. If you’d like to be kept up to date with news you can sign up here.
We have a £2,000 annual training budget at Red Badger that can be used however we like. Most people use it to travel to attend a conference in the US, Asia-Pacific or somewhere equally exciting. Training is really specific to your job role and expanding / honing your skills though, so sometimes the most relevant conference is… at the London ExCel.
On 12th May, I took myself out to deepest, darkest docklands (admittedly in my MX5 with the roof down as it was a super sunny day) and wandered around hall S6 for 7 hours. Amongst the stuff I wanted to hear about was why buyer journeys are all wrong and how to speak to big prospects whilst still sounding like a human being.
At Red Badger, it’s really important to us that we talk sense, both in terms of what we do and how we tell you about it. I was keen to hear how other people did it, and what the audience thought about it. One of the things I love about how we build new business here is that we don’t have a sales team. It means that we find new business based on our reputation, the need of the client and our suitability to do the job, not because someone wants to meet their target and get their bonus. Many agencies do use that model and it leads to division internally; projects teams hate the sales team because they just throw projects over the fence and don’t care about how it’s been sold. The clients are almost always disappointed too; they end up having their projects de-scoped to make them possible in the time or for the price they’ve been promised.
What are you doing right now?
We don’t work like that at Red Badger. Ever. We are one team from pre-sale conversations to support; you’re always talking to people who know and respect each other’s working practices and understand how and why something has been designed or built that way. As a marketer, it is a joy to work with.
The speaker in the “Maximising your Business Relationships” session talked about how he felt the same disillusionment with that model, and set out to prove that large projects could be sold and managed without resorting to sales speak. This actually makes life a lot easier for both the seller and buyer. The pressure to talk in acronyms and business language can make it really hard to know what the other party means or wants. It’s a lot easier to say “I’m going to provide you with some recommendations to help get everyone on board” than saying “we realise this is going to be a c-suite decision, and I will provide you with a formal RfP response via procurement”. You have the same obligations to meet due diligence but everyone feels like they are dealing with another human person. There were murmurs of uncertainty in the room; “but how will we sound important and knowledgable without using all those buzzwords?” – and frankly that is exactly the problem. If you don’t know how to sell your product without being plain and transparent, it’s probably not the sales process that is flawed.
It’s a lot like the Agile/ Lean process itself – cut the waste, cooperate constantly, deliver fast. Endless documentation (e.g. large proposal documents) doesn’t get anything done faster, and may well add to losing sight of the end goal. Just like when you propose Agile, lots of people in the room looked worried. It’s hard to let go of the models you’ve been using for years. But that’s exactly why you should do – they are obsolete. Just like the monolithic agency giants – they no longer provide the best solution.
It tied in with the buyer journeys talk I’d heard earlier in the day. If you are using the ‘traditional’ sales funnel, you’re going to be disappointed with your conversions.
This is just not how it works anymore. Most of your prospects simply aren’t interested in hearing about how your solution is going to do something X times better and Y times cheaper than your competitors over 40 pages of sales documentation. They want to know what it’s going to be like to work with you and how that is going to get the result they need delivered. They want to know why they should work with your teams, specifically, to achieve their aims. The old sales funnel model focuses too much on saying the right thing to the prospect to get them ‘down the funnel’, when you should be focusing on how to solve their issues.
Going to conferences isn’t always about learning new skills, sometimes it’s about being given the confidence to let go of old habits. Knowing that sales-speak isn’t necessary, that doing the right thing is more important than saying the buzzwords and being bold in your decisions will mean that you don’t make the same mistakes as before, and get a different, better result.
So, thanks B2B Marketing Expo! You reminded me that doing my job well is often about simply treating people as human beings.
This was my first React dedicated conference, and to be honest I had my reservations. There is only so much you can fit into a single topic. One day single track conf turned out to be quite diverse to keep the attention all the way. As usual I was keeping random notes from the event. All notes and ideas are originated from talks, but are not necessarily direct quotes.
If you always wanted to try RN but were afraid of the tools and setup you have to do prior to writing a single line of code, fear no more. There is a service that allows you to write and run native iOS/Android apps in browser as you type. Basically, JSBin for React Native. Meet rnplay.org. It also allows you to switch and try apps on your actual native device.
Behind the scenes there is Appetize.io service that streams iOS or Android simulator directly into your browser. As far as I know there are no real devices involved, but native simulation is a great start. In fact, React Native official documentation now uses the very same embedded simulation for illustrating the examples. Go ahead, run some native iOS apps in your browser.
Tinker. Release. Repeat.
Another interesting initiative is React Native Package Manager – RNPM. Managing modules with native dependencies is not easy at the moment, and RNPM is here to help. There are rumours that it might even be included as part of RN offering (and it is already mentioned in the official RN documentations as a preferred way of linking).
JSS builds on top of @Vjeux‘s idea that you can specify CSS properties of HTML elements as part of JSX declaration (which compiles into JS). The original approach lacks quite a few things like media queries and pseudo classes support. Christopher himself said that you should use common sense and combine inline CSS in JSX with conventional stylesheets.
Not anymore. JSS supports all CSS properties, can easily be used with React components, or simply compiled into CSS. It also offers dead code elimination, name scoping, rule isolation and fast selectors. It is even claimed to be faster than conventional CSS. And if you like idea of plugins, it has them too. The selection is far from PostCSS plugins catalog, but give it time and some crayons.
Apollo by Meteor
GraphQL is a great way of communicating data from backend to clients. It also requires a bit of setup. It is just a language, as a developer you will have to implement server side and client side support. On a server side it is likely that you’d use GraphQL layer as an opportunity to unify multiple RESTful (or otherwise) endpoints into a single GraphQL API. On a client you would in turn create and consume GraphQL requests either directly, or with something like Facebook Relay.
This is where the Apollo project steps in. Apollo server helps you consolidate multiple data sources into a single GraphQL endpoint. Apollo client help’s you to consume that endpoint, provide pagination, reactivity and optimistic UI updates.
Both are still very much in development and not really ready for prime time. There isn’t even much details on how exactly it’ll work.
MobX (former Mobservable) allows you to observe changes in things and act when those changes are happening. It uses ES6 decorators to help you wrap existing things (like app state and React components) into observables and computables. Observables are things that are being watched for changes. Computables are the things that must be updated as a result of a change.
If you choose so, MobX can be used as a Redux alternative. Like Redux, it promotes pure functions and is built on Functional Reactive Programming principles (FRP). You define observables and things that can change as a result, and then sit and watch how things are happening automatically.
A cube that projects tweets. Bonus for the cat userpics.
It would be a perfect companion to the throwable cube mic.
The place was called Pllek. From the official description:
This post-industrial spot with a beach-like atmosphere offers one of the best panoramic views of the IJ River… Pllek also is home to Amsterdam’s largest disco ball at night.
To get there you cross the IJ river on a ferry from Amsterdam Centraal station. The place is pretty bizarre, with a rusting Soviet submarine in the bay, cranes, sea containers and a chilly wind. I even made a short film on getting there and back.
I get the feeling that organisers didn’t expect the weather to be so cold in the mid April – it was pretty chilly inside. There were lots of developers from Netherlands, but also from all over the Europe. It was a chilly, crowded, but very friendly event with nice snacks and coffee. It was also first of a kind, and they do intend to continue next year.
Chilly weather didn’t affect popularity of the (free) ice cream stand
This trip was possible thanks to Red Badger’s learning budget perk. Join us, and you’ll get it too!
For now this is the last Fluent event in San Francisco. It was announced that next year will be in San Jose, and there is also one more Fluent this fall coming up in Amsterdam.
Worthy talks available to watch
All keynotes from day 1 and 2 are available online. To save your time, here’s my favourites:
Douglas Crockford from PayPal also did an intro on The Seif project – PayPal’s own reinvention of the Internet. They are pretty early stage, and their vision is debatable to say the least. They do have good intentions.
General trends and feelings
Last year React / Node combo was something of a novelty, a curious thing to learn. Netflix was doing introductory level talks on React and why they chose it. This year React / Redux / Babel / Node is the default. Dan Abramov’s name was mentioned in every other talk. Interestingly, Facebook was pretty much absent from this conf – which is understandable since they are busy having their own React-dedicated events. Notable cool guys on the ground included Google, Netflix, New Relic, Uber, and Léonie Watson doing an epic talk on a11y.
A lot of talks were about interesting ideas or wishful thinking, less of production-ready reality. I suppose this is what webdev is about – there is no platform really, more like a herd of clients and engines somewhat held together by loose rules and standards.
Two days of talks
The keynotes were followed by five tracks of talks to choose from. Sometimes it was hard. These talks are not available online and will be later published and sold by O’Reilly. I’m going to handpick some quick takeaways from the sessions I attended.
Accessibility is still very important. There are lots of different disabilities, and addressing such users is more important than addressing old browsers. Different OS platforms contain different a11y APIs, but with regard to the Web, semantic HTML combined with basic ARIA markup gives a huge heads up for a11y tools to read through your page correctly.
Few personal takeaways:
Browser in addition to DOM tree creates separate a11y element tree based on your markup
aria-live=“polite” element creates live region on the page, when action on one element affect content of other element. Every time content of live region is affected, screen reader would announce that as soon as it changes. Generally screenreader is unable to jump around the page, and cannot be in two places at once.
role="complimentary” when content is incidental but related to the content on page (similar to aside HTML tag)
Use tabindex=“0” to allow keyboard focusing on otherwise unfocusable elements
Léonie Watson did a highly practical talk on semantic HTML and ARIA roles. Her screenreader for some reason failed to function when connected to the projector, and so she did the whole talk from memory, without being able to see any slides.
There was also an announcement of the upcoming Web A11y free course on Udacity.
Google did a presentation on their vision of web apps and software delivery to the end user. In a way from the user’s perspective there is no difference between web apps and native apps, as long as they behave in exactly the same way. There’s also a negative trend regarding users buying new apps from App Stores, and in general they use only three native apps 80% of the time. Google wants to address issues with web apps lagging behind native apps in terms of offline availability, home screen shortcuts, direct to full screen launching and push notifications. Some of that stuff is already solved. The biggest missing piece is probably offline access, which they claim can be resolved with service workers and an extra layer that intercepts all requests and behaves according to the network availability.
As an avid npm user I spend a good chunk of time every day typing npm into console. There was a talk with various hints and hidden features that might be pretty useful.
npm install when you are offline – npm contains a (huge) library of modules on your machine and can install the relevant module even when you’re offline from the local cache. To do so run npm install --cache-min 999999.
npm version [major, minor, patch] will bump version of your npm package and save it in package.json file. You can even auto-commit this with npm version major -m "bump to version %s”
npm prune – get rid of all packages in your local node_modules folder that are not explicitly specified in the package.json
npm outdated – quickly check for old and outdated packages in your app
NSP is great for maintaining 3rd party security in your Node app (although it is known to be down from time to time).
There were two somewhat orthogonal talks on aspects of monitoring your production apps.
New Relic did a presentation on NR Browser, which is a handy way of getting data about how your users actually perceive the app. It gathers everything that a normal browser would, including JS errors, and time to load pages to the client based in various locations. Server side pages usually load 10-20x faster than client side. There are also a number of most strange JS related errors that can be experienced by users and their (derelict) browsers. You can also detect bad deployments by monitoring spikes of client errors.
Shape Security did a talk on dark traffic. According to them, 92% of the global web traffic belongs to non-humans, which is sort of a pity because you still get all the monitoring alerts, but none of your human users are actually affected. Here lies an interesting question of traffic origin detection. You are likely to only care about human users, but they are a minority nowadays. Most of the bots will also try and pretend to be real humans the best they can. Bots will try to authenticate with real usernames / passwords, which are quite openly available on sites like Reddit/r/pwned, or less openly traded for money on the dark net. Since most users are using the same password everywhere, bots will often succeed in signing in, then will crawl everything they can, and move on to the next site.
Falcor by Netflix
Falcor deserves a dedicated blog post. It is Netflix’s answer to GraphQL and Relay by Facebook – central store and dynamic data fetching combined with request optimisation. Its implementation however is distinctively different from both GraphQL and Relay.
@jhusain did an impressive job to a full house explaining Falcor while live coding an app and getting things to work. We are using GraphQL in our production apps, so my angle was obviously on how Falcor is compared to what we already have. Here are a few takeouts:
GraphQL is a query language that allows you to request any amount of resources. With Falcor you request either a single resource or a known range. There is no way in Falcor to ask something like “give me all you have”.
JSONGraph for data
There is no schema in Falcor – as opposed to GraphQL where you must specify types. This works for Netflix since their production app has something like 6 types of resources.
Falcor might be more lightwave and easy to start
Current implementations of Falcor are in Node and Java. There is internal implementation for iOS which is not released yet.
I shall come back to this topic and write a more comprehensive blog. Other relevant swag
We also attended a full day of workshops. The first half of the day was about implementing desktop apps with Electron, then we did a session on writing your first language compiler, and finally real time drawing on HTML canvas. Electron was probably most notable out of the bunch – in about three hours we ended up implementing two functional desktop apps from scratch. Roman is going to write more on this topic.
Electron provides you with tools to make native OSX / Windows / Linux desktop apps while using the familiar stack of Node and React. But unlike conventional web apps, you also get full access to the filesystem, no CORS restrictions and the ability to integrate into the system menu. If you always wanted to get your app behind the system tray icon, with Electron you finally can.
The general format over the conf was 30 min talks followed by 15 min breaks. After two or three talks there would be 30 min break. In the middle of the day there was an hour lunch break. Everything started at 9am and finished around 6pm.
Breaks were filled with extra activities you could choose to attend. The main attraction and largest source of swag was the exhibition hall, filled with companies presenting their products and giving out freebies. During the last two days the organisers also moved coffee and snacks to the middle of the exhibition hall.
I should probably mention – we were fed pretty well, considering the scale of the operation.
In the main foyer they also tried to get introverted software devs to talk to each other by having topical meetups, speed networking and lightning talks.
Being primarily a book publisher, O’Reilly brought a bunch of authors signing and giving away free books. I got a couple too.
This trip was possible thanks to Red Badger’s training budget programme. Me, Roman and Kadi had an amazing time, despite the daily dosage of rain. This time I also did daily video log episodes covering our full journey outside of the conference. Yes, we had some fun.
I enjoy Fluent mostly because of the variety of topics covered. Writing compilers, programming GPU, WebVR, fending off the evil bots, deploying clusters of containers, debugging performance – there’s something for everyone. So, thanks O’Reilly for making this a reality once again!
If you like the idea of an annual training budget, trips to conferences like this and a big focus on learning, Red Badger could be the place for you. Check out of current vacancies here.
Using FitBit and various apps and APIs to create a personalised health-tracking system.
Chrome DevTools deep-dive
The talk that really grabbed my interest, was the morning keynote session on the second day, from Addy Osmani on Chrome DevTools. DevTools is something I use every day, and essentially take for granted. There are features that I use all the time, and other areas that I don’t touch. I’m ashamed to say that I haven’t looked at the docs in a very long time, and am very behind on what new features there are to use.
This talk highlighted some really useful tools that I’m excited to start using. Some have been around for a few months, others are so new that you can only access them by turning on the DevTools experiments. The whole video is definitely worth a watch, entertaining as well as useful. Unfortunately I can’t link to specific parts of the video, but I’ve done a summary of the features covered, and where you can see them in action on the video.
Security Panel – 4:23 – New – check for valid certificate, secure origins and list the domains it’s relying on.
Service Worker Panel – 5:14 – New – Can visualise the entire lifecycle of events around your service worker.
Filmstrip – 10:19 Allows you to grab screenshots of the page rendering, and see at exactly what time the elements of the page loads.
Throttling – 11:41
Custom Network Throttling – 13:25
Block requests – 15:35 – New Allows you to test what is actually slowing your page down.
Timeline – 24:25 Record timeline and check for jank.
Filmstrip screenshots – 26:27 Film interactions with the page, after the initial load. Can see each screen, and identify aspects responsible for jank, or slow-down. Really helpful for analysing animation.
Aggregated details – 27:47 Breaks down exactly where time is being spent. Able to easily see what is causing the slowdown, and will attribute it to a script or a domain.
Paint profiler – 33:05 Allows you to record interactions and see how the browser builds up the page. Can look at why something is taking a long time. You can see the exact browser draw calls to see how the pixels are painted.
Animation inspection – 36:05 – New Access to timeline of all animations. Can control playback speeds, and play round with timings without having to edit your actual code.
Cubic Bezier Editor – 37:30 Cubic bezier editor, directly inside of devtools to allow you to tweak animation. Comes with a preview, so you can see how the changes will affect the animation.
DOM animation changes – 38:46 Elements on the page that change with an animation are highlighted, so it’s easy for you to see what’s going on.
Colour palettes – 39:40 Eye-dropper tool. Colour palettes tool picks out the colours used on a page, and allows you to play around and tweak them and see the effects. Also able to save your own colour palettes.
Search selectors – 41:05 Allows you to search for elements without knowing the exact classnames
Event Listeners – 41:50 Allows you to see exactly which events are bound to a particular node.
Framework Event Listeners – 43:08 View event listeners registered on DOM nodes even if they’re using a js framework. If you’re trying to debug, it’s not helpful to jump into the library code, you want to see what’s happening in the code you wrote.
Edit HTML in the console – 44:10
Inline variables – 45:56 Can check a setting to display variable values inline while debugging. Does away with the need to console.log everywhere – you can just see your variables inline.
Proactive Compilation – 47:32 If you want to run your code directly inside the VM, it will give you instant feedback on errors.
Blackboxing JS libraries – 48:13 This allows you to right-click and black box a library that you’re using. So when you add a breakpoint and step through, you can step through your actual code, instead of the source code for the library. You can actually set patterns that you want blackboxed, in settings, so that you don’t have to right-click and blackbox certain libraries each time.
ES2015 Promises inspector – 50:24 – new Shows you where your promises were defined, and when they get resolved, or if they are rejected.
I’m looking forward to incorporating some of these new tools into my workflow. Being able to see exactly how the page is rendering, and at what point is really useful for identifying what is causing lag. The less you have to change context and switch between code and browser the better, so I think things like the animation bezier editor, and inline variables are going to be massive timesavers. The DevTools docs are definitely something I’ll be visiting on a regular basis in future to keep up to date on all the new additions.
Red Badger offers an annual £2,000 training budget to go to conferences like this. Sound good? Then come and join us.
Too often in my career I have found that testing is exactly like water, gravity or Google: you don’t realise how important it is to your life, until you suddenly lose it for some reason. But to the people behind the yearly TestExpo conference, testing does seem to be everything – they dream of a world in which time and money doesn’t matter, testing is done for the sake of perfecting quality, and it’s more an art than a barely acknowledged necessity. Which is quite far from reality, so the conference was subtitled “We have a testing dream”, hence the title of this post (no, I’m not nearly that poetic on my own).
Honestly, I don’t have a testing dream. I have a nightmare though, one that I lived through, crafted by Morpheus’s darkest testing environments and emotionally scarring choices of software. What got me through those times was the idea that testing is precious, amazing and artful, and can be a continuously interesting experience. So I was really hoping to get in touch with my testing dream at TestExpo, and did my best to write up the ideas and tidbits that stuck in my mind after the talks.
So what did I walk away with at the end of a day spent surrounded by the dreamers of the UK’s testing professionals?
The dawn of DevOps testers.I’ve seen people break down in a fit of rage when someone refers to themselves as a “DevOps developer” or anything like that. Yeah, DevOps is a culture, not a set of tools or titles, but it leads to a certain way of working and organising tasks, which does affect the way we do our testing. At huge companies like IBM, according to Glyn Rhodes, there is an emerging new role which differs from both the Traditional Tester (manual) and Technical Tester (automated) roles, and involves tasks that incorporate a new way of thinking about practices and policies in a DevOps enabled environment. In any case, that’s a new label on Linkedin we should look out for.
Agile is still a hip new thing. You’d think DevOps is the new Agile, that is, a fancy buzzword that sells tickets and ushers in the interest of every manager leading a development team. But it turns out, Agile is still something that some bigger companies struggle with! As natural and effective as it feels to startuppers and the younger generation of software craftsmen, corporate environments take ages to change, even if that change is for the better. So while you might want to forget (or rather never look up) what Waterfall means, you should still not take Agile for granted. Consider it a gift that keeps on giving.
It’s not just you, mobile testing sucks. No one who ever looks around the tube on a crowded Tuesday morning is surprised if I say, there’s a myriad of different devices actively on the market, with differing hardware capabilities, screen sizes and diversely crappy OSes. If you take into account all variables, like the device itself, the browser in use, the OS version and everything else, you can easily end up with almost 19.000 different setups showing up in your metrics in just a year! Which is horrifying. But comfortingly, Christian Breitwieser, the specialist talking about his experiences with the Sisyphean task of mobile testing, shed some useful insight and made us all feel a bit better about sometimes being lost in the midst of rounded screens, JS disabled browsers and misbehaving Samsung phones.
Roundtable discussions. They are apparently very useful! Also, they’re not for me. It’s a personal thing, on some days I just don’t feel like talking to people… And it was one of those days.
Us testers are not special. Nah, of course you are! But when it comes to the trends and challenges of our path, we are not that far from developers. Though our daily tasks differ, newly introduced methodologies and swiftly evolving technologies not only affect the way software is developed, but also how it’s tested. The closer you work with automated tests, the more apparent it becomes – learning to use new tools, getting familiar with the trendy languages, wrapping your head around the changing requirements is a challenge you share with your more development-inclined peers. In fact, it’s getting increasingly hard to even separate these two roles, mostly because of my next point, which is:
Automated testing is on the rise.You think it’s self-evident, right? Not really. There’s still a general attitude towards testing that it should strictly be a manual, purely user-mimicking chore, and that anyone diverging from clicking through a UI is mostly just a developer in disguise. But automation is gaining momentum and recognition in the consumer facing world. Partly because of the sheer volume of work that mobile testing entails, but mostly because it really is a practical and powerful addition to the irreplaceable manual testing. We now have more tools and means to carry out automation than ever, and even the slowest moving corporations are starting to see the value in automation teams, which makes me really happy, for a number of reasons. But that might become a blogpost of its own in the future.
And that’s all the fragments I can remember of the dream shared at TestExpo 2015. Here’s to another great year of testing!
Do you have a testing dream, or a living nightmare you’d like to escape? We are hiring! Come join us in making the world a better place testing and breaking software!
Conferences, especially those based around management and operations, are so often focused on the “business” of things. How can you increase your margins? How can you get the most out of your workforce? Where is the next big wave that will take your company in to the stratosphere? We rarely talk about people as individuals, instead seeing them as little cogs that we fit together until we have a machine that, while not well-oiled, is at least less likely to fall apart.
Lean Agile Scotland 2015 was a pleasant surprise on all fronts. While they claimed not to have a theme, there was a definite trend of talks about actual human beings. The opening keynote from Richard Sheridan set the tone with a guide to injecting “joy” into your workplace. I had half expected something a little bit hippy dippy and fluffy, but what we actually got was a practical, achievable model for making your workplace a happier place. I was pleased to note that much of what was talked about it already in action here at Red Badger. I was going to say that all we were missing was an office dog, but even that has been remedied this week with a visit from Winston!
Bookending the first day was a talk about how happiness is exactly the wrong thing to aim for. While this may sound like a complete contradiction, it actually complemented the first talk beautifully. We all get so focused on chasing a mood, something that cannot possibly be maintained, that we tie ourselves up in knots. Instead we should be looking for an internal balance and sense of purpose. Sounds simple, but so much of what they were saying rang true for me that I am already looking inwards and trying to figure out how I can apply the same concepts to myself.
The focus on personal growth, culture and introspection was one that I feel I needed, and one that came at exactly the right point. I finally feel like I’m doing well at my job, but having the confidence to say that doesn’t even remotely come naturally. I think the most profound turning point of the week was the workshop “exploring your courage and vulnerability”. As a noisy introvert (the more anxious I am, the more words I use) I often feel fairly stranded at big events like this, but Gitte and Tobbe’s workshop made me feel like part of a really great community, and made me realise that I often trip myself up just by virtue of assuming people don’t care about what I have to say. I’m lucky to work at a company that accepts me and mentors me, so it’s silly that I still hold myself back.
Of course it wasn’t all soppy, there was some pretty hefty technical and intellectual content in there as well. One of the talks I unfortunately missed but intend to watch back is Matt Wynne’s “beyond BDD” talk. One of the hallmarks of a great conference is how much you feel you missed, and this, along with Chris McDermott’s “Systems all the way down!” talk definitely fall into that category. On the philosophical end of the spectrum, Will Evans wins the award for most confusingly interesting talk of the conference, with his talk “Heretics, High Priests and Hagiolatry”. You know you’re in for a rough ride when even the title contains words you don’t understand!
I also conquered some personal battles by standing up during Chris Matts’ Friday morning keynote and addressing the audience in response to a call for audience participation. It might seem tiny, but for me it was a huge step towards public speaking and wouldn’t have been possible if the preceding two days hadn’t been so inspiring.
I have a huge amount to still process from the conference, and could likely write a blog post on every single talk that I attended. However, I definitely have one overriding takeaway from the whole thing. That Red Badger are doing things right. I’m not saying we’re perfect, no company is, but the growing and learning we’re doing is going in the right direction. I had continuous swells of pride as people talked about what they were trying to do, as I knew that in many cases we are already doing it. Similarly, things that we aren’t already doing, I know we have a business that will be willing to listen.
I also learned that Hagiolatry is the worship of Saints, but I haven’t yet worked out how to use that in a business context.
Fancy working somewhere where things are done right? We’re hiring!
It’s 4am and the jet lag has woken me up far earlier than I would have wanted. I open the curtains and am greeted with pitch blackness so I pick up my phone and check on the twitterverse with whatever limited phone signal Yosemite has to offer. By 6am the light is beginning to creep over the High Sierras and I’m itching to get outside, so I throw on my running gear and escape. The air is saturated with the sweet smell of pine but it’s too cold to stop and admire, so I start running in any direction.
After a few minutes I notice the lack of noise around me. There is nobody around for as far as I can see or tell, and I seemingly have the entire national park to myself. The only noise penetrating the forest is the sound of early birdsong and the rushing of a waterfall, so I follow the latter.
When I arrive at the base of Yosemite falls the place is deserted. It would be only later the same day that I discover this area is usually packed with tourists taking photographs and admiring the view. But for now it’s just me and the tallest waterfall in North America. I stay at the falls for a while, it’s difficult to leave, but as the morning mist begins to fade I make my way on and start running in the direction of Half Dome peak with an extra spring in my step.
But why was I here? This wasn’t in fact some idyllic spring holiday I had taken, but an Apple conference. They called it ‘Yosemite by Cocoaconf’.
CocoaConf is a touring training conference for Apple developers based in the US, and has been going on since 2011. Since Apple started naming its operating sytem OSX after Californian locations it seemed obvious that somebody at some time would organise a pilgrimage to one of these, but to my knowledge nobody had. CocoaConf just happened to be the only conference ambitious enough to attempt this with OSX Yosemite. Who knows whether this will become a theme for the next versions of OSX, but we all hope they pick somewhere nice. On two separate occasions during the conference I heard someone say “Thank god they didn’t name it OSX Oakland”.
The theme of this conference was unlike any I had been to. Sometimes feeling more like a spiritual getaway than a tech conference, the talks at Cocoaconf Yosemite were more focused around self improvement for you and your company. Talks ranged from tips on managing your team and projects to learning how to avoid burnout, to the history of the Gregorian calendar; all of course within the context of Apple and its products.
There were also some more technically focused talks in the mix including Christa Mrgan’s excellent walk through designing interesting looking apps for iOS8, Andy Ihnatko on the history of wearable devices and expectations for the Apple Watch, and Andrew Stone’s wacky talk on the lifestyle of working for Steve Jobs at NeXT in the 80’s.
However, the focus of this event was not to learn or discover new technical skills. This conference was more focused on bringing together a set of likeminded people to discuss the platform they love to build upon, trade war stories from their careers, and share ideas. Whilst sharing ideas with people of different backgrounds can lead to new and interesting revelations, I came to realise that sharing ideas and philosophies with likeminded people can often strengthen and expand those you already have.
Every person I met seemed to be at the top of their field, working for large companies and startups alike, all with their own perspective on building apps for the Mac and iPhone. And whilst meeting people in the industry was great for professional networking, I was also very pleased to meet some familiar voices in the world of podcasting including Guy English, Serenity Caldwell and Jason Snell.
In addition to the location and talks at Yosemite, the third main attraction was the attendees themselves. The conference had a very small audience of approximately 80 people, and every one that I met had fascinating backgrounds and views. Networking of this kind was made even easier by the included daytime activities that had been organised to help attendees explore Yosemite valley. For example, a guided photography walk around Yosemite falls with TED conference photographer Duncan Davidson allowed me improve my photopraphy skills and trade shots with fellow attendees and speakers alike. Unlike most conferences, networking was never the primary goal but instead happened entirely by accident through a mutual enjoyment of the location we found ourselves in.
I would usually look for a more technically focused conference so I approached this one with an air of skepticism. But I found all of the talks to be fun, interesting and dare I say it, inspirational. I would almost go as far to say that in comparison to a traditional conference where there is no guarantee that I might come home learning anything new, I gained more value coming home from a conference that made me see the work a do a little differently and with a boosted enthusiasm. And what better place to feel inspired than one of the most beautiful national parks in the world. A wonderful experience for someone in any industry.
Needless to say, I came home from my time at Yosemite hungry for more. One day I’ll go back and explore all the High Sierras have to offer in full. But for now I encourage anyone to consider attending a conference not quite as focused on a particular language or technology, but on your profession as a whole. You might find it will help you to see your work differently for months or years to come. And who knows, you might just have fun in the process.
Red Badger offers an annual £2,000 training budget to experience things like this. Sound good? Then come join us.
When assessing conferences for myself, I tend to break them down in to “doing conferences” and “thinking conferences”. The former being skewed more towards picking up practical tips for day-to-day work and the latter being more thought provoking, bigger picture, ‘I want to try that’ kind of inspiration.
Joe McCann of Mother New York gave a high-level view on how mobile is increasingly reshaping how we interact with the web, with the world and with each other. Use of phones as payment methods in Africa, where availability of bank accounts is challenging, has reached around 80% of the population with systems such as M-Pesa. And SMS, the bedrock of mobile network operators’ revenue since the early 90s, is being disrupted by what are known as “over the top” messaging services that use devices’ data connections. These are familiar to us as iMessage and Whatsapp, but also growing at a phenomenal scale in the far east with services such as Line which is offering payment, gaming and even embedded applications within its own platform. Joe’s insight from a statistical point of view was fascinating, but it didn’t really feel like many conclusions were drawn from the talk overall.
Kenneth spoke about the web development workflow, a subject he blogged about earlier in the year. His premise was that the increasing complexity of browser-based debug tools, while helpful in their purpose, are only really fixing the symptoms of wider problems by adding more tools. We should be able to debug any browser in the environment of our choice, and he demonstrated this by showing early work on RemoteDebug which aims to make browsers and debuggers more interoperable – shown by debugging Firefox from Chrome’s dev tools. By working together a community on projects like this we can continue to improve our workflows.
My brain, I have to admit, was fairly fried in the early afternoon after an epic burger for lunch from the barbeque guys at The World’s End, a spit-and-sawdust boozer round the corner from the conference venue. So the finer points of Ana Tudor’s talk on some of the more advanced effects you can do purely with CSS animation were lost to struggling grey matter. Suffice it to say, you can do some amazing stuff in only a few lines of CSS, in modern browser, and the adoption of SASS as a pre-processor with its functional abilities makes the process much easier. It’s also brilliant that Ana came on-board as a speaker after impressing Remy in the JSBin birthday competition, and a perfect demonstration that participating in the web community can have a great pay off.
The finale of the day, and a great note to finish on, was Jeremy Keith speaking about “Time”. Not really a talk on development, or at least not the nuts and bolts of it, but more of a musing about the permanence of the web (if indeed it will be so) interspersed with clips from Charles and Ray Eames’ incredible short film, Powers of Ten – which if you haven’t seen it is a sure-fire way to get some perspective on the size of your influence in the universe.
Definitely a thought-provoking end to the day. As someone who has done their time in, effectively, the advertising industry working on short-lived campaign sites that evaporate after a few months (coincidentally Jeremy mentioned that the average lifetime of a web page is 100 days) it has bothered me that a sizeable chunk of the work I’ve done is no longer visible to anyone. On the other hand I have worked on projects that have been around for a long time, and are likely to remain so, and I suppose in the end its up to each of us to focus our efforts and invest our time in the things that we ourselves consider worthwhile.
Last Friday Joe and I attended All Your Base in Oxford “a database conference for web developers”. There were speakers from MIT, Lanyard, Hailo and Box to name but a few.
On the conference
All Your Base was a really well organised and friendly conference, both in the lead up and on the actual day. The food and coffee was decent throughout and the ready supply of bottled water appreciated. I liked the fact it was a “small” conference with a single track and that each slot was just 30mins. I had hoped that would mean the speakers would jump straight into the meat of their talk and skip the info we can all read in a FAQ or getting started guide to any of the databases under discussion. Unfortunately that wasn’t always the case, which made for a number of less than inspiring talks. By far and away the most interesting talks were those about something that had been done with the database, rather than explicitly about the database. After all, everyone there had chosen to attend a database conference, so I think it was fair to assume we were all familiar with nearly every database on show.
That said, I appreciate the huge effort that the organisers clearly put into the day which they obviously cared about, and for that, they’re to be congratulated.
Who uses what?
I always find it interesting to know who uses what technology and why. Some of the most interesting talks were on how startups had evolved their data solution, be it by moving from one database to the next, or by evolving their implementation on the same technology.
Hailo started out on MySQL, PHP and Java, before deciding to move to Cassandra (originally developed at Facebook) for greater flexibility; they clear $100m every year and take a taxi booking, on average, every 4 seconds. Interestingly, they’ve also chosen to use some Go and ElasticSearch on the backend. GoSquared had a similar story of starting out on the LAMP stack before being forced to find a solution as they were hit by success and their backend struggled with the write levels required. They first tried moving to MongoDB, before too opting for Cassandra (with Redis).
On the flipside Diaspora, an open-source, distributed social network started out building their solution in Ruby and backed by MongoDB. When they discovered that the very essence of their data was a better fit for a relational database, they moved to MySQL. Personally I would’ve suggested their data was a better fit for a graph database, but the speaker seemed to dismiss this, stating they were still too “experimental”. This, despite the fact Neo4j (for example) has been around for 2 years longer than MongoDB, is used by all these people, and a social network is the archetypal application for a graph database. But I digress…
Finally, Box showed the greatest staying power (most un-startup like!), being as they started out on MySQL and decided to stick with it, despite the lack of natural horizontal scaling support. They ended up implementing their own sharding solution, allowing them to scale as their customer base rapidly grew.
I thought it was a shame that there was no “real world” talk on Riak. Basho, being one of the main sponsors, gave a talk about Riak, giving us some useful insight (don’t use Riak unless you need at least 5 nodes!), but I know there are some really intensive implementations based on Riak out there, and that would’ve helped bring things to life a little more. That said, I’m looking forward to reading A Little Riak Book that I picked up and finding an opportunity to put that knowledge to use.
The best line
The best line of the conference goes to Tim Moreton of Acunu who provide real-time analytics for Cassandra databases. “No one applies for a job with 10 years of Cassandra experience on their CV/resume”. I may have paraphrased that slightly, but I just love that thought. That’s why we stopped asking for specific language experience when hiring people at Red Badger, and instead ask for a “strong background in a mainstream language”. Most ideas and concepts aren’t new; it’s how we apply them that evolves. A point that was also nicely reflected in the first talk of the day, where Neha Narula (formally of Google, now at MIT) pointed out that Materialized Views, which have just been implemented in Postgres 9.3, were first theorised in a white paper from 1986.