The Hiltmon

On walkabout in life and technology

CodeRunner 2

Nikolai Krill released a major update to CodeRunner today, and I highly recommend it to all programmers no matter what languages you use.

In my case I write a lot of code in C++, Objective-C, Ruby, Javascript and HTML as part of large, complex projects. Often I am unsure how best to write a snippet or function. One way would be to create a branch in the project, run and experiment, deal with compiling, branch again to try another solution, compile some more and work it out. But that is a slow process (and quite dangerous if you leave these experimental branches in, or forget to branch at all).

Instead, I jump over to CodeRunner, select my language and attempt several approaches (in tabs) to solving the problem. I use CodeRunner to write, run, test and debug to figure out which solution is best. Once I get the code working, fast and looking good, I copy and paste it back into my project and keep going. No branching, no risk.

CodeRunner 2 is no longer available in the App Store, I’m guessing sandbox restrictions. CodeRunner 2 comes with a bunch of new features including Code Completion, themes, multi-file support and Yosemite support. It’s a paltry $9.99 as of writing (or free for those who purchased CodeRunner on the App Store).

Highly recommended.

Follow the author as @hiltmon on Twitter.

What to Write About Next?

I was asked in a blog comment today how I decide what to write about. And once decided, how do I go about doing it. In this case, the answer was easy, I decided to try to answer the question. And deconstruct the process I go through as it happens.

Instructions: Read this post in black font first, then come back and look at the gray which deconstructs my thinking.

Every story needs a starting point, I added the next paragraph in the second iteration of the post to create some context. And maybe to establish some kind of credentials and an authoritative tone. Why would you, the reader who does not know me, care how I answer this question. My goal was to show you that my answer to this question evolved, that it was not taught. And that I was surprised to find out I have been doing this for 10 years already.

I started writing on the web in November 2004, see my embarrassing On opening a new Account. I had no idea what I would write about when I started, so I wrote about that lack of ideas. How meta. But I started. And I wrote.

And looking back, it evolved into the three kinds of things I do write about:

  • Views or opinions on topics related to my interests or work.
  • Sharing something I have learned or done by write a reference post.
  • Take on fun writing challenges on a topic I am not savvy with.

But all my writing starts with an idea, a thought, an opinion or a challenge. Where do these come from?

The Ideas

I realized after the second iteration of this post - I had focussed on the three kinds of post instead of ideas - that I had failed to answer the primary part of the question: How do I decide what to write about. So I added this section. Knowing the three areas I write about got my mind onto thinking where these magical topics come from. The answer, I jot down ideas. All the time.

Over the years, I have become an inveterate note-taker. Having a blog and wanting to write means I need ideas. And since I have not yet figured out the voodoo behind when ideas strike or what triggers them, I jot them down as and when they do occur.

I have notes with single phrases in them. I have notes with tweets that triggered thoughts. I have notes that look like half-completed treatises of a madman. I have notes that go nowhere. I have notes that contradict other notes. I have notes that repeat or reinforce other notes. I have notes to remind me to write about other notes.

Whenever I come across thoughts, topics or ideas I could want to write about, I stop and take a note. A question, a tweet, another post, a sentence on a podcast, if they generate an idea, I stop and make a note. Then go back to what I was doing. The objective is to build a corpus of ideas irrespective of the quality of those ideas.

Later on, the same day, weeks later, whenever, when I sit down to write, I look through these notes. Most get rejected. For example, there is no point in writing that I agree with someone else’s topic without having anything to add to it, even if it’s the most interesting topic in the world. And there is no point writing about stuff that no longer looks interesting to me sometime later, after the idea has cooled off a bit.

Fortunately, I have enough of these notes that some remain after the great culling to work with. Which means I probably have something I could write about. But what do I want to say on that note’s topic?

That’s where the categorization comes in. Do I want to express a view on it and add to the discussion? Is it something I have learned that I can share? Or is it a just writing exercise, a silly idea to help me become a better writer?

I am sure you have guessed that this piece fits my categorization of a writing exercise. Can I think through and write about this topic, and actually get somewhere with it? We’ll both see.

The Three Kinds

I had never thought through this before today. I try not to write and share my views if they add nothing to the larger conversation. So what does add to this conversation? Time to drill into it and see whether an opinionated idea can pass a sorting.

Writing about my Views or Opinions

If I have an idea to write about, I need to decide whether I can add to the conversation. No point in writing if it adds nothing. Once again, looking back, it seems that the sorting looks at three ways to determine if an opinion piece gets written.

  • Determining my View, Point or Opinion: This seems like a contradiction, but often I am not sure where I stand on a topic. Writing on that topic, creating a story for it, walks me down that path. I feel that stories that help me determine my view are often useful to others to help them determine or understand theirs. And that adds to the conversation. For this to pass, the story must be good. For example: My Mac Indie Writing Workflow or one of the originals, The Markdown Mindset
  • Confirming my View, Point or Opinion: When I am sure of the point I want to make, I write my thinking behind that position. If the resulting piece adds no more to my position, it gets thrown out. But often, working through my thinking brings out stronger and better arguments for that position, and that adds to the discussion. For this to pass, the argument needs to be good. For example: I Choose Not to Be Anonymous or Go Home
  • Challenge or deconstruct my position: The contrarian in me loves to write these. I have a position on a topic, so I challenge it. Either I choose a contrarian position and write that, or I dissect my own thinking on it. I never publish the contrarian writings, how would readers know when I am being arbitrarily contrarian and when I am standing up for a point. But these experiments help me see the position in a different light and result in better deconstructions and analyses. For this to pass, the flow needs to be good. For example: The Markdown Payoff

If I am unable to construct a story, argue a position or build a flow, the opinion piece fails the sorting and never gets done. I feel that it would not be interesting for me to write or you to read, as it adds nothing to the larger conversation.

I noticed at this point that there are a lot of “I”’s in this post. I am standing on a soapbox talking about a self-invented process where I sort out ideas into ones I will argue and ones I will not argue. True. I was going to shorten this section but understood that its just one of three types of sorting I do, and topics rejected here may still have reference or challenge ideas in them.

Reference, what have I learned?

Many of my ideas come from what I do. I design and develop software. I enjoy new and exciting experiences and face new and exciting challenges in my sphere all the time. And when I find ways to do what I do better, I care to share. These are my reference topic ideas and they happen all the time as I solve new-to-me problems, try out new tools, or dive in where I have much to learn.

Reference topics include how I go about common processes, or how I use software tools or how I think about business, software and design. They can be dry and factual. They can have screenshots and code and downloads to make them more visual and helpful.

Reference topics cover the tools I use, the architectures I develop, the business topics I want to discuss. They also include product reviews, surprises I found, and new-to-me ways to do things.

The best part is there are so many ideas here that I have trouble sorting which to cover. Deconstructing my thinking leads me to filter them out unless I can answer the following:

  • Why. Why do something that way? Why use that tool instead of another? Why think about a topic in this way?
  • When. When should you apply this knowledge? When does it not work?
  • How. How is this way or tool better? How does this process do better than others?

I try to be clear in my reference topics. For example, I intensely dislike product reviews where the reviewer leaves the decision as to whether something is good or bad up to the reader. If a review talks about a product but does not have a why, when and how, then what’s the point of the review? Another example, a post on a data structure in computer science needs to explain why that data structure is good, when to use it and how is it better in that situation, else it too is useless. It’s a tough standard, but interesting is tough.

Reference topic writing also helps me in other areas. Explaining complex software constructs or convoluted business processes is hard. Writing about them helps me find the words to express them simply and clearly.

A reference topic, therefore needs to have one addition to the factual details, the why, when and how to apply the knowledge gained. For example: Xcode and the Simple C++ Project Structure or Letterhead - Markdown Style

Reference posts to me are the easiest to write though. I know something I did not before, and I am sharing that knowledge or experience. The story is easy as it’s the journey I took to learn or experience that thing. And my opinions do not matter unless they add to the story. Facts do. The hard part is clarity, making complex topics readable, understandable and reproducible.

Experiments, Writing Challenges, Fun

Its all good to focus on the few skills that you are great at and let everything else slide. But writing about a few limited topics limits my scope and abilities. If I only wrote about tech, I’d get quite boring quickly.

Thats where the fun ideas and challenges come in. In whatever you do, you should be stretching yourself. Whether that’s taking on bigger and more complex projects, changing industries, or building up new skills. If you are not learning or being challenged, you are stagnating. In writing, for me, that’s where I look for the challenges.

I want to be a better writer. I have a long way to go, and many mentors high standards to target. But if I keep writing about what I know and have always written about, I will no longer be stretching, learning or growing.

So I take on my own small writing challenges.

I look through the strange and silly ideas I have had, and, instead of rejecting them because they are hard or different, I challenge myself to write about them. And, more importantly, I publish some of them too. The feedback loop on these is very important to self-improvement.

Writing challenges are hard. You have an off-the-wall topic to write about and need to

  • Build a story
  • Have an opinion
  • Be interesting or funny
  • Create an argument

Most of these exercises fail. If I cannot figure out most of the above, the story gets sorted out. But those that I can build even the weakest of stories and arguments on, I work on.

The goal is to make me a better writer. And these challenges have certainly done so. I think my opinion pieces are better presented, and my reference pieces are clearer, all because I stretched myself in writing challenges.

The hardest part was publishing them. I’m no expert on etiquette (See Email Etiquette) or suitcases (see Buying a New Suitcase) or personal story writing (see The Day He Walked to Freedom) or making fun (see Every ‘the Best Programmers Editor’ Review), but I took up the personal challenge, and then put them out there. Ironically, they were surprisingly well received.

I did not want to talk about these challenges at first. They’re stupid exercises that I chose to do to see if I could become a better writer and have no place in a professional persona. But the reality is that they do work, and I seem to find myself being able to talk on a far wider set of topics than before, with greater comfort. It becomes a courage thing to write these challenges, and a courage thing to publish them. These exercises help me find newer ideas for topics to write about, and that is part of the answer to the original question.

Growing the Idea

The sorting process helps me decide whether to write about the idea. It also forces me to think about what I want to say. It is at this stage that I find myself drilling into the idea, thinking about it in more detail and clarifying what I could write on it.

It’s critically important to me to capture these thoughts, as I lose them later on. So I add them to the notes in point form. They are not fully thought out, just the random, unstructured fragments that come to mind while thinking about the idea. Later, I cannot understand half of what they mean. But at the time, it’s important to capture them.

These are not structured thoughts. They are the scattered ideas of a scattered brain trying to think through an idea. They can be structured and reviewed later, but they need to be captured first.

It’s not a formal process either. Brainstorming makes it sound like something you can learn and practice. Maybe you can, but for me its more like dumping a stream of disconnected consciousness into a note.

This section was the one of the last to be written because I really struggled to find the words for it. How does one describe an informal brain dump where your creative and analytical juices are flowing and the result is almost incomprehensible. And yet without this messy pile of random thoughts, I really struggle to fill out the topic with reasonable and useful information when in the process of writing in clear sentences.

Filling it out

So the idea has passed the culling and the sorting. In sorting I added many points I want to make to the note and now it’s time to write.

Early in the piece, I also got stuck here when deciding what to write in this part of the post. I was thinking how sometimes the point you want to make just flows and there is no need to plan, structure, prepare to fill out or justify that part. And other times you get stuck, a part of the story needs to be told but you have no idea how to started on it. So I rely on a few tools, like mind maps, like asking myself why this part needs to be told, or try to document what I was thinking at the time, or even ramble on a bit to see if I get anywhere. Revisiting the structure and the why helps me think through the part again. And write it better. And that reminded me to write the previous section - where did I get the stuff to structure it in the first place?

Some posts take minutes to write and they work. Other posts take months to think on and write on and never get finished. And a lot get rejected because they never get to any point.

For bigger posts, I draw up a mind map using MindNode Pro. If there is a lot to write about, I feel it is important to list all the topics and structure the piece. It also helps me arrange thoughts and ideas. It helps me build the story. It helps me focus on the parts that I need to think about and and write.

For smaller posts, I start with a point-form summary, or a document full of random sentences taken from my notes. No structure at all.

And then I fill each section out with words and paragraphs. I try to type what I want to say, the way I say it. I just write. I do not worry about spelling, grammar, or even what I am writing. I just try to get it down and out as if I were on a stage in front of people having just been given an improv topic to talk about.

Aside: I think I am one of the few people who do not mind being in front of a crowd with nothing prepared. I have not studied improv, but I did teach at university. And teaching makes you learn that you never know what questions a student will ask. So its best to be prepared, but better to be able to think on your feet. And that’s how I write at this part of the process. Of course, unlike public speaking, with writing I can iterate and fix it up later. Oh yes, that’s the next point.

And then I iterate. Just like a programmer does. I reread what I wrote, correct the spelling and grammar. I look at the clarity, did I make the point? Does it flow? What did I miss? Am I repeating myself. This is not reviewing the topic, this is unit-testing, checking each sentence that I have written to see that it says what I wanted it to say, and reads that way. And most importantly, does the sentence add to the story, the argument, the topic, or do nothing with it.

I digress a lot when I talk and think. These “thought bubbles” in this post are proof. But I do come back from digressions because my programmer mind brings me back to the original topic. I do not have a problem with digressions in writing, they usually add color to the story, but too many digressions and the reader will lose track. I try, not very successfully in my opinion, to limit these when I write by iterating and using the delete key frequently. I do not always succeed.

I also get stuck a lot when writing. At the time of making the note, culling or sorting I had great ideas for the post, but now that I am in writing mode, I forget those great thoughts because I am focussed on making sensible sentences. That’s where the structure, the necessity of a point for sentences and the notes help.

Review

At some point, I find I have filled in all the sections. It’s time to go back and see if any of it makes sense. So I review the writing by re-reading it.

The first few reviews are easy. The text is messy, it does not flow. Tones and tenses change. Ideas are still a bit jumbled. But now that the whole structure is filled it, it becomes easier to see where everything is, should be and how it should flow. It becomes easier to see where you repeat yourself, where you digressed, and where you lost the story’s plot.

My early reviews involve re-reading in context, deleting that which is not necessary to the story, and filling in the smaller cracks that got missed out while focussed on writing. It also helps me see if the story works or not. Many a post has gotten this far only for me to realize that the story or points are either nonsense, boring or make another point entirely.

So it’s more iteration, read, edit, write a bit more, re-read, re-edit, re-write.

It is a sad truth, but rereading what you write again and again makes you blind to the text on the page. You start to miss the typos and grammar mistakes. Your eyes skip over paragraphs because you “just know” what’s in them. You assume what’s there instead of read what’s there. That’s why editors exist. But us lone writers do not have any.

For some posts, the ones that just flow, review is easy. They flowed, the point was made, good to go. For others, more tricks are needed to fight text blindness. For me, these include:

  • Reading the post aloud (or at least with my lips moving, like I was reading a speech). It helps to see if saying the words flows as expected, and just by saying things, they either feel right or wrong.
  • Looking at it in a different context. I export to a drafts folder and view it in Marked.app or on the web. The simple trick of changing the look and location of the text undoes much of the reading blindness, helping me see how it works.
  • Time heals all. While reviewing you get blinded. Come back later after doing something else when your mind has been elsewhere and the piece looks and feels different. That’s the best time to re-read and review it again.

The Story

In reviewing this post, I realized that I had harped on a lot about telling a story. But had not yet explained why I think that. After I wrote this section, I noticed that it did not add anything new, every topic on writing pushes story over boring facts, and so I almost removed it. But I also felt the need to clearly point out that posts need to be interesting and the best way I know to make things interesting is to, wait for it, OK, you guessed it, tell a story.

A good post needs to be like a traditional story, it has a beginning, a middle and an end. A great story comes full circle, where the end circles back to the beginning.

For reference pieces, this is easy. The beginning is the problem definition, the middle is detailing the workings of the solution, and the end explains how the solution solves the problem. Full circle.

For opinion pieces, not so easy. The beginning needs to set the stage. Why do I have this view, opinion or position? What is going on that this opinion piece needs to be written? The body then needs to walk the reader through the argument or story. Take them from the pre-set stage, through your thinking to the points you want to make. The road may be straight - a simple story, an easy post - to quite wiggly - complex ideas, digressions, a difficult post. And you need an end. You need to bring the story to a close, to show how and why the opinion or view impacts on the stage and how and why it is to be viewed differently after reading the piece. It’s not a case of being right, it’s a case of presenting your thoughts, ideas and experiences, applying them and helping the reader see what you see.

For the writing challenges, it’s even harder. There may be no beginning other than the challenge itself - like this piece. The body may be a mind game, a list of dry facts, a made-up story, or a well-written dissertation. And the end is your new-found view or understanding. You then need to make that interesting. And that’s where a story overlay kicks in. For challenges, I try to put myself into the challenge. How did I get to this challenge, how did think about it, what did I learn, and how did my understanding of the topic improve. The end may be a good piece or a mess, but at least I learned something, and maybe the reader can too.

Either way, a story is the most common way we share information, its the most common way we remember information and its the most fun way to consume information. I don’t remember the Newtonian formulae for gravity, but I do remember the apple-falling-from-a-tree story.

For a post, a presentation, a speech to be interesting, it needs to couch the information it contains in a story. If that’s all you take-away from this piece, that’s good enough for me.

Fin

It’s time to end this story. Way too many words have been written already. And I think I have covered how I capture ideas, decide what to write and what I then do with it. Which means I have answered the question. Time to close the circle.

When I started writing, I worried about what would I write about, just like the individual asking the question. I did not know who my audience would be, and whether I should write for them or for me. I did not know my own voice. So I followed some good advice and just wrote for me.

Initially the topics were quite random, a lot more writing challenge style posts. But I did start jotting down all my mad ideas. As time progressed, I found myself writing more and more opinion and reference pieces. I still had no audience or voice. And then one day, I noticed that I did indeed have one. This one. And immediately set out to challenge myself to write better for me and my audience.

I get ideas from what I do, see, read and hear. I write about what I am interested in, where I feel I can add to the conversation and hope that you, the reader, finds some of it useful. I write in the form of a story where possible, as its the easiest to consume and remember.

But almost all of my writings all started as ideas in notes. They survived the culling and the sorting. They grew as I thought more deeply on the idea. They got written and reviewed and iterated on. Where possible, they told a story. Some were good, some not so much. But I intend to keep on doing it.

Now, what to write about next? Let’s look in the ideas folder again.

Follow the author as @hiltmon on Twitter.

Lose the WWW

I have finally removed the www from hiltmon.com. The 1990’s have passed and www no longer makes sense in URL’s. Maybe it’s time you did the same to your site too.

What triggered this change was that, as of 14 October 2014, Google Analytics started throwing an error if you had links to www.yoursite.com and yoursite.com. This is because it treated links with www and without as different.

Removing the www was easy. I used Global Search and Replace (⇧⌘F in TextMate 2) to find //www.hiltmon and replace it with //hiltmon. Then regenerated the site.

But we are still faced with the problem that remote links to the site may still include the www in their URL’s. The solution is a 301 redirect. Setting that up depends on your hosting provider. For Dreamhost1, it required clicking one radio button:

Welcome to hiltmon.com.

Follow the author as @hiltmon on Twitter.


  1. Warning: Affiliate link.

Simple C++ Testing With Catch in Xcode

Catch is a simple, open-source, dependency-free unit testing framework for C++ projects. In this post I show you how to use it in a Simple C++ Project from Xcode.

Why Catch?

I am writing fast C++ libraries for work and need to wrap them in unit tests to ensure that they continue to operate and perform as they evolve. My number one constraint is that these libraries must be dependency-free. The only tools that I may use to compile or install these libraries on any platform (in my case OS X and Linux) is a C++11 compiler and a C++ standard library. Nothing else.

This dependency-free requirement precludes the use of excellent popular testing frameworks such as Boost Test (a dependency), cppunit (not up to C++11 yet), google-test (uses a dylib or library depending on the platform) or XCTest (Xcode only and not C++).

Catch is a single header only, dependency-free, lightweight testing framework that’s perfect for my needs. It’s simple to add to a project, simple to create tests cases and scenarios and simple to run. It also allows the user to run only a subset of tests using tags, which is really cool.

And that’s why I chose it.

Install Catch

Just include catch.hpp in a target and you’re halfway there.

The catch.hpp file can be downloaded from http://builds.catch-lib.net/. You can find the full source at https://github.com/philsquared/Catch.

Sample Tests

Catch is well documented. I recommend you follow the tutorial for simple functional unit tests and how to use the product. Since there is no point in me repeating how to write simple tests, go ahead and read through the tutorial, and I’ll wait until you return.

PLAYS ON-HOLD MUSAK

Ok, back? Good. You have seen how simple it is to spin up a TEST_CASE, break it down into several SECTION elements and test results using CHECK and REQUIRE.

Lets do something more complex, lets test a sample class. This sample project is what I used to test Catch when I first saw it and helped me choose it.

First, the tests:

test_sample_class.cpp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include "catch.hpp"

#include "SampleClass.h"

TEST_CASE("Testing Sample Class") {
  SampleClass sc;

  SECTION("setting the str") {
    INFO("Using TestStr") // Only appears on a FAIL
    sc.setStr("TestStr");
    CAPTURE(sc.getStr()); // Displays this variable on a FAIL

    CHECK(sc.getStr() == "TestStr");
  }

  SECTION("test bigStr") {
    sc.setStr("TestStr");
    REQUIRE(sc.bigStr() == "TestStr : 7");
  }

  SECTION("Test doubles") {
    sc.setD(1);
    CHECK(sc.getD() == 1);
    sc.setD(1.0/3.0);
    CHECK(sc.getD() == Approx(0.33333)); // Nice
  }
}

In this example, we have a single TEST_CASE and three sections. Inside the TEST_CASE we instantiate the object and each SECTION tests a function in the sample class. Note that in the example, I arbitrarily switch between CHECK (no stop test) and REQUIRE (stop test), whereas in a real testing environment, I use them appropriately.

Here’s the sample class that we’re testing’s header, it really is quite a useless class but gives us a range of things to try:

sample_class.h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <string>

class SampleClass {

public:
  std::string getStr() { return _str; };
  void setStr(const std::string& s) { _str = s; };

  double getD() { return _d; };
  void setD(double x) { _d = x; };

  std::string bigStr();

private:
  std::string _str;
  double _d;
};

And its body:

sample_class.cpp
1
2
3
4
5
6
7
8
9
10
#include "SampleClass.h"

#include <sstream>

std::string SampleClass::bigStr()
{
  std::stringstream ss;
  ss << _str << " : " << _str.length();
  return ss.str();
}

Testing In Xcode

I setup testing in Xcode using a separate tests folder and a second tests target and scheme. In this sample case, the main project code is in the SampleProject group (usually a library project) and the test target code is in the TestSampleProject group. This group (and its matching file system folder) are automatically created when you add an Xcode command-line target.

To create this target, select the project at the top and click + or choose File \ New \ Target from the menu, choose OS X \ Application \ Command Line Tool, choose C++ as the language and give it a name.

I then add catch.hpp and edit the main.cpp file. The main.cpp in the test target uses the default Catch main function, there is no point in writing my own:

main.cpp
1
2
#define CATCH_CONFIG_MAIN  // This tells Catch to provide a main() - only do this in one cpp file
#include "catch.hpp"

I also add the following command-line options to the test target scheme and toggle when needed:

  • -r console sets up readable console output (not necessary but a good reminder)
  • -d yes shows the time taken on each test (usually disabled)
  • s verbosely displays tests (usually disabled)
  • You could also add any test tags you want to run as an option, but I find most of my test projects run sufficiently fast that I usually leave this out and run all tests. It also protects me from forgetting to run the full test suite.

I then start to add .cpp files for each test case and write my tests.

Finally, you also need to add each class that is being tested to the Test target as well or it will not compile.

Running the test target delivers the following console output on success:

1
2
===============================================================================
All tests passed (8 assertions in 2 test cases)

If any test cases fail, you get:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TestSampleProject is a Catch v1.0 b53 host application.
Run with -? for options

-------------------------------------------------------------------------------
Testing Sample Class
  test bigStr
-------------------------------------------------------------------------------
/Users/Hiltmon/Projects/Spikes/TestCatch/TestSampleProject/testSampleClass.cpp:13
...............................................................................

/Users/Hiltmon/Projects/Spikes/TestCatch/TestSampleProject/testSampleClass.cpp:26: FAILED:
  REQUIRE( sc.bigStr() == "TestStr : 8" )
with expansion:
  "TestStr : 7" == "TestStr : 8"

===============================================================================
test cases: 2 | 1 passed | 1 failed
assertions: 8 | 7 passed | 1 failed

Correct the failures. Then add more tests. Run. Iterate, iterate, iterate. You know how to unit test.

Sample Project

You can download the sample project to see how it works from here.

Experience

I have been using Catch for several weeks now in multiple C++ projects and it’s been wonderful. Setup is easy, adding test cases is simple, running tests is a keystroke away and evolving my core dependency-free libraries is easier and more reliable than ever.

My thanks to Phil Nash (@phil_nash) for creating and maintaining this wonderful tool.

Follow the author as @hiltmon on Twitter.

Gist TextMate Bundle Updated for Yosemite

Thanks to Michael Sheets, the Gist TextMate bundle now works in TextMate 2 on Yosemite. The issue was that the UI code in TextMate 2 relied on Ruby 1.8, and Ruby 1.8 is deprecated and no longer installed in OS X 10.10.

Michael created a shim to fake Ruby 1.8 until such time as the code base moves to Ruby 2.0, implemented the change in the Gist bundle and it’s working now.

You can get the source at GitHub or just wait until it gets propagates via TextMate 2’s bundle update process.

Follow the author as @hiltmon on Twitter.

Create a Bootable OS X Installer Drive

Dan Frakes (@DanFrakes), previously of MacWorld fame, provides easy to follow instructions on how to create a bootable OS X 10.10 Yosemite installer USB drive on his personal blog. I’ve always done this and I recommend you do too.

Link: How to make a bootable OS X 10.10 Yosemite installer drive

Yep, mine is a R2D2 8GB USB Drive (called a Star Wars MIMOBOT) I found at the checkout at Kinokuniya in New York several years ago.

Follow the author as @hiltmon on Twitter.

TimeToCall Removed From App Store

I have removed TimeToCall from the App Store effective today, for several reasons:

  1. I did not update it for iOS 7 (or iOS 8) and it’s starting to look shabby.
  2. I never made any worthwhile money from it or received blog pageviews from it.
  3. There are newer and better products out there.
  4. I do not want to clutter the App Store with yet another abandoned product.
  5. It no longer showcases my development capabilities, they are far better now.

To those of you who purchased and used the product, thank you.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Any Hint of Humanity Is Valued

For decades we have had corporatization, mass-production, and everything becoming the same, having personality drained from it. That became what was common and what was the norm. And then in the last, you know, 5, 10 years, this concept of like the artisanal, the special, the hand-made, like this is coming back …

[interruption edited out]

… I think the reason why everyone loves all this hand-made crap today is because they are starved for authenticity after decades of mass-market personality-less crap, and they are starved for uniqueness, they are starved for personality and they are starved for authenticity and for people to talk to them like, you know, talked to like an adult please.

Lets not, you know like, my first job like out of college, my first job was an internship in college. I worked a summer at Nationwide Insurance, just like doing computer crap for them. And somebody, somebody fucked up at some point and my boss said, and my boss made some comment that indicated that this person had fucked up in some kind of much more nice way.

And I said “Oh, is he going to get in trouble for that?”

And she said “Well, it’s a coaching opportunity.”

And I was like “What? So does that mean he is going to get in trouble?”

And she just kept saying “It’s a coaching opportunity.”

And she wouldn’t, she couldn’t say he’s getting in trouble.

And this has seeped in so far in business culture and everywhere in our culture that any hint of humanity in something is valued and its like everyone is starving for humanity and being talked to with respect like a real person, like an adult, and having some kind of sign that humans are behind this wall, that its not just a corporate machine transferring you to people who can’t help you on the phone. Like some hint that there’s a person behind this who is, who respects you and not in some token mission statement way, a person who actually respects you.

Marco Arment Debug Podcast 43 (10 July 2014)

I think Marco makes an amazing point here. All we use and deal with is corporatized, personality-less, robotiscized horror and so when we do actually get a person who helps, we grab on with both hands.

I use Hover because of this. I bank with HSBC because of this. I even pay American Express for his. And I use Apple products because of this.

Just look at Apple. Its products are full of personality. And you can meet real people in real stores to get real help at the genius bar. It’s humanity in action.

Compare that to AT&T, Verizon, utilities, and other banks with their remote call centers and robot answering services and recorded messages on how important you are and useless drones reading wordy scripts and not listening to you and not helping at all.

Who would you rather deal with?

Any hint of humanity in a product or service is valued, and those that recognize this and act on this are valued and loved and people, people like me, are prepared to pay a premium to have access to them.

Note: Marco quotes transcribed manually by me without permission, punctuation added, all errors are my own.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Standard Markdown

Looks like Jeff Atwood (@CodingHorror), John MacFarlane, David Greenspan of Meteor, and folks from StackExchange, Github and Reddit have put their money where their mouths are and released the first version of Standard Markdown at http://standardmarkdown.com.

I believe this will be the future of John Gruber’s (@daringfireball) Markdown.

Up until now, I have relied on Fletcher Penney’s (@multimarkdown) MultiMarkdown on the desktop for all my documents because of its consistency, ubiquity and wonderful extensions for writers (including tables and footnotes). I use rdiscount for this blog for the same reason (especially it’s speed).

I look forward to seeing Standard Markdown being integrated into these tools to remove inconsistencies, but rely too heavily on the extensions that are missing from Standard Markdown to consider a switch just yet.

I will, however, be watching the development of this very closely.

Update Sep 4th, 2014

It seems John Gruber, the creator of Markdown, was not in the loop on this:

Not cool.

Knowing this now, I’ll wait to see if and how he responds first.

Follow the author as @hiltmon on Twitter.

The Quick Code Cleanup

The quick code cleanup is a process whereby you run through some or all of the files in a software project and tidy them up. Think about it as the regular tidying of your desk (or room) and filing things away – versus the rearranging and rewiring of a full code refactor. You can get a lot more done on a tidy desk.

Quick code cleanups can and do include some minor refactoring, but they are mostly about renaming items, reformatting code and commenting on or cleaning up messy sections. No features are added or changed.

So why do quick code cleanups? Because they save tremendous time as the project progresses. And the best part is, you do not need to do much thinking or need the zone (See the Four Hour Rule). For example, I just spent the last few hours doing a quick code cleanup while watching the US Open tennis!

Here are some of the things to do in a quick code cleanup:

Fix Bad Names

Naming classes, functions and variables is hard. Knowing how they may be used or evolve is almost impossible beforehand. When you name new classes, functions or variables, you have an idea of how you think they will be used. But as the program evolves, these old names may no longer be sufficiently explanatory or correct.

In a quick code cleanup, you revisit naming after-the-fact, but close enough to remember your thinking, knowing how the elements are now being used. You will find that you have a much easier time finding and choosing better names in cleanup. It also means that, when writing new code, you can relax a bit knowing you’ll come back and rename the items you are unsure of.

It makes the code more understandable for later.

Fix Lazy Formatting

While coding, we often forget to format our code properly. Or the IDE (I’m glaring at you, Xcode) helpfully generates its own code layouts for you.

In a quick code cleanup, you reformat the code to whatever standard you prefer, add white space, and rearrange the functions in files to make more sense. For example, I like to have functions that call each other closer to each other in the file so it’s easier to see them on the same screen. At coding time, I may not have written them or know which, at cleanup time I do. I also like to separate paragraphs of code with white space and comments, which I add in cleanup.

It makes the code a lot more readable and browsable for later.

Explain Some Decisions

If you have ever been in a code review you’ll know that the most common question is “WTF were you thinking?”. We know what we were thinking when coding, and we remember that thinking for a short while. But we all forget that thinking over time as other thoughts take over.

In a quick code cleanup, you add comments where necessary to explain your thinking. Why did you design a class this way, or write something that way. Or how does this complex calculation work? What was I thinking at the time?

It makes the code a lot more maintainable for later.

Early Cruft Removal

We all create classes and functions, use them for a while, and then replace them. We do not always remember to remove unreferenced classes or comment them out from the code base. Later on, when searching for how something went badly wrong, we get confused by this extra code. Is this the function called or another? This, to me, is how cruft starts.

In a quick code cleanup, while your mind is fresh, remove all classes and functions that are not being used. If you need them again later, you can get them back from source code control. If unsure whether something is being used, use search in your IDE to see if the function or class is referenced (or just comment it out and compile – if the compile passes, it is cruft).

It makes code smaller, simpler and less confusing for later.

Basic Refactoring

Other than renaming classes and variables, a quick code cleanup also usually entails:

  • Pulling up common and duplicated code into functions, or replacing long, complex, deep if clauses with function calls
  • Adding standard file headers (if necessary)
  • Hiding public variables behind setters and getters (one or both)
  • Commenting out or deleting surplus debug statements
  • Adding missing asserts to document your assumptions

It reduces the number of potential bugs for later.

When to run a quick code cleanup?

I try to do this every few weeks on current projects, when the code is still fresh in my mind and when I have some time. This often coincides with a minor release or the few hours at the end of the week when I know I will not have enough time to enter the zone and work on a new feature.

The quick code cleanup may not seem to be a productive use of your time, but it pays off tremendously as the software grows in size and complexity. As the code-base expands, it yet remains understandable, readable, maintainable, simpler and with fewer bugs, enabling you to spend more time crafting new code and less time figuring out what the hell happened in the past and untangling a knotted mess.

You can start doing quick code cleanups anytime.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.