Demystifying algorithms

Charlie Kozey — Thu, 21 Apr 2022 17:08:00 +0000

Algorithms have an intimidating reputation for programmers and non-programmers alike. This post is meant to 1) provide a high-level overview of what an algorithm is (with a non-techy, hopefully easy-to-grasp example) and 2) briefly touch on what makes algorithms important.

In the simplest terms, algorithms are just a series of steps executed in a specific order. Algorithms can be run by computers, of course, but they can also be done by hand. An example of an algorithm that most people have had experience with from an early age is long division.

The long division algorithm looks something like this (Follow along with a pencil and paper if you'd like! Or, even better, hide this tab and try to write out the steps yourself. It can be a useful exercise to articulate the steps of a process that has become automatic for you, because that's what you'll have to do when translating steps into code.):

Set up the dividend (the number being divided) and divisor (the number that is divided by) in the bracket: dividend inside and divisor on the left. Example: 42 on the left, 1000 inside bracket.
Examine the dividend one digit at a time, starting from the left, and check to see if the divisor can fit into that number at least once. (Let's call that number the fragment). If not, expand the fragment by one digit to the right and check again. 1 = too small. 10 = too small. 100 = big enough.
Once you reach a fragment that can be divided by the divisor, put the quotient (the nearest whole number) on top of the bracket above the fragment's final digit. 100/42 = 2
Multiply the quotient by the divisor, and place the result directly underneath the fragment, lining up the corresponding place-value columns. 42 * 2 = 84
Subtract the result from the fragment. 100 - 84 = 16
Repeat steps 2-5 with the result found in step 5. If the result of step 5 is too small, bring the next digit of the dividend down and append it to the result of step 5. If at any point you run out of digits in the dividend, add a decimal point and as many zeros as necessary to the dividend. Also add a decimal point in the quotient in the same position. 16 = too small. 160 = big enough. 160/42 = 3. 3 * 42 = 126. 160 - 126 = 34. 34 = too small. 340 = big enough. 340/ 42 = 8
Stop when you reach a number that is evenly divided into your divisor, when you reach a repeating decimal, or when you have enough decimal places for your precision needs. 23.8 is precise enough for me.

At a fundamental level, any algorithm you can think of—search algorithms, recommendation algorithms, routing algorithms (and the list goes on...)—works exactly in this step-by-step manner. On a practical level, technical interviews for coding jobs often emphasize algorithms. It's an important skill to have if you want a job. Like most things, working with algorithms is a skill that you can improve with practice. There are many free resources online for this purpose.

And on a societal level, it's important to think critically about algorithms and their real impact on people's lives. Like a lot of terms in, for example, finance, there’s a hand-wavey mystique about the word "algorithm." This mystique helps to maintain a status quo where insiders have a monopoly on knowledge and power. Moreover, because algorithms are iterative, their results are compounding. Small tweaks in their initial state can produce big changes in the output. Finally, an important implication of point 2 is that whatever biases are coded in by the programmers at the outset—however minor or unintentional—can have a huge impact on the final result (see, for example, racial biases in facial recognition algorithms). Algorithms are not a source of truth, which is especially important to remember since many people believe that if "a computer calculated it," it must be objectively true.

How to handle irregular plurals in Ruby on Rails

Charlie Kozey — Thu, 31 Mar 2022 19:10:28 +0000

Join me as I wander down the rabbit hole of word-nerdery in Rails!

One of the key philosophies of Rails is "convention over configuration," which makes it easier for programmers to establish relationships between items in a more or less intuitive way. Consider for a moment what the alternative would be: an emphasis on configuration would require explicit instructions to the application in order for it to understand that, for example, the Student class represents the data in the students table. However, Rails' emphasis on convention establishes the relationship based on the singular-to-plural relationship of student to Student. Provided programmers follow the agreed-upon convention, it all happens under the hood.

This is all well and good, but what happens when the thing you want to keep track of in your database is not a regular noun? Say you have a lot of mice to keep track of. If you create a "Mouse" class, will it be expecting a table called "Mouses?"

Fortunately, it will not. Rails has a component called Active Support that takes care of a lot of the irregular cases for you.

FYI: "inflection" is a linguistic term that describes the transformation of a part of a word (usually an ending) depending on its usage and context, for example, to differentiate number, gender, or tense. Verb conjugation is a subtype of inflection; inflections on other parts of speech are called declensions. So Active Support takes care of irregular plurals, but also a wider range of irregular word transformations.

But what about the cases that Active Support doesn't know about? Or the cases it gets wrong? (Or at least, wrong for your purposes—I'm chill about what's right and wrong when it comes to grammar. You do you.) Say, for example, you are building a networking platform for graduates of a fancy university, and it's very important to your boss that the plurals of "alumna" and "alumnus" have their traditional Latin endings, "alumnae" and "alumni." True, these terms will only show up in the back end for you and your team to see, but let's say your boss is a stickler for details.

In that case, you can customize Active Support's inflections for your app. As of Rails v7, those customizations are often stored in a file called /config/environment.rb, like so:

This process is also useful and important if you're coding in a language besides English, which is a topic that warrants a blog post of its own (at the least).

As a bonus, Active Support includes other built-in methods that are helpful for modifying words in various ways, including changing from snake_case to camelCase. A list of these methods can be found here.

Another use case for Active Support is to create custom rules for inputs. For example, if your app has a list of user-inputted names, and you use the method capitalize() on the inputs for uniformity's sake it successfully turns "vinay patel" to "Vinay Patel." But it also turns "Phil MacDougal" to "Phil Macdougal," which is incorrect and also a bummer for Phil, who's probably tired of that happening to his name. So you'd want to add a custom rule to Active Support that exempts names starting with "Mac", "Mc", "La", "De," etc.

Good luck and have fun wrangling words in Ruby!

Sources consulted/further reading

Rails API docs
GeeksforGeeks on capitalize()
This StackOverflow post on irregular plurals in rails (a little outdated)
Rails Guides: Active Support
Naming Conventions in Rails

Forem: Charlie Kozey

Demystifying algorithms

How to handle irregular plurals in Ruby on Rails

Sources consulted/further reading