Both are interesting and deserve a lot of research. Right now I’m more interested in SVG. SVG stands for Scalable . . . → Read More: SVG – The Web’s Display PostScript?]]> With Adobe backing down from Flash by no longer supporting it in mobile browsers, developers are looking for more supported platforms. I’ve been looking into SVG and the HTML Canvas element for a while.

Both are interesting and deserve a lot of research. Right now I’m more interested in SVG. SVG stands for Scalable Vector Format. “Scalable” means that SVG are defined mathematically, not pixel-by-pixel, and therefore maintain their crispness at any resolution. But SVGs go way beyond images. They can be animated and can have user interaction, such as dragging and dropping. In many ways, SVG reminds me of Display PostScript, the display technology used by NeXT computers (or its close cousin, Quartz, used on Mac OS X).

However, since SVG is markup, not binary data or programmatic commands, it can be easily saved and replayed. For the same reason, SVG graphics can be addressed as a DOM tree and manipulated using JavaScript (or other programming languages).

SVG exists natively on all modern browsers, including IE starting with version 9. However, older versions of IE are supported indirectly using libraries such as svgweb.

SVG is a core tool for a lot of advanced applications on the web today, including Google Maps and Google Docs. If it’s good enough for Google Maps, I am interested, to say the least.

SVG seems like a core technology for HTML5 and the next generation of web apps. I’m excited to see how it may turn out!

In a pure web app, the success or failure of what-oriented features can (and should) be determined solely by interaction with the . . . → Read More: Fixed Price Project Economics]]> In every project, there’s a what and a how.  The what consists of the functional features, the things the app or product should do.  The how is the way in which the project is implemented.

In a pure web app, the success or failure of what-oriented features can (and should) be determined solely by interaction with the app in the browser (either manually, through end-to-end integration tests, or both).  You do X, the browser does Y, either the feature meets the requirement or not.  All requirements that cannot be verified by direct interaction with the browser are how features.  This is where the client tells the designer how the app should be built, and this can be simple or it can be a matter of deep, deep micromanagement.

Some how requirements are necessary in any project.  For example, most projects require documentation.  Many projects specify a language, a web platform, a database type.  When a client specifies these things, they are telling you how to build the app, but to some degree it’s reasonable and even necessary.

Other how requirements go deep into the guts of the project.  You must use library X for testing and library Y for database querying.  You must (or must not) write functions that abstract certain repetitive code.  You must use transactions for all changes, always use SELECT FOR UPDATE, roll back manually on any exceptions (even if the library or database would do this for you automatically…)  You must unit-test every possible code path and every positive test must also have a parallel negative test, mocking an exception and testing for an appropriate reaction.

This is really in the guts of the app, and let me say there is nothing wrong with a client who has these rules — provided they state them up front and provided they’re willing to pay for them.  The problem arises in a fixed price contract when all these hows are not spelled out in the contract at the beginning.  When the customer comes along with new hows in the middle of the project, the assumptions that the original fixed price was based on become invalid.  The cost of doing the work goes up.  Not to be too harsh, but it’s a subtle way of stealing from the vendor.

Don’t misunderstand.  This is a huge problem even in hourly projects, although you as a contractor at least get paid for the extra work.  I’ve had hourly projects where, for example, I was asked to produce PDFs, and halfway through the project, the customer gets around to mentioning that the PDFs have to be PDF-X compliant, a pre-press standard for PDF.  I managed to finally deliver on this requirement and I was paid for the hours I worked.  But the customer was not happy because the cost was much higher than they expected.  But in a fixed price project, this is not just an inconvenience, it’s a killer.

This sort of thing is endemic to software development because quite simply, customers never know what they want until they get something and realize that what they got is not it.  This is why short review cycles (and other agile techniques) are good, but there is no magic bullet for this problem.  To paraphrase Erwin Tomash, everything (in software) takes longer, costs more, and is less useful than you had hoped for.

This is why, as developers, we need to understand that customer management, from the earliest negotiation all the way through the project, is probably more important than even the best developers using the most advanced development techniques.  Customer management means, among other things, not selling a fixed-price deal that can’t work; ensuring the customer is completely aware of the consequences of fixed-price; identifying any new hows immediately and quashing them; and in the end, being willing to walk away from any deal if the customer just can’t or just won’t honor their agreement.

That’s why I really hate fixed-price deals.  I don’t like to be mean, but sometimes you really have to be.

The Apple Store people were really sorry about our laptop and were helpful to the extent they could be.  They gave us . . . → Read More: Update on Apple and Pet Vomit]]> Read the previous post for more context, but in short our cat vomited on my wife’s laptop and Apple refused to fix it, even for money, because they deemed it a “biohazard”.  Here’s the update.

The Apple Store people were really sorry about our laptop and were helpful to the extent they could be.  They gave us a $500 voucher on any of their products, which I promptly used to buy their current cinema display, which I recommend to anyone.  (Great monitor!  Only $1000 retail.)

However, they obviously were not able to change Apple’s policies, and when I got a call back from Steve Jobs’ office, the guy was more interested in defending they way they did things than making sure my multi-thousand-dollar investment was protected.  I guess it was polite to call, but almost not worth the time since it was pure excuses and no acknowledgment of a real problem in Apple’s policies — even if not yet fixed.

So…..I went to a local computer lady in Longmont and she repaired the whole thing for $500, less than half Apple’s quoted price.  Just think: we would have paid Apple $1200 to fix that laptop, and because they turned us away, we got $500 from the Apple Store (and thanks again for that), and a $700 price reduction in fixing the laptop.

Am I happy?  You bet.  But am I going to take future hardware problems to Apple Store first, or the lady in Longmont?  Don’t think too hard, this is an easy question.

Sorry, Apple….bad policies have bad consequences.  I doubt I’m the only one who’s ever figured out that the Apple Store may not be the best place to take your broken Apple hardware.

Oh, and one last thing…..get well soon, Steve Jobs.  You aren’t perfect but you are a genius.  If the world loses you, it will be a sad day for everyone, even (occasional) critics like myself.

My wife just took a very fancy and expensive laptop to the Apple . . . → Read More: Apple: Got pets? Don’t buy our products.]]> Check out the letter I just sent to Apple CEO Steve Jobs. Before you do, remember that I actually like Apple a lot and use their products constantly (even though I’ve moved away from the iPhone). But this is just too unbelievable:

My wife just took a very fancy and expensive laptop to the Apple Store in Denver to be repaired. Our cat had vomited on it and it wouldn’t turn on.

Fair enough. That’s our fault. We’re willing to pay to get it fixed. But it was returned to us unrepaired because it’s considered a “biohazard”. Really? It seems too ridiculous to be serious, but that’s what they said.

This isn’t the first time Apple was too good to fix our hardware. We had an item that had a slight nick last year and Apple refused to fix it because, they claimed, it had been “abused.”

I can assure you we take good care of our hardware. People with pets have problems sometimes and we need to be able to turn to our vendor to fix them. This year, I’ve spent northward of $10,000 on Apple hardware. I am pretty committed to Apple. But this kind of awful service shakes my faith and makes Linux look more tempting. I hear they’ve come a long way on UI.

What do you think? Am I just being a whiny baby because you won’t fix (for money) the hardware I’ve paid you thousands of dollars to acquire? Or are the Apple policies unreasonable? It’s one or the other, don’t you think?

This is with reference to Repair No. RXXXXXXXX.

What say you? Am I a whiny baby? Or does Apple need to look hard at their repair policies?

The idea here is that Rails is bad because it uses gems. What, . . . → Read More: Rails Fail? Really?]]> Cruising through the web, I happened across an article on Tante’s Blog, hailing back to the good old days of language trolldom. The article condemns the open-source and distributed alternative to Facebook known as Diaspora. Why? Because it uses Rails.

The idea here is that Rails is bad because it uses gems. What, you ask? What’s wrong with gems? They’re an easy way to install Ruby modules. Well, the problem is that the system’s package manager should handle installation of things like gems, so says the author. It’s not Ruby-specific, but applies equally well to all package management systems introduced by languages.

This is an idea that sounds good on paper, but it ignores several inconvenient realities. First a practical one. Languages start out small and don’t attract the attention of packaging system maintainers until they grow quite large. This is why package systems rarely have the latest and greatest modules, even for big languages like Ruby. Said another way, they are slow to get up to speed.

Second, automatic updating of packages is rarely a benefit. Really, if anything, packages should be installed on a per-project basis, not a per-host basis, because we want the project to keep the same versions of everything until and unless the developer chooses to upgrade elements. This really even goes for the version of the language itself, the database used, etc. Ideally, it would all be integrated into a single package, not installed into the operating system itself. That way, it can be taken as a whole and moved anywhere. It’s self-contained and will not be broken by an OS upgrade. Sure, the developer ought to be able to upgrade (or downgrade) any of the package components in the project, and the system package manager (or the gem or egg system, or what-have-you) can help with that.

Third, every OS has its own package manager with its own rules. Some OSes don’t have a package manager at all to speak of, other than ones you install after installation of the vanilla system. All these package managers work differently, are run by different groups with different rules, use different formats….you get the picture. If there was one master package manager and developers could package up their content once, that system would probably be used. But this is not the case, not even in Linux-land.

Gems and their cousin systems allow developers to package their library one time and distribute it to all operating systems. None of the package managers can make that claim.

The article’s author made the further claim that PHP is a better environment because it doesn’t use gems. I’m sure the author must have been playing the new Halo or something on the side while writing the article, because this doesn’t make sense at all. PHP has its own module or add-on facility, in fact a couple of them. These are no different than gems. To achieve “works anywhere” ease like WordPress, you still have to package your dependencies with your project. In this regard, PHP offers no advantages and Ruby/Rails no disadvantages.

The real issue is package-management support for language libraries and frameworks. It’s a good idea on paper and maybe one day we’ll see it. In the meantime, the people who really care about a language are going to have to roll their own, hence gems and eggs and PEARs. We could hold our breath and wait for package maintainers to unify formats and catch up, but unfortunately we’d be holding our breath for a very long time.

This is good, because as reported on this blog, . . . → Read More: Apple opening up? Or meet the new boss, same as the old boss?]]> Apple recently made some moves that, while not perfect, do challenge the Android platform.  As of 9/9/2010, developers can use any toolchain they wish to create App Store apps, as long as the program doesn’t download code.  And the app approval process became more transparent, with published guidelines.

This is good, because as reported on this blog, previously Apple was losing the game.  Despite a two-year head-start by Apple’s iOS, Android is now selling more handsets.  That should, and apparently did, scare the chiefs at Apple. The transparent guidelines, provided they are indeed complete and transparent as promised, give developers more reassurance that they won’t spend a lot of time and money on an app, only to see it rejected.

Even positive changes can be minor ones, however, and so it is with these changes.  For example, the original toolchain restriction was gratuitous in the first place — Apple at its control-freakish worst.  It’s like an insane person getting back on meds.  A positive step, but far from a complete solution.

And despite these moves, Android is still the platform that is open, open in its source code, open in its carrier selection, open for developers to create any app they wish with or without Google’s approval, even open for app stores that compete with Google’s.  Android is still the platform with multitasking, and still the platform where developers can replace native app functionality (like the default music player, SMS program, or phone calling application).  Android, in short, offers freedom to all parties, whereas iOS is dominated by Apple.

Apple did a good thing, but in my judgment, not enough to change the calculus in the handset wars.  Meet the new boss — the old boss with a nicer tie.

Wasn’t that fast? Steve Jobs introduced the iPhone in January 2007, and Android was open-sourced in October 2008, giving Apple a nearly two-year lead time.  Any time you read in the press about Apple’s success with the iOS platform (iPhones or iPads), remember . . . → Read More: Mac Versus PC Redux]]> A recent Fortune Magazine article indicates that Android phones are outselling the iPhone.

Wasn’t that fast? Steve Jobs introduced the iPhone in January 2007, and Android was open-sourced in October 2008, giving Apple a nearly two-year lead time.  Any time you read in the press about Apple’s success with the iOS platform (iPhones or iPads), remember that with a two-year delay, Android is still outselling the iPhone.

Since October 2008, the Android has advanced far. Today you can do everything you can do with a stock iPhone, and dozens of things that are not possible with the iPhone, at least for anyone except Apple, due to Apple’s constraints on third-party developers and deliberate limitations in their OS (limitations that usually do not apply to Apple itself).

Other bloggers have noted that this phenomenon is exactly what happened with the Mac and the PC in the 80′s and 90′s.  If the same thing happens to the iOS that happened to the Mac OS, the iOS will become a niche product.  The difference here is that in this case, Android is actually better in many ways than the iPhone, whereas Windows 3.x was a very cheap knockoff of Mac OS, with very few countervailing benefits — and it still won the war for market share.

I guess people would like to control their own computing experience, eh, Steve?  They don’t want a big brother like Apple telling them what they can and can’t do.  The “walled garden” model leads to corruption and ultimately a less compelling product.

What should Apple do to regain momentum?  The answer is simple, and it would be the best thing for Apple, but will simultaneously be virtually impossible because Steve Jobs demands control over everything.  This means the main thing standing in the way of Apple’s success is Steve Jobs’ ego.  But here goes:

• Open-source the entire iOS.
• Make the App Store submission process completely transparent.
• Allow installation of apps, and copies of iOS, that were not approved by Apple, on any handset.
• By extension, allow for competing App Stores if people are not happy with Apple’s rules and limits.

This move is perishable, and will not work if market conditions change too much in favor of Android.  Netscape open-sourced its browser barely in time, and eventually Firefox became a huge thing and a threat to IE.  If Opera were to open-source its browser today, it would have limited benefit and probably wouldn’t gain much market traction overall.

Likewise, by the time Android is dominant, it will be too late.  Android is already transparent and open-source.  Apple can benefit by moving this way now because despite everything else, the iPhone is still slicker and more polished.  People may still move to it if Apple quits trying to dominate everything.

If they do not do this — and I am under no illusion that they will — then look for the Mac vs. PC story of the 80′s and 90′s to replay.

Now comes Blackberry 6.  Cool, eh? Packed with innovative features like a touch interface, universal search, an MP3 player, built-in social networking software….

Er, wait . . . → Read More: Blackberry 6 playing catch-up]]> The lead momentum players in the smartphone field today are Android and Apple.  RIM lost its position as the leader when the iPhone came out, and they have been stagnant since then.

Now comes Blackberry 6.  Cool, eh? Packed with innovative features like a touch interface, universal search, an MP3 player, built-in social networking software….

Er, wait a minute. These features have been in phones like Android and the iPhone for years. I didn’t see a single new or interesting thing in the clip, a single reason to switch.

That’s because RIM is trying to play catch-up right now, and rightly so. This is not about attracting new users, it’s about keeping the old ones. But sooner or later RIM will have to do something new and interesting, or they will be irrelevant. Er, wait a minute…. I guess they are pretty much irrelevant right now, at least in terms of market momentum and future direction.

As a former Blackberry user myself, it’s a bit sad. But in fairness, RIM could have been investing in an app store, a great web experience, a touch interface, media playing, and many other things, for many years. Instead they got lazy and let others move the field forward. It’s too bad, but it’s very predictable.