File this under "how did I not know about this already‽".
As I had previously been doing debugging by way of liberal use of
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.
node-inspector to save me a ton of time in the future.
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.)
programmer software engineer, and I’m happy to weigh in. But first,
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.
Discovered this sign at the W3C headquarters... pic.twitter.com/M9XJ2nW6rW— James Ward (@_JamesWard) February 11, 2015
For fun, I took my Apple Watch models and used SW and some basic assumptions to figure the gold content. 29.16g: pic.twitter.com/WGEnjtj1Yh— Greg Koenig (@gak_pdx) February 19, 2015
If anyone thinks Apple is charging less than $5k for the Edition, they are smoking crack. Based on the gold content alone, $5k easy— Greg Koenig (@gak_pdx) February 19, 2015
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.
One of the disadvantages of having such smart friends is never knowing when they do great work.
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.
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.)
Jeff Williams, Apple’s senior vice-president of operations, drives an old Toyota Camry. Ive’s verdict, according to Williams, is “Oh, God.”
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.
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.
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.
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:
@caseyliss You seem to have forgot to somehow expose the links in your RSS. Just links to the post on the site.— Hampus Jensen (@Leonick91) February 6, 2015
@caseyliss Having the item link be your link and including a permalink to your site at the bottom of the post content seem to be "standard".— Hampus Jensen (@Leonick91) February 6, 2015
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:
Camel Gets Link Posts http://t.co/f36LORcVzD— Liss Is More (@caseylisscom) February 6, 2015
As compared to this tweet, after the change:
Top Gear Aftermath http://t.co/849tDD5TVV— Liss Is More (@caseylisscom) February 8, 2015
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:
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, 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)
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.
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:
Top Gear Aftermath http://t.co/aySRavVYVu— Liss Is More (@caseylisscom) February 9, 2015
…and I couldn’t be happier.
Burner gives you 60 free text messages & 20 free minutes when you install; it’s an in-app purchase to get more. ↩
I’ve long wondered what happens to the cars that the hosts of Top Gear drive once they’re done with them — particularly so for cars they drive on foreign soil. In the past, I’ve noticed some of them end up in the studio, but not always. What happens to the others?
By the end of this episode the cars still worked perfectly, although they suffered minor cosmetic damages.
After looking at these pictures, it’s clear that not everyone has the same definition of "minor damages".
Link via Top Gear Box