DEV Community: Davyd McColl

Pair programming doesn't suck

Davyd McColl — Fri, 23 Oct 2020 07:26:05 +0000

I just read an article outlining why pair programming apparently "sucks"

Go read it, come back. I'll wait.

The author also lists some positives, which I totally agree with:

improved communication skills
improved dev skills by pairing with an experienced programmer

But the list of "negatives", well, those aren't the fault of pair programming. Rather, they're people problems. But we can work around those, and we should anyway, even if not pairing, for reasons which should become apparent:

I hate typing on someone else's computer or when someone types on my computer

This is based in a legitimate concern: I try to keep my station relatively "non-icky", but I've worked with people who seem to be trying to store food for the winter season in between their keys or on their mice.

Whilst we should all probably try to keep our workstations neat and tidy for our own health benefits (physical and mental!) we naturally will have differing levels of fastidiousness around this area of our lives. Some people are neater than others. Some people are simply less aware of how they're transferring lunch into the keyboard vault.

There's an easy solution to this. No, it's not "cleaning your keyboard every morning" (though there's nothing wrong with doing so). Some people are never going to be satisfied with the level of cleaning that can be attained. Also, sometimes, it's just not practical to do a full clean every day. I want a clean keyboard, but I have to make the compromise that it's "clean enough" for me, until I get some time to pull off the keycaps and clean properly.

The easy solution is: get another set of input devices. Another keyboard. Another mouse. Done. The cost isn't that high -- you don't need top-of-the-line gear here, as it's likely that when you're choosing to pair, the person whose workstation you're at will do most of the driving, but the guest should be able to work along at any point.

Yes, this means that you're going to sit at someone's machine and they won't have your favorite Cherry Red MX keys or your fancy Razor mouse. As Ewan McGregor says: "have a teaspoon of cement and harden up a bit".

If you use editor plugins like Vi-mode, be aware that many people don't know how to use Vi. Learn how to toggle that plugin on and off quickly, and do so before your partner tries to type.

Constant breaks

This is a point on which you and your pairing partner should decide together. Some people need to break down their day into smaller chunks. Some people can go a little longer. I can tell you that for the health of your eyes, you should find a way to look into the distance every 20-30 minutes, and you're probably dehydrated and don't know it.

So it's reasonable to say that on about every 40 minutes, it's ok to stand up, stretch legs, get a glass of water or a coffee, get back to it. But this is still something that's up to the pair, and not to be enforced by some arbitrary rules. The author may have experienced some kind of structured timing because of the environment, a coding bootcamp,, but who still works exactly like they did at school? Anyone?

Egotistical partners

This is at the heart of a lot of pairing issues: ego.

I can't say this enough: if you want to be successful in life, you're going to need to learn how to drop the ego, especially if you want to work with other people at any point in your career, and if you don't have billions of dollars to buy the allegiance of people around your or some cult-like following that puts up with your BS because they think that you have some kind of super-powers that entitle you to be a general jackass. I'm thinking of a specific famous person, now deceased, but the personality isn't exactly unique.

Even if you're not going to pair program, you need to understand that you will be wrong at some point. Particularly when you're learning, whether that's domain or tech, the path to mastery lies through multiple failures. You need to be able to listen to the ideas of others. You need to be able to concede when you're wrong. You need to be able to find compromise when it doesn't matter who is actually right because there are many ways to solve a problem.

Ego is your enemy. Pair programming will simply put a giant spotlight on your ego if it's toxic. Pair programming may also enable you to learn how to drop that ego, if you pay a little attention to how you're feeling. Getting mad because someone is questioning your solution? Perhaps that's ego. Getting mad because someone reminds you that you're not following the accepted style guidelines, or you've started writing prod code without tests, when the agreement is to use TDD? That's your ego, popping up again.

That same monster will pop up in code review. If you don't learn how to master it, pair programming is likely to be only one of your problems.

Passive partners

Ok, this I struggle with, because I don't see the point in doing half a job.

Just like with ego, this is a problem you need to sort out with yourself, especially if you're about to work collaboratively with someone else. Again, the setting doesn't have to be pair programming -- we all roll our eyes at the person in school who wouldn't work on the group project, just as much as the team member who doesn't pull their weight. Pair programming will just highlight these people.

If you can't talk to them directly (something like "hey, want to help a bit here?") then the only recourse is to talk to your team leader. I can guarantee that the person paying their salary cares.

Take a close look at yourself: are you pulling your weight in your team? Are you perhaps the person people dread to work with because they know they'll have to do the work themselves? Or simply have to fix up all the things you did half-assed? I'm not talking about making mistakes -- that's going to happen. I'm talking about people who just don't care to try harder.

You can do better.

Micro-managers

Micro-managers are control freaks, plain and simple. This is closely tied to ego -- if you can't accept that there are multiple ways to get something done, if you can't let people work with some level of trust, then you are trying to control everything around you.

Stop. Think a while how it would be to work alongside yourself! Yes, your pair partner may have missed a semi-colon. Don't you think they feel embarrassed with the compile fails? We all make mistakes, and part of pair programming is helping to pick up each other's mistakes, but if you're hovering all the time, it really ratchets up the tension in the dynamic.

Remember, you're both here to solve the problem. You're both here to tackle the puzzle. The other person is on your team.

Noise

This can be a legitimate concern, but again, can be solved by moving people into their own spaces. This is not the fault of pair programming, per se, but large-scale pair programming will certainly highlight bad office layout. I know it did at my former job. We used to pair a lot and there were also some poor people trying to participate in remote team meetings whilst others were fully-engaged in collaborative efforts.

Some tips though: be aware of your volume. One of my favorite people is known universally for being really loud. He's not often aware that he's being loud. He doesn't do it on purpose: he's just a more expressive, extroverted kind of person. He's also a teddy-bear, so whenever I reminded him to lower the volume, he always happily obliged.

People can make some of the change here, but the real solution is to stop packing your developers into one open-plan room. If your company won't change this, leave -- trust me, it will be worth it. Cramming devs into tight spaces is indicative of how the company values those people. If you're squeezed in like a sardine, unable to move your chair without hitting someone else, chances are good you're seen as a "resource", not a creative person. Bring it up with management, and if nothing changes, leave as fast as you can.

Wrapping up

Pair programming can be awesome if you:

provide spare input devices (mouse and keyboard)
leave the ego at the door
engage with the problem and your pair partner
don't be a nag - let people make their own micro-mistakes, and be there to catch the big ones
find ways to isolate your noise from others

Asserting sequence order with NExpect

Davyd McColl — Tue, 13 Oct 2020 08:13:44 +0000

I've made a recent small addition to NExpect core which I hope will make certain kinds of tests a little easier for everyone: tests where we have to ensure that the output of our system-under-test is ordered.

Some simple examples:

[Test]
public void ShouldAssertSimpleOrder()
{
    // Arrange
    var numbers = new[] { 4, 2, 5, 1 };

    // Act
    var ascending = numbers.OrderBy(x => x).ToArray();
    var descending = numbers.OrderByDescending(x => x).ToArray();

    // Assert
    Expect(ascending)
        .To.Be.Ordered.Ascending();
    Expect(descending)
        .To.Be.Ordered.Descending();
}

So you may be thinking: "this is all good and well, but what if I want to assert ordering on collections of types more complex than numbers?"

There are some strategies you can take there. First off, the underlying logic in the above assertions takes advantage of Comparer.Default which relies on the IComparable<T> interface, meaning means that:

a lot of types are already supported
you could implement IComparable<T> on your complex type and be able to order it anywhere with LINQ
you can .Select off the interesting bit and assert on that

(3) is probably going to be your go-to, so here's an example:

[Test]
public void ShouldAssertOrderedAscending()
{
    // Arrange
    var doggos = new[]
    {
        new { id = 1, name = "Rex", adopted = new DateTime(2020, 1, 1) },
        new { id = 2, name = "Spot", adopted = new DateTime(2019, 5, 6) },
        new { id = 3, name = "Woofles", adopted = new DateTime(2020, 4, 5) }
    };
    Expect(doggos.Select(d => d.id))
        .To.Be.Ordered.Ascending();
    // Act
    var orderedByAdoption = doggos.OrderBy(d => d.adopted);
    // Assert
    Expect(orderedByAdoption.Select(d => d.adopted))
        .To.Be.Ordered.Ascending();
}

The above, and first-class support for IOrderedEnumerable<T> is added in NExpect 1.0.181.

Happy testing!

NExpect: not just pretty syntax!

Davyd McColl — Fri, 21 Aug 2020 14:19:32 +0000

I've written about NExpect a few times before:

If you'd like to learn more first, open those up in other tabs and have a look. I'll wait...

I've had a preference for using NExpect myself, but I'm obviously biased: I had a developer-experience with NUnit assertions which I found lacking, so I made a whole new extensible assertions library.

But there's always been something that I haven't been able to qualify about why I prefer NExpect over NUnit assertions. I've even gone so far as to tell people to just use either, because they're both good, and I don't want to be that guy who tells people to use his stuff.

Though the deep-equality testing is really convenient and NUnit doesn't do that...

Today, that changes. I have a good reason to promote NExpect over NUnit now, apart from all of the obvious benefits of NExpect:

fluid expression
extensibility
deep-equality testing
better collection matching

Today I found that NExpect can tell you earlier when you've broken something than NUnit can.

Explain how?

Consider this innocuous code:

using NUnit.Framework;

[TestFixture]
public class Tests
{
  [Test]
  public void ShouldPassTheTest()
  {
    var result = FetchTheResult();
    Assert.That(result, Is.EqualTo(1));
    // or, the olde way:
    Assert.AreEqual(result, 1);
  }

  private int FetchTheResult()
  {
    return 1;
  }
}

Of course, that passes.

The interesting bit here is the usage of var, which, in C#, means "figure out the type of the result at compile-time and just fill it in". Long ago, that line would have had to have been:

int result = FetchTheResult();

var has some distinct advantages over the prior system. It's:

shorter to write
you only have to remember one "muscle-memory" to store a result (always var ___ = ___)
it means that if you do change return types, things are updated for you.

In theory (and practice), it makes you quicker on the first run and when you refactor.

The problem comes in when those strong types are discarded by code which compiles perfectly. The compiler can't save you from yourself every time!

Enter the refactor

When we update the above so that FetchTheResult now returns a complex object, the code will still compile:

using NUnit.Framework;
[TestFixture]
public class Tests
{
  [Test]
  public void ShouldPassTheTest()
  {
    var result = FetchTheResult();
    Assert.That(result, Is.EqualTo(1));
    // or, the olde way:
    Assert.AreEqual(result, 1);
  }

  public class Result
  {
    public int Value { get; set; }
    public DateTime Created { get; set; }
  }
  private int FetchTheResult()
  {
    return new Result()
    {
      Value = 1,
      Created = DateTime.Now
    };
  }
}

for the intent of the flow of logic, we're still returning the value 1, but we've also attached a DateTime property to that to indicate when that result was created. Rebuilding, we find that everything builds just fine, and perhaps we forget to re-run tests (or perhaps this function is very far away from where the result is being used, so we don't realise that we just broke a test somewhere else).

This is because the NUnit assertions fall back on object for types:

Assert.That is genericised for the first parameter, so it has a fixed type there, but takes a Constraint for the second parameter -- and a Constraint can house anything, because it casts down to object
Assert.AreEqual has an overload that expects two objects, so it will fall back on that, and also compile.

The test will fail -- if you remember to run it (or when CI runs it).

So how does NExpect help?

If we'd written the first code like so:

using NUnit.Framework;
using NExpect;
using static NExpect.Expectations;

[TestFixture]
public class Tests
{
  [Test]
  public void ShouldPassTheTest()
  {
    var result = FetchTheResult();
    Expect(result).To.Equal(1);
  }

  private int FetchTheResult()
  {
    return 1;
  }
}

then the refactor would have caused a compilation failure at second line of the test, since NExpect carries the type of result through to the .Equal method.

actually, it does a bit of up-casting trickery so that you

can, for example, Expect((byte)1).To.Equal(1);, but that's
beside the point for this particular post...

So the second the refactor had gone through, the test wouldn't compile, which means I could find the failure even before running the tests and update them accordingly, instead of waiting for tests to fail at a later date.

Conclusion

Strongly-typed languages have a certain amount of popularity because the types can help us to avoid common errors. This is why TypeScript is so popular. C# is strongly typed, but there are ways that the strength of that typing can be diluted, and one of those ways is found in NUnit assertions.

NExpect protects you here and alerts you about potentially breaking changes to your code before even running tests. Neat, huh?

I think I'll pat myself on the back for that 🤣

Introducing: NEWTS

Davyd McColl — Tue, 07 Jul 2020 07:38:48 +0000

I recently found myself in the position of needing to spin up several small TypeScript projects all at once, with the aim for at least two to publish to NPM. There are a bunch of steps to go through for this to work successfully, and I found myself remembering something and having to go back and apply it across all the projects.

I have a couple of library modules on the back-burner, so I could see how I was going to have to do all of this again, over and over again.

In the true nature of a lazy programmer, I figured that there had to be an easier way: spending several hours of my own time creating a tool which could do all of this for me 😆.

I figured this would be especially useful when I come up with an idea for a quick-n-dirty CLI tool to do something: with all the scaffolding out of the way, I could settle in on making things instead of boiler-plating.

But enough jibber-jabber! Let's check out 🦎 newts 🦎 and please take a moment to ⭐ the GitHub repository if you like what you see so that other people discover it*.

What's in the box?

NEWTS (literally "new ts" -- hey, naming is hard and all the good names are already taken on npmjs.com 😡) can bootstrap your TypeScript package with as little as one piece of information: the name of the package. In addition, it will:

test that the package name you've selected is available at npmjs.com
- naming is hard and it really sucks when you spend time making an awesome package with a name that fits, only to find that name is already taken by an unrelated project 😞
initialize git
- with relevant .gitignore
build your TypeScript to ES2018 JavaScript so anyone with a modern environment can use it
outputs your declarations so that anyone consuming your package from within a TypeScript environment will get the necessary types
install dev-packages
- typescript
- jest
- faker
- npm-run-all
- tslint (for now, until eslint behaves as expected)
- zarro (for release)
- relevant @types packages
set up tsconfig.json
- outputs to dist
- includes types
set up testing with Jest
- jest.config.js with ts-jest preset for node
- a starter spec file
set up tslint.json
select a license
create a skeleton README.md
set up your package.json
- scripts
  - build
  - test
  - release
  - release-beta
  - lint
- author information
- set up publish files from the dist folder
- set version to 0.0.1
- set up your CLI app
  - create a skeleton entry-point script with the correct hash-bang
  - install yargs
perform an initial build to check that everything is 👌

Most of these options are opt-out (with CLI setup being opt-in) by default.

Usage

There are three easy ways to get started on your next TypeScript project with newts.

interactively: npx newts
- you're asked some questions
- you can go back and change any answers
quickly: npx newts -n awesome-package --defaults
- the only input you may be prompted for is an output folder, if the current folder is under git version control. You may even omit --defaults if you know for sure you're not currently in a version-controlled folder, ie npx newts -n awesome-package
explicitly: npx newts -n awesome-package ...
- run npx newts --help to get a list of all possible flags
- newts uses yargs for commandline processing, so any --option can be negated by specifying --no-option

Now sit back and let newts bootstrap your project. This may take a minute as it will need to install packages into your project. I've found that the total run-time depends on network, but typically it's about 30 seconds to 2 minutes. Not bad considering that it saves me about 15-30 minutes of setup (and doesn't forget important configuration points!)

Notes:

You may explicitly specify where to create the project with the --output flag (or via the interactive interface), but the default is to create the project off of the current directory, unless you're in a git-controlled folder structure (because we potentially want to initialize git), in which case, you'll be prompted for a base folder to create your awesome-package folder in.
You may omit licensing and authoring information by specifying 'none' for these prompts
By default, authoring information is obtained by querying git's configuration, so hopefully your git is setup correctly 😁

I suggest using newts via npx as it's really the easiest way to always run the latest version

Working with your new project

Obviously, you can use whatever tooling you like to write your code, but at some point, you're going to want to release that package!

newts sets up two scripts for you (dependant on accepting the zarro dependency):

release
- builds the output JavaScript and typings, ready for publication
- runs your tests and linting
- increments the minor version and zeros the patch version (ie 1.2.3 will become 1.3.0
- creates a git tag for that version
- performs an npm publish
- pushes your commits and tags
release-beta, which is similar to release except:
- increments the patch version (ie 1.2.3 becomes .1.2.4)
- publishes with the beta tag
- use this to test that your package works as expected as a user: you can always npm install awesome-package@beta in a project to test your beta package. When you're happy, run npm run release to create an official release!

*Postscript:

I don't (personally) care much for GitHub stars, but I've seen that repositories which get starred frequently end up on lists like the Changelog Nightly email which might make it easier for someone to discover newts and have an easier time with their first TypeScript package.

Orthogonality

Davyd McColl — Mon, 08 Jun 2020 07:09:53 +0000

Definition

Orthogonality is a mathematical term referring to lines which are 90° to each other:

Seems abstract

The concept applied to software engineering may seem initially abstract, but the idea is quite simple: the axes on a graph are orthogonal to each other and provide the example we need: if we consider two axes, x and y:

We can see that if we only alter x, moving in any direction, we don't require a change in y. This is because x and y are orthogonal, and this is the point we're getting to in software terms:

Orthogonality in software refers to parts of the system which are not directly related. Often these parts interact with each other, but changes to one do not directly affect the other.

Getting practical

A common example of orthogonality is your business logic versus how your data is stored. For a business which sells items and needs to generate invoices, it doesn't really matter where we store invoices and line items -- flat files (never underestimate the humble flat file!), local database, Amazon s3 buckets, whatever. This is a common place where the principle applies. For example, if you're using Entity Framework (.net) or Knex (Node), you could quite easily swap out the method of storage (MSSQL, MySQL, Postgres) or even radically change the method of storage (Mongo, CouchDb) without having to change other layers in the app -- if you've ensured that there's a layer of abstraction in between those interacting layers.

Consider: if we write traditional ADO.NET code (with newer C# syntax, because it's neater!):

var customers = new List<Customer>();
using var conn = new SqlConnection(ConfigurationManager.ConnectionStrings["Main"].ConnectionString);
using var cmd = conn.CreateCommand();
cmd.CommandText = "select * from customers where is_trial = 1";
using var reader = cmd.ExecuteReader();
while (reader.Next())
{
  customers.Add(MapRowToCustomer(reader));
}
return customers;

Then we're quite tied into using MSSQL and ADO.NET here, especially if we have code like this scattered throughout the codebase. If you were using EF, this would be hidden from you:

no need for each part of the code to know where to find a configured connection string
no need to know how to open a connection
no need to know about the command/reader semantics of ADO.NET
no need to Dispose all of those (the clean new syntax hides 3 Dispose calls!)
no need to know the correct SQL dialect to perform the query

for example:

using var db = new Context();
return db.Customers
  .Where(c => c.IsTrial)
  .ToList();

As with everything, there are trade-offs -- at Codeo, we take a bit of a middle stance, using a CQRS pattern with commands / queries which have explicit SQL in them, so there are definitely parts of the code which are coupled with the database implementation. This has been done in the name of performance. But the rest of those concerns are tucked away in a common set of code.

Another common example is presentation (eg HTML, CSS, XAML) vs logic (eg JavaScript, C#, SQL). Even in the logic arena, we can have well-defined areas of abstraction which interact but changes in one don't (or shouldn't) cause changes in another.

A counter-example in the real-world is the control system of an helicopter: changes along one axis of movement require compensation along others. Becoming an helicopter pilot is no trivial task!

Orthogonality goes hand-in-hand with keeping things DRY because as common concerns are abstracted from code, we often find that a good abstraction will make the consumer unaware of the nuts-and-bolts of the code at the core of that abstraction.

Benefits of observing orthogonality

Isolation of common logic allows for across-the-board improvements or changes without affecting other parts of the system
Avoid vendor lock-in: if you've kept orthogonal concerns well-separated with abstract interfaces between them, it will be easier to swap out parts when necessary to address concerns of pricing or performance
Easier to test: when you don't have to spin up an entire functional "world" for tests, you can write smaller, faster tests that are:
- more likely to be run (faster)
- less likely to break when the system changes (maintainable)
- will better show where issues are introduced (more focused)

Design

Whilst programming for orthogonality, observe:

The "S" in SOLID (single responsibility)
- if a piece of code is doing too much, chances are good it's crossing orthogonal boundaries
Layering of your application
- Instead of shoving all code into one giant file, consider the many types of layered approaches which exist, some of the simplest and well-known being:
- Onion architecture
- MVC / MVVM
- This layering can be applied to documentation too
- Consider keeping presentation and content separate: write your documentation in a markup language which can be rendered neatly later (eg Markdown)
Keep code de-coupled
- Reveal the least necessary to let parts of the system interact with each other
- Consider the law of Demeter
- Instead of changing state on objects, ask them to do so; in this way, when a behavioral change goes hand-in-hand with that state change, it can be accomplished within the class where the change is required, instead of outside code having to do so
Avoid global data
- Global data becomes a point of coupling between different parts of the system. If you have a global static ApplicationSettings class which everyone is looking at, you can't test parts of the app in parallel with different configurations. If you have an injectable IApplicationSettings object, you can fake out the values for settings without having to actually back them from a database or wherever your settings come from. The settings themselves are orthogonal to the storage!

The takeaway

Whilst you're busy solving all of your requirements, always keep a look-out for orthogonal concerns and see how you can keep them from becoming entangled. This will provide you more freedom to change your system when required to do so.

You will find it easier to keep orthogonal code apart and DRY if you're constantly critical of your own code. Always look for neater ways to get things done.

Keeping DRY

Davyd McColl — Thu, 21 May 2020 07:48:33 +0000

One of the earliest principles we learn about in programming is DRY:

Don't
Repeat
Yourself

It's most commonly referenced in the scope of repeated code, but this doesn't just apply to code. Let's start there anyway 😅

DRY Code

Fundamentally, we'd like to not repeat code:

it takes time and effort to write and test
it would mean that any updates to the code have to be applied in multiple places. Bug? Fix multiple times. Enhancement? Alter in multiple places. Apart from the waste of time, there's the concern that we miss one of the implementations. Parallel implementations of the same logic tend to drift apart over time

When to refactor common code

Before refactoring out that code that looks so common, first consider the rule of three. The idea here goes:

Write the first implementation
Write the second implementation. Notice the similarities. Don't refactor just yet otherwise you risk refactoring out an implementation which is difficult to extend going forward, unless the problem scope is at least one of:
- very simple (eg FullName => FirstName + " " + LastName -- and even here, there are some edge cases, but it's a good starting point)
- quite abstract (eg hash algorithm)
- very well known (eg credit card number verification)
As you're starting on the third implementation, revisit (1) and (2). With the knowledge you have about the process right now, start refactoring out the common logic. Apply this refactored version in the three places you need it.

When code duplication is not knowledge duplication

The Pragmatic Programmer gives the following example:

Given the customer constraint that a user's age must be a positive integer and that the quantity that they are ordering of a product must also be a positive integer:

function ageIsValid(value) {
  return typeof value === "number" &&
         value > 0;
}
function quantityIsValid(value) {
  return typeof value === "number" &&
         value > 0;
}

The duplicated fragment of code is obvious. The book warns, however, that this is not duplicated knowledge, as ages and quantities are different bits of information. And, to a point, the book is correct. However, I'd probably want to take this one step further. I think that the following refactor is a good idea:

function ageIsValid(value) {
  return isPositiveInteger(value);
}
function quantityIsValid(value) {
  return isPositiveInteger(value);
}
function isPositiveInteger(value) {
  return typeof value === "number" &&
         value > 0;
}

And, right now, you could even inline that where these validations are used, as there's only one validation for both. Conceptually, they're different, so having dedicated functions for them abstracts away the details from the higher-level code. Also, it makes it much easier, later on, when the company has to validate that a user's age is within a certain range -- eg over 13 to be able to use the site -- and order quantities are fulfillable:

function ageIsValid(value) {
  return isPositiveInteger(value) &&
         isOldEnoughToUseSite(value);
}
function isOldEnoughToUseSite(ageInYears) {
  return ageInYears >= 13;
}
function isValidQuantity(value) {
  return isPositiveInteger(value) &&
         haveEnoughStockFor(value);
}
function haveEnoughStockFor(orderQuantity) {
  // ... imagine an implementation here (:
}

Your de-duplication refactorings should keep foremost that code is for co-workers, not compilers, so one of the primary aims would be to make the code easier to understand -- which makes it easier to maintain.

DRY Documentation

The wars over code comments are like tabs-vs-spaces or vim-vs-emacs: everyone has something to say, there are some strong opinions and few amicable outcomes from discussions on the topic 😅

There are people who say you should document everything -- comments all over the code and jsdoc or xmldoc or docstrings which clearly state the purpose of every function in your code.

There are other people who believe that all comments are bad.

I sit somewhere in between: If you're commenting on the what, then it's not useful. If you're commenting on the why, then it can be really useful.

Take this example from the book:

/**
* Calculate the fees for this account
*  - Each returned check costs $20
*  - If the account is in overdraft for more than 3 days,
*    charge the account $10 for each day
*  - If the average account balance is greater than $2000
*    reduce the fees by 50%
*/
function calculateFeesFor(account) {
  let fees = 0;
  if (account.returnedCheckCount > 0) {
    fees += account.returnedCheckCount * 20;
  }
  if (account.overdraftDays > 3) {
    fees += 10 * account.overdraftDays;
  }
  if (account.averageBalance > 2000) {
    fees /= 2;
  }
  return fees;
}

The commentary at the top of the function clearly duplicates the logic within the function. It doesn't add to the readability or understanding and it's likely to go out of sync with the function as the internals are changed. Have you come across code where the comment says one thing and the code itself does another? I have. The problem is that new programmer Bob is tasked with changing one business requirement: people are to be allowed more free overdraft time, and the free window won't apply to fees. So Bob updates the one part:

  if (account.overdraftDays > 5) {
    fees += 10 * (account.overdraftDays - 5);
  }

and forgets to update the comment.

So let's suggest some changes.

First off, there are a lot of "magic values" in this function. I'm talking about constants (like the 5 above) which should really have a name to communicate what they are to the reader of the code. If we can get the code to explain all of the what with good names, we're left with only having to document the why, if that's even necessary.

const RETURNED_CHECK_COST = 20;
const OVERDRAFT_FEES_PER_DAY = 10;
const OVERDRAFT_FREE_DAYS = 5;
const VIP_MEMBER_BALANCE = 2000;
const VIP_MEMBER_DISCOUNT_PERCENT = 50;

function calculateFeesFor(account) {
  let fees = 0;
  if (account.returnedCheckCount > 0) {
    fees += account.returnedCheckCount * RETURNED_CHECK_COST;
  }
  if (account.overdraftDays > OVERDRAFT_FREE_DAYS) {
    let chargedDays = account.overdraftDays - OVERDRAFT_FREE_DAYS;
    fees += OVERDRAFT_FEES_PER_DAY * chargedDays;
  }
  if (account.averageBalance > VIP_MEMBER_BALANCE) {
    fees *= (VIP_MEMBER_DISCOUNT_PERCENT / 100);
  }
  return fees;
}

Which is way better -- we gave those magic values names. We can make this read easier though, with a second round of refactoring:

function calculateFeesFor(account) {
  let fees = returnedCheckFeeFor(account) +
             overdraftFeeFor(account);
  fees -= vipDiscountFor(account, fees);
  return fees;
}

function vipDiscountFor(account, fees) {
  if (account.averageBalance > VIP_MEMBER_BALANCE) {
    return fees * (VIP_MEMBER_DISCOUNT_PERCENT / 100);
  }
  return 0;
}

function overdraftFeeFor(account) {
  if (account.overdraftDays > OVERDRAFT_FREE_DAYS) {
    // local law states we can't charge overdraft fees
    // during the free period because the advertising
    // is confusing
    let chargedDays = account.overdraftDays - OVERDRAFT_FREE_DAYS;
    return += OVERDRAFT_FEES_PER_DAY * chargedDays;
  }
  return 0;
}

function returnedCheckFeeFor(account) {
  return account.returnedCheckAccount > 0
    ? account.returnedCheckAccount * RETURNED_CHECK_COST
    : 0;
}

And now someone reading through the higher-level function (calculateFeesFor) can see, at a glance, how fees are calculated. When she wants to dig into the details, she can, and each individual function uses well-named variables to communicate the what of what's going on. We can also add the why comment to explain why we don't charge overdraft fees over the free period.

DRY Data

Consider the classes:

class Line {
  public start: Point;
  public end: Point;
  length: number;
}
class Point {
  public x: number;
  public y: number;
}

This is a perfectly valid representation of a line -- it has a starting and ending point, and all lines have a length (even if zero). However, there's a data duplication here in that the two points, start and end, determine the value of the length property.

So when someone updates this line, they would have to remember to update the length too.

Better, then would be:

class Line {
  public start: Point;
  public end: Point;
  public get length(): number {
   return start.absoluteDistanceTo(end);
  }
}
class Point {
  public x: number;
  public y: number;
  public absoluteDistanceTo(another: Point): number {
   const xDelta = end.x - start.x;
   const yDelta = end.y - start.y
   Math.sqrt((xDelta * xDelta) + (yDelta * yDelta))
  }
}

In the above, there is one source of truth for the length of a line, as determined by the absoluteDistanceTo method on Point.

If performance is a concern, then we start getting clever with property get/set methods, updating the length only when start or end are modified, and returning the cached length value:

public class Line {
  public get start(): Point {
    return this._start;
  }
  public set start(value) {
    this._start = value;
    this._updateLength();
  }
  public get end(): Point {
    return this._end;
  }
  public set end(value) {
    this._end = value;
    this._updateLength();
  }
  public get length() {
    return this._length;
  }

  private _start: Point;
  private _end: Point;
  private _length: number;
  private _updateLength() {
    this._length = this._start.absoluteDistanceTo(this._end);
  }
}

DRY Representation

It's inevitable that representations will be duplicated. The simplest example is perhaps a web front-end (I'm not picking a side in this article! 😅) for a web-api back-end (again, no sides 😁): both sides of that api (or contract) have to have knowledge of that contract to be able to work. If a new client is added (say, a mobile app), then that information has to be duplicated again in the new client.

This kind of duplication can't really be avoided -- the api has to know what contract it should stick to and the client has to know what contract the api provides.

However, the burden of this repeated information can be lightened considerably by having one source of truth and generating the other sources of reference information.

For example, defining your api in Swagger and then having your api conform to it whilst it generates the schema for that contract (as well as validating information crossing that boundary) means that when a change happens, everyone knows what the change is and can be adapted to handle that change as Swagger will produce a document defining that change and there is even tooling to generate client-side interfaces if you want.

If you must have repeating data / code / representations, spend the time to figure out a way to have one source of truth for that data.

Sharing is caring

The book speaks of a Y2K audit on government software which found that the 10000 programs audited all had their own internal (often subtly different) mechanisms for validating a social security number. This seems like a good place to be DRY -- but going DRY across multiple programs and teams requires:

Good inter-team communication

The first is quite important: how will I know if a team-member (even if on a different team in the company, we're all part of some larger team) has implemented something that I need if we don't communicate? Daily stand-ups are a good starting place, but so are dedicated times for people to "show and tell" what they've been working on or have learned recently. Perhaps Jane in the European division has come up with a novel way to solve a problem. Or perhaps Karen has just discovered a library which does stuff that I'm about to write by hand. Providing a platform for people to share this knowledge is crucial to effective success in the company.

In a way, dev.to is like this -- for a larger community of people I might never meet! On that scale, it's also our responsibility to promote open-source initiatives which solve common problems so that people are spending more time solving their own interesting problems and less time solving common problems. We have a limited amount of time we can spend on tasks, so we should choose how to use that time wisely

Common methods for sharing that common code or knowledge

If you can, put that code up on Nuget, NPM or whatever is the default package manager for the ecosystem you're working in. Always ask your manager if you can open-source stuff which you feel may benefit the community at large. If the code you'd like to open-source isn't specific to your company, it shouldn't be too hard to motivate: we all benefit from open-source, so it's good to give back.

As an added bonus, your functionality will be available with minimal friction to others.

If you can't motivate for public package hosting, then look into private hosting. NPM offers paid private hosting, or you can use Verdaccio. Private nuget hosting can be done with MyGet. At the very least, you could use the git submodule feature to share code between teams: extract out the common code and put that into a git repository which people can import via a submodule!

Make it easy to use

At the end of the day, whatever choices you make in helping to keep things appropriately DRY, you have to remember to keep it easy to use. Where possible:

have a single source of truth for rules and business data
find a way to share common application logic via easily-installed packages
share your learnings and creations with the people around you

#TIL how to move uncommitted code from one git repo to another

Davyd McColl — Thu, 14 May 2020 13:56:55 +0000

TL;DR:

in the source repo, do:

git stash
git stash show -p > /tmp/stash.patch
git stash drop

in the target repo, do:

git apply /tmp/stash.patch

🎉 WIN 🎉

The full story:

I often have two clones of work repos on my machines:

one I'm working in
one where I can check out reviews or do fixes for ongoing PRs without disrupting my main working repo

Today, I started doing some work in the secondary clone and realised that I needed to move that work over to the primary one. I hadn't committed, and I figured that there was a way to do this with git's stash command, but I wasn't sure. So I googled a bit to get to the above, based on a stackoverflow post.

Let's go through what's happening:

In the source repo

git stash puts all your uncommitted changes in the stash, which is a stack-based storage for changesets.
git stash show -p shows the latest stashed changeset in patch format. Here I pipe it into a file in /tmp, but you could pipe it anywhere. Without the -p, git stash show will give you similar information as what you'd see with git log --stat: showing a condensed version of the changes per file. So don't forget that -p!
git stash drop drops the latest stash -- you won't be needing it, since you have a patch file, but if you're feeling nervous, don't: there's a way to get it back

In the target repo

git apply /tmp/stash.patch applies the patchset to your current repository

Wrapping up

git can be challenging and confusing when you're new to it... even when you're not-so-new to it 😆 but the one thing I like to remind people is that it's quite difficult to permanently lose information in git. Well, except if you git reset --hard, then you can kiss those uncommitted changes good-bye! But most of the time, the reflog or fsck can find pieces you think are gone forever. Also, git probably does a lot more than you might expect, so try googling what you want to do before resorting to a manual plan or panicking -- chances are someone has had the same problem before and found a solution!

JavaScript: what's the point of bind()?

Davyd McColl — Wed, 25 Mar 2020 18:51:04 +0000

A fellow at work is currently working through a JavaScript course. He shared the following snippet of code:

let post = {
    id: 1,
};

let UI = {
    render: function(){
        console.log(this.id);
    }
};

let r = UI.render.bind(post);
r();

And asked the question:

I still don’t fully understand what the point of the bind keyword is and what it is supposed to achieve, maybe you can clarify? Why not just call the object directly with “post.id” instead of “this.id” and then
binding it in a third function.

Which I thought was a good question -- and I'm sure others have asked it. I'm quite sure I remember asking it myself.

Functions are first-class citizens

First off, we have to remember that functions in JavaScript are first-class citizens. This means that we can pass them around like any other object:

function modifyAndLog(startingNumber, modifyingFunction) {
  const result = modifyingFunction(startingNumber);
  console.log(`Modified ${startingNumber} to get result ${result}`);
  return result;
}

function double(number) {
  return number * 2;
}

function doubleAndLog(number) {
  return modifyAndLog(number, double);
}

doubleAndLog(2); // prints out a message and returns 4

See how we can pass functions around like any other object? This is also why the following function declaration syntax works:

var add = function(a, b) {
  return a + b;
}

(which, of course, is equivalent to the following):

var add = (a, b) => a + b;

but let's forget about arrow functions (for now) as they introduce a different behavior for .bind() (for good reason). I'll circle back to this later. Also, please bear the following in mind with respect to the above syntax:

[1] function variable declarations are hoisted to the top of the file, however the assignment only happens when that code is run:

var a = function() {
    b(); // will error
};
a();
var b = function() {
    console.log("b called");
};

[2] function variable declarations like the above create anonymous functions, which traditionally gave horrid stack traces when they eventually error: instead of seeing that you have an error in function a,you may see just the line number, and an anonymous function specified. Modern browsers and NodeJS versions give better messages, but I still recommend that if you absolutely must use function variable declarations like this, that you do

var a = function a() {
    b(); // will error
};
a();
var b = function b() {
    console.log("b called");
};

Rather prefer to explicitly define your functions in the form:

function a() {
}

and "var them off" if you really need to:

function a(fn) {
    console.log(fn());
}

function b() {
    return "b called";
}

var bFunction = b; // this var is unnecessary: just here to illustrate
a(bFunction); // prints "b called"

Functions are new, every time

Consider this code:

function Foo() {
  this.add = function(a, b) {
    return a + b;
  };
  this.add2 = function(a) {
    return this.add(a, 2)
  };
}

var foo1 = new Foo();
var foo2 = new Foo();

console.log(foo1.add === foo2.add); // logs false

This is ye olde syntax for object creation. This, kids, is what we used before the es6 class syntax (also used by TypeScript) became available.

Note here that the Foo function:

Creates a new anonymous function
Assigns that to the doStuff property on the new'd up object

This is why prototypes exist as they do: in a memory-constrained environment, we don't want code like the above creating many copies of (essentially) the same function. So a better solution to the above would be:

function Foo() {
}
Foo.prototype = {
  add: function(a, b) {
    return a + b;
  },
  add2: function(a) {
    return this.add(a, 2);
  }
};

function makeFoo() {
    return new Foo();
}
var foo1 = makeFoo();
var foo2 = makeFoo();
console.log(foo1.doStuff === foo2.doStuff); // logs true

In the above, we save memory (and compilation time) by essentially re-using the same function pointer every time we new up a Foo. This especially makes a difference if you're newing up hundreds of Foos.

Interestingly, because of the "light-copy" nature of the prototype, modifying the prototype later will apply that modification to every instance of the prototype, even existing ones:

var foo = makeFoo();
Foo.prototype.add = function(a, b) {
    // introduce an off-by-one error
    return a + b + 1;
}
console.log(foo.add(1, 2)); // prints 4, not 3

JavaScript has a history

JavaScript was created by Brendan Eich in a very short time period to embed in Netscape Navigator around 1995. Every time we find something "odd" with JavaScript, bear in mind that:

It was created on a shoestring time-budget (about 2 weeks)
It had to work on much more constrained machines than today -- even the phone in your pocket is orders of magnitude more powerful, computationally and memory-wise

Prototypes were an elegant solution to the above problem. In essence, the above prototype code could be written as:

function makeFoo() {
  var result = {};
  result.add = add.bind(result);
  result.add2 = add2.bind(result);
  return result;
}
function add(a, b) {
  return a + b;
}
function add2(a) {
  return this.add(a, 2);
}

The .bind calls are necessary so that add2 has a correct reference for this when it is called.

In reality, the mechanism is a little more complex, and involves calls on this.{whatever} searching through the prototype chain for methods. But the example above illustrates a possible solution.

Aside: Also remember that you can set the this context for any function by using either .call or .apply:

function add2(a) {
  return this.add(a, 2);
}
const adder = {
  add: function(a, b) {
    return a + b;
  }
};
const bound = add2.bind(adder);
console.log(bound(2)); // logs 4
console.log(add2.call(adder, 6)); // logs 8
console.log(add2.apply(adder, [10])); // logs 12

The only difference between .call and .apply is that .apply takes an array of arguments, where .call takes arguments as parameters. This makes it useful when you want to programmatically build up arguments for a function -- you put them in an array and use .apply

.bind can be essentially rewritten as:

function bind(ctx, fn) {
    return function() {
        return fn.apply(ctx, arguments);
    };
}
const adder = {
    add: function(a, b) {
        return a + b;
    }
};

function add2(a) {
    return this.add(a, 2);
}
var bound = bind(adder, add2);
console.log(bound(13)); // prints 15

What's `this` anyway?

Every object-oriented programming (OO) language that I've ever encountered has the concept of the current object context within member methods, often called this, though VB used Me and in Python it can be whatever you like, but the convention is self, as it is in Ruby, perhaps a nod to Python which came 5 years earlier? PHP and ITcl use $this, which is really just this in their own dialect 😆

Consider C#:

public class Adder
{
    public int Add2(int a)
    {
        // note that `this` can be dropped in C#,
        // because the compiler can infer that
        // the Add method exists on `this`. But I've
        // included it here for clarity
        return this.Add(a, 2);
    }

    public int Add(int a, int b)
    {
        return a + b;
    }
}

Python is more explicit: members must be declared taking in as their first argument the context on which to operate.

class Adder:
  def add(self, a, b):
    return a + b

  def add2(self, a):
    return self.add(a, 2)

foo = Adder()
print(foo.add2(4)) # prints 6

It turns out that Python is just being very explicit about what other runtimes and languages do anyway.
For example, if we were to use reflection to invoke Add2 on the C# class above, it could be:

var adder = new Adder();
var add2Method = typeof(Adder).GetMethod(nameof(Adder.Add2));
Console.WriteLine((int)add2Method.Invoke(adder, new object[] { 4 }); // prints 6

The .net runtime is doing the same thing when it invokes methods. Similarly, C++ methods are compiled in such a way as to take the context to become this as the first parameter, and calls to that method
are compiled to explicitly provide this context. (At least, it was, last I checked).

The concept of this is "transparent magic" to the programmer in most OO languages.

Coming back to answer the original question

There are several circumstances where being able to bind is advantageous

Passing a member as a callback

Imagine this code, which does stuff with DOM elements:

class BodyClicked1 {
    _element;
    _clickedCount;

    constructor() {
        this._element = document.querySelector("body");
        this._clickedCount = 0;
        this._element.addEventListener("click", this.clicked.bind(this));
    }

    clicked(ev) {
        this._clickedCount++;
        console.log(`You've clicked me ${this._clickedCount} times`);
    }
}

Without the call to .bind, the DOM element would call the provided handler (eventHandler) without any context, so the line this._clickedCount++ would error, most likely with an error like this. is not a function. The DOM element doesn't have the context, so it can't know what to call. Of course, we could also rewrite the above as:

class BodyClicked2 {
    _element;
    _clickedCount;

    constructor() {
        this._element = document.querySelector("body");
        this._clickedCount = 0;
        this._element.addEventListener("click", ev => this.clicked(ev);
    }

    clicked(ev) {
        this._clickedCount++;
        console.log(`You've clicked me ${this._clickedCount} times`);
    }
}

But we should also unsubscribe when we're done, which we can't do without a reference to the original subscribing function, ie:

class BodyClicked3 {
    _element;
    _clickedCount;
    _clicked;

    constructor() {
        this._element = document.querySelector("body");
        this._clickedCount = 0;
        this._clicked = this.clicked.bind(this);
        this._element.addEventListener("click", this._clicked);
    }

    destroyed() {
        if (this._element) {
            this._element.removeEventListener("click", this._clicked);
            this._element = undefined;
        }
    }

    clicked(ev) {
        this._clickedCount++;
        console.log(`You've clicked me ${this._clickedCount} times`);
    }
}

If we didn't have the bound function, a call to removeEventListener wouldn't properly unsubscribe, because we'd be passing in a new function:

class BodyClicked4 {
    _element;
    _clickedCount;

    constructor() {
        this._element = document.querySelector("body");
        this._clickedCount = 0;
        this._element.addEventListener("click", this.clicked.bind(this));
    }

    destroyed() {
        if (this._element) {
            // doesn't work because it's not the exact same function we bound with
            this._element.removeEventListener("click", this.clicked.bind(this));
            this._element = undefined;
        }
    }

    clicked(ev) {
        this._clickedCount++;
        console.log(`You've clicked me ${this._clickedCount} times`);
    }
}

Frameworks like AngularJS

AngularJS has always been one of my favorite frameworks. Perhaps just because I learned it quite early on, or perhaps because it just did more and sat better with me than Knockout or CanJS did at the time. AngularJS is still kept up to date, so don't count it out. Personally, I find it more flexible than Angular, though both have their merits. Anyway, I'm not here to start The War Of The Angulars 😄 and anything new I write at the moment would probably be in Vue, so there's that 😛

If we have a look at how an AngularJS directive can be created:

angular.module("app")
    .directive("CustomElement", ["$scope", function() {
        return {
            restrict: "E",
            template: "<button ng-click='clicked'>Click me</button>",
            controller: function ($scope) {
                $scope.clickCount = 0;
                $scope.clicked = function() {
                    $scope.clickCount++;
                    alert(`you clicked the button ${$scope.clickCount} times!`);
                }
            }
        };
    }]);

With the above code, every time a custom-element is created, a brand-new clicked function is created, compiled and stored in memory. Not a big deal if this is only created a few times in the lifetime of the app, but if you have a bunch of repeated custom-element tags, you're paying CPU and memory that you don't have to. We can't use a prototype here because AngularJS simply calls the function we gave it with the dependencies we asked for. However, we can use .bind:

(function() {
    // use a closure to stop the function `clicked` from leaking out or being
    // overwritten elsewhere
    angular.module("app")
        .directive("CustomElement", ["$scope", function() {
            return {
                restrict: "E",
                template: "<button ng-click='clicked'>Click me</button>",
                controller: function ($scope) {
                    $scope.clickCount = 0;
                    $scope.clicked = function() {
                        $scope.clickCount++;
                        alert(`you clicked the button ${$scope.clickCount} times!`);
                    }
                }
            };
        }]);
    function clicked() {
        this.clickCount++;
        alert(`you clicked the button ${this.clickCount} times!`);
    }
})();

Whilst .bind produces a new function every time, the original function only has to be JIT'ed once -- the bound version is doing something like my example above, performing clicked.call with the provided context. In addition, our controller function can be kept shorter and neater -- we could even declare the methods in other files, eg if we were using es6 modules or AMD (eg Require).

Binding parameters

.bind isn't only useful for binding the context to use for this -- you can bind parameters too (essentially, currying):

function add(a, b) {
  return a + b;
}
var add2 = add.bind(null, 2);
console.log(add2(8)); // prints 10

note that we still need to provide an argument for the context -- above, I didn't really need a context, so I bound null

Arrow functions

I promised to come back to this...

Arrow functions are not just nice to look at -- they also introduce new behavior with respect to the context of a function.

Consider code like this:

class SomeService {
  fetchData() {
    return $.get("/data").then(function(result) {
      return this.process(result);
    });
  }
  process(data) {
    // does some stuff with the data
  }
}

I'm sure we were all caught out at some point with code like the above, and this not being quite what we expected. A simple solution is:

class SomeService {
  fetchData() {
    var self = this;
    return $.get("/data").then(function(result) {
      return self.process(result);
    });
  }
  process(data) {
    // does some stuff with the data
  }
}

See that var self = this; line at the top? That's an easy go-to as an alternative to using .bind(), which we could have, like so:

class SomeService {
  fetchData() {
    var bound = this.process.bind(this)
    return $.get("/data").then(function(result) {
      return bound(result);
    });
  }
  process(data) {
    // does some stuff with the data
  }
}
// or, shorter
class SomeService {
  fetchData() {
    return $.get("/data").then(
      this.process.bind(this)
    });
  }
  process(data) {
    // does some stuff with the data
  }
}

Both options are unnecessarily cumbersome, so the arrow function was introduced. Arrow functions cannot have their this binding changed -- they are assigned this from the scope in which they are declared. (They also don't have access to arguments or super).

Arrow functions make the code above simpler to read and understand:

class SomeService {
  fetchData() {
    return $.get("/data").then(
      result => this.process(result)
    );
  }
  process(data) {
    // does some stuff with the data
  }
}

When you can use arrow functions, I suggest you do, as they make reading the code a lot simpler for others. When you can't, there's always the trusty .bind()

Wrapping up

.bind is an essential tool in the JavaScript developer's toolbox. Understanding how (and when) to use it is vital to being able to write effective JavaScript. Understanding the nuts-and-bolts of .call and .apply is also good 😄

Bind mounts with an OpenRC service

Davyd McColl — Sun, 15 Dec 2019 15:38:33 +0000

Recently, Windows 10 is refusing to connect to my SMB service on my desktop Gentoo Linux machine. It basically refuses to use anything other than domain auth, and my Gentoo machine doesn't know anything about a domain, most especially my work domain (which is what the laptop wants to use -- .\username doesn't seem to help, and giving my Gentoo machine's name as the domain doesn't help either, most likely because I don't have a domain controller running -- and I really don't need one at home).

After about 1/2 an hour of trying to convince the Windows machine to connect to SMB shares it had had no problem with a few months ago (before the last Great Windows Update), I thought "stuff it, I'll just go old-school and install VSFTPD on my Gentoo machine so I can copy some stuff off to watch during the impending load-shedding".

For those of you lucky enough not to live in South Africa, "load-shedding" is a phenomenon where the state-owned electricity provider, due to rampant corruption and mismanagement for the last 20 years, is unable to provide power to the entire country, so, for fear of rolling blackouts caused by overloading the grid, certain neighborhoods are literally turned off for two hours at a time.

Yes, it's about as much fun as it sounds. Fortunately, I have a nice laptop and plenty of media stored offline. I just have to get the media onto the laptop. Hence the fun with connections.

Now, VSFTPD (the Very Secure File Transfer Protocol Daemon) lives up to its name: it's Very Secure. Part of that security is that users who log in to the server -- even the anonymous user -- are confined to a chroot jail so that they cannot possibly access files outside of their allowed domain. This works quite well for regular users, who are confined to their home folders by default, as well as the anonymous user, who is also confined to a special place on disk. The problem comes in when you'd like to allow access to some parts of the filesystem: VSFTPD does not follow symlinks (for security reasons), so I can't just symlink in my media drives. Another plan has to be made.

The generally accepted answer is to use bind mounts, which worked, but leaving these mounts in /etc/fstab as auto-mounting resulted in odd behavior: after booting, the mounts wouldn't be showing the same contents as the folders they were linked against. If I unmounted and remounted them, they worked just fine. I have a feeling they were being mounted before their targets were being mounted, perhaps because my original script, run via cron at @reboot wasn't waiting for local mounts to complete.

So first attempt was to:

set the mounts as noauto
alter my hacky script to do the mounting for me
- that script could take arguments like -d 120 to delay the mounting
add this as a @reboot line in my crontab for root (with crontab -e)

here it is (don't judge me! I know it's hacky! I was trying to figure out wtf was going on, and I also was getting tired of debugging this issue with only a few minutes until the power is cut, and no media to watch on my laptop (: ):

#!/bin/sh
BASE=/var/ftp/pub
LAST=""
DELAY=0
while test ! -z "$1"; do
  if test -z "$LAST"; then
    LAST="$1"
  else
    if test "$LAST" = "-d"; then
      DELAY="$1"
    fi
    LAST=""
  fi
  shift
done

if test "$DELAY" != "0"; then
  echo "delaying by $DELAY seconds"
  sleep $DELAY
fi
for m in $BASE/*; do
  umount $m &> /dev/null
  if test -z "$(mount | grep $m)"; then
    mount $m
  else
    echo "Unable to (re-)mount $m: already mounted and umount denied"
  fi
done

If you're new to bash, the while loop at the top, with the shift command near the end, is a way of cycling through arguments provided to the script until we run out:

shift, like Javascript's Array.prototype.shift, removes the first element from the array of arguments that this script was invoked with
test ! -z "$1" tests the first argument in the args list to see if it's empty -- so once all arguments have been shifted off, $1 is empty (:

I figured someone else might like to have a look at the OpenRC init script:

it's an example of how simple OpenRC scripts can be, unlike the dumpster-fire that is systemd 🔥
- all flaming aside: everything sucks in its own special way, so I'm sure OpenRC isn't perfect -- but systemd has so many "features" which make me dislike it intensely
it's an example of
- line-by-line file reading with bash
- some of the simplest, but very powerful GNU utils
  - awk
  - grep

#!/sbin/openrc-run

depend() {
  need localmount
}

start() {
  for MOUNT_POINT in $(find_bind_mounts); do
    do_mount $MOUNT_POINT
  done
}

stop() {
  for MOUNT_POINT in $(find_bind_mounts); do
    do_umount $MOUNT_POINT
  done
}

do_mount() {
    if test -z "$(mount | grep -E "\s$1\s")"; then
      echo "  mount $1"
      mount $1
    else
      echo "  already mounted: $1"
    fi
}

do_umount() {
    if test -z "$(mount | grep -E "\s$1\s")"; then
      echo "  already unmounted: $1"
    else
      echo "  umount $1"
      umount $1
    fi
}

find_bind_mounts() {
  while read LINE; do
    OPTS="$(echo $LINE | awk '{print $4}' | grep -E '(,)?bind(,)?')"
    if test -z "$OPTS"; then
      continue
    fi
    echo $LINE | awk '{print $2}'
  done < /etc/fstab
}

Some explanations:

This script should be run with /sbin/openrc-run (see the hash-bang line) because that stub provides a lot of base functionality:
- provides default start, stop and status functions
- understands how to get dependencies from depend()
we declare services that this one depends on in the depend function, one per-line. Simple!
OpenRC scripts can be as short as just a few lines long because there are default implementations for start, stop and status (see here: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md
- in this case though, I'm not starting a daemon process: I want to do some work at startup and some more at shutdown, so I implement start and stop myself
from start() and stop()
- while read LINE; do echo $LINE; done < some_file is how you can work over a file line-by-line in bash. Now you know (:
from find_bind_mounts()
- awk '{print $1}' prints the first field found on a line -- this is a really simple way to get a field out of a line which is broken up by whitespace -- like fstab entries! Field 4 in /etc/fstab describes the mount options...
- so bind mounts will have bind in there somewhere. Now we need to invoke grep with -E to use Extended syntax and the regex I'm using searches for the word "bind" preceded either by whitespace or a comma, and followed either by whitespace or a comma, so matches would be, eg: auto,bind, bind,noatime,noauto or noatime,bind,noauto, remembering that the mount options field is not the last field, so there would be whitespace before and after it.
  - we get lines like:
```
/mnt/monolith /var/ftp/pub/monolith none defaults,bind,noauto 0 0
```

once we have a line describing a bind mount, we select out the second field with awk, since this is the directory into which we would be mounting, so the shorthand syntax of mount <mount-point> would work
- from the above line, we would get /mnt/monolith

from do_mount() and do_umount()
- just to be safe, we check if the mount point retrieved from /etc/fstab is already mounted with mount | grep -E "\s$MOUNT_POINT\s", which would look for that mount-point by name, surrounded by whitespace, from the mount command
- mount would print lines like: /dev/sdh1 on /mnt/monolith type fuseblk (rw,nosuid,nodev,noexec,noatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) and the second field in that line is the mount-point
- if we're starting up and the mount-point is already mounted, we don't do it again (a bind mount can be done again onto the same directory!)
- if we're shutting down and the mount-point is not mounted, we also don't attempt to unmount it

And whilst booting, we get the following output from OpenRC:

mount-binds        |  mount /var/ftp/pub/monolith
mount-binds        |  mount /var/ftp/pub/piggy
mount-binds        |  mount /var/ftp/pub/dump
 [ ok ]

And that's about all (:

Duck-Typing with PeanutButter #1

Davyd McColl — Sat, 14 Dec 2019 17:54:36 +0000

Some time ago I started a thread on duck-typing, and then went on to elucidate further. I've also given a presentation on duck-typing at my work.

Honestly, I've been putting off this blog because it's a little daunting to go through the full process for how PeanutButter.DuckTyping actually works. There's type emission, IL generation and quite a lot of reflection. I'm quite sure most people would lose interest quite quickly. If you're not one of those people -- great! You're more than welcome to check out the source on GitHub

As Scott Hanselman says, we have a limited number of keystrokes, so I'd rather spend them on something that delivers a little more value: a run-down of why you might want duck-typing in .NET (or, rather, why I wanted it, and why PeanutButter.DuckTyping was born), and an introduction to how to use the .DuckAs<T>(), .FuzzyDuckAs<T>() and .ForceFuzzyDuckAs<T>() extension methods provided by PeanutButter.DuckTyping. So here we go!

What is Duck-Typing?

That's a good question!

I feel I've covered this in prior posts (1 2) and the presentation linked above). Feel free to check those out and come back here (:

Why would you want to duck-type?

Ok, so there are many reasons why a person might want to duck-type -- heck, Microsoft even created the dynamic keyword and ExpandoObject because there are use-cases for leaving type determination to as late as possible.

Side-note: please don't use dynamic:

it's slow... really... slow.
it negates your compiler's type-checking abilities
it's not supported any more and has some serious bugs

My use-case was that I was building a web front-end to a generic workflow system. The front-end should be able to query information (what workflows are available / in progress) and invoke actions on the workflows. However, I wanted to leave the decisions about what could be done on a workflow as late as possible, because I wanted workflows to define the actions that were available at any time.

So I ended up wanting a single, tolerant end-point I could hit with JSON data determined from the currently-loaded workflow and the user's actions.

I thought that some kind of duck-typing would be ideal for what I wanted to do. There were already some available options:

I could have a bunch of custom reflection code in my web api code
I could use ImpromptuInterface

The former seemed like I'd end up with a rather "dirty" project. The latter I only discovered once I'd done the bare minimum of PeanutButter.DuckTyping, and by then I had requirements that ImpromptuInteface couldn't handle, like fuzzy-ducking (more on this later). A colleague of mine didn't see eye-to-eye on this: he reckoned I was wasting my time. Perhaps I was! But I learned a lot, and in the end, I have a library which works incredibly well for all the workloads I throw at it. It's consistently the one project of mine that I'm surprised by when I use it for the first time in a long time because it just does what I expect it to.

Like any code, it could be better and prettier. Like any code, it's not perfect. But unlike most of my code, I still like it (:

Enough jibber-jabber! I want to duck-type now!

Cool beans!

For my presentation, I wrote a cli demo which takes you through some of the capabilities of PeanutButter.DuckTyping and scenarios you might want to use it for. I'm pretty-much going to run through those here:

1. Reading from unrelated classes

Let's imagine that we have a class from an assembly that we don't control, and it doesn't implement any interfaces -- but we'd really like it to, perhaps for testing, perhaps for other purposes (which we'll explore later). We just want to be able to read from it, for now at least (modified from demo source):

public interface IReadOnlyEntity
{
    int Id { get; }
    string Name { get; }
}

// imagine this came from another assembly
public class LooksLikeAnEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public override void Run()
{
    var unrelatedObject = new LooksLikeAnEntity()
    {
        Id = 42,
        Name = "Douglas Adams"
    };

    var ducked = unrelatedObject.DuckAs<IReadOnlyEntity>();
    Log("Original:\n", unrelatedObject, "\nDucked:\n", ducked);
    DoStuff(ducked); // will compile!
}

private void DoStuff(IReadOnlyEntity entity)
{
  // gnarly logic goes here
}

Let's unpack this:

we had our original object
we had an interface we'd like it to conform to
- this interface matches the types and names of the original object perfectly
- in addition, the interface only requires read-access to the properties

But why bother? Why not just make DoStuff take an instance of LooksLikeAnEntity? Some reasons include:

not having a third-party class exposed in our api
not requiring full (ie write-) access to the object in DoStuff and wanting to prevent write-back
the entity we're duck-typing may be a lot more complex, perhaps with tens of properties and/or methods we don't care about, and we'd like to keep the consuming code simpler.

That last reason brings me to an idea I call interface shielding, which is where I might want to shield the full data of an object from a consumer, for example:

public class Person
{
  public int Id { get; set; }
  public string Name { get; set; }
  public string Address { get; set; }
  public DateTime DateOfBirth { get; set; }
}

The class above could be exposing too much data for the code that will consume it. Imagine if you'd like to pass off this data to a consumer without letting that consumer have access to the Address or DateOfBirth. Of course, you could write another class and map values -- or you could shield with a simpler interface:

public interface IIdAndName
{
  int Id { get; }
  string Name { get; }
}

// elsewhere
public void Producer()
{
  foreach (var person in FetchPersons())
  {
    Consumer(person.DuckAs<IIdAndName>());
  }
}

private void Consumer(IIdAndName details)
{
  // code here can't get to the Address or DateOfBirth
  // -> due to the way DuckAs<T> works, it would even be
  //    very tricky via reflection
}

Not only would Consumer not have access to sensitive data, but it would also not have write-access to insensitive data. This can also help to make the intent of Consumer clearer.

I use this method quite a lot in tests, for example when I want to prove that an item retrieved from the database matches an expected item and some of the properties on both are auto-generated (like Created DateTime values) -- here I might create a lesser interface, duck-type the two objects onto it and Expect(actual).To.Deep.Equal(expected); (see my posts on NExpect to learn more about how to use this handy deep equality assertion!)

There's a lot more PeanutButter.DuckTyping can do, including:

duck-typing app configuration (ie NameValueCollection) onto an interface to pass to code consuming configuration
- I use this quite a lot: it's really convenient!
- it's even possible to use key prefixes and duck-type only the settings with that prefix
duck-typing dictionaries to known interfaces, with write-back
duck-typing methods from one object onto a known interface
fuzzy duck-typing where:
- member names don't have to match case
- extraneous characters in member names are ignored (eg underscores)
- property types don't have to explicitly match: auto-casting is done for you
forceful fuzzy duck-typing which allows duck-typing an empty dictionary onto an interface and collecting the data which is written back
merged duck-typing in which a collection of objects or a collection of dictionaries can be duck-typed onto a single interface, with priority given to the first matching member found amongst any item in the collection

If any of this sounds interesting, tune in for the next part in this series!

NExpect, Level 3: You're the secret sauce!

Davyd McColl — Tue, 03 Dec 2019 17:34:31 +0000

In previous posts, I've examined how to do simple and collection-based assertions with NExpect

These have enabled two of the design goals of NExpect:

Expect(NExpect).To.Be.Readable();
- Because code is for co-workers, not compilers. And your tests are part of your documentation.
Expect(NExpect).To.Be.Expressive();
- Because the intent of a test should be easy to understand. The reader can delve into the details when she cares to.

Now, we come on to the third goal, inspired by Jasmine: easy user extension of the testing framework to facilitate expressive testing of more complex concepts.

Most of the "words" in NExpect can be "attached to" with extension methods. So the first question you have to ask is "how do I want to phrase my assertion?". You could use the already-covered .To or .To.Be:

internal static class Matchers
{
  internal static void Odd(
    this IBe<int> be
  )
  {
    be.AddMatcher(actual =>;
    {
      var passed = actual % 2 == 1;
      var message = passed
                    ? $"Expected {actual} not to be odd"
                    : $"Expected {actual} to be odd";
      return new MatcherResult(
        passed,
        message
      );
    });
  }
}

The above extension enables the following test:

[Test]
public void ILikeOddNumbers()
{
  // Assert
  Expect(1).To.Be.Odd();
  Expect(2).Not.To.Be.Odd();
}

There are a few concepts to unpack:

.AddMatcher()

This is how you add a "matcher" (term borrowed from Jasmine... Sorry, I couldn't come up with a better name, so it stuck) to a grammar continuation like .To or .Be. Note that we just create an
extension method on IBe where T is the type you'd like to test against, and the internals of that extension basically just add a matcher. This takes in a Func so your actual matcher needs to return an IMatcher result, which really is just a flag about whether or not the test passed and the message to display if the test failed.

Pass or fail?

This is the heart of your assertion and can be as tricky as you like. Obviously, your matcher could also have multiple exit strategies with specific messages about each possible failure. But the bit that takes a little getting used to is that you're writing a matcher which could be used with .Not in the grammar chain, so you should cater for that eventuality.

Meaningful messages

There's a simple strategy here: get the passed value as if you're doing a positive assertion (ie, as if there is no .Not in the chain) and set your message as follows:

If you've "passed", the message will only be shown if the expectation was negated (ie, there's a .Not in the chain), so you need to negate your message (see the first message above)
If you've "failed", the message will only be show if the message was not negated, so you need to show the relevant message for that scenario.

It turns out that (mostly), we can write messages like so:

internal static class Matchers
{
  internal static void Odd(
    this IBe<int>; be
  )
  {
    be.AddMatcher(actual =>;
    {
      var passed = actual % 2 == 1;
      var message =
        $"Expected {actual} {passed ? "not " : ""}to be odd";
      return new MatcherResult(
        passed,
        message
      );
    });
  }
}

Doing this is tedious enough that NExpect offers a .AsNot() extension for booleans:

internal static class Matchers
{
  internal static void Odd(
    this IBe<int>; be
  )
  {
    be.AddMatcher(actual =>;
    {
      var passed = actual % 2 == 1;
      var message =
        $"Expected {actual} {passed.AsNot()}to be odd";
      return new MatcherResult(
        passed,
        message
      );
    });
  }
}

Also, NExpect surfaces a convenience extension method for printing values: .Stringify() which will:

print strings with quotes
null values as "null"
and objects and collections in a "JSON-like" format.

Use as follows:

internal static class NumberMatchers
{
  internal static void Odd(
    this IBe<int>; be
  )
  {
    be.AddMatcher(actual =>;
    {
      var passed = actual % 2 == 1;
      var message =
        $"Expected {actual.Stringify()} {passed.AsNot()}to be odd";
      return new MatcherResult(
        passed,
        message
      );
    });
  }
}

You'll have to think (a little) about your first matcher, but it starts getting easier the more you write (:

Now you can write more meaningful tests like those in the demo project

The above is fine if, like me, you can see a pattern you'd like to test for really easily (if you have a kind of "matcher-first" mindset), but does provide a minor barrier to entry for those who like to write a few tests and refactor out common assertions.

Not to worry: NExpect has you covered with .Compose():

internal static class PersonMatchers
{
  internal static IMore<Person> Jane(
    this IA<Person>; a
  )
  {
     return a.Compose(actual =>
     {
        Expect(actual.Id).To.Equal(1);
        Expect(actual.Name).To.Equal("Jane");
     });
  }

// ....
  [Test]
  public void TestJane()
  {
    // Arrange
    var person = new Person() { Id = 1, Name = "Jane", Alive = true };

    // Assert
    Expect(person).To.Be.A.Jane();
  }
}

.Compose uses [CallerMemberName] to determine the name of your matcher and attempts to throw a useful UnmetExpectationException when one of your sub-expectations fails. You may also provide a Func to .Compose to generate a more meaningful message.

.Compose also returns an IMore<T> for the type being tested, which allows fluent continuations. If you're not composing, you can always use the .More() extension method to get the same result:

internal static class PersonMatchers
{
  internal static IMore<Person> Jane(
    this IA<Person>; a
  )
  {
     a.AddMatcher(actual =>
     {
       // imagine fancy matcher logic in here!
     });
     return a.More();
  }}

These are some rather simple examples -- I'm sure you can get much more creative! I know I have (:

Some parts of NExpect are simply there to make fluent extension easier, for example:

To.Be.A
To.Be.An
To.Be.For
To.Have

NExpect will be extended with more "grammar parts" as the need arises. If NExpect is missing a "grammar dangler" that you'd like, open an issue on GitHub

NExpect, Level 2: Collections

Davyd McColl — Tue, 03 Dec 2019 17:33:19 +0000

In a prior post, I covered simple value testing with NExpect. In this post, I'd like to delve into collection assertions, since they are fairly common.

First, the simplest: asserting that a collection contains a desired value:

[Test]
public void SimpleContains()
{
    // Arrange
    var collection = new[] { "a", "b", "c" };

    // Assert
    Expect(collection).To.Contain("a");
}

This is what you would expect from any other assertions framework.

Something has always bothered me about this kind of testing though. In particular, the test above passes just as well as this one:

[Test]
public void MultiContains()
{
    // Arrange
    var collection = new[] { "a", "b", "c", "a" };

    // Assert
    Expect(collection).To.Contain("a");
}

And yet they are not functionally equivalent from where I stand.
Which makes the test feel a little flaky to me. This is why NExpect actually didn't even have the
above assertion first. Instead, I was interested in being more specific:

[Test]
public void SpecificContains()
{
    // Arrange
    var collection = new[] { "a", "b", "c", "a" };

    // Assert
    Expect(collection)
        .To.Contain.Exactly(1).Equal.To("b");
    Expect(collection)
        .To.Contain.At.Least(1).Equal.To("c");
    Expect(collection)
        .To.Contain.At.Most(2).Equal.To("a");
}

Now my tests are speaking specifically about what they expect.

Sometimes you just want to test the size of a collection, but you don't really care if it's an IEnumerable<T>, a List<T> or an array. Other testing frameworks may let you down, requiring you to write a test against the Count or Length property, meaning that when your implementation changes from returning, eg, List<T> to array (which may be smart: List<T> is not only a heavier construct but implies that you can add to the collection), your tests will fail for no really good reason -- your implementation still returns 2 FrobNozzles, so who cares if the correct property to check is Length or Count? I know that I don't.

That's Ok, NExpect takes away the care of having to consider that nuance and allows you to spell out what you actually mean:

  [Test]
  public void SizeTest()
  {
    // Arrange
    var collection = new[] { "a", "b", "c" };
    var lonely = new[] { 1 };
    var none = new bool[0];

    // Assert
    Expect(collection).To.Contain.Exactly(3).Items();
    Expect(lonely).To.Contain.Exactly(1).Item();

    Expect(none).To.Contain.No().Items();
    Expect(none).Not.To.Contain.Any().Items();
    Expect(none).To.Be.Empty();
  }

Note that the last three are functionally equivalent. They are just different ways to say the same thing. NExpect is designed to help you express your intent in your tests, and, as such, there may be more than one way to achieve the same goal:

  [Test]
  public void AnyWayYouLikeIt()
  {
    // Assert
    Expect(1).Not.To.Equal(2);
    // ... is exactly equivalent to
    Expect(1).To.Not.Equal(2);

    Expect(3).To.Equal(3);
    // ... is exactly equivalent to
    Expect(3).To.Be.Equal.To(3);
  }

There are bound to be other examples. The point is that NExpect attempts to provide you with the language to write your assertions in a readable manner without enforcing a specific grammar.

Anyway, on with collection testing!

You can test for equality, meaning items match at the same point in the collection (this is not reference equality testing on the collection, but would equate to reference equality testing on items of class type or value equality testing on items of struct type:

  [Test]
  public void CollectionEquality()
  {
    // Assert
    Expect(new[] { 1, 2, 3 })
      .To.Be.Equal.To(new[] { 1, 2, 3 });
  }

You can also test out-of-order:

  [Test]
  public void CollectionEquivalence()
  {
    // Assert
    Expect(new[] { 3, 1, 2 })
      .To.Be.Equivalent.To(new[] { 1, 2, 3 });
  }

Which is all nice and dandy if you're testing value types or can do reference equality testing (or at least testing where each object has a .Equals override which does the comparison for you). It doesn't help when you have more complex objects -- but NExpect hasn't forgotten you there: you can do deep equality testing on collections too:

  [Test]
  public void CollectionDeepEquality()
  {
    var input = new[] {
      new Person() { Id = 1, Name = "Jane", Alive = true },
      new Person() { Id = 2, Name = "Bob", Alive = false }
    };
    // Assert
    Expect(input.AsObjects())
      .To.Be.Deep.Equal.To(new[]
        {
          new { Id = 1, Name = "Jane", Alive = true },
          new { Id = 2, Name = "Bob", Alive = false }
        });
  }

Note that, much like the points on "Who's line is it, anyway?", the types don't matter. This is deep equality testing (: However, we did need to "dumb down" the input collection to a collection of objects with the provided .AsObjects() extension method so that the test would compile, otherwise there's a type mismatch at the other end. Still, this is, imo, more convenient than the alternative: item-for-item testing, property-by-property.

The above is incomplete without equivalence, of course:

  [Test]
  public void CollectionDeepEquivalence()
  {
    var input = new[] {
      new Person() { Id = 1, Name = "Jane", Alive = true },
      new Person() { Id = 2, Name = "Bob", Alive = false }
    };
    // Assert
    Expect(input.AsObjects())
      .To.Be.Deep.Equivalent.To(new[] {
        new { Id = 2, Name = "Bob", Alive = false },
        new { Id = 1, Name = "Jane", Alive = true }
      });
  }

And intersections are thrown in for good measure:

  [Test]
  public void CollectionIntersections()
  {
    var input = new[] {
      new Person() { Id = 1, Name = "Jane", Alive = true },
      new Person() { Id = 2, Name = "Bob", Alive = false }
    };
    // Assert
    Expect(input.AsObjects())
      .To.Be.Intersection.Equivalent.To(new[] {
        new { Id = 2, Name = "Bob" },
        new { Id = 1, Name = "Jane" }
      });
    Expect(input.AsObjects())
      .To.Be.Intersection.Equivalent.To(new[] {
        new { Id = 1, Name = "Jane" },
        new { Id = 2, Name = "Bob" }
      });
  }

You can also test with a custom IEqualityComparer:

  [Test]
  public void CollectionIntersections()
  {
    var input = new[] {
      new Person() { Id = 1, Name = "Jane", Alive = true },
      new Person() { Id = 2, Name = "Bob", Alive = false }
    };
    // Assert
    Expect(input)
      .To.Contain.Exactly(1).Equal.To(
        new Person() { Id = 2, Name = "Bob" },
        new PersonEqualityComparer()
    );
  }

or with a quick-and-dirty Func:

  [Test]
  public void CollectionIntersections()
  {
    var input = new[] {
      new Person() { Id = 1, Name = "Jane", Alive = true },
      new Person() { Id = 2, Name = "Bob", Alive = false }
    };
    // Assert
    Expect(input.AsObjects())
      .To.Contain.Exactly(1).Matched.By(
        p => p.Id == 1 && p.Name == "Jane"
      );
  }

And all of this is really just the start. The real expressive power of NExpect comes in how you extend it.

But more on that in the next episode (:

DEV Community: Davyd McColl

Pair programming doesn't suck

I hate typing on someone else's computer or when someone types on my computer

Constant breaks

Egotistical partners

Passive partners

Micro-managers

Noise

Wrapping up

Asserting sequence order with NExpect

NExpect: not just pretty syntax!

Explain how?

Enter the refactor

So how does NExpect help?

Conclusion

Introducing: NEWTS

What's in the box?

Usage

Notes:

Working with your new project

*Postscript:

Orthogonality

Definition

Seems abstract

Getting practical

Benefits of observing orthogonality

Design

The takeaway

Keeping DRY

DRY Code

When to refactor common code

When code duplication is not knowledge duplication

DRY Documentation

DRY Data

DRY Representation

Sharing is caring

Good inter-team communication

Common methods for sharing that common code or knowledge

Make it easy to use

#TIL how to move uncommitted code from one git repo to another

TL;DR:

The full story:

In the source repo

In the target repo

Wrapping up

JavaScript: what's the point of bind()?

Functions are first-class citizens

Functions are new, every time

JavaScript has a history

What's this anyway?

Coming back to answer the original question

Passing a member as a callback

Frameworks like AngularJS

Binding parameters

Arrow functions

Wrapping up

Bind mounts with an OpenRC service

Duck-Typing with PeanutButter #1

What is Duck-Typing?

Why would you want to duck-type?

Enough jibber-jabber! I want to duck-type now!

1. Reading from unrelated classes

NExpect, Level 3: You're the secret sauce!

.AddMatcher()

Pass or fail?

Meaningful messages

NExpect, Level 2: Collections

What's `this` anyway?