DEV Community: Nic Hartley

Set up a Pi with no router, no cable, and no peripherals

Nic Hartley — Wed, 03 Apr 2019 00:46:21 +0000

If you're at uni and you've tried to set up a Raspberry Pi, you've probably hit an error. Ditto if you don't own your router and your ISP (or landlord) won't give you access to the control page. That issue is that you somehow need to get your RPi's IP address, but you don't have any way to get it!

So instead of using your normal router, well... why not make your own? Sure, you could go out and buy one, but chances are you already have a device capable of generating a hotspot. Your laptop can probably do it, as can your phone. Why not use them?

Note: if you're already experienced with setting up RPis headlessly, you can probably skip the rest of the tutorial. That last paragraph was the big secret. The rest of this is just applying the normal techniques to this specific case.

Requires

An RPi. I'll be using a Raspberry Pi 3 Model B+, but this should work with any Raspbian-capable machine. This should work on any Raspbian machine, though. Also, you will still need the normal mandatory accessories for your RPi -- a power cable, an SD card, etc.
Any device which supports mobile hotspots. I'm using my Android phone for this tutorial, but the instructions will be similar regardless.
An SSH client. I use the CLI packaged with the Windows Subsystem for Linux because it's convenient, but there are dozens, and literally any will work.

Instructions

Get your Pi ready

The first thing you need to do is get your Pi ready. There are a ton of tutorials on flashing Raspbian to your SD card; you can follow literally any of them.

Note: Do not install NOOBS! NOOBS is great if you have a monitor and keyboard to attach to your Pi. If you do, you should use it! This tutorial, however, is built on the premise that you don't, so make sure that you install Raspbian, not NOOBS.

Once you have Raspbian installed on the SD card, you'll need to add two files, both in the root directory of the SD card:

An empty file called ssh
wpa_supplicant.conf (see below)

Open up wpa_supplicant.conf in your favorite editor, and

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
     ssid="TODO"
     psk="TODO"
     key_mgmt=WPA-PSK
}

Keep that text editor open. We'll be setting the values of ssid and psk by replacing the TODOs on those lines.

Note: If you're not in the US, you should change the country= line to match your country's ISO 3155-1 alpha-2 code. I have yet to see things break when the wrong country is supplied, but that doesn't mean they can't.

Setting up your router

The exact steps for this vary by the product you're using as your router. I'll describe the process for a couple of common systems, but there are definitely tutorials online for what you're using, even if it's not here.

In general, though:

Create a hotspot.
Set ssid to the SSID of the network.
Set psk to the network's password.

Windows

A Windows 10 machine will require an internet connection or some fiddling to create a hotspot, but it gives you the same benefits: Open your WiFi menu and look in the bottom-right or bottom-middle for a button labeled "Mobile Hotspot". Click it. You now have a hotspot starting.

Once that turns blue, right-click it, click "Go to Settings"¹, and find the section showing the network name and password. Back in wpa_supplicant.conf, set ssid to the value next to "Network name", and psk to the value next to "Network password". Make sure you get all of the characters exactly right, including case.

Android

Note: Most phones allow this; however, yours might not, or might have slightly different names for things. Use your best judgement.

Open Settings. Find the category labeled "Connections" or "Network & internet" and tap it. Tap the option labeled "Mobile Hotspot and Tethering", or something similar. Tap the switch next to the option labeled "Mobile Hotspot" or "Wi-Fi Hotspot". Before you connect to it, go into the settings and try to find something labeled "WiFi sharing" -- this will keep you from accidentally using mobile data while you have your RPi connected. With my phone, once I turn WiFi sharing on, I can actually turn WiFi entirely off (or at least disconnect from my local WiFi) and still use it, but this may not work with yours.

As before, you'll nede to set ssid and psk to the network name and password, respectively. Both should be visible on the main screen, but if you're having trouble finding them, try tapping the three-dot menu icon in the top corner, then "Configure Mobile Hotspot". Each of the fields will be labeled nicely.

You should also look at the Security dropdown. Chances are it'll be WPA2-PSK, and if that's the case, you don't need to do anything. If it's something else, you'll need to learn more about wpa_supplicant.conf to correctly configure your RPi.

Putting the two together

Now that you have your 'router' running and your RPi's SD card configured, put the SD card in the RPi and plug in the power cable. Give it some time to start up -- it'll take a little while.

Eventually, you should see the RPi pop up on the list of devices connected to your network. On a Windows 10 hotspot, you'll see the device's name, IP address, and MAC address in a table. On your phone, you might just see a name -- try tapping it or tapping-and-holding to bring up extra information about it.

You need to get your RPi's IP address for the next step. It should be clearly labeled. Be sure to copy it exactly; any typos will be annoying to spot.

Connecting to the Pi

This is actually the easiest step. Using the machine you'll control the RPi with, connect to the same network that the RPi is on. SSH into the IP address you just got, as the user pi with password raspberry. Congratulations! You're now in the RPi, and can do anything with it that you could with a normal terminal setup.

Remember to change the default username and password for your RPi, by the way! Even if you don't now plan on using it for anything that's accessible to others, it's better to get into the habit of changing default passwords than to learn the hard way that you forgot.

One important caveat, by the way: Connecting to a different network with either the RPi or your man machine will break the SSH connection. If you change the network your RPi is on, your connection will break before the other connection is established.

Next steps

From here, you have full control over your RPi. If your router connects to the internet, you can even install things from the internet. If you're brave, you could even set up X11 forwarding so you can graphically control your RPi. You can even walk away and leave the RPi to do its own thing for a while -- when you come back, it'll automatically reconnect to the WiFi in its wpa_supplicant.conf and you can access it like before.

It's trickier if you want it to connect to another network, though. You can, of course, just change wpa_supplicant.conf to point to the other network, reboot, and leave it be -- assuming you got all the details right, it'll connect to that network perfectly well. The trouble is when you want to get control over it.

If you have your RPi phoning home, you can of course write that system such that it can deliver commands like "reconnect to my hotspot" from your server. You could also have a script scanning the locally available WiFi and, if your hotspot is available, reconnecting to it. There are quite a few ways, and none of them are necessarily better than the others. It just depends on what you're trying to do, and what your resources are.

Good luck!

What's a git tree?

Nic Hartley — Wed, 27 Feb 2019 04:21:55 +0000

I made a tool recently called Git Gud, and wrote a blogpost. Y'all seemed to really like that, so hey, why not milk it for a little more?

More seriously, though, how git works internally has fascinated me for a while. It's not actually that complicated, but there are two big chunks. I'll cover the abstraction git operates on first, and next week I'll go over how that's stored on disk. Trust me, it'll be easier to understand how it's stored if you understand what's being stored first.

Note that this is not a git tutorial. I'm assuming you have some familiarity with git -- you don't need to know what commits are, but you do need to know what version control is, and

Note: Pointers make an appearance here, as an analogy. If you don't know what they are, there are plenty of incredible resources online to explain them, but that's far beyond the scope of this article. And probably my abilities, too.

I'm gonna break git down into three pieces:

The repository
Commits
Branches

Repository

The repository, "repo" for short, is the "container" of git. Git doesn't operate on your entire filesystem, as you probably know. It's limited to just one directory, and all the directories that are recursively in that directory. In the root of the repository is the .git folder, which stores all of git's internal files.

You can actually have a repository inside a repository -- if you've ever been told to git clone --recursive something, that's what it relates to. This article is just going over the basic concepts of git, though, so I won't cover them here.

There are some more corner cases, like .gitignore. I highly recommend looking into .gitignores for your git repos if you don't already have them. They might have been autogenerated by your IDE or in place from your template, but you should take a peek, learn the syntax, and see if you can't make them better. There's usually some stuff that can safely be omitted from your build.

Commits

A commit is a snapshot of the state of the repository. It stores the contents of every file as they are at the moment of a commit -- this is why .git folders can sometimes get so big. Each commit is basically a tarball of the entire repository! Git doesn't use the tar format internally, it uses a format that's way more space-efficient and doesn't clone identical data repeatedly, but that's a digression for next week.

If you've used git a lot, you might notice that's not how they're typically displayed, though. They're normally displayed as diffs. And when you do things like merging (which we'll get to in a minute, I promise) you merge sets of differences, not two entire files. So... how does that work?

Don't worry. We'll get to it.

Metadata

The snapshot of your directory is accompanied by some metadata. The most important, in my opinion, are:

Commit message. This tells people about your commit, and is vital to making your code's history easy to understand. Write good commit messages and you'll inevitably thank your past self.
Author: The person who wrote the code. Almost definitely you, though some projects do accept patches and change the author to reflect the actual source of the code.
Parents: The commit (or, occasionally, commit*s*) which this commit follows. This concept will be explored more in the Branches section.

These metadata (along with the rest that git stores) are bundled together with the 'tarball' into a "commit object".

Commit names

Commits don't quite have names. What they have is a hash. Today, that's generated with SHA-1, though it's expected that git will start to migrate to SHA-256... sometime soon. Whatever the algorithm, it's applied to the commit object, and the result is the commit's "name".

The name, with SHA-1, looks something like this: e9f8ebe40fadf3a644f92c4a5e4af70f92d29347. That's usually condensed down to the first 7 or 8 characters, so e9f8ebe instead, though you can use any number of characters, so long as it's more than 7 and enough to uniquely identify the commit's hash.

Stashes

You might or might not know about git stash. It's really helpful, and I love it a lot. It lets you save the current state of your repo without making any changes to history, and easily reapply the changes. A stash is basically a commit object, but not pointed to by a branch (we'll get into that in a second). When you pop what's on your stash, it gets merged in basically like a branch (again, in a second).

Branches

Branches are interesting. In a sense, they don't actually exist. They're just pointers (told you they'd crop up!) to commit objects. When you add a new commit to a branch, the commit's parent is set to what the branch is currently pointing to, and the branch is set to point to the commit you just made.

The "branch", then, is just the parents, grandparents, etc. of the commit that the branch is pointing to. This is, as you may guess, somewhat confusing to define. Where does a branch start? When it 'splits off' from another? How can you tell that the branch you're looking at split off, and not the other?

Good question. A very good question. Such a good one, in fact, that I don't actually know the answer -- it seems to be a mix of convention and just sort of letting things work themselves out. By all means, if you can shed some light on this, please comment.

Tags and `HEAD`

Tags and HEAD are the same thing as branches: Pointers to a commit. The difference is that tags never move, even when you commit -- they're fixed pointers to a single commit object in the tree.

HEAD, on the other hand, moves a lot. When you commit, it moves to point to that new commit object. When you git checkout another branch, it moves to point to the same place that branch is pointing (...mostly). You can even git checkout individual commits or tags, and your HEAD will point to those commits.

As a side note, the commits branches are pointing to are often called the heads (lowercase) of those branches. I personally prefer the term "tips", because it's less likely to get confused with HEAD, but calling them "branch heads" is much more common.

Merges

I did promise I'd get to merges eventually. How do they work, if commits are just tarballs of files?

Well, it has to do with one key invariant of a git repo that I've kinda glossed over up until this point: The root commit.

In a repo, every commit, if you follow the chain of parents back far enough, points to the same, original commit. Because of that, if you start at two disparate commits in the repo and follow their parents back far enough, you will eventually find a common ancestor. It might well be the root commit itself, but there'll be a commit that both commits came from.

Once you have that commit, you look at the state of the filesystem in it, compare it to the filesystem in the two child commits, and get the differences. If only one commit touched a given area, then you can merge those changes in 'safely'. If both commits touched an area, but made the same changes -- say, a commit was cherry-picked between them to apply a security fix -- then you just apply those changes. If they made different changes to the same bit, then you flag it as a merge conflict and ask a human to handle it.

That's obviously just an overview, and there are multiple merge algorithms with different strengths and weaknesses. They all operate fundamentally the same, but the actual algorithms used to find the diff, decide what counts as a merge conflict, etc. are different.

Once all that is done, a new commit is made, with the changes from both branches integrated into the new snapshot. Generally, you're merging from one branch onto another, and the branch you're merging onto is the one whose tip advances. The new commit has two parents: The two commits that the branches pointed to when you started the merge.

Squashed merge

There's actually a different type of merge, which you may have heard of, called a squashed merge. It's just like a normal merge, but rather than retaining the "from" branch as a parent, it only has the changes, all "squashed together" into a single commit. This is generally used when a very compact, very clean commit history is desired, but it loses the history which can be so useful in tracking down when a regression was introduced.

Rebase

So what's a rebase then?

It's actually pretty dissimilar to a merge, even though they have the same end result of combining two sets of changes. While a merge leaves the branches as they are and adds a new commit with the new files, a rebase keeps the same number of commits, and moves them around.

When you rebase, you again need to pick a branch to rebase from and a branch to rebase onto. Again, their common base is found, and again, diffs are computed.

This time, though, the diffs are computed for every commit starting at the "from" branch tip and ending at the commit just ahead of the common base. Each of those diffs is then applied to the tip of the "onto" branch, each on its own commit. When the rebase is done, all of the old commits of the "from" branch (and the "from" branch itself) are deleted, leaving only the new commits on the "onto" branch.

All in all, not very complex, and nowhere near as scary as it might seem.

Deleting a branch

You may wonder -- if there's no marker saying when a branch ends, how does deleting a branch work?

I refer you back to the beginning of this section on branches, where I talk about how to determine what the root of a branch is.

Conclusion

So, in short:

Repos are folders with some git metadata in them.
Commits are basically tarballs of the whole repo, plus some extra metadata.
Branches are really just pointers and you shouldn't think about that too much.

Hope you enjoyed! If you have questions, feel free to ask. This is a generic overview and probably didn't hit everything you might be curious about.

Git Gud at git

Nic Hartley — Thu, 21 Feb 2019 03:18:12 +0000

Show of hands, everyone, who knows git?

Not just the standard git pull / git commit / git push arcanery that you go through to magically make your changes public, who actually understands git? Who here understands its internal tree model, the thing that makes it work so well?

If your hand is still up, you can feel free to skip this post, or pop over to the source and help implement more features. You may want to hold off for a little while before you contribute, though; I'm porting it from WASM to JavaScript.

If you don't know how it works, though, can I recommend something I made? It's called Git Gud.

What is it?

Git Gud is a web-based Git simulator. It shows you the git tree visually, and you can run commands to show you what they do to the tree. You start out with an initial commit:

You'll notice it's labeled "c0". That's the commit ID. Because we don't have any actual files to track -- that's for a much later version -- we don't have anything to hash, and on our initial build, we just ordered commits sequentially. The first, automatically generated commit is "c0", the second is "c1", and so on. Speaking of the second commit, click in the bottom area and try typing:

commit

You'll see another commit get added:

Just like in Git, you can checkout individual commits:

checkout c0

You can also make a new branch with branch, check it out with checkout b1, commit on it, merge it back in, etc. For example, enter this sequence of commands:

commit
checkout c0
branch
checkout b1
commit
checkout b0
merge

and you'll get this:

If you want to reset, well, there's no git command for that, but we've repurposed init:

Why?

If you look at the commit history for Git Gud, you'll notice a massive spike in development over the course of a weekend. That weekend was BrickHack, RIT's annual hackathon. It was an interesting experience, and a great way to get a prototype up and running.

It did introduce some issues, though. The code isn't too great, since we didn't have a chance to really think through issues in just 24 hours. We wrote it in WebAssembly rather than the pure JavaScript that would have been less effort to develop and debug, because one of the team members only knew C++ and wasn't sure he could learn JavaScript in the few days well enough in the few days before the hackathon¹.

1: As it turns out, he was able to learn it in an hour or so during the hackathon, at least well enough to edit some drawing code. Oops. Probably could have done that better, then.

Next steps

Right now, Git Gud pretty barebones, as you'll definitely notice if you try it. There are quite a few features we want to implement, most of which boil down to working more like the real git. For example:

If you type git at the beginning of the line (say, out of habit from using real git), delete it from the input rather than breaking
Informative (aka any, in some cases) error messages when you do something wrong
Rebasing
Commit messages
Branches with names
Parsing flags like -b on checkout
File changes, rather than just abstract 'commits'
More themes. Amber on black is pretty, but it'd be nice (and not too hard, really) to offer multiple colors.

Got any other ideas? Anything you want me to know as I develop it more? Either raise an issue, or comment on this post.

The Best Thing about C++

Nic Hartley — Tue, 12 Feb 2019 22:48:18 +0000

Note: For this post, you'll need a pretty decent understanding of programming. I'll explain most of the words I use in the article, but I still expect you to know what an "object" is, and not just in the OOP sense.

Destructors are great. When I first learned C++ they seemed like magic, and now I'm mildly annoyed by languages that don't have them. The thing is, most languages don't have them. If you've only ever coded in Java or C#, you're probably wondering why I like such terrible, useless things, because you've never actually experienced destructors. Java has the finalize overrideable method, and C# has something that it calls destructors (which even apes the C++ syntax), but neither one is a real destructor.

Object lifetimes

Before we can talk about what a destructor is and why it's great, we need to talk about something related: Object lifetimes. An object's lifetime is just how long it sticks around as usable, allocated memory. If you have some handle to that object, be it a pointer, a reference, a variable, whatever, then until the object's lifetime is over, you can continue using it.

In most languages, it's outright impossible to guarantee exactly when every object's lifetime ends. In some, though, they get closer than others. For example, in Java, the object lasts at least until it's no longer referenced, and then until the garbage collector gets around to collecting the garbage. You have no guarantees when, or even if, that happens.

On the other hand, languages like C++, Rust, and Swift have much more strictly defined object lifetimes. I won't go into the exact rules, but the rule of thumb is that once every variable referring to the object is out of scope, that object's lifetime ends immediately, rather than ending at some indeterminate point afterwards. I'll call these "strict" lifetimes, since they have a precise end time.

There is, of course, an exception with pointers in C++; in that case, an object's lifetime ends when it's deleted.

One important corollary to note is that when an object's lifetime ends, so do the lifetimes of its fields.

Destructors

A destructor is a function that runs at the end of a strict lifetime. It's basically the inverse of a constructor, hence the name. You can absolutely guarantee that:

A destructor will run, barring something very strange happening.
It will run only after the object is no longer being used¹.
It will run soon after the object is no longer being used (mostly)

Number 3 is somewhat fuzzy, but if your language has strict lifetimes and you restrict things to the smallest scope you reasonably can, then the destructor will run quickly after the object's last usage.

Because a field's lifetime ends with its containing object, you don't need to explicitly call the destructors for your fields. They're called after the destructor for the containing object.

Why are they good?

There are two related things that destructors allow you to do: Simpler cleanup, and RAII.

Simpler cleanup

Have you ever coded anything complicated in C? You've probably got more than a few blocks of code like this:

struct foo *my_foo = construct_foo();
use_a_foo(my_foo);
use_it_again(my_foo);
destruct_foo(my_foo);

That's all well and good, until you remember that use_a_foo might fail, and if it does, we shouldn't run use_it_again. If use_a_foo does fail, it'll return false, so let's check that:

struct foo *my_foo = make_a_foo();
if (!use_a_foo(my_foo)) return false;
use_it_again(my_foo);
destruct_foo(my_foo);

The issue here is that now, sometimes, you're not properly destructing my_foo. Sure, in this example it's trivial to fix, but it quickly gets out of hand, trying to keep the code legible while also correctly destructing every object.

In contrast, this is the equivalent C++:

foo my_foo;
if (!use_a_foo(my_foo)) return false;
use_it_again(my_foo);

The foo destructor is called implicitly as soon as my_foo goes out of scope, so you don't need to manage it. That means that whatever cleanup needs to be done -- closing file handles, deallocating memory, whatever. In C++ you also have exceptions, and if you throw an exception, the destructors will still be called when you get to a scope above the one the object is in.

RAII

RAII, short for "resource acquisition is initialization" is a fairly small leap, once you've realized that "cleanup" can be generalized a little. The name means that anything which takes control a resource -- be it a thread handle, a file handle, whatever -- does it when it's constructed, and then makes sure that it's cleaned up when it's destructed.

For example, this is a fairly common pattern for acquiring mutexes in C++:

{
  std::lock_guard _l(the_mutex);
  // ... do your processing ...
}

When it's constructed, a std::lock_guard takes control of, by locking, a mutex. That way, no matter what happens in // ... do your processing ..., unless you forcibly exit the entire thread somehow, you still unlock the mutex once that block is done, and it happens automatically.

But the concept has been expanded somewhat. Some types do error-checking on destruction, like std::thread, which makes sure that the thread is either done executing and joined back to the parent thread, or detached so it can keep executing on its own.

So what's a finalizer?

A finalizer is like a destructor in that both run at the end of a lifetime, but the word "finalizer" is used when the lifetime isn't strict. Because the lifetime isn't strict, and because the lifetime might not even end until the program stops, you have no guarantee that the finalizer will run, or that it'll run "soon" after the object stops being used to any useful degree.

Now, to be clear, there's nothing inherently wrong with a language not having destructors. Most language provide some way around the lack. In C#, you can do this:

lock (object) {
  // ... do your processing on object ...
}

That's arguably even better design than C++'s lock guards, since it makes it explicitly clear what is having its access controlled, rather than just that something is controlled. The lock statement will also release in a timely manner no matter what.

More generally, anything that implements IDisposable can be basically given a destructor:

using (Foo f = new Foo()) {
  // use f
}

There are only two minor issues with that:

It's yet another piece of syntax to learn and remember when coding.
You need to actually implement IDisposable, which might not be done in bad code².

Both of those can be worked around if necessary, but compared to the inherent simplicity and elegance of RAII, it's frustrating. Again, it's not necessarily a bad design, just an uncomfortable one.

Why finalizers?

To put it simply, they're easier on both language designers and users. Just sort of handwaving away object destruction and saying "it'll go away eventually once you're done with it" is much easier than writing or learning, say, Rust's complex object lifetime semantics. Personally, I prefer Rust, because it does give me that information and avoids the overhead of garbage collection in most cases, but when you're just getting into coding, it's just another thing on the already large pile of things to learn.

Plus, destructors really aren't necessary for most languages. Java and C#, for example, already introduce the overhead of a virtualization layer; tossing a garbage collector into the mix isn't that much more. Add something like using or try-with-resources and you have a workable alternative, albeit with a little more mental overhead.

Questions?

If you're still confused about this, feel free to leave comments! This can be a tough concept to wrap your head around, especially if you've never had any exposure to destructors before. If you're reading this with only a background in JavaScript... well, you have my condolences. It was probably tough. Thanks for sticking it out!

Footnotes

C++ does allow you to call destructors manually (the syntax is foo->~type_of_foo()) but this is very much not recommended. It causes all sorts of issues because destructors typically depend on all three assumptions holding, and even if you do everything right you can still break things.
Interestingly, Java seems to have an epidemic of not using AutoCloseable. For a while I wondered why, but then I realized that AutoCloseable was only added in Java 7! Certainly frustrating if you're dealing with code so old it predates generics. Thankfully, it can be worked around fairly simply in most cases.

% Is Not Modulo

Nic Hartley — Wed, 06 Feb 2019 03:19:37 +0000

Note: This post doesn't actually apply to all languages. Only many of them. To see if it applies to your chosen language, check if -4 % 3 equals -1. If it's 2, your % is actually modulo. If you get something else, let me know, because I'm curious!

You may have seen % used in a few places. Maybe someone was generating a random number in a range:

rand() % max

or cycling through an array:

index = (index + 1) % array.length;

You've probably heard this referred to as "modulo", too. If you know anything about modular arithmetic, at first glance it seems to be accurate, too. But it's... not quite. The difference might seem insignificant, but if you find yourself implementing any math that uses real modular arithmetic, it's important.

Vocab

First, quick vocab lesson:

A / B = C means "A divided by B is equal to C". A is the divisor, B is the dividend, and C is the quotient. If I refer to "division" without specifying, in this article I mean integer or floored division. That's when you do a division without keeping track of the decimal component (so, for example, 14 / 5 is 2, not 2.8).

Right, with that out of the way...

What's `%`?

% gets the remainder of an integer division. If you think of integer division as splitting a lot of objects evenly into a number of groups, the remainder is how many objects are left over. For example, 14 / 5 is 2, because each of the 5 groups can have 2 objects in it, and there are 4 objects left over which can't be evenly split into the groups.

Or, more mathematically, the remainder is the difference of the divisor and the product of the dividend and quotient. For example, 14 / 5 is 2, so the remainder is 14 - (2 * 5) = 4.

For the sake of clarity, I'll be using "rem" as an operator to specify that I want to get the remainder of a division. So, for example, 14 rem 5 is 4.

Note: Getting the remainder is rarely implemented like that on actual hardware. The effect is the same, though, so I'll leave that for another day.

What's modulo?

Modulo, or modular arithmetic, is a little different. First of all, it's not an operation. It's more of a system of doing math. It's just like normal arithmetic, but whenever you perform an operation, it wraps in a. That range is from zero to what's called the "modulus".

That might be a little technical and abstract, so think about telling time. Whether you use a 12-hour or ~~correct~~ 24-hour clock, think about 1:00, just after midnight. Now think about what time is two hours before that. It's not -1:00, it's either 11:00 or 23:00. Or, going the other way, you don't go from 11:00 to 13:00 in 12-hour time or 23:00 to 25:00 in 24-hour time. Instead, you wrap around, going back to the start of the range -- from 0 to 12 or 24 -- when you pass the end, or ahead to the end when you go back behind the start.

In math, because it's an arithmetic system, modulo is usually used as a sort of modifier for the entire equation. In programming, though, it's not exactly easy to redefine how arithmetic works for a single expression (at least, not in most programming languages), so it's used as an operator. To use the time example from before with a 24-hour clock, 25 mod 24 = 1.

You might be wondering what happens if you're still outside the range when you wrap around. For example, what's 14 mod 5? If you just wrap once, then you get 9, which is still outside of the range. You just keep wrapping in that case, down to 4, which is in the range.

So... what's the difference?

Up until now, I've only used positive integers for both divisors and dividends. Under those conditions, remainder and modulo perform the same. I won't be getting into all reals in this post, if ever, because remainder and modulo are almost always used with integer arithmetic in programming.

But there's still a massive area that I just... haven't covered yet: Negative numbers. So how do things differ there?

Well, let's start with the simplest case. To go back to the clock example, what's -1 rem 24 and -1 mod 24?

The remainder is pretty easy to calculate. -1 / 24 is 0, so the difference is -1.

The modulo is also simple. -1 is under 0, so it wraps back around to 23.

The same problem happens, but backwards, if we use a negative modulo. 12 / -5 is -2, so 12 rem -5 is the difference between 12 and 10, or 2. Wrapping 12 around to fit in the range from 0 to -5 can't give us a positive number, though, and in fact it gives us -3.

With two negative numbers, things go right back to working normally. -12 rem -5 and -12 mod -5 are both -2.

How do I fix it?

You may have already noticed a pattern about the difference between remainder and modulo. Specifically, the difference, when there is one, is always exactly the divisor. Also, as mentioned before, the divisor and dividend are different signs. Both of those are provably true, but I'm not going to get into the actual math here -- just take my word for it.

That makes the fix pretty easy. First, check whether % means remainder or modulo in your language. It's very likely to be remainder, but there are some large ones, like Python, where it's modulo. You can do that pretty easily by using any of the examples I've used in the previous section and seeing which answer you get.

If your language's % is a remainder, then chances are there's a standard library function to do modulo. If not, though, here's a C function to do "real" modulo based on the remainder:

int mod(int dividend, int divisor) {
  if (dividend == 0) return 0;
  if ((dividend > 0) == (divisor > 0)) // if they're the same sign
    // then remainder is the same as modulo
    return dividend % divisor;
  else // otherwise, if they're different signs
    // account for the difference
    return (dividend % divisor) + divisor;
}

Note: Zero has to be special-cased because whichever way you check the sign (both positive or both negative) it always ends up with zero being wrong on one of the branches. If you have any ideas for how to make the code cleaner, let me know!

That should be fairly simple to port to just about any language, though the check to see if they're the same sign may need to be written differently if binary XOR isn't available in yours.

Why did things work?

At this point, you might be wondering about how things have worked, given this discrepancy. In most cases, it boils down to things always being positive. For example, the rand() example I gave at the beginning:

rand() % max

In C, and therefore most C-derived languages, the builtin rand-like function returns numbers from 0 to some maximum value, and the max value is always positive. Of course, more modern languages typically offer another, more clear way to get random numbers anyway, and you should use those instead.

The array-index example is similar:

index = (index + 1) % array.length;

This gets the next index in the array, wrapping back around to the beginning once the end is reached. Because the index starts out positive and, aside from when it wraps to zero, only increases, the negatives are never reached. Though if you were trying to do it backwards, it'd break:

index = (index - 1) % array.length;

In this case, when index is 0, (0 - 1) % array.length will give you -1, which is an out of bounds access. You'd have to do a proper modulo add to account for this.

So, have you ever encountered any issues with the difference between modulo and remainder? I have; fixing one such bug is what inspired this post, actually.

How do you use IRC?

Nic Hartley — Wed, 30 Jan 2019 00:42:47 +0000

IRC is pretty neat. It's from the late 1980s, but it's still around, and still fairly widely used. As of this writing, the IRC network I'm on the most has 86,546 users, and according to netsplit.de, the top 100 most popular IRC networks have 234,581 users combined. It's also pretty common in open-source projects, as a way to get support.

But... how do you use it? You've been told that your favorite project is on #aproject on Freenode, but how do you get on that channel, too? Well, in big, abstract steps:

Download an IRC client
Pick a nick
Find the server you want
Connect to it
Connect to your channels
Register your nick
Additional info

1. Download an IRC client

This step, as you might guess, depends on your operating system. There are a wide variety of IRC clients, from command-line software like irssi to the GUI-oriented generic chat software Pidgin. Because I personally use it and it's cross-platform, this tutorial uses HexChat, but all of them work similarly.

2. Pick a nick

This is a more important step than you might think. A "nick", or nickname, is how you're identified in IRC. It's your name on IRC.

It can be at most nine-characters long¹, and can contain letters (uppercase or lowercase), numbers, hyphens (-), underscores (_), square brackets ([]), curly braces ({}), backslash (\), backticks (`), or pipes (|). If you have a consistent handle across the internet, I highly recommend using that, or some minor variation on it, so people recognize you elsewhere, too.

Fill your nick in in the topmost box, and add a username. The username doesn't have to be anything specific, but it's recommended that you make it close to the username of your local user. If you don't know that, just put in unknown.

1: Some servers -- e.g. Freenode -- allow longer nicks, but the IRC protocol specifies a maximum of 9. Therefore, it's generally a good idea to use a 9-character nick, so you can take it with you to different servers.

3. Find the server you want

You need to find two things to connect to an IRC server network: The domain or IP address, and the port. In HexChat, quite a lot of servers are presupplied. Fill in your nick at the top, find the server's name on the list and click Connect, and it'll all happen automatically.

If you've been given a name but no more information and can't find it on the list, try Googling it. Many IRC servers have an associated website which will give you all the details you need. That is, the domain name or IP address, and port.

If you're given a domain or IP and port and want to connect directly, you can add your own server to the list. Click Add -- it's the topmost of the five buttons -- give it a name you'll remember, click Edit, and add the domain name and port to the list at the top, separating them with a slash. For example, if the domain is irc.server and the port is 1234, you'd put irc.server/1234.

If you're not given a port, try 6667. It's the de facto default for IRC.

4. Connect to it

In HexChat, this is as simple as clicking the server in the list, then clicking "Connect" in the bottom right.

You may see a message about your nick -- something like this:

your_nick :Nickname is already in use

This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify .

You have 30 seconds to identify to your nickname before it is changed.

Try connecting again with another nickname. The former means someone is currently logged in with that nickname, and the latter means someone else has staked a claim on that nick. I'll walk you through doing it for yourself in step 6.

5. Connect to your channels

Once you connect to the server, wait for a moment. It takes some time to establish an IRC connection. Once you see the text stop scrolling, you can join a channel with /join #channelname. You must include the first #; it's part of the channel name. Some channels start with & instead -- rather than being global across the entire network, these are exclusive to the server you're currently on.

6. Register your nick

While trying to connect to your desire channel, you might have seen a message like "Please register and identify to speak". There are several ways to do that, depending on the server, but most of them involve NickServ.

NickServ is a special bot available on most servers. You message it to register your nickname, and it ensures that no one else takes your nickname, as well as tying nicks to emails so troublemakers can be effectively moderated. To register your nick with NickServ, send it a private message:

/msg NickServ REGISTER [your-password-here] your@email.here

Of course, replace [your-password-here] with your actual, unique password, and your@email.here with your actual email. You'll get an email sent to that address with a special code, which just confirms that you actually have that email. Confirm that's really your email with /msg NickServ CONFIRM [code], and the nick is yours!

Now whenever you join, you'll see this message:

This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify .

You have 30 seconds to identify to your nickname before it is changed.

You now have the password -- you just created it -- so just type:

/msg NickServ IDENTIFY [your-password-here]

And just like that, NickServ knows you're who you say you are. You can also do some more configuration, which is largely out of the scope of this tutorial. If you have any other questions, /msg NickServ HELP. (The all caps isn't actually required, but I find it amusing to shout 'help' at a robot)

7. Additional info

Multiple nicks?

If you have multiple nicks, you need to group them. Change your nick to the other nick you want to use, then:

/msg NickServ IDENTIFY old-nick [your-password-here]
/msg NickServ GROUP

Now your two nicks are grouped together, and any NickServ management you do to one applies to the other.

AFK?

/away you go! Use that command to tell the server, and other people, that you're away. You can also add a message, like /away to get food, if you want to be a little more specific.

Curious how IRC works?

I'm going to be writing up more articles on how IRC works internally later, but those are by no means the only resources. The RFC is surprisingly easy to follow if you get some experience using IRC before reading it, and, given that it's the standard every IRC server meets or exceeds, it gives most of the necessary information. Extra features like SASL aren't in the original RFC, but they're also standardized and open.

Want to say you're doing something?

Use /me. It's not a standard IRC command, but it's supported by basically every server I've been a regular on. This command:

/me does a thing

produces this message:

* nic-hartley does a thing

in contrast to the normal IRC message format, which might be

nic-hartley: does a thing

Got more questions?

Ask in the comments! I'm happy to answer more questions, if I know the answer.

Why I'll Love Flutter Next Year

Nic Hartley — Thu, 17 Jan 2019 16:48:11 +0000

If you've used Flutter a little, you're probably overjoyed with it. A cross-platform mobile development suite? Which actually works cross-platform, with no platform-specific configuration? Hot restart and stateful hot reload, so you can test changes in seconds? No need to mess with platform-specific configuration files? All of your layout is done in the language itself?!

All in all, it seems like a perfect thing. The hot-reload and hot-restart especially make Flutter hard not to love. I really can't put in words how useful it is to wait seconds, not minutes, to see your changes on your device.

The more you use Flutter, though, the more that initial warmth seeps away, replaced by the cold realization that it has its limitations, like anything else.

Among those is sending notifications. If you're building an entirely offline app -- in my case, a mobile game -- then it's not easy to get notifications working. Sure, you could go through FCM (since GCM is phasing out in April this year in favor of it), but that would require me to do a round-trip between a server just to send a notification from an app on the device to the device, or at least bundle that capability in when I don't need or want it.

So how do you do offline notifications in Flutter?

The short answer is that you can't. You can, of course, call out to native code, but the point of Flutter is to avoid writing native code yourself, and let Flutter handle it automagically. Instead, you have to look for third-party libraries which sort of work, except that you can't schedule or group notifications. (Maybe you can, but I couldn't get it to work.)

That kind of little thing is all over Flutter. For example, when it comes time to make a release for your app -- or even give it a pretty icon -- you need to do platform specific things (which, let's be fair, can be automated) to get that done. It'd be easy to make a lot of that platform-independent -- static icons could be generated from a single high-res file, like what flutter_launcher_icons does; permissions could come from a list in pubspec.yaml or even code analysis.

None of this is to say Flutter is bad. It's new. It's barely two years old, and when you're building something as complex as an entirely new way to develop cross-platform mobile apps, some early stumbling is to be expected. It has a ton of promise, and I think they're quickly getting to where they should be, but they're not there yet.

In short, I'll love Flutter a lot more next year.

DEV Community: Nic Hartley

Set up a Pi with no router, no cable, and no peripherals

Requires

Instructions

Get your Pi ready

Setting up your router

Windows

Android

Putting the two together

Connecting to the Pi

Next steps

What's a git tree?

Repository

Commits

Metadata

Commit names

Stashes

Branches

Tags and HEAD

Merges

Squashed merge

Rebase

Deleting a branch

Conclusion

Git Gud at git

What is it?

Why?

Next steps

The Best Thing about C++

Object lifetimes

Destructors

Why are they good?

Simpler cleanup

RAII

So what's a finalizer?

Why finalizers?

Questions?

% Is Not Modulo

Vocab

What's %?

What's modulo?

So... what's the difference?

How do I fix it?

Why did things work?

How do you use IRC?

1. Download an IRC client

2. Pick a nick

3. Find the server you want

4. Connect to it

5. Connect to your channels

6. Register your nick

7. Additional info

Multiple nicks?

AFK?

Curious how IRC works?

Want to say you're doing something?

Got more questions?

Why I'll Love Flutter Next Year

Tags and `HEAD`

What's `%`?