ispivey

11 năm trướcdiscuss

Now that's what I call selling pickaxes!

11 năm trướcdiscuss

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.

ispivey

11 năm trướcdiscuss

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!

ispivey

12 năm trướcdiscuss

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.

GMail, Facebook, New York Times, and lots of other smart folks don't show their mobile-web versions if you make the browser viewport very small. Their sites have min-width ~980px when viewed on desktop.

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?

ispivey

12 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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....

ispivey

13 năm trướcdiscuss

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".

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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?

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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!

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

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.

ispivey

13 năm trướcdiscuss

Try https://www.blitz.io/

ispivey

13 năm trướcdiscuss

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.

Submissions

Workers Durable Objects Beta: A New Approach to Stateful Serverless

Secure Modular Runtimes

The Paradox of Meritocracy [pdf]

Show HN: Simpler, New Hire Paperwork Without The Paper

comments