Liss is More
By Casey Liss
Good Dad 
  ⚓

Very recently, former MLB pitcher Curt Schilling congratulated his daughter becoming a pitcher for her college softball team. As any dad would:

Curt writes:

With that tweet I expected a response. Some congrats for sure, but absolutely the smart ass college kid and likely many of them from RS to reply. And I was not disappointed.

On his site, Curt details some of the deplorable tweets that he received as a result of him being excited for his daughter.

It pains me to say that this, in and of itself, this is nothing unexpected.

His response was.

Curt took it upon himself to doxx several of the jerks who posted those deplorable tweets:

“The Sports Guru”? Ya he’s a DJ named Adam Nagel (DJ is a bit strong since he’s on the air for 1 hour a week) on Brookdale Student Radio at Brookdale Community College. How do you think that place feels about this stud representing their school? You don’t think this isn’t going to be a nice compilation that will show up every single time this idiot is googled the rest of his life? What happens when a potential woman he’s after googles and reads this?

The other clown? He’s VP of the Theta Xi fraternity at Montclair State University. I gotta believe if Theta Xi is cool with a VP of one of their chapters acting like this I’d prefer to have no one I know in it. Also, does anyone attending Montclair State University have a student handbook? If so can you pass it along because I am pretty sure there are about 90 violations in this idiots tweets.

I hope I take these sorts of threats this seriously when Declan is of age.

That being said, I’m sure it won’t be a problem, because Declan isn’t a girl.

Curt summarizes:

The amount of vitriol I’ve heard is not an issue. I am sure I’ll hear more.

But I have to ask, is this even remotely ok? In ANY world? At ANY time?

No. It isn’t.

node-inspector 
  ⚓

File this under “how did I not know about this already‽”.

Earlier today, I lamented on Twitter that me having never really learned gdb nor lldb hasn’t served me well when working with the debugger for node.js.

Twitter quickly reasserted its worth, as two people immediately called node-inspector to my attention.

node-inspector, in short, allows you to use Chrome’s JavaScript debugger to debug your Node.js apps. This is the same debugger you may have used to debug your front-end JavaScript.

Demo reel

As I had previously been doing debugging by way of liberal use of console.log(), node-inspector is a revelation. I haven’t felt this free since I switched from writing C++ on the Watcom compiler on DOS to using Visual Studio on Windows.

I expect node-inspector to save me a ton of time in the future.

True Development is Boring

Your favorite snowman and mine, Dr. Drang, has responded to Brent Simmons’ observation that software engineers don’t really have a code of ethics. Certainly not like traditional professional engineers from old and boring tangible disciplines like civil engineering.

In his post, Dr. Drang makes an observation:

Not that long ago, Daniel [Jalkut] couldn’t be a licensed engineer, because there was no licensure procedure for software engineers, but that changed a couple of years ago. Now there’s a licensing exam for software engineering, although I don’t know how many states currently accept it.

…which he follows with a question:

(I am, by the way, curious what programmers think of the topics covered by the exam.)

I’m a programmer software engineer, and I’m happy to weigh in. But first, a diversion.

When I landed my first job out of college, I was writing software that ran bingo games that masqueraded as slot machines. When I arrived, I immediately realized that despite graduating from a top-10 public undergraduate engineering school, that I had no clue how to write software. We were using crazy things like “source control” and “issue tracking software” that I had never heard of before.

I had to learn quickly. I had to take all the theory that I learned in school and turn it into practical knowledge.

Fast forward a couple years and I’m working for a defense contractor. The firm was, at the time, CMMI Level 3. That means, in short, that we were pretty good at writing software reliably. Our estimates were nearly always on the mark, and our releases were nearly always bug-free.

Here again, I had to learn quickly. I had to learn how to be a good participant in code reviews — both as a presenter and as a contributor. I had to learn what a quality assurance department was, and how they are friends, not foes. I had to learn that, in that environment, waterfall is your friend.

With this knowledge in mind, that brings me back around to Dr. Drang’s question: what do software engineers think of the topics covered by the exam?

I think they make perfect sense, and I like them.

The topics were clearly written from the perspective of someone who takes software engineering seriously. Not the fire-from-the-hip startup world, where failure is an option. Instead, this was clearly written to encourage real, true, software engineering. Development that is predictable and reliable. This is abundantly obvious in the first 10 lines of the topics list:

I. B. Requirements elicitation
I. C. Requirements specification
I. D. Requirements analysis
I. E. Requirements verification
I. F. Requirements management

Perhaps I’m allowing my perspective to be skewed by a career mostly in consulting, but these topics being part of a software engineering exam makes me smile.

The catch about software engineering — about development in general — is that to be a great developer is to be great at the un-sexy stuff. To be a great software engineer is to be great at the entire process of writing software. It begins with defining the problem, and flows all the way through ensuring changes to a deployed system do not break the system:

VI. C. Configuration status accounting
VI. D. Release management and delivery

In this environment where the new and exciting are fetishized so heavily, the reality is that writing code that’s “boring” is actually a good indicator that you’ve done your job well. Having a sign like this, while funny, means we’re probably not doing our jobs right.

Speak Beautiful

Dove ran an ad before the Oscars that I was glad I happened to catch:

The cynical man in me says I shouldn’t be celebrating a commercial. Really, though, I’m just happy to see the message get out.

You are beautiful.

Gold Ain't Cheap

Matthew Panzarino of TechCrunch retweeted a couple interesting tweets about the Apple Watch last night:

This corroborates the rumblings I’ve heard about cost.

Not long ago, I remember just having an iPhone could be construed as a status symbol. The Apple Watch will be taking it to a whole new level.

Behind the App 
  ⚓

One of the disadvantages of having such smart friends is never knowing when they do great work.

When John writes an amazing OS X review, is it really amazing? Or am I just biased because John is my friend?

Is Overcast actually good? Or do I just really like Marco? Or maybe I just really like orange?

Are the retrospectives Stephen, Federico, and Myke did, for the iPhone and iPad, truly impressive and deserving of our praise? Or do I just find their unique accents so adorable?

I hope and suspect the answer to all of the above questions is “yes”.

When Myke sent me a pre-release version of the new Inquisitive, I was immediately floored. Myke has brought a level of research, discipline, storytelling, and polish to tech podcasting that I haven’t heard before.

Myke is a dear friend. We share a podcast together. I’m predisposed to like everything he touches.

Despite all that, I’m completely confident when I say Inquisitive: Behind the App is good. Really good.

Eschewing his previous interview/profile format, Myke has started Inquisitive anew, taking it in a very different direction. The first series is about making apps in today’s app-obsessed world. There are plenty of interviews in the episode, and perfectly tell the story that Myke is setting up.

It’s a neat and welcome change for me to hear all these voices in one show. As an exclusive listener of one-to-three-host podcasts, Inquisitive sounds so delightfully different to me. As an occasional listener to This American Life, I was very much reminded of that format and editing style. Given This American Life is one of the most popular podcasts on the planet, that’s quite a compliment.

I’m really impressed with the new Inquisitive. Not just because Myke is a friend, but because it’s damned good programming. If you’re a fan of ATP, you should really like it. If you’re not a podcast listener, Inquisitive is a wonderful way to dip your toe in the water. You won’t regret it.

Scenery

Yesterday The New Yorker released a phenomenal profile of Jony Ive written by Ian Parker. Well worth the very long read, I could quote so many portions of the piece.

These quotes related to cars deeply appealed to my inner gearhead:

[Ive] and Newson are car guys, and they feel disappointed with most modern cars; each summer, they attend the Goodwood Festival of Speed, where vintage sports cars are exhibited and raced in the South of England. “There are some shocking cars on the road,” Ive said. “One person’s car is another person’s scenery.” To his right was a silver sedan with a jutting lower lip. Ive said, quietly, “For example.” As the disgraced car fell behind, I asked Ive to critique its design: “It is baffling, isn’t it? It’s just nothing, isn’t it? It’s just insipid.” He declined to name the model, muttering, “I don’t know, I don’t want to offend.” (Toyota Echo.)

Later:

Jeff Williams, Apple’s senior vice-president of operations, drives an old Toyota Camry. Ive’s verdict, according to Williams, is “Oh, God.”

Apple Building Their Own Car?

The Wall Street Journal is reporting that Apple is working on their own electric car:

Apple has several hundred employees working secretly toward creating an Apple-branded electric vehicle, according to people familiar with the matter. They said the project, code-named “Titan,” has an initial design of a vehicle that resembles a minivan, one of these people said.

I’m pretty skeptical. If this does happen, I know who is having the last laugh.

Perspective 
  ⚓

When I first started doing ATP, I wasn’t really prepared for the amount of feedback I’d get. Some of it was funny — who the hell is Casey, anyway? Some of it, though, was really harsh. Some days it feels like everything I say is critiqued or criticized somehow.

It can hurt after a while.

What I have to deal with, though, is not even in the same universe as the hatred that some people face. These people, almost universally women, are ridiculed, ostricised, and even threatened, simply because they are women with opinions.

What Brianna Wu (among many others) has gone through is not only stupefying, but also terrifying. I don’t know how she has the will, the tenacity, and the stamina to continue to fight every day. To continue to fight for something that should already be a given. To continue to fight for her right to be a woman with an opinion.

Take a few minutes out of your day and read her piece at Bustle. It’s well worth your time.

Small Hurdles

Last night I added native post-to-Twitter support to Camel. In and of itself, this is not particularly remarkable. However, the path to get there is an interesting example of how developers work, and how one small change can create some significant ripples.

Genesis

Everything started with me deciding to add the ability to make link posts to Camel. That went smoothly and, at first glance, didn’t create any further problems. Until:

I needed to do something to fix this.

Diversion #1: RSS Modifications

Thus, I did what was recommended, and I had seen a zillion times before. I modified the RSS generator to set the URL of the post not as my own site, but instead the target of the link post. All seemed well.

Then I made a second link post and realized something else was amiss.

A New Problem

At the time, I was using IFTTT to automatically tweet when I make new posts to this site. That was working perfectly, until I made that change to how the RSS worked. Notice the difference between this tweet, which was before the change:

As compared to this tweet, after the change:

You’ll notice in the latter tweet, the link is to the external URL, not to this site. This is a change from how it was before I adjusted the RSS feed. Unfortunately, I preferred it the old way.

I was now at an impasse — I could either have RSS work the way I want or Twitter work the way I want. At a glance, there was no way to tell IFTTT to use a different URL for what it posts to Twitter.

Diversion #2: Creating a Twitter App

Most of the motivation for using IFTTT was to avoid having to write my own Twitter client into Camel. I didn’t want to do that specifically because I wasn’t sure how the OAuth flow would work. The idea was for Camel to autonomously post to Twitter; I had no intention of building a login flow just for that.

As it turns out, I had made a poor assumption.

When creating a Twitter application (which is to say, asking Twitter for the ability to access its data programmatically), you can actually get the requisite OAuth tokens by hand for the account that created the application. So, I created an application off of the @caseyliss Twitter account, and was able to mock something up using the twitter package for Node.

However, since I created the app off of my Twitter account, it could only post to my account. Now that I had things working, I need to create a Twitter application off of the @caseylisscom account, so tweets would be posted from there. That should have been easy, until I ran into this:

Twitter Error

At a glance, this is no big deal. Until I remembered that my phone number is associated with my @caseyliss account. Unsurprisingly, Twitter only allows a phone number to be used for one account.

Diversion #3: Getting a Burner Number

Most people need a “burner” phone number to do nefarious things. Perhaps they’re trafficking illegal items. Perhaps they’re running around on their spouse.

Me? I’m trying to get my blog to post to Twitter.

I wasn’t sure how to go about getting a burner number that can receive text messages. I asked on Twitter, and got a few responses. Most immediately jumped to Google Voice, but others pointed out that Google Voice can’t receive messages from short codes. So, that was a non-starter.

By the magic of Twitter, though, I did get the winning suggestion:

I quickly checked out Burner, and it looked promising. I downloaded it, set up a number for free[1], and plugged that into Twitter. It sent me a confirmation code, which Burner received no problem, and I was up and running.

A New New Problem: Determining When to Tweet

The next obstacle was determining the right time to tweet. Camel doesn’t have any sort of database, and Heroku has an ephemeral filesystem, which means I can’t just save a record of the last post that has been tweeted. Thus, the only reliable way to figure out what has been tweeted is to look at the tweets of the account itself. In my case, that meant inspecting @caseylisscom’s tweets.

Though I very rarely write tweets by hand from @caseylisscom, I do on a rare occasion. Thus, it wouldn’t be as simple as just grabbing the most recent tweet, or even the most recent tweet that had a URL associated with it. I needed a reliable way to determine when Camel itself had tweeted last.

The easiest answer? Look for tweets posted by the just-created Twitter app that Camel uses.

The general idea is, Camel looks at the most recent tweet posted using “Camel Spitter” (the aforementioned app) has made. Once it finds the most recent auto-tweet, Camel looks at the URL on that post, and sees if it matches the URL of the most recent post within Camel. If not, Camel will fire off a new tweet for that post.

Diversion #4: Deployment Issues

At this point, I had:

  • A RSS feed that points to the external link when the post is a link post
  • A Twitter app unique to my website
  • Code to automatically tweet when a new post is posted

I had everything I needed, so I went ahead and deployed the changes to Heroku. Which didn’t work:

module.js:340
throw err;
      ^
Error: Cannot find module 'Twitter'
	at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/app/camel.js:21:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)

Uhhhhhh… what?

After doing a bit of trial-and-error, I realized that my Mac’s file system (🔔) is not case-sensitive, but the one Heroku uses is. Thus, this line:

var twitter = require('Twitter');

Just needed to be changed to:

var twitter = require('twitter');

And everything was right as rain.

Turns Out

None of the actions above are particularly remarkable, but what made it interesting to me is that a seemingly innocuous change — adding the ability to create link posts to Camel — caused quite the avalanche of random changes and issues.

Despite all the pain, Camel is now considerably more robust than it was just a week ago. I’m extremely happy with where it’s ended up. The challenges were, well, challenging, but that’s exactly what makes software development so much fun.

When the dust settled, after all that work, I got this:

…and I couldn’t be happier.

  1. Burner gives you 60 free text messages & 20 free minutes when you install; it’s an in-app purchase to get more. ↩

« Newer 
» Older
Copyright © 2014-2026 Limitliss LLC