Hi, I'm Josh Symonds

I blog about Ruby on Rails, coding, and servers

Cryptolalia, for Creating Cicada 3301 Ciphertext Puzzles

Reading time 4 minutes

After reading yet another article on Cicada 3301 on Hacker News a few weeks ago, I was struck by inspiration. If I wanted a whole gaggle of people on the Internet to compete for — well, for some unknown goal — apparently all I needed was ciphertexts of arbitrary complexity and arcane places to hide them. Arcane places I had, but what I didn’t was a good way to generate all the sorts of codes that Cicada 3301 employed.

So I decided to make it.

Don’t Code Defensively

Reading time 4 minutes

As an engineer, we’re responsible for creating things that people care about deeply. Whether you’re programming something as important as a car’s operating system or as silly as an iPhone game, our code touches lives. It’s no wonder, then, that the people who interact with our products feel strongly about them — and possibly about us, as well.

This can sometimes be a good thing. It’s always touching to receive a heartfelt letter of thanks and admiration from a customer. But much more commonly, you’ll hear complaints, demands, and anger.

Under a deluge like that, it’s easy to become disillusioned and bitter. I see it all the time: programmers who hide in their shells at the slightest provocation. They make excuses, shift blame, and refuse to own their actions. I think this attitude is ultimately cowardly — if you’re willing to take credit for the good things you’ve done, you have to “take credit” for the bad stuff too. And cowardice of this sort contributes to making bad code, since your goal is no longer to to solve your organization’s problems, but to shirk responsibility.

That’s what I call coding defensively — an entirely separate subject from defensive programming. Coding defensively mires you in your codebase. It’s hard to go forward because you don’t want more responsibility, and you can’t go back because it would be admitting error. And it’s a self-reinforcing cycle: once you start becoming defensive, it’s difficult to stop.

I was a defensive coder too. I struggled to own the results of my actions: I would refuse to discuss solutions in a sensible, level-headed way. It took me a long time to change my approach, and as part of doing so I wrote a list of maxims summarizing how I wanted to think and act. When I feel myself slipping I go over them to refresh my resolve. I’m publishing them here in the hope that they’ll help someone else as much as they’ve helped me.

What Makes a Good Programmer Good?

Reading time 4 minutes

I’ve worked with a lot of programmers over the years — some of them super amazing, and some distinctly lackluster. As I’ve had the pleasure of working with some very skilled individuals recently, I spent some time thinking about what I admire in them. What makes a good programmer so good, and a bad programmer so bad? Or, to mangle English a little bit, what makes a good programmer good?

Based on my experiences, being a great programmer has nothing to do with age, education, or how much money you make. It’s all in how you act and, more deeply, how you think. I’ve noticed a consistent set of habits in the programmers I admire. More than knowledge of their chosen language, deep understanding of data structures and algorithms, or even more than years of on-the-job experience — the way they communicate, the way they conduct themselves, and the way they approach programming speak volumes as to their amazing level of skill.

Certainly there’s more to being a good programmer than anyone can enumerate, and I wouldn’t judge any programmer solely based on the presence (or lack) of these practices. But I do know wisdom when I see it, and when I see a programmer expressing these traits, I think, “This person really knows what they’re doing.”

Sidekiq + Houston: Production Ready

Reading time 3 minutes

Three months ago, I wrote Sidekiq + Houston: Persistent Apple Connection Pooling. The code I included there initially worked great but over time all the APN connections I had established would break and not restart themselves appropriately. To correct this issue, I wrapped the APN connection itself in a class that was more resistant to failure. To help those who are using Sidekiq and Houston together in production, here’s the code I used to do so.

Helper Methods in Sprinkle

Reading time 2 minutes

Recently I’ve been using sprinkle a lot in a large client project. Sprinkle is server provisioning software, akin to Chef except much lighter. It’s most directly akin to rubber, but rubber’s biggest advantage is its pre-built recipes: it’s a little finicky to sensibly extend, and those only work well on EC2. Sprinkle is built for extension, customizability, and platform agnosticism, but comes with no recipes at all by default. Tradeoffs!

Sprinkle (and rubber) are very different from most other server provisioning software I’ve used — on the one hand, by leveraging Capistrano for server communication (or SSH or Vlad if you prefer), it remains extremely light and focused on just provisioning. But on the other, it inherits most of Capistrano’s downsides too: primary among them is that it’s easy to repeat yourself if you’re not careful. So I wanted to post a quick tip for other people using sprinkle on how to DRY it up just a little bit.

Gistify 1.2.0: Drag & Drop Gisting

Reading time less than 1 minute

Gistify just keeps getting better!

Gistify 1.2.0 is now in the App Store, and features some awesome drag and drop magic. Drag a snippet of text or an entire file onto the Gistify icon and a new gist will be created from your file. The format of the file will automatically be detected, and the resulting gist URL added to your clipboard just as usual. Amazing!

In addition to that big new feature, 1.2.0 features a number of bug fixes and performance improvements: for example, now Gistify will properly start up if you check the “Open at Startup” box, and you can copy and paste in the GitHub username/password fields (for the 1Password or LastPass users out there). Just small quality of life improvements generally.

Interested in giving Gistify a shot? Go download it now! Or if you’d like to demo it without paying the $1.99, just let me know and I’d be happy to set you up with a review copy.

RubyMotion Update: One Month Later

Reading time 2 minutes

My last post on RubyMotion generated quite a lot of interest, and I’ve been asked a few times for my opinion on the recent RubyMotion bugfixes (like correcting RM-3 and RM-32). I thought it sensible to revisit this issue a month later to discuss the changes the HipByte team has been making and what they mean for the future of the RubyMotion project.

Sidekiq + Houston: Persistent Apple Connection Pooling

Reading time 2 minutes

I updated the code here based on my production experiences with it in a new post, Sidekiq + Houston: Production Ready. Check it out after reading this article.

Having not updated rapnd in a good long while, I was looking for well-supported, up-to-date solution for persisting long-running connections to Apple’s push notification service through a worker. I didn’t run into anything offhand, and also haven’t posted a helpful code snippet in awhile, so this is how I connected Houston and Sidekiq to Apple’s Push Notification service.

Why I’m Not Using RubyMotion in Production

Reading time 5 minutes

Based on recent bugfixes and refinements by the RubyMotion team, I’ve posted an update to this blog post. Check it out after reading this article.

I’m a big proponent of RubyMotion — a year and a month ago, I wrote an article titled “Why RubyMotion is Better Than Objective-C” and despite its divisiveness I still stand behind the points I made. Recently I’ve been doing a lot of OSX and iOS coding, coming out with a Mac app and working on a new iPhone app for a client. For both projects, though I initially evaluated RubyMotion, I ended up settling on using Objective-C. Given that my blog post is frequently cited as a reason to adopt RubyMotion, after more than a year of its use, I wanted to weigh in on why I believe it isn’t an appropriate choice for production applications.

Big Brother Is Both Savvy and Incompetent

Reading time 4 minutes

I heard an argument recently that the data collected by PRISM was safe from abuse because if the government had the technical expertise to gather the data, it had the competency to secure it as well. While on the face of it this statement is flatly absurd, its derivatives can seem plausible:

  • “The data is only used if a court approves.” (The fallacious assumption being that the government can reasonably control access to the PRISM data.)
  • “The government is trying to protect us by safeguarding this information in one place.” (Of course, the idea that this centralized database’s existence has made said data more secure is preposterous.)
  • “You had no assurance of privacy on the Internet anyway, so why should this bother you?” (Because while I can take reasonable steps to make my own data secure, once it’s in the government’s hands it’s their responsibility, and, as should be abundantly obvious, leaks happen.)

It’s easy to believe that a government agency capable of collecting this information and then keeping its existence a secret for so long must have a way of keeping it safe. Unfortunately, the access that was given to the NSA to take this information has no correlation to the skills necessary to secure it; and the very fact of PRISM’s existence will probably prove too enticing a target to remain secure for very long.

Essentially, the argument as I heard it can be expressed as a simple question: if the government is savvy enough to gather the data, surely they’re not incompetent enough to lose it? Unfortunately, big brother can indeed be both savvy and incompetent. I think this is the greatest danger to the data PRISM allows access to — not improper use or excessive domestic surveillance, but complete and outright theft.