iOS Storyboards Tutorial

I’m starting to learn iOS app development, so I wanted to learn the basics of the latest and greatest for iOS UI development: Storyboards. A quick search online lead me to this great tutorial at raywenderlich.com.

I found it was short, to the point and covered the basics well. It got me introduced to the interface in XCode and the primary concepts of Storyboards. I would recommend it if you’re jumping into iOS development.

Curated List of Falsehoods Programmers Believe In

On GitHub there is an entertaining collection of falsehoods that many programmers believe in:

Falsehood articles are a form of commentary on a particular subject, and are appreciated by the developer community at large for their effectiveness and terseness. They’re a convenient written form to approach an unfamiliar domain by dispelling myths, point out common pitfalls, show inconsistencies and subtleties.

In a sense, Falsehood articles are a suite of wordy unit-tests covering extensive edge-cases provided by real-world usage.

I’m personally a fan of the date and time falsehoods.

Long Names Are Long

Bob Nystrom, on identifiers (e.g. variable or method names) in code:

What I want to talk about is something I see in a lot of code that drives me up the wall: identifiers that are too damn long.

Yes, names can be too short. Back when C only required external identifiers to be unique up to the first six characters; auto-complete hadn’t been invented; and every keypress had to be made uphill, in the snow, both ways; it was a problem. I’m glad we now live in a futuristic utopia where keyboard farts like p, idxcrpm, and x3 are rare.

But the pendulum has swung too far in the other direction. We shouldn’t be Hemingway, but we don’t need to be Tennessee Williams either. Very long names also hurt the clarity of the code where they are used. Giant identifiers dwarf the operations you’re performing on them, are hard to visually scan, and force extra line breaks which interrupt the flow of the code.

While the algorithmic part of programming is a science, writing readable, easily understood code is an art.

Handling a Dying Router

My router is dying. How do I know? It keeps dropping my wireless connection. I’ll be away from my home server and, when my router goes down for a few minutes, it loses its wireless connection. Then a bug in OS X results in my server failing to reconnect to the network, leaving it offline until I can get to it.

This has been happening a few times a week for a couple of months. I was kind of hoping it would start happening so frequently it would give me an excuse to get a new router, but alas, the old router keeps hanging on.

To work around this issue, I wrote a script for my server that runs every 10 minutes, checking if there is an internet connection. If not, it logs it, then restarts my server’s wifi connection so it will re-connect. This has let my router live another day.

Logging the disconnects has allowed me to get a handle of just how frequently my network is dropping (on average once per day so far), and therefore properly evaluate when to get a new router.

Below I walk through the script; next time I’ll go over how I automated its execution.


Since my home server is a Mac, I wrote the script in AppleScript. View and download the full script here.

Lines 2-29 redundantly attempt to ping the OpenDNS servers, noting if there’s a connection. I grabbed this code from an answer on Stack Exchange.

set connected to false

-- Ping the primary OpenDNS server.
try
    set pingResult1 to do shell script "ping -c 1 208.67.222.222"
on error
    set pingResult1 to ""
end try

-- Check the results returned and return true or false.
set p to number of paragraphs in pingResult1
if p < 5 then
    -- Ping another Open DNS server for redundancy.
    try
        set pingResult2 to do shell script "ping -c 1 208.67.220.2220"
    on error
        set pingResult2 to ""
    end try
    
    set p to number of paragraphs in pingResult2
    if p < 5 then
        set connected to false
    else
        set connected to true
    end if
else
    set connected to true
end if

Line 31 simply sets the path to the log file. I’m keeping it on my desktop and have named it reconnectLog.txt.

set logFile to (path to desktop as text) & "reconnectLog.txt"

If there isn’t a network connection, line 34 logs the date and time the disconnected state was encountered, using the appendToDisk function defined at the bottom of the script.

if not connected then
    appendToDisk from ((current date) as text) & " Disconnected
" into logFile

Lines 38-40 attempt to reconnect by restarting AirPort, OS X’s WiFi service. To do this, commands must be run in the shell using the do shell script syntax. I inserted a delay of 3 seconds between turning AirPort off and turning it back on to improve reliability. Sometimes it wouldn’t turn back on if the call was made too quickly. I grabbed this code from a StackOverflow question.

    do shell script "networksetup -setairportpower AirPort off"
    delay 3
    do shell script "networksetup -setairportpower AirPort on"

If there was a connection, line 42 logs the date and time the check was performed.

else
    appendToDisk from ((current date) as text) & " Connected
" into logFile
end if

Lastly, the function appendToDisk is defined on lines 47-57. This takes theText and appends it to the file located at thePath, while handling errors. I grabbed this code from an answer on Stack Overflow.

on appendToDisk from theText into thePath
    try
        set fileDescriptor to open for access file thePath with write permission
        write theText to fileDescriptor starting at eof
        close access fileDescriptor
    on error
        try
            close access file thePath
        end try
    end try
end appendToDisk

A Better .NET Regular Expression Tester

Recently I needed to write a regular expression in C#. To validate it I needed a regular expression tester for .NET. A quick search led me to Derek Slager’s Better .NET Regular Expression Tester.

Simple, yet effective, it supports all evaluation options (e.g. case insensitive), multiple matches and was fast to execute.

OneCore to Rule Them All

Peter Bright at ArsTechnica has the detailed and fascinating story on how Microsoft came to have a single kernel for all Windows devices: OneCore. So far, Microsoft is the first in the consumer operating system space1 to achieve this feat:

Microsoft can now credibly speak of having one operating system (with Windows 10 as its most familiar branding) that can span hardware from little embedded Internet of Things devices to games consoles to PCs to cloud-scale server farms. At its heart is a slimmed down, modularized operating system dubbed OneCore. Windows 10, Windows Server, Xbox 10, Windows 10 Mobile, Windows 10 IoT, and the HoloLens operating system are all built on this same foundation.

It took a long time to reach this point. Along the way, Microsoft built three major operating system families, killed two of them off, and even reorganized the entire company. In the end, all that action was necessary in order to make building a single operating system practical. Apple and Google will probably do something similar with their various operating systems, but Microsoft has managed it first.

This is an incredible feat, particularly that this was accomplished while still maintaining Microsoft’s sometimes extreme levels of backwards compatibility.

OneCore comes with initial benefits for Microsoft and third party developers; however, consumers will reap the benefits indirectly in the long term:

Perhaps the biggest gains, for both developers and users, come from unexpected new platforms. When the first work on MinWin was started, nobody could have imagined that one day HoloLens might exist. But with the OneCore platform, adding support for this new hardware becomes relatively straightforward.

The past decade has been an incredible period of technological innovation, with the next decade looking just as bright as all of the technology companies fire on all cylinders. I can’t wait to see and be a part of what comes next.


  1. Yes, technically Linux was first — by a long shot. Let’s be honest though: Linux has negligible market-share and impact on the consumer desktop market; its dominance is on server and, arguably, embedded systems. ↩︎

Scream Testing

I came across an interesting method of testing, but not to find defects. Instead, scream testing can be used to determine if some hardware or a service is being used or not:

...we put these servers into a scream test environment where they still have access to our corpnet, but users are now limited from doing just about anything on the machines except logging in.  If someone does log onto a machine to try something (like running tests, installing other software, etc.), a dialog pops up telling them that this machine is in a scream test and they need to contact my lab managers if they want access back for this server, otherwise it will be retired in so many days.  We usually put a set of servers in a scream test for 2-4 weeks.  Some people on the team will scream profusely and we are happy about that.

Hello, Machine Learning

If you’ve ever been curious about Machine Learning, this is a short, easy to understand introduction to the concept.

Programming Sucks

Fact: I love programming.

Also fact: I loathe programming.

Programming Sucks does an impeccable, and hilarious, job of describing the parts of programming that, well, suck:

Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro, you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.”

They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming. [...]

In particular, this is one metaphor that rings far too true:

...the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. [...]

Much of programming is managing insanity. Some of us are insane enough to love doing it.

Vexing Exceptions

In C# it can be sometimes be confusing to know what exceptions to throw and which to catch. The ever insightful Eric Lippert has a great way of categorizing exceptions, leading to the simple answer: only catch the vexing exceptions.