Archive for the ‘Personal Life’ Category

mytop to monitor mysql

With the basic operation of mytop covered, let’s look at the steps you take to perform common tasks using mytop. This it intended to give you a hands-on feel for using mytop.

Find, analyze, and kill long-running queries
When mytop starts, it sorts threads by the Time column—that is, how long the thread has been in that state. Those that have most recently changed appear at the top of the screen. To locate long-running queries, first remove all idle threads from the display by pressing i, then reverse the sort order by pressing o. The resulting display will show the longest running queries at the top of the screen.

Once you’ve located a long-running query, you can obtain the full query by pressing f and entering the thread ID when prompted. When looking at the full query, you can ask MySQL to explain the query by pressing e. Or you may kill the query by pressing k and supplying the thread ID.[1]

[1] In MySQL 3.23 and 4.0, killing a query also terminates the client’s connection to the server. In other words, it kills the connection, and the query dies as a byproduct of that.

Determine what type of queries MySQL has been running
It’s often useful to know whether MySQL is running more SELECT or more INSERT queries. Maybe you suspect an application is misbehaving, or perhaps you’d simply like to compute your server’s typical read to write ratio. In mytop’s thread view (Figure B-1), it displays the percentage of SELECT, INSERT, UPDATE, and DELETE queries. On the right side of the header, you’ll see something like this:

Se/In/Up/De(%): 61/30/02/05

…  63/07/12/10
The first line means that, overall, 61% of the server’s queries are SELECTs, 30% are INSERTs, 2% are UPDATEs, and 5% are DELETEs. The second line displays values that apply to the last refresh interval (5 seconds by default) only. The two together can give a quick feel for what your server has been doing recently and how that compares to the longer term average.

If you want more detail, press c to switch mytop into command view. There you’ll find detailed counts and percentages for each type of command or query executed. The first column of numbers summarizes overall counts (since the server was started or counters reset), while the second set of numbers reflects the last refresh interval only.

Kill a group of queries
Use mytop’s “super-kill” feature by pressing K. You’ll be prompted for a username, and mytop will then kill all of that user’s threads. In the future this may be extended to evaluate more complex expressions, such as killing all nonidle threads from a given hostname or IP address.

Limit the display to a particular user or host
You can ask mytop to filter out all threads except those from a given host or those owned by a given user. If you press u, mytop prompts for a username to filter on. Similarly, pressing h allows you to provide a hostname or IP address which is used to filter the display. If you supply both, mytop restricts the display based on both criteria.

To clear the filtering, you can press F to remove all filters at once. Otherwise, you can use the u or h keys to remove either of the filters manually.

 

FreeBSD sendmail start stop

To stop sendmail:

cd /etc/mail
make stop

To start sendmail:

cd /etc/mail
make start

To restart sendmail:

cd /etc/mail
make restart

To get sendmail to regenerate aliases, the virtual user table and other stuff, run make on its own like so:

cd /etc/mail
make

After running “make” on its own, sendmail automatically reads all the files so you shouldn’t need to restart sendmail yourself at this point.

The header information from the Makefile in /etc/mail contains information about commands that can be passed to make. The top of this file is listed below.

# This Makefile provides an easy way to generate the configuration
# file and database maps for the sendmail(8) daemon.
#
# The user-driven targets are:
#
# all     - Build cf, maps and aliases
# cf       - Build the .cf file from .mc file
# maps     - Build the feature maps
# aliases - Build the sendmail aliases
# install - Install the .cf file as /etc/mail/sendmail.cf
#
# For acting on both the MTA daemon and MSP queue running daemon:
# start         - Start both the sendmail MTA daemon and MSP queue running
#                 daemon with the flags defined in /etc/defaults/rc.conf or
#                 /etc/rc.conf
# stop         - Stop both the sendmail MTA daemon and MSP queue running
#                 daemon
# restart       - Restart both the sendmail MTA daemon and MSP queue running
#                 daemon
#
# For acting on just the MTA daemon:
# start-mta     - Start the sendmail MTA daemon with the flags defined in
#                 /etc/defaults/rc.conf or /etc/rc.conf
# stop-mta     - Stop the sendmail MTA daemon
# restart-mta   - Restart the sendmail MTA daemon
#
# For acting on just the MSP queue running daemon:
# start-mspq   - Start the sendmail MSP queue running daemon with the
#                 flags defined in /etc/defaults/rc.conf or /etc/rc.conf
# stop-mspq     - Stop the sendmail MSP queue running daemon
# restart-mspq - Restart the sendmail MSP queue running daemon
#
# Calling `make' will generate the updated versions when either the
# aliases or one of the map files were changed.
#
# A `make install` is only necessary after modifying the .mc file. In
# this case one would normally also call `make restart' to allow the
# running sendmail to pick up the changes as well.

 

Apache Wildcard Subdomains *.example.com

Every account for our server monitoring application, Server Density, is accessed under a unique URL such as http://example.serverdensity.com. This gives each account a unique identifier for our internal account management system.

Although each customer has their own database which is linked by their unique URL, there is only 1 copy of the application code itself. Wildcard domains are used to allow any subdomain to be used.

*.serverdensity.com

means you can use

hello.serverdensity.com
cheese.serverdensity.com
whateveryouwant.serverdensity.com

without needing any kind of additional configuration of Apache or the DNS for serverdensity.com.

In our DNS zone for serverdensity.com, we have the usual entries but there is also the following record:

*.serverdensity.com. serverdensity.com. CNAME

This refers to

serverdensity.com. 67.23.6.201 A

because we currently have a single server set up for beta test accounts. As the service grows, this will be replaced by appropriate load balanced servers but for now, a single machine is handling requests.

The Apache config uses name based virtual hosts and we define a single vhost for the *.serverdensity.com domain:

ServerAdmin customer.service@boxedice.com
ServerName *.serverdensity.com
DocumentRoot /path/to/sd/
ErrorLog /path/to/sd/error.log

All requests to any subdomain are therefore picked up he DNS wildcard and passed to Apache, which also handles the wildcard, with the application code handling the requests. The subdomain used is made available in PHP in the $_SERVER['SERVER_NAME'] variable so it is easy to pick out which customer database to load.

The advantages of this system are:

  • Only a single copy of the Server Density application code base needs to be deployed.
  • Customers can have their own unique URL.
  • No additional configuration is required for domains or Apache, which would result in large config files.
  • Requests are all handled by a single DNS zone which makes it easy to swap in a load balancer to distribute requests across multiple servers.
  • Requests can be individually linked to customer accounts so we could track down heavy usage or link error reports to a customer to help us reproduce and diagnose problems faster.
 

10 Quick Tips for an Easier CSS Life

This nice article for Css designer. Found at :http://www.search-this.com/2007/03/26/10-quick-tips-for-an-easier-css-life/

**********

As with most things, a logical and structured approach is the best way to go. Therefore I have put together 10 quick tips (in no special order) to help make your CSS coding as pain-free as possible.

1. Keep it Simple

This may sound obvious but if you find yourself using complicated coding to achieve your design then you should think again about whether the feature you need is really necessary or if you’re just thinking about your design and not your visitors. Too often designers get caught up in their own design and go to great lengths to produce a certain visual effect only to find later on that visitors find it either irritating or unusable.

Complex code is usually the result of muddled thinking. Plan your layout logically and work from the outside in and from the top down where possible. Look at what containers you will need and break jobs down into smaller parcels. I usually start with a page wrapper and then progress logically through the header, navigation, main content and footers etc trying to preserve the flow of the document as much as possible.

While good visual design is necessary to attract visitors you must still have good content and a usable and accessible site. If you find your html and css looks like spaghetti then have a re-think and see if you can simplify it. This will make it easier to maintain in the future and will often save code and bandwidth.

2. Don’t use hacks unless its a known and documented bug

This is an important point as I too often see hacks employed to fix things that aren’t really broken in the first place. If you find that you are looking for a hack to fix a certain issue in your design then first do some research (Google is your friend here) and try to identify the issue you are having problems with.

If you find its a known bug then 99% of the time there will be a known solution to this bug and you can safely use a hack if required knowing that you are fixing a bug and not just correcting bad coding.

I couldn’t count the number of times I’ve seen layouts using hacks when all that was needed was to control the default margins on the page (see next tip).

3. Take care of margins and padding on all elements that you use

All browsers apply default padding and margins to most elements and the amount they apply varies quite substantially. Therefore you need to explicitly control the padding and margins on all the elements you use.

This is covered in depth in this article “No Margin For Error”.

4. Avoid using too much absolute positioning

Most novices to CSS quickly latch on to absolute positioning because it is pretty straight-forward and does what it says on the box. However absolute layouts have a number of problems and the biggest problem of all is that absolute elements are removed from the flow.

This means that when you absolutely place an element then it has total disregard to whatever else is on your page. It will overlap whatever was in that position and will take no notice of other content at all. The result of too much absolute positioning is that you end up having to control everything with absolute positioning and makes for a very rigid and inflexible layout.

The most common problem encountered when using absolute positioning for two or three columns is “How to put a footer at the bottom of all three columns?” The answer is you can’t, unless you resort to scripting or use a fixed height for all three columns.

Instead you should look into using mostly static positioning, margins and floats to maintain the flow of the layout. Static positioning is the default and basically means no positioning at all and the elements just take up space in the normal flow of the document. If elements flow normally then they have a logical construction and one element follows another without having to position it at all. You can use margins to nudge elements into position or use floats when you want elements aligned horizontally.

5. Avoid “divitus”

Although “divitus” isn’t a real word it is now commonly used to refer to layouts that have too many divs and not enough semantic html. Semantic html means using the correct html element for the task in hand and not just using divs for everything. Divs are generic dividers of page content and nothing else. 99% of the time there will be an html tag perfect for the job in hand.

e.g. p,h1,h2,h3,h4,h5,h6,ul,ol,dl etc…

Use divs to divide the page into logical sections or when there is no better alternative. If your page is logically divided into sections that use id’s to identify each section then this will allow you to target inner elements in that section without having to over-use classes on each element

e.g. #top-section h1 {color:red}(see next tip on “classitus”).

A common misuse of divs can be found in the following example:

HTML:

  1. <div id=“header”>
  2. <div class=“bold”>Heading</div>
  3. </div>
  4. <div id=“subheader”>
  5. <div class=“bold”>Sub Heading</div>
  6. </div>
  7. <div>This is the content</div>

A lot of times the above code can simply be reduced to this:

HTML:

  1. <h1>Heading</h1>
  2. <h2>Sub Heading</h2>
  3. <p>This is the content</p>

As you can see, by using the correct html to describe the content you give your layout inherent structure and meaning without any extra effort.

6. Avoid “Classitus”

“Classitus” is another made up word similar to “divitus” (as explained above) and refers to the over-use of classes (or id’s) when in fact none are necessary. If your page is logically divided then you can target many specific elements without the need for millions of classes.

A common example of misuse of classes is shown below:

CSS:

  1. a.link{color:red;text-decoration:none}
HTML:

  1. <li><a class=“link” href=“#”>Link1</a></li>
  2. <li><a class=“link” href=“#”>Link2</a></li>
  3. <li><a class=“link” href=“#”>Link3</a></li>
  4. <li><a class=“link” href=“#”>Link4</a></li>
  5. <li><a class=“link” href=“#”>Link5</a></li>
  6. <li><a class=“link” href=“#”>Link6</a></li>
  7. </ul>

All the links have been given a class of .link in order to style them and is completely unnecessary. If we apply an ID or class to the UL instead, we can target all the anchors within that ul without having to add any extra classes at all.

CSS:

  1. #nav a {color:red;text-decoration:none}
HTML:

  1. <ul id=“nav”>
  2. <li><a href=“#”>Link1</a></li>
  3. <li><a href=“#”>Link2</a></li>
  4. <li><a href=“#”>Link3</a></li>
  5. <li><a href=“#”>Link4</a></li>
  6. <li><a href=“#”>Link5</a></li>
  7. <li><a href=“#”>Link6</a></li>
  8. </ul>

As you can see we get the same effect and save considerably on mark-up and readability. A lot of times the ul may be unique in a section anyway and you can use the parent id without even having to add an id to the ul. (Remember that id’s are unique and can only be used once per page.)

7. Validate your code

Visit the validator at every opportunity and validate your css and html especially when learning something new. If you are new to html/css then validate regularly during development so that you can be sure the code you are using is correct; that will allow you to concentrate on getting the design right.

Do not wait until you have finished coding the design as you may be using features that are not appropriate and will result in a lot more work than necessary. Validating frequently will also catch simple errors like typos which will always creep into the code when you are not looking.

8. Rationalize your code

At every stage during development ask yourself whether you need that extra div wrapper or not. Can existing elements be utilised for background images without adding extraneous code?

Thinking ahead and planning your layout beforehand will often lead to more concise code and an easier-to-manage layout.

9. Flexibility

Remember that a web page isn’t the same as a printed page and that ultimately the user has more control over how your page will appear than you do. With this in mind try to allow for some flexibility in your design so that things like text resizing issues don’t break your layout. Don’t make everything a fixed height/width or at least use ems to allow the layout to expand when text is resized.

With a little thought and patience you can still make your page look good and satisfy accessibility requirements.

10. Browser support

A designer’s lot is often not a happy one due to the variance in the display offered via various browsers. There is no easy answer to this question (apart from the tips already given) and my method of working is as follows.

First of all decide with your client (or yourself) what browsers you are aiming to support. This will of course be based on many factors (which we won’t go into here) but could be as simple as checking your server stats to see who your visitors are.

Once you have decided what browsers to support then make sure that you have access to these browsers in some way. The easiest way is to download the browser you need so you can test locally.

If you can’t download the browsers for one reason or another or you need to test on another platform, then there are a number of sites that will offer remote access or screenshots. Some of these require payment and some of the simpler ones are free (a quick look on Google will soon sort you out).

Once you have decided what browsers to support it is time to start coding then you must check your design at every stage in the browsers that you want to support. This means writing a line of code then firing up at least 3 or 4 browsers to check. As you get more experienced you will soon learn what is likely to work and what doesn’t and you can check less frequently.

If you take this approach of checking at every stage then you will soon find out what works and what doesn’t and identify problems straight away and determine the cause is immediately. This would not be the case if you waited until you had finished and then checked the design. It could take hours (or days) to identify where the problem is and what is causing it. It may in fact be too late to fix it because you have built the whole page on a function that only works in one browser and you would have to start again from scratch.

By checking as you go you eliminate this problem and quite often a small change in design at each stage will accommodate nearly all the browsers you need to support without needing to hack. You can’t make these small tweaks and changes in design if you wait until the end.

The above tips for css coding aren’t in any special order and most are just plain common sense. If you follow the advice given you will make your web design life a lot easier and less stressful.

 

Startups in 13 sentences

Good article on startups

*****

One of the things I always tell startups is a principle I learned from Paul Buchheit: it’s better to make a few people really happy than to make a lot of people semi-happy. I was saying recently to a reporter that if I could only tell startups 10 things, this would be one of them. Then I thought: what would the other 9 be?

When I made the list there turned out to be 13:

1. Pick good cofounders.

Cofounders are for a startup what location is for real estate. You can change anything about a house except where it is. In a startup you can change your idea easily, but changing your cofounders is hard. [1] And the success of a startup is almost always a function of its founders.

2. Launch fast.

The reason to launch fast is not so much that it’s critical to get your product to market early, but that you haven’t really started working on it till you’ve launched. Launching teaches you what you should have been building. Till you know that you’re wasting your time. So the main value of whatever you launch with is as a pretext for engaging users.

3. Let your idea evolve.

This is the second half of launching fast. Launch fast and iterate. It’s a big mistake to treat a startup as if it were merely a matter of implementing some brilliant initial idea. As in an essay, most of the ideas appear in the implementing.

4. Understand your users.

You can envision the wealth created by a startup as a rectangle, where one side is the number of users and the other is how much you improve their lives. [2] The second dimension is the one you have most control over. And indeed, the growth in the first will be driven by how well you do in the second. As in science, the hard part is not answering questions but asking them: the hard part is seeing something new that users lack. The better you understand them the better the odds of doing that. That’s why so many successful startups make something the founders needed.

5. Better to make a few users love you than a lot ambivalent.

Ideally you want to make large numbers of users love you, but you can’t expect to hit that right away. Initially you have to choose between satisfying all the needs of a subset of potential users, or satisfying a subset of the needs of all potential users. Take the first. It’s easier to expand userwise than satisfactionwise. And perhaps more importantly, it’s harder to lie to yourself. If you think you’re 85% of the way to a great product, how do you know it’s not 70%? Or 10%? Whereas it’s easy to know how many users you have.

6. Offer surprisingly good customer service.

Customers are used to being maltreated. Most of the companies they deal with are quasi-monopolies that get away with atrocious customer service. Your own ideas about what’s possible have been unconsciously lowered by such experiences. Try making your customer service not merely good, but surprisingly good. Go out of your way to make people happy. They’ll be overwhelmed; you’ll see. In the earliest stages of a startup, it pays to offer customer service on a level that wouldn’t scale, because it’s a way of learning about your users.

7. You make what you measure.

I learned this one from Joe Kraus. [3] Merely measuring something has an uncanny tendency to improve it. If you want to make your user numbers go up, put a big piece of paper on your wall and every day plot the number of users. You’ll be delighted when it goes up and disappointed when it goes down. Pretty soon you’ll start noticing what makes the number go up, and you’ll start to do more of that. Corollary: be careful what you measure.

8. Spend little.

I can’t emphasize how important it is for a startup to be cheap. Most startups fail before they make something people want, and the most common form of failure is running out of money. So being cheap is (almost) interchangeable with iterating rapidly. [4] But it’s more than that. A culture of cheapness keeps companies young in something like the way exercise keeps people young.

9. Get ramen profitable.

“Ramen profitable” means a startup makes just enough to pay the founders’ living expenses. It’s not rapid prototyping for business models (though it can be), but more a way of hacking the investment process. Once you cross over into ramen profitable, it completely changes your relationship with investors. It’s also great for morale.

10. Avoid distractions.

Nothing kills startups like distractions. The worst type are those that pay money: day jobs, consulting, profitable side-projects. The startup may have more long-term potential, but you’ll always interrupt working on it to answer calls from people paying you now. Paradoxically, fundraising is this type of distraction, so try to minimize that too.

11. Don’t get demoralized.

Though the immediate cause of death in a startup tends to be running out of money, the underlying cause is usually lack of focus. Either the company is run by stupid people (which can’t be fixed with advice) or the people are smart but got demoralized. Starting a startup is a huge moral weight. Understand this and make a conscious effort not to be ground down by it, just as you’d be careful to bend at the knees when picking up a heavy box.

12. Don’t give up.

Even if you get demoralized, don’t give up. You can get surprisingly far by just not giving up. This isn’t true in all fields. There are a lot of people who couldn’t become good mathematicians no matter how long they persisted. But startups aren’t like that. Sheer effort is usually enough, so long as you keep morphing your idea.

13. Deals fall through.

One of the most useful skills we learned from Viaweb was not getting our hopes up. We probably had 20 deals of various types fall through. After the first 10 or so we learned to treat deals as background processes that we should ignore till they terminated. It’s very dangerous to morale to start to depend on deals closing, not just because they so often don’t, but because it makes them less likely to.

Having gotten it down to 13 sentences, I asked myself which I’d choose if I could only keep one.

Understand your users. That’s the key. The essential task in a startup is to create wealth; the dimension of wealth you have most control over is how much you improve users’ lives; and the hardest part of that is knowing what to make for them. Once you know what to make, it’s mere effort to make it, and most decent hackers are capable of that.

Understanding your users is part of half the principles in this list. That’s the reason to launch early, to understand your users. Evolving your idea is the embodiment of understanding your users. Understanding your users well will tend to push you toward making something that makes a few people deeply happy. The most important reason for having surprisingly good customer service is that it helps you understand your users. And understanding your users will even ensure your morale, because when everything else is collapsing around you, having just ten users who love you will keep you going.

Notes
[1] Strictly speaking it’s impossible without a time machine.
[2] In practice it’s more like a ragged comb
[3] Joe thinks one of the founders of Hewlett Packard said it first, but he doesn’t remember which.
[4] They’d be interchangeable if markets stood still. Since they don’t, working twice as fast is better than having twice as much time.

 

8-3

Haizzz…zzz.

Het 8-3 vo iu nhe’.Cuoi cung thi anh-nguoi hung cua em cung hoan thanh xong nhiem vu cao ca. Mua qua cho vo, goi dien cho mama, cho mama in law. Phu` phu`. Tuong lay duoc em ve roi thi` 8-3 nhe no, ai ngo`, hic, cang` ngay` cang` lam nhieu khe. Nhung vui, vi` nam nay 8-3 khong lam vo khoc’ phat’ nao`.

Bravo, 8/3 hoan hao nhat tu` ngay` yeu vo!

 

18 Mistakes that kill startups

I have experienced a few of these and would like to share with you this article. Great one !

**********

Link: http://paulgraham.com/startupmistakes.html

In the Q & A period after a recent talk, someone asked what made startups fail. After standing there gaping for a few seconds I realized this was kind of a trick question. It’s equivalent to asking how to make a startup succeed—if you avoid every cause of failure, you succeed—and that’s too big a question to answer on the fly.

Afterwards I realized it could be helpful to look at the problem from this direction. If you have a list of all the things you shouldn’t do, you can turn that into a recipe for succeeding just by negating. And this form of list may be more useful in practice. It’s easier to catch yourself doing something you shouldn’t than always to remember to do something you should. [1]

In a sense there’s just one mistake that kills startups: not making something users want. If you make something users want, you’ll probably be fine, whatever else you do or don’t do. And if you don’t make something users want, then you’re dead, whatever else you do or don’t do. So really this is a list of 18 things that cause startups not to make something users want. Nearly all failure funnels through that.

1. Single Founder

Have you ever noticed how few successful startups were founded by just one person? Even companies you think of as having one founder, like Oracle, usually turn out to have more. It seems unlikely this is a coincidence.

What’s wrong with having one founder? To start with, it’s a vote of no confidence. It probably means the founder couldn’t talk any of his friends into starting the company with him. That’s pretty alarming, because his friends are the ones who know him best.

But even if the founder’s friends were all wrong and the company is a good bet, he’s still at a disadvantage. Starting a startup is too hard for one person. Even if you could do all the work yourself, you need colleagues to brainstorm with, to talk you out of stupid decisions, and to cheer you up when things go wrong.

The last one might be the most important. The low points in a startup are so low that few could bear them alone. When you have multiple founders, esprit de corps binds them together in a way that seems to violate conservation laws. Each thinks “I can’t let my friends down.” This is one of the most powerful forces in human nature, and it’s missing when there’s just one founder.

2. Bad Location

Startups prosper in some places and not others. Silicon Valley dominates, then Boston, then Seattle, Austin, Denver, and New York. After that there’s not much. Even in New York the number of startups per capita is probably a 20th of what it is in Silicon Valley. In towns like Houston and Chicago and Detroit it’s too small to measure.

Why is the falloff so sharp? Probably for the same reason it is in other industries. What’s the sixth largest fashion center in the US? The sixth largest center for oil, or finance, or publishing? Whatever they are they’re probably so far from the top that it would be misleading even to call them centers.

It’s an interesting question why cities become startup hubs, but the reason startups prosper in them is probably the same as it is for any industry: that’s where the experts are. Standards are higher; people are more sympathetic to what you’re doing; the kind of people you want to hire want to live there; supporting industries are there; the people you run into in chance meetings are in the same business. Who knows exactly how these factors combine to boost startups in Silicon Valley and squish them in Detroit, but it’s clear they do from the number of startups per capita in each.

3. Marginal Niche

Most of the groups that apply to Y Combinator suffer from a common problem: choosing a small, obscure niche in the hope of avoiding competition.

If you watch little kids playing sports, you notice that below a certain age they’re afraid of the ball. When the ball comes near them their instinct is to avoid it. I didn’t make a lot of catches as an eight year old outfielder, because whenever a fly ball came my way, I used to close my eyes and hold my glove up more for protection than in the hope of catching it.

Choosing a marginal project is the startup equivalent of my eight year old strategy for dealing with fly balls. If you make anything good, you’re going to have competitors, so you may as well face that. You can only avoid competition by avoiding good ideas.

I think this shrinking from big problems is mostly unconscious. It’s not that people think of grand ideas but decide to pursue smaller ones because they seem safer. Your unconscious won’t even let you think of grand ideas. So the solution may be to think about ideas without involving yourself. What would be a great idea for someone else to do as a startup?

4. Derivative Idea

Many of the applications we get are imitations of some existing company. That’s one source of ideas, but not the best. If you look at the origins of successful startups, few were started in imitation of some other startup. Where did they get their ideas? Usually from some specific, unsolved problem the founders identified.

Our startup made software for making online stores. When we started it, there wasn’t any; the few sites you could order from were hand-made at great expense by web consultants. We knew that if online shopping ever took off, these sites would have to be generated by software, so we wrote some. Pretty straightforward.

It seems like the best problems to solve are ones that affect you personally. Apple happened because Steve Wozniak wanted a computer, Google because Larry and Sergey couldn’t find stuff online, Hotmail because Sabeer Bhatia and Jack Smith couldn’t exchange email at work.

So instead of copying the Facebook, with some variation that the Facebook rightly ignored, look for ideas from the other direction. Instead of starting from companies and working back to the problems they solved, look for problems and imagine the company that might solve them. [2] What do people complain about? What do you wish there was?

5. Obstinacy

In some fields the way to succeed is to have a vision of what you want to achieve, and to hold true to it no matter what setbacks you encounter. Starting startups is not one of them. The stick-to-your-vision approach works for something like winning an Olympic gold medal, where the problem is well-defined. Startups are more like science, where you need to follow the trail wherever it leads.

So don’t get too attached to your original plan, because it’s probably wrong. Most successful startups end up doing something different than they originally intended—often so different that it doesn’t even seem like the same company. You have to be prepared to see the better idea when it arrives. And the hardest part of that is often discarding your old idea.

But openness to new ideas has to be tuned just right. Switching to a new idea every week will be equally fatal. Is there some kind of external test you can use? One is to ask whether the ideas represent some kind of progression. If in each new idea you’re able to re-use most of what you built for the previous ones, then you’re probably in a process that converges. Whereas if you keep restarting from scratch, that’s a bad sign.

Fortunately there’s someone you can ask for advice: your users. If you’re thinking about turning in some new direction and your users seem excited about it, it’s probably a good bet.

6. Hiring Bad Programmers

I forgot to include this in the early versions of the list, because nearly all the founders I know are programmers. This is not a serious problem for them. They might accidentally hire someone bad, but it’s not going to kill the company. In a pinch they can do whatever’s required themselves.

But when I think about what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That’s actually much harder than it sounds—almost impossibly hard in fact—because business guys can’t tell which are the good programmers. They don’t even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he’s a Microsoft Certified Developer) but who aren’t. Then they’re mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think there’s an answer. I was about to say you’d have to find a good programmer to help you hire people. But if you can’t recognize good programmers, how would you even do that?

7. Choosing the Wrong Platform

A related problem (since it tends to be done by bad programmers) is choosing the wrong platform. For example, I think a lot of startups during the Bubble killed themselves by deciding to build server-based applications on Windows. Hotmail was still running on FreeBSD for years after Microsoft bought it, presumably because Windows couldn’t handle the load. If Hotmail’s founders had chosen to use Windows, they would have been swamped.

PayPal only just dodged this bullet. After they merged with X.com, the new CEO wanted to switch to Windows—even after PayPal cofounder Max Levchin showed that their software scaled only 1% as well on Windows as Unix. Fortunately for PayPal they switched CEOs instead.

Platform is a vague word. It could mean an operating system, or a programming language, or a “framework” built on top of a programming language. It implies something that both supports and limits, like the foundation of a house.

The scary thing about platforms is that there are always some that seem to outsiders to be fine, responsible choices and yet, like Windows in the 90s, will destroy you if you choose them. Java applets were probably the most spectacular example. This was supposed to be the new way of delivering applications. Presumably it killed just about 100% of the startups who believed that.

How do you pick the right platforms? The usual way is to hire good programmers and let them choose. But there is a trick you could use if you’re not a programmer: visit a top computer science department and see what they use in research projects.

8. Slowness in Launching

Companies of all sizes have a hard time getting software done. It’s intrinsic to the medium; software is always 85% done. It takes an effort of will to push through this and get something released to users. [3]

Startups make all kinds of excuses for delaying their launch. Most are equivalent to the ones people use for procrastinating in everyday life. There’s something that needs to happen first. Maybe. But if the software were 100% finished and ready to launch at the push of a button, would they still be waiting?

One reason to launch quickly is that it forces you to actually finish some quantum of work. Nothing is truly finished till it’s released; you can see that from the rush of work that’s always involved in releasing anything, no matter how finished you thought it was. The other reason you need to launch is that it’s only by bouncing your idea off users that you fully understand it.

Several distinct problems manifest themselves as delays in launching: working too slowly; not truly understanding the problem; fear of having to deal with users; fear of being judged; working on too many different things; excessive perfectionism. Fortunately you can combat all of them by the simple expedient of forcing yourself to launch something fairly quickly.

9. Launching Too Early

Launching too slowly has probably killed a hundred times more startups than launching too fast, but it is possible to launch too fast. The danger here is that you ruin your reputation. You launch something, the early adopters try it out, and if it’s no good they may never come back.

So what’s the minimum you need to launch? We suggest startups think about what they plan to do, identify a core that’s both (a) useful on its own and (b) something that can be incrementally expanded into the whole project, and then get that done as soon as possible.

This is the same approach I (and many other programmers) use for writing software. Think about the overall goal, then start by writing the smallest subset of it that does anything useful. If it’s a subset, you’ll have to write it anyway, so in the worst case you won’t be wasting your time. But more likely you’ll find that implementing a working subset is both good for morale and helps you see more clearly what the rest should do.

The early adopters you need to impress are fairly tolerant. They don’t expect a newly launched product to do everything; it just has to do something.

10. Having No Specific User in Mind

You can’t build things users like without understanding them. I mentioned earlier that the most successful startups seem to have begun by trying to solve a problem their founders had. Perhaps there’s a rule here: perhaps you create wealth in proportion to how well you understand the problem you’re solving, and the problems you understand best are your own. [4]

That’s just a theory. What’s not a theory is the converse: if you’re trying to solve problems you don’t understand, you’re hosed.

And yet a surprising number of founders seem willing to assume that someone, they’re not sure exactly who, will want what they’re building. Do the founders want it? No, they’re not the target market. Who is? Teenagers. People interested in local events (that one is a perennial tarpit). Or “business” users. What business users? Gas stations? Movie studios? Defense contractors?

You can of course build something for users other than yourself. We did. But you should realize you’re stepping into dangerous territory. You’re flying on instruments, in effect, so you should (a) consciously shift gears, instead of assuming you can rely on your intuitions as you ordinarily would, and (b) look at the instruments.

In this case the instruments are the users. When designing for other people you have to be empirical. You can no longer guess what will work; you have to find users and measure their responses. So if you’re going to make something for teenagers or “business” users or some other group that doesn’t include you, you have to be able to talk some specific ones into using what you’re making. If you can’t, you’re on the wrong track.

11. Raising Too Little Money

Most successful startups take funding at some point. Like having more than one founder, it seems a good bet statistically. How much should you take, though?

Startup funding is measured in time. Every startup that isn’t profitable (meaning nearly all of them, initially) has a certain amount of time left before the money runs out and they have to stop. This is sometimes referred to as runway, as in “How much runway do you have left?” It’s a good metaphor because it reminds you that when the money runs out you’re going to be airborne or dead.

Too little money means not enough to get airborne. What airborne means depends on the situation. Usually you have to advance to a visibly higher level: if all you have is an idea, a working prototype; if you have a prototype, launching; if you’re launched, significant growth. It depends on investors, because until you’re profitable that’s who you have to convince.

So if you take money from investors, you have to take enough to get to the next step, whatever that is. [5] Fortunately you have some control over both how much you spend and what the next step is. We advise startups to set both low, initially: spend practically nothing, and make your initial goal simply to build a solid prototype. This gives you maximum flexibility.

12. Spending Too Much

It’s hard to distinguish spending too much from raising too little. If you run out of money, you could say either was the cause. The only way to decide which to call it is by comparison with other startups. If you raised five million and ran out of money, you probably spent too much.

Burning through too much money is not as common as it used to be. Founders seem to have learned that lesson. Plus it keeps getting cheaper to start a startup. So as of this writing few startups spend too much. None of the ones we’ve funded have. (And not just because we make small investments; many have gone on to raise further rounds.)

The classic way to burn through cash is by hiring a lot of people. This bites you twice: in addition to increasing your costs, it slows you down—so money that’s getting consumed faster has to last longer. Most hackers understand why that happens; Fred Brooks explained it in The Mythical Man-Month.

We have three general suggestions about hiring: (a) don’t do it if you can avoid it, (b) pay people with equity rather than salary, not just to save money, but because you want the kind of people who are committed enough to prefer that, and (c) only hire people who are either going to write code or go out and get users, because those are the only things you need at first.

13. Raising Too Much Money

It’s obvious how too little money could kill you, but is there such a thing as having too much?

Yes and no. The problem is not so much the money itself as what comes with it. As one VC who spoke at Y Combinator said, “Once you take several million dollars of my money, the clock is ticking.” If VCs fund you, they’re not going to let you just put the money in the bank and keep operating as two guys living on ramen. They want that money to go to work. [6] At the very least you’ll move into proper office space and hire more people. That will change the atmosphere, and not entirely for the better. Now most of your people will be employees rather than founders. They won’t be as committed; they’ll need to be told what to do; they’ll start to engage in office politics.

When you raise a lot of money, your company moves to the suburbs and has kids.

Perhaps more dangerously, once you take a lot of money it gets harder to change direction. Suppose your initial plan was to sell something to companies. After taking VC money you hire a sales force to do that. What happens now if you realize you should be making this for consumers instead of businesses? That’s a completely different kind of selling. What happens, in practice, is that you don’t realize that. The more people you have, the more you stay pointed in the same direction.

Another drawback of large investments is the time they take. The time required to raise money grows with the amount. [7] When the amount rises into the millions, investors get very cautious. VCs never quite say yes or no; they just engage you in an apparently endless conversation. Raising VC scale investments is thus a huge time sink—more work, probably, than the startup itself. And you don’t want to be spending all your time talking to investors while your competitors are spending theirs building things.

We advise founders who go on to seek VC money to take the first reasonable deal they get. If you get an offer from a reputable firm at a reasonable valuation with no unusually onerous terms, just take it and get on with building the company. [8] Who cares if you could get a 30% better deal elsewhere? Economically, startups are an all-or-nothing game. Bargain-hunting among investors is a waste of time.

14. Poor Investor Management

As a founder, you have to manage your investors. You shouldn’t ignore them, because they may have useful insights. But neither should you let them run the company. That’s supposed to be your job. If investors had sufficient vision to run the companies they fund, why didn’t they start them?

Pissing off investors by ignoring them is probably less dangerous than caving in to them. In our startup, we erred on the ignoring side. A lot of our energy got drained away in disputes with investors instead of going into the product. But this was less costly than giving in, which would probably have destroyed the company. If the founders know what they’re doing, it’s better to have half their attention focused on the product than the full attention of investors who don’t.

How hard you have to work on managing investors usually depends on how much money you’ve taken. When you raise VC-scale money, the investors get a great deal of control. If they have a board majority, they’re literally your bosses. In the more common case, where founders and investors are equally represented and the deciding vote is cast by neutral outside directors, all the investors have to do is convince the outside directors and they control the company.

If things go well, this shouldn’t matter. So long as you seem to be advancing rapidly, most investors will leave you alone. But things don’t always go smoothly in startups. Investors have made trouble even for the most successful companies. One of the most famous examples is Apple, whose board made a nearly fatal blunder in firing Steve Jobs. Apparently even Google got a lot of grief from their investors early on.

15. Sacrificing Users to (Supposed) Profit

When I said at the beginning that if you make something users want, you’ll be fine, you may have noticed I didn’t mention anything about having the right business model. That’s not because making money is unimportant. I’m not suggesting that founders start companies with no chance of making money in the hope of unloading them before they tank. The reason we tell founders not to worry about the business model initially is that making something people want is so much harder.

I don’t know why it’s so hard to make something people want. It seems like it should be straightforward. But you can tell it must be hard by how few startups do it.

Because making something people want is so much harder than making money from it, you should leave business models for later, just as you’d leave some trivial but messy feature for version 2. In version 1, solve the core problem. And the core problem in a startup is how to create wealth (= how much people want something x the number who want it), not how to convert that wealth into money.

The companies that win are the ones that put users first. Google, for example. They made search work, then worried about how to make money from it. And yet some startup founders still think it’s irresponsible not to focus on the business model from the beginning. They’re often encouraged in this by investors whose experience comes from less malleable industries.

It is irresponsible not to think about business models. It’s just ten times more irresponsible not to think about the product.

16. Not Wanting to Get Your Hands Dirty

Nearly all programmers would rather spend their time writing code and have someone else handle the messy business of extracting money from it. And not just the lazy ones. Larry and Sergey apparently felt this way too at first. After developing their new search algorithm, the first thing they tried was to get some other company to buy it.

Start a company? Yech. Most hackers would rather just have ideas. But as Larry and Sergey found, there’s not much of a market for ideas. No one trusts an idea till you embody it in a product and use that to grow a user base. Then they’ll pay big time.

Maybe this will change, but I doubt it will change much. There’s nothing like users for convincing acquirers. It’s not just that the risk is decreased. The acquirers are human, and they have a hard time paying a bunch of young guys millions of dollars just for being clever. When the idea is embodied in a company with a lot of users, they can tell themselves they’re buying the users rather than the cleverness, and this is easier for them to swallow. [9]

If you’re going to attract users, you’ll probably have to get up from your computer and go find some. It’s unpleasant work, but if you can make yourself do it you have a much greater chance of succeeding. In the first batch of startups we funded, in the summer of 2005, most of the founders spent all their time building their applications. But there was one who was away half the time talking to executives at cell phone companies, trying to arrange deals. Can you imagine anything more painful for a hacker? [10] But it paid off, because this startup seems the most successful of that group by an order of magnitude.

If you want to start a startup, you have to face the fact that you can’t just hack. At least one hacker will have to spend some of the time doing business stuff.

17. Fights Between Founders

Fights between founders are surprisingly common. About 20% of the startups we’ve funded have had a founder leave. It happens so often that we’ve reversed our attitude to vesting. We still don’t require it, but now we advise founders to vest so there will be an orderly way for people to quit.

A founder leaving doesn’t necessarily kill a startup, though. Plenty of successful startups have had that happen. [11] Fortunately it’s usually the least committed founder who leaves. If there are three founders and one who was lukewarm leaves, big deal. If you have two and one leaves, or a guy with critical technical skills leaves, that’s more of a problem. But even that is survivable. Blogger got down to one person, and they bounced back.

Most of the disputes I’ve seen between founders could have been avoided if they’d been more careful about who they started a company with. Most disputes are not due to the situation but the people. Which means they’re inevitable. And most founders who’ve been burned by such disputes probably had misgivings, which they suppressed, when they started the company. Don’t suppress misgivings. It’s much easier to fix problems before the company is started than after. So don’t include your housemate in your startup because he’d feel left out otherwise. Don’t start a company with someone you dislike because they have some skill you need and you worry you won’t find anyone else. The people are the most important ingredient in a startup, so don’t compromise there.

18. A Half-Hearted Effort

The failed startups you hear most about are the spectactular flameouts. Those are actually the elite of failures. The most common type is not the one that makes spectacular mistakes, but the one that doesn’t do much of anything—the one we never even hear about, because it was some project a couple guys started on the side while working on their day jobs, but which never got anywhere and was gradually abandoned.

Statistically, if you want to avoid failure, it would seem like the most important thing is to quit your day job. Most founders of failed startups don’t quit their day jobs, and most founders of successful ones do. If startup failure were a disease, the CDC would be issuing bulletins warning people to avoid day jobs.

Does that mean you should quit your day job? Not necessarily. I’m guessing here, but I’d guess that many of these would-be founders may not have the kind of determination it takes to start a company, and that in the back of their minds, they know it. The reason they don’t invest more time in their startup is that they know it’s a bad investment. [12]

I’d also guess there’s some band of people who could have succeeded if they’d taken the leap and done it full-time, but didn’t. I have no idea how wide this band is, but if the winner/borderline/hopeless progression has the sort of distribution you’d expect, the number of people who could have made it, if they’d quit their day job, is probably an order of magnitude larger than the number who do make it. [13]

If that’s true, most startups that could succeed fail because the founders don’t devote their whole efforts to them. That certainly accords with what I see out in the world. Most startups fail because they don’t make something people want, and the reason most don’t is that they don’t try hard enough.

In other words, starting startups is just like everything else. The biggest mistake you can make is not to try hard enough. To the extent there’s a secret to success, it’s not to be in denial about that.

Notes

[1] This is not a complete list of the causes of failure, just those you can control. There are also several you can’t, notably ineptitude and bad luck.

[2] Ironically, one variant of the Facebook that might work is a facebook exclusively for college students.

[3] Steve Jobs tried to motivate people by saying “Real artists ship.” This is a fine sentence, but unfortunately not true. Many famous works of art are unfinished. It’s true in fields that have hard deadlines, like architecture and filmmaking, but even there people tend to be tweaking stuff till it’s yanked out of their hands.

[4] There’s probably also a second factor: startup founders tend to be at the leading edge of technology, so problems they face are probably especially valuable.

[5] You should take more than you think you’ll need, maybe 50% to 100% more, because software takes longer to write and deals longer to close than you expect.

[6] Since people sometimes call us VCs, I should add that we’re not. VCs invest large amounts of other people’s money. We invest small amounts of our own, like angel investors.

[7] Not linearly of course, or it would take forever to raise five million dollars. In practice it just feels like it takes forever.

Though if you include the cases where VCs don’t invest, it would literally take forever in the median case. And maybe we should, because the danger of chasing large investments is not just that they take a long time. That’s the best case. The real danger is that you’ll expend a lot of time and get nothing.

[8] Some VCs will offer you an artificially low valuation to see if you have the balls to ask for more. It’s lame that VCs play such games, but some do. If you’re dealing with one of those you should push back on the valuation a bit.

[9] Suppose YouTube’s founders had gone to Google in 2005 and told them “Google Video is badly designed. Give us $10 million and we’ll tell you all the mistakes you made.” They would have gotten the royal raspberry. Eighteen months later Google paid $1.6 billion for the same lesson, partly because they could then tell themselves that they were buying a phenomenon, or a community, or some vague thing like that.

I don’t mean to be hard on Google. They did better than their competitors, who may have now missed the video boat entirely.

[10] Yes, actually: dealing with the government. But phone companies are up there.

[11] Many more than most people realize, because companies don’t advertise this. Did you know Apple originally had three founders?

[12] I’m not dissing these people. I don’t have the determination myself. I’ve twice come close to starting startups since Viaweb, and both times I bailed because I realized that without the spur of poverty I just wasn’t willing to endure the stress of a startup.

[13] So how do you know whether you’re in the category of people who should quit their day job, or the presumably larger one who shouldn’t? I got to the point of saying that this was hard to judge for yourself and that you should seek outside advice, before realizing that that’s what we do. We think of ourselves as investors, but viewed from the other direction Y Combinator is a service for advising people whether or not to quit their day job. We could be mistaken, and no doubt often are, but we do at least bet money on our conclusions.

 

Happy birthday, sweet love

Today (the unforgettable 15th Oct) is an important day of my life. Happy Birthday Sweet Love ! I know I could be something without you but having you make me a bigger thing. I feel more alive after works when I see you and take you out. Wish you be more beautiful each day and have the most lucks in the world. You will be always beautiful in my eyes as the first time when I saw you.

Thank you for bearing with me and I will try to keep the smile on your lovely face whenever I can.

Beautiful as rose

Beautiful as the rose

 

Settle down

Finally, family is calling and individual life is getting to be limited. Next month, our marriage wedding will happen. It’s time to think more seriously about building a good home and try to be a good family man.

Nothing much on works at the moment. Things keep me busy all the time, but still manage to balance work and life. I have to tell you, it is hard. I have the fortune to have my girlfriend (soon-to-be my wife) keep telling me to ralax, take on some exerices and go out.

Thanks God for sending me this lovely woman.

 

Something in the air

Love is calling