For the last few days my wife and I have been visiting family on both sides that live around Los Angeles. Since we were bouncing between locales, and since LA is an exercise in urban sprawl, we decided to rent a car. A friend of mine had mentioned that he was looking forward to trying a new rental service that is only available in a few locations: Silvercar.
The Idea
Silvercar is designed to be a modern, tech-savvy take on car rentals. In most locales, the process is as follows:
- Make a reservation using their app or website
- When you arrive at your destination, find the Silvercar rental area
- Walk up to any silver Audi A4. It’s the only kind of car they rent
- Scan the QR code on the windshield using the app
- Get in and drive away
Silvercars offer a few perks over regular car rental:
- As mentioned, the fleet is entirely silver Audi A4s.
- All cars are equipped with WiFi (more on that later)
- Easy in/out using the iPhone app
- Competitive prices: we paid under $70/day for a rental out of LAX, though this included a $50 new customer credit. This is roughly on par with a far crummier car from Hertz.
- When you return the car, if you don’t want to bother filling it with gas, they charge $5 plus whatever the normal rate is at the pump.
First World Problems The Car
I have, in very short time, gone from hating all BMW drivers to becoming one. In all the worst possible ways. I really do believe that within the semi-affordable sport sedan segment, they are “The Ultimate Driving Machine”. Part of the draw of renting a Silvercar was being able to see how an Audi compares.
It turned out to be death by a thousand paper cuts.
To be clear, I really liked the Audi. I thought it was a well-made car, and way, way better than any other rental I’ve ever had. But many things about it annoyed me just a little. By the end, it made me appreciate how much better the A4 was than any other rental, but also made made appreciate my car that much more.
What I noticed:
- The window sill is too high, but
- the center armrest was just a little bit too low.
- The feel of the switchgear was excellent.
- Audi’s MultiMedia Interface, which is their equivalent of iDrive:
- The stick, rather than sliding in four directions like on the iDrive, instead tilted. Which was wonky, and felt flimsy.
- It showed wonderful upcoming exit information (i.e., what gas stations were at upcoming exits), but at the cost of next-move instructions not being terribly clear.
- However, the display in the instrument panel included navigation data, which was awesome, and much nicer than the single center-mount screen I have in my car.
- …but it didn’t show the next turn as early as I would like.
- The stereo was pretty bad.
- The volume control was to the right of the gearshift, in an unnatural place for the driver, but much more accessible to the pasenger.
- The car sounded like an anemic, struggling 4-cylinder. Probably because it was an anemic, struggling 4-cylider.
- The WiFi was slow. Unbelievably cool to have for free in a rental, but really slow. To be fair, this test was done on the 405 outside LA and it could be a hiccup.
The only other thing to note is that in some locales, such as LAX, there are absolutely no car rental agencies on site. Thus, you have to take a LAX shuttle to the cell phone parking lot (which is free). When you get on the bus, you use the Silvercar app to send a text message to them to let them know you’re on your way. By the time you get there, the car is waiting. An additional car is also waiting to take your delivery agent back to their facility. It worked out well, but it did take time for the bus to arrive.
On the return side, you drop the car off at their facility, and then one of their drivers takes you to your terminal in that same car.
At a more traditional airport with on site rental car presence, none of this would have been the case.
Overall
Would I do it again? If it’s cheaper than Hertz/equivalent, absolutely. If it’s slightly more expensive than Hertz, almost surely. However, the value-add diminishes as price gets more and more expensive than a traditional, national chain.
No matter what, I definitely recommend Silvercar, and will start my next car rental search with them.
Should you decide to give it a try, you can use the referral code CLISS
; if you do, we’ll both get $25 off.
I’ve been evangelizing T-Mobile’s free 200MB data for life for a while now. I think it’s a really smart move on T-Mobile’s part, and I admire them for doing something outside the box.
Well, I did, anyway.
Around a month or two ago, the website used to manage your prepay account, T-Mobile’s Mobile Internet Management, changed. Instead of accepting passwords of up to 16 characters, it now accepts passwords that are 15 characters or less.
As a developer, I am already shaking my head in disgust, but the fun is only beginning.
When I attempted to log in with my 16 character password, I was forbidden, because my password was too long. “Okay”, I thought, “I’ll just reset my password using the ‘forgot password’ link.”
Nope.
When one “forgets” their password on T-Mobile’s MIM, T-Mobile simply e-mails the password back to the on-file e-mail address. In my case, the invalid, 16 character password.
Sigh.
For a couple months, this was simply an annoyance. I had been able to see how much of my data was used each month, but now I can’t. Instead, I’ll just rely on the “you’re running out!” messages and hope for the best.
Things, however, took a turn when I realized I’m going to be traveling and could really use some mobile data.
I called T-Mobile early last week and spoke to an extremely nice individual in Colorado. Things were off to a great start. I explained the situation to him, and he told me that the only way to reset my password was to have engineering do it manually.
ಠ_ಠ
That was annoying, but fine. I was told I’d have an answer in three business days, before my trip started. That was nearly a week ago.
Now, I’m in the position where I want to give T-Mobile money for extra data, but I can’t, because I can’t log in to do so. When you’re a struggling also-ran like T-Mobile, you need to do extreme things like offer free data to get new customers, and get them to pay you. However, all of those extremes are for naught if you can’t get the basics right.
So, now I’ll just give my money to Verizon, since I can’t give it to T-Mobile.
Well, I suppose I could call T-Mobile and read them my credit card information over the phone, but I’m not an animal.
Background
When we recorded next week’s ATP, we realized shortly before show time that our showbot wasn’t operational. Since the showbot wasn’t even our work, we couldn’t really complain. Brad Choate took it upon himself to be kind enough to fork the open-source bot that is used on 5by5. We owe Brad many thanks for roughly a year of faithful and uneventful service.
If you’re not aware, while we’re recording our podcast, it’s also broadcast live. Additionally, we have an IRC
channel (#atp
on Freenode) where we hang out with listeners. In this channel, there’s an automated robot that
listens to the channel for title suggestions. Those suggestions are logged and placed on a page for us hosts to review
at the end of the show. Additionally, listeners can up-vote titles they really enjoy; this lends a completely false air
of democracy to the process.
So, what with the bot being down for that episode, Marco took it upon himself to whip together a really quick-and-dirty showbot using his PHP framework in the span of 20 minutes. It didn’t have an IRC component; it was simply a web page that one could use to suggest a title or up-vote an existing one.
A Challenge
That got me thinking… I wonder if there’s an IRC package for Node?
Spoiler alert: there is.
So, during the after show, I started to hack. Within around the same 20 minutes, I had an IRC bot that was POSTing to Marco’s short-lived web form.
The next day, I spent a few hours hacking on it. While I’m certainly not done with it, I’ve come up with something that seems to be functional.
Thus, I’ve open sourced “Accidental Bot”; you can find it at GitHub, of course.
Getting Cute
As is often the case, recently I stumbled upon a new technology that I really wanted to find an excuse to use. In the past, that has been things such as .NET reflection, LINQ, Cocoa Touch, or iBeacons. In the case of Accidental Bot, however, it was two things: Node and WebSockets.
Node has been mentioned quite a few times in relation to Camel, the engine that runs this site.
WebSockets are something I’ve only been able to play with briefly in the past. The general premise is, rather than having a user’s web browser continually asking the bot “Can you send updates?” on a regular basis, instead, I instruct the web browser to take a different approach. In this case, the web browser opens a connection to the bot, and keeps it open. Thus, as new titles or votes come in, the bot can push those updates directly to all connected users immediately. This is far preferred to having a latency between the time that a vote or title comes in and the time a user sees it on the site.
So, Accidental Bot conists of a few components:
- The bot itself, written in Node.
- The bot’s connection to the IRC channel, to listen for suggestions made there.
- The client page, hosted on this site.
- A websocket connection between the two.
In very quick and brief practice, this seems to work, and work well. What’s on GitHub is the result of less than working day of hacking, and thus, there are plenty of features that could be added, and plenty of bugs lurking beneath the surface. However, when we record next, I plan to have the Accidental Bot running to see if it can handle the load.
Gotcha
First, the titles page is not terribly exciting to look at when the bot isn’t running. And, generally speaking, there’s no point in keeping it running when we’re not recording.
Originally, I would have liked to have hosted the titles page in the same Node server as the bot itself. However, I’m hosting the bot on Heroku. Heroku only allows each dyno to have one port open–in the case of the bot, I need it for web socket connections, and thus can’t open a second port for just plain web connections.
Luckily, since connecting to the bot is done client-side, there’s no reason I can’t host the titles page… anywhere, really. Thus, I looked to the obvious place: the publicly accessible web server hosting this very site.
In a perfect world, I would have opened a web server within the bot and handled sending the static HTML page from there.
I also don’t like that there’s is no persistent storage for titles, should the bot crash during recording. I don’t see the point of rolling an entire database—even NoSQL—for something so ephemeral. However, I can’t even dump a JSON blob on the filesystem because the filesystem is also ephemeral.
Future
Knowing me, as soon as this bot is good enough™, I’ll leave it be and never touch it again. However, there are certainly plenty of improvements that can and should be made.
Nevertheless, my hope is that fledgling show networks may want to build on the work that I’ve done, to help make the experience that much better for their listeners.
In the spirit of Dr. Drang’s “outboard memory”, I’m placing this little tidbit here for my own future reference.
I have an iPad that has LTE. I have two SIM cards for it: the Verizon card that it came with, and a T-Mobile SIM that I picked up for the free data late last year. I generally keep the T-Mobile SIM in it, as I don’t often need data, and when I do, it isn’t much.
However, I’m about to embark on my annual pilgrimage, and as such, am likely to want/need to use data on my iPad. It’s quite likely I’ll need more than my 200MB that I get for free. Thus, what should I do? Despite all the kvetching about Verizon lately, I want to make sure I get the best bang for my buck if I am to buy a one-day, one-week, or one-month data pass from either carrier.
So, I crunched the numbers:
Carrier | Plan | Cost | Cost/MB |
---|---|---|---|
T-Mobile | 500MB Day Pass | $5 | $0.01 |
T-Mobile | 1GB Week Pass | $10 | $0.01 |
T-Mobile | 3GB Month Pass | $30 | $0.01 |
T-Mobile | 5GB Month Pass | $40 | $0.008 |
T-Mobile | 7GB Month Pass | $50 | $0.007 |
T-Mobile | 2GB Monthly | $20 | $0.02 |
T-Mobile | 6GB Monthly | $35 | $0.005 |
T-Mobile | 10GB Monthly | $50 | $0.005 |
T-Mobile | 14GB Monthly | $65 | $0.005 |
T-Mobile | 18GB Monthly | $80 | $0.004 |
T-Mobile | 22GB Monthly | $95 | $0.004 |
Verizon | 500MB Week Pass | $15 | $0.03 |
Verizon | 1GB Month Pass | $20 | $0.02 |
Verizon | 2GB 2-Month Pass | $35 | $0.02 |
Verizon | 6GB 2-Month Pass | $50 | $0.008 |
Verizon | 5GB 2-Month Pass | $60 | $0.01 |
Verizon | 10GB 2-Month Pass | $80 | $0.008 |
Verizon | 2GB Monthly | $20 | $0.01 |
Verizon | 4GB Monthly | $30 | $0.008 |
Verizon | 6GB Monthly | $40 | $0.007 |
Verizon | 8GB Monthly | $50 | $0.006 |
Verizon | 10GB Monthly | $60 | $0.006 |
Some notes about the above:
- “X pass” indicates a non-recurring/one-shot plan.
- “X Monthly” indicates a recurring plan. They must be canceled before the month is up, lest they automatically renew.
- I’m using base-10 representations for data sizes, since the carriers probably do the same. And for easy math.
- The table is sortable, if you click on the headers.
To me, the clear winners are the 1GB week pass on T-Mobile, as well as the 300MB day pass on Verizon. Naturally, depending on the length of your travel and your data needs, your mileage may vary.
UPDATED 29 August 2014 1:30 PM: Changed to reflect new T-Mobile plans.
UPDATED 29 November 2014 7:30 AM: Changed the T-Mobile day pass to reflect the decreased price of $5 (from $10).
UPDATED 6 June 2016 8:00 PM: Updated all prices; added the many new Verizon monthly passes.
Yesterday I had the pleasure of joining my “OTP”, Myke Hurley, on his fantastic interview show, CMD+Space. In this appearance, I talked to Myke about my recent news, Camel, this blog, and blogging in general.
What’s wonderful about CMD+Space is that every episode is worthwhile, and every episode I learn something new. Myke has a great talent for not only picking great guests, but also putting in the effort to ensure that he asks great questions as well. If you’re not a regular listener, you should be.
“Maybe it’s just not supposed to happen for us.”
My wife Erin — the most important person in my world — is feeling somber again.
It’s late 2011. We’ve been trying to have a child for a year now. It hasn’t happened yet.
We’ve progressed past keeping track of her cycle on a calendar. We’ve learned about basal body temperatures and Erin has just started using ovulation prediction kits. Erin has taken more of an interest in the goings on inside of her body than she has ever had to in the past. She doesn’t want to, but she has to. She has to if we’re ever going to be able to have a baby.
We haven’t sought out professional help or anything, but we know it’s taken us longer than it “should”. Something just isn’t right.
“Well, we wanted to have the baby some time in the next year or year and a half, so we started trying. Turns out, we were able to connect the first time!”
I squeeze Erin’s leg.
Hard.
We’re at dinner with dear friends of ours that we’re visiting. They don’t know we’ve been trying to have a baby. They’re incredibly excited to share their news with us.
They should be.
But unbeknownst to them, Erin and I just had that knife in our hearts turn another 30°. The wound immediately gets reopened.
“Well, I’m having fun practicing!”
This is easily the hundredth time I’ve told this joke. I’m not sure if it was ever particularly funny. I know for sure that I don’t find it funny anymore.
I’ve just been asked “When are you two having kids?”. Again. I know the person asking is trying to be nice, and trying to make conversation. Well, unless it’s a family member. Then they really are asking and really want to know why we’re being selfish and taking so long.
I use the joke because it’s disarming, and it forces me to smile. I’m scared if I tell the truth, I won’t be able to smile very much at all.
“We’re pregnant!”
Again, with friends. Again, they have no idea we’ve been trying over a year now.
These particular friends got married in March of 2011. We had already been trying for months before they even got married. We were at their wedding.
Not too long later, they’re pregnant.
Turn the knife.
How is this fair? We’ve been trying since they were planning their wedding, yet they’re able to conceive so easily. It just doesn’t add up.
Erin is putting on the happy face. She’s doing an amazing job. It’s a little easier because she is happy. We’re very excited for our friends. They can’t tell she’s dying inside. No one can tell.
Except me. I can tell.
And she’s dying.
“I think I’m ready to get help.”
It’s late spring of 2013. Erin and I have been trying for two and a half years now. We’ve flirted with the idea of seeing a fertility specialist, but I knew Erin needed to come around to it in her own time. It seems like she has.
It’s a huge step for us, as it’s an explicit admission that we can’t do this on our own. That we need help.
Life seems to happen in stages. As someone who has had a Facebook account since 2004, I’ve seen it. All of my friends got married (we were one of the first). All of my friends got pregnant. All of my friends had kids. We started on the marriage bandwagon before nearly anyone. Erin was a couple months shy of 24 and I was 25. Yet here it is we’re on a treadmill, and can’t progress forward. At this point we’ve been married 6 years.
I stop looking at Facebook daily, like I used to. I rarely look at it anymore. I just can’t stand it; every other post is about someone’s baby. I’m happy for them… I really am. But I can’t see the constant reminder of how we’re falling short. Of how we can’t seem to conceive.
“It’s like driving a used car off a cliff. Every month.”
Erin and I have just left our fertility doctor’s office. Since the actions we’ve taken thus far haven’t really stuck, it’s time to start discussing more invasive alternatives. In our case, that means in vitro fertilization. We talked to our doctor about this for around an hour. It’s worse than we expect in every way.
It’s harder on Erin in terms of time spent, pills taken, procedures she’d have to go through. It’s harder on both of us in terms of a financial burden. Our choices basically amount to driving a used car off a cliff every month, or driving a shiny new car off a cliff once. It’s something we’ve had to prepare for, and we’ve been saving for a while now, but it’s still hard to swallow.
Now having the facts, we talk it over. Simultaneously we curse our poor luck and dysfunctional bodies and yet at the same time we give tremendous thanks that modern science gives us the option of doing IVF at all. We worry about the potential for twins, triplets, or more. While our doctor is very cautious when it comes to “multiples”, it’s still something to worry about.
A lot to consider. As with seeing the fertility doctor in the first place, I think it will take time for both of us to come around to this idea. We may never actually do so.
“I think I’m pregnant.”
Erin and I woke up early, for no particular reason. She has just come back from the restroom, and she looks white as a ghost.
“Wait, what?”
“I think I’m pregnant.”
It’s March 3. Just a day or two before, we were discussing whether or not we want to take the leap of starting our
first round of IVF treatments. Erin shows me the pregnancy test. It’s one of the ones that says the words, rather
than having easy-to-misconstrue lines. Clear as day, there it is: Pregnant
.
We’ve been with our fertility doctor for nine months now. That irony isn’t lost on us. We’ve been getting help, and seeing him each and every month to assist in the conception process. Somehow, by some miracle, it finally worked.
Erin and I are beyond ecstatic to announce that she is pregnant!!
We expect to meet our baby — “Sprout” is our going nickname — in the first week of November. (I should point out we’ve also selected the designated sprout emoji: 🌱)
We’re so extremely thankful, and so unbelievably lucky. We’ve taken a long road to get here. At times, we weren’t sure if we would ever get this far. We’re scared to death of what the future brings. We’re scared to find out if we’ll be good parents. We’re scared that Sprout may not end up healthy, despite every test so far saying he or she is.
Despite that, we’re overjoyed. We’ve conceived. We’re having a baby.
We’ve worked hard at this. Some of it was practice, but a lot of it was work. Even before meeting 🌱, it’s already so amazingly worth it. When we got our first ultrasound, and were able to hear a fast little heartbeat, it was all worth it.
Four years after this journey began, barring any unforeseen complication, it will finally end. We will finally get to meet our Sprout. Our little bundle of pure, unadulterated joy. We’re so excited, we can barely think or talk about anything else.
Finally.

This morning I received a pull request for my blogging engine, Camel. The
pull request had a lot of changes, and they were made with good reason. The primary
purpose was to split up camel.js
. Instead of one monolithic 650 line file, it was
split into a total of four files. This makes sense to me. I instituted some
“flower boxes”, which were controversial, in order to try to demarcate the different
sections of the file. That was already indicative to me that something wasn’t quite right.
I liked the changes. They were an improvement over my monolothic file, and provided for a separation of concerns between different parts of the app.
However, I’m not sure they were right for Camel.
When I was a younger developer, I always aimed to be right about everything. I did what was considered the “best practice”. No matter what. I mean, it’s a best practice for a reason, right?
As I’ve gotten older, I’ve stopped caring as much about what’s best during practice. I’m worried about what’s best in the game. While reviewing this pull request, it occurred to me that it was done well, and done by the book. But that didn’t make it right for my project.
I’ve come to realize, with time and experience, that “best practices” are simply a starting point. They’re there to point you in the right direction. But they’re not designed to be followed letter-for-letter, word-for-word. Instead, you have to do what’s right for your project. You have to be pragmatic.
For Camel, my priorities are to be “fast, simple, and lean”. It says so right on the tin. Splitting Camel into four files just felt like too much. It wasn’t right for my project.
In my case, simplicity is important to me. I wanted Camel to serve not only as the engine for this site, but also as a sample for someone like me—a total Node noob—to learn from.
As always, I think the answer is in the middle. I think that Camel should be split into either two files (routes/helpers), or three files (entry/routes/helpers). It’s only a file or two less, but it’s quite a lot easier to swallow. Doubly so for someone who is new to the code.
And if it weren’t for this pull request, I may not have bothered to really think it through. I’m already so very glad that I decided to get over my fears and open source Camel.
The system works.
As a part of my increased notoriety over the last couple of years, I’ve had many more people paying much closer attention to the things I say, tweet, and post. Many of these people are complete nerds passionately opinionated.
I’ve noticed that as time has gone on, I’ve gotten more and more… let’s call it “feedback”… about my particular preferences. This feedback comes in several flavors:
- Have you considered X?
- Why not X?
- I like X instead.
- [What I like] is stupid. You should use X.
- X? Casey, Casey, Casey.
- X? Are you kidding me right now?
- X? I used to like you.
Of that list, the top two are acceptable. They’re having a conversation, rather than simply making a statement. The next one, “I like X instead”, is a statement, but said without malice. I get all of these a lot, and am not at all bothered by them.
Starting with “[What I like] is stupid. You should use X.”, things take a turn. They’re no longer about having a conversation. They are about shaming. Sometimes shaming with a faint hint of corrective action (“You should use X”). Often times though, they’re simply about shaming. Or sometimes about insulting (“I used to like you”).

The first question I ask myself is, how are these shame-comments helpful?
They’re not helpful. If anything, they’re very preachy. No one enjoys that, outside of your particular house of God, if applicable.
These kinds of comments—“I used to like you”—are also, often times, hateful.
Who wants to be spreading that hate in the world? Especially over something as silly as a way to listen to music, or perhaps a choice of text editors. Who cares if I like Emacs? It works for me, and that’s all that matters.
If this is the price to be paid for me making a name for myself, I’m happy to pay it. Things could be so much worse.
Nevertheless, as I’ve grown older, I’ve realized that the only person getting shamed by a comment like that is the person speaking.
I was asked by my pals Faith and Jason to pinch-hit for Jason on this week’s episode of their awesome podcast, IRL Talk.
Faith and I talked about several things, including Michael Bay’s dubious films of late, Micro Machines, oogling cars, what it’s like to adjust to being a podcast host, the pyramid of methods of communication, and then things get real while we briefly discuss sexism.
It’s a great show in general, and as with the other times I’ve been on, I had a blast recording it.
If you’re at all a fan of ATP, you should definitely check it out.
Today I’ve open-sourced “Camel”, the curiously named blogging engine I use to run this site.
You can find the source at GitHub. It is MIT-Licensed.
The motivations behind Camel are covered both in this site’s about page, as well in my post introducing the site. More technical details can be found on the README at GitHub.
We also discussed it at the end of episode 63 of my podcast.
While the code is a work in progress, I’m curious to hear what the “Node Nerds” think about it. I very nearly didn’t open source it, for fear that I would expose myself as a hack and a fraud. But I quickly quieted those fears by knowing that the easiest way to get better at something is to put it out there in the universe, and welcome whatever feedback you may get.
Check it out, fork it, send me a pull request, and tell me how I can get better. We’ll both be better for it.