AO3 News

Post Header

2011-06-15 10:43:27 UTC

As part of our series giving an insight into what goes on behind the scenes at the AO3, coder Enigel has written up a day in the life of an AO3 coder! Enigel has been coding for the AO3 since November 2008. She studied computer science at university and works in the tech industry, but had never worked with Ruby on Rails before volunteering with the AO3. She started out tackling small bugs and has progressed to more challenging tasks - she is now one of the more experienced members of our team and is currently battling with the intricacies of our site Javascript.

I open up my archive coding tools, which are:

  • My webdev - a web-based development environment which hosts all the things needed to run the Archive, including Ruby on Rails, a MySQL database, and the Archive code itself. We used to install all this stuff on our own computers, but as the site has grown that got unmanageable for most people (especially those of us who are on Windows...), so the web-hosted version is much handier! I can see the working site and my changes at my own dedicated URL.
  • A git bash console - a command line tool which lets me upload code changes to our code repository on Github
  • Notepad++ - a text editor specially designed for editing code, which has some nifty features like syntax highlighting and line numbers
  • A Putty SSH console - a command line tool which lets me communicate with the webdev to get new code, run commands, etc
  • The Google code issue tracker - where we keep track of things which need to be worked on.

I sort the issues by priority - argh, a Critical one. I've tried to investigate it before, going from file to file to track what is defined where, and arrived to a thicket of code, deep in the forest where the Wrangulator meets the works model and controller (aka Mordor). No, today is not the day either.

Sometimes, I would just pick another issue, by priority, or by relevant interest - I'm only human after all. But today I choose a different path. Today, I will vanquish ALL the errors! We have an error notifier, which collects info about all those "Something went wrong" black holes where your pages sometimes get to, and sends emails to the Coders list. We have quite a collection. I load the page and go on chasing after those that occur most frequently, in the hundreds.

I spot a weird one, that only seems to happen for a particular browser: Sony PlayStation Portable. What's going on there? First I want to make an automated test. This is good practice in general, and vital in particular, because I don't own a PSP.

OK, how on Earth do I test this? It's pretty easy to simulate visiting a page - not so easy to simulate the peculiarity of a certain browser. Google, Stackoverflow, Google, forums, email lists. Aha! I find someone else's solution for testing sending a certain header in the browser request. I copy that in my test, and there it is! The red dots of a failed test! \o/ (Yes, this is a good thing. *g* It means I can reproduce the error in a controlled way.)

Putty console window showing a line of red dots as a failing Cucumber test runs

Now, how to fix this? Google, Google, forums, code snippets, aha! It's a bug in Rails itself! Oh, the sheer joy of being able to say "It's not us, it's them!"

And there's also a monkeypatch available - a monkeypatch is a temporary fix, applied on top of existing code, meant to go away when the bug is fixed officially.

I add the monkeypatch, run the test - it is now green! \\o//

Putty console window showing a line of green dots as a passing Cucumber test runs

I run ALL the tests, because it's important to verify that I haven't broken something else in fixing my bug. The tests run. And run. And run. I grab some chocolate, because I deserve it, and after almost half an hour, the full test suite has finished. All green! Hurray!

I feel a bit tired, and glance at the clock - good heavens, when has it become 2am?! I push the code to my repository on GitHub - this means that the changes I have made are now saved on my personal branch of the code, and other people can see and download them. I make a pull request for that code to be grabbed in the official master branch, and... I should go to sleep. Really.

But there's another very frequently occurring error... It means hundreds of times that people have tried to load listings for various fandoms, and they got "Something went wrong" instead. And this time, the latest error is for one of my fandoms! Now this, this is personal.

I make a new code branch on Github, so that I can have a copy of the code which includes only my changes for this issue, not anything else I might be working on. I write a test. It's easier to write one for this scenario, so armed with the failing test, I start digging through our code. Aha, there are about three files involved in this. I know exactly what needs changed. I rub my hands together in glee...

...Or do I? There are always several ways of doing pretty much anything with code, but not all them are equally advisable. Luckily, there are some senior coders in the Coders room, and I pester them for ideas. I could test the parameters here, or I could do it in this other place, or even in three different places.

Obviously, a more general solution is generally (ha!) preferred. We arrive at a rather good consensus, a cleaner way - and one I hadn't known was possible. Yay, I've learned something, too!

It's a bit more involved than the other ways, but it's more rewarding. I code the changes, upload them to my webdev, launch the test. I test manually, in the browser, too, because this bug is easier to reproduce and test manually. (Unlike, for example, bugs with Gift Exchanges, for which you have to set up a whole challenge and find people to test with you. Ask Cesy about them sometime.)

Oops, errors all the way.

I fiddle with the code some more, I poke at it some more, rinse and repeat until - huzzah! - the test spits only green dots, and the page loads fine in the browser. Hurray! I push the code, I make a pull request. It is now 4am. I not so much go to sleep as ooze into bed.