What I learned today! tail -f vs. less +F

I know, it's been a while. Truth is, after MakerSquare, things got busy.

In fact, things are still busy, what with the new (or newish) job.

But that's why I'm back: because things are going so fast that I want to start recording at least one useful thing I learned.

(Otherwise, as one developer noted today, it's real easy to look back at your old code and not know what's going on.)

---

So today I learned about less +F.

At work, I use tail -f to follow a file as it changes. So, if I'm running a Unicorn server that has a log file and I want to see what's happening in that log, I tail -f unicorn.log.

But now, according to this post, I can use the similar less +F, which both follows the file and allows one to look through the file as normal with a Ctrl-C.

I also learned that you can tail -f multiple files.

Word frequency counter in Elixir

Before I got into web/software dev seriously, I was pretty serious about literary analysis. (Ask me sometime about how pregnancy and history work in Edgar Rice Burroughs's Princess of Mars and Ursula K. Le Guin's Left Hand of Darkness.) And these two loves came together a few years ago in a new-ish field called "digital humanities": the crunching of literary data with computers.

For instance, we could go through an entire writer's work and see what words got used most often--or not at all. (Fun trivia for nerds: Lovecraft uses the word "squamous" only once, which is funny because parodies of Lovecraft love that word.)

Which is a long intro to explain why I like writing word-frequency counters in new programming languages. So, to count words in Elixir, you could use this:

1. defmodule Words do
2. @doc """
3. Count the number of words in the sentence.
4. Words are compared case-insensitively.
5. """
6. @spec count(String.t) :: map()
7. def count(sentence) do
8. sentence
9. |> prep 
10. |> count_words
11. end
12. 
    
13. defp prep(sentence) do
14. sentence
15. |> String.replace(~r/([^\w-]|_)+/u, " ")
16. |> String.downcase
17. |> String.split
18. end
19. 
    
20. defp count_words(words) do
21. Enum.reduce(words, Map.new, 
22. fn(word, map) ->
23. Map.update(map, word, 1, &(&1 + 1))
24. end)
25. end
26. 
    
27. end

Commentary: @doc and """ are for heredocs. Now if I type "h count" into the terminal, I'll get back that info.

You'll also note two things: (1) the program is written with two helper functions, in classic modular fashion (and these functions are defined with defp, which makes them private functions, only call-able by functions within the module); (2) Elixir uses pipes (|>) as a way of handling and handing off data. And I love pipes. 

Check out prep, a pretty straightforward way to prep a sentence for counting (with line numbers to help follow): 

(14) it takes the sentence; 

(15) runs it through a regex replacer to get rid of anything that isn't a word; 

(16) then runs that new string of just letters through the downcase function; 

(17) then runs that newly downcased string through a split function, which works like all split functions seem to work, taking a string and returning a list of strings. 

Now, if I wasn't piping, I would have to include the parameter, like

String.split(sentence)

But when piping, the first parameter is assumed to be whatever is piped in. Now, without piping, I could write this sequence of functions pretty easily, and it would look like this:

String.split (String.downcase (String.replace(sentence, ~r/([^\w-]|_)+/u, " ")))

Which I can read, but which is a little less intuitive, because you have to read it backwards, with every left-side function taking as parameter the output of the right-side function. Yuck.

Then we get to the heart of the word counter program, the count_words function. This function is doing something interesting--and wasn't my first version of this.

My first version:

1. defp count_words([], acc), do: acc 
2. defp count_words([head | tail], acc) do 
3. quantity = Map.get(acc, head, 0) 
4. acc = Map.put(acc, head, quantity + 1) 
5. count_words(tail, acc)
6. end

My first version was a fairly standard tail recursive function that went through the list, calling itself until the list is empty. When the list is empty--i.e., when line 1 is called because the first parameter matches the empty list []--it returns the accumulator. If the list is not empty, it processes the word in a pretty standard way: words and values are saved in a map (which is a key-value structure like a Ruby hash), so I pull the old quantity from the map and then update the map with the new quantity for the word.

So let's look again at the second (or third) version:

Second version:

1. defp count_words(words) do
2. Enum.reduce(words, Map.new, 
3. fn(word, map) ->
4. Map.update(map, word, 1, &(&1 + 1))
5. end)
6. end

So, the heart of this is still a Map function; here, we call Map.update with the map to be updated (map); the key to be updated (word); the initial value to be used if the key is not found (1), and a function that tells how to transform the value if the key is found ("&(&1 + 1)").

We could rewrite that to make it clearer for new Elixir users, like: 

Map.update(map, word, 1, fn(x) -> x + 1 end)

But the real magic is Enum.reduce, which does all the work of going through a list until it's empty and resolving all the data in that list into a single structure or value. For instance, a classic use of Enum.reduce would be to sum all the numbers of a list:

Enum.reduce([1, 2, 3], 0, fn(x, acc) -> (x + acc) end)

So we have the list to be reduced ([1, 2, 3]); the initial value to use as the accumulator (0); and a function that tells reduce how to resolve all the elements of the list into a single value ("fn(x, acc) -> (x + acc) end").

(P.S. That's the long way to write the function, which I did to make the action clear; i.e., we take two parameters, the element of the list (x) and the accumulator (which starts at 0), and we add each of them. The really short way to say that would be &(&1 + &2). Awesome.)

So the Enum.reduce in this function takes the list of words; accumulates it in an empty map; and the function that it uses to resolve the list into the map is ... the Map.update function that adds one to the value of the word each time it finds that word.

Shiny new computer, cruddy old flu, fun new Fizzbuzz in Elixir

I just updated my LinkedIn profile, so I might as well update you here: my new job is as a junior developer at Clutch Analytics, the digital invention arm of Windhaven Insurance. And this last week was my first week there.

Which makes it the perfect week for me to get the flu. Ah well, that's only tangentially related to coding, so I'll leave it at this: a slight fever might, occasionally, be helpful when studying a new language.

Another issue that's only slightly related to coding, but which I have to bring up here for other junior developers--especially those who come straight out of school without much work experience: starting a new job involves a lot of logistics, including filling out paperwork. (Note to self: fill out paperwork this weekend.)

So now I have a new(er) computer, set up with my preferred configuration; the lingering effects of a flu; some health insurance paperwork to fill out; and some fun Elixir challenges. To that end, I've (thank god) gotten back to committing to my Github, which has a new repo for Elixir challenges. The first, of course, is Fizzbuzz.

Elixir Week, Day Five: Not quite as Elixiry as expected

When I titled my last blog post "Day One," I thought I would do a little Elixir each day and report on the fun things I found--

like the difference between case and cond; or how the h before a function name actually gets the documentation from the code file

--but since this week was also my last week home before moving to Austin, I've had quite a few other things to do. Like find a place to live and shower my dog with affection in the form of walks.

And also look through some Tom Green Country library books. In the future, I will create a page just for the books I've read, with some notes, both general and specific.

For instance, I read that O'Reilly book on Version Control with Git. (I do love to see which animal gets which book: Version Control is a bat.) So the general remark might be: "In-depth look at Git, more than really necessary for daily use. Excellent chapter on merge control." And some specific remarks might be "Use rm command."

(For some reason, I've never had reason to rm a file from my git index.)

And about Learning JavaScript Design Patterns, I'd probably say "Get it for the MV* chapter; though some of the other material feels a little too abstract if you're not trying to apply it to project; and some of it feels a little too concrete if ditto. Not an introductory book to design patterns."

But that seems to be the way with computer books, I find: there's a lot of danger that they'll be too abstract or too concrete or too in-depth for what you need right now.

So, you read any good books lately?

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.

Post-MakerSquare, Week Two: Keeping your code sharp--and, oh yeah, about that job search

How do I not have just a plain jane "Coding" tag? Anyway, welcome to the tag family, "Coding"!

And I want a "Coding" tag here because I want to talk about a website that I have fallen in love with recently: exercism.io.

It is very much like those other websites where you get coding challenges, e.g., CodeWars, Project Euler, etc. (which I also like). That is, the goal of Exercism.io isn't to build any project (which I still maintain is the best way to really get into the nitty-gritty of a language), but merely to play around with a few challenges.

I especially like how Exercism.io keeps everything real clean and focused. Rather than running a test online (and oh, how online tests have given me heartache), you run the tests on your computer--as you would normally. Exercism.io also has a nice breakdown of various languages, so that you can try only the Ruby challenges or the Clojure challenges; and after you submit one solution, you can fetch the other. (The interface is not unlike Github, which is another reason I like it.)

And then, best of all, you get some commentary and feedback on your code. Because, sure, my DNA/RNA transcription agent worked, but the real benefit of using this is I have now discovered a new method--String#tr--that I never used before and wouldn't have used if I hadn't seen someone else use it.

So, if you want to practice a new language or keep an old language sharp, I recommend at least looking at Exercism.io

***

And about that job search, I've been offered and accepted a junior developer position. So I'm off the market for now; and very excited about starting in early December. I will say more about the job and the company--after I reread my NDA and figure out what I can say.

For now, my new challenge--both for fun and for work--is to learn functional coding. Come on, O'Reilly books, don't fail me now!

Post-MakerSquare, Week One: Don't be so apologetic on the job search (plus bonus FizzBuzz)

"So, one note for you," said a mentor, after I went through a mock technical interview, "is: Stop being so apologetic."

Which really might be the centerpiece of why I don't love interviewing. I mean: I love talking to people, I love asking questions, I love answering questions. God help me, I even love coding challenges. Ask me to do FizzBuzz in one line, please!

Sidebar: How to do FizzBuzz in one line:

(1..100).each {|num| num % 3 == 0 && num % 5 == 0 ? (puts "FizzBuzz") : num % 3 == 0 ? (puts "Fizz") : num % 5 == 0 ? (puts "Buzz") : (puts num) } 
It's not pretty--or really all that maintainable--but it works in one line. (Note: tested on repl.it; and inspired by a Paul Irish post.)
Let's break it down:

• 1..100 -- standard Ruby for an inclusive range
• each -- loop over each element in the array/range and slip it into the following block
• followed by a cascade of ternary conditionals
  • if it's divisible by 3 and 5, put "FizzBuzz", and if not, then
  • run through the next case (divisible by 3) and if that doesn't work,
  • run the next case (divisible by 5), and if that doesn't work
  • just put the number already

But I don't love selling myself. When I'm discussing my projects and my web dev foundation, it's pretty tempting for me to pick at the issues or the lessons (i.e., the mistakes that I made). Largely that's because of where I am in my career--just beginning, with plenty to learn and a big hunger to learn it. I mean, I really liked the early hackathon project we did, but weeks later, I can see some of the holes there.

Looking at those holes can be very educational and even rewarding. ("Look, ma, I'm learning!") But they don't always make the best interview discussion.

So, dear mentor, I'm going to try to be less apologetic during interviews.

And wouldn't we all rather talk about FizzBuzz anyway?

P.S. For actual information about my job search--well, I'm not going to get into details. Suffice it to say, I'm concentrating on Austin right now, with an eye cast on Chicago; I'm looking primarily for, let's say, middle-end to back-end--anything below HTML/CSS, which I can do, but don't enjoy as much. I've got some leads and had some positive interviews, so I feel OK. But I'll be 100% honest with you: I'd much rather be coding than searching for a job.