I’ve been looking at different IDE themes, and am curious as to what people might be using.

I find myself leaning toward the Railscasts theme in Espresso.

If you’re not familiar with the SXSW process, the topic submissions are closed, but now the community is invited to vote for their favorite sessions.  It’s not required that you be registered for the event to vote, but you do have to sign in/create and account.  The community votes count for 30% of the decision-making process, 40% is by the SXSW Advisory Board, and 30% by the SXSW staff. (full faq)

So in summary, and in the words of the great Mayor Robert “Bob” White, “Vote for me”

While you’re at it, why don’t you vote for Andy Branch and Leonard Souza‘s sessions.

Mickey’s 10 Commandments
(originally for theme park design)

1. Know your audience – Don’t bore people, talk down to them or lose them by assuming that they know what you know.

2. Wear your guest’s shoes – Insist that designers, staff and your board members experience your facility as visitors as often as possible.

3. Organize the flow of people and ideas – Use good story telling techniques, tell good stories not lectures, lay out your exhibit with a clear logic.

4. Create a weenie – Lead visitors from one area to another by creating visual magnets and giving visitors rewards for making the journey

5. Communicate with visual literacy – Make good use of all the non-verbal ways of communication – color, shape, form, texture.

6. Avoid overload – Resist the temptation to tell too much, to have too many objects, don’t force people to swallow more than they can digest, try to stimulate and provide guidance to those who want more.

7. Tell one story at a time – If you have a lot of information divide it into distinct, logical, organized stories, people can absorb and retain information more clearly if the path to the next concept is clear and logical.

8. Avoid contradiction – Clear institutional identity helps give you the competitive edge. Public needs to know who you are and what differentiates you from other institutions they may have seen.

9. For every ounce of treatment , provide a ton of fun – How do you woo people from all other temptations? Give people plenty of opportunity to enjoy themselves by emphasizing ways that let people participate in the experience and by making your environment rich and appealing to all senses.

10. Keep it up – Never underestimate the importance of cleanliness and routine maintenance, people expect to get a good show every time, people will comment more on broken and dirty stuff.

Martin Sklar, Walt Disney Imagineering, Education vs. Entertainment: Competing for audiences, AAM Annual meeting, 1987

I have a quick regular expression to remove most of the unnecessary namespaces and data from the file; I figured someone else might find it useful.

(ai:|ATE:|flm:|d:)(\w*)(=")([^"]*)(")( )?

Comic: The only valid measurement of code quality: WTFs/minute

There will be code.

A fragile premise?
“Good code matters.” –Kent Beck

Everybody gets slowed down by bad code – why do we write it?
We confuse the need for speed with the need for clean code.

Metaphor – What’s the fastest way to be done with dinner? Get up from the table and not do the clean up. When it is time to eat we just find the cleanest dishes and when dinner is over we leave the dishes dirty again. Eventually it is so hard to make dinner we outsource dinner. Sushi chefs clean as they prepare food. If you want to go fast – go as clean as you can. The only way to go fast is to go clean.

We can blame a lot of things for leaving a mess behind. Ultimately we are the ones who make the mess.

Excuses:
The deadline looms.
The backlog grows.
Managers are testy.

When managers approach and ask you to go faster we need to hold the line. Make sure they understand that the best way to go faster is to code cleaner.

Metaphor – The doctor and the patient. The doctor is the servant and the patient is the customer. Even still the doctor is the boss. The patient needs to relinquish a certain amount of control to the doctor to allow them to be the most efficient.

We are paid because we are the experts.

This is the dilemma that we as developers face and we haven’t been doing a very good job.

“Later equals never”

Productivity vs Time
On a new project the beginning of the project we are the most efficient and get the most done. It doesn’t last. Over time the code becomes more complex and productivity goes down.

The mess grows so big and so deep and so tall, they can not clean it up. There is no way at all.

When productivity goes down the business hires more people. Productivity goes down during training; it might go back down. Then the business decides to redesign. They pick the 10 best and start a tiger team to head up the redesign. Then there is a race with the rest of developers maintaining the code.

Xeno’s paradox

Boy Scout rule – always leave the code cleaner than you found it, and do some random act of kindness.

Why does code rot?
When we find dirty code, we don’t want to touch it because if something breaks the code will be assigned to us to fix it.

If you want to be able to clean code – you need to have a suite of tests that you trust.

You only trust tests you write first.

– Break –

The planets take odd paths as they travel across the sky. They actually back track.

What color does you IDE make your comments? Green, why? It is calming – sometimes it’s faded so as to not distract. Meaning the comments are less important.

Comments rot when we don’t pay attention to them. Eventually comments become lies and things change and they do not. We should have a reason for every line of code we write, even/especially comments.

Refrain from adding comments in your code that contains information contained elsewhere, including the source control system.

Instead of including HTML formatting in the comments (for source docs) use only the pre tag (as a concession for the docs)

DW: Comments are sometimes written for the developer to think through what they are building.
UncleBob: So they are masturbatory?

Your effort is to make your code as readable as possible.

Writing code should follow the journalism rule – order the contents of your class in order of importance.

Maybe the private symbol doesn’t belong in an abstract class at all.

It isn’t just nice to have an IDE that will support refactoring, it is necessary.

Sometimes conventions are more important than common sense. The principle of common surprise.

Never make your users do a double take.

The best documentation for a module is the source code for the module. The code should be written in the most readable fashion with a smattering of helpful comments.

We have the impression that frequent comments means we are a good developer.

You should look at every comment as a failure. We still write comments because we still have failures.

Here is the issue, we are the developers, the code is our document. We have stupid rules put on us because we have behaved unprofessionally in the past. We have to suffer through it now.

– Break –

Long Functions
Avoid nested if statements
Avoid large dynamic ranges within functions

First Rule of Functions
They should be small

Second Rule of Functions
They should be smaller than that.

Function should not be 100 lines long.
Functions should hardly ever be 20 lines long.

Smallness implies that blocks within:
if
else
while
etc
should be one line long.
Probably that line should be a function call.

Smallness also implies:
functions should not be large enough to hold nested structures
therefore the indent of level of a function should not be greater than one or two
this makes the functions easy to read and understand

A large function usually hides one or more classes.

A function is cohesive if it does one thing, does it well, and does it only

Extract until you drop

“I like my code to be elegant and efficient… clean code does one thing well.”
– Bjarne Stroustrup

“Clean code is simple and direct. Clean code reads like well-written prose…”
– Grady Booch

“Clean code can be read… Clean code should be literate…”
– “Big” Dave Thomas

“Clean code always looks like it was written by someone who cares”
–Michael Feathers

“You know you are working on clean code when each routine you read turns out to be pretty much what you expected…”
– Ward Cunningham

– Day 2 –

Refactoring

You can write something badly and then manipulate it.

(Uncle Bob’s personal rule) Don’t ever make the developer scroll right (in the IDE).

Never test through the UI. (Don’t test business rules through the GUI).

Rule for writing tests – Intentional Coding! Write the tests for the code you wish you had.

First refactor the tests. Make sure they are easy to maintain or you’ll eventually throw them out.

The tests are the parachute you are going to jump out of plane with; make sure they are folded correctly.

As far as performance – you don’t know where the bottle neck is until you profile. You can look at the code and refactor all day without improving performance unless you first check to see where the problem is.

– Break –

Switch/If statements can be refactored into polymorphic dispatcher.

Uncle Bob’s Three Laws
1) Write NO production code except to pass a failing test.
2) Write only enough of a test to demonstrate a failure.
3) Write only enough production code to pass the test.

Unless you’ve tried it, you should find these rules to be rediculous.

Book – Working Effectively with Legacy Code by Michael Feathers

As tests become more specific, production code must become more generic.

http://cleancoder.posterous.com/the-transformation-priority-premise

– Day 3 –

No more than three arguments in a function.

Don’t use booleans as arguments.

Avoid output arguments.

Here is the list:

1. Response
2. Metaphor
3. Navigation
4. Consistency
5. Training
6. Efficiency
7. Design
8. Prevention
9. Recovery
10. Help
11. Emotion
12. Anthropomorphism

I’m working up a more in-depth exploration and will post it soon.

I decided I should support the wonderful program and buy a couple of fonts. I don’t have any specific project in mind to use them, they are just pretty. Feeling cheap by not paying anything (which is totally allowed by the site) I decided to pay at least $1 for Wisdom Script created by James T. Edmondson.

This morning I received a thank you email from James. I thought it was quite decent to get a system generated thank you email even for my $1 purchase, but scrolling down I realized that James had personally written it (handmade even) when I saw this drawn message.

For this – James T. Edmondson is my Typography Hero; follow him on twitter and send him bags of money on Lost Type Co-op.

Update – James has released a new font called Duke. After purchasing it he sent me another thank you.

I’ve included my slides, but, to be honest, they are fairly minimal and don’t make as much sense without context of the presentation.

I was also asked to participate in the keynote on why it is a good time to be a UX Designer.

For the fun of trying something new I built the deck with Showoff, taking the recommendation from Sim.  It’s not as feature rich as Powerpoint/Keynote, but it is fun to play with.

I also posted the deck to github.

Designing for Mobile Deck (pdf)

I’ll be presenting on Designing for Mobile Applications and I’ll make sure to post my slides when I am done.