andymism

> It could also be that they just aren't being implemented in a very intelligent way that makes them easy for people (or that the nerds are wrong–gasp! :)

I agree. They are not implemented in an intelligent way which makes them clumsy and painful to use.

My point about nerds is that us nerds are much more likely to live with pain to use fun, new tech. And as far as my experience from Google IO and my day-to-day work life, it doesn't seem to be the case here.

This was a timely article as I recently had a fun time playing devil's advocate regarding QR codes in a friend's start up idea. She insists that they are a useful, convenient, and a big trend. I countered that they require too much effort and precision to be mainstream in their current incarnation. While the promised convenience sounds great (which was basically her argument), the current implementation does not live up to that promise.

While in Las Vegas, recently, she mentioned that she went to an art gallery that had QR codes on the placards for paintings that were for sale. One could scan the code and be taken to the gallery's website where you could then purchase a print. Prints cost in the range of a few hundred to a few thousand dollars. Who goes to an art gallery in Las Vegas to walk out with a few bookmarks so they can spend a thousand dollars at home? It's a use case with lots of cool factor and wouldn't-it-be-awesome-if's, but that does not pan out with real, normal humans.

I was at Google IO this past May with 5,000 other nerds. I spent much of the time walking around, talking to people, and figuring out whose brain I wanted to pick further. On our admission badge was a QR code that attendees could opt-in to having all your contact information on using a checkbox on the Google IO registration page. I had opted in for this. What do you think the primary method of exchanging contact info was that weekend?

You guessed it.

Business cards. Only one person asked to scan my QR code, but this was after he asked for my business card first (I ran out). The rest of time, I logged email addresses and names in my phone or wrote my name and email on a piece of paper.

QR codes are a flop. I know this because I was in a room with 5,000 fellow nerds for a weekend, in 2011, and almost none of us cared to use it.

How can you be the hot new tech if the nerds don't care to use you?

It's not about the PDF copy having zero marginal cost. Manning is a business that is trying to offer an incentive for customers to buy direct from them. Are you suggesting that they destroy their own value add?

Also, I seriously doubt that Manning responded to d0m's request by literally saying:

"Fu, it's your problem, next time buy it at manning, not amazon"

Pronounced "F-U" and not "foo".

The moment you twist someone's wording to sound that aggressive, you're overreacting.

IIRC, Posterous does this as part of their caching strategy. Static content is HTTP cached and dynamic content is pulled in via AJAX on page load. The result is that the primary content is available fast and dynamic secondary information (such as view count, etc) pops in soon after.

The distinction between web sites and web applications is not granular enough to make this decision. What you should be considering as a developer/designer of a web site/app is not about what bucket Flickr or YouTube or Yelp falls into, but what specific screens should be accessible with shebangs and which screens should not.

Flickr's photo indexes and Yelp's listings and reviews should probably be accessible via regular old URLs. But Flickr's uploader screen? Adding a new listing to Yelp? If you're ok with leaving behind users who have javascript turned off, it simply _does_ _not_ matter. In those cases, why not take advantage of the snappy UX that shebanged interfaces offer?

Agreed. On top of that, the discussion about time in app is an implicit straw man. It's no surprise that one set of metrics might be more important to LinkedIn versus for Facebook, but the relative importance of a set of metrics for two different businesses targeting different audiences is a weak argument for their relative valuations.

Facebook has fundamentally changed the way millions interact with their social circle; LinkedIn's impact is smaller by far. I find this a pretty simple explanation for much of the difference in their valuations.

As an introvert myself, I follow a short list of rules/steps before big events/social gatherings that starts a few days before the event itself. Although I'm usually physically exhausted the day after the event, I'm often complimented and mentioned as 'quite the social butterfly' by friends and acquantances during such events. These things don't take much time, but do take effort. The payoff is worth it though (firends, fun, and fame ;-) ). YMMV.

1. Ditch the alcohol. Or, at least, know your limit (that gives you a buzz) and have 50% less. You want to be able to remember faces and names of the people you meet and some details about your conversation. So make sure your mental faculties are reasonably sharp.

2. Spend most of your time listening. Pretend that you're interviewing the person and ask them open ended questions about their job and hobbies. You will almost certainly find out something interesting about them that you can discuss further. Who knows, maybe they're a programmer just like you!

3. Get up to speed on current events. I personally try not to read much news, but for about 3 days heading up to an event, I'll skim headlines and first paragraphs news articles on a broad range of topics (takes less than an hour each day). The goal here is to create little hooks that you can hang conversations on, it is not to become an expert on a random topic. You'll most certainly run into someone who'll know more than you and will gladly tell you all about it.

4. Keep it light. You and the other guests are there to have fun. Downers are for drug addicts. Politics and religion is for reddit.

5. Work the room by having short conversations with lots of people and asking for introductions. Introductions are as simple as asking, "So who else do you know here tonight?".

6. Prepare yourself mentally for being at the event. Clear out to do's and other distractions. I kind of psych myself up for chatting with lots of people in the same way others might psych themselves up for sports contests (metaphorically, of course).

All of the above can be summed up as:

1. It's not about you. It's about everyone else who you'll meet, the friends you'll make, and making sure your significant other has a good time (especially if he/she is an extrovert).

2. Prepare. "A hard drill makes an easy battle".

I've learned to turn down small talk heavy events that I can't adequately prepare for. I've also learned that you can have a 15 minute conversation with someone by just asking what they do for a living and how they got to doing it. I've learned that stock phrases (aka, pick up lines) really work. My favorites are:

"Hi, I'm Andrew."

"What do you do (for a living)?"

And, if I find out the person has an MBA: "So what the hell is future-discounted value?"

I'm also tired of seeing HTML5 this and that (as it's mostly grossly misused to mean 'highly dynamic'), but this

  <!doctype html>

Reference: http://dev.w3.org/html5/spec/syntax.html#the-doctype http://ejohn.org/blog/html5-doctype/

Karma's really a proxy for community participation, albeit kind of one-sided since you don't get increased karma for up-voting someone else (and rightfully so). I don't think it would be unreasonable to say that if you don't participate, then you don't get to solicit the help of others.

But the bar is much lower than that. For the purpose of just keeping spam accounts out, I think the combination of a karma threshold with average non-karma accruing activity over time (such as upvoting others, clicking through on articles, etc) could be an effective filter.

If you're doing the work for a flat project fee, ask for 20-50% of the fee up front before doing any work. If you're going to be paid hourly, you probably would have provided at least an estimate of hours that the project will take. Your retainer should be 20% of the total of your rate times hours estimated.

Always request a retainer. Especially for new clients. Even more so for friends and family.

Most of the time, I'd argue that you can't really say 'No' at all. Not if you want a happy client. If you do say no, then you'll just end up delivering an end product that isn't exactly what the client wanted and didn't have that feature they requested. I can't imagine any situation where that results in a happy client.

So what do you do? I say: Get the client to say 'No' for you.

Getting people to understand the trade-offs and sacrifices for what they might consider a "quick 'n easy" feature is the name of the game here. You've got to flesh out all the assumptions that they have when making such a request so that they understand what the impact is on schedule, budget, and code.

But what they still don't understand is why Projects X, Y, and Z will have to be pushed back for 2 weeks or why Joe and Mary will have to pulled away for 3 weeks just to do this "quick", "simple" thing. At this point, what I usually do is spec out the entire feature (front-loading all the mockups, copywriting, etc) on the spot or in a meeting immediately following. The reasoning is that "If you want this feature tomorrow, then it has to be designed today." And well, practically speaking, you can't implement it by tomorrow if you don't know what you need to do yet anyway and, worse still, you'll build the wrong thing if you don't at least discuss it in some detail with your client first.

If the feature isn't important enough to spec out in detail now, it's not important enough to be done by tomorrow.

In my experience as a solo webdev freelancer (so take it for what it's worth), clients usually see my point and give in when they realize that we're trying to compress about a week's worth of back and forth emails, phone calls, and let-this-idea-sink-in time into about an hour--sometimes even realizing that they don't really know yet what they want.

You can actually do better by selling software and hardware infrastructure to other evil geniuses working to antagonized (er... disrupt) established companies.

Assuming your cofounder is also involved in the design of the product, the easiest way to show him the rest of the iceberg is to sit down and write a functional spec of the feature together.

As a non-technical founder, he's likely just thinking about the end result of feature X, not the implementation of it, whereas you see the technical details at a much higher resolution.

You don't need to do this every time with him (although it's not a bad idea)--just once or twice will be instructional enough. The goal is for him to understand the amount of thinking and problem solving that goes into feature X before a line of code is even written.

One of the major advantages to actually making things is that the students will be making things with each other. As many have said before, figuring out who to build a product with is just as important (or more so, even) than figuring out what to build.

I agree that, in general, you should educate yourself about what your doctor is telling you and push back a little bit. It's probably a good practice of any thinking person.

Routine conditions are a case where self-diagnosing will yield adequate results most of the time. But outside of the most common conditions, a smart but not medically trained person will end up treating symptoms rather than causes. A good example is blood pressure. You can walk into any pharmacy and find out within a minute if you have high blood pressure. For 80% of cases, you could probably just look up the most popular generic medication, start at a low dose and adjust a month at time until your blood pressure is normal. But what about the underlying cause? It could be an endocrine system problem, enlarged heart, arterial narrowing of the blood vessels from the kidneys, or ion channel exchange imbalances, to name a few. It is routine for a general practitioner to check for these and other causes and interpret the results of their tests, but is decidedly not routine for most smart people.

> diabetes patients test their own blood. If they need more insulin, why does a doctor have to prescribe it

In many states (California is one) you can by certain brands of insulin OTC. The limitation is more a decision of the manufacturer than it is codified into law. Pharmaceutical companies are well known for milking their patents as long as they can and then lobbying hard for OTC status as soon as the end date on their patent is coming up. This gives them the opportunity to continue to push their brand and squashes any competitors who are still behind the counter.

You need look no further than allergy medications for an example. Claritin and Allegra were the biggest brand names in prescription allergy medications just a few years ago. But as Claritin's patent protection period was ending, its makers pushed hard to go OTC. And they did. The result is that Claritin dominates the OTC allergy medication category while Allegra is no longer covered by insurance plans because an OTC alternative is available. It's easy to guess what this did to Allegra's market share.

> There are lots of conditions where it is easy for the individual to maintain their own medications

Maintain is the key word here. OTC availability is only half the story. Your comment makes the assumption that someone knows that they're developing some sort of condition, say diabetes, in the same way they know they're coming down with a cold. How do you know you're becoming diabetic without a doctor's examination and follow up? Are you just going to know think one day that "Hey, maybe I'll google why I feel tired all the time and have been bruising easily lately..."

I know that the medical system is under a lot of fire these days and it's everyone's favorite axe to grind, but some good reasons that prescription control is necessary is to (1) control easily abused substances (this means narcotics as well as antibiotics, though the litigious culture here in the US is quickly rendering traditional antibiotics useless) and, probably most importantly, (2) maintain communication with your healthcare provider. Doctors use prescriptions in order to monitor your compliance and require (at minimum) annual visits so they can check up on you, even if it is only for 5 or 10 minutes. Maybe that decrease in energy is a side effect, or even that occasional but not cold related cough. Your doctor will recognize this and will be able to suggest changes. You probably had no idea a cough was a related side effect. Even if you did, did you keep up on any of the literature for the class of drugs you're taking in the past year? I doubt it. You have better things to do with your time.

> Doctors know a lot, but all doctors don't know everything about every medical condition.

You're right about that. But that's why we have a system of specialists. Even a less than average doctor will refer you up and down that chain until you're dead, out of money, fixed, or have found a way to live with it. It's like throwing a reverse exception where it gets passed from the most general to the most specific handler. Or a search tree where the root is the most general case and the leaf nodes the most specific. Of course it could be more efficient: science could be more advanced, doctors could be smarter, insurance companies more willing to pay, and patients less litigious. But the way doctors handle medical cases has evolved this way because it can solve the most common cases the fastest. And the rare cases, the exceptions? Well, they're rare and the exceptions.

The reason you see so many cases of patients out diagnosing doctors on TV is exactly because they're the rare, man-bites-dog kind of story. How many lottery losers do you see on the nightly news? Safely landing planes? How about stories about cars not piling up in bad weather? My advice to you (though you don't want it) is to stop watching TV. Or at least, stop watching TV and then using what little information is conveyed to make generalizations about the world and how society should be run.

--

What became obvious to me from reading your comments is that you don't know what you don't know and that you assume that what you don't know is trivial. There is an unprecedented wealth of information at our fingertips. That's a cliche. But no number of articles read on Wikipedia, no number of Google searches, or stays at a Holiday Inn Express can replace the actual practice of medicine.

> My biggest criticism of the barefoot running crowd is that they usually treat it as a way of life.

This behavior is a common pattern with groups on the margins. Although it can be annoying, it doesn't have any bearing on the merits of barefoot running. The Ruby community is a good example, as are vegetarians.

I'm failing to see how callouses would be such a show stopper with barefoot running. Any of the minimal shoes available on the market are enough to prevent callouses if you're concerned about them. I've never owned a pair of traditional running shoes that didn't give me agonizing arch pain within 5 minutes of running, but I've been running for 6 months in a pair of Vibram Five Fingers with no pain at all--I've also got no ugly callouses.

> Feet, legs, and backs aren't evolved to properly support overweight joggers.

You're probably right on this point. But, to me, it's a lot like saying that our cardiovascular system is not properly evolved to transport blood with high levels of cholesterol.

Edit: The callouses bit.

Looks like this one is already on there: "Argument from fallacy: if an argument for some conclusion is fallacious, then the conclusion is fallacious."

Link: http://en.wikipedia.org/wiki/Argument_from_fallacy

I thought the username and password was a good choice for this test. There really wasn't that much of a difference in phrasing between Patrick's form and the Huffduffer form. The most likely explanation for the drop off is the difference in the audience these sites are made for.

As far as design decisions like these go, the data doesn't say anything on an absolute scale about the merits of one form versus the other, but it does tell us which is more effective for a particular audience in a particular context.

The real problem isn't that the line ignores cognitive research, it's that the rest of the essay is built around a statement that is on fundamentally shaky logical ground. See fallacy of equivocation. The OP intentionally misinterpreted 'achievement' in the context of video games (simple trophies or indicators that you're playing a game in the intended way) and applied the abstract, idealized meaning of achievement instead.

While I more or less agree with the intent of his essay, writing that's based bad analogies and fallacious statements just end up sounding like fluff.

For me, the pain of ochem really depended on the instructor. Where I went to college, it really felt like 90% of the ochem instructors were either bad teachers or liked to watch students struggle. It was otherwise pretty easy material--if you had a good teacher.

From the shear number of horror stories about ochem and my own experience, I'd say most ochem professors are just bad teachers and don't care about their students.

I love to cook. My kitchen cabinets are stuffed with all sorts of kitchen appliances, pots and pans, and utensils. But even when cooking the most elaborate meals for up to 16 guests, I've found that I only use 5 or 6 tools out of my large (and expensive) arsenal.

I've actually moved most of my pots and pans into my outdoor storage. The ones I'll need, I'll go grab and keep inside, but after another 6 months, the rest will be up for sale on ebay--and there'll be a lot of them.

One of the things I'll be excited to see (or develop, if I'm fast enough) would be a social note taking app integrated into the reader, shared among a book club for example.

There are plenty of constraints (slow screen refresh, not ideal user interaction) but who knows, some good new ideas might be born to work around them.

I thought the 'browser not supported' message was odd too. I got that message while signing up using my iPhone, but it seemed to work just fine.

Yes, this will work if you want to keep from sending the password in plain text. But you should make sure you send the request via POST rather than GET and know that you are still vulnerable to replay attacks--an attacker could just sniff out the username and hash, which they could present to you and still authenticate on your site (though they wouldn't know the actual password). Also, as far as md5 hashes go, rainbow table lookups work pretty well, so hashing alone won't provide great password security.

Another way to solve your problem would be post to your auth script via SSL. From what I know of SSL (correct me if I'm wrong, please), the handshake and encrypted connection is established before any data is sent, which will protect you against sending passwords in the clear and against password sniffing.

What you're asking about is a pop filter. They're used in music recording to reduce a singer's mouth sounds (or plosives). It's basically a nylon screen placed between the singer or speaker and the microphone. You've probably seen these music videos before.

Third paragraph from the bottom of the post says they'll be releasing the source in Github this evening (probably pacific time).

I second that on the 37Signals influence. I was actually confused at first and thought I had some how landed on the Highrise site at first--they're remarkably similar.

I've got to point out too that wrapped up in those 10 hours per week were 1000 lines of a little web framework in Ruby.

I read just fine for long periods on my iPhone, especially in apps like Instapaper, Stanza, or the Kindle app. It's hit or miss with web content, however, but is overall a good experience.