Skip to content

Blag

  1. The Functional Shape of Loops

    Learning to program, it's quite common to come across many resources and code samples that include imperative loops of various sorts (particularly for and while).

    Frequently when I see examples that include loops, I cringe. They often include many steps that make them harder to understand because there is so much happening every iteration.

    Instead, I much prefer to use a functional approach to iteration. Each step can be converted to an individual function and those functions can be applied to the entire collection to produce a result.

    There are several advantages to the functional approach over imperative:

    • Named functions are essentially declarative; they describe what will happen rather than how it will happen.
    • Splitting functionality into individual functions allows for code reuse.
    • Pure functions can easily be tested individually.

  2. Good Judgement

    Good judgement comes from experience.
    Experience comes from bad judgement.

  3. Clinging to Mistakes

    Don't cling to a mistake just because you spent a lot of time making it.

  4. Dynamic Sort Direction

    This is a follow-up to my "Multisort via Composition" post, and won't make sense if you haven't read that post.

    When sorting on a single dimension, changing the sort direction can usually be handled by changing the sorter function directly.

    const data = [33, 1, 95, 77, 54, 91, 38, 89, 48, 24];

// ascending
data.sort((a, b) => a - b);

// descending
data.sort((a, b) => b - a);

    making this act dynamically based on some external input can be reasonably handled by updating the function as well:

    const ascending = getAscending(); // true or false
data.sort((a, b) => (ascending ? a - b : b - a));

    This works fine for a single sorter, but quickly becomes untenable once multiple sorting dimensions are used:

  5. Multisort via Composition

    Sorting a collection of data in a single dimension is pretty straightforward in most programming languages. It's quite common to use some sort of comparison interface that exposes a function with two parameters of the type being sorted, and expected return values of -1, 0, or 1.

    For example, JavaScript has Array.prototype.sort, C# has IComparer, and PHP has usort.

    This works quite well when you want to sort on a single property:

  7. I Refuse to Use

    I recently saw Amber Weinberg's tweet after it blew up on twitter:

    My gut reaction was that it was a bit harsh to those of us who choose to use Sass, React, or Redux. It implies that anyone who uses those tools isn't writing clear, or clean code, which explains why so many front-end developers collectively flipped thier shit at it.

    But seeing as Amber's a WordPress developer, it entirely makes sense to me that she would have no use for React and Redux. I can even see why she'd avoid Sass too*. The types of problems best solved by a WordPress site do not necessitate any use of React or Redux.

  8. Beginners Not Yet Welcome

    Joel Spolsky recently tweeted a message about some phrasing in a question that was a strong indicator that the question was inappropriate for Stack Overflow.

    to my surprise, this elicited some strong reactions from other developers chastising him for turning away beginners from the site.

    Here's the thing about Stack Overflow:

  9. Dots Oscillating

    Permalink: Dots Oscillating

    I've meant to finish this years ago, but I never got around to figuring out the proper cubic bezier timing funtion that most closely matches a cosine.

    The idea stemmed from two different illusions, which I have since lost the links to.

    The first was a series of dots that oscillated on straight lines to produce what appears to be a ring rotating around a larger percieved circle.

    The second was a series of cirlces rotating to produce what appears to be waves.

    Having seen both illusions I decided to throw them together—which I started to do a couple years ago—and then promptly forgot about it.

  10. Writing Good Release Notes

    When writing release notes or changelog entries it's important to keep some things in mind. First and foremost it is important to be aware of who the release notes are for.

    Release notes are not for you…now.

    Release notes are for future you.

    Release notes are for a user who wants to know what the latest updates are.

    Release notes are for a stressed-out colleague who's trying to narrow down when they think a particular breaking change might have occurred.

    Identifying the personas of the people who will be reading release notes is important so as to effectively communicate with them. If you don't understand your audience you may end up losing them.

    If you write bad release notes for a product, you may frustrate your users into finding an alternative solution that feels more stable, or is more predictable.

    If you write bad release notes for a client, you may end up confusing or angering them.

    If you write bad release notes for your team, you may end up alienating your maintainers and slow the pace of progress.