Object Oriented Toastmasters

Last night I did a somewhat impromptu speech at my toastmasters club. Looking through past presentations, I saw ones on OOP and Class vs. Prototypes. Trying to condense a longer talk into something understandable by a non-technical audience was clearly out of the question, so Tried to present only the basic principals of OOP in terms they would understand. Given it was an un-rehearsed speech, the words recorded here are likely very different than the speech itself.

Greetings fellow toastmasters, and honored guests. Tonight I would like to explain a somewhat technical and abstract programming topic. I hope that I will be able to do so in terms that may be more familiar to you.

Object oriented programming has a long history, developing through many people and ideas. One of the best known pioneers was Alan Kay. Alan Kay had a lot of interests, including teaching programming concepts, to children as well as adults. One of the systems he developed was called, Smalltalk, which has become one of the iconic early object oriented systems.

Before we get into Kay’s definition of OOP, I should clarify “objects”. An object is an an abstract notion of one particular piece of a programming system. For tonight, our objects of discussion will be toastmasters and roles and officers they fill.

Alan Key defined object oriented programming as having three key qualities: encapsulation, genericity, and messaging.

Encapsulation means the object has secrets. It knows things about the program’s state and processes so that the rest of the program does not have. By keeping information encapsulated, we hope that programs are shield from small changes causing the whole system to fall apart.

When a toastmaster wants to pay his dues, he knows to pay the club treasurer. The member does not need know which bank we use, or the club’s account number. The treasurer encapsulates that information. Going further, the treasurer does not actually keep the account – he communicates with the bank, and does not need to know every detail of how the bank manages it’s accounts. Keeping this information separate makes it easier for us to change treasurers, or for the club to change banks.

Genericity means we don’t have to know the exact identity of an object – or a toastmaster – up front. When a member joins the club, he doesn’t need to know the identity of every treasurer that he will pay during his term with the club – it is sufficient to know that a treasurer will be available who can fulfil the required duties. Likewise, Toasmasters International does not need to know the exact identity of every officer in it’s thousands of clubs in order write the rules that govern the duties of those offers.

For Alan Kay, genericity ment specifically “extreme late binding”, something we all too often practice with our meeting roles. Many of the meeting roles are filled when we arrive at the meeting. We didn’t need to know all those identities to write up the agenda at all – just that someone would be available who could fulfill that role when it came time.

Messaging means that objects communicate with small, fairly abstract messages. Messages express a request, not a detailed set of instructions on how to perform that request. The agenda tells me as president to “open the meeting”. It does not prescribe the manner in which I do so or the exact words to use. While Toastmasters does have some extensive rules and recommendations, I still have control of how I respond to a message.

Messages may have parameters. So for opening the meeting I might receive a list of guests to greet, but I still choose exactly when and how to do so.

I hope I’ve been able communicate some basic principles of object oriented programming, and do so in terms that you can understand. Perhaps if you find yourself facing a large, complicated system, you might try applying encapsulation, genericity, and messaging to the problem.

Leave the first comment

Nothing to Lose: Getting Rid of Shared Secrets with SQRL at WindyCityRails

Passwords in actual use are commonly weak, hard to enter, reused, and forgotten Even if the user interface concerns can be dealt with, the fundamental technology is still shared secrets – which put both the user and the application in a position to lose control of those secrets. This becomes a major issue during database compromises, and is magnified manyfold by the prevalence of password reuse.

“Secure, Quick, Reliable Login” is a proposed technique to replace username/password login, as well as third party logins providers. SQRL (pronounced “squirrel”) provides an extremely user-friendly day-to-day workflow – the user simply scans a QR code on the page using a dedicated application, verifies that it refers to the correct site, and is then logged into the site. Other client options include clicking or tapping a link to run a local plugin or application.

SQRL uses sound and proven public/private key cryptography to provide a user-centric, fully decentralized system with an extremely easy day-to-day workflow. The only secret information is held by the user, which provides no place for third party tracking and insulates users from data breaches at service providers.

Comments Off

iOS Development Concerns

I had occasion to list all of the struggles I’ve been having with iOS lately. Maybe this will draw some advice.

RubyMotion development in general. The ruby layer isn’t a big deal, but Cocoa is huge, as is the iOS platform in general. Most reference material is written assuming you’re using all the XCode shortcuts, so it can be a challenge to track down information on doing things the hard way.

Application architecture. There are no complete real-world iOS projects on Github; what examples do exist are toy applications, with limited scope meant to illustrate a specific feature.

Database management. I’ve picked up that I should be using Core Data. It took a while to get straight, but I’ve got something that seems to be working okay for the time being. Are there issues that will come back to bite us later?

Data synchronization. I spent a lot of time thinking about how do this in a sane way. At the moment, new records are sent incrementally to the server, and a full-download is performed to ensure the client has a consistent state. I expect this to change. I have an interface that will hopefully isolate most of the application from changes in the syncing strategy, but there are still major features to be implemented, e.g. some records will be editable, and there aren’t actually multiple clients making concurrent changes yet.

API Versioning. Probably one of the next things that needs to be cleared up. Getting a version number in should be straightforward, but unlike database versioning, I haven’t forced a test case, and even then there aren’t old clients hanging around trying to access an old api that needs to be maintained. (of course I’m not testing DB jumps of more than one version either)

Custom views everywhere. It feels like I need half a dozen custom views for every screen, making every screen a long slog, filling in elements piece by piece. State and events have to move up and down the view hierarchy, and it seems like I’m defining glue methods at all the intermediate levels. Autolayout seems really verbose, but unspecified dimensions are unspecified, and who knows what they’ll do in the future.

Layout updates. There is a current issue where the certain cells don’t update their size when the finishes downloading. Might be something simple, but I know I’ve spent time on it before.

Image sizing. I took in an image a certain resolution, scale 2, and couldn’t get out a modified image at the same resolution and scale 2. I found a combination that drew to the screen in the desired size, so it may not be worth spending any more time on.

Comments Off

A SQRL Took my Passwords at RailsConf

“Secure, Quick, Reliable Login” is a proposed technique to replace username/password login, as well as third party logins providers. SQRL (pronounced “squirrel”) provides an extremely user-friendly day-to-day workflow – the user simply scans a QR code on the page using a dedicated application, verifies that it refers to the correct site, and is then logged into the site. Other client options include clicking or tapping a link to run a local plugin or application.

SQRL uses sound and proven cryptography to provide a user-centric, fully decentralized system with an extremely easy day-to-day workflow. The only secret information is held by the user, which provides no place for third party tracking and insulates users from data breaches at service providers.

Comments Off

SQRL: Solving the Login Problem at Software Craftsmanship McHenry County

“Secure, Quick, Reliable Login” is a proposed technique to replace username/password login, as well as third party logins providers. SQRL (pronounced “squirrel”) provides an extremely user-friendly day-to-day workflow – the user simply scans a QR code on the page using a dedicated application, verifies that it refers to the correct site, and is then logged into the site. Other client options include clicking or tapping a link to run a local plugin or application.

SQRL uses sound and proven cryptography to provide a user-centric, fully decentralized system with an extremely easy day-to-day workflow. The only secret information is held by the user, which provides no place for third party tracking and insulates users from data breaches at service providers. A little bit of complexity creeps back in to the protocol for reclaiming a compromised ID, but this should be a extremely uncommon occurrence.

Comments Off

Git Q&A at ChicagoRuby

This has two main features. It starts with a brief conceptual overview of how Git works, and then uses that as a basis to talk about a couple of common questions. The presentation was mostly visual support, so the answers aren’t always in the slide deck.

This is the same as the FVCP presentation from the past week; a speaker dropped out and I happened to have this ready.

Comments Off

Git Q&A at Fox Valley Computing Professionals

This has two main features. It starts with a brief conceptual overview of how Git works, and then uses that as a basis to talk about a couple of common questions. The presentation was mostly visual support, so the answers aren’t always in the slide deck.

Comments Off

National Day of Calendar Hacking

I went solo for National Day of Civic Hacking. I attempted to run an unofficial event at the Elgin Technology Center but I put off the marketing and partnerships too long. Summer seems to be tough for suburban groups – several of the meetups go on hiatus.

Project 1: Elgin Area Chamber calendar

This may have been a little bit of stretch for civic hacking, but having to browse to the Elgin Area Chamber events page every week to see if there were any events that fit into may schedule was kind of a pain. So I built a program that scrapes the chamber events page and produces an iCalendar file which allows you to download elgin chamber events or subscribe to elgin chamber events

This took about half of Saturday.

Project 2: Farmers Market calendar

I had been wondering if tracking local farmer’s markets would be an appropriate activity. My fears were put to rest when I saw that an official challenge to hack farmer’s markets had been posted.

I originally wanted to do something with Disk Clock‘s week view, but the USDA Farmer’s Market Directory API didn’t have any affordances for cross-origin requests – presumably the javascript examples were only tested on their own site.

Since I’d just been working with iCalendar, I decided to try and rework the chamber project into a market feed. I actuality, I was able to reuse very little of the code – a little on the iCalendar side, but the API parsing was completely different, and since it’s a dynamic search I needed to present a form and immediately generate the calendar file – the chamber calendar is a singular artifact, so I was able to generate it once a day and upload to S3.

Farmer's Market Calendar

The information in the API isn’t as complete as the information available on the main site, and even produces invalid JSON with a trailing comma. But that was an easy fix, so now you can go get a Farmers Market Calendar for your area and never forget your local market again.

Comments Off

Classes Are Premature Optimization: Prototypes in Javascript at Fox Valley Computing Professionals

This talk is a mash up of two others:

The hard crunchy shell claims that Classes are premature optimization, forcing the programmer to freeze method implementations and often memory layouts during the design stage in order to make things easier for the compiler writer. Classes are also accidental complexity forcing the programmer to deal with rules and limits unrelated to the problem domain, and sometimes expend extra effort working around the class system. This talk will gaze into the soul of object oriented programming to see why classes might not always be beneficial (though they often are). We’ll look at alternate visions from the hard core classlessness of Self to the modern renaissance of Javascript.

The soft, melt-in-your-mouth center is an intro to the prototypal objects implemented in Javascript. Javascript objects are basically maps from strings to values, with a few extras, like dot indexing and prototypes. Prototypes are a way of relating objects so that one, the prototype, can provide default values for another.

Finally, we crunch out with a review of patterns for the proper application of classless patterns.

FVCP had a speaker drop out on the day of a meetup, and I was able to combine two previous talks to make sure members got some good content.

Comments Off

An Exercise in Extreme Modularity at ChicagoRuby

I have a rails project which is composed of gems. One of those gems is a rails app which depends on the others.

This was an on-the-spot lightning talk put together with only a few minutes preparation.

Comments Off