condiment

Disqus is in the unenviable position of having a freemium product that everyone wants but nobody is willing to pay for. Their freemium model provides commenting services with the expectation that value-added features or the need for an SLA would compel site owners to upgrade to paid plans in order to use those features. Problem is, customers that are large and important enough to require an SLA are also large and important enough to be able to afford a custom solution.

This leaves them with the options of transitioning the business model to something that people are willing to pay for, or finding ways to extract value from their free customers.

I know of one other commenting widget provider who got into this exact same morass, but they have opted to leverage the communities that their customers have created to engage in "influencer marketing", where the site owner cooperates with the commenting widget provider to have an above-board "sponsored conversation" with a third party company.

Since it's unlikely that Disqus will be able to successfully integrate advertisements into commenting feeds in a way that doesn't damage their relationships with site owners, an approach like this shifts the value-extraction machinery away from a site's commenters, who Disqus technically has no claim on, and provides an avenue for mutual profit with the site owners, who have an existing relationship with Disqus.

This is an elegant starting point for implementing read-only mode in a Django app.

The appearance of buggy behavior can be expected if this is used on a site that does not strictly implement a REST interface (ie. POST to /resource/new/ instead of /resource/), but that's a flaw resulting from the individual implementation, not from your library, and even with an appropriately RESTful interface you'll still need to display messaging to the logged-in user when GET_ONLY_MODE is set to True.

You mention wanting to provide a generalized means of providing messaging in the template, but I've found that library templates are almost always inappropriate for inclusion into an existing application except in the most trivial of cases. An alternative to generalized messaging might be to implement some crazy logic in process_response() to disable all forms.

I also wonder whether environmental variables are appropriate for this type of change, since administering environmental updates across multiple servers requires a deploy strategy outside of the traditional Git schemes that people set up.

That said, I'll be watching the project to see where it leads. Congrats on the launch.

I agree that this may be the case.

My aim in posting these figures was just to give an example how correlating the number of job postings with each area's population can give additional meaning to the data. So instead of being fooled by a population graph masquerading as a job graph, we can see where jobs outpace the population, and by how much.

For a more detailed analysis, marshaling job postings from additional startup-focused job boards and correcting the city population figures to reflect the metro areas would provide a minimum level of rigor to the data. Comparisons between startup job postings and 'corporate' postings could provide a bit of extra perspective as well.

I would be interested in seeing a follow-up analysis where the figures are adjusted to account for the resident populations in each of the listed cities (and metro areas).

Looking at US cities only, the Bay Area is utterly exceptional in terms of tech/startup career opportunities. Amsterdam (at 4.15 jobs per 100k) is better than NY or LA, but is an order of magnitude worse than San Francisco.

  City		Pop	Jobs	Jobs/100k
  New York	8175133	165	2.018315788
  Los Angeles	3792621	58	1.52928542
  Chicago	2695598	21	0.779047914
  San Francisco	805235	344	42.72044807
  Boston	617594	64	10.36279498
  Washington	601723	23	3.822356799
  Seattle	608660	42	6.900404167
  Austin	790390	30	3.79559458
  Palo Alto	64403	89	138.1923202

  Amsterdam	820256	34	4.1450474

As another commenter pointed out, forums tend to serve one of two needs. Either they are a source of information, or they can be a place for casual conversations.

Your list of 'wants' mainly speaks to forums being a source of information. People ask questions, remark on current events, debate and discuss and create a long-term record of thoughtful discussions.

But Discourse appears to be geared more towards the community aspects of a forum. Mentions between members of a community are relevant in this case, since it gets users into threads and posting. Real-time features lower the friction of using the software and increase rapid-fire communication (we call that "banter") between members. Avatars on the topic index make it easy to see which of your friends are posting in which threads, so you can better decide where to go next.

For this group, forums represent a "Third Place"[1] community outside of their home and workplace groups. I've been building forums software similar to Discourse, on my own for the past year, wagering that this second group of users is larger than the first, and that their needs are only accidentally addressed by the current generation of forums software. I'm anxious to see whether Discourse finds traction in this respect.

[1] http://en.wikipedia.org/wiki/Third_place

I agree with this. Outside of explicitly signaling to users that they have a saved 'draft' of the form, and having them click a button on the page to restore their filled out fields from the draft, there aren't really very many sane implementations.

Some other issues: - doesn't work in IE - saved data doesn't expire - Storage keys aren't unique to the URL, so if two pages have the same exact layout, but different content, identical forms on the page will be filled out with stored information.

So it's a good concept, but I think that there are definitely some questions about user privacy, and that it needs to be paired with some extra UI cues that make it clear to the user that they're looking at draft information, and not something that's saved.

The documentation for the feature is near the bottom of the commit.

This is a really great addition. Every non-trivial Django project I've ever worked on has required extending the user model using both the bolted-on AUTH_USER_PROFILE pattern and hacked together middleware in order to support email-based logins.

While there's a bit of possible backwards-incompatibility with my hacks, it looks like this change addresses both pain points.

I noticed this as well. The older search results have the same width as the new results.

It's also interesting to note that the old results page is displaying multiple results for single domains using result nesting, while the new results page displays only one listing for each domain. The end result is that the same number of 'effective search results' are displayed on the page for both versions.

The gradual transformation of white space into content is a natural evolution in the life of any web product. While the feature set is simple, the design can be sparse. Mature products benefit from rich feature sets, with the drawback of having to sacrifice the sparse visual design that may have initially distinguished them from the competition.

I agree - lists like these don't really have value if you're doing serious mobile web development. A few more examples of broken and inconsistent implementations:

• Viewport - this meta tag isn't supported on HTC phones, so your slick CSS media queries will expose a terrible UI in some cases.

• Websockets - the specification was changed after vendors implemented it, so you have to support multiple authentication schemes on the server side.

• Video - every vendor has their own take on how the controls should look, and certain vendors (I'm looking at you, iOS) disable or override the w3c default specification, so you have to sniff user agents to make a decent custom control. That's not to mention the difficulty of supporting all the various formats.

What adds to the pain is that the browser vendors don't always do a great job of keeping their APIs current, so you have to play the trial-and-error game to tease out the reasons you're having trouble - a game that is exceptionally difficult when the problem only occurs on the mobile device itself.

This sort of ad-hominem attack doesn't really have a place on Hacker News. It's no secret that Scott Cleland is an anti-Google shill, available for hire by fortune 500 companies to write books and testify in front of Congress, but the correct response to his arguments is to point out the gaps in his reasoning and prove him wrong.

Instead, this is an appeal to groupthink to disregard the fair (and not-so-fair) questions raised in the blog post, instead of responding critically to them.

I agree that there are a lot of excellent questions there. The author references the Google-Kansas City agreement [1] throughout the article, and has articulated some very real, pressing concerns about the terms of that contract.

It's my understanding, however, that ALL of the infrastructure providers for a city will have similar contracts with the city, but I've been unable to find any online records for Google's competitors ATT & Time Warner. I imagine that while each of the contracts will feature significant differences, the average person would balk at the privileges the city government affords to each of these companies.

Without those documents to put the Google-KC contract into context, I'd hesitate to draw any conclusions from Google's (possible) response.

[1] http://www.netcompetition.org/wp-content/uploads/Google-Kans...

I think the blog post goes to show that much like words change their meaning over time, icons can also come to represent objects that are much different from their original metaphors. As new generations of people learn to associate concepts with the icons that embody them, the original metaphor loses its importance.

To give an example, the word "microphone" has only been used to represent modern microphones since 1929. The term referred to the mouthpiece for a telephone between 1929 and ~1878, and from ~1878 until 1683, it described ear trumpets.[1]

[1] http://www.etymonline.com/index.php?allowed_in_frame=0&s...

I appreciate how your experience in the late 90s has given you a heuristic for picking up on the signals and leading indicators of a bubble, but I question how relevant it is in this case.

The poetry blog post is just one bad idea that a couple guys had in an attempt to gain a small amount of funding from a notable startup indicator. That's not to say that there aren't more small teams with laughable ideas out there, but I think it's important to note that nobody gave them money. I suspect they went home empty handed because the folks who manage VC funds did learn from the mistakes of the 90s, even if a new generation of wantrepeneurs have no clue.

Which brings me to my point. The niche based thinking expressed by the poetry disruptors and many others is an expression of the realization that individual programmers have the ability to work alone to create products and businesses that are capable of supporting them financially in much the same way that a sole proprietorship would in the physical world.

I'm fairly certain that this wasn't possible in the 90s without outside help, but I think that it explains a lot of the misguided enthusiasm from people who want to build lifestyle businesses, but don't realize that venture capital is not the way to go about it.

This is a really excellent example of the animation potential in CSS. I haven't looked, but I wouldn't be surprised if in the next year or so, a number of libraries are released with the sole purpose of helping actionscript-and-flash developers cross the chasm into CSS-and-HTML development.

Since I wanted to experiment with the parameters, I took the liberty of putting the author's code in a fiddle:

http://jsfiddle.net/AAKcP/1/

What's interesting about Twitter's model is that no data actually comes down to the user when they first request a tweet. Twitter builds the page, loads the layout, and initializes the client-side script, which makes a JSON request to pull an individual tweet after everything has loaded.

This means that to get the requested information on first load, the user has to wait for a 2MB download, followed by another roundtrip Ajax request to twitters tweet retrieval API. This results in the perception of a slow page load, even though the tweet itself comes down the pipe in only 100ms.

In my view, Twitter is an excellent case study in some of the pitfalls of thick-client application design. Mainly that ignoring the first-time-use case will result in widespread perception among users that your app is slow, even when every page view after the first is lightning fast.

One thing to note (and this may be a contentious statement) is that a modern Django app should be created using class-based generic views, rather than the simple function-based views that are demonstrated in all the Django beginner tutorials and documentation linked in this article.

I've found that class-based views help to improve the organization and structure of my applications significantly, so that for larger apps I don't necessarily have to segment each view into a separate file in order to maintain that organization. The primary drawback of class-based views, at least for a beginner, is that the documentation is terse, incomplete, and difficult to understand without a thorough foreknowledge of the underlying architecture. I've had better luck finding solutions by digging through the Django source code itself.

Your comment ignores the next section in the article, detailing how they are caching templates with a high level of granularity, and actively removing template logic that impedes efficient cacheing.

The article goes on to state that delivery times for cached segments of HTML are under 50ms in most cases. While I agree that it would be possible for them to improve the user's perception of the app performance even further via JSON or client-side updates, with the level of performance they described that type of improvement is unnecessary and introduces additional vectors for bugs to creep into production code.

The original question was to know how Google was driving their G+ feedback feature. In the context of capturing user feedback, the point of a screenshot is to relay information about the state of the user's environment to someone else, without the need for physical proximity.

In my experience, users who report feedback are typically concerned more with the data on the page than how the page itself looks when it's rendered. In these cases, a screenshot acts as proof and can immediately focus the problem without requiring a lot of written description. Among users who have non-trivial feedback about a website, the likelihood of their being able to clearly and concisely describe their problem is vanishingly small, and removing the friction of attaching screenshots to their issue reports is immensely helpful.

I don't understand the argument against having to revisit the site and fix it in the future.

Web design takes place from the standpoint of what is possible to accomplish with the most-supported features. From that starting point, vendor prefixes only allow developers to improve their product for users of more modern browsers, and in doing so, place a vote of support for the rapid completion of the prefixed feature.

If you decline to use "-webkit-", you put your website at a disadvantage compared to others that do use the prefix, and you still have to return to the site at some point in the future in order to implement the feature once it's widely supported.

I suppose there's an argument to be made for saving a little bit of hassle in the present time, but that's highly situational and since CSS is so easy I don't think it holds muster.

The blog post doesn't go into it, but I'm curious to know what the long-term implications of this release are for the built-in android browser and the android SDK's WebView and WebChromeClient.

If this is indeed the first step towards decoupling the browser from the Android platform itself, I would expect to see continuing development of those aspects of the SDK to dwindle and die completely, leaving them in the dust feature-wise when compared to native apps, and putting the people who work on web-wrapper-apps at an even more serious disadvantage.

I think the point that many are missing is that is not known for certain that an engineer is more likely to enjoy certain hobbies over others. People use their personal experience to develop a heuristic which this test is designed to reveal.

Getting hung up over the specificity of the hobbies and interests and the likelihood of those hobbies and interests representing either or a lawyer or an engineer is irrelevant, because the only factual data that was provided by the questioner is that 30% of the participants were engineers, and 70% were lawyers.

I agree that this example is a little confusing. The author is making assumptions about the behavior of the Django admin site based on either his previous experience using it, or the Django documentation. In practice it could be extremely difficult to write advance tests for third-party libraries, although I admit I don't have much experience doing this.

Normally I'd expect devs to write tests based on formal specifications of the desired program output (ha! more like a loose mental model). In these cases, all of the eventual behavior of the tested module will be controlled by code that the dev themselves wrote, which makes a much more compelling argument for TDD, but is also more difficult to convey in a made-for-newbies tutorial like this one.

To give the uninitiated an idea of what happened, whenever a plane at the Reno races experiences a mechanical problem, the pilot points the aircraft vertical and bleeds off all their forward speed. Once they're high enough, they level off and glide to the runway for a landing.

For the 'Unlimited' class of race aircraft, this typically occurs once a day during the races. These aircraft are running 3000hp engines, and race at speeds around 500mph.

Link #3 has the best angle on this maneuver. It looks like the pilot lost control shortly after pulling the plane vertical, after which it rolled 180 degrees and pitched straight to the ground.

> What am I doing wrong?

pushState is called with three arguments, {state, pagetitle, url}

If the user navigates directly to a URL, state will be null or undefined, in which case your onpopstate handler should not execute the XHR transition.

I'd recommend testing in both Firefox and Chrome, as each browser handles onpopstate events differently.