seldo

Good point. Especially since his Amazon affiliate code is tacked onto the end of the URL.

There's a very important lesson in here about investing, but not the one the author intended. From the article:

"Suppose you find a stock that you know will increase in value. You go to the bank and say, “hey, can I borrow $90k to buy this stock? I’ll put down a down payment of $10k.” You’ll be laughed right out of there."

And then, later:

"Now suppose you find a house that you think is a good deal for $100k. ... suppose you go into the bank and say “hey, can I borrow $90k to buy this house, and I’ll put down $10k?” If you have decent credit, you’ll get the loan easily."

Leverage, i.e. a multiplication of your investment by borrowing money, is quite frowned upon when investing in stocks[1] but is not frowned upon, in fact positively encouraged, when investing in real estate. This is because "owning a home" has a sentimental value attached to it by policy makers that equity investing does not. It is a weird market distortion caused by bad policy, particularly in the US.

Leverage by retail investors is frowned upon because they can get badly burned and lose a ton of money. Real estate is not as volatile as equities, but as the financial crisis of 2007 showed, large numbers of retail investors going into real estate solely as a speculative investment can lose them huge amounts of money.

In all investing, the size of your return is related to the risk you are taking on. If you can get a 30% return investing in housing, as the author suggests, and only 6-7% investing in mutual funds, that's because housing is 4-5x more risky than a mutual fund. Higher returns are not just sitting around waiting for you to notice how much more money you can make.

So by all means leverage away if you've got capital and want to take on more risk for the chance of higher reward, but don't go into it thinking it's an "almost guaranteed way" to make money, as the author has concluded.

[1] Unless you are a large bank, but that's a whole other story.

So there are a handful of other services doing this same basic concept (see other comment), and none of them seem to have a story about how this scales past a single developer: sure, you can share the Dropbox folder and all work in the same place, but on something like a website with common CSS files and other centralized assets it seems like that would rapidly become unmanageable.

See also https://harp.io/

Indeed. One way you can use Docker in production[1] is one container per machine: even when you're not using the containers to split resources, the ability to snapshot and move an application and all of its dependencies in a single, lightweight, easily deployed package is very exciting. And because there's no translation etc. happening, running a single container is pretty much identical, performance-wise, to running it directly on the machine[2].

[1] dotCloud don't actually yet recommend running Docker in production, but if you did...

[2] This was part of what Mailgun (part of Rackspace) said in their presentation at the Docker workshop in SF today.

Agreed, a rewording of the title to something a little more accessible would not go amiss.

Apparently "Apple Inc" and "Apple Inc." are separate companies?

There's a widely-held view that public transit is associated with higher crime rates, but it's a myth:

http://www.theatlanticcities.com/commute/2012/01/transit-sta...

In fact, the data shows that if anything, introducing more transit will reduce crime.

My point was not so much that the color is bad, so much that the process by which the color was selected -- ignoring customer familiarity in favor of something that made employees happy -- was very characteristic of Yahoo.

You do learn lots of good things at companies, but you can also learn bad habits -- you can acquire a predilection for long meetings, acquire a taste for political point-scoring over (more difficult, less fun) compromise, and a default position of creating process over improving communication. Those things are survival skills at a big company, but very bad for small ones. The trick is to identify which of the skills you're picking up are good or bad and using them appropriately when you strike out on your own.

I think the weirdest thing about Yahoo's logo is the color. It wasn't until I started working for Yahoo that I first heard that the corporate colors were purple and yellow[1], later changed to purple and white.

The logo on Yahoo.com was -- from birth until around 2008 or so -- red. That was the color everybody outside of Yahoo knew. But inside the company everything that could be a color was purple, people were emotionally invested in it, and debate raged on getting Jerry and Filo (who were apparently the holdouts on red) to change the home page logo to purple.

It seems to me very emblematic of Yahoo that they chose their corporate color first entirely at random and then hung on to it forever out of sentimentality. That's the kind of place Yahoo is: fuzzy and loving but not terribly sensible, business-wise.

Changing the logo is a cliché for a struggling company that doesn't have a lot of new ideas. I actually don't think that's true of Marissa Mayer; a whole bunch of her ideas are along the lines of "do whatever Google did", but then Google is very successful, and at least part of what Yahoo needs to do is get better at the things that Google is already good at. But the acquisition-frenzy in mobile seems smarter, and the acquisition of Tumblr smarter still. Time will tell whether it's enough to turn the ship around.

But I still think it's weird that the corporate color is purple.

[1] Chosen essentially at random because they were the cheapest paints available when they painted their first offices. Purple and yellow do not go together at ALL, incidentally.

At any other company, the marketers or whoever would have said "well, we obviously can't call it KitKat, 'cause that's trademarked". At Google, they know they're big enough that they might actually get KitKat to agree. But would another big company even have tried? I gotta give them credit, in a weird sort of way, for having the arrogance/self-confidence necessary to do it.

Another good (and slightly less flippant) introduction to the country and conflict from the WaPo:

http://www.washingtonpost.com/blogs/worldviews/wp/2013/08/29...

The idea here is apparently that there are people living in a war-torn country ruled by a murderous dictator who will gas his own people and the only reason they haven't left is because they can't find a good programming job. As if they're sitting there on Monster.com as the bombs rain down, desperately refreshing for a job with benefits.

The degree of disconnection here from the reality of the situation in Syria is so enormous as to be insulting, even though that was not the intent.

Well, it sort of did in 2007. But that wasn't a software error.

My experiments with lxc-attach always failed; presumably my kernel was wrong in some way (I followed instructions to get to 3.8, but I am sufficiently clueless that I wasn't sure it had worked, or that it was the right flavor of 3.8).

But that's only the ad-hoc case: the bigger question is, if you have an image with instructions "RUN apt-get install mysql", you're not even halfway to having a copy of MySQL you can run in production: at a minimum you'll need to install a custom my.cnf to suit your application's operational parameters[1], but really you'll want it to be slightly different every time -- new bind addresses, potentially new master-slave relationship grants, etc.. The way docker images interact with configuration management in a grown-up production environment is still really hazy to me.

[1] We are all agreed that running default my.cnf in production is laughable, yes? That information has filtered into the mainstream from the DBA crowd?

Docker is a pretty thin usability wrapper around LXC, which has Linux right in the name, so very unlikely to become useful on Windows (or even OS X, which is BSD) anytime soon.

I'm very excited about Docker[1] as both a development environment and deployment solution. However, from my early experiments, it seems there's an important difference between LXC (which is what Docker manages for you) and a full VM, namely that the model revolves around running one process at a time: you can install mySQL on your docker image, but once it's up, it's running mySQL -- you can't then ssh into it as you would a VM to poke around, modify config files, etc..

There are trivial ways to solve this, obviously. You can stop the image, restart it running bash, use that to modify config files, and then restart it again. But it requires a change of mindset: these things are much more than background processes, but they are less than a full VM. As the piece mentions, configuration management for newly-started images seems to be a missing piece of the puzzle right now, and debugging running Docker images can be... strange. [2] Not necessarily difficult, but different from what you're used to, and learning curves are barriers to adoption.

As this tech matures I think these things will be quickly solved, and I'm looking forward to the results.

[1] Plus Virtualbox, started by Vagrant. See mitchellh's comment.

[2] Unless, of course, I'm missing something. Docker-people: how do you configure vanilla server images to work in your environment?

So is this totally vaporware with a signup button to judge interest levels?

I can't really speak to XBox as it's not my field, but IE 6 was definitely not a clone of Netscape. I hate it with every fiber of my being, but Internet Explorer invented a bunch of stuff we take for granted every day -- the iframe tag is the first one that comes to mind, and they were also the first browser to adopt CSS, way back in IE3. People forget that for a hot second in 1995 Netscape started swinging its weight around as the dominant browser and introduced a bunch of half-baked ideas (the layer tag, for example).

IE6 was a terrible browser, but it was the best browser at the time. The anti-competitive behaviour helped, and then of course they sat on their laurels for years, but the best browser won.

Reacting to new market conditions is definitely Ballmer's problem. Under Gates, the explosive growth of the web took them totally by surprise, and he managed to swing the whole company around, producing the market-crushing behemoth that was Internet Explorer 6, and green-lit the XBox on the basis that "convergence" (i.e. computers running your TV) was inevitable. Those two alone are really tough, smart, forward-thinking decisions that Gates nailed.

Under Ballmer, Microsoft had the same pattern repeatedly: Zune, Kin, Windows Phone, Surface, Windows 8 -- they took too long to see the need, took way too long to make the product, and when they did it was either not good enough, too late, or both.

Oh. I was expecting it to be some javascript-y reason rather than a mere big-O calculation :-P Forgive me, I flew cross-country overnight and am operating on not much sleep :-)

Could someone who understands these things explain to me why flattening the declaration in the second example appears to make it 85% faster?

Nope, they are boyfriends and live together (in Brazil).

I mean, you can. You are CEO, and there is AFAIK no legal restriction on you releasing details of your funding. It's just not in your interest to do so.

I would have thought this was obvious, but orders of magnitude more developers know Javascript than Lua[1], thanks largely to the popularity of browsers as a programming environment.

According to some recent research[2], the three primary factors affecting the adoption of a programming language by developers are, in this order:

1. Libraries available

2. Familiarity

3. Performance

And per the paper, this order of preference is extremely strong. Which means, because of the huge mass of Javascript developers out there, that as soon as a library becomes available to do something in Javascript, Javascript will rapidly become the most popular way to do that thing, regardless of the performance hit.

[1] http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12... [2] http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/pap...

"It's no longer necessary to be a computer person in order to use a computer, and that means lots of people are using computers who aren't computer people!" TRAGEDY!

Lots of people use cars and don't know how to fix them. Lots of people live in houses but hire people to repair the plumbing or the electricals when those things break. You don't have to completely understand something to use something, and that's OKAY.

It's like Freshmeat, for web apps!

(Edit: apparently Freshmeat is now called Freecode? I guess it's been a while since I visited...)

But the alternative possibility, when running a retail business, is that you blow 90% of your time being extra-nice to existing customers and never get around to building the features that would have attracted new users. It depends what stage of growth your business is at; the bigger you get, the unpleasant reality is that the less important any individual customer becomes.

I absolutely can.

I arrived in this country on an H-1B, and then I co-founded a company where I repeatedly examined the option of hiring employees on H-1Bs. It never, ever made sense to hire a foreign employee if there was a local one available, even though I have absolutely no bias towards hiring American citizens.

The only reason you'd hire an H-1B is if you were out of qualified American engineers, because it is so much harder to hire foreigners.

The chief users of H-1Bs are big, boring companies that can't attract local talent at any price. And then they can't hang on to them, thanks to the American Competitiveness in the 21st Century act, which lets H-1B holders switch companies if they get a better offer. The purpose of the law was to prevent companies using immigration status to "trap" employees at lower wage. Because the immigration system thought of that problem.

The argument that for the same price, you get a more-qualified applicant for a given lower-skilled position doesn't fly, because

a) the cost of an H-1B is far more than their salary; the legal fees run into tens of thousands of dollars before you even consider relocation. Foreign workers are much more expensive.

b) the pool of people willing to up and relocate from a foreign country to the US just isn't that big; the same market that applies to American engineers applies to foreign ones, and they are just as demanding.

c) once in America, the H-1B holders don't need to stick around if their salary is crappy, and they don't. See above.

The fundamental misunderstanding that a lot of people have about talent immigration is that they think there are hordes of unwashed foreigners beating down the doors to get in. They're not. Most people stay where they are. That's why you have to make it easier for them to get in, because we need them more than they need us.