Head of Developer Experience & Relations at Hookdeck
The number of companies looking to build developer relations teams is on the increase. But what developer relations means to each company tends to differ; some hire advocates and some hire evangelists, some are looking to market to developers and others see developer feedback as key to the success of their product. What's the difference between these job titles? How do you know the roles and activities that will work best for your company?
There are lots of real-time frameworks which exist to allow us to build real-time features and functionality into our apps. However, I often see developers who are excited about discovering real-time framework X and then proclaim now to find a use for it. Every single application has real-time data and every single application could benefit from real-time feature driven by that data. So I felt compelled to write a series of posts.
So, you want a real-time API. Where do you start? You're convinced of the benefits of a real-time API and know what data you want to make available through it. But you've probably got a number of questions playing on your mind...
I like retrospective-style posts. When writing them I get to look back at the things I've done and am often surprised, pleased and encouraged to improve. I also enjoy reading retrospective posts of others, particularly from those who are doing similar things or those that I look up to and learn from. Hopefully the majority will forgive the indulgence of a personal retrospective and a few - like me - will find it interesting and useful. If you're considering a developer evangelist role this may provide you with some insight. If you're already working in a similar role then it might be a useful comparison. I'll also do a summary retrospective retro including a few stats, and cover what some my plans are for 2015 Q2.
Back in February 2014 I wrote a list of 10 predictions for realtime web technologies in 2014 (well, it was 10 and 2 bonus items). In this blog post - sorry it's not 1 year on - I'll review they and provide my thoughts on whether those predictions were correct or not.
In this post I'll take a look at why HTTP-based transports are still used by realtime frameworks and services, why don’t all solutions use WebSocket, and which transports are best for different realtime use cases.
The callback has been invoked, the Promise fulfilled. I'm super-excited to be rejoining Pusher to head up evangelism and developer experience.
It’s interesting how I used to always talk about the Real-time Web and Real-time Web Apps but now it really does need to be Real-time Internet Apps because IoT (The Internet of Things) now means we need to think beyond what we would traditionally class as Internet technologies. In this latest talk I cover realtime web technology communication paradigms and use cases for 2014 and beyond.
![[Updated] The State of the Componentised Web preview image](/images/web-components/web-component-status.png)
The idea of building applications out of a number of independent components isn’t anything new. But with Web Components on the horizon I thought it would be a good time to look at component-based application development, how we benefit from taking this approach, how we can build our applications in this way using existing technologies and how we’re likely to be building our front-end web apps in the future.
Nearly two months in, I thought I'd publish 10 realtime web technology predictions for 2014 based on how it developed in 2013 and the trends I've seen so far this year. I've added two additional bonus predictions for good measure.