I’m at the API Strategy and Practice Conference here in Chicago, where Kin Lane and Kirsten Hunter have kicked things off with an “Introduction to APIs” workshop. Despite its title, the talk had value for API developers beyond the absolute beginner level. Although the two did an excellent job of explaining what an API is for someone who doesn’t know, the most valuable elements of the talk for someone who has made and used APIs, but wants to get better at it, were the cornucopia of resources that Kin recommended in his portion of the talk and Kirsten’s ______ in her portion of the talk.
Last month, I had the experience of building out an app on an extremely tight time schedule. The rapid-fire development, while exciting, left me with technical debt to pay. Luckily, I’ve had the extremely good fortune to work with a master of refactoring and code maintenance, Coraline Ada Ehmke, as I learn how to clean up my controllers, detect problems, and write a tight test harness. I wanted to pay it forward and share some of the lessons that I am learning from her in our process of building code together.
I’ll go over some things that I learned in our last session, with examples:
- controller methods: form and function
- code smells: method names and variable names
- Hash methods: zip and inject
- An array method: map
- “Or Equals”: an introduction to caching and an elegant alternative to instantiating variables outside of loops
- Sugary Ruby syntax: &:, ?, and ranges (they’re not just for integers!)
Extreme Programming, or XP, encompasses a set of values, principles, and practices for software engineering teams to increase productivity, decrease waste, and improve predictability on their software projects.
If you’re looking for the Cliffs Notes, this is definitely not your blog post. Rather, it’s a short selection of salient points from the book—namely, points that piqued my interest enough such that I would like to learn more about them than what is contained inside it.
Addendum: to see, copy, and run the code itself, you can pull from https://github.com/chelseatroy/acled-data-webclient.
Thank you to Sajal Sarkar for the image: http://www.eolikes.com/jquery/chart-js-simple-html5-charts-plugin
an application utilizing Chicago open data to produce narrative on crime in any Chicago neighborhood.
The app takes mountains of Data about Chicago crime and presents a story based on a specific neighborhood, which you can specify on the homepage.
This Tuesday at lunchtime, Brian Kung spoke at the Groupon Chicago office on W Chicago Avenue to talk about how his dance practice has contributed to his programming. The talk ended up focusing on, in my view, two groups of ideas:
- similarities between the dance community and the programming community
- the elements of character that contribute to becoming a good dancer/programmer
I’ll discuss the concepts introduced in the talk within each of these categories.
This synopsis is a guest post by Matt Hucke (@matthucke), a developer at AutoAccessoriesGarage.com and one of the first people I met this year at Windy City Rails! It covers Justin Love’s talk on SQRL.
Shared secret password security is “rotten at its core”.
With a memorable image involving monkeys sharing far too much, Justin Love (@wondible) exposed the fundamental problems of typical web site password setups. What we want in an effective authentication system, he says, is unique identities, not reused from site to site, to protect us from the inevitable breaches that are far too frequent these days. A hack of Target or iCloud should not result in our email accounts also being compromised – for users will reuse passwords across sites, no matter how often we tell them not to.
This afternoon at Windy City Rails, Matt Polito of HashRocket gave a talk called “Why Cucumber is Still Relevant.” For those who haven’t used it, Cucumber is a gem used in conjunction with writing tests in a rails application that provides a domain-specific language for describing and documenting what the application is supposed to do.
He brought up this article by Martin Fowler, which poses a question:
Will DSLs allow business people to write software rules without involving programmers?
He ends up answering this in the negative, but instead identifies the value of making software business-readable rather than business-writable.