Learning Clojure – Baby Steps Towards Readable Code

Posted by Brian in Clojure, Howto, Languages (October 29th, 2010)

One thing that keeps me coming back to trying to learn Clojure is the way the language forces me to think about problems in a different way. To illustrate that, I thought I’d share a simple problem and solution with you.

The sales tax on items where I live is 5.5%. 5% goes to the state of Wisconsin, and the other .5% goes to Eau Claire county. So, given a price, let’s compute the total amount owed by the customer. Most programmers have done this simple problem enough. We know that the math is basically this:

price + (price * 0.055)

Let’s break down what we know about Clojure and write this expression.

First, we know we can add two numbers together like this:

(+ 4 4)

And we know we can multiply things like this:

(* 4 4)

So by combining those concepts together, we could define our function like this:

(defn total [price] (+ price (* price 0.055)))

That works, but let’s make it more expressive.

In Clojure, things like + and * aren’t just traditional operators. They’re functions, and the parameters we pass in can also be functions.

So if we made a function that computed just the sales tax for Wisconsin at 5%:

(defn wi_tax [price] (* 0.05 price))

and another function that computed the tax for Eau Claire county at 0.5%

(defn ec_county_tax [price] (* 0.005 price))

then we can simply add the results of those two functions together with the price to get our result.

(defn total [price] (+ price (wi_tax price) (ec_county_tax price)))

When we call

(total 5)

we see that we end up with a total of 5.275 for our total price. More importantly, we’ve written readable code.

Looking into the problem more, we see we’ll need to round the number up to the nearest hundredth. Also, this illustrates how we can make better use of functions, but this code doesn’t seem to be very maintainable in its current form. There are 72 counties in Wisconsin, each with their own value for taxes. But I’m sure Clojure has a nice way of handling things like that.

Baby steps, for now.

Web Accessibility – The Screenreader Experience Part One

Posted by Brian in Accessibility, Browsers, Usability (October 15th, 2010)

In order to help other developers understand accessibility and assistive technology, I’ve been working on a series of articles aimed at developers. As a slight change of pace, I invite you to experience Twitter through the “eyes” of a screen reader in this short video. You’ll hear what it sounds like when a screen reader reads the text of a page, and you’ll experience what a blind user might experience if he or she encounters a browser popup dialog. You’ll also get a chance to experience what happens when the browser experiences the “spinning beachball” on Mac OSX.
(more…)

How to Survive a Live Coding Demo Without a Projector

Posted by Brian in Accessibility, Howto, Public Speaking, tips (October 10th, 2010)

I love to turn bad situations into opportunities to help others learn. This morning I gave a talk at Twin Cities Code Camp on “Building Mobile Apps with HTML5 and Web Standards”. The talk had a slide deck, but was mostly designed to be a follow-along live demo. When I went in to give the talk, the projector system was locked down. According to my feedback, the talk still worked very well, thanks to the preparation I did beforehand to accommodate for things like this. Hopefully this advice will help you if you’re preparing for a talk in the future.

My slides for the talk are online here. The code is on Github.

Practice Writing and Drawing

I have horrible handwriting when I write fast, and when I’m nervous. I teach a lot though and have learned to slow down and think carefully as I write. Having clear handwriting on a whiteboard is really important because you’re going to have to give people URLs to your content. They need to be able to read it at the back of the room, too, so be sure to write big.

Learn to carefully draw simple shapes that resemble things you’d show on-screen. In my talk, I drew the interface elements we’d be creating and was able to show how they’d look.

Have a live copy people can see

Make the finished product available on your website so people can play with it. If you’re building a web site, provide the URL to the demo version. If you’re demoing an iPhone or Android app, have a link to a video that people can watch that shows the app in action if you can’t get access to put the app on the App store. This helps people see what’s in your head (and on your screen.)

Make a PDF of your slide deck!

If you use Keynote or PowerPoint, or even SlideDown, convert your slides to PDFs. Include presenter notes in your export so that people will have more context as they’re reading along. If you don’t make use of presenter notes, you should start. They can help you when you present, but they can also help jog memories later when people look at your slides at work.

Protip: Presentation Remote for iPhone will let you see the presentation notes in your hand. You can control the slideshow with it as well.

Use Git and Github for your examples

Lately I’ve been using Git branches to stage my code examples. For my talk on HTML5 mobile apps, I started out with a new branch like this:

git init
git checkout -b 01_simple_form

Then I’ll do all the work for the first stage, commit it, and make a new branch for the second stage. In this talk, the first branch was just the HTML for the user interface. The second branch then covered the JavaScript we used to create the database on the client machine.

git add .  
git commit -m "Web form"
git checkout -b 02_create_database

By the time I’m done, I have several branches in the repository that I can use to track the stages of my live demo. At the end, I merge my last branch into the Master branch.

git checkout master
git merge 09_offline

Protip: If I realize that I made a mistake, I can check out the earlier branch, fix the code, commit the code, and merge that fixed branch forward into the branches that followed.

git stash      # puts your in-progress work aside
git checkout 01_simple_form
# fix changes
git commit -am "fixed the form"
git checkout 02_create_database
git merge 01_simple_form
git checkout 03_add_note
git merge 01_simple_form 
git stash apply # put your stuff back

Once I’m ready, I create the new Git repository and push my code. I have to push the master branch and the other branches too.

git remote add origin git@github.com:napcs/html5_offline_notes.git
git push origin master
git push origin 01_simple_form
git push origin 02_create_database
git push origin 03_add_note
..

So how does this help me during a talk? I can direct people to the Github page and they can use the Select branch section to see each branch. The Github web interface lets them follow along as I talk about the code. That’s what I did here.

Git advantages
Uploaded with Skitch!

Be ready offline

As a last resort, take this git repository and your PDF presentation and make it available on a thumb drive, or fire up a local wifi hotspot and run a server. An iPad, iPhone, or iPod Touch with Air Sharing can help with this.

Wrapping Up

So, that’s how I’ve done preparation for my talks and managed to make it through a code-centric talk with just a whiteboard. Do you have any suggestions on what you would do?

Web Accessibility For Developers

Posted by Brian in Accessibility (October 6th, 2010)

Recently, I polled people via Hacker News and Twitter about the things they’d like me to share about web accessibility given my experience as both a web developer and a daily user of assistive technology. The questions I received are great, and I’ll be writing a series of posts over the next few months about various ways developers can improve the accessibility of their sites for not only disabled users, but for everyone.

To kick this off, you can read my latest article in the October issue of PragPub Magazine, entitled “HTML5: Accessibility For All” where I discuss some of the new accessibility features in HTML5 that make sites easier to use for both screen readers and mobile devices.

In the coming weeks, you can expect to see articles on

  • Improving audio and video for the web
  • Colorblindness
  • Learning disabilities
  • more concrete progressive enhancement
  • Motor impairment issues
  • low vision issues

and many more.

I hope you follow along.