Pages

I run because I love chaffed nipples


My friend's mother would warn him saying "Still waters run deep". The person in question was me. And obviously she meant I was trouble. At the end of the day it's always the silent keen observer, who makes notes while watching the world, that's dangerous.

Qualifying for SCMM is simple. You exercise diligently, train hard and give a faster runner your bib in one of the qualifying races.
Well, fortunately when I started running there was no qualification criteria. One fine day I saw an advertisement for the Mumbai Marathon, decided to sign up, put on my shoes, went out for a quick fire 5km run and then was bed ridden for the next two weeks.

My initial year of running was solitary. No friends, no groups, just me, my shoes, my music and my motivation. I was then introduced or rather reluctantly inducted into the general running population where in I met all kinds of runners. Soon running became more social with the likes of facebook and mediums prior to it. Finally I found a 'new' stage to observe.

One of the most popular questions in the endurance running circuit is "Why do you run?". The winners would typically run to win. Pretty straight and simple. But what about the others who don't win? (like me).
That's where fun begins, because I believe actions speak louder than words. And while we have the regular answers such as 'to inspire others', 'self competition', 'love'. I have observed that recreational runners do run for other reasons. Here are some observations:
  • The Limca Runner: Well, it's isotonic and so much easier to get as compared to a Beer record. What's even better is that, you can create your own category. For e.g. First male in my neighborhood over 40 to wake up at 5am and run a 5km. And yes, you can also wake up at 4:59 and claim to be better; who cares if it is am or pm. As you guessed, correctly, these are the mediocre record makers, if you can't break one you make one.
  • The Facebook Runner: This runner came out of the woodwork thanks to social media aka Facebook. What motivates them is not the benefits of running but the number of likes their posts generate. You could possibly see them sulking at the end of the day in the corner of a bar with a Guinness (pun intended) just because they didn't cross 200 likes. What's the point of running (and facebook) if no one likes your post.
  • The Selfie Runner: This runner's goal is simple. Get out for a run, midway take a selfie, a quick shot of the feet, a shot of the road ahead, a shot of the GPS watch, maybe a shot of a bruise or cut that occurred when they were trying to take a selfie while running and fell into a ditch and if possible a photograph of some sweat at the end of the run. Oh yeah Baby!, 2kms done and dusted @15mins/km typically feeling blessed.
  • The Hashtag Runner: #ran10k, #badass, #ballstothewall, #cheetahontheprowl, #wtf, #hashtag. This runner is totally clueless about the proper usage of the '#' tag. 
  • The Brand Runner: The only reason they are able to run faster is because of the brand they endorse. To hell with training, just buy this shoe and it will boost your performance. "Hey, I got a PB/PR wearing this shoe". Obviously the time taken to finish the race is conveniently missed out and more often that not, its probably a 1 minute improvement that took them from a 6:46:33hr  to a 6:45:55hr marathon. In case you are wondering, they would typically round down the time to show a minute's improvement.
So the next time you decide to answer this question, smile and be honest to yourself. As for me, I still don't know why I run. Maybe its because I love chaffed nipples.


Nike Lunar Glide 6


Having done most my long distance runs in the ASICs Kayanos.  My initial reaction towards the Nike Lunar Glide 6 was that of skepticism since I found the shoe very light for a stability shoe. I also felt the upper inner lining would be inconvenient. However after the first runs those doubts were put to rest.

The shoe is an excellent stability shoe, with great arch support. The additional flywire loops for the laces holds the foot in place. The fore foot cushioning is a bit soft as compared to other stability shoes. I prefer a stiffer feel.

The toe box is nice and wide compared to other Nike models that I have used in the past. The upper layer is snug and was quite comfortable during my runs.(The trivial complaint here would be considering the rains and dust/gravel in Mumbai its pretty difficult to clean the shoes due to the upper mesh).

Even though I am more of mid foot runner, I tried running a couple of Kms(13kms to be exact) using a heel strike and found the heel cushioning pretty good.

In a nutshell this is a pretty good, light weight stability shoe that would benefit runners that need stability. However the shoe is not recommended for neutral pronation runners or runners who prefer a more natural ride..

Being a triathlete, I have even used them without socks (no blistering and pretty comfortable). I did most of my Half Iron Tri distance training/racing in it without socks.

Also did 4-5 trails runs in it and yes, cleaning it became a problem since dirt gets logged between the mesh and the inner lining.

Some other points to note:
  • Heel-to-toe drop: 10mm (17mm front and 27mm rear)
  • Stack height: 17mm
 

Transitioning to Barefoot running

This is just some notes I thought of sharing. I might comeback and make this more structured.

I'm not going to talk about what is better, running shod or barefoot?
There is ample information online which talks about this.
Also there is enough scientific evidence that says an optimally cushioned shoe with a zero mm drop is what one should transition to when running. There is a trade off between weight which slows you down and intensity that one can maintain when running barefoot.

Many runners tend to transition to barefoot running too fast and by doing too much. This results in injuries and a sense of disbelief.

A traditional shoe (sports and non sports) typically has a 10-15mm heel toe drop. This means that your heel is raised when running and walking. In certain individuals it also ensures that you naturally heel strike when running(I'm not saying this is bad. Meb Keflezighi is a heel striker) . Prolonged use results in the shortening of your calf and achilles tendon.

When one runs in zero drop/canvas shoes or barefoot there is no artificially induced raising of the heel. The impact of running causes over stretching of the shortened achilles tendon and calf muscles.
Also when running barefoot your brain will automatically cause you to land on your forefoot/mid foot instead of heel. The toe off in barefoot initially will be exaggerated causing additional stress on the calf muscles (One needs to learn to use your hips and glutes when running or to be more precise improve their running form).

If you do not show patience then in certain cases this will lead to calf strain, metatarsal fractures, plantar fasciitis etc since the body hasn't adapted to this as yet.
If you want to run barefoot, then run barefoot (don't use shoes). There are many ways to transition to doing this. 
I would say start of with 1km at a time slowly. Allow your body to adapt to it and your feet to strengthen.
You should gradually build up distance and get up-to 5km over a period of 6-8weeks.
A barefoot progression would be around 6-8mths to do a Half Marathon distance.

The other alternative is to progress towards lower heel toe drops and transition to a zero mm drop by going from the traditional 12-15mm drop to a 7mm, 4mm and finally 0mm.

In either case I cannot stress the importance of patience, strength training and well patience..

Skora Tempo Review



Picked up this shoe recently in a sale. The first thing that got to me hooked was the fact that even though it is a 0 drop shoe it still has about 22mm of cushioning which makes it a good bet to pound the pavement.

The shoe gives adequate protection while running and is surprisingly light. The upper is a mesh like structure through which you can almost see your socks or feet depending on how you like to run.

I would however say that unlike other skora models this shoe is not for running without socks. The toe box is more like the Altra running shoes which is good, However its just large enough to ensure that the outer edges of your feet (especially inside ball of the feet) rubs against the mesh. This ends up with giving you a nasty blister, especially when doing runs above 10km/6miles. I have also faced blisters on the heel but that seems to go off after a few runs. This can be circumvented by either using some tape or cutting out a little bit mesh where contact is made (I find cutting my shoes a better option).

Apple Watch


Some of the reasons why the Apple watch does not work for me in its current state.


  • Battery Life: This takes me back to the 1970s where the first thing you did, when you woke up, was wind your mechanical watch. Times have changed! You will be charging this daily.
  • Product Life: High quality watches last years. Apple will probably cover this watch for 2-3 yrs. The tech in it would get obsolete even earlier.
  • Standalone Device: It only works with an iPhone. On its own its useless, well its just a watch.
  • GPS: For at activity watch, at that price range, a built in GPS is needed. This needs your iPhone. Carrying an iPhone on a run (especially the bigger sized 6 and 6+) is a pain.
  • Water resistant: Not water proof, so no swimming or submerging it underwater for prolonged periods.
  • Productivity: Or Distraction? Seriously, is it that necessary to get an SMS or email notification on your watch?
So there will be the regular eager beavers who would line up to buy this watch. As for me, I will wait for the next iteration.

Database Indexes in Oracle

I have often been sucked into intense debates of database indexes and how they work.

In order to explain indexes in a simple way, think of a telephone diary that most of us use (or at-least used to some years back).  A typical telephone diary has tabs from A-Z and we save names along with other information based on the person's last name in the appropriate alphabet page.
For example William Gates would be listed under the G page or Steve Jobs would be under the J page.
The tabs therefore are indexes which enable you to quickly go to the relevant page and look up a name. If there were no tabs you would be forced to flip page by page and search for a name( which equates to a table scan).

Another example (though not directly appropriate) is the Facebook list that you maintain where in the regular suspects are Family, Friends, Acquaintances. However as you keep adding more friends there comes a need to further breakdown the Friends list to Close Friends, School Friends and University friends. This enables you to search for a friend in the appropriate list and locate a name faster than as opposed to looking up a single list called Friends. Of course the assumption here is that you don't use the search field to find a Name.

Database indexes work in a similar way. The more unique values the better the index performance. However in the database world retrieving data is not simple and there are different searches that one needs to perform on a table. Tradeoffs need to be made between performance while retrieving records vs saving/updating records and retrieval speed vs storage space.

Creating an index on a single column, a composite index on a multiple columns or multiple indexes on multiple columns often come up and become hot topics of debate.The debate further becomes skewed if the persons debating do not have proper understanding as to how indexes work.

The reason for choosing the Oracle database is simply because I use it. And while the basic principles of indexing remains the same across different database vendors, each vendor incorporates some quirks into their search logic. A prime example of this is the cost based optimizer introduced by Oracle (which some people also refer to as Voodoo magic).

So here's my understanding how database indexes work in Oracle.

Consider a table X which has columns a, b, c, d, e and f.
Say we index c,d,e,f. (Note: In a composite index the order of the composite columns also play an important role.)
The possible efficient queries are

1. select * from X where c = :c and d = :d and e= :e and f = :f
2. select a,b from X where c = :c and d = :d and e= :e and f = :f
3. select a,b from X where c = :c
4. select c,d,e from X where f =:f
(I have not listed all the possible queries but I hope common sense prevails)

In the above examples Oracle will use the composite index. Even in the 3 query oracle will use the index since c is the first column in the composite index

5. select a,d,e from X where e=:e
In such a case the index will not be used and even with a hint it will cause an inefficient retrieval of data.

6. select c,d,e,f from X where c=:c
In this case oracle will use the composite index as a skinny table and directly search and retrieve data purely using the index.

Lets take another set of indexes where say, there is one index on (e,f).
And then single indexes on a, b, c, d

The possible efficient queries are
1. select *  from X where e=:e and f =: f
2. select * from X where a=:a (and similarly for all index columns)

However consider the following:
3. select * from X where e=:e
Oracle will still used the composite index (e,f). Thus making the query efficient.

4. select * from X where a:=a and b:=b and c=:c
Oracle will either say let me do a full table scan or use the first index and then do a table scan to fulfill the other search. You could also use hints to tell oracle to use the indexes on a, b and c. This will still be in-efficient as opposed to having a composite index on all 3 columns (a,b,c).


So before you decide on your indexing strategy, you need to first define your queries for retrieving data and then make a decision.

Database multitenancy architecture

With a sizable number of companies offering SaaS software. Architects are faced with typical problems of how to manage their customer's data.
Questions like, Data security, backup, recovery, cost(ROI) are typically what an architect needs to answer when offering a strategy to achieve multitenancy.
Whenever my peers ask me "What is the best database strategy to achieve multitenancy".
My answer is "It depends!"
  • It depends on the domain that you are targeting. Or rather the data that your software is going to manage. The isolation that is required. 
  • It depends on the dollars your business is willing to spend (also read as licensing fees, hardware at your disposal, ability to quickly ramp up production capacity). 
  • It depends on how fast you need to provision or setup a new customer. 
And while I can go on and on, the point here is that there has to be "buy in" from your business that lets you decide what is the best strategy to be applied to the application that is being built.

As far as databases are concerned there is only a finite set of approaches that can be used to achieve multitenancy and these approaches would take you from a isolated to a shared database architecture. The reason I go from isolated to shared architecture is because in the past decade many software companies that offered "single installation" products have modified their offerings to make them "SaaS" compatible and as they try to manage cost they knowingly or unknowingly move from an isolated database to a shared database architecture.

Separate database
Each customer/ tenant has a separate database. This is probably the most easiest approach to mutitenancy. The customers data is isolated. There is no way another tenant can access or corrupt the data. In case of customization needs the data model can be extended as per your customers requirements. Backup and restoring is straight forward and there is no impact on the another tenants data. Almost zero or minimal application logic is required to achieve isolation. This however is a costly approach as you add more and more customers to your offering. Hardware and processing costs will be higher. A single server can only hold a finite number of databases and so more hardware will be required. And you would need a substantial budget and strategy as you start gearing up for horizontal scalability. This strategy is most suited for customers who are willing to pay a premium for added security and customization.

Shared database separate schema
This approach is similar to the separate database approach. It provides logical isolation of data. Each tenants data can be accessed using the schema name and the table name. There is some application logic required to resolve the schema for the entity. You can accommodate more customers per server as compared to the separate database approach. Data restoration would provide some problems when it comes to restoring a specific customer's data. This approach is suitable when you have a small number of tables that are used by your application.
(A variation to this model would be a shared database, shared schema and separate tables per tenant. Additional logic would be required so resolve which set of tables to use for a specific customer).
This approach while costly is still cheaper to implement as compared to the separate database approach. This strategy is suited for customers who accept co-location of their data.

Shared database shared schema (and shared tables) 
In this model the customers data is stored in same set of tables. A tenant id column is required in all relevant tables to identify a tenant's data. 
This strategy is the most cost efficient as far as your hardware budget is concerned. However there would be extensive application logic required to ensure security and separation of data. Added care from a software architecture perspective has to be taken so as to ensure that a tenant can NEVER see or corrupt another tenant's data.

Data restoration in case of a failure can be big pain point especially if you are trying to restore a specific tenant's data. This would involve importing your backup into a temporary database and then copying over the relevant tenants data into the production database. This could be a fairly complex (or as a friend of mine would say "Non Trivial") and time consuming task.

As far as performance is concerned, one customer's volume could potentially impact another customer.
As you keep adding customers you could potentially reach OLAP volumes requiring OLTP operations. Hence your indexing, partitioning, archival strategies play an important role. But more on this later..

Irrespective of the approach taken, it is important to understand the trade offs being made. It will also play an important role in deciding your strategy as far as scalability, extensibility configuration capabilities are concerned.