rafekett

which line?

Ok, now try maintaining that when there are 15 types of cars and cars are used in dozens of services. You're imperatively expressing a dependency graph that you could (and would benefit from) defining declaratively at a larger scale.

I'd recommend reading the user guide for Guice for balance before you respond. It's worth seeing how nice DI can be.

I feel like these articles come up every few weeks. people don't understand angular (particularly why DI is useful) and criticize it for being verbose or confusing, usually using the provided sample code -- would it hurt to spend some time actually trying to understand the framework than to dismiss it on face because it looks kind of like something people don't like in Java?

i don't think you actually understand these patterns or how they're used. it's useful when you have multiple implementations of `Car` that you want to use under different circumstances. Or when `Car` is dependent on static configuration that might depend on the host it's running on, or might be different in development/testing/production.

the last 10 years in build tools has felt like 1 step forward, two steps back. i like being able to write tasks in any language other than Makefile. however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. new task runners have either eliminated or pigeonholed the (typically one-to-one in makeland) correspondence between tasks and files, meaning the build system can't be intelligent about what tasks to run and which to not.

computers are fast enough that this doesn't often bother me anymore, but i've run across some huge Rakefiles that could benefit from a rewrite in Make.

Stripe and Square don't remotely compete. Stripe is in a low-volume, high-margin world (flat fees), which is the opposite of Square's situation.

overreliance on /dev/urandom in the presence of little entropy is a well known performance problem on servers. that's why http://en.wikipedia.org/wiki/Hardware_random_number_generato... exist

I can confirm this is the case, which is why services like http://www.binlist.net/ exist.

guess without reading the article: uses less material per unit length of track

> To get started you had to understand things like headers

since when is this a problem? really.

I think the short story is that the engineers at Facebook feel pretty productive with their stack today. Making a new language that basically fixes up PHP is ideal for them because it gives them good confidence they can get the benefits of static analysis without sacrificing much productivity. That level of productivity + the sheer numbers they have make Hack a more attractive option.

one of many reasons why I will never again live in New York or locate a business there. I refuse to pay taxes to a state as oppressive as the government of New York (city).

nice service that people take for granted working at a big company. at SQ we had designers who just made keynote presentations.

when I went for an OSS sprint it was completely locked down. the security was very disruptive -- we really weren't allowed to leave one floor of one building, so it was pretty difficult to get any kind of focus room even for half an hour. I was working on a facebook project (one that saves them tons of $$$ at that) and we couldn't leave the building to go to a conference room even when escorted by two engineers.

what do you do when rsyslog drops log events?

while we're at it, let's let graphite die too. in a fire.

the example is poor, butI think you're missing the core point here -- slow tests. I don't think this really improves readability or organization much -- but my real world experience with a giant slow rails test suite gives me 100% confidence that patterns like this are the only way to not have a completely intractable giant test suite.

git-grep is something you only learn about when you work on a large codebase, and something you never stop using afterwards.

I'm in this camp. Have you ever been to a talk given by Scott Chacon? He demos git on Github's internal repos. It's clear that there's little value placed on keeping a feature under wraps before it comes out over there.

I believe they were going to but were met with stern resistance from the community and caved.

i agree with all but #2. this seems to embrace conciseness as simplicity or understandability. it forgets the more cardinal value that explicit is better than implicit.

hmm. i've used git pretty regularly since 2010, after coming from svn. the more i use it the more it reminds me of being the administrator of a website -- sure, i _could_ have a password recovery form, but it's much easier for me to use this python script i've written that just edits a user's row in the logins table... that is, i've found git to be incredibly powerful, but in the process i've forgotten the safe way to do everything.

Guido was a salaried employee of CWI at the time. he made money for his efforts. in fact, he has always been paid to work on Python, at least part of the time.

before i sign friends up for this, i need to know: is there an unsubscribe option?

Your idea would make it easy to add an unacceptable amount of overhead to GC. Since GC is already the biggest performance killer on the JVM, I don't think it makes sense to give developers this particular loaded gun to shoot themselves in the foot with.

maybe i'm being a downer, but i feel like the latency of an HTTP request defeats the purpose of using redis in 99% of use cases.

Yes, for some time (the dark ages I like to think) programmers had to sacrifice productivity to make things faster, or to make them fit in memory. The original C compiler had a 6 character limit on variable names, leading to abominations like `strstr()`.

Fortunately, by the Pentium era, which was when PHP was designed, those times were long gone.

"X made this design decision before us" is never a good justification for any design decision unless the decision is truly arbitrary (i.e., are arrays 0 or 1 indexed?) -- then it might be better to stick to what's more familiar. If it was a good design decision then, then there must have been some reason at the time that should be true now to give a good case for repeating a design decision.

It _is_ their fault, for repeating the stupid mistakes that Kernighan, Ritchie, et al made when designing Unix and C.

If logging doubles your per server costs then you're doing it wrong. The amount of noise you'd have to be producing there would make logs useless anyway.

I agree logging has to scale, but it doesn't look like there's any substantial difference between anything benchmarked (it'd have to be at least an order of magnitude for me to care).