I have to agree with the frustration of the apparent minority. We've been using HipChat corporate-wide, and the subset of users that have been using Screenhero aren't going to be able to change to Slack now (even if we wanted to).
And it seems that the wondering our remote development team has been doing about what happened to progress on Screenhero's video codec (pumping 800kb/s+ over my line when nothing is happening on screen is a bit excessive) is now answered with a resounding, "We've been trying to get acquired." Well, congrats on that.
Back to VNC and Skype with no cursor of my own, I guess. But at least it's free and has less chance of my ISP throttling my home connection due to saturating the pipes with Screenhero all day.
Philadelphia airport has been like this for years already. The "airlock" isn't a single-person, but a small room that can lock a handful of people in as they pass individually through some unjumpable turnstiles. I'd post a photo, but there are signs around the room forbidding photography.
Having just gone through the Philadelphia airport in October, I don't remember anything of the sort. Maybe it's only in a specific area for a specific reason? But no, you can go from plane to free air without being in any sort of "airlock" like this.
If you look closely at the metal turnstiles in the bottom-right photo on page 8, you can see that there are glass doors between them. These separate and close by sensor to allow only one person at a time through the exit passage. This room is, by necessity, fully covered in cameras, and as other posters have said, it's a short jump from this into something with software recognition that locks the doors and waits for the armored men with clubs.
Sure, it's a far cry from the firetraps that those glass tubes in Syracuse are, but this method of containment is not new -- we were just not really paying attention to it before.
I was on a team that built a web app for primary school standardized testing. The amount of data presented and collected per student per test is large and perfect for a document store. MapReduce operations allow the app to quickly produce cacheable reports across cross-sections based on requested criteria.
Event the tests themselves are composed of multiple parts that randomize for each student, and lend themselves to the document structure that MongoDB provides. Individualized tests could be assembled from components based on student criteria and stored uniquely for a user as of that time, a thing which would be unnecessarily complex within a relational system.
Could this all have been done with a relational database? Yes, I suppose, but I cringe at the complexity of relating test questions with test answers with users with other data elements ad infinitum using JOINs on both read and write. And this doesn't even touch the topics of sharding and replication, which Mongo made easy in comparison to MySQL or MSSQL.
Choosing MongoDB was the correct decision for this dataset and application. I don't advocate it for every app, but for this one, it was the appropriate fit.
The aggregation framework is ideal for answering these kinds of issues. Mongo has a bunch of aggregation routines that are useful for producing reports on demand, but not on the fly. The trade-off is possible because we know that the collected data (test answers) won't change after it is finalized, and the output of any individual report can be cached virtually indefinitely. (See http://docs.mongodb.org/manual/core/aggregation/)
Also keep in mind that unlike something like a web analytics package that gives you the option to filter and sort your data on any combination of criteria imaginable (for no good reason), the questions that academics/educators tend to need the answers to are generally the same for every new set of tests.
In other words, it's not necessary to enable every possible combination, filter, and sort of output, but merely (ha!) to optimize for the specific results that we know we will need (with a nod toward those results we might expect people to want in the future), and to codify the formulae that will produce those results.
Working with not a school but a testing research company (think of a company like "College Board" vs a "Smallville School District") leads you to produce reports that are significantly more detailed and statistically more valuable than "average score" questions like this, all of which is possible within MongoDB. Though, obviously this treads a little more into work product than would be comfortable to expound upon here. ;)
I don't see anything particularly nasty about the comments called out by the author. One even seemed somewhat humorous in nature (first one).
Look.. if you are unable in this day and age, and this environment, to differentiate between honest criticism directed at your product, in this case "you wrecked my back history", "too much clicking", "too much animation" and insults directed at you (or your child.. what a shameful appeal to emotion), you are in the wrong line of work.
I honestly and truly mean that. If your criterion for "nasty" is a short message containing no insults, no foul language, simply a lack of social niceties book-ending the actual content, you're going to be very unpleasantly surprised when actual end users get ahold of your product and start voicing their annoyance with language that would make Linus Torvalds blush.
Being a labor of love certainly doesn't exempt you from criticism, even less so when you make a "Show HN" post about it!
If you don’t like my work because it is bad, tell me about it.
Here were three very concrete issues presented by random people. I don't know about you, but were I on the receiving end of those pretty reasonable comments, I'd have taken their advice to heart and made changes, not written what amounts to a tone argument in blog post form.
This post is made not in insult of the author or his work - it is made in honest critique of the blog post. Whatever tone is chosen to be read into this post is the reader's choice.
I am the author and I'd like to answer your comments, please:
I agree with you that the jump from the quoted comments to my passionate statement ("If you don't like my work...") was extremely abrupt. It seems to indicate that I believed the criticisms to be ad hominems directed at me.
Refuting the ad hominem ad-hoc, without an example was childish behavior on my part and I would like to apologise for that bit unreservedly. I also realise that it is VERY ironic considering the nature and topic of my post but I hope the rest of the post still makes good points.
Nope, I am not ashamed about the 'appeal to emotion' because it wasn't an appeal to emotion. It is something I personally believe and I'd like to stand by it, please. I think that anyone who's created something deserves a bit of admiration/praise along with the criticism and in that regard the example fits perfectly, IMHO. Let us agree to disagree here?
I beg to differ about the 'honesty of the criticism' and the 'concreteness' of the three issues you mention - IMHO, they were disguised as insults. The same points have also been brought up by others in the same thread in ways that are far better at promoting a conversation and a learning experience, in general.
It'll please you to know that the original creator of the Show HN (TuringMachine) was a far better man than I and I was thoroughly impressed by his responses. I, OTOH, was quick to express my anguish in a public forum and I have received some very interesting criticism myself. Yours is definitely one of them, thank you.
I think that anyone who's created something deserves a bit of admiration/praise along with the criticism and in that regard the example fits perfectly, IMHO.
As a programmer, it's worth keeping in mind that your work—with any luck—will touch the lives of tens of thousands of people. If your work is poor, you will make those lives worse. If your work is excellent, you will make those lives better. Everything you do, for good or ill, may be multiplied by a huge number. This is how programmers can change the world, and how they can make piles of money.
But with this power comes a responsibility: We have to listen to those users, and we have to give them the best we can. If we're unlucky, the users will say nice things while suffering in silence. If we're lucky, some of those users will gripe and moan about something specific. Many programmers spend a huge amount of effort trying to get users to vent their frustrations in detail. One of the most brutally effective things a programmer can do is watch a user through one-way glass from a sound-proof room. You will sit there cursing yourself, mutter, "How could I have been so stupid? I have to fix that immediately."
Now, if a novice programmer shows me their Rails app in person, I'm going to compliment some stuff, rip some other stuff apart (with instructions on how to fix it), and point them towards useful tools. But if a programmer releases software to a wide audience, and that software sucks, I'll gripe as much as any other user. (Of course, if the software is open source, I know the answer will be "Patches, please!", so I skip the griping and send patches along with enthusiastic thank yous for the code.)
If you don't think your work is ready to touch the lives of ten thousand people, and you don't want that responsibility, then I actually recommend against doing a "Show HN". Find a smaller, more personal group, where people will interact with you, and not just your code.
And I say all of this as somebody who has zero patience for nasty personal remarks. The feedback you quoted was brutal, but as a working professional, I've invested both time and money to elicit similar feedback.
Hehe, I'll be the first person to agree that it would be better if HN had a few more "Go you!"s and a few less "This sucks!" - seems people are more likely to leave a comment in the second case but not on the first.
Then again, call me crazy, but I rather like the acerbic and terse nature of hackerdom. Phatic communication is jettisoned in favor of information density.. not something I'd want to live in as a society, but nice in this one slice of life. I can definitely see how that would bother some people and begin to eat at others, though.
> Constructive, no. Especially to someone who didn't understand enough not to do this in the first place
That's the whole point of the comment - to tell them not to do this! If we knew they did this on purpose just to piss us off, we wouldn't make the comment to begin with. We'd just put "Asshole."
In general it's not good or useful to present comments in a negative way, because negative comments cause a negative reaction from the intended recipient. But they're still getting the information that there was something specific they need to improve upon. So it's still constructive, it's just also rude.
He makes a good point in that design generally sucks on the web, though I disagree with practically everything else in this article, which seems to lay all of the blame for bad design on poor web standards and the need for revenue-earning advertising. Design needs to support the content - be it text, photo galleries, or advertising - not vice-versa. The complaint is valid, but the targeted cause is completely incorrect. Instead, try taking aim at factory CMSes that cram all content into a poorly-designed blog-like form factor and a lack of imagination, knowledge, and skill on designers' part for integrating a good design with those tools.
And... Should web designers learn to code? Absurd question. If you don't code, you're merely a hack graphic designer, not a web designer. You don't need to code all your designs, but you need to know code well enough to know that your design can be implemented; therefore, you need to know how to code.
It's a byproduct of a one-size-fits-all-content design for a CMS that all of their output looks like the same drivel. In contrast, if a designer had the opportunity to hand-design each content page distinctly, such a site would look markedly better.
CMSes are not built to produce beautiful design, but to expedite content publication into a designed-once template, so it's no shock that their output typically exemplifies bottom-barrel design.
"It's a byproduct of a one-size-fits-all-content design for a CMS that all of their output looks like the same drivel."
I think this is a really important point, and want to further expand on it. The New York Times was cited as having a bad website. However, on occasion, when they put their mind to it, they produce a truly beautiful page with some fantastic visualization or something. But it's a one-off; you can't produce a beautiful page for every story, so you get the lowest-common-denominator page for most stories.
A literal paper magazine is a concrete artifact, and a set of designers can be tasked with making each page perfect. A web page on these sites is dynamic and may literally not serve the same page twice. If, as a designer, you don't internalize the idea that these are two extraordinarily different domains, despite the superficial visual similarities of the final product, then you're going to have a hard time accurately diagnosing the core problem. And I do believe many designers make this error on one level or another, when I see these complaints.
In Matthew Butterick's defense, I do think he did implicitly make one very concrete suggestion for how those sites can improve, though, at least in terms of design: Get rid of the ads. It's hard, probably to the point of impossible, to create a coherent design for a website when you are selling to the highest bidder the right to put a bright yellow and orange banner with a poorly-photographed item described in a random non-anti-aliased font unaligned with anything else on your page in the viewer's highest-priority visual space, and a different such thing for each page load. Against an uphill battle like that, is it really any wonder that the web designers of the world have collectively given up?