16 Aug 2016

So Much to Learn, So Little Time

My birthday is coming up; looking back on what I learned about looking forward on what I want to learn, I noticed a pattern. Each year I spend revolving around the sun tends to have a pattern of what I learn. Maybe it was distributed systems and how easy it is to screw up in 2007-2008. Or APIs from 2012-2013.

There is too much to learn with far too few years to learn. The only way I’ve been able to be ok with this fact is to schedule my learning, learn by doing, and then reading the books on the subject. Note: read the books, not the blogs, is a technique by Chris Oakman and it’s helped me dive into the theory behind the tech. The tech changes, but the theory stays the same.

That said, this is probably a very hip-javascript heavy post. If you’re suffering from JavaScript fatigue, this may or may not help.

What I learned

With learningyear 2015-2016, I’ve devoted most of my learning to two separate sets of technology:

  • Upgrading my JavaScript to 2016 era JavaScript Front-End

  • Exploring Elixir/Phoenix and other functional languages

2016 era JavaScript

Front-end is fun, sticking to 2010 era jQuery is a mess, and functional components, surrounded by imperative containers, is the past and the future.

I started with learning React so that I could explore React-Native. This was a bit like learning how to cook by starting with a Cajun Roux (and filling the house with smoke) when you’re 15. Which: yeah, I totally did. Small steps, I’m not a fan of.

I had been pretty heavy with Ember, running Houston-Ember, and building apps with it. After the ember team declared they would focus on the web-experience (instead of mobile), I started looking for something to help solve the cross-platform development experience. React-Native appeared to do so, and I built a couple of apps with it, not really knowing what I was doing.

You know: change something and see what happens development.

I saw react-rails, and began to see the potential for a mixture of Rails as the API and React components managing their view and their state at the same time. Presentation: Given. Apps: built.

But I missed the ease in which you could import modules and dependencies in front-end apps versus the flips you had to do to get Sprockets to work in Rails.

Recently, I explored getting webpack or browserify working in a Rails project. The progression at which I tried to get Rails’ to behave with the node ecosystem:

  • shakacode’s react_on_rails: complex, thorough, and was difficult for me to understand what’s going on.

  • Browserify with Rails: excellent tutorial by Reax. It was good, but I wanted to learn webpack.

  • Jay Morlan: simple webpack integration with Rails.

I haven’t replaced the Asset Pipeline, I’ve enhanced it with a webpack process that builds out app/frontend into a bundle, which Rails slurps up and uses with jquery-ujs, action-cable, and other Railsy front-end things. Jay is going to give a talk at Houston-Ruby about this soon, which I’m excited about.

Functional

Both elm and elixir are functional languages, and I had a blast writing with both of them. I have friends who have jumped all in on the elixir train, with its millisecond response times, coherent coding style, and Rails like Phoenix framework.

I built out an API for a React-Native mobile app and thoroughly enjoyed the experience. It was a hop-skip-and-a-jump to learn Elm, a front-end functional language that compiles down to JavaScript.

I wrote Hipstack.me in elm; a fun project that allows me to rewrite the entire application every six months in whatever language is hippest at the time. Sort of a TodoMVC, but TodoMVC is a little too popular these days.

Where to learn these techs

What I’m diving into next

I’m exploring data-science, both the correlation/statistics/machine-learning aspect as well as the big-data side of the house. I’m not sure I believe in “AI” as traditionally taught, but I absolutely believe in data and our ability to make guesses based upon said data.

I’m also going to give Go another chance. Working through exercism’s examples in Go is super cool. The static code analysis helps you learn the “go” way to do things.