Vishnu Gopal

There’s always a tradeoff between time, money and quality in software development. More often that not nowadays, product managers are asked to deliver excellent products on a tight schedule and on a budget. Agile processes and the trendy idea of the minimum viable product only confuse things further because they seem to prioritise quick iterative development and a tight rein on features. How does one build a good product on time and keeping startup thriftiness in mind? I have six clear steps for you to follow:

One: Before building anything, dig to the roots and find product goals. Ask your client (or yourself) “Why do you need this product built?”. Answers like “We need to run a twitter campaign” or “We want a CRM for our sales team” are not clear enough. “We need to run a twitter campaign to promote our new startup” & “We need a CRM that tracks and updates senior managers about daily sales” are better answers, but ideally what you’ll dig for and get is the true reason behind the product’s existence. For the twitter campaign, it could be “reaching out to potential customers who are likely to purchase our startup’s product”. For the CRM, it could be “improving sales performance and making our sales team more accountable”. You are digging for goals—the why—not features—the what—that comes later, and that’s less important.

Two: Minimum viable product is a great idea. But when choosing what to whet down, keep the goals in mind. I have little patience for managers who come back and tell me, “But isn’t this what we decided to build?”. If you can’t deliver what your clients need, then you aren’t doing a good job. Keep product goals in mind, and prioritise features that will provide the most bang for the buck. Only then will Agile and MVP work well for you.

Three: Find great developers. What’s more important than your process are people. Great developers can manage themselves, figure out their own deadlines and do a lot more than a mediocre developer. Give them great tools too: a good working space, the editor that they want, and their operating system of choice. It’s also much better when you have a good team to split work into spheres of responsibility rather than into discrete chunks where many developers work on the same piece of code. Adopt practices like pair programming & SCRUM and promote discussion within the group. If at all possible, guide every discussion to a consensus and make sure every developer is aware of potential tradeoffs.

Four: Try as much as possible to not build engineering debt. This is easier said than done, but few rules go a long way: adopt a good source control system and practices, a development, staging and production deployment for every product, a continuous integration and deployment server, and have a system in place to code-review every commit before it gets merged back into the main tree. Make your developers police each other.

Five: Have an independent team to do security audits & quality assurance. This is a “manual testing” team, and while they might use several different tools, their mandate is to make sure the product has the features necessary, doesn’t have bugs, and is secure from a security standpoint. This team can be external to the company as well, but it needs to build a good rapport with the engineering division so that they don’t work at odds.

Six: Have regular deployments or sprints. Nothing focuses a developer more than a predictable schedule of deployment. Divide chunks of work into sprints and have staging deployments between them. Make sure that developers are responsible for successful deployments and pour woe to the person who breaks the build.

Well, those are the rules. Sticking to them is hard, and at times impossible, but my experience is that any deviation has always resulted in a loss of quality. While that might be acceptable in the short-term, in the long-term, it always comes to bite you on your ass. However, being a product manager is one of the best jobs out there! Figuring out the nitty gritty details of product construction, overcoming obstacles, finding consensus within the team and outside, and finally, building a product that meets the requirement is a very rewarding job. I’ve done a few stints here at MobME building good products and I’ve loved every challenge.

Update: I’ve started a Github repo that has completed assignments.

I’ve mentioned this before countless times to friends: the Stanford course on iOS Development is really mind-blowing. It’s the best way to learn iOS and Objective-C: Paul Hegarty is a wonderful teacher, the content & density of the slides is excellent and the complex Cocoa Touch framework and the Xcode 4 development environment is brought out very well through hands-on coding sessions.

Just to take one example, take a look at this slide above detailing MVC in iOS. I can point out dozens of developers who wouldn’t have this condensed understanding even after months with the ecosystem. In this small slide, you have:

• Models, Views & Controllers with road lines between them depicting the fact that models and views never talk to each other (double-yellow line), controllers always talk to models and views (dotted white) and when models and views need to talk to controllers, they do so in very defined ways (solid white).
• When views need to talk to controllers, they either fire an action arrow into a controller target, or delegate will, should, and did methods to the controller, or when they want data from the controller, set up a datasource and ask for data at & count methods.
• When models need to talk to controllers, they set up a radio station and broadcast notifications that controllers then tune into.

And this is just one slide in the introductory lecture. It’s a wonderful time to be a self-taught app developer. The Stanford course is right now ongoing and lectures are being updated on iTunes U. There’s a Piazza discussion forum as well for the course.

So I recently got a bunch of calls from an NGO calling itself Relief India Trust. The calls themselves were a bit odd and over zealous with the volunteers flinging themselves at me and describing the plight of children in gory detail, but it was the frequency of the calls that first gave me a clue that something wasn’t right. Then, when I finally decide to put in some money, there’s a volunteer who calls me up, takes me through the donation process and then offers to stay on line until I give her a Transaction ID for the bank transfer.

I did up a Google search and found tons of consumer complaints about the organisation. And if you notice their NGO registration number in the link above, it’s just a plain four digit number: 3696. The Indian Government has an NGO search site where you can search for voluntary organisations by name or their unique registration ID. 3696 doesn’t turn up Relief India Trust. Neither does a search for their name. These are a bunch of scam artists.

Real NGOs probably needn’t be this aggressive. I donate every year to SOS Children’s Village India, which has been my charity of choice since forever. They have a unique take on bringing up disadvantaged children, a personal dialogue (if you wish it) between your kid and you, and I’ve visited their centre in Kerala too.

Silver Linings Playbook is a really good movie. I’m a complete sucker for good romantic flicks, so this was no surprise, but the story around two psychotic folks finding each other was well done. It could’ve been better slightly, a little bit more edgier perhaps, but it’s still really good. And oh, Jennifer Lawrence is hawt!

So it needn’t be said that IRCTC is sluggish at the best of times and at the worst, darn unusable. Is it because of astronomical load? Bandwidth issues? Technology mismanagement? Resource exhaustion? Let’s take a look and try to guess.

This news article from July 2012 mentions that IRCTC did 4.47 lakh bookings in a day. Doubling that figure to get current estimates makes it 10 lakh bookings a day. To get the number of folks accessing the site trying to reserve tickets, let’s multiply that figure 10x. That makes it 100 lakh folks (i.e. 10 million) as a guesstimate who will try to reserve tickets using IRCTC in just a single day.

The first question to ask is are those many tickets available? The answer is an emphatic no. The Centre for Railway Information Systems that develop CONCERT, the backend engine behind web bookings only does around 2.2 million reservations a day. So there’s no way IRCTC can satisfy 10 million users. We don’t have that many seats to reserve.

The second: is 10 million visits a huge number? This is a tough question to answer because it depends quite a bit on what those folks are doing. On most days, the IRCTC website homepage is accessible and loads up reasonably quick, but when you try to login, search or book, it falls down flat. So most likely bandwidth exhaustion is not the root cause, because 10 million visits is just about 11 visits a second. That shouldn’t translate to a lot of bandwidth. Besides, even 100Mbps+ pipes are cost-effective for an organisation the size of IRCTC.

My theory is that the problem likely is the CONCERT backend. That’s not built to handle this kind of a consistent load, especially at peak Tatkal hours when traffic per second could be much more than what I’ve estimated above. And CONCERT was probably never built with online reservation in mind; it was built for a world where people queued up physically, talked to a railway official and booked tickets. And neither CRIS nor the Railways would want an immediate revamp. So what can IRCTC do about it?

There is a very simple solution: decouple the user experience from the backend booking system. I’ll explain what I mean in screenshots:

Step 1: User goes to IRCTC website, logs in and is taken to a page that has a queue number and an approximate wait time on it. This queue number is the position in the queue and is alloted on a first-come first-serve basis and resembles a physical queue where folks wait to book tickets via CONCERT. The page auto-refreshes and updates this information periodically.

Step 2: When the user reaches the front of the queue, he’s taken to the search & booking page. IRCTC perhaps takes up around 500 customers in a minute this way (or however much CONCERT can reliably handle) & booking proceeds as usual.

Advantages

• IRCTC booking is no longer a lottery. This is perhaps the biggest win.
• Customers who log in bright and early get the first slots.
• Late customers get a higher queue number and won’t get tickets, but IRCTC can always blame the other people ahead of them in the queue and not the faulty technology for it.
• The queueing system is optional when traffic is low and below CONCERT’s reliability threshold.

As I see it, if there’s no way to work around limitations of older software, the only thing you can do is remove customer frustration. And it’s high time they did something to improve the Tatkal madness.

Hat-tip to Anoop for making me dig deeper into this.

So if you’re like me and have a ton of different passwords to manage but don’t know how to securely store them, here’s a neat trick: first off, don’t use password managers that store your data in proprietary formats; god forbid if you ever someday need to change platforms or store something more than just “passwords”. Use a simple plain text file and pick Markdown to organize data. Here’s how mine looks:

Now, use a little known facility in OSX to create encrypted disks. Type ⌘+space & open Disk Utility. Now, File > New > Blank Disk Image. Under Encryption, choose 256-bit (why not?) and for image format, choose sparse disk image. Choose a place to save and you’ve got your own secure storage.

Drag and drop your Credentials markdown file into your disk image and you’ve got your own secure password store. If you’ve got any backup tools like Time Machine or Backblaze installed, then it’ll pick up this file too so your passwords are backed up. Have fun!

I took one look at the Holstee Manifesto and decided I wanted it right then & there.

Here’s what it says:

This is your Life.

Do what you love, and do it often. If you don’t like something, change it. If you don’t like your job, quit. If you don’t have enough time, stop watching TV. If you are looking for the love of your life, stop; they will be waiting for you when you start doing the things you love.

Stop over analyzing, life is simple. All emotions are beautiful. When you eat, appreciate every last bite. Open your mind, arms, and heart to new things and people, we are united in our differences. Ask the next person you see what their passion is, and share your inspiring dream with them. Travel often; getting lost will help you find yourself.

Some opportunities only come once, seize them. Life is about the people you meet, and the things you create with them so go out and start creating.

Life is short. Live your dream and share your passion.

And it says this in beautiful old school typographic print. I ordered one, had it framed in classic black and it now hangs on my wall to be the first thing I see when I wake up.

(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.

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. 

(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.

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.

(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.

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

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.

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

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

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.

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

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!

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.

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

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

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

(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!

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.

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 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.

Share this:

• Twitter
• Facebook

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