Michi Knows

Everybody, listen. There’s a Web 2.0 bubble right now. I know it’s difficult for some people to acknowledge, and many people may even casually agree with me without actually believing the statement in full. But it’s true, and the quicker you realize this, the better it will be for your pocket books.

Lately, I’ve been doing stock trading, and have come to learn first hand about the energy and commodities bubbles that were slamming the market. And when that thing was going crazy, it helped deflate the banking bubble, which was a direct result of the housing bubble. And in many ways, the housing bubble was a result of the dot-com bubble bursting due to people exiting the stock market in search for a new investment. And everybody in the web industry likes to think they are wise to bubbles because they learned their lesson in the dot-com boom. But it is increasingly evident that this is not the case.

As we know, Facebook has a supposed valuation in the double digit billions, thanks to Microsoft’s minority stake investment in that company. And just the other day, it was news that Google was seriously considering buying Digg for $200M (the deal ultimately fell through).

There is a clear bubble here, but it’s sometimes hard to see because most startups are at least producing some revenues.

An Example Exercise

The problem here is that people are approaching this with the mind set of “this will be somebody else’s problem after I sell it.” It’s important we try to figure out what happens to the eventual owner of the startup.

1. Take your favorite Internet 2.0 “company”: Digg, Myspace, Twitter, etc. Decide how much you think that company is worth. $5 million? $10 million? $50 million? $500 million? The sky is the limit!
2. Take half your life savings. Take all your discretionary spending money for the next 5 years and take it out of your budget.
3. Now imagine there is a company that exists that has some money to throw around into a startup. The company is, at least for now, profitable. You will now put the funds from step #2 into the stock of a subsidiary of this company. This subsidiary will be exposed to 100% of the gains/losses that will arise from this takeover.
4. Remember that number you threw up there in step #1? That’s how much your new company is going to pay to acquire that 2.0 startup. Your stock’s valuation is now 100% tied to the income generated by this newly acquired startup. If the startup loses money, your stock goes down and if the startup makes money, your stock goes up.
5. Nobody will accept an offer to buy the startup from your company at a break-even or higher price until it has reported a yearly net revenue of 10% of the purchase price and is profitable.

That last part is the key because it effectively stops the hot potato game and forces you to examine if the company is truly viable. Some people would accuse that of being an unfair restriction, but I will show you why this is the key part in understanding why there is a 2.0 bubble.

Defining the Bubble

Let’s take a second to define a bubble:

An investment yields a return, much like a chicken can produce eggs, a savings account produces a yield, and a farm produces crop. This return is not always immediate, and is not always in the same terms as the input. Also, it is almost a law that returns are proportional to risk (some investments have negative returns). But ultimately, it is called an investment because it will (usually and) eventually generate more value than what you put in.

Now consider an investment that does not create a return. Such an example would be the web stocks of the dot-com boom. Back then, fundamentals like earnings, operating margins, and profitability were ignored when evaluating a stock. Companies that bled millions of dollars a year saw their stocks rising at record levels. This is because the investment - the stock - was being traded to somebody else for a profit because that next person believed they could trade it for an even higher profit.

A bubble is defined as a trend where merely owning something long enough to sell it is profitable. It is a giant game of hot potato. Everybody is essentially a middle man between the original owner and the eventual owner — adding to the price tag at every step. Eventually, people wise up and no longer want to trade the hot potato, causing the bubble to burst.

And most importantly, let’s define a bursting bubble:

A bubble is defined as bursting when the value of the traded item reverts to its true market value.

Understanding the Exercise

So let’s talk about the exercise again: if you thought the company was worth a paltry $50M, then your assets are stuck inside that stock until the startup can earn $5M in revenue AND be profitable while doing so. Why did I pick such restriction? Because those are reasonable things to assume when buying any other type of company. Why would another company offer to buy the startup if it failed to produce respectable profit margins or revenues?

Given this extremely reasonable reality-check requirement, would you want to tie your personal investment to the startup being able to produce a profit? Would you end up selling your stocks in fear that they would go to zero? I know some of you would still blindly accept this gamble, but I am sure it helps you see the absurdity of at least some of the valuations that are going on right now. How can Facebook be worth over $10B if it isn’t producing revenues somewhere in the $500M-$1B range? Reality check: Facebook has revenues of $150M a year.

Speculation Should Still be Grounded on Fundamentals

These types of companies are “worth” that much because the valuation is highly speculative. People aren’t investing for what Facebook and other 2.0 companies are worth today, it’s all about tomorrow. I agree that it is important that tomorrow’s profits are taken into today’s valuations, BUT isn’t this reasoning eerily similar to the reason people listed as to why they bought over-priced houses and profitless dot-com stocks? Both were purchases made while completely disregarding the fact that the *current* valuation of the items were negative.

But since that day of profitability is so far away into the future, you end up playing a giant game of corporate hot potato. Most people would agree that a profit of 10% is far better than a loss of 90%. So as soon as you find a sucker to pay 10% more than you paid, you bail. And of course that guy who bought your stake is thinking the exact same thing — sell this to somebody else for 10% profit before something bad happens. That’s a bubble, my friends.

In Conclusion

In 2001, the bubble was all about going IPO so that the general public could hold the hot potato.

Today, the bubble is all about selling to a big corporate entity that will hold the hot potato.

There is no difference.

If you are currently thinking about entering the 2.0 scene, think carefully about what your end goal is. If it isn’t “to be profitable and retire”, then it’s likely just another bubble startup that will become completely worthless (and your invested time and money completely wasted) once the bubble pops. And believe me: given our current economy, that bubble is going to pop in the next year or two.

Finally, an extremely interesting speech about bubbles given in 2006 (gets good around part 2):

Part 1

Part 2

Part 3

Part 4

Part 5

Part 6

Today I want to talk about passing in objects as arguments in PHP methods. Many PHP developers do not have this patience. This is obvious when studying libraries written for Java versus those in PHP. It is a horridly underused programming style in PHP, and since PHP supports argument type prototyping in methods, I thought it would be good to go over this particular style of development.

First of all, let’s start with a few “PHP” way of doing a mundane task (this will seem extremely familiar):

function login($username, $password, $remember);

function processMail($to, $from, $subject, $body);

function editPost($id, $title, $body, $newTime);

Of course, good developers would make sure these types of examples are part of a class:

$user = new User;
$user->username = $_POST["username"];
$user->password = $_POST['password'];
$user->login();

The examples can continue, and I hope that you good developers use this type of basic OOP development when doing using PHP. But there are examples where the standard “newbie” OOP model seemingly falls apart. The system quickly breaks down when new requirements are added to the system. For example, what if we want to do a “remember me” option in the login? What about logging in as an administrator versus a regular user? Okay, now what if we have different login session lengths depending on the user type? How long do you think that login function will be? Think about how it will accommodate IP bans, login logging, banned users, suspended users, max failed attempt lockouts, etc. The list goes on, and depending on your implementation, things can get very ugly. Your login function might become a huge bloated monster sitting in your User class.

The problem is that what you’re actually doing is mixing a data model [user data] with controller logic [how to login using the user data]. The solution is to separate these two entities into two classes, which is what you would see in most modern MVC frameworks.

Here is the seemingly more complex, but far more elegant solution:

$authenticationController = new UserAuthenticationController;
$user = new User;
$user->username = $_POST['username'];
$user->password = $_POST['password'];
$user->rememberMe = true;
$authenticationController->login($user);

The prototype for the login method would look like this:

function login(User $userObject);

In this example, I am hoping to show you possibilities. First, notice that the arguments for login() are down to one. But the more interesting part of the implementation comes with the proper abstraction between the User data and the authentication process. In my example, I Just logged in a regular user. So if I had to map out my class structure, it might look like this:

(Abstract class) AuthenticationController
=> GuestAuthenticationController
  => UserAuthenticationController
    => AdminAuthenticationController

The old way of doing things would look something like these:

function adminLogin($username, $password, $remember);

$user->adminLogin();

But using the Java-esk model, we’d end up with something like this:

$authenticationController = new AdminAuthenticationController;
$user = new User;
$user->username = $_POST['username'];
$user->password = $_POST['password'];
$user->rememberMe = true;
$authenticationController->login($user);

This means the login method is likely broken up in a few pieces inside the AuthenticationController. The Guest user’s login() method would always return false. The UserAuthenticationController would piggy back on AuthenticationController::login() by looking at the User::rememberMe variable and take it into account. But the AdminAuthenticationController doesn’t allow people’s logins to be remembered due to security reasons, so it doesn’t take that variable into account. And in that crazy case where there is nothing different about the admin login, the method would remain untouched (inherited from the parent), but any other changes (such as session length) would still kick in for the admin user with no additional coding.

All of this is done without modifying the core User class. The user class remains clean for its own further abstraction possibilities. New fields such as profile, name, DOB, etc., could be added with no modifications to the controller.

Yes, my version requires the most lines of code, but it is also the easiest to maintain and understand. Why? Because it isn’t cluttering up the User data class with methods that have nothing to do with the user. If you’ve ever written a generic “user” class, you know how large and cluttered such a class can become when you start piling in the methods for login, logout, preferences, session management, lookups, and other needs. I haven’t even talked about the fact that virtually all “operations” that involve a user also involve the database, which adds its own headaches. Being able to keep the hard work in other more data-manipulation-oriented classes is for your own good.

If down the road, it is determined that logging in should also require pre-approved IP addresses, what will your code need? Will your login method need an IP address passed in too? Or will the IP address be generated inside the login method? In my example, I would update the core Authentication class and be done. What happens when a new requirement is added that requires that the login also passes a CAPTCHA test? What about when logins need to be logged in a flat file? What happens when we change logins to use the email field instead of the user field?

Today, I only talked about logins. The ideas I propose here are not new; they are simply good ideas that get ignored by web developers. Remember, you’re application developers that happen to work in a browser. Don’t think that regular application design principles don’t apply to you: they do, more than ever.

Ever wonder why Google gives away so many web-developer tools? Tools that otherwise seem like complete money-and-bandwidth-pissing schemes (notice how most of these don’t directly show ads):

• Maps Widgets
• Charts API
• Open Social
• YouTube embeds
• Unified AJAX libraries
• Android
• General Search APIs

This is all about obtaining browsing behavior in a long term bid to increase ad efficiency. Nothing else.

1. It is not about making things more “open”
2. It is not about making web development easier
3. It is not about making an online operating system
4. It is not about competing with Microsoft
5. It is not about making the Google brand more ubiquitous
6. It is not about showing ads in new places

If any of these above things happen, they are a (likely planned) side effect. For example, if a particular API makes something easier, that is good because it will encourage other developers to adopt it as well. But as I will explain shortly, the commonly held beliefs about Google doing Good or Google making the web more open are simply not the reason for these initiatives.

If you notice, all of their APIs use JavaScript. This means all of their APIs have the ability to note what computer a given request is coming from. This means that on top of your search preferences, they can eventually begin to correlate your browsing habits based on the sites that you visit that use Google APIs.

For example, if my blog were to use a YouTube embed, it would be possible for Google to read a cookie originally placed on your machine by YouTube and correlate it as traffic coming from this site. This means they can unique track every YouTube video your computer has ever watched since the last time your cleared your cookies. YouTube is just an example because most of Google’s APIs are far less obvious to the end user. For example, the unified AJAX libraries could be used by a good half of the “2.0″ web sites out there without impacting performance (and in many cases would make the sites load faster for the end user). But because everything is going through Google, it’s possible (although I’m not saying that are) for them to track which sites you visit.

If this isn’t extremely valuable information, I don’t know what is. Don’t forget that the AdSense API is, in itself, a means for Google to track every website you’ve ever been to that uses AdSense, and for a way for Google to know exactly which type of ads interested you in the past. Once they know what sites you visit, they can surmise what a given site is about, and then determine, for example, what sort of products would interest you.

It’s the classic advertising chicken and egg problem: If I knew what my customers wanted, I could sell it to them, but they won’t tell me.

…And Google found the chicken. For the time being, they haven’t started using this information (at least noticeably), but I am sure they will as market forces move to make competition in that area more necessary.

Say goodbye to privacy. =( Oh wait, I’ve been saying that for quite some time now.