Matt Robenolt

Things I Learned About Being a Software Engineer

2014-01-07T00:00:00+00:00

Things I Learned About Being a Software Engineer

Since I started working at Disqus a year ago, I feel that I’ve grown more as an engineer than I have the rest of my career combined.

For the first time in my career, I’ve been spending some time to reflect and look back on what has changed and how I got to this place. There is one critical point that has stood out to me that has changed my perspective on how I tackle problems and interact with our team.

I don’t actually know what I’m doing

I like to think that I’m a relatively accomplished individual. I’ve been writing code in some shape or form for the past almost 18 years. The one thing that I’ve learned is that I actually suck at this programming thing and I have literally no idea how anything actually works.

What?

When I was a young kid and everything was new to me, learning all this shit was an amazing experience. Honestly, nothing in my life has given me the same joy or the same feeling. As I got older, that started to wear off. The foundation of my skills had been laid and I began to hone my skills more and more. Sure, I was still learning a lot, but the pace had slowed down. I sorta figured out what all this code stuff was and things started to actually make sense. I could build new things from scratch and all of that good stuff.

From this point, my confidence started to grow and grow. Up until a few years ago, I was feeling like I was at a pretty high point in my skillset and grew overconfident.

As a result of being overconfident, I started making critical and sloppy mistakes. I stopped asking questions. I knew how to do this, it’s easy! This lead to several critical mistakes and lots of lessons learned.

Since then, I’ve begun to realize that the more I learn, the less I actually know about all of this. And that’s ok. Every time I learn something new, I feel like I’ve opened a door into a brand new world of things I’ve never dealt with before.

Cool story bro, why are you telling me this?

Understanding this has caused me to tackle problems and work with others differently.

1. Make crazy changes, but be cautious

Since I have no idea how anything works, I’ve learned more that anything can happen and I’m probably not really going to understand. I’ve learned enough to be as defensive as possible. Anything that can go wrong, will go wrong and we don’t want to bring down the whole service. Sometimes dangerous and radical changes need to happen, and it’s safer to assume it’s going to fail 100%. So just plan for that, then iterate. Overall my risk assessment skills have skyrocketed as a result of accepting that I know nothing about how anything works.

2. Ask more questions

Other people are smart. Why spend a lot of time trying to figure something out on your own or re-inventing something when someone smarter has done it already? People will gladly help you if you ask enough.

3. Not knowing everything is really fine

I don’t need to know everything to do awesome things. Understanding the risks involved is much more important than actually knowing. Make things up. Have fun. But cover your ass. Nobody is going to complain about a broken experiment if that experiment isn’t affecting anything. Once your ass is covered, try whatever you want! This is the opportunity to learn if your crazy idea is actually meaningful.

Ending thoughts

In retrospect, this realization seems like common sense to me. It has taken me almost 18 years to figure out that computers are really hard and I’ve learned how to embrace it. I hope this insight helps someone out. I’ve been very fortunate in my career so far to have some awesome mentors by my side, and I’m very thankful for having worked alongside them all.

Announcing: Raven.js 1.0

2013-01-27T00:00:00+00:00

Announcing: Raven.js 1.0

If you’ve used Raven.js in the past, I’m sorry. It probably didn’t work well, and you probably ended up with a ton of strange Script Error. logs.

Today, I’m excited to announce a full rewrite of Raven.js with the goal of actually making stack traces in JavaScript meaningful.

Throughout this process, I’ve learned much more about error handling in JavaScript than I’ve ever wanted to, and in turn, learned how equally terrible it is.

One of the goals with 1.0 is, in general, a much better understanding of why things weren’t working right and figuring out solutions, either on our end or yours, to make the errors as meaningful as possible.

Also, from this point on, I’m personally committed to making Raven.js the best tool for debugging client side exceptions, and I encourage sending me feedback and reporting issues and ideas to make the project better. It’s very hard to identify every scenario in every browser alone!

If you are using GetSentry, you can begin trying out the new Raven.js today. If not, you’ll want to upgrade to Sentry 5.3.

I hope you enjoy it!

Resources

Reusable Django Tests

2013-01-21T00:00:00+00:00

Reusable Django Tests

First of all, I think that testing should be accessible to everyone and should be simple enough to just “plug in” some automated tests for common patterns.

Django does a pretty awesome job at encompassing applications. An application may be a blog, or a voting system, or one of many other components that require minimal configuration. These applications lower the barrier to writing larger systems.

These applications come from the idea that a lot of these pieces share the same basic pieces across different projects, e.g. everyone’s tagging system is going to support the same core necessities.

What if we were able to identify common testing patterns and were able to generate tests that automatically introspect and make assertions about our app for us? Then we could just install a new application, apply some basic configuration, and boom! Instant tests without needing to actually write them yourself.

I want to start tackling this problem and begin identifying patterns that can be extrapolated out into their own suite that is just installed and ready to go.

Introducing: Proofread

My first attempt at a solution to this is a project I’ve called proofread. Proofread tests the very basics of any web application: the public endpoints.

Proofread is simply configured in your settings.py to make requests to each of the endpoints on your app, and check that they respond with correct status codes.

What makes Proofread awesome?

Well, anyone can use it, whether you’ve ever written a test before or not, and take advantage of some immediate features.

In my experience, I tend to write a quick layer of tests that I’ve called a “smoke screen” check. This smoke screen would just make sure that the application worked in the most basic sense.

Does making a request for the home page succeed?

That simple question can usually catch accidental SyntaxErrors or missing import statements. Too often have I see someone do a really quick fix and forget to import the file needed resulting in someone else cleaning up the broken commit.

What’s next?

I’m going to be researching and experimenting with automating some tests for other common aspects of Django. I think my next attempt is going to be introspecting Forms and automating a test suite for validation.

I’d love to hear thoughts and opinions on this topic!

Resources

https://github.com/mattrobenolt/proofread

Handle X-Forwarded-Port Header in Django

2013-01-02T00:00:00+00:00

Handle X-Forwarded-Port Header in Django

When running on a non-standard port, and behind a load balancer/proxy, it has become “standard”^[1] to forward along a header called X-Forwarded-Port.

This header is very similar to X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-For in the sense that it’s forwarding relevent information about the originating request and telling your backend to ignore the values it’s aware of.

In this case, X-Forwarded-Port is not supported by Django natively, and the easiest way to handle it is through a simple middleware:

class XForwardedPort(object):
    def process_request(self, request):
        try:
            request.META['SERVER_PORT'] = request.META['HTTP_X_FORWARDED_PORT']
        except KeyError:
            pass
        return None

This will allow urls to be properly reversed with the correct port as you’d expect.

References

https://gist.github.com/4439597

Footnotes

^[1] I use quotes because nobody has a fucking clue what’s really going on with this shit. There isn’t a standard, just an idea that a few people started implementing.

American Express iOS6 Passbook Security Flaw

2012-09-28T00:00:00+00:00

American Express iOS6 Passbook Security Flaw

This morning, American Express announced that you are able to bring in your card into Passbook for iOS6 via Twitter.

Upgrading to #iOS6? Add our Apple #Passbook Pass using Safari for auto acct notifications + more aexp.co/vn0 bit.ly/Uy5MmR
— American Express (@AmericanExpress) September 28, 2012

Immediately, I try it out. Awesome.

I open up Passbook, and see my balance and a list of recent transactions. Awesome again.

Then I realized what I had to do to get this Passbook file which exposes some relatively sensitive account information.

The link that Amex posted is just a form, that asks simply for first name, last name, email address, credit card number, and CID. All information that anyone who has ever touched my physical card had access to.

You enter in the information, and you’re giving a .pkpass file, which is really just a fancy name for a zip file. Extract it, and inside you’ll find a pass.json file, which looks something like this:

{
    "authenticationToken": "...",
    "generic": {
            "key": "recentActv",
            "label": "RECENT ACTIVITY",
            "textAlignment": "PKTextAlignmentNatural",
            "value": "..."
        }],
        "primaryFields": [{
            "key": "name",
            "label": "",
            "value": "Matthew R."
        }],
        "secondaryFields": [{
            "key": "outstandin",
            "label": "Outstanding Balance",
            "textAlignment": "PKTextAlignmentLeft",
            "value": "$..."
        }]
    },
    "organizationName": "American Express",
    "passTypeIdentifier": "pass.com.americanexpressdigitalpartners",
    "serialNumber": "...",
    "teamIdentifier": "...",
    "webServiceURL": "https://americanexpressdigitalpartners.com/pass"
}

So, without entering any password or logging into my account, I can generate a list of recent transactions and an account balance.

And last, from my understanding of how Passbook works, is that new transactions are pushed to my device. So any future transactions will be updated in semi-realtime.

American Express, this is awesome and all, but PLEASE secure this page inside my account page after I’ve logged in, or add it to your iOS apps directly.

The Django ORM & Subqueries

2012-09-26T00:00:00+00:00

The Django ORM & Subqueries

Note: At the time of writing, Django is at v1.4.1

So what actually happens when you have a Django query like the following?

cities = City.objects.all()
venues = Venue.objects.filter(city__in=cities)

Django is smart enough to know that you want to use the results from the first unevaluated QuerySet as the input for the __in clause, and in turn, generates a subquery. The raw query generated is something like this:

SELECT ...
FROM   "venue" 
WHERE  "venue"."city_id"
IN (
    SELECT U0."id" 
    FROM "city" U0
)

Awesome. Django saved us an extra round trip by inlining the query instead of evaluating the first query separately.

What’s wrong?

In this scenario, nothing at all. We’ve saved a round trip to the database, all is good. Let’s throw caching into the mix.

cities = cache.get('cities')
if cities is None:
  cities = City.objects.all()
  cache.set('cities', cities)
venues = Venue.objects.filter(city__in=cities)

In this scenario, we want to cache the entire list of cities. The City QuerySet gets cached for us like we expect, but when Django gets to the filter(), it sees that you’re passing it a QuerySet and generates a subquery again. We’ve effective cached nothing because the exact same query is being run.

This also applies when you want to use the same __in across multiple filters.

cities = City.objects.all()
venues = Venue.objects.filter(city__in=cities)
users = UserAccount.objects.filter(city__in=cities)

Again, the exact same subquery is repeated across both queries.

Well, how can we fix this?

The reason why Django is doing this is solely because the argument passed into filter() is a QuerySet. If we just pass a list, Django will use an array of ids inside the IN SQL.

Let’s look at an improved version with caching.

cities = cache.get('cities')
if cities is None:
  cities = list(City.objects.all())  # Force query evaluation
  cache.set('cities', cities)
venues = Venue.objects.filter(city__in=cities)

The only thing that has changed is forcing the QuerySet to be evaluated by converting it to a list. Now, cities is a list, so Django won’t try to perform a subquery anymore. This could be simplified to just caching the primary keys as a list as well, depending on what you’re trying to achieve.

The resulting SQL will be something like:

SELECT ...
FROM   "venue" 
WHERE  "venue"."city_id"
IN (
    1, 2, 3
)

One more gotcha!

We all know that Django’s QuerySets are lazy, right? No query is actually performed until the QuerySet is iterated over. Once a QuerySet has been iterated over, it won’t query again for the results. The results get cached into an internal _results_cache object.

At the moment, Django is not smart enough to detect that a QuerySet has already been evaluated before generating a subquery, effectively causing the query to be run again when we already know the results.

Picture this scenario:

cities = City.objects.all()
names = [city.name for city in cities]  # QuerySet cache is filled
# ... do something awesome ...
venues = Venue.objects.filter(city__in=cities)

Since we’ve already evaluated the QuerySet before passing it to the __in clause, it’d be smart to just use the ids that we’ve already calculated from before, but it doesn’t. So pay attention and be careful.

I’ve submitted a patch to Django core to try and get that behavior fixed:

Making shit is hard.

2012-09-19T00:00:00+00:00

Making shit is hard.

I procrastinate a lot.

I find it very difficult to commit to doing work for myself. It’s very easy to get wrapped up in doing work for other people, and it’s just so easy to say, “Eh, I’ll get around to it,” when it comes to personal projects.

A blog has always been at the bottom of my TODO list. I’ve had elaborate, complicated ideas for things I wanted to make custom that end up being so monstorous, that it gets in the way of what my main goal is: write some shit and have people read it.

I hope to share some of my experiences as a software engineer, and help a few people along the way.

This blog is currently being built with Jekyll, and hosted on GitHub.

Hopefully this won’t be as hard as I’ve convinced myself it would be.