ringmaster

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.

I work from home and brew my own beer. (home -> home -> home -> home)

The airlocks are not at all of the terminals, so it's not surprising you didn't see it.

Here's a PDF explaining the airlock rooms at PHL (they call it a "secure exit lane system") with photos: http://www.aci-na.org/sites/default/files/tufts.pdf

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.

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.

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

Is it just me, or should this title be "Zero-Day Attack"? What's the "Under" all about?

Useful, maybe. Constructive, no. Especially to someone who didn't understand enough not to do this in the first place.

Just because you should expect the internet to be full of douchebags does not mean you need to contribute to their number. It doesn't hurt to be nice.

It's ownCloud, but SaaS. Wait... That IS Dropbox.

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.

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.

Better yet, put the stuff that's not related to what's on the tab (like bookmarks) OUTSIDE of the tab. Then I don't have to explicitly hide my bookmarks every time I capture a screenshot of a browser.

In the Introduction, under functions:

  f = m*a
  f(20) = 20a

  f(a) = m*a
  f(20) => 20a

Otherwise, quite nice.

When you write an authentication system with username and password you never display an error like "that password is incorrect", because then the attacker knows that the username is a valid one.

Why does everyone here assume that it's a vast conspiracy when, if they returned everything they had on you, it would be a giant red flag to anyone who was denied that they were being explicitly monitored?

The only way to guarantee secrecy for records that should rightfully be secret (whether you agree with the collection methods or not) is to deny everyone's request.

There are plenty of free and full yet simple CMSes that also fully integrate these features, for no monthly fee.

There is clearly a niche for these small "CMS" tools, but let's be real about what these CMSes are generally not offering: User authentication, localization, custom field indexing, internal search...

Yes, it "manages content", thus is technically a "CMS". But at the level of many of these tools, so is my file system. At best, these tools are useful automated markdown renderers.

This seems especially difficult for a web-based model, and I've personally questioned why anyone would want SaaS when:

1. The company already pays for and supports infrastructure.

2. The company already has a development/IT department that can support an installed product.

3. Viable Open Source alternatives (often using open standards) exist and can be tailored specifically to the company's business needs, either by the in-house team or by eager contractors.

It seems to me that the majority of SaaS providers don't have a way to make their data interoperable with their competitors' products and don't have a way to tailor their product to the specific needs of the business. Worse, there is an impression that SaaS services will offer support better than having someone internal to the company learn an installed or custom tool, when the reality is that many SaaS companies throw up a Get Satisfaction page and call it a day.

To me, a better SaaS sales pitch would include a few key points:

1. Describe the way that the company's data can be taken elsewhere and how well it will work. ("If you decide to cancel, you can push this button and drop the downloaded data directly into X-competitor's product, but we hope to impress you enough with our offering that you never need to do that.")

2. Describe the concrete benefits of a recurring payment over a one-time or per-upgrade fee. ("We are constantly making improvements and refinements to the product based on real client use. Here is a list of the last two iterations of updates, which happened on our regularly scheduled update cycle of X weeks/months.")

3. Describe the specific support and technical infrastructure that the SaaS provides that the company would have trouble or lag time implementing themselves. ("We constantly adjust our infrastructure to your needs, implementing load balancing, reporting, localization, etc. Our techs are on-call via phone/VoIP for your support issues during our regular business hours if there are any issues.")

I'm not suggesting that SaaS isn't a viable business model. I merely posit that the real and valid objections purchasers may have to locking themselves into a perpetual SaaS contract have not been addressed within this post, and are quite common with SaaS products in general. Rephrasing how you present the contract may sell better, but it doesn't change what you're offering.

What is of interest to me in this crowdfunding of celebrity projects is that it gives the impression that crowdfunding could be a way to "solve" the general issue of content only coming from a select few media outlets without it actually doing so. Without the popularity - gained by being part of those initial big-media enterprises - of some of the stars that are able to draw in that funding, there's no similarly easy way for a good grassroots project to get the level of funding they would need for a competitive project.

I equate popular people/companies using Kickstarter to promote and fund their next project to retailers selling products directly on eBay. Yeah, it's viable, has long since drowned out the small guy with something useful to sell, which seemed like the whole point of eBay to me.

I was disappointed by this headline. After resetting my Evernote password this morning, I was looking forward to reading about a new technique that would allow me to avoid password resets in the future. Oh, well.

Is anyone working on such a thing?

(While I'm thinking of it, wordpress.com's password reset should be shot. I get several emails a day because it allows resets by username instead of email or username+email. This whole password issue needs some better minds assigned to it.)

A more sensible rule: If I'm wearing headphones in/over both ears, it's possible I can't hear you, so you might want to make sure you have my attention before you talk to me from behind for ten minutes then get upset when I don't respond. Actually, forget the headphone part of that rule.

Properly indented code is like properly layered design graphics. It should be a habit such that you're unconsciously doing it all the time, regardless of whether you're otherwise doing things "right" or taking shortcuts to be "good enough for now".

To be sure, it makes sense to ship over making everything perfect under the hood. But to many who would read this post, it's granting implicit permission to write code that is utter drek. They hear you offering consent to make code that "just works" over actually giving thought to how users will ultimately use the code or how future coders will maintain and augment the project's codebase. Most developers I've met can't evaluate what "good enough" code is, and shouldn't be given license to release merely working code.

As a person who has spent the bulk of his career now cleaning up other people's lousy code and fighting technical debt, I would ask you to please stop telling other people that it's ok to ship code that, in reality, does suck.

In my work, clients mostly need a site built to perform a specific function, and if Habari fits that task, I use it. There isn't an explicit demand for Habari developers, but there is a high demand for sites that Habari is suited to produce, which overlaps a bit with WordPress' capabilities.

As others mentioned, the main habari/habari repo commit count is low because the main development doesn't happen there, but in a submodule'd repo, habari/system. The purpose of this is to allow you to easily fork the main repo to add your own plugins and themes to it, while the submodule continues to pull from the system repo. It's very beneficial from a maintenance standpoint.

I'm not sure how to explain the community. My involvement has been nothing but beneficial for me, and it has been a similar experience for the people I know the community has touched. Development has been reasonably continuous, as you can see here: http://www.ohloh.net/p/habari

First, let me say this: I love what you've done with the Ghost design. I think it's clean and useful. More on this below...

I am one of the early contributors to WordPress (you'll see my name on wp.org's About page near the bottom), and one of the founders of the Habari Project. We started the Habari Project for many explicit reasons, but in part because the curators of the project (Automattic) were not behaving in a way that we felt was beneficial to the community they had begat. So let me tell you a little about our project:

Not only is the Habari Project an entirely Open Source platform, but it recognizes participants in the project appropriately based on their contributions, something that I did not observe during my tenure working on WordPress.

Habari employs the Apache Software License, which is more permissive than WordPress' GPL. Want to develop a plugin or theme? Is the code tainted by the GPL? In WordPress, I don't really know for sure what parts can be redistributed, if any. In Habari, you can sell your themes and plugins for profit if you want to, or contribute them back to the community -- most themes and plugins so far have been.

The passion of the Habari community for producing good, documented code has (in my mind) been one of the driving forces behind WordPress' "recent" adoption of similar policies. The quality and friendly tone of assistance I get from people who know about Habari has been consistently orders of magnitude better than anything I've seen come out of WordPress, which is a characteristic that everyone working on Habari strives to maintain in the project. One of our guiding principles has been to be a project that is useful for web development education; We've seen a lot of people join our project and learn how to code well, both in the method they use and in the collaborative environment our development often lives in.

We've accepted a policy of keeping up with as current a deployment of technology and standards as our core users can stand. We recently adopted a PHP 5.3 minimum version, and I'm pushing hard to take that to 5.4. Habari simply does not run on PHP 4, and never will because it's no longer secure. We code for HTML(5). We're using CSS3. Our roadmap (admittedly difficult to find online) includes PSR-0 and namespace adoption to more easily integrate with vendor libraries. The use of current technology and techniques is really good for developers, and a refreshing change from projects that insist on supporting every old (insecure) server architecture out there.

And I'm currently making a living (yes, paying the mortgage) deploying Habari as a CMS for clients. It is viable. It is open source.

I know first hand how long it takes to build a working product with a small community. We are admittedly behind in our implementations of some features that WordPress was able to steam ahead with due to their larger community. There are also non-dev areas like marketing where we could use some work. We've been trying (albeit weakly) to lure those kind of contributors to the project.

We had a talented designer help us with our current admin design, and one of the things people comment on most about it is how it's not as cluttered with st as WP's. I like the design you've used in Ghost because it's similar to ours, yet modernizes, and I think our community would like it, too. We've been talking heatedly about a new admin design for our next release...

Habari may not be the thing for you, but I do encourage you to take a look, visit our IRC channel on freenode, and take from it what you can. If you still want to try to bend a WordPress fork, I'm at least interested in the story of your effort and struggle. And if you want to chat about why we started over (though I think it's obvious, maybe it's not to everyone else) instead of forking, or why a new project with a handful of addons (compared to a competitor) can still be a contender, I'm happy to chat. Here we are: http://habariproject.org/

Is there an explanation online about how a network that only has 11k users is worth $50 per year? I can almost see paying that much for the volume of users on Twitter. Almost. The value of a network that is aligned with users over advertisers is clear, but where is the value in such a small network? (This isn't a dig, but genuine curiosity.)

The one thing the author fails to address is what is actually revolutionary about the OUYA: It is a TV-based console without a developer licensing fee.

This is revolutionary because on any other platform, the developer produces the software and the distributor takes a cut of the earnings, and the console manufacturer takes a cut of the earnings. (Remember all that "loss leader" talk when new consoles come out and are cheaper than what it costs to manufacture them? This is why.) By the time everyone gets their slice, you have a pit of dedicated game developers making $15k a year that have put up with distributors telling them what kind of game to make, who then ultimately get fired when they've done their job as commanded. Seems like a career you'd need to love to stick with it.

Even if the numbers don't work out in the end - if OUYA's cut is just as big as the big guys, if the CPU doesn't cut the mustard, if developers can't sell big enough numbers to stay afloat, etc. - it still seems like a worthy enough idea to back it if you're a gamer and want to see what developers could do, free of the shackles of conventional distribution. I can also completely understand people being relentless about personally promoting the console if having more gamers is actually what it needs to get the game developers to break even developing for it.

Then it is important that the emails that are collected are then used for doing that. I have yet to receive anything more than a "verify your address" email based on submitting mine to any of these pre-launch email collection sites. Nobody has communicated with me about features, or tried to use my interest to help develop their brand. Perhaps if that were the case, I'd look upon these pages more favorably. But my thought in general still stands: If you don't have anything to share, you possibly should reconsider collecting emails until you do.

Please don't misunderstand. If you want to use WordPress that's great. My "What were you thinking" comment refers to PHPBB only, which I've seen used more than once for the primary blog for a startup. I'll use more commas next time or something.

That said, Habari is also a good choice for a blog. ;)

Better yet, don't launch until you've actually launched. On the list of startup behaviors that drive me crazy, right after the two in my post, comes "Sign up to be notified of when (hah, IF!) we actually do something" pages. To paraphrase Yoda: Launch or launch not, there is no sign up to be notified.

Oops. Should be working a little better now.