22 Feb, 2010

You know you hire the best talent when people want to pay to get in :)

Posted by Bhavin Turakhia | (5) Comments

At Directi we hire some of the best talent in the country. For tech hires we look favorably upon applicants who solve some of our coding puzzles. One of my colleagues just came across this amusing link on LimeExchange where someone is willing to pay for a solution to one of our puzzles -

http://www.limeexchange.com/software-development-freelance-projects/6188.lxp.Team-selection-code

We must be doing something right if candidates are willing to pay to get in

11 Jan, 2010

Notes on Kestrel – the open source twitter queue

Posted by Bhavin Turakhia | (4) Comments

Kestrel is a simplistic, high-performant, loosely ordered, reliable queue that twitter uses as the backbone of its messaging infrastructure. I spent sometime today morning studying it and here are my notes -

• Extremely small footprint (<2000 lines of scala code)
• JVM based (written in scala)
• Servers in a Kestrel cluster have no communication amongst one another. Clients simply pick a server at random for gets and puts. This results in a loose ordering of the messages which maybe quite ok for most messaging applications
• There is no replication
• While the queues are maintained entirely in memory, they are written to a journal file to prevent data-loss due to a server shutdown or failure (quite similar to redis)
• Supports a reliable read, where a client can fetch an item from the queue within an “open” and “close” block, and if the client disconnects before sending a “close” the item is re-enqueued
• NIO based using Apache MINA
• Supports item expiration

References

• Kestrel Home – http://github.com/robey/kestrel
• Kestrel Documentation - http://github.com/robey/kestrel/blob/master/docs/guide.md

11 Jan, 2010

The best programmers in the country battle it out at Directiplex

Posted by Bhavin Turakhia | (4) Comments

On January 10th 2010, we witnessed the awesomest programming teams from campuses all over India battle it out in person at our Mumbai headquarters of Directi. 639 teams of three each, had registered for the CodeChef Campus SnackDown to be crowned as the best coders in the country. The first round of the SnackDown took place on 21st November 2009. We then flew the top 7 teams from various corners of India to Mumbai to prove their mettle.

I was most excited with the results – the winning team comprised of the youngest programmers of the lot – three juniors in their 2nd and 3rd year at IIIT Hyderabad, who overtook their mentors and seniors and took the first place . You will find details about the winners and a recap of the events in the codechef blog post here

10 Oct, 2009

Judging Humility in an Interview

Posted by Bhavin Turakhia | (16) Comments

At Directi, one of the most important qualities we value in potential candidates is humility. Infact, in the constantly dynamic landscape that is our industry, the only way to keep up is to know that you don’t know [it all]. Infact I include humility as an important attribute in my document on Skills and attributes that a good developer must possess.

I never really got a handle on how one can judge humility of an individual, until it struck me recently. A technique that has actually effectively worked in the past, but I have never paid attention to it. Humble individuals are always respectful, and do not have an air about them. One of the ways I have been able to distinguish individuals who are not humble are those who feel specific interview questions are beneath them to answer. We have all seen this category. Often I will fire an extremely easy or fundamental or theoretical question in my interview to a candidate – and they will respond with a short answer – accompanied by negative body language or verbal cues or in some cases a direct rebuke that essentially states – “Are you kidding me? Why are you asking me such a question at my level. I am above this type of questioning.”

There are only two reasons (not mutually exclusive) for this type of a response – (1) Ignorance – the candidate does not know the answer to the question and instead of acknowledging it he prefers to go down the path of “this question is beneath me”, (2) Lack of Humility

At Directi -

• no question is ever beneath someone
• all of us know that we have a lot to learn
• none of us feel uncomfortable in acknowledging something we don’t know
• all of us are respectful

So if you want to judge the humility of an individual during an interview – ask a couple of really easy questions – and see how they respond

Do you feel you would fit into our work culture? Apply at http://careers.directi.com

21 Aug, 2009

Directi Campus Recruitment 2009-10 off to a great start

Posted by Bhavin Turakhia | (222) Comments

We just began our campus recruitment exercise, and thus far the first week has been a resounding success. This year we plan on visiting upwards of 60 institutions, engineering and management, across 4 countries, in our search for the best, kick-ass talent available. Check out our Campus drive page for further details on the campuses we will be visiting. We will continue to add entries in there as we fix the dates.

This week we visited 5 colleges. The process – an online test at CodeChef.com, a personal interview,a telephonic interview, and then a visit to our uber cool HQ at Mumbai for the final rounds. We hade several hundred students compete across multiple cities and institutions for the top spot in a fast-paced, fun hackfest at 5 different venues. So far 2 offers have been made. Our talent scouts – Ankush, Nishant, Anup and Anirban had fun, met a ton of interesting people and generally spread the word. Here are some pictures  and trivia -

3 May, 2009

Skills that make a good developer

Posted by Bhavin Turakhia | (3) Comments

Joel Spolsky captures the essence of a good (read: recruitment material) developer in his succint mantra – “Smart and Gets Things Done“. My own personal part-plagiarised part-modified version has always been – “Smart, Takes Initiative, Gets things done, Paranoid about Perfection and is a Nice Person”. I believe Joel’s shorter version does not capture all these aspects – for instance being Nice and being Smart are mutually exclusive.

Both versions (mine and Joel’s), in their brevity, have a quotable-charm, but fail to provide a more detailed perspective. As a parallel effort, I wanted to list down, in micro-detail, a significantly more extensive document, of skills that I find good developers possess.

The current work-in-progress version of it has been put up at - What skills doth a good developer possess? within our Wiki. Granted that all developers at Directi do not possess all the skills listed. However the document serves as a “skills-to-acquire” list for our existing team, as well as a reference list for aspiring applicants. As someone who wants to join our organization, you should have several of these mastered, and be prepared to tackle the rest.

Excerpt from the document - What skills doth a good developer possess?

• Algorithmic skills
  • Understand and dissect complex problems quickly
  • Understand trade-offs between space / time complexity
  • Come up with solutions with minimal space / time complexity
  • … <snip>
• Data Structures
  • Basic Knowledge of data structures – Hashmaps, Binary tree, B-Tree, B+Tree, Linked Lists etc
  • Understanding of trade-offs between various data structures etc
  • … <snip>
• RDBMS
• Caching
• Networking
• … <snip>

For further details visit the complete document - What skills doth a good developer possess?

To apply for a tech position at Directi visit our Careers Portal

15 Feb, 2009

Pros and Cons of Diskless Servers booting off a SAN

Posted by Bhavin Turakhia | (3) Comments

In our constant efforts towards Architecture nirvana we are often faced with the question of whether a cluster of application servers should have their own hard disks or should they PxE boot off a SAN. This short article explores the options

Notes

• If a cluster of machines have their own OS hard drives, and one cannot afford a machine going down then each of the machines would need a RAID 1 config which requires a RAID card and 2 hard drives each resulting in a considerable cost (high-cost)
• In the scenario where multiple machines boot off a partition on a SAN device, the machines do not need any harddrives. However if for any reason the connectivity to the SAN goes down or the SAN device itself crashes (rare) then all the machines in the cluster would be down (marginal redundancy concern)

Conclusion

• In the scenario where the data partition of the cluster of machines is residing on a SAN device, it makes sense to boot those machines off the SAN device too since as such the SAN going down would render the entire cluster useless, and this way one can save the cost of 2x’n’ hard drives and ‘n’ RAID cards (assuming we have ‘n’ machines in the cluster)
• In the scenario that a cluster of machines does not have any data on a SAN device, one may want to invest in hard drives for the machine itself, since a downtime of the SAN device will not render the cluster inoperational. Additionally, if the cluster consists of 10-15 machines, the cost of 2 SATA drives and 1 RAID card per machine may not be much higher than the cost of a SAN device if one needs to be exclusively setup for these machines.
• This may change however if one has spare and redundant SAN devices lying around, with spare capacity in their network
• Ideally if a cluster of machines are to PXE boot off a SAN, one should try and ensure that the boot partitions are spread across separate SAN Devices each of which are accessible through different network paths, so that the downtime of any given SAN Device does not compromise the cluster

4 Feb, 2009

Introduction of New TLDs will NOT increase costs for Trademark Holders

Posted by Bhavin Turakhia | (4) Comments

As an ICANN accredited Registrar, a consultant to Registrars and Registries, and an erstwhile chair of the Registrars Constituency, I am very closely involved with the ICANN bottoms up consensus processes. Amongst the most interesting endeavors of ICANN, and a fundamental element of ICANN’s goal is the creation of new gTLDs. Some of the recent comments on the new gTLD applicant guidebook seem to suggest that creation of new gTLDs will result in a cost increase to existing trademark holders who will have to register their trademark in various TLDs as a defensive mechanism.

Paul Stahura published a great report demonstrating that trademark holders have historically not been blocking their names across multiple Top-Level Domains (TLDs). I have always been a fan of number crunching—”numbers never lie”.

Since Paul has already done a remarkable job of statistical analysis, I am going to wear my theorist hat and prove a reworded form of the Hypothesis using logical deduction and common sense.

Hypothesis – Introduction of new TLDs will not increase the sum total registration cost that trademark holders need to spend on domain names.

Methodology – Logical deduction.

Fact:
There are currently over 280 TLDs of which a little over 250 are ccTLDs in the IANA root zone.

Assumptions:
Individuals and companies spend money for economic gain. Therefore whether a registrant is an organization, a speculator, a cyber squatter, or a phisher, their purpose in registering a domain name is to derive economic gain that outweighs the cost of the domain name.

Description:
Let us start by analyzing why one would want to register a domain name in each additional TLD outside of the primary TLD that they use for their business. Lets take the example of a company—Extra Cautious Inc.—who uses the domain name extracautious.com. They now need to evaluate whether it makes sense for them to register the string extracautious in other TLDs. Here is the reasoning that the CFO of Extra Cautious Inc. would go through.

Traffic expectation:
It makes sense for the CFO to register extracautious.biz or extracautious.info in case an adequate number of people are expected to type in extracautious.biz in their browser directly. The number of type-ins needed to make it worthwhile to register this domain name is negligible given that .biz and .info domains cost substantially under $10 per year. If there is a clear traffic value to be derived, then as Paul has pointed out in his elaborate report, the registration of this additional domain name is not a cost but rather a revenue generation opportunity for Extra Cautious Inc, who otherwise would have missed out on the hits. Therefore in case of a Traffic Expectancy the hypothesis above holds true.

Source of traffic:
A typical website gets traffic in two ways. Either through direct type-ins, or via hyperlinks. Both the former and the latter are primarily a function of the domain name that an organization promotes. When Extra Cautious Inc. promotes extracautious.com as its website on its stationery, advertising etc., it expects people to type in that domain name to reach their website. It also expects search engines to index that domain name, and other directories and websites to link to that domain name. In other words traffic through type-ins and hyperlinks would directly end up on their website.

Next let’s explore the possibility of direct type-in traffic on other TLDs. Users on the Internet type-in a domain name directly if they expect to find the website or information they were looking for. The most common case of this is appending a .com to a company/product name. It is common behavior on the Internet to append a “.com” to the end of a company name to look for its website. In some cases people even append a .net or a .org. However, given Google magic, that is the limit of a user’s patience. One does not have to be Einstein to conclude that no users are trying out 280+ TLD combinations to get to a company’s website. It can therefore be assumed that if 50 new TLDs, each quite different sounding from the other, were to be launched, that users on the internet would not begin to iterate through those 50 TLDs to find a company.

ccTLDs type-ins:
In fact the only other type of domain that tends to get type-in traffic is ccTLD equivalents. This is based on two behavior patterns. Users seeking for a company that they know is based in India, could try to reach that company’s website by appending “.in” to the company name as a last resort after attempting a .com / .net / .org search. Similarly, users from India, who are used to seeing “.in” domains may append “.in” to a company name (e.g. dell.in) to find its local website. By this logic, many companies should ideally have registered their domain names in several ccTLDs, especially those of highly populated countries like India and China. Yet the TLD Zones of these ccTLDs have little overlap with the global trademark registry as well as with the .com zone, barring generics and some fortune 500 companies.

Many new TLDs have a specific purpose:
Add to this the fact that many of the proposed new TLDs have varying creative purposes. We have heard of business models such as .wiki, .blog etc. which have such specific purposes. Type-in traffic on those TLDs for a specific trademark such as Extra Cautious Inc, is highly unlikely, since users would not expect Extra Cautious’ website to be available at extracautious.wiki.

No traffic expectation:
Going back to our first point—in case no one is expected to type in extracautious.newTLD, it makes little sense for Extra Cautious Inc. themselves to register extracautious.newTLD. This for instance applies to specific TLDs like .aero. Since extracautious is in the business of making fireworks … they do not expect any of their existing or potential customers to type in extracautious.aero. Similarly since Extra Cautious Inc. largely operates in the US, it may block extracautious.us but chooses not to block extracautious.in. The likelihood of individuals typing in extracautious.biz and extracautious.info ad-hoc is ZERO so they do not need to block those domains. If there is a traffic expectancy on any TLD option, it is a no brainer to block those domains since the potential revenue would outweigh the cost.

What about cybersquatters:
The next argument typically made by IP constituencies is that if a speculator / cybersquatter / phisher were to register extracautious.newTLD then they could create nuisance value and the company may be prompted to block their domain name (defensive registrations) to prevent this nuisance value.

It is important to understand that CyberSquatters / Speculators / Phishers register non-generic trademark domain names for specific economic reasons. Let’s explore these.

Type-in traffic on trademark names:
If a trademarked domain gets type-in traffic, a speculator maybe prompted to register this domain to monetize the traffic. However in this case, as we have discussed before, a trademark holder themselves would wish to register it prior to a speculator since the revenue outweighs the cost. If a speculator can earn more than the cost of the domain name by simply monetizing traffic to that domain name, then it is assumed that the actual trademark holder can earn significantly higher revenue and therefore is not bearing any cost by registering his domain name in that TLD. Therefore Extra Cautious Inc. chooses to register extracautious.au since it has an office in Australia and expects type-in traffic from Australia. This is not an extra cost for them since through this additional domain they get traffic that they would have otherwise not received.

Defensive domain registrations to prevent misrepresentation or blackmail:
Some folks argue that even if a domain name has no traffic potential, speculators can choose to register the same to either fraudulently pretend to be the trademark holder (phishing etc.) or otherwise to try and sell the domain name to the trademark holder for a premium. Let’s analyze both these arguments.

Mr Scrupulous registers extracautious.info and puts up a website on it to sell fireworks. He intends to spam thousands of users, pretending to be Extra Cautious Inc. and leverage on the advertising campaign of Extra Cautious Inc. to earn money. It can be argued that if Extra Cautious Inc. had registered their .info domain name this could have been prevented. However this argument is flawed, since Mr. Scrupulous could have registered extracautiousweb.com, extracautiousonline.com, extracautiousfireworks.com, extracautiouscrackers.com, extracautiousoffers.com, extracautiousshop.com and a gazillion other variants within the .com space itself. By this logic the CFO of Extra Cautious Inc. would need to register every combination of extracautious in the .com and .net and .org TLD spaces. Therefore new TLDs are no more expensive than existing TLDs when it comes to protecting one’s trademark from identity theft/phishing. In fact I would go so far as to submit that phishers and spammers would rather register <company&rt;online.com or <company&rt;web.com or some such variant in the .com TLD space in order to commit identity theft, than to register a .info / .biz domain name, since .com domain names are easier to relate to for users. While I have conducted no statistical analysis, gut feeling tells me that one will find more variants of Fortune 500 company brand names in the .com TLD than defensive registrations of those trademarks in all other TLDs.

Let’s take a look at the second argument, wherein Mr. Scrupulous registers extracautious.info with the sole purpose of reselling it to Extra Cautious Inc. for a profit. This has already been covered in our previous assertion. The CFO of Extra Cautious Inc. would only buy extracautious.info at a certain price if the expected profit from the purchase was higher, in which case the purchase does not result in a cost increase. Additionally, Extra Cautious always has the option of filing a dispute, instead of purchasing the domain from Mr. Scrupulous, and this knowledge is by itself sufficient to prevent widespread blackmail of this form. If extracautious.info is getting no traffic, then Extra Cautious Inc. has no reason to purchase extracautious.info either directly or from Mr. Scrupulous

Conclusions:

• Trademark holders have no reason to register a domain name in a newTLD if the domain name is not going to get any traffic
• Speculators have no reason to register a domain name in a newTLD if the domain name is not going to get any traffic, since they will be unable to generate revenue from it or sell it to the trademark holder
• Spammers and phishers have adequate options for registering similar sounding domain names in existing TLDs without having to bother with new TLDs
• Thus, it can be concluded that the Introduction of new TLDs is not increasing the sum total registration cost that trademark holders need to spend on domain names

20 Oct, 2008

Denying a Denial of Service attack

Posted by Bhavin Turakhia | (2) Comments

At our size, not a day goes by without being under some DDOS attack on atleast one of our services. They are now an assumed constant. Most of them do not impact us in any manner. Some of them manage to make a dent. Others can result in unscheduled downtimes. Here are a set of tips in no particular order that we have learnt the hard way to improve your infrastructure resilience -

• Monitor your traffic at the network adaptors and switch ports using MRTG and Nagios, and ensure any spikes result in immediate alerts and escalations
• Ensure that your switches, routers and other devices can provide you with packet capture and other pertinent monitoring information
• Since DDOS attacks originate from multiple source IP addresses, typical DDOS mitigators use heuristics to determine bad traffic patterns and block those source IP addresses. This can result in blocking genuine traffic patterns / sources. If instead you can identify the traffic pattern of the DDOS you can block that pattern atyour firewall, as opposed to blocking source IPs. For eg, we have had UDP attacks on our DNS Servers where the UDP packets were of a fixed length. We blocked packets matching that configuration and thwarted the attack
• Last week we got hit by the mother of all DDOSes – a 4.8 GBps sustained attack on one of our deployments. An attack of this size is cannot be thwarted by regular DDOS mitigators or source blocking. The only choice we had was to null-route our destination IP Address. Try and ensure that your service is bound to multiple IP addresses, with a low TTL in your DNS server to allow you to modify your DNS entries rapidly. Many a times DDOSes target a specific set of IPs in which case you can simply give up that IP address and substitute it with another one. Sometimes DDOSes may target a domain name in which case the attack may be visible on all the IP addresses that the domain name resolves to. In this case, if your app-design can allow for a modification of the service URL – it would make it easy to block the DDOS. Otherwise your best bet would be to modify the ip addresses in your DNS for that domain, and hope that the DDOS clients are caching DNS resolution and the attack will not migrate to your new IP addresses. It is also highly recommended that your application have multiple different service access URLs and that you provide different ones to different users. That way a DDOS may not affect all your users.

This is a hurriedly drafted article and there is significantly more knowledge that we have amassed over the years on this subject. If I find some additional time I will likely pen it down in a more structured format on some other day.

1 Oct, 2008

The Game of Business

Posted by Bhavin Turakhia | (5) Comments

I delivered a presentation titled the Game of Business at the Proto.in conference in 2008 and subsequently at IIT Kanpur’s Megabucks event.

Visit our wiki at http://wiki.directi.com/x/BwCK to view the video of this presentation and download the slides. At Directi, we believe that Business is like a game. This presentation covers principles that embrace this philosophy and that continue to be instrumental to the success of Directi.

I finally managed to obtain a copy of the video of the presentation and hence am posting this entry quite late. I believe this is by far one of the best presentations I have delivered in terms of value and the importance I personally attribute of the concepts I expound in the presentation to the success of our company.

Comments / feedback are solicited and welcome