ispivey

Now that's what I call selling pickaxes!

Understood! I'd looked at Keyczar in the past as a component of a system to manage secrets/keys, but I see it's actually providing about 0% of what Keywhiz does.

I'd love to hear from some of the team who built this about differences between Keywhiz and Keyczar, which to my mind was the best-practice open-source cross-platform solution to date (i.e. if you're not relying on things like AWS Cloudformation config or Heroku config vars to "manage" secrets).

Obvious pieces to me appear to be (1) roles and auditability (2) end-user front-end (3) filesystem interface & associated ease of access for various services. But I'm not an expert!

The advice on min-width vs min-device-width strikes me as controversial:

  Therefore, you should avoid using *-device-width, since the
  page won’t respond when the desktop browser window is
  resized.

I imagine this is because (a) their mobile sites use different interactions that require different DOM and JS, not just different CSS styles, and/or (b) those different interactions might not be appropriate on desktop even if you shrink the viewport and/or (c) it's confusing for the site to work differently when you resize your window and/or (d) they don't want to send unused JS/DOM to devices that aren't going to use it.

Any thoughts, kinlan?

This is probably a new HN record in mistakenly ascribing bad intentions, which is pretty impressive.

Perhaps people are interested in watching some awesome founders speak.

Agreed. To quote Colin Percival's excellent article which addresses both topics:

"Assessing the security of software via the question "can we find any security flaws in it?" is like assessing the structure of a bridge by asking the question "has it collapsed yet?" -- it is the most important question, to be certain, but it also profoundly misses the point. Engineers design bridges with built-in safety margins in order to guard against unforeseen circumstances (unexpectedly high winds, corrosion causing joints to weaken, a traffic accident severing support cables, et cetera); secure software should likewise be designed to tolerate failures within individual components. Using a MAC to make sure that an attacker cannot exploit a bug (or a side channel) in encryption code is an example of this approach: If everything works as designed, this adds nothing to the security of the system; but in the real world where components fail, it can mean the difference between being compromised or not. The concept of "security in depth" is not new to network administrators; but it's time for software engineers to start applying the same engineering principles within individual applications as well."

http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....

There's a bunch of research suggesting that using "he" as a neuter pronoun makes women feel excluded: - First experiment/study I found: http://scholarworks.umass.edu/cgi/viewcontent.cgi?article=12... - Links to more research on the subject: http://alyx.io/educational-resources/gender.html#generic-mas...

Douglas Hofstadter wrote a good piece of satire explaining why it's oppressive by s/man/white, etc: http://www.cs.virginia.edu/~evans/cs655/readings/purity.html

Contrary to what you say, "they" was used as the singular neuter pronoun for a long time, until a concentrated effort to force it out of use in the 1800s. Some examples from a previous thread: https://news.ycombinator.com/item?id=6824352. Some history here: https://en.wikipedia.org/wiki/Singular_they

Given it's possibly (likely) ostracizing and there's nothing categorically wrong about using "they" as a singular neuter pronoun, I think you're on the wrong side of this.

People should certainly stop fighting; the answer is to just roll with "they".

We're used to looking at a pronoun's antecedent to determine its subject. In the sentence, "Jacob finally published a post he'd been mulling for a long time," we don't object that it's unclear whether "he" refers to Jacob. I don't understand why "The user receives the data they requested" is so fundamentally different. You still look to the antecedent; it's still clear.

I grew up taking great pride in "correct" English usage, but I now think insisting on gendered pronouns causes harm without any tangible benefit.

In the most meaningful way, it could be Android for consoles. It's "freely licensable" for hardware manufacturers, so companies will be able to build new consoles without building their own OS -- the same innovation that led HTC and Samsung to become two of the world's leading phone manufacturers.

Imagine being a single mother with a young child. You're a great programmer. But you spend 90% of your time outside work raising your kid, so you can't make the time to make significant contributions to OSS.

...

You can't get a job that requires a Github OSS history. You're severely disadvantaged in job hunting when OSS contributions are a major metric.

If people tested your suitability for a job by pair programming with you, or looking at code samples, you'd look just as good as someone who contributes to OSS. But because OSS is an important metric, you're disadvantaged.

Does this make clear how it's discriminatory?

A few suggestions:

- Use Vagrant and some bootstrap scripts (or Docker) to make giving them a dev environment easy

- Get them to use a git GUI like SourceTree (free & good: http://www.sourcetreeapp.com/)

- Build a workflow around pull requests / review branches a la github/bitbucket/gerrit so you can have them submit changes but an engineer reviews/verifies before it's merged.

In general, empowering them to do this is an investment in the future and well worth it.

That investment amount seemed low, as it suggested you weren't exercising your pro rata rights.

If the initial $400k bought 10% of the company, USV would need to buy 10% of each subsequent round to maintain their ownership, which would be ~$12.5M. That's ignoring varying definitions of pro rata rights, other dilution but probably a good lower bound.

If the initial $400k bought 20% (more likely for Tumblr in 2007), USV invested ~$25M to keep their ownership stake.

Fred seems like the kind of guy who always does his pro rata, so I'd imagine those numbers are closer to reality.

cloud-init for programmatically configuring new instances https://help.ubuntu.com/community/CloudInit

Anyone who complains about how they can't trust the Posthaven team because Posterous was shut down has to put $10 into the 'poor reading comprehension' pool.

tl;dr version: his recommendation algorithm stored an amount of data that was Θ(n^2) + Θ(n*m) for # of users, beers. He optimized that to put a constant limit on the storage space used.

The clearest takeaway is: if you want to reduce the disk or memory footprint of your DB, you need to figure out what tables/rows/columns are consuming the lion's share of the space (there's almost always one column that's way worse than the rest) and figure out how to change your app logic to store much less data in that column.

The OP's lessons learned apply no matter which DB you're using!

Game development is hard. The average engineering role at a games company involves a lot of work on hard deadlines.

It's also tough for some engineers because there's usually a very clear product vs engineering divide -- you're implementing stuff other people come up with, and when they change their minds you throw it out and do it again a different way.

That said, making games is also a ton of fun and is a great way to be exposed to a lot of interesting engineering challenges. If you like games and you can put up with the issues above, you should definitely consider it.

What's "classical" in your book?

Search trees, dynamic programming, and reducing an algorithm's worst-case runtime are about as "classical" as you get; that's why they're in every beginning algorithms textbook.

5% - but it's the very important 5% where I'm optimizing existing code. The "classical algorithmic problems" you reference are almost all optimization problems; there's a naive search/sort/comparison, but how can you do it better?

The algorithmic problems I deal with are things like:

- Why the hell is this API call running O(n*m) SQL queries? Can I tweak my logic and use of the ORM get it down to O(1)? The ORM doesn't let you forget about the underlying algorithms, it just makes it easy for you to shoot yourself in the foot if you don't understand them.

- Why is my single SQL query so slow? DB optimization is very much a "classic algorithmic problem", in that you need to understand the operations the DB performs and optimization is reducing its search space / # of operations.

- We're using too many jQuery pseudoselectors like ":hidden" and they're causing framerate drop on a particular page; can we use some dynamic programming / memoization techniques to dramatically reduce use of pseudoselectors?

- We need to figure out what font size will allow a piece of text to fit within a container on a PDF, but the bounds of the font (space consumed) don't scale perfectly linearly with the font's point-size. Finding the best fit is a search problem!

- And that's not even getting into infrastructure scaling issues! Do you know why Vertica might be a better fit for your data set and end user needs than Hadoop? If you understand the difference between an ETL approach and a MapReduce approach to data analysis, you're thinking about algorithms!

I spend a meaningful amount of time on "classical algorithmic problems" while doing frontend and backend web development, even if I've never had to re-implement mergesort.

Try https://www.blitz.io/

You're right that this filter already exists to a certain extent, particularly among investors.

However, there's an optimal amount of humility and self-doubt that people are looking for. Deviate too far away from it, and people run for the hills. It's just another pattern-matching tool.

I want to offer something positive to go with that downer -- you can find people you can come to trust enough to talk to honestly. There are many investors who are great people who, once they've decided to back you, are going to be there for you and understand the roller-coaster ride and won't hold it against you. You can find co-founders who are level-headed and have the right expectations, and don't get freaked out by some straight talk. You can and should talk to family members and significant others. That way, it can be 'us against the world' rather than 'me against the world'.

The hard part is finding those people :)

In a nutshell, this is why the problem is so hard to fix:

  > When I was raising my first round, it fell apart because 
  > an A-list investor who had given us a verbal commitment 
  > backed out. He did this because he had heard from his 
  > friend, who I had went out for beers with, said that we 
  > were struggling and unsure of what we were doing. I don't 
  > blame the investor for backing out and I don't blame his 
  > friend for relating his honest opinion he took away from 
  > our conversation. But I will tell you that I now never 
  > share my struggles with anybody I think might be even 
  > remotely close to affecting my future opportunities. And 
  > in San Francisco, that pretty much means everybody.

And so founders who want to have the best chances at "winning" have to create an aura of momentum, of inevitable success, around themselves and their companies. That's perfectly understandable too.

How would you even fix that? How do you even define the problem you're trying to fix?

  $> diff @coreyhaines-apology @steveklabnik-apology
  < grace
  ---
  > sorry if i made you upset

[1] http://programmingtour.blogspot.com/2013/01/im-sorry.html

[2] http://blog.steveklabnik.com/posts/2013-01-23-node

They dramatically changed their business model twice. The second change was less dramatic in direction, but more dramatic in that the business had much more inertia.

That's the point of the post, and it's an impressive achievement. Read Tony Hsieh's (Zappos) "Delivering Happiness" if you want to appreciate how hard it is to build a business on drop-shipping, and how hard it is to move to full inventory.

I realize this isn't a battle worth fighting, but everyone needs to stop being pedantic over the use of the word "pivot". It had meaning before Eric Ries used it, and it will continue to have intrinsic meaning no matter how narrowly it's defined in the context of the Lean Startup movement. The business changed directions. Let the man call it a pivot.

HN, where anyone can be a jerk to successful entrepreneurs running large technology companies who show up to share their brains.

For all of you crapping on Peter and his team:

What if the employees were founders with equal shares of the company, and they launched a product and it fell over? Would you blame them for pulling an all-nighter to scale it up in the face of unexpected traffic? Should they give up at 10pm? Midnight? 5AM?

If they're not equal partners, should they immediately give up? What if they own 10%? 1%?

What if they don't have much on their resumes and are excited to make this a successful project, instead of a laughingstock that fell over in the face of scaling challenges? What if they care about each other and want to make this a success for their friends and coworkers?

What's the function into which you plug all these variables and decide when to go home?

It's not black-and-white, pun intended, and if you think it is you're being obtuse. I hope they feel happy and like they accomplished a lot in the face of long odds, and you should too.

dalton, I think that's a good answer but it needs to be way above the fold. I had to watch the video before I knew exactly what was up.

SQL For Web Nerds is a terrific resource for learning SQL. http://philip.greenspun.com/sql/

If your data model is built on top of an RDBMS, learning how one works is the best first step to designing good data models!

What happens to his relationship with Founders Fund?

A venture investor can't sustainably direct opportunities to multiple vehicles that have the same/overlapping mandates.

It's definitely not for everyone.

However, one of the reason this often works for small startups is that we hire our friends. From among my friends, I find the people whose abilities I know best, who I trust the most, and who I'm confident I can work well with. Thus I hire friends, thus I am happy spending time with them.

But yeah, I've worked plenty of places where spending 10-15 days in another country with my coworkers would've been a nightmare. And once a small startup becomes a 50+ person company, this gets really really hard to do.