[kibwen]

  > We’re working on a protocol adapter that will allow 
  > clients using the Firefox Remote Debugging Protocol – 
  > including the Developer Tools and WebIDE – talk to all 
  > mobile browsers, regardless of rendering engine or 
  > runtime. Our first targets are Chrome for Android and 
  > Safari on iOS.

My company expects all of our internal web applications to function on the executives' iPads, but they refuse to purchase Macs on which to debug issues that manifest only on mobile Safari. And since the mobile Safari developer console was disabled in iOS 6, I haven't come up with anything better than alert-based debugging techniques (Firebug Lite was broken the last time that I tried, though admittedly that was a while ago). If Mozilla truly reverse-engineers Apple's remote debugging protocol it would be a godsend for us.

(And if I'm just an idiot who's overlooking some simple way of debugging mobile Safari, please let me know.)

[paulirish]

> If Mozilla truly reverse-engineers Apple's remote debugging protocol it would be a godsend for us.

Google did this a while ago: https://github.com/google/ios-webkit-debug-proxy It works well for connecting Chrome DevTools to Safari, automating Mobile Safari through ChromeDriver, or hooking up your iOS device to a private instance of WebPageTest.

[kibwen]

Thanks, I've never heard of this before and it sounds very useful.

...Or rather, it would be very useful were it not for the fact that it only appears to run on Linux and OS X, whereas my employer-granted computer is running—drumroll, please—Windows XP! And like I said, these are all internal applications, and I don't have the authority to VPN in on any computer that I please.

Ah well. Enterprise bureaucracy strikes again. :\

[robin_reala]

Have you ever thought about quitting and working for a company that doesn’t treat you like a child?

[kibwen]

What, and not get paid to spend half my time on HN while the ravages of Sarbanes-Oxley grind productivity to a halt?

(The funniest thing is that we're not even a public company, and have no shareholders to defraud. That's right, we opt in to Sox-compliance.)

[mercer]

That's interesting. Can you tell us why your company opted in?

[daxelrod]

I've seen companies adopt stricter compliance rules than required by law when their customers demand it. I have no particular knowledge of this specific case.

[magicalist]

That sucks, though it would definitely be much easier to run a virtual linux instance on that box than an OS X one as someone else suggested.

I will say that being able to debug pages in mobile safari directly (via Safari on a mac) makes a huge difference, so if this works even partially as well, it's worth investigating if you can get it running.

[23andwalnut]

There is is a windows version too: https://github.com/artygus/ios-webkit-debug-proxy-win32

[Raphael]

Linux virtual machine.

[campd]

And that work is key to the stuff we're doing. Thanks again, Chrome folks!

[Sephr]

Mozilla didn't have to reverse engineer anything. Firefox, Chrome, and Safari all aim to support http://remotedebug.org/

[paulirish]

Not accurate right now. Firefox and Chrome spoke about this at EdgeConf this year, along with the remotedebug founder, and basically said "Please go forth and develop a shim layer common protocol in the community. However, all browser vendors standardizing to a common protocol would slow us down too much." Video: https://www.youtube.com/watch?v=tQG6PljqmLc#t=1013 (around this timecode)

[canuckistani]

Hear, hear. None of this needs to be a standard to show a web page so I'm personally happy to let developers hack on what lets them be more productive, and let browsers continue to innovate. It's way too early to get a committee process involved, and innovation will happen faster this way.

[jkrems]

Actually this article points to the reverse happening - they build bridges to be able to connect to each others protocol to work around having to use a common protocol.

[chousuke]

So instead of a one-time cost, they'd rather bleed money due to lowered productivity? I don't know how much time you spend developing internal tools, but I'd expect the cost in lost time to surpass the cost of a few (possibly shared) development machines rather quickly.

[smacktoward]

Never underestimate the ability of managers to be penny wise and pound foolish.

[blueicelt2004]

...or the inability of developers to properly demonstrate to their managers why something is needed. simply saying it makes it easier is not enough, learn to sell and spin in a way that does not make you seem lazy and you will be surprised what you can convince people to do.

[malandrew]

Which is why I'm increasingly bullish on the idea that the best managers in the future are going to be engineers that learned management skills.

Historically, software engineers have been the minority of the worker bees in a company. As companies trend towards more and more technical folk at the bottom of the work pyramid (not just software engineers, but anyone doing highly technical work that increasingly incorporates ways of working that have been the status quo among developers), managers are going to need to be able to understand the technical side more and more.

We'll eventually reach the point where it will no longer be enough for a developer to spend inordinate amounts of time convincing the manager what the right thing is. That works for the low hanging fruit that most developers can argue for. Once most if not all of the low hanging fruit has been picked, not picking the higher hanging fruit will be as much the fault of the manager as the engineers that need to convince the manager of their importance.

There will come a time where technically competent managers become a requirement, not just a luxury.

[marcosdumay]

That's true. But managing a company is still the managers task, not developers. It doe not excuse them.

[27182818284]

The sad answer is that your co' is what is incorrect. If you have "executives" plural you have the budget in your organization to buy a dev mac and a dev device.

[kibwen]

I agree that they're being foolish (though hey, they're the ones paying me to waste my time), but I'm just as peeved at Apple for removing a perfectly-workable self-contained solution in favor of yet more platform lock-in.

[JohnTHaller]

> but I'm just as peeved at Apple for removing a perfectly-workable self-contained solution in favor of yet more platform lock-in.

Peeved, but not surprised, given their track record.

[stebemops]

Here's a crazy idea: what if we stop buying apple products until they stop pulling this walled garden crap and we are free to use the overpriced hardware we paid for as we damn please?

[chris_mahan]

I have never bought an Apple product. Not even a iTunes file.

Apple is still doing well, though.

[smrtinsert]

That sounds like lunacy. How is the world supposed to buy overpriced brush metal technology?

[bergerjac]

most customers don't realize the garden is walled.

[gress]

Most customers have a better experience because it is walled. Those who care, should indeed not buy Apple products.

[colinramsay]

I've never tried it, but how about this?

http://developer.telerik.com/featured/a-concise-guide-to-rem...

Or, run OSX in a Windows virtual machine? You could us Safari remote debugging then.

[sliverstorm]

Are OSX virtual machines allowed now?

I mean, obviously you can do it at home, but a company has to be a little more careful.

[jryans]

Yes, Apple's license allows it now.

[masklinn]

Only on top of Apple hardware.