I can appreciate the usefulness of Python, the simplicity of Go, and the mind-expanding nature of Haskell. Yet, anything that isn’t Ruby felt like a usability downgrade. It’s all highly subjective, ça va sans dire, but Ruby was always my favorite.

It’s not every day that a language comes along and genuinely excites me to the point of putting Ruby aside (within the scope of what it’s great at doing).

I <3 Elixir

That language is Elixir. I’ve been using it on and off for a few years now. I first talked about it back in 2016 and even managed to convince my team at IBM to adopt it to an extent. It’s working out well for us so far and I have a hunch we might double down on it soon.

Since I have a little more time, due to being stuck inside, I’ve been on a “study anything in sight related to Elixir and Phoenix” kick lately.

I am a big fan of Mike and Nicole Clark of The Pragmatic Studio and in the past have highly recommended their Ruby and Rails courses. So I decided to start taking their Elixir courses as well. In this post, I’ll give you a fairly detailed review of their largest course on the subject, Developing with Elixir/OTP.

Who is it for?

Developing with Elixir/OTP is aimed at programmers. It’s so well explained that beginners can give it a shot, however, they are not the target audience.

The course assumes you have zero knowledge of Elixir itself but it’s not going to explain basic programming concepts when they are not novel or unique to Elixir.

Experience with Ruby is not required nor assumed, but it’s beneficial. This isn’t so much due to the way the course is presented (though there are a couple of nods to Ruby programmers). Rather, it’s the similarity (on the surface) between the two languages.

How much time do you need to invest?

Developing with Elixir/OTP is a 6.5 hour course divided across 30 modules. There is no way for you to take this course in 6.5 hours and get anything worthwhile from it.

In fact, the secret sauce is that each module has a Notes section dedicated to expanding on the topic, providing tips and tricks, as well as exercises. 

I would estimate that it took me around 20 hours or so to finish, despite being very familiar with the subject matter. Mind you, I do like to experiment quite a bit within IEx to veer off the beaten path.

Estimate 30 hours of your time, an hour per module, if you intend to fully absorb and experiment with the material presented.

Unlike their Rails course, you won’t develop two applications (one while watching the videos and one in the Notes section). In this course, there is only one application that is mostly developed in the videos and then enhanced in the Notes through exercises.

This will save you a lot of time at the small expense of having to pause and resume the video to type along.

Another time-saver is that the code for each module in the course is provided so that you’re never lost. Particularly useful to copy and paste the more tedious parts (e.g., sample data and template code).

What will you build?

The course starts off by developing a simple web server. Think, high-level transformations of requests into responses. It builds it from the ground up and then layers a simple RESTful API for a fictitious wildlife reserve on top.

They start off with the simplest thing, a function that transforms one specific request into one specific response, and then move up all the way to actually serving the API over HTTP.

The goal, as often stated in the course, is not to replace an established and much more robust web server like Cowboy or a framework like Phoenix. At all.

Instead, it serves two pedagogical purposes. First, it teaches you how to use the language to solve a fairly complex problem. Second, it gives you a deeper understanding of how the production-ready tools you are going to adopt actually work within.

This approach is endemic to their teaching method. For example, they’ll develop a simple web server and API from scratch and then show you how similar it is to the equivalent Phoenix version. By the time you hit module 17 on Phoenix, you don’t quite know Phoenix but it should feel oddly familiar. After all, you built a naïve/simplified version of the same controllers, router, templates, etc. from scratch. This is, of course, a deliberate choice.

The same is true when they implement a simple GenServer from scratch and then are able to seamlessly replace it with the real deal (with use GenServer). Yes, you developed the Fisher-Price version of the production-ready tools, but you now understand how they work under the hood. All before Mike and Nicole proceed to teach you how to use the battle-tested ones.

I’m a fan of this didactic approach and I think it will serve most people well.

What will you learn?

It might be surprising to some but this course does not provide the typical tour of data types and data structures available in the language.

Instead, it uses the language to build something from the beginning and, in the process, it quickly exposes you to a variety of concepts, including how to use common data types.

It doesn’t cover them thoroughly, however, so reading the Elixir tutorial on the official site would be very beneficial prior to or after taking this course.

The course starts off with several modules that are heavily focused on pattern matching. This is a good choice because pattern matching is one of the most valuable and pervasive features of Elixir.

As you would expect, there is also quite a bit of emphasis on immutable data structures, the pipe operator, recursion, and the Enum module.

In the process you’ll also learn a lot about IEx, Mix, organizing your code in a logical and idiomatic manner, defining Structs as the safer alternatives to maps, and comprehensions. 

Testing is covered adequately but not extensively in its own module. Not in a TDD manner from the very start of the course like they did in some of their previous courses. This has, again, didactical advantages even if you choose to adopt TDD in your actual work.

In the second half of the course, things get a little more serious courtesy of OTP, delving deeper into working with sockets, the actor model, Task, GenServer, and linking and monitoring processes.

Other points worth making

In more or less random order:

• The course is up to date to Elixir 1.10.x, somewhat rare among Elixir courses. Some of the videos show Mike and Nicole using a previous version (i.e., 1.5), but the Notes use the latest version and the rare differences are noted.  For example, the video shows the old mix new project format which included a config folder. In their hands-on notes for the video, they have a comprehensive “I don’t see a config directory” section to address it. You’re basically never lost or confused due to version discrepancies.
• The overall quality is excellent. It’s a really polished product in terms of audio, video, text, and visuals used to aid in explaining the more conceptual parts.
• They answer the overwhelming majority of your “wait a second” questions and objections. Either later in the video or right in the notes for that particular module. They genuinely anticipate most questions, which is the hallmark of a great course.
• Most modules have a single 5-15 minute video, but some modules include two videos. So the modules are… well, modular.
• Although this course will equip you to start studying Phoenix, it doesn’t really cover the subject. There is a module, as I mentioned, which is just enough to whet your appetite for the framework.
• Erlang interoperability is at least in part addressed in module 20, where sample code from the documentation of gen_tcp is converted from Erlang to Elixir code.
• The course is full of small tips like enabling command history in IEx (with export ERL_AFLAGS="-kernel shell_history enabled"), speeding up unit tests by making them asynchronous (i.e., use ExUnit.Case, async: true), using flush() to clear a process’ mailbox, etc.

Is it worth the price?

At $89, Developing with Elixir/OTP is not your average Udemy course that’s routinely discounted to $12. That’s because it’s not your average course.

If I had to rate it, I’d give it a 4.5 out of 5. I highly recommend it to working programmers who are interested in picking up Elixir quickly.

I would argue that it’s a great, current resource that is well worth the price of admission if you favor learning from videos.

The post Developing with Elixir/OTP Course Review appeared first on Programming Zen.

One of the changes that will impact you as a developer is that Apple switched the default shell from Bash to Zsh (Z shell). You can, of course, change it back to Bash, but I don’t mind Zsh (or Fish) so I decided to keep it.

I needed to install htmlbeautifier, a gem used by some prettifier extensions within Visual Studio Code. If you try it with the default system installation of Ruby, you’ll get a permission error:

$ gem install htmlbeautifier
ERROR:  While executing gem ... (Gem::FilePermissionError)
    You don't have write permissions for the /Library/Ruby/Gems/2.6.0 directory.

At this point, you might be tempted to simply sudo it, but that’s not a smart approach. Instead, I like to have multiple versions through an environment management system such as rbenv or asdf.

For this particular machine, I picked rbenv. Unfortunately, following the usual setup instructions didn’t really work, so I’m sharing the setup that worked for me here.

I updated brew and used it to install rbenv and ruby-build. The latter allows us to select a series of Ruby versions to chose from.

$ brew update && brew install rbenv ruby-build

To ensure that rbenv is correctly loaded when we start a new shell, I had to edit a couple of files. I added the following line to .zshenv:

export PATH="$HOME/.rbenv/bin:$PATH"

This adds gem-specific binaries to the PATH so that they are accessible to the shell without fully qualifying them with their path.

Then I added the following lines to .zshrc:

source $HOME/.zshenv
eval "$(rbenv init - zsh)"

This ensures that the previous file is sourced when a new session is started and that rbenv is initialized for Zsh.

At this point, you’ll want to source .zshrc (or simply restart the terminal of your choice like iTerm2, instead):

$ source ~/.zshrc

With rbenv ready to go, I installed the latest version of Ruby and set it as my global default for this machine.

You can determine the latest stable version by running:

$ rbenv install -l

Go ahead and run:

$ rbenv install 2.7.2
$ rbenv global 2.7.2

After restarting the terminal again, do a quick sanity test to ensure that the right version of Ruby is being selected:

$ ruby -v
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20]

$ ruby -e "puts (1..100).reduce(:+)"
5050

Finally, you’ll be able to install htmlbeautifier, like I did:

$ gem install htmlbeautifier

No need for sudo.

I hope this helps anyone who is trying to install rbenv on zsh. It did the trick for me.

The post Installing rbenv on Zsh (on MacOS) appeared first on Programming Zen.

I don’t see this as a negative, true as it might be. When Rails arrived on the scene a decade ago, it was thoroughly impressive and quite the improvement over the status quo in the PHP, Java, and even Ruby communities. At the time, despite some shortcomings, it was revolutionary.

Not surprisingly, as time went on the framework evolved, improved, and became more mature. The whole ecosystem around it grew exponentially. You can now deploy scalable Rails applications. It is the darling framework of most startups in Silicon Valley. You can leverage advanced support in editors and IDEs, run it on different platforms (e.g., on the JVM via JRuby), and find Rails developers to hire with relative ease.

As it grew to become the tool of choice of countless web developers, it managed to have a massive influence on other communities as well. It contributed to raising the bar for frameworks in other languages and as a result we have at least a bit of Rails inspired frameworks in virtually every language today. We are more productive almost regardless of the language we choose, and in many cases we have Rails to thank for it.

What Rails lost in the process is the massive competitive advantage it had in its early days over virtually everything else that was out there. [1] It hasn’t failed to grow. It hasn’t failed to innovate. It simply matured and so did the rest of the web world.

I think it’s important for developers to reinvent themselves, or at least stay up-to-date on what’s available out there. That’s how I came to discover Rails in the first place. This is true for programmers in general, and its especially true for my professional role which includes technical evangelism in a team that continually reinvents itself.

When you go talk to a new generation of programmers, you need to be able to speak their language. And today for many, in my experience, that means speaking Node.js, instead of Rails.

That’s okay. Ruby on Rails might be old news by now, but it remains a perfectly capable solution for a wide array of problems. It has become the status quo and there is nothing wrong with that.

As we look for new runtimes, languages, and frameworks that innovate further and better solve those particular use cases where Rails doesn’t shine, we might stumble upon a new and innovative solution that make today’s Rails look like J2EE or PHP did to us back in 2004. [2] Until then, it’s worth keeping an eye open while still wearing that old, comfortable, and very trusty hat that has been helping us get the job done for a decade now.

The post Rails Is Old Hat, and That’s Okay appeared first on Programming Zen.

The method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.

The second definition is more interesting because it allows me to make a point about programming languages. It goes like this:

The system of communication used by a particular community or country.

Look at that. Isn’t that beautiful? Let’s cut the country stuff, and shorten it to, “The system of communication used by a particular community”. Tell me that it’s not a spectacular definition of programming languages as well.

We can look at programming languages in two possible ways. They can be a means for us to instruct the computer, and incidentally communicate with fellow programmers, or they can allow us to communicate with other programmers in specific terms that are ultimately executable.

The first interpretation is technically more accurate. Or, more specifically, the worst kind of accurate.

I like to think of programming languages as languages because, outside of trivial programs, above all else they enable programmers to communicate with one another when it comes to resolving a problem or completing a particular task, while incidentally producing code that is also understood by computers via “translators” (e.g., compilers and interpreters).

There are plenty of benefits that can be derived from thinking about programming in terms of the second interpretation.

When you view programming in this light, you start considering the value of comments expressing the “why” and code expressing the “how”. Tests become a way to communicate to a fellow programmer [1] that a change to the codebase has violated a given requirement. Above all, writing idiomatic code becomes important.

Remember the Google Dictionary definition. “The system of communication of a particular community”. It is in fact the community, for better or for worse, that sets the guidelines and de facto style of a particular programming language.

Since we are operating in a system of communication, programming is a bit like driving: predictability is important. That’s why in the Ruby community we have the principle of least surprise [2] and in the Python community one finds the “There should be one – and preferably only one – obvious way to do it” mantra. [3]

When you think of programming languages as a series of conventions adopted by a community, and incidentally understood by the computer, you avoid recklessly monkey patching classes just because you can. You know that doing so leads to unexpected results and miscommunications with other programmers.

You also avoid features which are technically legal in the language, but rare and confusing to fellow experienced developers in that particular language. For an example of this, take a look a the Flip-Flop operator in Ruby (a reminiscence of its Perl heritage). Technically legal Ruby, even useful at times, however you shouldn’t use it because only a handful of fellow Rubyists will understand what you’re doing. [4] Worse yet, it will be hard to Google for an answer unless you are familiar with its name already.

When you’re first picking up a human language, you learn the meaning of common words. Then you use simple sentences that you memorize from books, people around you, songs, movies, and TV shows. Then you try to mimic the idioms you see used by mother tongue speakers. Often you won’t get them right at first, resulting in comical variations that are close, but not quite right, to those of native speakers.

When it comes to programming languages things really aren’t all that different. That’s why it’s critically important to read other people’s code, write code and receive feedback in code reviews, do peer programming, take part in open source contribution, and engage in other forms of social interaction pertaining to code. Doing so is immensely important when it comes to truly mastering a programming language.

Another consequence of this emphasis on communication among programmers through a common, precise, language whose style, conventions, and idioms are defined by the community is that you should choose your communities carefully. What are the community’s priorities? If there is no love for beautiful, clear, elegant, easy to understand code, tread very carefully. [5]

As someone who had to learn English as an adult, pretty much from scratch, I can tell you that I find many parallels between the experience of learning a new language and that of a new programming language.

Even if the two are not a perfect match – and seeing a programming language as a human language is an imperfect metaphor – I feel that thinking of it in these terms has allowed me to quickly acquire key skills in the programming languages that I needed or wanted to learn.

The post On Programming Languages as Languages appeared first on Programming Zen.

Each episode lasts about half an hour and sells for a mere $5. This strategy will work well in their favor because screencasts are a great way to teach programming. So far they’ve put out 5 series: Expression Engine, Core Animation, Erlang by Example, Everyday Active Record and, their latest entry, The Ruby Object Model and Metaprogramming.

If you are reading this blog, I’ll assume you’re mostly interested in the last two topics. I haven’t had a chance yet to watch the Active Record ones, so I can’t say much about them, other than that I have faith in their author, thanks to his magnificent work on the Railscasts.

Today after work however, I spent about an hour and a half watching the first three available episodes of The Ruby Object Model and Metaprogramming. This is a brief review of my thoughts on them. In short: they’re fantastic. But let me provide you with a bit more of a in-depth analysis than that.

These screencasts shine for the simple reason that you feel as though you’re sitting right there, next to a master programmer like Dave Thomas, as he explains Ruby concepts in detail to you. Whenever you’re not very clear about a concept, you can go back and listen to the explanation as many times as you’d like. You can pause, experiment with irb, and then go back to the screencast. After watching the first episode, I though that the $5 price was a steal.

Currently the following three episodes are available:

1. Objects and Classes (29 mins)
2. Sharing Behavior (39 mins)
3. Dynamic Code (31 mins)

The first episode lays the groundwork for the series and introduces a useful diagram that enables you to easily visualize the Ruby object model correctly. Concepts like singleton methods and ghost classes are really well explained. The first episode also covers ‘self’ and the concept of current class, which is often confusing to beginners.

The second episode explores what constitutes good object oriented design, as well as the usage of prototype programming, inheritance (and how not to abuse it), and finally an excellent explanation of modules and mixins. If you are a beginner you may not know the difference between including and extending a module, or the true power of mixins. Fear not, the last part of second episode really covers those subject well.

The third episode starts by defining blocks and their usage, including the difference between lamdba and Proc.new. It then moves on to explore the concept of bindings capturing the execution context, and the importance of closures in metaprogramming. The last 12 minutes or so are spent dealing with the subject of dynamically defining methods, which is at the heart of metaprogramming, and the video includes a nice example of how to create your own version of attr_accessor by defining, in a module, a method that dynamically defines getter and setter methods.

I’d say that aside from the feeling that I was enjoying a “private lesson”, what I liked the most was the coding style recommendations about when to employ a given concept and when to opt for something else. The examples were clear and easy to follow as well.

I can’t recommend this series highly enough to any Ruby programmer with a basic grasp of the language. I feel that intermediate developers will get the most out of these videos, but they’ll also definitely be very beneficial for beginners. Real experts shouldn’t find any alien concepts, at least in the first three episodes; I know I didn’t. Yet, they’ll appreciate, just like I did, the fresh slant when it comes to reviewing some of the illustrated concepts and examples. There will also be a few “ah-ah!” moments here and there, I guarantee you.

Five stars, and I’m certainly looking forward to future episodes.

The post Review of the screencast series The Ruby Object Model and Metaprogramming (episodes 1-3) appeared first on Programming Zen.