Programming is about Interfaces, and not just the graphical ones, EuroPython2011 post 1

If you program, you create interfaces. And I don’t just mean the graphical user ones. All software is broken up in functions, methods, modules, plugins, etc. All pieces of software are used by other pieces of software. Every programmer’s code is used, sooner or later, by oher programmers. In the very least, it is used by himself. Also your future self, and your future self may not necessarily understand you as well as you hope. And why not make other programmers’ life, or your own life, easier, with better API design? Faster said than done, obviously, and I have a world to learn, I know that. Not going to happen overnight, though. All I can do is improve a little bit every day. And this EuroPython2011 conference has helped me start understanding the importance of that effort.

Application programming interfaces, also known as APIs, are everywhere. Google even has an API for APIs, and don’t call it meta. And application interfaces certainly were everywhere at this year’s EuroPython conference in Florence.

Alex Martelli‘s talk on good API design opened the conference, and Raymond Hettinger followed on the second day with his explanation of API design and the lessons learned. The API acronym kept showing up in titles, including Ali Afshar‘s “Latest advances in the Google APIs platform” and Johan Euphrosine‘s “Web API Mashups in a Python Application“. I missed out on “An iPhone-Python love affair: Building APIs for mobile” by Anna Callahan and Nate Aune.

Other talks didn’t have the word API in the title, but the subject could be read in between the lines, like at the Design Patterns talk by Alex Martelli (as Anna Ravenscroft noted, the Facade pattern was very API like). Or when Raymond Hettinger changed our view of Subclassing. And Wesley Chun talked about creating your own types that act just like Python types. The ZeroMQ talk by Francesco Crippa made me think about giving my applications a better way to talk between themselves (ZeroMQ is to sockets as Python is to C++, apparently).

Sad about having missed all of that? Don’t be! Watch the videos. Click on the title at the Schedule website, and watch. As easy as that! For some of my notes, click “Continue reading”.

I’ll use my tweets from EuroPython and my paper notes to help me put this post together.

“Alex Martelli API anti-patterns,avoid: No API. No design, API just happens. Wrong/no documentation. Lang specific data exchange #EuroPython

If worrying about not being able to make a good API is paralyzing you, take Martelli’s advice: the worst mistake is no API at all. Because APIs just happen anyway, you can’t prevent that. So it’s best to plan. Same applies to documentation. If you don’t like writing documentation or are nervous about not doing a good enough job enough to keep postponing it, at least write code use examples. Those can be even more useful for programmers.

“Incremental design is great, but Big Design Upfront is recommended for: #Privacy / #Security and #API design. Alex Martelli at #EuroPython

What can I add?

#Scrapers +imitating user interaction in demand, see Stackoverflow. #APIs reduce extra work and save resources. Alex Martelli at #EuroPython

Jedi tricks are fine but should not be necessary as often as they are. By Jedi tricks I mean the “these are not the droids you are looking for one”, that is I am talking about having to pretend to be a program like a browser or a graphical user interface to access information and functionality that you need and have a right to. What’s wrong with being able to automate routine data retrieval tasks? Isn’t IT about that, mostly? Well, it’s not that the world is necessarily completely against scrapers and user interaction simulators, but that sometimes the world doesn’t want to put in the effort to design an API. Hope this changes with time. Programmers’ hours, energy and nerves will be saved. Also the machine and network resources.

Decide what to expose (#API design) or expose inner workings. And if you want to improve those later? Alex Martelli at #EuroPython

APIs happen anyway. And if you let others’ just randomly pick at your code or look at your internals, how will you make changes later on? And improvements? Innovation? Think about it.

“You’re not done with your class if you haven’t tried to subclass it. Like forgetting leaky roof until rain. Raymond Hettinger at #EuroPython

Subclassing is the ultimate API challenge. I mean, if you are designing your code for other’s to use, than consider subclassing issues as well.

“Hettinger on APIs – extendable but protected from damage. So modifying __setitem__ doesn’t change update. __local_setitem helps. #EuroPython

If one changes the method that sets the item, will that automatically affect other functions that call upon it? Be careful about that. Hettinger explained it in detail. We could say that the Hettinger API talk offered some very concrete and interesting advice, watch the video if you are interested.

“No problem? Get icecream. Unsolvable problem? Get icecream. Solvable problem? Design Patterns. Martelli at #europython” (RT from Anna Ravenscroft)

APIs are about writing code for other programmers to use (or your present and future self). I keep hoping it is easier to understand each other if one uses design patterns. I keep hoping that some day I’ll figure out and learn and use patterns. And do it well.

Ali Afshar‘s talk on Google API platform, which is really an infrastructure, was pretty fun. Hard to some up now. APIs for APIs. One API to rule them all. What more can I say?

Enough blogging for today. Some of the issues I mentioned here will be explained in future posts. See you in the next episode then!


About apprenticecoder

My blog is about me learning to program, and trying to narrate it in interesting ways. I love to learn and to learn through creativity. For example I like computers, but even more I like to see what computers can do for people. That's why I find web programming and scripting especially exciting. I was born in Split, Croatia, went to college in Bologna, Italy and now live in Milan. I like reading, especially non-fiction (lately). I'd like to read more poetry. I find architecture inspiring. Museums as well. Some more then others. Interfaces. Lifestyle magazines with interesting points of view. Semantic web. Strolls in nature. The sea.
This entry was posted in events, python and tagged , , , , , , , , . Bookmark the permalink.

2 Responses to Programming is about Interfaces, and not just the graphical ones, EuroPython2011 post 1

  1. Interesting and insightful, as usual. Just one thing wasn’t that clear:

    “Google even has an API for APIs, and don’t call it meta.”

    Care to expand this concept? It’s not entirely clear what you want to convey; looks to me that a X on X is, with no exceptions, a meta-X, so the statement must have some connotation I did not grasp.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s