Swift Pair Programming – Session 6


Last week Nick and I took another run at OAuth2 in Swift. Hawaii isn’t affected (neither fall nor spring) by Daylight Savings Time. I called him an hour early while he was still driving back from work. Once we determined why the scheduling was incorrect, we reconvened and dove back into OAuth with Swift.

Unfortunately we weren’t able to get the application to authenticate. After the first run through, I looked deeper into the actual OAuth process. I have a better understanding of the delineation between Consumer Keys and Consumer Secrets versus the Access Keys and Access Secrets.

I suspect that we are unable to connect because we are using an open source library to connect to Twitter that was actually written to use OAuth to connect to github. The list of attributes necessary for the connection are different from the way we are meant to connect with Twitter.

As our pairing time was winding down, we did two things. We searched for another open source OAuth repo to test with. We also talked about how we both don’t really understand lambdas.

“Wait, have you heard of this fucking website for Swift closures?” Nick asked.

Thinking I hadn’t heard him correctly, I said, “No.”

He was already sharing his screen and opened up Safari. He started typing in the url, “fuckingswiftblocksyntax.com” and I couldn’t help  laughing. Once we finished typing the url I couldn’t hold it in. And laughed for an uncomfortably long time 🙂

To put this in context a few weeks back he shared a JSON parser called Freddy. Their tagline is:

“So, Freddy vs. JSON, who wins? We think it is Freddy.”

You have to add some levity to this profession that sometimes feels like crafting concrete skyscrapers with steam. That’s the thing about the profession. There’s nothing tangible. We’re working with electricity. Making it to magical things. And it could break at any time.

Nick also mentioned a testing framework that was developed to allow debugging inside the simulator but I can’t remember it now. I made a note to myself to ask him tomorrow.

This weekend I successful set up push notification in my app. Hemingway was famous for saying that when he was writing he would always stop at a place where he felt he could easily get back into the groove the next day.

As I get more and more experience developing I find myself forcing myself to stop as soon as I have made some serious project after a full day of working. Knowing when to stop to avoid burn out is a hard lesson to learn, an even harder rule to follow, but a worthwhile lesson in humility, patience, and love of the craft.

Author: David Neely

Professional Software Developer. Technology and Web Coordinator at the University of Hawaii's Manoa Career Center.