The truth is far from ‘ideal’ – developing an iOS application is somehow a frustrating process. You want to play Apple’s game? You have to follow Apple’s rules. Welcome to the jungle kid!

Idea

Let’s do some brainstorming and throw all our wonderful ideas on the table – audio, video, animation, geo, gesture, social media, what else? One fact that gets overlooked here is that app is supposed to be simple, to do one thing and do it brilliantly. We learned the lesson at a late stage.

Users don’t care about all the fabulous additional features. Sometimes they are just fripperies distracting users’ attention and make them confused. If they cannot figure out how to use the main functionality, the app will be sentenced to death in seconds. Certain users have expectations about what the app should do by default, if your app does something different and innovative, makes sure your design is fool proof and test it with your 80 year old grandma before hitting the App store.

Design

‘How about the design?’ ‘It’s just a… clock face!’ our brilliant designer looked bewildered. After 2 months, we had a folder full of design files: storyboard, icon, view designs, animation, transparent overlays, help screens, the list kept growing. The lesson learnt here is that get the wireframe right at the outset and stick to it until it has made a debut in the Apple Store.

Sometimes we got biased judgement of what is good and what is not, we forgot that not everyone is iPhone savvy user, not everyone knows that you can swipe to delete an email and actually half people (based on our sample) don’t know that the ringtone ringer and application volume are different. The philosophy that the user knows nothing, we need to tell them what to do is absolutely insightful. Remember to collect as many ‘difficulties of using the app’ as possible before releasing it.

Development

After all the 22 steps and more than 140 hours clocked in my emacs, I felt I needed a small vacation. The uncertainty, the waiting and the pressure from peers can make the development process quite a daunting task. One thing I can remember vividly is sitting in the office on a raining Saturday afternoon, reading the 80+ pages of guidelines on how to distribute apps.

Conclusion

Treat app production as a serious development, don’t look down it because of it’s size. I admit our app is not perfect, we have a long list of improvements for the next update. Every time someone says good things about our baby, it puts a smile on my face.

Every time when I tell someone who knows Emacs that I use emacs for all my shell tasks, editing and programming, they would do the Emacs hands impression and check my fingers instinctively. This is actually one of the stereotypes that I like.
(source ❐)

Lucky enough I have the habit of using both Ctrl keys in standard IMB keyboard layout so I was not lurked to Remap Caps Lock Key, which is a half-standard popular approach of giving left pinky double work based on the fact that traditional UNIX keyboards typically had the control key where the caps lock key is now. This knowledge is true, but it is not the correct answer to Emacs.

Emacs shortcuts were designed specifically for the space-cadet keyboard which is commonly used for List machines in the 80s. In those keyboards, Ctrl key is the main modifier key and Meta is right after it as the secondary modifier. In today’s IMB PC keyboard, the Meta key has been replace by Alt and the Ctrl key is placed in the corner far away out of thumb’s reach.Strange enough, in spite of the fact that IBM has changed the keyboard layout and made Ctrl one of the most costly key to press, almost all the software designs have followed the tradition of using Ctrl key as the main modifier key along with the HCI guidance published by IMB itself and Apple.

(Source ❐)

At home, I use Microsoft Natural Ergonomic 4000 keyboard.

This is definitely one of the best keyboards you can get as a programmer, it has split keys oriented for each hands, very large modifier keys. Most importantly, they are symmetrically positioned on each side, which is the perfect design for people use modifier keys a lot. If that doesn’t satisfy you, you can even re-map the modifier keys with the IntelliType software comes with the keyboard. For example, you can swap Ctrl and Alt keys to make the keyboard function exactly same as original Symbolics Keyboards.

Things started to go wrong when I switched to a MacBook Pro, which only has one bad positioned Ctrl key.

To cope with the pool design of precious Ctrl in Emacs, I re-mapped Caps Lock key for the first time . Who needs Caps Lock key anyway. Also I re-mapped Caps Lock key for my work PC in Windows XP, hoping to form the new finger habits quicker.

I can live with the feeling that my right pinky has been cut off and hope I can get used to it in a few weeks. But after a while, my left pinky hurts and It hurts a lot. I have been searching for the solutions and tried to work out the best one for my case. But after reading How To Avoid The Emacs Pinky Problem, I give up the thought of getting a Apple Keyboard just for the right Ctrl key.

To ease my pinky pain, I am bring the Microsoft Natural Ergonomic 4000 keyboard to work and upgrade to Microsoft Natural Ergonomic 7000 for my home PC, then move back to Linux again. As for the Macbook Pro, I’ll just use it mainly for design and coding objective-c.

Update: After a year and half of iOS development, now I am quite comfortable with remapped Caps Lock key as Ctrl key – thanks to the fact that majority of Emacs keyboard shortcuts work in xCode.

Refactor early, refactor often, refactor thoroughly.
Test early, test often, test thoroughly.

For 9-5 programmers (The programmers who come to work at 9am, shut down their computers at 5pm and go home with coding-proof bubbles around them.), my points would seem to be over killing. The overwhelming effort needed to practice the principles is enormous, after all, not every coder would like to put these things as his/her epitaph.

For well versed desktop application developers, these three words, early, often and thorough, might not be innovative, as we all have read The Pragmatic programmer and Steve McConnell’s Code Complete. However, from a web developer’s point of view, they are quite interesting.

A typical web application development circle includes requirement, specification (optional), design, coding, testing and delivery. We apply different three word formulas to each stage.

Requirements and Specification

Gather early, gather often, gather thoroughly.

Clients, especially shareholders, usually are non tech savvy type of people, they come to you: ‘We want a website, we want it next month and we like Facebook pop-up bubbles!’. I am so glad you said ‘pop-up bubbles’!

Gathering requirements should be absolutely essential and it is the first deference of disappointment. Some small agencies, including the ones I worked with, tend to pitch their ‘free designs’ in the first meeting, do the hard sells, tell the client nothing could not be done – even if the client want the web to trap real fish.

Instead of trapping clients with free design and ocean deep low price and then rip them off when it comes to tiny changes and maintenance, a well composed contract that is based on enough requirements would be more appropriate. For web applications, personally I don’t think specifications are usually necessary and somehow they produce more disappointment than satisfactions. Reason? it’s not easy to get the specific level right. How specific is specific enough? ‘Membership management’ equals nothing when it comes to design and coding, but ‘The site needs three roles, respectively gusts, registered users and vip users’ will guarantee future changes to be incurred. For a requirements-change-everyday application, you might want to spend more time to gather the right requirements to ensure the solidity of design – both visual and coding.

Design and Coding

Refactor early, refactor often, refactor thoroughly

Not to repeat many great talks (PDF) and discussions on this topic, I will only say one point that I found very interesting yet paradoxical. DRY is the first thing I learned from my C++ class and I believed in it for many years. But for web applications, it becomes quite disadvantageous sometimes: If the page only needs to be alive for three days, code generator and wizard are your best bets. Duplication? don’t worry about that, you would not have a chance to modify them before they die out from Google.

Testing and Delivery

Test early, test often, test thoroughly.
User involve early, user involve often, user involve thoroughly.

Test is a big topic and will not be discussed here.

User involving might be a pleasant way to work with, it is definitely the most efficient way of avoiding disappointment and disagreement. Let the end users involve from the beginning to the end. Give them a prototype of interface to play with, ask for feedback after each stage/component. There is a thing called one-mind, but you and your client don’t usually have it. Sometimes user doesn’t know how much effect would be involved for a small change of his mind; sometimes a big change the client is afraid of telling you may only requires one line code change. Communicating with user can synchronize user’s expectation and developers’ decision, reducing the unhappiness caused by the parts which developers put a huge amount of effort in but lives out of user’s expectations and prevent client changing mind like a kid – which is far more efficient than specification and user would appreciate it.

Until I found out that Mac OS comes with a SSH agent:

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA). The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.

With the ssh agent, we can add the identity once per login. It means ‘add once, use everywhere’! It will be really helpful if you use more than one clients to connect to the same repository server.

Step1:
Use mac os build in ssh-keygen to generate a pair of openssh format keys. Deploy the public key on your server (assume your server uses openssh) and set up the appropriate permissions. If you already have a .ppk key, then a conversion from Putty format to openssh format would be the easiest way to go. It can be done either using PuttyGen in Windows OS or using a Putty Mac port (MacPorts or DawinPorts).

Step2:
Grant the private key file minimum permission. It needs to be:

chmod u=r,ga-rwx

In the beginning I thought that SSH_AUTH_SOCK and SSH_AGENT_PID environment variables need to be set in subversion clients – unless you only use terminal. After a few failed attempts, it turned out that the SSH_AGENT_PID value changes form login to login.

Found the below from Apple website:

/tmp/ssh-XXXXXXXXXX/agent.Unix-domain sockets used to contain the connection to the authentication agent. These sockets should only be readable by the owner. The sockets should get automatically removed when the agent exits.

In this case, svn client needs to talk to the OS to find out the variable values. Since ssh-agent servers as a lower level service in the OS, it seems to be impossible to set up those values for svn clients manually and I assume it is not necessary.

Setp5:
Find the following three files in the ~/.ssh/ directory (create if not exist).

~/.ssh/identity
Contains the protocol version 1 RSA authentication identity of the user.

~/.ssh/id_dsa
Contains the protocol version 2 DSA authentication identity of the user.

~/.ssh/id_rsa
Contains the protocol version 2 RSA authentication identity of the user.

Append your private key in the right file (depends on the key type) and change the permission to owner read only, the ssh-agent will automatically read those files and add identities to the agent every time a ssh request occurs.

Now it’s really password-less!

Ok It’s a lie but seriously, I am not a big fan of mice and timing function animated GUI, they usually slow me down and distract me from concentrating on the job I supposed to do itself. Besides, some really badly designed HCI, such as Windows Vista UAC, can easily push my buttons in all circumstances. People from Microsoft say:

Disabling UAC risks your computer for allowing some worms to execute commands secretly without a prompt confirmation from end user.

and I up voted this:

Enabling UAC risks me throwing my computer out the window from frustration with a poorly designed and horribly executed security model.

Forgive me being loquacious, the point here is I don’t want to use TortoiseSVN – I 100% agree with you that it’s a fantastic software, it integrates with Windows OS very well. I just need to get svn+ssh work with my Emacs shell mode so my SVN experience would be exact the same across Windows, Mac OS and Linux.

Let’s get started.

1. Download Putty, if you are like me always afraid of installing untrusted software from the Internet because you believe that they are mostly badly written piece of cr*p that they would mess your already trashed Windows OS completely then you can be greatly relieved here.

2. Start Puttygen.exe and generate a pair of keys, save the private key without passcode.

3. Copy the public key, yes copy not save, paste/append it to $HOME/.ssh/authorized_keys, create the file if it doesn’t exist.

4. After modified the authorized_keys file, remember to:

chmod 700 authorized_keys
chmod 600 .ssh

This is important as you may get connection errors if the file is group writable.

5. Next, test the connection with putty.exe or plink.exe, (side note: TortoiseSVN has a plink.exe Windows implementation which would not pop up messages.)

plink.exe -i theprivatekey.ppk username@hostname

6. Modify your subversion configuration file. It’s in c:\Users\yourname\AppData\Roaming\Subversion in Windows Vista
add the following line to your [tunnels] section:

ssh=x:/path/plink.exe -i x:/path/privatekey.ppk

Now you should be able to access your svn+ssh repository without typing password, in Microsoft Windows! Vista!

Some extra info for folks who love GUI – for TortoiseSVN users, you need to generate the OpenSSH private key from server, then load it with puttygen.exe and get the public key – it’s due to the fact that there are differences between private key implementations in putty and OpenSSH, otherwise you will get the “server refused our key” error message.

Update: Please check my Configure svn+ssh on Mac OS to see how to convert between existing putty private key and OpensSH private key.

The book starts with an introduction of ‘Part Interface Design, Part Psychology’ and the typical rudimentary web ‘Usage Life-cycle’ to raise readers’ awareness of what hurdles social web design may face and the ultimate goal: ‘Better Design’.

Besides of clearing all the hurdles in the following chapters, there are lots of insights and clichés scattered across its 187 pages, some you may completely agree with and some would make you think. Overall, it was an intriguing read for me. Just like the famous Don’t Make Me Think from Steve Krug, this book is more about common sense. It’s not rocket science, but you just don’t happen to have collected and have systematised all the simple bits and put them in good use. Comparing the style of drawing conclusions from author’s own experience in Don’t Make Me Think to providing more results from research in Designing for the Social Web, this book suggests less detailed description of how to apply the insights into practice, which means you may have to combine your own experience with what the book says to find the best solutions on your own. I felt the author carried out very good research into the subject and represented it compactly yet coherently in a conversional style.

In the London Web Standards meet-up, we discussed this book and someone found that the chapter “Authentic Conversations” is a bit out of topic. Interestingly enough, I found this chapter is particularly useful and I would like to research it more. After been working for a media company, which runs several high profile social web sites for a while and based on the observation on how the publishing team runs the sites, I can see how we can improve and hopefully to put the knowledge learnt from the book in use in the future. It has been said, if you combine your own experience with what the author presented in the book, most likely you will find something interesting and useful.

If you grab this book before going on a trip or jumping on a commuter train, it could make you journey.

I remember complaining to my fellow programmer friends that the worst thing about being a programmer is that you are not supposed to dress smart, if you turned up at work in suit and heels, people would think you are going somewhere else for a job interview.

Lots of programmers take dressing smart as a hard concept to grasp and think that’s totally irrelevant to what they do, which is very sad in my opinion. Are t-shirts and jeans tech guys’ iconic wardrobe possessions, or tech guys just don’t need wardrobes because they only throw their clothes on the floor?

We were asked to dress smart at work today. I went to office in a small-collar-thin-lapel suit with skinny tie combination, which has being popular for the last two years and recently it even caught more attention because of the popular TV series ‘Mad Men’. I was comfortable with my tastes on clothes, and fortunately people liked it. The problem is: as a programmer, I seemed somehow ‘over-dressed’. The popular acknowledgment turned to be that tech guys’ smartness of clothing should be lower than other people at least one level under the same dress code, why is that? Is it a stereotype or most tech guys are just being lazy?

After work, I did a search with keywords “trendy nerd” on Google, there are only 346 results. Which made me wondering is there anything wrong with tech guys’ dress sense or it’s just me that likes ties? Would that even disqualify me being a good programmer?

Personally I like work clothes very much, it’s not I am having a suit fetish. In my mind, this is not about how you want other people to see you, it’s more about how you see yourself, how you feel about yourself – it’s more of an attitude.

Geek clothes can not be trendy or stylish, but there is also a difference between casual and slobby.

If you really don’t like suit, then think different!