krobertson

Better subject: "How not testing my website with all browsers, even IE, and ignoring metrics for months cost me dearly"

I agree. You can find previous generation server hardware pretty cheap through liquidators or ebay. Availability may vary in India, so that may be a factor.

Hardware availability after the initial purchase is certainly a big longterm consideration. I can easily search for "dell 2950 raid" or "dell perc 5i", match the individual part number to the I have, and be good.

Preface this by acknowledging don't know much bout the OP and his professional experience, but he is likely young.

I don't care for the "I'm now the Lead Software Engineer with my own department". If he was in manual data entry, he is likely young and has limited professional coding experience to cut his teeth on.

He is likely soloing himself, will limit his advancement by not having peers, and when he changes jobs he may have unrealistic expectations not realizing these.

Ohh no, 4.2Kw in Sacramento... just thinking in terms of what that would be in HE.

I must need sleep, since just realized I calculated kW/$. :)

With my math corrected though, getting about $338/Kw.

It is great for DR if it can support your IO load, considering the cloud sucks for IO. :)

One project moved from AWS to a managed hosting provider with gear built to our specs mostly due to IO issues... continued to grow and then went back to AWS looking to do an easy DR process. Had some issues just with EC2 being able to keep up with replication at that point.

The one thing I'd like to try with AWS though is their Direct Connect service. Basically colo in a facility near them and get a cross connect to EC2 (think it focuses on VPC). http://aws.amazon.com/directconnect/

IO loads on real hardware, EC2 for all the other stuff.

Doing the quick math from what I remember HE's pricing to be, it is cheaper per watt... at my peak I had a full rack and 4.2Kw and only actually using half a rack. It just feels wrong to have to get 3 racks at HE and basically just be 4 servers per rack.

HE just seems at weird economies of scale. Pretty much no cooling, 70-80% of the warehouse empty, and $1/Mbit (they lower now?). If Fremont 2 gets more populated, will it inherit the same power issues? Part of me doesn't want to know.

I've heard good things about SVTIX though... haven't toured or had anything in there, but it seems to have a good rep.

I toured Layer42's Mountain View facility and it looked pretty good. Don't remember exactly what the power prices were, but it was comparable to Sacramento. I stuck with Sacramento since it was closer.

HE Fremont is a total ghetto. 15A per full rack, essentially no cooling. Its just a massive open warehouse. Fremont 2 is much better than Fremont 1, but still had one power outage when I was there.

Connectivity wise, they are pretty good. Sometimes may be a little more DDoS prone though.

I've been in several Sacramento datacenters and currently have a half rack in in Webion in Rancho Cordova. Ragingwire is freakin expensive.

The pricing with prgmr.com looked pretty good though. SJ gets better bandwidth pricing, and probably about just as crappy on power.

If looking for a serious deployment, generally have to look outside CA. Great connectivity, but power is what will kill you.

Actually, not telling them may be illegal too.

This isn't legal advice, but as someone who worked when I was a teenager, parent consent may be required, so then they'd know you are a minor.

Under US Federal law, it is illegal to work under the age of 14. 14 & 15 can work but only during non-school hours. 16 and older are fine, but under the age of 18, parental consent is required.

Taken from: http://www.dol.gov/dol/topic/youthlabor/agerequirements.htm

The illegal-to-them comes from hiring child labor without the proper consent or regulations met.

Four years in and just now doing a seed round. They were likely young, inexperienced, and mostly technical. Unfortunately, technical people don't always think of those ramifications.

And it was probably a series of pivots along the way that individually didn't look at big, but over time transformed immensely.

> Cloud Foundry is really not at the point where it can replace Heroku.

I'm curious what Heroku still does that CF can't.

As another person who is building infrastructure on Cloud Foundry like Lucas, I am biased, and don't quite agree with you.

I think from a user perspective, you can do as much with CF as Heroku.

Architecture wise, you can't compare CF to Heroku because its closed source. Heroku could be even more overblown and complex than CF for all you know. And even then, a PaaS by nature is sort of complex.

Administration wise, CF still has a ways to go. It isn't the easiest to deploy and manage, docs need work, etc. But that isn't something that is user facing or comparable to Heroku.

Amen. Talk about "running to mommy"

I agree. I think the interesting aspect is that they built a service that serves an impressive number of users on fairly common technologies.

There isn't anything very revolutionary about their stack by itself. FB didn't buy them for their technology... they could have replicated that on their own.

If they want to be talking about infrastructure, the story of using common tools at high volume is more interesting that just what tools...

Not always. Most employers will likely realize the differences in cost of living and try to get you relative to your local market. One of the benefits of remote employees for an employer is around being more cost effective.

I've also been in the situation working for a remote employee who tried to pay comparable CA wages (wasn't in the Bay Area), but didn't understand the true cost of living differences. Also been on the flip side, in office in SF and looking for people in cheaper markets.

Their hybrid offering still leaves a lot to be desired. They're more like two separate products, and even being on a sales call with them involved people from each team. It lacks a unified product experience.

What is it based on? Global activity? I am seeing 99% "Eclipse Platform project repository".

I love APIs. One recommendation though would be to change the server response slightly for the API call. In Chrome, it had me download a file instead of showing the response in the browser. I think it might be because the response has a Content-Type "text/json" instead of "application/json".

http://stackoverflow.com/questions/477816/the-right-json-con...

The service only pulls info from hosting services like Github/Bitbucket. If you host your own, you can't show up on their "awesome" list.

I wouldn't say none, you still need to setup your DNS settings with SPF/DKIM to support Mailgun/Sendgrid. They usually have documentation how to do that, but you need to be sure to do it. :)

Good article though... overall, if you aren't in the kind of email volume you guys are, just use Sendgrid/Mailgun. Sending email is a PITA and just pay someone else if you have the option. :)

I've done custom debian packages from scratch and always found it a pain. I've also done customized source builds and still prefer this approach because its simple, slimmer, easily version controlled, and wrapped up in a single command.

But there are many ways to fry an egg. I prefer this way, but overall having a package is a big plus for commonality between systems and convenience vs simply building from source.

I prefer to custom build deb packages (on Ubuntu myself) using a project called brew2deb:

https://github.com/tmm1/brew2deb

It provides a DSL for describing how to build and package something, including patching, and already has a nginx formula:

https://github.com/tmm1/brew2deb/blob/master/packages/nginx/...

Will likely be adding in this patch today...

Agreed. It can sometimes be a side effect of small companies, or young developers living the startup lifestyle. Not saying its bad or the root of the problem, just an observation.

More so, I think it comes more with modern languages that don't force you to manage memory anymore. When you don't need to alloc/free everything you're using, it is easy to get lazy. Factor in never generation who've never worked outside a managed memory language. There are minute details about retaining references, having multiple copies of the same data, or other leaks (file descriptors?).

I think this is a pretty common misconception overall. Working at startups, often find devs with multiple hats sometimes doing ops tasks. Seen many who hop on a system trying to diagnose some issue, fire up top and proclaim "OMG, the problem is we're running out of memory!"

2nd is explaining virtual/resident set size.

Aren't they pretty much all the same? :)

Don't know if the author is reading, but would be nice if the main domain list was sorted.

Have dealt with a few of those mentioned and agree, and was going to forward the site to our internal recruiter to make sure don't use them. :)

He's also optimized around his current setup and think that would carry over 1:1 to another platform. He has 24 unicorn workers now, so he thinks he needs 24 dynos on Heroku.

Whenever I've moved an app between platforms or server setups, I benchmark an individual instance and figure out your needs that way.

Also find it interesting how his current setup is all on a single server. So his entire service is one massive SPOF. On Heroku, he'd be highly available and horizontally scalable. How much does downtime cost him?

The "they" in this case being the Rails team and not Github?

A common thread here seems to be grouping Github and Rails.

Its interesting how bring up their Terms Of Service gets discounted and the holy war just takes over. No where did I mention Rails, Ruby, community, or anything else.

Me: He broke the rules. Retort: I like plant.

Disclaimer: The actions of individuals are representative of individuals. Drawing dramatic generalizations accomplishes nothing. Yes, there are more vocal asses in every community. For every asshat there is likely 100 quiet people. Right now, I'm being an asshat.

Gee, homakov is Russian. All Russians must want to hack your site. Really? No, its a dumb generalization.

Where have they been dicks? Please elaborate.

From all appearances, GH is taking it quite seriously. Because it is a serious matter. Egor on the other hand wasn't taking it seriously.

He clearly violated their Terms Of Service. If you like and enjoy a service, exploiting it to prove a point is not the way to do it. It takes no time to spot the clause about exploiting the service.

Legally, it wouldn't be good to have a TOS and then not enforce it. You never how that could bite you later on if you get dragged into a dispute.

All this "they should give it back when they're done" is pointless. You can't reward stupid behavior.

Like this? https://github.com/blog/1068-public-key-security-vulnerabili...