Startup Saturday Bangalore - December-2011 - Should you spend your money or someone else's?

After hearing a lot about Headstart.in and Startup Saturdays and after having read a lot about startup communities and their importance in various blogs (including Paul Graham's) I attended this month's Bangalore edition of Startup Saturday. I must say that I totally loved it and am really sad that I did not attend it earlier. Well, better late than never.

This edition's broad focus was on funding and equity distribution. Here is a link to the event description page. We had Suresh from Telibrahma and Sujai from Sloka Telecom sharing their experience and some of the nitty-gritties associated with securing funding for your startup and managing equity and stakes. Here are a few things that I grasped and managed to remember.

For those in a hurry, there is a tl;dr section at the bottom. I know your time is precious and I blabber a lot. :)

1. Start your company with an exit clause in the agreement with your partner
   
   Suresh pretty much started the discussion with this point. When you start your company decide first off what the founders are going to do with their share of equity in case they leave the company. You might be thinking that it is such a negative thing to start with, but Suresh made it clear enough that it is essential, irrespective it's positive or negative influence. The rationale is that things look very good at the beginning and everyone is absolutely positive and hopeful, but it is very likely that not all founders will share the same amount of enthusiasm and hope as time passes by. Reasons could be various, but it can just happen. One of the founders might just want to move out at some point. Such an event shouldn't derail your company/organization. This is why it is better (and pretty much essential) to have an exit clause in the initial agreement. The specifics can be anything. You might choose to compensate the person moving out based on the amount of years he/she has put in or the initial investment they came in with or whatever. Just be sure that it is there in black and white in an unambiguous way. You do not want a member of your founding team going out shouting, bringing the morale of the team down, now do you?
   
   
2. Do not hesitate to talk about money and stake. Finalize it ASAP
   
   This is sort of a follow-up point to the previous one. Whenever a startup is formed by a group of people, which is very common, specifically by a group of friends, which is even more common, there can be some stigma about discussions around stake and percentages. There might be one or two members who feel that talking about such things very early is a sign of lack of trust and is not really a good way to start with. As Sujai and Suresh said, this isn't really so. It is always better to finalize these matters at the earliest, no matter how delicate they are. In fact you should do it at the earliest because they are delicate. You do not want to be dealing with them in a crunch situation, which might just worsen the case. So act mature and deal with it, of course in a fair way.
   
   
3. Term sheets are very flexible. Use it to achieve a common ground during negotiation
   
   It is very common to come up with valuations vastly different from the investor's when you are trying to raise money. In some cases it can be so vast that the middle ground itself is unacceptably far for both the entrepreneur and the investor. For example when raising very early stage funding from an angel investor you might value your company at $1 Million, because you think your idea is kickass and totally innovative and you seem to have a perfect plan. OTOH, the investor values your company at nothing more than $100K, because all you have is an idea and your own expertise/experience. The average of the two numbers is just not acceptable to both of you. But both you and the investor might like each other (the frequency just matches) and you want money and the investor wants to invest. In such a case you can use the term sheet to achieve middle ground. You can tell the investor to give you money at your valuation, and say after a year or two when you go for a bigger round of funding with $5M or $10M valuation, the angel investor will get some perk - like he gets shares at a discount or he gets an outright payout (like interest or dividend on what he invests now) or whatever. But if you fail to reach that goal within the stipulated time, then the angel investor will get some more stake to match "his" initial valuation.
   
   This is just an example and terms can be anything that you can negotiate for. The idea is that if there is a good match between the entrepreneur and the investor, then the deal should not fall through just because of  differences in valuation. This of course doesn't mean that you should accept money at any crappy valuation that an angel or a VC is throwing at you. See the next point. Also you should not expect investors to put in money at insane valuations just because you got a very innovative product. Be reasonable.
   
   If you are new to Term Sheets check out this and this.
   
   
4.  It's a good deal only when both parties are happy
   
   Often entrepreneurs think that investors are out there to squeeze everything they can from the founders and that one has to be very cautious when dealing with investors. What both Suresh and Sujai said was that a good investor will make sure that the founders will get a good deal, even in cases when all that the founders (typically engineers) know about finance is addition and subtraction. The reason is that, if the VC "tricks" the founders into shelling out a lot of equity for a small sum of money, it is very likely that the founders will lose the motivation to keep going. If all that they own (collectively) is something like 20% or 30% they will soon feel like they are slogging for the investor and there is nothing in there for themselves. This is the worst thing that can happen to a startup. If the founders themselves are not motivated enough, the startup will come to a screeching halt in no time. Alternately, another "good" investor might come along and woo the founders away to form a new company where they really have sizable stake and actually feel like "founders". So both entrepreneurs and investors should go home happy after a deal. If you are not happy with the deal it's better you walk away. Sujai even went on to say that it's better not to deal with investors whom you don't think you can work with without two strips of aspirin, even when the valuation is close to what you want or even more. It's just not worth the headache it will eventually generate. But if your company is dying and you are absolutely in need of cash, then it's a different situation altogether.
   
   This piece of wisdom also applies to equity that is given to the co-founders and early employees. Do not be very stingy is handing out equity. Remember that when you get a co-founder or when you hire someone, you and that person are making a deal too. And like every other deal this one should keep both the parties happy. If you do not give sufficient equity to keep them motivated, eventually they will have no reason to stay with you. They will all be working their asses off. You better keep them motivated. Otherwise someone nicer will come along and take them away to their company with a much better offer. Also investors do consider the equity distribution amongst co-founders and the initial team. If they find it highly distorted they will very likely refrain from investing because they are not confident that the team will stick around. This doesn't mean you give out equity like a charity program. It is good (and often necessary) that you as the founder will retain a majority stake. This brings me to the next point.
   
   
5. There should be a LEADER  -- a MAJORITY STAKE HOLDER
   
   As mentioned in the second point, when a group of friends join hands to start a company, the general tendency is to distribute equity equally among themselves. For example 4 friends starting a company might end up owning 25% each. This is very very bad. Both Suresh and Sujai strongly emphasized that there should be a leader (call him/her a CEO or MD or anything) who is also a Majority Stake Holder. It is very common to hit deadlocks, get into conflicts, during product design or in cases when you have to pivot and it becomes essential that there exists a leader who can resolve these conflicts and take a decision. In the absence of a leader the conflict will persist delaying the process or decision making. Time being an essence in startups, such leader-less scenarios lead to the death of a startup, often with the people involved getting upset with each other. Some might say that they prefer to have a "flat hierarchy" and will take collective decisions. It all sounds good, but doesn't really work always. A leader doesn't mean a dictator. The leader will still invariably consult his team before taking any significant decision. Having a leader also makes interaction with outside parties easier. A customer or an investor doesn't have to deal with 3 to 4 people for the same thing. Doing the same work repeatedly is no fun for anyone (unless you are a body building freak).
   
   
6. LEADER should act like one. He/She is the face of the company
   
   This is something that my manager (also a very good friend and a mentor) at a previous company explained to me when I said I want to go out and join a friend in his start up venture.
   Being a leader is not just about holding a title or exercising your superiority during a discussion/conflict. The leader will be the face of the company and is as such thought of as a reflection of the company. When investors put in their money, they invest not just in the idea or the product, but also in the people and very specifically the leader. They expect the leader to steer the company towards success. It is the leader's ability that they trust. Consequently any wrong doing on the leader's part will reflect very poorly on the whole company. Integrity is of utmost importance. For example one might feel a sense of achievement in "tricking" investors with false promises or similar things. But it will create a permanent dent in the image of the company (and also that person). Also, the leader should command respect within the company by virtue of his/her actions and thought process. So choose a wise leader, think a lot before choosing one, especially when you are choosing yourself. (Yeah, the last line is my addition :) )
   
   
7.  You will miss your first deadline - Learn to live with it
   
   Almost every startup start's with a "perfect plan" and with the hope and confidence of "perfect execution" of that plan. You look at the money you have and you feel that you are good to go for a year. Then you look at the idea, discuss about the product, make a plan for the implementation, possibly meet potential customers and promise them a delivery date (mostly a very aggressive target). You then foresee that you are going to get money in 8 months or you will be able to raise good amount of money from investors in not more than 10 months. Isn't that fantastic? You are so safe..!
   
   But this rarely, if not never, happens in reality. Sujai spelled it out that each and everyone of us is going to miss our first deadline/target. So one has to learn to live with it, get over it and continue working towards the target. This doesn't mean that we all plan so badly. It's just that the startup environment is so dynamic. There is a lot of flux and uncertainty. It's better to come mentally prepared for shocks and than to come in overly optimistic and get bogged down by these unexpected setbacks.

tl;dr
  Here are the main points. If you find something interesting you can go back up and read it in full.

1. Start your company with an exit clause in the agreement with your partner
2. Do not hesitate to talk about money and stake. Finalize it ASAP
3. Term sheets are very flexible. Use it to achieve a common ground during negotiation
4. It's a good deal only when both parties are happy
5. There should be a LEADER  -- a MAJORITY STAKE HOLDER
6. LEADER should act like one. He/She is the face of the company
7. You will miss your first deadline - Learn to live with it

This discussion was followed by a product demo by Saptarshi from Quikast. They are building some cool stuff. I wish them all the best.

A testimonial to one of the best mentors I have had

I have previously written about my internship at IBM in this post and this post. The first post makes it pretty clear that the internship was a very productive (very likely most productive) part of my engineering student life. The second post briefly talks about Gautham Pai as being my guru. Both are very much true and I am thankful to Gautham for having provided me the opportunity to be on the Eclifox team. Although I have expressed my gratitude to Gautham a few times, I never really wrote it down anywhere, neither in my blog nor on any social n/w site. A few months ago Gautham started his own company Jnaapti, which is a technical skill development company. Basically he is doing what he is very good at, i.e. bringing the best out of anyone willing to learn and succeed. As part of the company operations he conducts training sessions for various corporate clients and also mentors engineering students helping them understand their subjects better using some useful project as a means of teaching. He is experimenting with various educational methodologies and different ways to teach/mentor students remotely. I am very confident that his efforts are going to change the landscape of computer science engineering education vastly. Having been mentored and guided by Gautham at various points, I thought now would be a good time to pen down a testimonial and finally put that gratitude in words. So here it goes :

Every software engineer who has been in the industry, even for a small amount of time, surely knows the gap between academic teaching and the industry requirements and the initial uphill task of coping up when a fresh engineering graduate joins any company. It would not have been different for me, if not for Gautham's guidance as my senior at college and my mentor at IBM during my internship. With Gautham's mentoring, the internship was probably one of the most productive spans in my 4 years of engineering studies and also the one packed with maximum learning. Additionally it opened up a number of opportunities for me which I previously did not even know existed - like my participation in Google Summer code and later being with the Mozilla community for quite some time and many others.

Traits like general intelligence, theoretical understanding of the subjects and the ability to solve problems are undoubtedly necessary, but not sufficient. An engineer should be able to think not just about the next line of the code that he is going to write but also think about product that he is building or helping build. He should also know that any technology is just a tool to get the work done and not something that limits you. That way you just pick any new tool that you come across and find useful or necessary for the job. This also means you keep up with the latest happenings in the tech world via blogs, articles, mailing lists etc. Above all the zeal to do more, to come up with new ideas, to start executing those ideas and the persistence to see them through, in the course carefully managing a team as a leader, are what will make an engineer truly successful.

I, of course, did not realize or understand all this during my internship. These were not handed out to me in bulleted list of To-Dos. Rather it was all nicely baked into the project that I (with a few friends) carried out and I was set on the right path without any additional effort. More than that, all of this was demonstrated to us in practice by Gautham himself and some of it just rubbed off on me, making me a much better problem solver, much better product developer, much better ENGINEER, than I would have been otherwise. Now when I look back at my internship days and my days as an engineer after that, I clearly see the impact and how much it has helped. That's Gautham and his way of mentoring. Thank you Gautham for letting me be part of the Eclifox team and for your guidance till date and the future too. :). (For the readers : Eclifox was what we built during our internship - http://buzypi.in/2007/10/11/eclifox-bringing-eclipse-to-the-browser/  and I am very proud of it.)

 In case you are wondering where did all of this finally land me, here is my linkedIn profile. :)
Keep up the great work Gautham. Wish you all the success and happiness.

Transactions - both single node and distributed - are hardwired in Windows - since Win 95

Transactions or "Atomic Transactions" to be precise, are very well known to anyone who has worked with databases. With the recent advent of NoSQL databases and the CAP theorem being used/abused by anyone and everyone, words like "consistency" and "transactional model" have become run-of-the-mill jargon. But what is actually interesting is that the concept of transactions or transactional model goes beyond our typical RDBMS. Things get even more challenging when we try to achieve transactions in a distributed system. Because transactions inherently lock the resource(s)/data they are operating on until the transaction completes, those resources can become inaccessible altogether very easily in a distributed setup if one of the node fails or if there is some problem with the network or any such thing, there by increasing the complexity of implementing distributed transactions by many folds compared to transactions on a single node.

Today I was trying to figure out if there is a way to "simulate" (albeit it will be very crude) some sort of transactions in my application which uses MongoDB (which doesn't support transactions by design - to avoid the locking mentioned above, although ironically there is a global write lock..!!). Searching on the internet lead me to this blog of a Raven DB developer. The author there mentions that RavenDB supports both sharding and transactions, which means it has implemented distributed transaction support. At first read I was pretty impressed (this was the first time I had heard about RavenDB). Before I could ask the author about the implementation details I saw a comment in which the author had mentioned that they use DTC (which again was a new thing). Turns out DTC, Distributed Transaction Controller, is a service that is baked right in the Windows OS itself, that too dating back to the Windows 95 days (wow.. now I am impressed with Windows..!). Here is the MSDN article describing the service.

The MSDN article clearly explains the basics of distributed transactions and how it is modeled. What is worth noting is that, by abstracting out the code for carrying out distributed transactions as a service, multiple resource managers (like different databases, queue servers, file servers/managers, etc..) can all interact together in a single transaction. For example, lets say that you have web application where in a client request results in a job being picked up from a queue for processing and simultaneously you update the status of the job in a DB and also create a new file associated with the start of the job. Very evidently all the three resource managers and the web application itself can be (very likely will be) on different nodes. With something like DTC you can easily create a new transaction, send across a commit message and you will get a success notification only if all three actions were successful or else none of the actions go through. Of course, this is possible only if all the three resource managers involved here adhere to the Microsoft's DTC specification and provide the necessary interface to work with it.

The previous example might make DTC appear like this Jason Bourne kind of super dude who can take care of all the heavy lifting and also do it very efficiently. But remember even Bourne gets shot at and also loses his girl. So DTC is not fully immune to problems either. Here is one blog post titled "My beef with MSDTC and two phase commits". It is definitely worth reading. Note that my impression about DTC is purely based on reading the documentation. I have not written a single line of code using DTC.

Microsoft's Virtual Wifi adapter ( or virtual wifi card) -- cool technology

I wasn't aware of the very interesting research on Virtual Wifi Adapters that Microsoft guys have been carrying out. Apparently they have been doing it for quite some time now. What this research group is trying to do is basically allow us to have an unlimited number of "virtual" wireless cards on our computers, each connecting to a different wireless connection, and all of it using just a single physical card. That is some awesome stuff.. !

A couple of days ago I opened up the Dell Support Center tool on my laptop and it popped up a message saying a device on my system is in the disabled state. I was pretty startled to see that, as pretty much every device on my laptop is used by me daily. On clicking the message it told me that the disabled device is "Microsoft Viritual Wifi Miniport". That did not make any sense to me. I had absolutely no clue about this device.

Searching the internet led me to this Microsoft page (along with several others, of course) which gave me a fair idea of what this device might be, but nothing concrete. It was this fine article on istartedsomething.com that clearly explained what this is all about. In the same article the author tells us that Microsoft has been carrying out research in this regard for a few years now. But nothing was given to end users until Windows 7 baked in this wifi card virtualization natively. And not just that, all WiFi card providers are expected to add support for this virtualization in their drivers if they want their drivers to be properly signed digitally and recognized by Windows during installation. I say that is "Wicked cool".. :)

About the technology itself, it can be described as a way to make "software copies" of your Wireless card and use those copies to "connect to multiple networks simultaneously".  Although research prototypes can apparently create any number of virtual devices over the single actual hardware device, Windows 7 limits it to just one copy/virtual device.

This whole research is doubly fascinating.

First because the applications of this research work are very interesting. One such application is explained in the article mentioned above. It talks about being able to connect to an existing wireless access point with your laptop and at the same time making your laptop a wireless access point in itself. It means, if someone is far from the actual access point and your laptop happens to be closer, he/she can connect to your laptop instead and your laptop will forward their connections to the actual wireless access point. Of course, this can only happen when the two laptops involved are in the same security/trust group. I wouldn't go on and connect via some random stranger's laptop. It is like letting that person look at all the data coming in and going out of your computer over the internet (or network in general). Despite such caveats, this is very much a practical use case. May be you wouldn't use it to be a hop in the network (or more like a virtual signal booster), but you may use it to make P2P/direct connections with another laptop close by for sharing files instead of doing over the wireless LAN. Or, if access to wireless network is possible only after you authenticate via certificate (like in a corporate setup) and the certificates can be put only one of your laptops (the official company laptop), the connection sharing will indeed come in handy.

Secondly, and more importantly, the complexities associated with this are lot and that makes it all the more exciting. If we delve a little deeper into what this virtual adapter is and how it works, we will see that it is actually a piece of software sitting between the actual device driver and the rest of the network stack (i.e. all above the MAC layer in the OSI model). This little piece of software is supposed to appear as one or more "devices" to the OS and hence it invariably has to have its own device driver. That is the "Virtual WiFi Filter" driver or VWifi driver. This VWifi driver tells the OS that there are multiple wireless cards and the OS then allows the user to connect to different available wireless connections via these virtual cards. But note that all this time, there is only one physical card and hence at any given point in time that one physical card can be connected to (or can communicate with) only one wireless network. It is the job of the virtual adapter software to cycle over all the virtual wireless cards and service the network requests made through them using the one physical card, in a time shared manner all the while keeping it transparent to the user. Although it sounds very similar to the kernel's process scheduling which makes use of the single processor in a time shared manner, this is actually somewhat different because of the way wireless networks work.

Note that different wireless networks behave differently. They might be operating at different frequencies, they might be having different authentication/encryption schemes, the bandwidth might be different and probably many other factors that I can't think of right now. So every time the actual wireless card switches to a different connection, there can be a shift in all or some of the above mentioned attributes. The card might have to step up or down its operating frequency, change to a different encryption scheme and all of this on the fly. Now that is a lot of work to do and in fact all of this switching can just drag the network performance to the ground. This makes the design and implementation of the virtualization software pretty challenging. This and many other challenges/caveats are discussed in this Microsoft Research's FAQ page.

I have been very excited about this research work ever since I read it and have been meaning to try out writing some network code using the virtual adapter. Sadly I have zero experience in network programming in Windows and currently don't have enough time to read up all of that. I hope such a thing will come up in Linux some time soon, if it isn't already there.

Computer hardware test/analysis tools

Today I happen to look into the causes for over-heating of my Dell Studio 14 (1458) laptop (i7, 720QM, 4GB RAM, Win 7 with ATI Mobility Radeon  HD 5450 - 1GB) and came across these various tools which people use to test/analyze their hardware.

ThrottleStop
CPUmark
CPU RightMark
Furmark
ORTHOS
HWMonitor
RMClock - Undervolt processor.
GPU-Z

I am yet to use any of these, but I do hope to run them soon and post some results here, JFK. :)

Machine Learning online course - Class 1

As I mentioned in my previous blog post I am going to use this blog as my course notebook. All posts related to this course will have a "ml-class" tag, just in case.

The first class was all introduction stuff, as expected. What I really liked about this class was the real world examples used. They were very useful in understanding what to expect from this course. Anyways, here are my notes for the class :

Initially there were formal definitions of Machine Learning, one of them with rhyming phrases. I think we can skip those parts.

There are two types of learning algorithms - Supervised and Unsupervised

1) Supervised - A bunch of right answers are already provided to the machine. The machine has to try and get more of those right answers for the next set of questions.
The data provided already has some sense of direction or some sort of inference. It is like a set of input and output values and we have to predict the output value for a new input value given based on the existing data. Here the resultant dimension is known and defined. We have to find a suitable function which when applied on the given set of input values will best match the corresponding output values. This same function will then be used to predict output values of new inputs.
  - Eg :
    1) Predicting the price of the house of a particular size given the price of various houses of varying sizes.
    2) Predicting whether a tumor is malignant or not based on the size given the answer for tumors of various sizes
 
  Different Types
    1) Regression - Machine tries to predict a continuous valued attribute, i.e. the value of the attribute whose value we are trying to predict belongs to a continuous range. (The house price example)
    2) Classification - Machine tries to predict a discrete valued output, i.e the range of values is a finite small set of discreet values. (The tumor example)
   
2) Unsupervised learning - The data set given doesn't provide anything conclusive. It is just a data set and we are expected to make sense out of it and come up with the inference. There is no expected or target domain defined. It has to be inferred by examining the data. Very likely several target domains will be defined over the course of analyzing the data.
  - Types :
    1) Clustering of data -
      -Eg : Google news example. Several articles about the same topic are grouped/clustered together. The input data set for this is just a bunch of articles (which is just one dimension/attribute). The other dimension (which is the common topic) itself is not well defined, i.e. the topics are not known before hand. We keep defining them as we go. So we have to infer that some of the articles belong to the same/similar topic and can be grouped together.

That's it. Done with the first class. YAY.. !. I am yet to attempt the review exercises. I have decided to go for review exercises of this and the next class together.

ಹರಿಃ ಓಂ.

Starting with the Stanford online Machine Learning class

Today I am starting with the Stanford online Machine Learning classes, taught by Andrew Ng. This is my second attempt at learning machine learning, via the same medium, with the same professor and under the same program. This course has been available online since about 3 years, albeit the current one is much more polished and very meticulously designed for online learning, unlike the old ones which were just recordings of the actual classroom teaching. Two years ago (i.e. in 2009) I, along with some of my friends/colleagues (from different teams) decided to learn machine learning at our office. Quickly a team of interested folks was formed. There was a friend who had completed his post-graduation in US and he had studied and AFAIK also worked on machine learning stuff. Then there were two other friends who had completed their post-graduation from IISc. Then there was my boss, who also had done his post-graduate studies in US. Apart from these folks, there were some smart folks not keen on a post-grad degree. And finally there was me. Yeah. me too. :). The idea was that all of us would watch the video lectures and one of us would present a session weekly.

We started with a bang, with an initial class on basics of statistics and probability, taught by that experienced and well-learned friend of mine. He called it "Statistics 101". It was good. There was no video lecture for this. So it was useful for me as my math needed a lot of dusting. This was followed by the first video lecture, which I believe had introduction to ML in general and also introduced the Linear Regression with one variable. It was taught/presented by another friend who had finished his post-graduation from the prestigious IISc. It went well too. (A side note : This friend seemed to have picked up the teaching traits/style of his IISc professors and I was getting the feeling of actually attending a class in IISc). More importantly most of us had watched this video and read the lecture notes once, before hand. All in all, the plan was on track. Till now.

But then it all fell apart from the subsequent week. The meeting time clashed with another actual work related meeting for some. An upcoming release caused a couple of us to give this a skip. Then after two missed meetings, the interest had pretty much waned away and the ever increasing work load did not help anyone. After postponing the meeting many times and several declined responses for the calendar invite, the "Statistics 101" friend, who had setup the meeting, removed it entirely from the calendar and Machine Learning studies ceased to exist officially too.

Now, a couple of months ago when I found out about the ML class being offered again, in an entirely new package tailor made for online learning, I decided that this time I would take it seriously and learn ML for real. I signed up immediately, not just for ML, but also for the DB and AI classes that are also being offered simultaneously, that too for the "Advanced Track" in all of those (which now looks like a bad move. I don't think I will be able to take up the AI class). Although classes officially started on Sunday/Monday, I could not get to until today. I just kept postponing it. Thanks to the review questions deadline, it came to now or never situation and I finally took the bold step of starting with the ML and DB classes. Luckily DB class doesn't have any assignments due on 16th Oct. So I just watched the introductory video. Then I started with the ML video lectures, which I am going through right now. I hope to keep up with the course schedule and get to all assignments on time, although they allow two delayed submissions. More importantly, I hope to learn something that I can use at my work right away, because I know there is scope for that at work.

I intend to continuously blog, as I go through the course. This will sort act like my notebook and also keep my blog alive and updated and also have some meaningful content. :)

Good luck to myself. .. !
Hari: Om.
ಹರಿಃ ಓಂ.

"List all Tabs" in Firefox 7 has different backgrounds for onscreen and off-screen tabs

A few days ago, my Firefox automatically updated to version 7.0.1 and ever since it's one new feature (which hasn't been advertised as a feature at all) has been bugging me; because I was not able to understand what it does.!. The feature in question is the different background color for some tabs in the "List All Tabs" menu - The menu that you get when you click the small (almost inconspicuous) inverted triangle between the "New Tab" (+) and the "Window minimize" (-) buttons.

The first time I saw the differential background I thought it was like the read and unread tabs, like one of the tab management add-ons does. But no. No matter how many times I read the page in a tab, it's background color did not change.

The next thought was that it corresponded to background tabs which are lazily loaded, i.e. the page is not actually loaded from the internet until you bring that tab to focus. But no, it was not even this. Even after several visits some tabs stayed with dark background.

No amount of searching on the internet helped at that time and I had to calm myself down and let go off the quest for this eternal answer. Finally today I gave it another shot with some variations in search strings and I landed on this page which lists all the changes in version 7.0. Here I started searching for any bug related to tabs and finally got the right bug. This bug states the purpose of differential background color in the tabs list.

As the bug states, the dark colored (highlighted) tabs are the ones which are currently displayed on the screen in the tab bar and the light colored ones are scrolled off the screen (horizontally). The rationale is that, this will make it very easy to figure out where a particular tab that you are looking for is, in case you are confused about it's position.
I am yet to see the feature being actually useful. Nevertheless, for the moment I am happy that I know what the feature does. :)

Watch points for variables in Ruby - Object#freeze

Almost every programmer knows about watch points. Especially the ones doing native development with C/C++. Watch points were really helpful to me when I was working with C/C++. They were, sort of, my go to weapons whenever I wanted to understand how some third party code worked. It was something that I dearly missed when I started with Ruby. I am fairly new to Ruby and I have never used the ruby-debug (or ruby-debug19) gem, because until today simple print statements were sufficient most of the times.

Today I was at a loss as I was unable to figure out where a particular hash variable was getting two new key-value pairs in it. It was an instance variable with just an attr_reader defined. So obviously a reference to the instance variable was being passed around to the place where it was being modified. So my initial idea of writing a custom write accessor method was probably not going to work (did not try it). That is when I came across this http://ruby-doc.org/docs/ProgrammingRuby/html/trouble.html#S3. The last bullet point in that section has the answer.

You just freeze the object/variable that you want to watch by calling the "freeze" instance method on that object and anyone modifying that object after it's frozen will cause an exception to be raised giving you the precise location of where that modification is happening. This isn't probably as elegant as running a debugger and setting a watch point but it gets the work done nevertheless. RTFM after all..!! This tool is definitely going into my belt. :)