Using CS figures names for test data

Here’s something that falls more along the lines of an interesting thing to do rather than a good practice.

When writing unit tests we often need to create test data to populate our test objects. Our Person or Client objects needs to have a name, a birth date and so on.

I’ve stumbled on many practices for doing this: writing meaningless data, the developer’s own name, names from a popular fiction series, etc.

One thing I’ve taken a fancy to is using the names of historical computer science figures. I find that a lot of developers tend not to know the great pioneers in our field and this can be a fun way to introduce some of these people. While this knowledge isn’t necessary, I think we should still have a basic grasp of the history of our field.

This is pretty common in other fields. You would be hard pressed to find a physicist who doesn’t know who Niels Bohr or Isaac Newton are.

Here are some of the names I have been using:

Ada Lovelace, she wrote the very first algorithm intended to be carried out by a machine!

Alan Turing, known for the Turing machine and the Turing test. During the second World War his work was instrumental in breaking German ciphers.

Dennis Ritchie, author of the C programming language and co-author of the Unix operating system.

Edsger Dijkstra, known for his classic graph traversal algorithm, the dining philosophers problem and his article against the GOTO statement.

Grace Hopper, while many know her as the first person to come up with the word “bug”, much more importantly she wrote the first compiler.

John von Neumann, an early pioneer who was involved with some of the first computers. He is know for the Von Neumann computer architecture.

Tony Hoare, amongst other thing, he came up with the Quicksort algorithm.


Using a local crate with Cargo

The Cargo web site provides a good explanation of how to use Cargo with external libraries found on GitHub but it does not give any examples of how to use libraries or crates which are local projects.

Today I came upon a question on StackOverflow asking how to do this. I had also created an issue on GitHub relating to this, so I decided to write this post.

Basic project structure

These instructions assume that you are using the default Cargo project structure which is initialized when you call cargo new project-name.

If you added your Cargo.toml file after creating your project you can conform to the Cargo structure by moving your sources in a src/ folder, creating a in project-name/src/ and putting your Cargo.toml file under project-name/.

For the project’s structure here’s what you’ll end up with where project is the name of your project and local_dependency the name of your component/sub-project.

├── Cargo.toml
├── src
│   ├── local_dependency
│   │   ├── Cargo.toml
│   │   ├──
│   │   └──
│   ├──
│   └──

Your Cargo.toml in your main project’s root should look like this:

name = "project"
version = "0.0.1"
authors = ["That guy over there!"]

path = "src/local_dependency"

Since your local dependency is a separate project it will need it’s own Cargo.toml file which will should like this:

name = "local_dependency"
version = "0.0.1"
authors = ["Somebody else"]

name = "local_dependency"
path = ""

The in src/local_dependency/ will contain the public declarations of your modules.

pub use source_file::SomethingUseful;

pub mod source_file;

For reference here is

pub enum SomethingUseful {

The file in src/ is the library file for your main program which you leave empty until you need it.

Finally, in your main source file (src/ you can reference parts of your local dependency likewise:

extern crate local_dependency;

use local_dependency::SomethingUseful;

fn main() {
    println!("Hello world!")

Here you go.

Good enough!

In the last few weeks I have started contributing to Servo, a Mozilla Research project. The project is hosted on GitHub but instead of doing code reviews using the GitHub interface it uses a third party website called OperaCritic.

When my pull requests are accepted it displays the following (click for a bigger version):


The first time I read it quickly and I had to re read it again to make sure if it was a good message or not. Found it pretty funny :)

I like it when people (or the things they create) don’t take always take themselves too seriously.

Updating pull request branch with changes from upstream in GitHub

I don’t know if it’s the most efficient way but here’s one way of dealing with updating a pull request from a personal branch after upstream/master has been updated.

I update my origin/master:

git checkout master

git fetch upstream

git merge upstream/master

I switch to my local branch:

git checkout local-branch-name

“Pop” the PR commit back into unstaged:

git reset HEAD^

This will remove the last commit (I usually rebase all my PR commits into one before submitting a PR but you can also specify HEAD~x where x is the number of commits you want to pop back out) and put it back into unstaged.

And then try to merge master into the branch:

git merge master local-branch-name

If it merges cleanly I can proceed with a commit. If it can’t merge cleanly, I stash the unstaged changes, I merge and then pop the stash likewise:

git stash

git merge master local-branch-name

git stash pop

And then take care of the merge conflicts manually. You will get info on which files are in conflict by doing:

git status

After all of this I can commit and push the branch to GitHub which will update the pull request.