aaronyo

If you want to testify, asking them to subpoena you seems smart. I can't see how a subpoena could make testifying look worse, and yes, it just might alleviate some employers' concerns. But your first step seems to be deciding, for yourself, if testifying is the right thing to do. What if someone asks, "Did you ask to be subpoenaed?" Most people won't go that deep, but wouldn't you still like to feel comfortable answering that? Do you want to let unproven fears about this somewhat crazy but very diverse industry sway your decision? What will you think when you look back on this in 5 years?

Thanks for sharing the examples -- really appreciated.

I'm not convinced that HTML is preferable to other representations of the DOM, particularly for representing UI's and applications (rather than documents). The clojure script wrappers for React I've seen seem to believe, for example, that lisp is better at representing the DOM than HTML and I tend to agree. Especially since any configured IDE should be pointing out missed commas and have rainbow parens.

One thing that is different between your examples and the DOM I've been creating with React is that I tend to make custom tags, and I don't end up with tons of repetitive looking stuff. Your last example is quite readable to my eyes, and would be even more so if perhaps decomposed into some helper functions and, of course, if loops were used and the DOM was populated from some data structure.

Having a preference for reading HTML seems fair, though I prefer closing parens to closing tags for short bits, and the JS formatting problem is one you've already got in the rest of your code base. Also, you'll be formatting HTML + JS bits and not just static HTML like in the example. JSX seems like a good deal of machinery to support this preference.

Big fan of React. For others using it, why use JSX instead of just doing everything in js?

In other words, why is HTML like this:

  <Group style={styles.group}>
          <Image style={styles.image} src='http://...' />
          <Text style={styles.text}>
            Lorem ipsum...
          </Text>
        </Group>

Preferable to something like this (which can easily be done with some helper methods wrapping the verbose React DOM methods):

  $group({styles: style.group},
    $image({styles: image, src: 'http://...'}),
    $text({styles: style.text},
       'Lorem ipsum...'));

No pre processing step required, and of course it's natural to imbed js in, er..., js.

What am I missing? Why keep the HTML part in all this?

Promises help with this quite a lot. http://promises-aplus.github.io/promises-spec/ What 3.2.6.2 means is that any thrown exception is caught and turned into a rejected promise which will bubble up (across async boundaries) until it gets to a rejection handler.

I haven't had too much experience with Domains, but I believe they are generally used for courser grain error handling (because it's a bit verbose to attach them all over the place). E.g., to catch most errors (it's no guarantee what 3p libs do to your context) generated in fulfillment of a particular web request.

Reliability is gold.

Thanks for the pointers. I will read up on GIN and hstore.

If nothing else, duplicating an element from a doc column to a first class field seems reasonable. Also, even in mongo one must define indexes which is a schema of sorts and can be non trivial to change.

It's only one of several interesting comparisons in the slides, but I think we need more data points on the disk space to make use of the data. Does it grow linearly? probably, but is there a +x in there? Mongo has some big upfront disk allocations. Were those considered somehow?

Do you have any thoughts on expression indexes? Assumed I would have to pull out fields from the document to index reasonably on pgsql, but this presentation at least shows that simple expression indexes perform well. I wonder about compound, nested, etc.

Thanks for writing this article!

There's a lot here that seems to apply to equality in general, not just gender equality.

I have two daughters, bi-racial. I struggle with what I think the ideal world should look like and what our actual world needs to look like, today. For example, if there were not a historic misbelief that women are not good at math, there would be no reason to go out of our way to make women only events. But it happened, and it lingers. So I wonder -- how many women have a story about how these women-targeted events helped to open some doors? Def seems like we've swung too far sometimes, but what's the right middle ground?

At home I go for the ideal. My wife and I don't bring up race and gender. We don't attach it to things. My daughters are still under 4, so this is easy. I wouldn't want to say, "girls can do it, too" because I agree with the author -- the effect would be opposite of the intended one. But some day, there eyes will be opened to all those ignorant ideas, and the imperfect "bandaids" that we have. I mean, hell, they already get party bags that are "for girls, not the boy ones." They are already being influenced in ways they can't comprehend.

I think it's possible to get many of the benefits by decomposing your back end into logical subsystems (still running in the same process, etc.) or vertical slices from the get go, rather than starting out with some fixed number of layers that horizontally span your app. I'm building a JSON API right now this way. My take is that Dividing first by subsystems and then by layers prevents the growth of monolithic layers and lets each subsystem evolve independently. If you have contracts between the systems, you can later split them out onto separate boxes. So far, it feels reasonable. You do give up querying across all your tables. We're trialing Mongo (jury still out on that choice) which means we don't have the option to join anyway. The bet is that we'll need other data systems for reporting style queries or other data processing, but that's not the major concern of the JSON API.

I believe that breaking up the code this way makes it easier to reason about the app (isolate probs, etc.) and provides more modularity and flexibility then when your primary division is layers. Not sure why, though, you'd want to go the extra step of physical isolation from the beginning. Why? Unless, perhaps, you feel it is the only way to enforce the separation of systems.

Ethics: +1

"Flaw" seems strong. If you have a small enough and strong enough team, the approach makes a lot of sense to me. I wonder how big the original Storm team was.

The article doesn't even speak to the obvious rebuttals: 1) the "touch screen" Android interface is mostly driven by buttons, 2) the iPhone was launched 11 months earlier, 3) the blackberry looking phone is the one the guy was carrying around for 6 mo.

Right or wrong, an argument that does not address obvious rebuttals is not an argument, it's wishful thinking in an echo chamber.