Skuunk Works

(This article is pure opinion and is not based on any facts what so ever...) At present (in April 2026) not only are most programmers not writing code directly, we are not writing Domain Specific Languages directly either. A domain specific language, unlike a general programming language, is a language written to solve a specific problem. Often a DSL is translated into a general purpose language (either by interpreter or compiler) and exists to help a programmer read code and reason about a problem in a more readable way. One example that comes to mind is a Arel which is a DSL for writing SQL queries. While SQL is already quite user friendly on the surface, queries can become complex quite easily after a few joins. Also, there are slight differences in SQL depending on which database you use (e.g. Postgres vs MySQL vs Oracle) so having a DSL smooths over these changes as well. However, sometimes achieving what you want to do in Arel can be harder than doing it in raw SQL and also Arel ...

Ok, controversial click bait title aside, personal software projects do an enormous amount of good in teaching you how to learn new languages, write better code, architect code and may even make you a buck or two on the side (if you are lucky). However, there are some things that you are not likely to learn when writing personal software projects and I wanted to discuss a few of them here. What they can't teach you How to communicate your ideas By definition a personal project is personal. You are probably the only one working on it (though you can ask a friend or two to help, which is highly advisable if you can). When you want to add a new software pattern or framework, you just do it. While that's incredibly liberating, one of the benefits of working in a team is having to explain your decisions will make you more reflective and will give you a better sense of if you are doing things the right way or not. If you meet with resistance to the idea, it means you have to th...

Oooh them's fighting words. Anyways, this is definitely not true inheritance by any means, but let me explain the problem and then the solution. Ecto is the primary way you connect to the database in Phoenix. However, Ecto differs in many significant ways from ActiveRecord in Rails. You can set up a schema file which lists the relationships between your "models" or "entities", but these schemas do not allow you to directly access the database. They are merely descriptions of how the data is expressed. To access the database, you need to use a data context which uses Ecto. So, from my article comparing Active Record to Ecto ( http://www.skuunk.com/2020/01/comparing-rails-active-record-pattern.html ) defmodule Schema.Article do use Ecto.Schema import Ecto.Changeset alias Schema.Author alias Schema.Comment @permitted_fields [:title, :content] @required_fields [:title, :content] schema "article" do belongs_to(:author, Author) ...

Why am I covering 3 Elixir topics at once? Well, perhaps it is to show you how the three are used together. Individually, any of these 3 are interesting, but combined, they provide you with a means of essentially getting rid of conditionals and spaghetti logic. Consider the following function. def greet_beatle(person) do case person.first_name do "John" -> "Hello John." "Paul" -> "Good day Paul." "George" -> "Georgie boy, how you doing?" "Ringo" -> "What a drummer!" _-> "You are not a Beatle, #{person.first_name}" end end Yeah, it basically works, but there is a big old case statement in there. If you wanted to do something more as well depending on the person, you could easily end up with some spaghetti logic. Let's see how we can simplify this a little. def greet_beatle(%{first_name: first_name}) do case first_name d...

Rails has a very well established Active Record pattern for dealing with the database. You have an Active Record model which maps to the database table, the schema of the model comes directly from the database schema and you place your model specific methods on the Active Record model. This file is also where you set your model relationships (e.g. has_many, has_one, belongs_to). Your instance of the model has all the methods built in. In Ecto/Phoenix it's a little different. First of all, the database schema doesn't automatically map to the "model". In fact we don't really have models (as Elixir is a functional paradigm). What happens in one file in Rails, happens in essentially two (or more). You have a schema file (where you have to list out all the attributes and relationships). Using the schema file, your "instance" is essentially a data structure (with no methods on it). If you want to transform the data on your struct, you would use a context mod...

Whilst I am primarily a JavaScript programmer, my framework of choice is Ruby on Rails. A lot of JS guys like Node or other frameworks which are JS all the way through, but there's a lot to like about Rails, even in 2016 and it's worth learning another language (Ruby) or two (SQL) in order to get the best environment on which to write your JavaScripts. Before I say what I like about Rails though, I will take you through what I don't like just to balance things out. What I don't like about Rails Asset Pipeline still does not let you use ES6 Modules.  Even at this late stage, one still cannot access ES6 Modules in Rails in a "Railsy" manner. You can either bypass the whole Asset Pipeline or else separate out the JS using Webpack or whatever, but in a standard Rails project, the fact that the asset is generated with unique hash in the file name before the extension pretty much nullifies its use for ES6 Modules which need a static location to store the fi...