What I plan to learn in 2019

21 December 2018

Another year, another set of new shiny technologies to entice you! At Cogent, we recently asked each other what we were planning to learn in 2019. Below is my list: you’ll find a mix of front-end and back-end technologies, as well as some marketing related one.

It’s tempting to learn anything that looks compelling and interesting in any way. I am trying to be a little more particular and choose things that have some maturity. Or things if new, that I think will be here to stay.

One thing I’m keen to learn through is by teaching. To finally have a proper somewhat regular blog and make screencasts. I would start with a blog post, get feedback from people, then record a lesson or walkthrough to share on YouTube.

When I was teaching junior programmers I felt like lots of my knowledge was strengthened by having to articulate concepts that I just took for granted. I’m curious how things work generally so will want to know, but there’s always something that I gloss over — “yep this just works, and I don’t care why or how to do my job”. So it was great to sit down and study these concepts and then explain them in a way that didn’t lead to 35 confused faces.

After wondering if I should focus a blog on a particular topic, I’m thinking I’ll just write about what I’m working on and not worry about if I’m not satisfying ‘web developers’ or whoever with every single post.

What I plan to learn

  • Cloudflare Workers and what they best suit
  • Architecting apps well with the next-gen React
  • Optimising web apps to be faster and leaner
  • GraphQL
  • Golang and what it best suits, maybe compiling it to Webassembly
  • Google App Engine and Datastore
  • Elixir and what it best suits
  • Whether Gigalixir is worthwhile
  • Maybe Websockets and what they best suit
  • Will try CSS Grid again
  • Probably more iOS App development
  • Latest Swift changes
  • Possibly machine learning
  • How to run and launch open source projects
  • Marketing
  • How to plan and write and record screencasts — after teaching I find presenting to a group of people much easier and engaging for me than sitting down and cranking out words
  • How to not over engineer my blog and use something boring like WordPress (Done! You’re reading it)

What I plan to not learn

I find it helpful to have a no list too:

  • Not Reason
  • Not Rust
  • Not Android
  • Probably not React Native unless for a project, then yes
  • Less Node.js
  • Not Electron

I often made ‘no’ lists when teaching for what would not be covered, as it helped to focus the lesson.

What are you planning on learning in 2019? Let me know by tweeting me.

Understanding state

17 December 2018

State is what is known by your app.

In a web app, state refers to local state. It only knows a subset of all information. And that information is from a certain point in time: it might have changed since.

In a JavaScript web app, your user’s web browser talks to an API. The API has its own state, usually stored permanently in a database.

(In a server-side web app like one built with Rails, your application usually talks to the database directly.)

So local state. It’s your web app’s state of the world at a certain time. That world depends on factors, such as which account is signed in, or perhaps whether the user is not signed in, which page they are looking at, and what capabilities their account has.

Loading state

For your web app to display information, it has to first load it.

So your web app loads this initial information, and this becomes its state of the world. If five minutes later, the latest information is desired, it must load it again.

Making things more complicated is the fact that there is not just one set of information.

Take Instagram as an example. There is the feed of photos. As you scroll through the feed, more photos are loaded. For a good user experience, photos are loaded before you reach them. But still, only a subset of photos are loaded. It would make little sense to load your feed from the top to the very bottom, as it would likely be hundreds of megabytes of information in total, and be a huge strain on Instagram’s servers to collate all that information.

Instagram offers more than just a feed. Your can explore and search for photos. You can take or upload a photo. You can see a list of activity aimed at you, such as recent comments or likes on your posts. You can also look at your own profile, with the photos you have posted.

Depending on which section you look at, and how you interact within that section (scroll, tap to see details, tap to go to someone’s profile), new information will have to be loaded. The app’s state of the world expands. It goes from a small subset of data, to a larger subset of data.

Managing this state, and coordinating the loading of additional or fresher state, is one of the key skills in building web apps.

A step back. A command line app.

Any app that has an interactive user interface has state. Think of PowerPoint and the file that is being viewed, the currently active slide, whether that slide is being edited, viewed with slides listed to the side, or is being presented. All of those variables are state.

A command line app also has state. The less command efficiently reads from a file, only presenting a slice of it that fits in the terminal window. As the user scrolls and down, the app’s state is updated with the offset slice into the file.

A command line app is a useful starting point, because many operate in the same manner as web apps based on React. In React, the application is built by deriving the entire user interface from state. The application developer declares their intent for what should be displayed on screen given a certain state. If the state changes, then that codified intent is used again, but with the updated state. And so on, every user interaction usually affects the state in some way, and the user interface is updated quickly to respond. This pipeline approach is popular with games, where the displayed image is rebuilt again and again many times a second, fast enough to produce fluid motion.

The alternative is to intertwine the state with what is being presented. As new information comes in, it is not a simple change to state. It is a manual change to what’s on screen too.

A pipeline is like to correct a typo in a printed document, making the change in software, throwing the old copy away, and printing a new fresh copy. Fortunately, in an app built totally with software means that nothing is wasted.

An intertwined approach is more akin to correcting a typo by using whiteout and a fine pen. It’s much less wasteful, but takes much more effort and skill than just printing a new copy would be. The same is true for apps.