dmethvin

Exception models have been analyzed extensively for about 40 years, what you're referring to is the "resumption model". I know PL/I supported it, circa 1980. There are problem domains where it makes sense, think about hardware exceptions for example where you generally can resume.

I don't use Perl much anymore, but I never had a problem with it when I did. Stop complaining and write some code.

Well the back-end payment processing will have to pass the seller some sort of identifier with the purchase, at the very least something like an email address, so that you can have an account for that person. Then the seller will want to assign a license and/or customer number for their own records. If she doesn't know her email address or license, then yes she is screwed. Just like when I try to return things without a receipt.

She can, of course, dispute payments with the credit card processor or whoever paid the seller. Even when a merchant provides clear paths to get refunds on their site, some people just prefer to do a chargeback which costs the seller a lot more than the purchase price.

Yes, it says the requirements are Apache 2, PHP 5.x, and GD lib. I would call those specific server-side technologies.

Just about anyone using PayPal's back-end payment notification has experienced this. The article says PayPal notifies you about a delay but I've seen cases where even that doesn't happen.

If you're selling a service, the best thing to do is to provide a grace period. So to maintain goodwill you just let 'em in and if PayPal doesn't confirm payment within 48 hours you suspend the account until they pay.

Obviously that doesn't work well for non-revocable transactions, but you have to weigh the potential for fraud against the lost sales.

All of these adaptive image solutions are heroic but incredible hacks. They load two images, load no images when JavaScript is disabled, depend on userAgent sniffing, and/or only work with specific backend technologies.

What we need is the ability to tell the client what we have, then let the client choose the right one based on screen size and bandwidth. Browsers should be able to do that for us. Here's one solution along that line:

http://www.alistapart.com/articles/responsive-images-how-the...

We've been spoiled by Moore's Law in technology. In comparison, all the "battery breakthroughs" of the past decade are pretty feeble. If someone could double or triple the energy density of a battery, that would be a breakthrough.

Unfortunately, there's another discipline where energy density is important: explosives. The critical difference is in how quickly the energy is released, and as Li-Ion batteries show it isn't always as controllable as we'd like.

With great power comes great responsibility. Sure, read the source. But don't think that because you followed some internal code path and figured out that it's "safe" to pass `null` to a function that it will always be safe. If the docs for a project don't say it's safe, ask them to clarify.

I think it's just a matter of time before some legitimate cardiology hospital accidentally adopts this as their logo.

As long as security uses a blacklist, it will be possible to evade it pretty easily. There are products that use a whitelist such as bit9.com, but that approach mostly works in corporate networks where they can set policy about what executable files can be run--period.

I understand deadlines, and yes you may not be able to do more than explain to the user that there is a problem out of your control. But don't diss Airbrake because you don't have time to investigate and/or fix. They're not sayin' you have to fix it, they're just sayin'.

Google Analytics works for summary-level error reporting (file, line, error message) but not very well if you want to know the details like a stack trace which can change on each occurrence. That's where the other solutions are much better. GA is certainly better than closing your eyes though.

It sounds like Airbrake was very helpful. It is telling you that users are experiencing errors frequently, something you didn't know before. If, for example, the "google javascript never loaded" situation is common you'd want to either fix that or have your own script work around it -- at the very least, let the user know why the page is broken and that it isn't your fault.

Line 0 script errors can be from dynamically loaded code, such as JSONP requests or `eval()` code.

Every browser has its quirks on errors. At least IE will give you stack info from window.onerror even without a try/catch, although they didn't get the file name right until IE8. The "line 0" errors are often due to eval scripts where there is no source file, it could even be something like a bad JSON string being passed to a JSON.parse shim.

Rather than using $.ajax, I've used a simple image request with URL parameters for sending back error info. That has the benefit of allowing cross-domain transfers. Be sure to save the user-agent info as well so you can correlate errors with browsers.

Everyone makes mistakes, so the fact that Perkins Coie sued the wrong person isn't so bad. But the fact they won't admit their mistake without this person hiring their own lawyer to prove them wrong? Bad. I suppose he can countersue Perkins Coie in small claims court for his legal costs, but what a hassle to deal with their mistake.

Can you be more specific about what is missing?

> "Corporate ethics and compliance may be similar, but their cores are different," says Oshima from his home in Sendai. "From the perspective of corporate social responsibility, we cannot say that there is no need to question a company's actions just because they are not a crime under the law."

If only we could see those actions before they result in disaster. So many of these decisions happen behind closed doors and the public can't see what future risks are being assigned to them. Whether it's apps downloading a user's entire address book in the name of "standard industry practice", pink slime in a hamburger, or a dangerously constructed power plant, we don't get the chance to participate in these decisions. Sunlight would really help.

The point of that blog post is that sites should track the client-side errors that occur. It's hardly a new idea, but is worth repeating since so few people still seem to do it.

Remember folks, for apps that use the back-end as a JSON service, nearly all the code is running on the client. If you have no feedback about errors, you are assuming your 15 minutes of testing with Safari on a Macbook is representative of the entire Internet including that guy with IE7 on XP with the Bing Toolbar. It's not a good bet.

They mention tinyfeedback but there is also DamnIT and the YC-funded proxino.

I think the main takeaway here is that rather than creating a product that needed to elbow its way into an already-crowded market, they solved the problem by creating a new market. Seeing how people really cleaned minor spills and dirt was the inspiration for what is essentially a moist paper towel at the end of a stick.

It sounds like we are agreeing then. If you are using the data for ad-hoc reporting via a SQL query tool for example, you're not just using your database as a simple program data persistence layer.

If you're not careful though, your program-oriented database won't be very useful outside the realm of the program. As an example, I worked on a database where they persisted a good chunk of data in each record as a JSON string. They did it because they didn't want the hassle of updating the database schema. It worked fine for their needs inside the program, but it was kind of hard to do an ad-hoc query on that.

SQL is just like any other language. If you're new to it then sure it's going to look strange. But a large well-designed query can be many times faster than "building up from intermediate results". Your procedural code is off in another process from the SQL server, maybe even in another server across the country. Pulling the intermediate results back and forth between them is expensive.

ORM is great when a database is being used as a simple program data persistence layer, but if you limit yourself to that then you might as well use a NoSQL solution.

It's really hard to say what the performance issue was here, but my experience is that SQL servers do a really good job of handling data sets if you use them correctly. If the problem was a "cache miss" it might mean that one or more tables needs proper indexes for example. Or, if the code involves a cursor and a code loop, that is a very bad sign.

Back in September, Microsoft demoed a similar Windows 8 thing they called "semantic zoom". Obviously it requires the app to understand when zooming is taking place so that it's possible to do something smarter with it than just magnifying the pixels.

Keyboard shortcuts are great--take that with a grain of salt since I like vim too. Unfortunately, the emphasis of Word has always been to make it so a new user can manage to do those things by browsing around the menus and toolbars. It's not a good habit to learn as far as productivity goes, but I'm sure it scores well in usability labs where subjects have no training and an hour to do some simple tasks.

Word's problem is that it has evolved so many features that there is NO reasonable interface to access them. I have been using Word for two decades and still I find myself resorting to features like the Format Painter because I cannot find the settings to fix a run of text.

Don't blame jQuery Mobile for that. It's a result of a bunch of time-based heuristics that sometimes don't work the way you expect. You can always override them (at your peril) by going for the immediate events like touchstart.

I went through this very same left-at-the-altar scenario a decade ago with a startup. It can be very difficult to prove that the company used the NDA information they had in their possession. Clearly the tech staff in the big company saw it, since this seems to be how they made the determination that they could do it in-house for less.

Microsoft stops providing XP security patches in April 2014. Any organization that wants to use XP after that will need to pay Microsoft to maintain support. Any organization that continues to use XP without support is irresponsible.

Where's the nonsense? This doesn't seem to debunk the claim that if the batteries go totally dead you are screwed, out a $40K battery pack.

> Tesla batteries can remain unplugged for weeks (or even months), without reaching zero state of charge.

Maybe I'm trying to find a conspiracy here, but the batteries generally aren't unplugged; they are connected to the car and it's drawing a small current. That drain from the mostly-idle Tesla's electronics are enough to flatten the battery faster than if it was truly unplugged.

I think the reasoning of P3P was that a site would declare what it uses the information for, and if it was found otherwise the liars would be dealt with by conventional legal means. Theoretically that should work well for legitimate companies with a lot to lose, and not so much for malicious sites with nothing to lose that work outside the law anyway. But what do you know, big sites like Google and Facebook have circumvented these P3P rules and will probably not suffer at all, even though they are clearly violating the standard to force their cookies through. But "we need to get our cookies through" is no excuse for circumvention.

About 10 years ago I worked on a site that put together a P3P policy, it was a nightmare. Like many other sites, we needed multiple P3P policies. Your ecommerce site probably has different things it stores compared to your marketing pages, for example, and you certainly don't want your marketing or blog pages saying that you are storing name/address/credit-card and scaring the crap out of people wondering how you are even getting that info off their system.

You can still find the decade-old tools over at p3ptoolbox.org that help you build a P3P policy, God forbid you try to build it by reading the spec. It also seems ironic that p3ptoolbox.org doesn't have a P3P policy and hasn't been updated since 2005.