It's hard to conceptualize the value $500 when you've just raised a couple million from investors. The measly few hundred -- or few thousand -- dollar expenses seem to be too unimportant to even consider.
Over time, we've started looking at things in a way that can bring it all in perspective. Consider this: if you've raised $2M at an $8M pre-money valuation, that $2M is worth 20% of your company. Each time you raise money, you are giving up a certain amount of equity to someone else in return for that money. And each time you spend money, you're spending equity in your company.
While it might seem like a $20,000 couch
isn't an expense to fret over, that couch cost you 0.2% of your company. Likewise, a $250/month expense, while seemingly too insignificant to worry about, represents almost 0.1% of your company over 3 years.
The lesson here isn't to be penny wise and pound foolish -- certain expenses pay for themselves many times over -- but rather to carefully consider where you decide to spend your equity.
An article on Reddit recently (Unidentified hot girl stealing my Christmas presents
) got me thinking: why hasn't a private company created a global database for facial recognition matching?
The pieces are all there: Crawl Facebook's publicly available data and index people's profile pictures. Then, provide a service where anybody can upload a picture and it will attempt to provide a match for the faces in the picture. It's sort of a DNA matching database for photos, if you will.
The implications are a bit frightening, but it's likely just a matter of time before someone does this exact thing, unless the law changes. IANAL, but it seems pretty clear that there is no expectation of privacy
in public.Like this post? Subscribe to this blog now.
Disclaimer: This worked for me, it might not work for you. Please back up your data before trying any of this.
You usually discover the breaking points of a particular schema once the table reaches a certain size. Unfortunately, at that point, ALTER-ing the table to add the appropriate index can take a really, really, really long time, especially if you get stuck in MySQL's dreaded "Repair With Keycache" phase.
I recently needed to alter a few tables with >50M rows in as little as time as possible. Here's one solution that goes reasonably fast if you have access to a machine with lots of memory:
- Backup your data.
- Shut down the MySQL server you're copying data from.
- Copy the MyISAM table files (large_table.frm, large_table.MYD, large_table.MYI) over to the machine you'll do the ALTER on.
(Make sure you set the permissions properly or MySQL won't be able to read the new table)
- Run a SHOW CREATE TABLE large_table.
- Copy the table definition, change the name to something like large_table2 and add your new index at the end.
- Shut down this MySQL server.
- Overwrite the large_table.frm and large_table.MYI files with the large_table2.frm and large_table2.MYI files. (You remembered to backup your data, right?)
- You can safely remove the large_table2.MYD file (it should be zero bytes)
- Next, run the following command:
myisamchk -r --key_buffer_size=1024M --sort_buffer_size=6000M --read_buffer_size=1024M --write_buffer_size=1024M large_table.MYI
(Change the memory numbers to match what you have available)
- Once the table has finished rebuilding, copy the large_table.frm, large_table.MYD and large_table.MYI files back to the original server.
- Start up the original MySQL server and your new schema should be in place.
Earlier today -- between 12:04 and 12:07pm PST, to be specific -- Authorize.net changed the way their API worked, unannounced, that caused successful transactions to not be recorded by us and many others, including ZenCart customers
, and who knows how many others.
A Silent POST is the mechanism by which Authorize.net POSTs back to our servers to inform us of the outcome of a transaction. An MD5 hash is used to authenticate that the POST is legitimate, and one of the values hashed is the transaction amount.
Starting today, they are now passing the x_amount parameter back as 19.9500 (as an example) but still using 19.95 as the amount for the x_MD5_Hash parameter.
An immediate fix would require stripping out the last two 0's from x_amount (if present) when calculating the MD5 hash so that the computed md5 hash matches the x_MD5_Hash passed.
After having spent the better part of today figuring out what the problem was, fixing it, and manually reconciling hundreds of transactions, I'm really hoping they don't change the x_MD5_Hash tomorrow to rely on the new price format (x.xxxx), as it'll break everything all over again, and pretty much scuttle any chances I have of getting any thing done tomorrow.
If you're wondering why your transactions aren't showing up in your billing system, this is why.And if it isn't clear enough, this is absolutely unacceptable.
Not only is an unannounced API change to a heavily-used billing system horrendous, but this specific change is severely impacting customers, and Authorize.net are completely missing to fix the issue or answer any support requests.
I just recently got a new MacBook Pro, migrated my data over from my old laptop with Time Machine, and upgraded to Snow Leopard. Everything worked great, except Fireworks CS3, which wouldn't start and spit out the message: "Licensing for this product has stopped working".
After a couple hours of fiddling around and troubleshooting, I finally came up with a solution:
On the old laptop:
- Open Fireworks and go to Help -> Deactivate...
- Complete the deactivation process.
On the new laptop:
- Uninstall Fireworks.
- Move the "/Library/Application Support/Adobe", "/Library/Application Support/FLEXnet Publisher" and "/Library/Preferences/FLEXnet Publisher" folders somewhere else (you probably should keep them around somewhere just-in-case everything goes bad).
- Install Fireworks.
- Open Fireworks. It should ask you for your license key, and work!
Hope this helps someone else save a few hours of frustration...
Yahoo! has just announced that they will be completely shutting down GeoCities later this year. I was a very early user of the service, and there are a couple lessons I've drawn as an observer over the years.
First is the danger of forcing advertising on your users. To me, this was the start of the slow decline, when the early adopters all moved on and started looking for other services.
But second is the incredible staying power of a large user base. While "all the cool kids" moved on by the late nineties, GeoCities still has an Alexa rank of 149 today, even though they've been providing a mostly sub-par experience for quite a while.
It's one of the best examples of how slowly users can evaporate once you've acquired enough of them, or in non-web speak, that people are resistant to change: once they've found a good way to do something, they tend to keep doing it that way for a while.
This is the coolest thing I have seen in a very, very long time. You need to print out a piece of paper, and then hold it up to your webcam:
Here's a fun little tip: You can open most Sentex key pad-access doors by typing in the following code:
The first *** are to enter into the admin mode, 000000 (six zeroes) is the factory-default password, 99# opens the door, and * exits the admin mode (make sure you press this or the access box will be left in admin mode!)
I'm not sure how prevalent they are, but here in San Francisco, Sentex building access systems seem to be the most popular.
The emerging indie electro scene has really been doing it for me lately. It mixes the fundamental production values of electronic music with some of the more mainstream appeal of indie music, like lyrics, for example :)
One of my favorite songs is "Cold Dust Girl" by an artist called "Hey Champ" that I can't seem to find anything about (bar a few songs on the Hype Machine). Friendly Fires, who's more well known, also has some pretty cool stuff too, as well as Cut Copy.
Hey Champ - Cold Dust Girl
Friendly Fires - Paris
Cut Copy - Lights & Music
SynthaSite, one of our competitors, just released news today that they have closed a $20M round of financing. Now that this is public, I think it's very interesting to examine the difference in strategies we are taking.
We're a big fan of capital-lean businesses: those that are able to accomplish a lot with a little. They have a few large advantages: they're generally better for the entrepreneur, who maintains a larger ownership of the company, and for the investor, who sees their (relatively) small amount of capital used to build maximum value per dollar.
A different strategy, that can also be successful, is to raise as much money as possible, and then buy your way to the top. But buying your way to the top doesn't reduce all of the business risks -- it's just rolling the dice with higher stakes.
The downside for the entrepreneur, in this case, is closing doors: the option of a successful exit at smaller ranges is completely closed. In SynthaSite's case, with $20M raised and a likely $30-60M post money valuation, they will likely not be able to exit successfully for any less than $100M. Not to say that it isn't possible, just that it's much more difficult.
What's most interesting about this comparison is contrasting to Weebly's story: We raised $650k in April 2007, which brought us to profitability with a medium-sized team. Our team is very efficient. We're constantly working hard to improve the service, and we're accomplishing a tremendous amount.
In every sense, we're ahead of SynthaSite for the time being: a larger user base, more pageviews per month across all user sites, faster organic growth, and significantly more revenue. The question I would be asking as an investor in this most recent round is: "Why is there such a disparity between the capital needs of Weebly and SynthaSite?", or "Why did SynthaSite need to raise $25M to get to a similar point Weebly has with $650k?"