Ergonomic Analysis of Doors Connecting Malet Place Engineering Building to the Roberts Building

(This is unmarked coursework, part of my HCI course at UCLIC and is released with permission from Prof. Rachel Benedyk. Since this is not evaluated and hasn’t gone through any sort of peer review process, it will most certainly contain errors.)

This analysis uses static anthropometric data to find out inconsistencies of door measurements with the stature of the intended population and recommended positions of door artefacts such as push handles and see-through windows. It further uses dynamic anthropometry to find out if the restoring torque of the door is within recommended limits. The most common use case of a healthy adult is considered in detail as the target user group and the lack of wheelchair accessibility is also noted.

Door Dimensions

Figure 1: Approximate Measurement of doors

Static anthropometry does not reveal faults with the door width and height. According to data available, the width of the door at 93 cm (all measurements are described in detail in Figure 1) and height at 240 cm is adequately wide and high for the 95th percentile of the tallest man who at 180 cm tall (Pheasant 2003) serves as the limiting user. The recommendations for the door handle or push plate state that it should be 25-35 cm from the door edge and 100-150 cm above the floor (Chang & Drury 2007)—and we see that both the push plate and the door handle at 8 cm from the door has inadequate distance from the door edge. However, both have the requisite span since they are long vertical strips that have a length of 65 cm, making their total effective area close to 145 cm, well within the recommended space. Analysing the placement of the see-through door windows, a flaw is immediately obvious. In the case of a short woman as a limiting user (shorter than 140 cm), the window would be useless since it will not allow her to see an intended user on the other side. The major limitation of the static anthropometry method was that it did not consider the purpose of the door: i.e., it hypothesised a theoretical user and did not analyse the function of the door—to open and close and lead the user through.

We decided then to take a step back and use the doors ourselves and note down psychophysical observations. We also observed other people using the doors and noted down possible flaws in the door design. One problem was immediately obvious and unanimous: the doors were too heavy and couldn’t be pushed through easily. We noted an instance where a man walked in with a package, couldn’t use sufficient leverage to open the door with a single hand and instead kicked out with his leg to stabilise the door enough to move through. These observations made it evident that the heaviness of the door was a source of major ergonomic discomfort.

Taking into account Chang & Drury’s recommendations for restoring torque at 30 Nm, an analysis could be done after measuring the door width and the placement of the handle. However, the study was complicated by three factors: 1) the hinges on the door were badly in need of oiling, 2) the door had different resistances at different points in its axial opening and 3) the hinge was loose and at least a portion of the door was intersecting with the frame of the door causing added initial opening friction. Even ignoring these three factors, and calculating the torque of this door,

Moment = F r Sin a

Assuming a as 90 degrees, which means the user pushes the door at a right-angle,

Moment = F r

Since there was no way to measure the weight on the door, we assume a force ranging from 22 to 132 N as in Chang & Drury, moment at 22 N would then be: 22 N x 85 cm, which is 18.7 Nm. Assuming the upper limit of a 132 N force, moment would be 112.2 Nm.

We notice here that if the force on the door is beyond 35 N, we exceed the stated recommendations. The three subjective experiences noted above however, exceed any apparent weight of the door. The hinges of the door at the Malet Place end were so badly unmovable that they would not open beyond 70 degrees unless an exceedingly strong force was used. While any door is an interruption to the dynamic flow of walking of an individual, the successful doors try to stay out of the way by minimising resistance and being easy to open and close. The resistance of these doors makes even the strongest user take a cognitive break from his actions and use his will on the door to move through—this is especially evident when the user has his first experience since he does not expect the door mechanism to be so rusty.

Considering the operation of the door with normal users in mind, the biggest recommendation that can be made to ease the use of the door is to oil the hinges and position the door within the frame so that no part of the door impinges on the frame. The door could also be made lighter and conceivably transparent since it does not overlook into any sensitive areas. To ease wheelchair access, the door could be made powered. The placement of the door pads and the handle could be moved to be more conforming.

The doors would also probably require regular maintenance since they experience heavy traffic throughout the day. Because they connect two buildings with possibly separate and insulated heating systems, a heavier door might have been preferred, but the ergonomic cost add up after each use. Keeping in consideration cost requirements, an enclosed area between the two buildings could be constructed to serve the same purpose since the primary function of the door in this instance seems to be insulation.

While considering an evaluation of this nature, one thing that I thought could be done differently was to perform a contextual enquiry of people using the door—immediately after they went through the double doors. The users might be able to articulate what their material difficulty was, and provide clues to how to construct these doors better. The study could also have been better if it had more data to analyse: it would be relatively easy to set up video recording equipment and observe users interacting with the doors and analysing quantitative measures from the door as well, like the time it takes for a user to successfully complete the interaction. Perhaps grouped by gender, this can provide further insights.

(1047 words).

References:

Pheasant, Stephen (2003). Bodyspace. Anthropometry, Ergonomics and the Design of Work. Second Edition. p. 244.

Chang, Shih-Kai, Drury, Colin G. (2007) Task demands and human capabilities in door use. Journal of Applied Ergonomics Vol 38. pp. 325-355.

Heuristics as an Aid to Training a Usability Evaluator’s Expertise

(This is unmarked coursework, part of my HCI course at UCLIC and is released with permission from Prof. Ann Blandfod. Since this is not evaluated and hasn’t gone through any sort of peer review process, it will most certainly contain errors.)

Heuristics as an Aid to Training a Usability Evaluator’s Expertise

Vishnu Gopal

University College London

It is clear that heuristic evaluation as Nielsen envisioned it is a method meant for experts (Nielsen, 1992). Heuristics do not stand alone, and have to be moulded to fit any particular scenario: the general set of heuristics have been expanded into specific guidelines for different kinds of activities: accessibility, internationalization (Gonzalez, Granollers, Pascual, 2008), etc. are examples and these require evaluators who are trained and experienced in separate spheres. Experimental data also seems to suggest that the more experienced the evaluators, the more usability errors they find (Dumas and Redish, 2002). Given this scenario, I seek to explore if heuristics or other similar guidelines can serve as a tool to strengthen a beginning evaluator’s “experience”.

Without doubt, applying heuristics to usability evaluation gives a methodical structure to the task of analysing potential faults in a system. During a recent analysis of e-commerce websites, one major observation that I made was that without rules, it’s easy to miss the forest for the trees—i.e. one might speculate on possible faults: for e.g. the links on the right hand side navigation bar was not prominent or relevant enough, or the visual design was not attractive; but fail to gather the data into meaningful coherent suggestions. The aim, after all, of a successful usability evaluation is to find ways to rectify potential faults. When pitted against an evaluators raw instincts then, following a set of guidelines acts both as a reasonably exhaustive search space and a framework for assessing faults that have been found. It can also be argued that using a set of guidelines methodically can sensitise an evaluator to common errors.

On the other hand, I also observed that there might be faults found more easily not from a strict adherence to guidelines, but from an evaluator’s own prior experience. During the usability evaluation activity, my companion who is a trained visual designer found that much of the website’s apparent clutter was due to it not following a coherent “grid system” (see Chang, Dooley, Tuovinen, 2002). While it might be easy to slot this into either guideline 4 (consistency) or 8 (aesthetic design), it doesn’t cleanly fit into the heuristic framework provided, but is a crucial criticism nevertheless. I suspect that a strict adherence to guidelines without a broader background might harm rather than help a beginning evaluator’s progress, but this requires detailed investigation. It could also be too easy to be trained to look into a series of specific and common problems rather than try to evaluate a system based on its intent.

This is further imperilled by the fact that the minutiae of specific guidelines change often. An example of this debate is how the specific recommendation relating to websites displaying content above the fold (the initial viewable area) changed from 1994 to 1997, a short span of three years (Nielsen 1997).

When compared to other methods of user testing, heuristics pale further in this regard. They remove a vital component from usability evaluation: the serendipity (Stoskopf 2008) that observing a user adds to training an evaluator’s instincts. This is especially important in a field like usability evaluation where observation of real users continues to be stressed (Petrelli, Hansen et. al. 2004), and rightly so, for HCI evaluation has its roots in cognitive psychology and that is a science yet to attain adulthood (Miller 2003).

It would also be instructive to observe how HCI (and accordingly usability evaluation) is taught in University courses worldwide. Saul Greenberg of the University of Calgary remarks that a “fundamental tenant of HCI is that end-users should play an integral role in the design process” and that “performing usability studies in class hammers home the relevance of evaluation”—indeed his course description (Greenberg 1996) is filled with references that directly involve users in class. Interestingly, the course is structured so that “Designing Without the User” is a later event: where lessons learnt from these evaluations are then integrated to try to formulate a theory of user behaviour.

Chan, et. al. exploring issues integrating HCI in master-level MIS programs also stresses the emphasis on users and “empirical testing” and recommends a curriculum that largely ignores heuristics. Faulkner and Culvin in “Integrating HCI and Software Engineering” condenses it well and also explains a crucial difference with software engineering:
“Some HCI practitioners seem to believe that if HCI can be reduced to guides and checklists that anyone can apply to anything, then all will be well. This is tantamount to designing HCI out of software engineering as it is providing rules to be followed without the requisite theoretical under-pinning. Students trained in this way will be chanting mantras and will be woefully unable to deal with problems that have not been solved elsewhere or are not covered by style guides and checklists. Software engineers on the other hand are either keen to embrace these checklists or are unwilling to accept that the age of users having to adapt themselves to systems has gone. Users want systems to work for them and not the other way round.” (Faulkner & Culvin, 2000)

Furthermore, in a study examining how guidelines and patterns might be effective in HCI teaching, Hvannberg et al. “found very little hard evidence” supporting the importance of using patterns or guidelines in HCI teaching. However, they also noted “a desperate need to conduct studies on a suitable scale on the use” of patterns and guidelines in teaching HCI concepts.

There is no doubt that Nielsen’s basic heuristics have stood the test of time as a way to find usability errors. However, as a tool to train a beginning evaluator, they should certainly be supplemented by other evaluation methods.
(1045 words).

References:

Chan, S.S, Wolfe, R. J., Fang, X. (2003), Issues and strategies for integrating HCI in masters level MIS and e-commerce programs, International Journal of Human-Computer Studies, Volume 59, Issue 4, Zhang and Dillon Special Issue on HCI and MIS, October 2003, Pages 497-520, ISSN 1071-5819, DOI: 10.1016/S1071-5819(03)00110-1.(http://www.sciencedirect.com/science/article/B6WGR-4938JRM-1/2/498d2855a23d35c7524dd9c4201b5d4e)

Chang, D., Dooley, L. Tuovinen, L.E. (2002), Gestalt theory in visual screen design: a new look at an old subject, ACM International Conference Proceeding Series; Vol. 26 Proceedings of the Seventh world conference on computers in education conference on Computers in education: Australian topics – Volume 8

Dumas, J.S., Redish J. A Practical Guide to Usability Testing. (1999), Oregon. Intellect Books. pp 67.

Faulkner, X. Culwin F. (2000), Enter the Usability Engineer: Integrating HCI and Software Engineering, ACM SIGCSE Bulletin

González, M.P, Granollers, T., Pascual, A. (2008), Testing Website Usability in Spanish-Speaking Academia through Heuristic Evaluation and Cognitive Walkthroughs, Journal of Universal Computer Science, vol. 14, no. 9.

Greenberg, S (1996), Teaching Human Computer Interaction to Programmers. Technical Report 96/582/02. University of Calgary.

Hvannberg, E.T., Read, J.C., Bannon, L. Kotzé, P. & Wong W. (2006), Patterns, anti-patterns and guidelines: Effective aids to teaching HCI principles? In, Inventivity: Teaching theory, design and innovation in HCI – Proceedings of HCIEd2006-1 (First Joint BCS/IFIP WG 13.1/ICS /EU CONVIVIO HCI Educators Workshop (pp. 115–120). Limerick, University of Limerick.

Miller, G. A. (2003), The cognitive revolution: a historical perspective. Trends in Cognitive Sciences, vol.7 no.3.

Nielsen, J. (1992), Finding usability problems through heuristic evaluation. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Monterey, California, United States, May 03 – 07, 1992). P. Bauersfeld, J. Bennett, and G. Lynch, Eds. CHI ‘92. ACM, New York, NY, 373-380. DOI= http://doi.acm.org/10.1145/142750.142834

Nielsen, J. (1997), Scrolling Now Allowed. Blog post at http://www.useit.com/alertbox/9712a.html

Petrelli, D., Hansen, P., Beaulieu, M., Sanderson, M., Demetriou, G. and Herring, P. (2004), Observing Users – Designing clarity a case study on the user-centred design of a cross-language information retrieval system. Journal of the American Society for Information Science and Technology, 55 (10). pp. 923-934.

Stoskopf, M. K. (2008), How Serendipity Provides the Building Blocks of Scientific Discovery. ILar Journal. vol. 46.

Quickie Food

It’s been a while since I’ve been in London and it’s the first time that I’m in a situation where I’ve got to feed myself. I could go over my supposed angst at the situation, reminisce about the good old food days, and probably smirk at how I’m handling the situation right now, but since I always pride myself on being practical, here’s eight food items that a) won’t break the bank, b) takes less than 15 minutes to prepare and c) are moderately healthy, d) will fill up your stomach. You’ll notice another weave through these two soon, but I’ll leave that for when you finish reading.

Cereal, Milk and Juice

So, the classic quickie breakfast, and wonder of wonders—it’s quite good after all. Supplement this with toasted bread with chocolate filling if you have a hungry morning. If you’ve got a hangover, orange juice helps!

Requirements: Pretty much nothing if all you’re having is cereal and milk. Remember to check the expiry date on the milk, keep it refrigerated and consume within a week.

The Ham/Pork Sandwich

Buy Ham and pork slices from Tesco. Both are delicious, but the pork ones especially so. The way I make them is: three slices of bread, with fillings alternating between: 2 slices of pork and one ham, and one spinach or lettuce half-handful. Combine this with the fish fillet below and it’s a nice lunch/dinner. Microwave then at 250W for 2 mins.

Requirements: Toaster for bread, pork, ham slices and either lettuce or spinach filling from Tesco (you buy them in a plastic bag).

The Tuna Sandwich

Pretty much the same as above, but the Tuna comes in a tin and can be bought at local stores so you might not have to find your way to a distant Tesco/Sainsbury’s. One tuna tin should last your for three sandwiches. Store the remaining tuna in an airtight container but don’t keep it in the fridge. Consume within a week.

Requirements: can opener (yeah without it it’s a pain to open).

Chicken (or Vegetable) Soup in a Tin

A quick “snack” or filler, these again come in a tin (but the ones you can just pull to open). Just put out in a small bowl and microwave, 250W for 4mins. One tin serves two servings. It’s pretty healthy too.

Paratha and Curry (any kind)

Buy a parathas packet (might be spelt porattas on it) at a local Indian shop. To make them, just buy some oil (olive oil is what I like) and pre-heat the pan: 5 on your indicator for around 5 mins. Each paratha will then take around 3-4 mins to make. Make sure you slightly burn both sides. Combine with curry—the vegetable ones are common and can be bought for a pound at any Indian shop, the non-veg ones are a bit rarer, but try hunting around. Mix with rice too for a full meal when you feel like it.

Requirements: parathas, a pan to cook, (olive) oil, some curry (or curd, or sugar).

Pizza to Bake

You can buy pizza again at pretty cheap prices at local shops or at mainstream stores. The instructions on the back will be pretty clear, but it involves you putting the pizza on an oven plate for around 15-20 minutes. Make sure you have it hot because pizzas are not good when had cold. When you put in the pizza into the oven and take it out, use oven gloves (or if you don’t have them—some kind of thick cloth). This is again a nice quick snack.

Requirements: Oven, pizza.

Fish Fillet to Microwave

Fish fillets can be bought at all mainstream stores. I love the ones at Waitrose, but Tesco’s and Sainsbury’s’ are good too. Find the one you like. You can either oven this or microwave, but I prefer the latter. Just do a 540W for 6 mins and it’s done! Eat after it cools down a bit.

Rice and Curry (of any kind)

So, rice is insanely easy to make. Instead of me telling you how, I’ll point you to where I learnt it from: WikiHow—the video at the bottom is almost exactly how I did it the first time. Rice is also easy to buy at all local stores and it’s very satisfying to have combined with some form of curry (see curry above).

So one thing that you should’ve noticed: I didn’t exactly write these for expert cooks. This is for people like me who are absolute beginners in the kitchen. But this way works, trust me—when you’re really busy you don’t have time to cook much anyways.

Memorable Photos

(This post was written a way back. Couldn’t find the upload b/w to up em photos until now)

I’m leaving for London tomorrow. It seems like a good juncture in my life to look back at good moments in my life. So in no particular order, some good moments from my life, with a bit of commentary. This is also to some extent an exercise in narcissism, so am begging for advance forgiveness right here.

40379424102007

Me, Sony, Andrews and Sanj, 25 Oct, 2007. This was one of the few times Sanj Andews and me got together after college. Sanj & me have the beginnings of bald hair here, and Andrews as usual is the glamour boy :-)

DSC03041

This is at Vivek’s cousin sis’s engagement. A whole lot of us turned up that day. I remember hiding the drink when his mom came calling. 30 Jun 2007.

photo

Me and Sherin. 9 Dec 2008. At Coffee Beanz, Kochi. One of my favourite places, and one of my favourite people.

DSC03095

MobME (then Torque)—the old office. This is after I came back from Delhi but before we moved into better offices in Kochi. This photo also has my beloved mac. 10 Jul 2007

DSC04843

Aks and me when I went to Blore on one of my many trips. I remember lots of other people turned up that day, but it was after a long time that I got to see him. 5 Nov 2007.

DSC04853

Nandu, Vivek and me, in a pub. This is a landmark photo coz this is how Nandu started drinking. :-) 5 Nov 2007.

DSC05041

15 Mar 2008. DP, Prema and me, Loungevity. So I have the unique distinction of being one of two people to get DP into a pub. She wouldn’t let me drink tho! :-)

IMG_0029

DP and me, Fort Kochi. 3 May 2008. I love this photo. I remember all of us (the other people being Sanj and Prema) were very happy that day.

IMG_0322

28 Dec 2008. Me at the Taj. With Sanj, but I’ve decided this is the photo I like best and he just happened to be the one taking it :-)

P8286397

29 Aug 2007. Me after getting on a Vallam, traveling from Malakkara to Aranmula and back. With Mom.

PB247503

24 Nov 2007. Me at the first Barcamp Kerala. What we started off then is now really active and doing good. Great stuff!

P220209_17.58

(22 Feb 2009). Prema girl and me in the boat to Fort Kochi. We did this trip many times and often by sitting on the edge of the boat like this. And then Kashis for coffee, and sometimes Dal Roti for dinner. Good times!

DSC02980

Me and Meera—we have a lot of photos and it’s hard to pick one, but I like this. Muthoot Plaza, 18 Jun 2007.

Snow Leopard Installation Tips

So by random chance, I’ve installed Snow Leopard twice in the past two days and learnt a little in the process. Thought it’d be nice to share:

First off, Snow Leopard (as of today, 26th August) has not been officially released yet. It’s easy enough to download it off a torrent tho. The magic letters are “10A432″. That’s all I’m going to say on that subject.

Installation

  • First off, backup everything important. Not doing this is stupid and besides, this guide is oriented towards a fresh installation and not an upgrade.
  • There’s a better way to get it installed than from the Install DVD (or burning one). If you’ve got a portable HD lying around, partition the drive (using Disk Utility) into 2, a small 8G Snow Leopard Installation partition and a bigger Data partition. Make sure that under Options, you select a GUID partition table, otherwise you won’t be able to boot from the drive.
  • Once you’ve done that, click the Snow Leopard partition, click Restore and drag your downloaded .dmg into Source, and the partition into Destination. Make sure Erase is checked and click Restore.
  • If you’ve got that running (after the restore is complete, the “Snow Leopard Install DVD” will be mounted but don’t do anything yet) go to System Preferences -> Startup Disk, select the new partition as the Startup Disk and then Restart.
  • Install Snow Leopard as you will once the computer restarts, but if it’s a downloaded build, you’ll have to start from scratch with a Fresh Install. If the installation program doesn’t recognize your drive (or has an exclamation mark next to it) it’s because you didn’t format it properly. Just select Utilities->Disk Utility and reformat any partitions as Mac OSX Extended (Journalled).
  • As far as I can see, there’s no Upgrade from Leopard option. This is a good thing in my books though since things work much better with a Fresh Install.

Post-Installation Steps

  • Install iWork and iLife if you have and need them.
  • Start up Software Update and let it do its thing. It’ll take a while so you can do other useful things in between!
  • Restore your data from your backups.

Optional Post-Installation Steps

These are oriented mostly towards coders. If you aren’t one, feel free to skip.

  • First off, install Xcode. It’s a must for a lot of things. Note: you’ll have to use the build that comes with Snow Leopard under the Optional Installs folder. Xcode downloaded off Apple’s websites won’t work with Snow Leopard.

  • Install MacPorts. You’ll have to do this from source since the available installation package doesn’t work with Snow Leopard. It’s easy though. Follow these steps in a Terminal:

    $ cd
$ mkdir Applications
$ cd Applications
$ svn co http://svn.macports.org/repository/macports/branches/release_1_8/base ./MacPorts
$ cd MacPorts
$ ./configure --enable-readline
$ make
$ sudo make install

  • Create a file named .profile in your home directory (~) and add these two lines to it and save:

    export PATH=/opt/local/bin:/opt/local/sbin:$PATH
export MANPATH=/opt/local/share/man:$MANPATH
  • Now close the Terminal you have and open a new one.

  • To test our MacPorts, we’re going to install a pretty useful utility—wget. You can choose to install something else.

    $ sudo port -vd sync
$ sudo port -v install wget

    This’ll take some time, so you’re free to do something else.

  • Install TextMate and register it.

Well that’s pretty much it!

The Art of Fixing Code

The title isn’t original, but it’s apt and describes my feelings exactly. Bulleted, and also referred to as Vishnu’s Commandments for Fixing Code:

  1. Fix The Fucking Problem (hereafter FTFP)

    When you’re faced with a bug, a calamity, a loss of limb, you solve the problem. Don’t worry about its causes, its probable antecedents, which commit broke your painfully arranged view of the multiverse or whether you’ll earn a PeeEtchDee by writing a paper about good software engineering practices. Instead, you FTFP.

    Only after you’ve FTFP, shall you think about anything ancillary. Only afterwords shall you blog or tweet about it or submit it to our humorous overlords. Capish?

  2. Next, FTFP as if your ass is on fire.

    Downtime sucks. If a marginally large system used by a non-trivial number of users (by which I refer not to your blog which your mom and your imaginary girlfriend reads) goes down the rabbithole, a lot of people will complain. If you work for Initech, Lumbergh will cluck his tongue and hand you a pink slip if you mess up too often. Forget nine-nines of reliability, if you manage a month with just 5 mins downtime, it’s great.

    I’ll also extrapolate this from TDD: “Write a test, write the minimum amount of code for the test to pass, refactor, write more tests.” becomes “Figure out the problem, write the minimum amount of code that fixes
    the problem    , refactor, find more problems.”

  3. Log. Write logs to Disk. Backup & rotate Logs.

    In any after-action report, you’ll want to figure out why the Problem happened. What went wrong. For this you need logs from when it happened. Often you’ll notice that it’s a periodic bug which slowly got worse as your system added in more users, so you’ll want to figure out exactly when it happened, and when the issue escalated. For this you’ll need to log properly and backup those gzipped logs. Thumb rule: for the first nine months of any production system, logging should be enabled with the maximum possible verbosity. This includes connected systems, like for example, Database Logging.

  4. Use Git already, nitwit!

    It’s pretty much what everybody should use. Easy, quick code commits and can even serve as a quick and dirty deployer too. Git allows you to hotchpotch solutions in case of emergencies. There will be instances when you want to short-circuit every code review check and just deploy the thing goddammit and nothing beats Git, for now.

  5. Use an automatic deployment tool.

    Your deploy should be just one command, or a click of the button. Hooking up before-commit hooks is okay as long as it doesn’t take an eternity.

  6. Make pretty downtime notices so people know you are at least trying.

    Being apathetic sucks. Giving an impression of being apathetic when you are working hard to save your application sucks harder because of stupidity. So don’t be stupid. Communicate. Make twitter work for you or for the old-fashioned, have a mailing list or an RSS feed. Your blog shouldn’t go down at the same time as your site so keep it on a different server—wtf are you doing writing a blog app anyways—outsource that to people who know better.

  7. Learn the ins and outs of your deploy OS of choice

    It’s not enough to be a Gee Whiz programmer. Learn your OS inside out. If you’re on *nix (like real men) then this involves figuring out what to do when your load average goes through the roof, your SQL engine hogs CPU, your hard-disk fills up or your webserver restarts. Learn about commands like: top, iftop, iotop, uptime and the entire /proc magic filesystem. It’ll help you diagnose code and issues. For blacker magic, learn about strace and dtrace and how to debug difficult issues. All this comes later though—remember the golden rule: FTFP, so the first take should always be to Google your error.

  8. Don’t put all your eggs in one basket

    Do trust in Murphy, he’s eternally right. Things will fuck up. Instead of preventing it, plan for contingencies and try to recover from them fast. Have scenarios where bad things happen to your application. Have a load balanced implementation the first thing for chrissake! Have a DB in a master-slave configuration the instant you can afford it. Have a system where provisioning servers doesn’t take days. Move as much infrastructure as you can to the cloud where you don’t have to maintain it directly.

  9. Delegate the Debugging

    This might be harder to do because you’ve got to pump up your adrenalin and stay in the zone to figure out problems and implement quicker solutions, but often, three or four helping hands work much better at solving problems—especially when other people can help you cross-reference data to try to come up with probable cause. Remember, speed is key.

    Surround yourself with people who are smarter than you too. That helps to negate your stupidity. Own up to mistakes and implement solutions fast.

  10. Have a Staging Server (or Replicate Production as closely as possible)

    The worst problems are those that happen only on production systems and can never be replicated in development. Remember: OSX is not Linux, minor version differences often introduce incompatible interfaces (I’m looking at you, Rubygems and PHP) and stuff breaks when you add something new without testing it on your deployment OS of choice.

    If you are making any drastic changes to the architecture, test in on a staging server (or if you can’t afford it, a password-protected subdomain) in live conditions before switching, it’ll save you loads of trouble.

  11. Prevention is better than Cure

    Do TDD or have a good test suite. Stuff will break far less often then. Educate your coders to have decent S/W engineering practices. Indent code and name variables uniformly. Raise exceptions and use assertions within your code. Use transactions too so when stuff breaks it doesn’t affect a lot of other important elements. Learn how to use a Queue and how important that is in modern production systems. Don’t abuse an RDMS for tasks it wasn’t meant for. Learn about newer key-value storage DBs. Beware of caching—it introduces subtle errors and problems, but learn to love it too, without it, you’ll never scale. Write readable code and document it both within and separately.

Meera’s Blog

Meera's BlogMeera’s new blog is here: meerarnair.wordpress.com. (She also has a twitter account btw @meeranair).

Women, Diversity & Discrimination

Background: Presentations that include female nudity and references to porn in professional presentations. The first incident occurred at GoGaRuCo the Ruby conference in April, the second and far more blatant one at the Flashbelt conference just two days ago.

This is my take on the issue, and my personal experiences with these kinds of incidents.

Incident one: I had gone to the Bangalore FOSS.in conference about two years ago. An extremely attractive lady from linuxchix came up on stage to speak on The Black Art of Makefiles. As has happened many a time before to many a speaker’s laptop, hers refused to play nice with the on-screen projector and the slides just wouldn’t come up. Yes, probably a screen resolution mixup. What was unusual though was the ten guys who rushed up on stage and started working on her laptop. They tried for a minute or two to fix the problem (without success) before the lady eloquently managed a few keystrokes in. And voila, the slides came up and the crowd dispersed, sheepishly. Yes, the lady knew best—it was her laptop after all.

Incident two: One of my friends is studying for her MBA at a good institute where companies come up to place people for summer internships. An interesting statistic: 80% of people who got placed in high-profile companies were girls, and a reputed technical MNC only gave out internships to girls. I theorize that this is because as a rule, girls sell products much better than guys.

Fact: There are subtle (and not) gender differences in the technical community that’s visible every day. While most often this is genuine discrimination, sometimes (as in incident two) it’s biased towards women too.

Fact two: Not all discrimination is deliberate. I’m pretty sure the Ruby presenter was just trying to be “edgy” (Ruby is much more conducive towards such non-mainstream behavior) but ended up offending the women in the audience. I’m not sure many women realize this, but men do not have an internal radar on the things that offend women – this is a general extension of the “cluelessness” that is often attributed to us, albeit with more serious consequences in this case.

Whatever the case may be, there’s one solid fact. We genuinely need diversity in the technical community – a broader opinion and insight on every topic just leads to a better community and this is true however cutting-edge it might pretend to be. Most of the people do want to encourage this diversity too and not make women uncomfortable at formal presentations and in a crowd which is >80% men.

One suggestion. I know women are not confrontational, but early intervention will help – if you feel uncomfortable, speak out, and the earlier the better. If you are in a mailing list and there’s a sexist troll, speak out and say you are not happy. Some men do listen (and those men are usually the ones who are in charge).

I’ve got to admit the blog posts and news coverage have made me think on what is appropriate behavior in public. Some people want to portray conforming behavior as a dampener to creativity but that’s hardly the case – you always follow some sort of rules (for e.g. imagine a guy taking off his clothes on stage – I’m certain the 80% won’t be amused). Creativity within constraints is a challenge and if you want a discerning minority to listen in and come up with suggestions, make sure your slides do not offend too.

One more thing—As many women have pointed out in the Flashbelt incident comments, it’s not the bawdy humor that’s the problem—it’s the context. If you want an analogy, imagine yourself as the only person in a crowd of women all laughing at a joke about how size does matter after all.

Identity Changes

So I was a very early Internet user. Not so early as Tim Berners Lee, but early enough to see Internet access begin in India – those dialup modems were excruciating: they promised much but delivered little. I remember a service early enough in the Web 1.0 era that allowed people to register domains for free (yes, without paying a buck). These guys (I’ve forgotten the name) made money by framing the site contents and delivering flash and scroll ads up top. Needless to say, they quickly went out of business. But I remember I had a vishnugopal.com registered with them way back then.

Since I’ve been “alive” on the net for close to ten years now, I’ve left traces under many different identities. Very early on, it was uncheckedramblings, which was the name of a blog that I made at blogspot.com – vysnu.com evolved from those humble beginnings. Concurrently, my primary identity on the web was thehitchhiker and the necessary variants that had numerical prefixes, suffixes and substitutions to it. My Yahoo ID until a couple of years ago was thehitchhiker_123. I had another alias during this time created for shady purposes. I used q— to write unconventional stories. Then (in a fit of originality) I combined that ID with thehitchhiker to create QHitcH (often spelled all lowercase as qhitch). That is still my Skype ID.

So just to recap, until now I’ve had four identities on the web. Till recently, I maintained my portfolio site at vish.in, my blog at vysnu.com and my twitter account was named vishmaker.

While it’s nice to be creative, it’s also nice (and SEO sensible) to be consistent. And what better name to brand than your real name? So it’s vishnugopal everywhere from now on.

Inspiration: The excellent Securing Your Online Identity article, an extract below:

Ideally you should implement one consistent online name that can be used across many different platforms. It's best if your online name is the same as your offline name, but you may find it necessary to make them different for certain reasons. You may also decide to use a different name for your business presence and your personal communications. Generally the higher the consistency you can achieve the better.

via Securing your online identity | creativebits.

Aside: It’s a sad fact of the web that none of those early avatars are visible now. It’d have been nice if HTTP behaved more like source control – web.archive.org didn’t consider any of my sites important enough to store.

Peep into PI

My talk for this time’s Barcamp was a distributed computing project that I worked on called Peepapp. Here are the slides:

The slides should be self-explanatory, but some notes from my talk:

  • The USP for this application is the fact that it’s really easy to become a worker. You just connect to the job using a browser and everything else is transparent.
  • We change the MapCalculateReduce architecture of a system like BOINC a little bit by separating out the concerns of the coordinator and the master node. The server (peepapp.com) is just responsible for coordinating actions and as such, it’s just a message queue.
  • The coordinator itself is written in Sinatra running on Ruby Enterprise Edition, and fronted by Nginx and passenger running on Ubuntu Jaunty on a Slicehost 512 VPS. Around 20-30 people connected to the job during my talk with negligible load on the server.
  • The map bit of the code I haven’t implemented yet. That, and a system to make creating jobs easier. Once that’s done, I plan to opensource a lot of the codebase – it isn’t much anyways, less than 200 sloc.

One thing which I’ve realized during the course of this talk is that the concept is sound and there’s some interest too. I’ll continue work on this!