As Summer rolls around each year, smart and talented students looking for a good reason to stay in Santa Barbara apply for summer internships. This summer Daniel, a final year Physics student from UCSB joined out development team. Daniel was fun, hardworking and dedicated — everything you could hope for in an intern. To cap off his time with us, we tasked him with writing about his FollowUp.cc journey. We loved it so much, that we decided to share it with you. Enjoy this guest posting by our dev intern, Daniel.
“Yeah, I can Integrate Evernote with a Rails Application”
At least, that’s the gist of what I said 6 weeks ago, just 3 weeks into my first software development internship. My name is Daniel, and last year I was an student at the University of California, Santa Barbara. I was searching for something to do over the summer, and having experience in web development I decided that I’d try my hand at programming. I was lucky enough to get accepted by the dev team at FollowUp.cc.
One of the nice things about working for a small company is that you get to hit the ground running. My boss was the CTO, and he threw me into the app immediately. When I walked in the door I knew nothing about ruby, but within a few days I was building mailers, web pages, and learning the nuances of a Rails MVC backend.
It was about 3 weeks in when I started getting cocky. There was talk of developing a heavily requested integration with Evernote, and I volunteered for the project. I set to work, learning and coding as I went.
My first task was to OAuth with Evernote. I spent the first few days reading, coding, and cursing. I had no idea what I was doing. What controller action should I map this to? Where do I post the request? What even is OAuth? Good times. Eventually I figured it out, and managed to create a passable OAuth scheme.
Next up, it was time to flesh out the flow of the integration. I decided that our process would be simple; get an email from the user, and create a note out of it. I’d attach all the information I needed to create a model instance to the note, and then wait for a webhook, which I’d use to build the model instance. Of course, this flow meant sending data through a foreign server, which I figured wouldn’t be a big problem. Big mistake.
After building out the whole integration under that flow, I realized that the Evernote servers simply couldn’t be relied on: API calls would fudge the data, and Evernote’s XML format exacerbated already daunting issues. After spending a few days trying to force my original flow to work, I realized that I needed to rethink everything. Queue a total refactor.
1000 lines of code later, I had fixed the flow. Now I was only sending the barest amount of data through Evernote. I had two flows that created model instances, each weaving out of each other beautifully. After cleaning up all the excess code leftover from my first attempt, I finally had a working product. It was time to test!
I’m pretty convinced that it’s a law of coding that a newbie’s code shall never work the first 100 times. This was certainly true for me. It took me another week to fix all the bugs, work out the kinks, and get the edge cases under control. Let’s try again!
I submitted a pull request, and waited for my CTO to review it. He began testing it, and everything broke.
After examining the issue, I realized that I’d pulled a newbie and accidentally merged a coworkers branch into my own, effectively corrupting my branch with random code snippets. An awkward git reset and a ton of editing later, we were once again good to go.
At long last, it was time to push to production. We ran the migrations, set up some configurables, and began testing again. Of course, nothing worked. A frantic hour followed, and at last I discovered the problem. I’d forgotten to move the webhooks to the new URI. One facepalm, two emails, and two days of wait time later, the FollowUp Evernote integration was prepped for launch.
So what did I learn from all of this?
For a big project like an integration, making a poor planning decision can mean adding weeks to development time as a result of poor flow, buggy code, and inefficient methods. Take the time to understand the details of the code, and run your flow by fellow developers. Chances are they’ll catch something you missed and save you weeks of effort.
When working with a foreign API, take the time to read the bloody documentation. Don’t skim it, don’t skip it, and don’t ignore it. If I’d read a few documents a little more thoroughly I could have saved myself hours of coding. Don’t be afraid to spend an extra hour reading; it will save you time in the long run.
It’s easy to forget how fun coding is. When you’re sloshing through a wall of code that just won’t work, it’s easy to get demoralized, frustrated, and confused. We all got into coding because we love it; we love the thrill of creating something new, of building applications, of designing UIs that help people live better, more productive lives. Just remember to take a step back, take a break, and don’t give up!
As my internship draws to a close, I find myself becoming almost nostalgic. I built some beautiful things here at FollowUp, and met wonderful, driven people. So I’ll let the sappiness flow, and say that this experience worth it. If you ever get the chance to work at a small software startup, I recommend taking the risk: it’s definitely an experience I wouldn’t want to miss.
Thanks for sharing Daniel! It was great spending time with you this summer. Come back anytime and keep coding.