Elixir Week, Day One: books and just-in-time-learning

In a week, I start work at my first engineer/developer job; and so, while I'm trying to wrap up some other projects (including purely logistical (i.e., boring) projects having to do with transportation and shelter, ho-hum), I'm also trying to do some prep work for that job.

Which involves getting myself up to speed on Elixir, a functional, concurrent language built on top of the Erlang Virtual Machine. (Shout out here to my 10+ year old comp sci class for covering virtual machines. Of course, we couldn't cover Elixir back then, since Elixir is only 2 or so years old.) And so, I'm declaring the first week of December, Elixir Week.

::fanfare::

Elixir Week, Day One

Thankfully, I had no trouble installing Elixir with just brew install elixir on my MacBook, which nicely installed Erlang as well. I've seen so many hours gets eaten by some seemingly simple step that I'm always thankful when this first step goes smoothly.

(If it doesn't for you, there's a few different methods for installing Elixir, some more involved than others, and hopefully one will work for you. See here for installation instructions.)

And so I could dive right into the official (I guess) Getting Started guide for Elixir, which starts, as most guides do, by talking about basic types, like integers, strings, and atoms.

Er, what's an atom? In Ruby, we'd call it a Symbol, but the Elixir guide goes on to define an atom:

Atoms are constants where their name is their own value.

And already I know this is a language that Jorge Luis Borges would love. There's a lot more in that getting started guide, but I just want to point out (for myself) some things that will be useful to remember.

> When talking about a function, the convention is name / arity, where arity is how many parameters it takes. So: IO.puts/1 refers to a function (IO.puts) that takes one parameter.

> To get help about a function, type h and then the function name/arity.

> Elixir data types are immutable. (Not news, but something I'm going to need repeated.)

Books and JIT learning

Reading up on Elixir is fun, but reading about a language is, let's say, only the first step in getting to know a language. Trust me: I used to pronounce "awry" as "aw-ree" because I only ever saw it in books.

I'm not sure if there's an ideal way to learn a language; it probably differs for everyone. For me, I like a little abstract learning and a little getting-my-hands-dirty in equal measure. So while I've been reading the Getting Started guide, I've occasionally turned to my Elixir terminal and tried a few things. "Oh, I can do a boolean AND like this--but can I do it like this?"

Which is to say that I'm a big fan of just-in-time learning. I can pack my head full of data about a language, but they only start to become real information when I put it into practice. (Or: fail to put it into practice. That's a teachable moment right there.)

And that's why I have a complicated relationship with many coding books. Give me a book with some coding challenges interspersed and I'm pretty happy. Don't--and I won't be. Which is why right now, while I'm in San Angelo, I'm flipping though a library book on Git. It's not a deep dive into all the mechanics of Git. (Do I really need to know the history of Git to do my job? Probably not.) But it is one of those aforementioned projects that I'm trying to wind down before work starts.

MakerSquare Day 2: An Intro to Github and Rspec (1/2)

Theme: Zen and the art of testing

I don't know what will make less sense to people reading this blog: my title or my theme. Or maybe you're a MakerSquare student and you understand it all--as well as the pain behind it.

But for my parents, here's the quick skinny: Git is a version control system that I didn't quite get before but that I'm devoted to now; and Github is a website where you can store all of the versions you've written. So, for instance, let's say you write your code and it works--great! Commit it to Github. 

Then you decide to add some new function and it breaks something in your old code and you don't remember what--well, not that big a problem. Just rollback your program to the last time you committed. In short, Git and Github are great ways to experiment on things without screwing up what you've already got. 

In a similar but completely different vein, rspec is also a very logistical side issue to coding: it's a way to set up a program to test your original code. Which means that, yes, now you have two chances to screw up and twice as much code to debug. But really (say the instructors) it makes a lot more sense to work with rspec rather than to test your program by copying everything over to irb.

(Oh boy, I really should link you to a dictionary site because there's lots of special words here. "Irb" is the interactive Ruby shell, where you can run Ruby right in your terminal.)

Today also involved a visit from Savrut of career services, which was very interesting and full of plans for future events: mock interviews, resume reviews, etc.

Also, he said that any tech company thinking of hiring you would find your online presence, so... Hi!

But I am running out of steam here and I still wanted to note something Nick said today that pinged my sense that coding involves a lot of strange Zen overlaps. (Or Derridean deconstruction, if that's the way you want to take it.) Today's comment (paraphrased):

"You want your code to be broad and very specific."