I’ve always dabbled with open source (Linux got me through university), but it’s only since GitHub that I’ve released a lot of stuff: GitHub.com/alexyoung — I only had weird experiments on my site before, and I released some stuff through work too (code.helicoid.net. Nothing much drew any major attention until I publicly announced JsChat.

I’ve read a lot of game reviews where the intuitiveness of a game is described: the control scheme and menu system can be rated by how intuitive they feel. Intuition is a useful concept, and means more than "easy to use" -- it imparts a sense of instinct; mental processes found in the subconscious.

Code can be intuitive too. Not intuitive to write, but to read. If this seems confusing just think about pseudo–code: beginners are immediately comfortable with pseudo–code but put off by the arcane constructs and symbols of a real programming language. Some languages appear more like pseudo–code: Ruby can be written clearly with little hand–holding for the interpreter. A few conventions must be learned: symbols and blocks usually confuse beginners, but once the basics are second nature code comprehension edges closer to instinct.

I’ve always argued verbosity over needless truncation: write recurring_reminders not rcrr_rmdrs or just r. Concise code is important but is not created by shortening variable or method names. Verbose names are not enough, however. There are more ways to create intuitive code.

I almost survived Future of Web Design unscathed. I say almost because I still have a slightly dull head, thanks to the after party and free drinks. I can’t quite remember why, but at one point I thought ordering a load of sambuca shots would be a great idea.

Carsonified's events have so far been a rare chance for me to meet up with fellow web designers and developers. This FOWD had a particularly friendly atmosphere, and I met lots of interesting people. The Carsonified team were professional and friendly, keeping the event ticking along smoothly.

Web design is a diverse subject. There’s a continuum between design as ergonomics/usability and visual design. Add standards to the mix and web design suddenly looks more like engineering. The talks moved back and forth along this continuum throughout the day.

I went to the Ryan Singer Carsonified workshop yesterday. The title of the workshop was “How to design amazing web app user interfaces”. Ryan discussed his influences and processes behind 37signal's interfaces.

Ryan’s workshop covered:

Least effective difference

Copy

Workflow: Highrise example

Flow

Validation

Rails advice

How MVC helps organise designers and developers

As a web application developer and designer who uses Rails, I found his insights fascinating. Here are my notes from the workshop. I haven’t managed to capture everything we talked about — these are the things that made an impression on me.

Deadline is a reminder web app I made. It sends out alerts through SMS, email and IM, and now it works with Mac OS too. I spent this weekend building a Mac cocoa app for it that integrates with Growl. You can download it here: DeadlineGrowl

I use Secure Trading for Helicoid's payment processing. I wrote a payment processor plugin for our apps about two years ago, and it’s been in production since then. A few people have asked me to open source the code, so here it is: securetrading-rails.

I’d like to integrate it with ActiveMerchant because I like their API, but I haven’t had time so far.

Building games with Ruby and Shoes is a lot of fun because you can throw away the boring stuff and focus on the game’s rules and algorithms. The cross–platform (Mac, Linux, Windows) nature of Shoes also keeps your work accessible.

I went to GitLondon last week, a git training event organised by the developers at Codebase and GitHub. Scott Chacon from GitHub did the main presentation and workshop, which lasted from 9:30am until around 4pm, with Adam Cooke from Cobebase explaining how to set up Git on your own server.

Scott’s presentation covered everything from basic git commands to advanced commands and even the internals. He originally started using git several years ago when it was in its infancy, and built a system that required rsync–like features (but presumably more advanced than rsync). This means he has an interesting perspective on git because he’s familiar with the internals that most of us never see.

Before the event I was using git to store my open source projects on GitHub. I definitely like their social coding approach, and it’s helped me get help and feedback on my work. However, I only knew the basic commands, most of which GitHub shows on the site. After this event, I felt like an entire book on git had been poured into my brain, and I’m definitely more comfortable with it now. It’s not necessarily hard to learn, but it does take some work to become comfortable with it.