Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2018

NYT: iOS Maps another internet services blunder for Apple:

The Times claims "numerous interviews" with former Apple employees "made it clear that Mr. Jobs and other executives rarely paid as much attention to Internet services as they did to the devices for which Apple is best known."
...
“I always felt if you had to name an Achilles’ heel at Apple, it’s Internet services,” said former Apple product designer Andrew Borovsky, who previously worked on MobileMe. “It’s clearly an issue.”
...
Tantamount to the arguable lack of foresight was the iPhone maker's secrecy, which wouldn't allow services like MobileMe to be thoroughly vetted before launch.

I've been hinting a while here that software development really isn't Apple's strength. Look at the iMovie debacle for a good, end-user specific example. The newest iMovie isn't half as useful as its pre-rewrite predecessor, starting with the simple fact that Apple killed plugins. The Java VM went all over the place, adding Mac-specific stuff, then pulling it away, changing available look and feels, etc, without warning. The Final Cut Pro rewrite had a similar, but much more vocal, backlash too, enough that Apple refunded purchases and rereleased the old version, iirc.

You can get away with this stuff when it's USB-only and you've killed serial ports on the iMac -- and nobody's really using your hardware anyhow except those predisposed to cope with changes like this. I guess that doesn't work so well with iPhones.

Aside: How many people use iPhones? It didn't really hit me until the recent report that Apple is tracking 800,000 workers in China. Wow. They apparently added 300k since January of this year. That's a lot of iPhones being made in China. A lot. I realize without the savings almost inherent to the use of a Chinese factory, that many jobs don't exist, but can you imagine if they could move all of those jobs to the US? They could bring a third NFL franchise to the Bay area beside the campus in Cupertino.

The biggest find from the NYT is that Apple doesn't understand testing. That's not a surprise, honestly, but it explains a lot. You'd've thought the Final Cut Pro issue would have been obvious if they had a good sized group of professionals doing beta testing. Apple is a hardware company. I keep seeing folks on the forums at rumor sites contesting that claim. They shouldn't. Apple makes software to sell their focus: hardware. The end.

Of course, in retrospect, we now know Apple obviously did Maps wrong.

Wild idea: They would have done better to hire/buy/whatever some great GIS iOS developers to rewrite the Google app first. They could and should even have used Google data for the app. I'm not sure how you make cash doing that, but instead of offering to disgruntled users what's already on the App Store a few weeks after the iPhone 5 comes out, know you've got a great back-up waiting on them. Heck, even push the code that reads directions from your Maps dev to these guys in a garage replacing the Google powered app.

The selection screen, which turns out to be a selection website, viewed on my Mac today

It's as if Microsoft decided, when cornered by the EU, to do away with Internet Explorer by replacing it with a horribly hastily written, completely new browser. Instead, Apple needs to do what the EU required Microsoft to do (though for very different reasons): Preload the platform with map choices rather than a definitive app. Slowly grow a subset of folks' comfort level with yours, have those that chose to use Maps Beta laugh at the foibles rather than rant, and remove the Google app a year later when your license runs out (or, in the hypothetical above, release the "Apple-funded garage GIS development app" as part of iOS 6 too). The neat part: You weren't charged with anti-competitive practices, so you can remove the choice screen when you're ready.

Anyhow, hindsight is 20/20, but anyone who has actually used Apple software for years isn't particularly surprised. Heck, very few companies get it right every time, and most of those don't range as widely as Microsoft, Google (hello, new Blogger interface; I'm looking at you), or Apple. You know, shoot, Evernote can't even get Skitch 2.0 right.

Labels: apple, development

PnlCustom = Ext.extend(Ext.Panel, { title: "Title", html: "spam", initComponent : function(){ PnlCustom.superclass.initComponent.call(this); if (null == this.someVal) { this.someVal = "NOTHING"; } console.log("#" + this.someVal + "#"); } }); Ext.onReady(function() { var pnlCustom = new PnlCustom({ someVal: "3" }); var pnlCustom2 = new PnlCustom({}); var pnlPlain = new Ext.Panel({ title: "TITLE", items: [ pnlCustom, pnlCustom2 ], renderTo: "uiHook" }); //Ext.Msg.alert("test","test"); // compulsory test that Ext is set up correctly. });

So my relative dislike of any mergetool that I've tried (list below) has me slowly coding my way to one of my own. I think it's a doable task, now that I've nearly got the [exceptionally simplistic] diff engine close to done. A good mergetool seems to be mostly about the UI, honestly. Can I tell what I'm doing, what's in the current file I'm about to check back in, and the source of each of those edits? Can I tell that I've handled each conflict?

I've got a number of ideas of what's really needed -- saves of past unconflict sessions, quick summations of how much of each file (local, remote, base) you've put into the unconflicted file, the ability to look at the file's history beyond local/remote/base into other branches and farther back in history, etc -- and that's largely GUI driven. I might need a middleware tier for interfacing with git, but that's about it for the faceless code.

The UI, on the other hand, is going to be a bear.

Anyhow, doing this in Mono so that it's crossplatform is both exceptionally cool and horribly painful. Cool in that the faceless C# code really does work great no matter where I run it. Cool in that my code, all written in MonoDevelop on OS X, "just runs" when I opened it in Visual Studio 2010 for fun today. I'm inserting a screenshot, just because it's crazy cool how easily the Mac developed code opens in Microsoft-land.

(Note that it's obviously not close to done yet; still just playing with the diff engine and learning how to do everything in Windows.Forms programmatically -- no RAD designers in MonoDevelop for Windows.Forms. Gtk#, sure. Windows.Forms, no.)

The pain I've documented largely already. You'll notice no highlighting in that screenshot; just colored text. That's b/c highlighting doesn't work on Mono's Windows.Forms for Mac. Nor do ToolStrips. Nor does every menu accelerator. It's a mess.

Just for fun, I'll include a Mac screenshot here... I don't have it handy, so I'll include the one from sourceforge for now. For some bizarre reason, their system added a horrible black border around the image to make it look like it's on an old TV. Go figure.

Which means I'll eventually need to use MonoMac -- a bridge between Mono code and native UIs designed in XCode -- to finish up a quality unconflict for OS X. And since it appears so much of a good mergetool is UI, that means a lot of repeated logic.

Oh well. For now, I'll just use the ugly lowest common denominator of Windows.Forms on OS X, then fork like mad when I get to a good stopping point.

Final thought for now: Writing the diff engine is actually pretty neat. Makes you appreciate what mergetools and diff functions are really doing. You'll notice the "-1" out in front of some lines. That means those lines "didn't change", relatively speaking. That's the wrong way to do a diff. Initially I had way too much of a file-centric approach to diffs, and not diff-centric enough. Working on that. And to do it right, you have to make at least two passes through the code to work out when what's moved has changed order or not.

mergetools I've tried and not really liked:

WinMerge: No three-way merge. Leaves crappy files to clean up. Not updated in a long time, and the rewrite seems dead.
p4merge: Great ideas, poor implementation. Love the icons, but I can't always see them. Also hard, with current highlight scheme, to see what I've inserted and what's an option for inserting. No hard confirm on saves.
FileMerge: Two-way merge, poorly done, at least when SourceTree calls it. Works fine (aka, "reliable"), I guess, but featureless.
vimdiff: Good, but though I love VIm in general, I'm newbie enough to merging files to want to to use a mouse and have more helpful UI cues than just highlighted colors over what amount to tiled xwindows.
kdiff3: For some reason, I can't get this to integrate correctly. Using something as a mergetool should be easy. Few are. I don't think this is always saving when and where I think it's saving (same deal with WinMerge and p4merge at times), and often (likely b/c of a flaw in my script, I guess) isn't opening when it's called from cmd line or the git GUI I'm using. Also a little bit of a stodgy interface.

Labels: git, mono, monomac, unconflict

[merge]
keepBackup = false
tool = custom
[mergetool "custom"]
cmd = /Applications/p4merge.app/Contents/Resources/launchp4merge
"$PWD/$BASE" "$PWD/$REMOTE" "$PWD/$LOCAL" "$PWD/$MERGED"
keepTemporaries = false
trustExitCode = false
keepBackup = false