sah

Cucumber does indeed work. We just added an example: https://github.com/appium/appium/tree/master/sample-code/exa...

The quoted statement was hyperbole. I followed it with as much nuance as I felt it made sense to get into in the broader context of the article.

"If you don't like it, it must be because you haven't taken the time to understand it" is cognitive poison. What evidence will convince you that someone has understood well enough to judge that something doesn't make sense?

I've spent many years using schemas, and I know well how they work and what they achieve. I'm saying they're a lousy tradeoff.

I didn't say anything about domain-specificity.

My primary point was just that SQL is old, and I think the reason it is the way it is has more to do with history and compatibility than what we'd want it to look like if we started from scratch today.

SQL is still around because it was successful. And there are reasons to value compatibility, and to avoid changing things for no reason. But my personal experience using a database without using SQL was pleasant, and I'm anxious to see the world move on to something new and improved.

You're right that I was lumping transactions and data integrity guarantees in with "relational". I was thinking about normalization, and protecting data integrity in ways that lead to joins and transactions.

"They don't exist, if you don't construct SQL queries by concatenating strings and variables."

My point is, people still do this. You never hear about REST-injection or memcached-injection attacks, even though those are possible in principle, because those protocols don't encourage this mistake the way using SQL as a database API does.

We keep things we might need to search in regular columns (typically with indexes). The JSON object is just a way to add extra data to rows, which we can fetch and deal with on the app side. That works fine for a lot of things, and we're hoping it will give us some flexibility around when we need to do schema migrations in some cases.

The connection I see is the attempt to make the syntax English-like. Expressions like "SELECT * FROM users" remind me of COBOL's "ADD X TO Y".

A number of us know MySQL fairly well, and in particular I've seen how it's used by some of the biggest internet companies. We have some postgres experience on our team as well, but it's a little more of an unknown. So experience trumped feature set in this case.

One thing I would say about postgres is that it has a lot of features. As a new user, it's hard to know which ones to use in which ways, and what the downsides might be.

I'm one of the authors of a Python framework called monocle for doing async programming in this style. It works with twisted and tornado. http://github.com/saucelabs/monocle

Haskell Curry made this argument in his "Outlines of a Formalist Philosophy of Mathematics": http://www.amazon.com/Outlines-Formalist-Philosophy-Mathemat...

His idea is that mathematics is the empirical study of the implications of systems of rules.

I'm not sure I understand your concern here. How does monocle make decomposing logic into functions difficult?

The "yield" keyword is an indicator of where control is returned back up to the event loop and other things can happen. We like that in monocle, because we view it as dangerous; in thread-and-lock terms, it's sort of like "unlock everything".

Eventlet (http://eventlet.net/) is an example of a similar framework that decided not to require "yield" at these points.

Well, monocle is headed in its own direction. We're abstracting the generator-style concurrency stuff out from the underlying I/O framework, so monocle works with both Twisted and Tornado, and we're prepared to interoperate with other frameworks in the future. On top of that base, we're developing a framework for working in this style; there are some early ideas in monocle.experimental. We're also building simplified base networking APIs in a way that only makes sense if you're committed to this style of concurrency.

I think the question is really whether you're more compelled by generator-style concurrency, or Twisted itself. If you want to work deeply with Twisted, inlineCallbacks lets you use generator-style where you want, and is maintained along with Twisted. If you want to use generator-style concurrency to its full advantage in simplifying complex evented servers, that's where monocle is going.

I don't think it's very credible to hold Perl 6 up as the standard for how to encourage and enable complete implementations, considering that ten years in, it still has only partial implementations.

http://projects.csail.mit.edu/church/wiki/Church

Yeah, we know our front page is lousy right now; we've got a redesign and a much clearer explanation in the works.

You need our service to make sure your web apps work in all the popular browsers.

We've got a bunch of web browsers in the cloud which you can remote-control via and API, to make sure the features of your site work cross-browser. We use a popular open source browser automation tool called Selenium, which my cofounder Jason Huggins created.

I'm curious whether the above description makes sense, or still leaves you scratching your head!

Loops don't kill the server -- it runs them until they reach a timeout, and then aborts them.

The JVM is threaded, and threads will require a little bit of (careful!) work for the codepad security sandbox to support. I haven't had time for that project yet.

That's me. Sauce Labs has indeed been keeping me ridiculously busy. But codepad is my favorite side-project, and I don't mean to neglect it. I'll find a free weekend and update interpreter versions once things are less crazy here!

That's my mission with http://codepad.org/

http://codepad.org/

  Firefox       55.28%
  IE            17.05%
    7.0  38.08%
    6.0  34.21%
    8.0  27.77%
  Chrome         7.51%
  Safari         7.46%
  Opera          5.53%
  Mozilla        5.34%
  Konqueror      0.95%

"Awesome! I can just store things in a JSON-like list and not have another table or anything!" Oh, what if I want to find all the users who have 'ruby' as an interest? Oh, I can only lookup by key? And yes, there are ways around that. You could create a table of interests and each interest would be a key in that table and it would have a list of people with that interest.

This is not true of CouchDB. Indexing is done on the keys generated by arbitrary Javascript views. A view returning results keyed by interest is trivial.

I think the duration of this outage was basically about waiting for the GFS team to roll in. They knew at 6:44am that they had a crashing GFS Master on their hands, but they didn't decide to try upgrading until 8am, and only escalated to the GFS team after the upgrade failed to help, at 9am. That's the story of this outage, to me:

6:44 AM --- A GFS Site Reliability Engineer (SRE) reports that the GFS Master in App Engine's primary data center is failing and continuously restarting.

8:00 AM --- The cause of the GFS Master failures has not yet been identified. [...] the GFS SRE decides to commence the upgrade immediately in an attempt to alleviate the problem.

9:00 AM --- The GFS upgrade [...] finishes, but the Master is still failing. The GFS SRE escalates directly to the GFS engineering team, and [they begin] live debugging of the failing software[...].

10:00 AM --- GFS SRE advises that the GFS engineering team has identified the cause [...] GFS Master is no longer failing and GFS Chunkservers, which hold the actual needed data, are starting to come back up by 10:30 AM.

You're overestimating the amount of effort and creativity it takes to play a song someone else wrote, and underestimating the effort and creativity involved in the kind of sampling Danger Mouse did on the Grey Album.

Kenny G definitely had the easier job among those two examples.

The differences are hard to notice, but to me the /classic page is subtly better. Things I'm personally interested in ("Fibers & Cooperative Scheduling in Ruby") are mostly voted a couple places higher, and things that bored me ("Steve Blank: Gravity Will be Turned Off") are a few places lower.

Not just hilarious, but truly in the spirit of AFD, unlike most of the lame "pranks" that plague the internet every April 1st. Maybe it was unwise and bad for business or maybe it didn't actually matter, I don't know. But either way, this was a great prank!

Isn't "this feels like clutter to me" what the down-mod button is for?

"Making people happy" is hard to define, but you can pick better concrete metrics than RMSE, and this article offers suggestions on how. An important part of solving any problem is defining success correctly.

I should have added: if you can prevent the hire, probably the most significant thing you can do for the company is to learn how to correct the problems, real or perceived, that have led to the desire for a new engineering manager.

It's normal for the VP Eng to be a peer of the CTO and report directly to the CEO. That said, you are almost certainly being marginalized. Your CEO likely knows he needs your irreplaceable understanding of the company's technology, but otherwise wants you out of the way.

Replacing you as manager is probably not going to work out well unless he already has someone good in mind. CEOs rarely understand how much difficulty they'll have identifying competent tech managers. He's in danger of finding someone who does a great job of "managing up" and a poor job of getting things done efficiently and correctly.

If you can't prevent the hire, making sure you hire someone competent is probably the most significant thing you can do for the company.