dmethvin

Let me give you one example that felt like magic. I was taking a trip to New York on business. At 4pm I come off the train at Penn Station and pull out my phone to look up the hotel confirmation I got two weeks before so I can get directions. When I turned it on, a Google Now card was there saying "Carlton Hotel, you're checking in today." I click it and up come directions.

Now, I performed absolutely NO action to make that happen. I just had a confirmation by email that it had picked up. Now maybe that's creepy to some people but it saved me a lot of fiddling around with the phone to find the confirmation and it knew exactly what I wanted, when I wanted it. Isn't that what computers are supposed to do for us?

Actually, I think the article's point was that big feature branches should be merged --no-ff so that they would not be a fast forward commit. That way you can whack them out of master easily if needed. You can still rebase right before the merge -- I would.

That doesn't always fly for a large active project, and for regressions that aren't detected until weeks or perhaps months after they were introduced. I use exactly your technique and it works more than half the time, but for the rest it's really nice to have git bisect.

> I guess where git bisect slows way down for me is that you have to devise code that will indicate definitively that the bug exists.

Normally whoever found the problem should provide you with a test case. Once you fix the problem you'd add that to your unit tests to prevent future regressions.

I'd assume that as well. I have collected several Microsoft IDs by way of Hotmail/live.com/outlook.com but I only have one Facebook account.

* Click on the hyperlink for the line where the message was generated.

* Set a breakpoint.

* Refresh the page.

* View the stack trace(s).

Adding stack traces to the plugin itself would be difficult, since that's not standardized functionality and it would add quite a bit of bulk to the plugin.

Reminds me of that bug back in 2007 when Google translate would take "sarkozy is chirac" and translate it into "Bush is classless" or other completely different text.

http://www.globalnerdy.com/2007/10/23/google-translates-stra...

You've left out things like bundled crapware, impossible-to-remove stickers that advertise Intel on the palm rest, horrible tech support, the need for antivirus, the sleazy way the software autorenews at much higher rates, and retail stores that bully you into protection plans that are a bad value.

I'm puzzled how PC vendors can be so oblivious to the reasons why people are unimpressed by their products. Most of them just ooze mediocrity. Microsoft is powerless to fix the problem because the OEM owns the customer and Windows is just a component.

So your server returns an HTTP 200 with an empty response, and you process the `null` in your success handler? Do you really want a `null` returned? Is this a server you control, or is it some third-party service? Just curious about the use case and how widespread it might be.

> so very very many things changed in backwards incompatible ways

jQuery has always made feature changes/additions on .x releases. We're saving the 2.0 moniker for removing oldIE because that is a much more significant change than these API cleanups.

At this point the jQuery installed base is so big that any change, however innocuous, is a breaking change for someone. Even fixing bugs, conforming to W3C standards, or making API return values consistent can cause trouble because someone depends on the old way of doing things. We try to be respectful of people's existing work but also want to make forward progress.

Like the intro at the top of the upgrade guide page says, this list seems a lot more scary than it really is. We're just trying to call out every change that we think may cause issues, so people can assess and address them in advance.

The jQuery Migrate plugin is designed to make it easier to find any compatibility problems, and can be included with jQuery versions as old as 1.6. Add the plugin to your current code, run it, and view the console to see if there are warnings.

Sure, if you want to build it all yourself in JavaScript, but that's the point of a library isn't it?

And as far as "not targeting old browsers" there are plenty of places where modern browsers differ and jQuery normalizes their behavior. Chrome doesn't support mouseenter, Firefox doesn't support focusin, Safari's String.trim() doesn't trim zero-width spaces, their CSS uses prefixed properties, etc.

Also, talking about jQuery in isolation is like talking about C++ without its runtime library. One of the strengths of jQuery is its ecosystem such as plugins.

Kudos to Jamie and Jacky for proving that the problem isn't HTML5. Does anyone know if the code is available?

On #3 it does seem that Safari for Windows is either dead or very late. As a Windows web developer this means I can't test on the latest Safari anymore. At least with IE it's possible for Mac or Linux users to run IE in a VM.

I'm pretty sure that nobody but web devs actually used Safari/Win, so I understand why Apple want to spend the engineering time porting something that users didn't care about. But how is Apple not shipping Safari on Windows (or Android for that matter) different than Microsoft not supporting IE on Macs or Linux?

Funny, that's just the attitude Steve Jobs had about IBM in the 1980s. He was sure that IBM was the bad guy monopolist that stood in the way of Apple's success. He created the famous "1984" commercial as a result.

You're looking in the wrong place, 30 years late. The 2012 Microsoft is more like 1984 IBM and that's not likely to change. The duopoly of Apple and Google has more ability to dictate our technology today, if that's what you're worried about. At least we have a choice though.

Instead, think of ways to hijack it like the Iranians (supposedly) did. After all, you could sell it to the Chinese or Russians for a LOT of money. Go ahead I dare you.

As a countermeasure, we would have a second-channel kill switch and self-destruct mechanism. If you try to hijack it back to an unfriendly location, we blow it up when you approach it with resulting casualties. If you try to use it as an offensive weapon we use the kill switch and/or self-destruct in an area of our choosing.

To overcome the possibility of an external self destruct signal reaching the drone when you hijack it, you'll probably come up with tricks like bathing it in strong spread-spectrum interference or dropping it into a Faraday cage. Either can be detected and trigger the self destruct internally.

Perhaps you can disable the drone by hitting it with an EMP weapon but still recover it. Good luck.

There are "systems developers" and there are "applications developers". The two groups often use different tools, so JavaScript vs CoffeeScript isn't much more surprising than C vs C++ or Win32/COM vs .NET for that matter.

Systems developers provide services for other developers; generally they want to minimize dependencies. It doesn't make sense to write foundational tools in CoffeeScript unless all the clients of those tools will be written in CoffeeScript as well. Otherwise you're just adding complexity to their projects and making them harder to debug.

Larry has that wrong, IBM wasn't to blame.

IBM licensed DOS from Microsoft. Microsoft bought DOS from Seattle Computer Products QDOS. That software got its command line switches using "/" from CP/M for compatibility reasons; originally, both CP/M and MS-DOS were available for the IBM PC.

CP/M borrowed the convention primarily from RT-11, the OS for the PDP-11, although it wasn't consistently followed there. Programs on RT-11 were responsible for parsing their own command line args, and not all of them used the same convention.

Inside Windows itself, most APIs accept either forward or backward slashes in paths (even both in the same path) without any special incantation. The problem is mainly at the application level where the whole forward/backward slash thing gets messed up because technically you should accept either one from user input and most app code expects one or the other.

Yes, and several C/C++ conventions and types seemed to make that a safe choice, for example wchar_t. Let's face it, collectively we really screwed this one up. It's the biggest mistake since Microsoft chose the backslash as a path separator in DOS 2.0.

Yes and yes.

Chrome's debugger is darned near a full dev environment at this point, it's just not documented all that well and a lot of the best stuff has only been added recently. You can even edit the files, run the edited code, and save the changes locally.

You know what's really good about the Chrome debugger? It's free and it's on every computer that runs Chrome. Visual Studio is neither of those. I really wish they built VS functionality into the IE debugger.

As far as showing variables, one trick I use a lot is to set a conditional breakpoint where the code to execute is `console.log(stuff), false` so that it just logs stuff but doesn't ever stop. That's also handy for "fixing" variable values without stopping.

There aren't a lot of Windows 7 touch devices, and the ones that do exist have proprietary drivers since Win7 doesn't support touch. It doesn't make sense for Microsoft to spend a lot of time back-porting the whole touch system to Win7 and then pleading with OEMs to provide touch drivers there as well. Even assuming they were able to do both of those successfully, you'd be stuck using touch with Win7 desktop apps unless they back-ported Metro to Win7 as well.

Doesn't make a lot of sense once you write it all out.

window.screen.availHeight and window.screen.availWidth look like the best bet.

If you want to support this on IE 6/7, just add a shim that uses userData behaviors for localStorage. Here's one: https://github.com/mattpowell/localstorageshim

Although the title talks about detecting the iPad Mini, the article makes it clear that the real dilemma is that there is no way to know the physical size of pixels as presented on the screen and size things accordingly. That's especially important on touch devices where you want to size controls to make them finger friendly.

Openness about the problem is good, but I am not sure that it helps to provide that much detail about the ways you detected the fraud. That just give the attacker more information about how to circumvent your detection.

> But what if you want to share a story? In Desktop, I’d right-click, copy the URL, and send it over. Metro News doesn’t have URLs. So I go to the right side of the screen and choose “Share.” I have two real options — I can send an email, share via Facebook, or share via Twitter. If I send an email, it generates a link that only people with Windows 8 can read.

This seems like a general problem with trying to share non-web content inside apps, regardless of the platform. If you're just putting an app wrapper around web content, like the Wikipedia app, you can provide a URL. But if your app does more than that you can't give them a web URL if there is no web implementation.

It all comes down to consent. I should be able to install a browser plugin that blocks ads entirely, or a plugin that replaces their ads with ones more relevant to me.

This is not a new technique, there have been adware/spyware apps for nearly a decade that do similar things. The ones that do it openly as a "legitimate business" claim the user consented, like Gator/Claria and Direct Revenue did. The netherworld ones dispense with that fantasy and just install.

Often the advertisers have no idea their ads are being served up through these shady networks. For example, in 2005 Gator was showing ads from the Yahoo network as part of the Overture keyword search. As an Overture advertiser you couldn't control whether ads appeared there.

Sorry but I just can't follow the logic here.

The Flash whitelist is only for the formerly-called-Metro immersive browser that will primarily be used on touch-based tablets. It does not affect desktop IE10.

Many Flash apps were designed for big screens and mouse interaction where pointer precision is great. Now you're throwing them onto a screen that's smaller and using a fat finger to emulate a pointer when the Flash app's target areas weren't designed for that.

Now certainly, some Flash apps will work. Other apps will not because they just weren't built with this environment in mind. If the user ends up running one of the apps that fail, they will have a bad experience. It happens all the time with the iPad where Flash doesn't work at all.

To improve the experience, you could make a whitelist of apps that work, or a blacklist of apps that fail. Which implementation you might choose would depend on whether you expect more good or bad apps, the complexity of managing the list, the impact of failure on the user, etc.

Is this really so controversial?

I co-founded a company a decade ago that spent most of its marketing budget on AdWords, on the order of $120K a month. We were constantly running into issues with the credit card company triggering their fraud algos and killing our campaigns, despite having these charges regularly coming from the same company (Google).

At some point if you're Google you get tired of letting the banks skim 3 percent ($3.6K a month!) off the top of these high-volume transactions and prevent your customers from spending. Google knew we were certainly good for the money by the time we'd been doing it for a few months. This kind of cash squeeze is why all sorts of companies get into financing, like GMAC for auto financing and Dell for computer financing.

In that case I think "little or no certification" would be more appropriate. It does seem kind of strange that doctors, lawyers, electricians, plumbers, and barbers all have to take tests to get into (and sometimes remain in) their professions, but a programmer can write the software for a missle system, voting machine, or power plant with no certification whatsoever.

I'm one of those guys programming in my 50s. Technically my jobs involve project management and consulting as well but I still love programming the most.

Saying that programming "requires little or no education" is from the perspective of either a naturally smart person or the Dunning–Kruger effect. Like any profession, there are some self-motivated people who can do the job effectively without formal education. Yet it saves time to have everyone on the same page with knowledge of basic algorithms, terminology, and problem-solving methods.

If money is your motivator for programming in your 20s, the odds are that you will find some other way to make more money and not last until you're 50. At least I hope so.