Gumbo. Substance behind the hype?

Just like everyone else, I downloaded the public beta of Gumbo as soon as I found out about it.  But is it better than its predecessor?

My biggest problem with Flex is the components and the framework.  I hate Adobe’s bloated swiss-army-knife software approach.  I waste so much time struggling with Flex components, trying to get those monolithic beasts to behave in the way I want them to.

In the pure-actionScript world, I deal with small and efficient fit-for-purpose components.  If something doesn’t quite do what I want, I inherit it and override or add what I want it to do.  Everything is small and easy to understand.  (No wading through hundreds of methods and properties in the Flex documentation or source code).

Hence developing an application in Pure ActionScript is ultimately faster than Flex.  Flex Builder may initially look easier, with its drag and drop interface – but that’s deceptive.  But Pure ActionScript development is faster in the long run because Flex is a blunt instrument that’s inept at crafting the details.

So this was the issue I expected to be addressed in Gumbo.  I’d heard about the new “Spark” components.  The word “Spark” carried connotations of “lightweight”, and “rapid”.  So I was hopeful that Adobe were moving away from Swiss-army-knife approach, in favour of something that empowers the programmer and their Object Oriented methodology.

But it doesn’t look like Gumbo gave us anything like this.  It will take a while for me to determine whether Gumbo is an improvement for the programmer (apart from the workflow with the graphic designer ).

Opening files in e2spreadsheet

A user has reported that they can’t open their saved work in e2spreadsheet.  There should be no problem opening files from within the application FILE->OPEN…,

but there is a workaround to allow you to open files by clicking on the file icon, or dragging it to the application icon, or on the dock.

Just manually add the extension “.e2s”.  So if your file was called “myspreadsheet” change it to “myspreadsheet.e2s”.

However, the user has reported that even with this workaround – they still can’t open their file.  So I need to know if the problem is widespread.

Is anyone else having this problem?  Please try it out.  Save a file from e2spreadsheet, (close the window), and open it again.  Let me know if it works or not on your computer.

……………………..

File saving in Adobe AIR is a little awkward because the browseForSave() method doesn’t have a typeFilter parameter (whereas all the other browseFor methods do).  So the AIR application programmer can’t specify a default file type.  There IS a workaround – appending the extension after the browse window.  I’ve done this in e2vector – but the workaround isn’t perfect.

Church Of The Flying Meta-Tag Monster

In “Blashphemy! Burn the Flex-hating heretic!”, I likened Flex evangelism to a religious cult.  If I pursue this theological metaphor, then Pure ActionScript developers, like myself, are clearly atheists.  Our choice is not dictated by faith or devotion to Adobe Flex.  Pure ActionScript is IDE agnostic.  It’s a pragmatic individual choice.  It does not blindly follow the congregation.  (Most information on Flex, most blogs and training courses, will focus on MXML.)

It is possible to utilise the Flex-framework and components, via a Pure ActionScript approach.  However, I am presenting Pure ActionScript approach here as an ALTERNATIVE to the Flex components.  Not a complimentary philosophy.

So, let’s compare the use of Pure ActionScript to the Flex/MXML (Flying Meta-Tag monster) approach.

The Ten Commandments of the Church of the Flying Meta-Tag Monster…

1. Thou shalt use meta-tags.

Flex evangelists will tell you that MXML is simply an equivalent way of expressing ActionScript.  (The apples vs. apples argument).  While this is true, and you can always express MXML as ActionScript, it does not work the other way around.

It is possible to automatically convert MXML script to ActionScript script.  So it is also possible to automatically generate ActionScript from a Flex Design View visual representation.  Yet Flex doesn’t include this feature for the benefit of Pure ActionScript developers who want to manipulate, resize and position their components visually.  Why not?

2. Thou shalt find me difficult to learn.

Actually, MXML evangelists often claim the opposite.  “MXML resembles HTML – therefore it is easy to learn.”  But in actuality, this resemblance is superficial, and it certainly does not prepare the novice for the finer points of MXML development.  But the similarity between ActionScript and other programming languages is much more profound.  For a software developer, the transition to Pure ActionScript is relatively painless.  Whereas MXML requires the user to ascend a steep learning curve, irregardless of their transferrable skills.

3. Thou shalt not produce a small file.

The Flex-framework is incredibly bloated!  Flex evangelists will claim that file size is irrelevant.  But at least the smaller, leaner, files produced using Pure ActionScript don’t keep you waiting, staring at a loading bar, while the application loads.

4. Thou shalt not create applications that run efficiently.

Ok, it depends how you write it.  But you have much more control over the computational load with a hand-crafted Pure ActionScript program.

5. Thou shalt not use any other IDE.

A Pure ActionScript application can be developed in Flex, Flash, or third-party IDE.  Or you can switch between IDEs, depending how you feel that day, or the phase of the moon.  This also means that you are free to re-use your code across IDEs, and collaborate on Flex-based projects, Flash based projects, work with other programmers, or graphic designers.

6. Thou shalt not target multiple platforms.

In Flex you decide at the outset whether your project is for the browser or the desktop.  Flex is dogmatically restrictive.  Suppose you have a Browser project, and you open a file that references AIR-runtime objects.  Flex will actually delete the include statements from your source code!

When I develop a Pure ActionScript AIR application, I write it first without AIR-runtime methods.  Then I include those methods within a main class that inherits the main class of the non-AIR program.  This methodology enables me to deploy my applications to either AIR or the browser, and to test most of my application without launching the AIR runtime.

Pure ActionScript produces a smaller file-size and lower computational load.  These are important considerations for adapting an application to a Mobile device.

7. Thou shalt not port thy applications to any other language.

It is easy to port Pure ActionScript code to another programming language.  But it is easier to pass through the eye of a needle than it is to port a Pure ActionScript / MXML hybrid.  Some developers have ported ActionScript programs to the iPhone.

8. Thou shalt be required to read the documentation daily.

This is my penance as a Flex contractor.  Sometimes, I’m required to make Flex components behave as if they were not Flex components.  If I’m very lucky, this can be achieved be overriding a method, or responding to an event.  Each Flex object has hundreds of documented properties, methods and events.  Each documented with a very brief description.  Sometimes, you can hit upon something useful by trial and error, just reading through the list, and trying out things that looks relevant.

The problem with the Flex components is that they are too complicated.  Adobe has tried to make them flexible and configurable, adding so many bells and whistles.  I would have preferred the Flex components to be smaller, simpler, with fewer parameters.  But documented from the point of view of a programmer who might want to override its methods.

9. Thou shalt not change the sacred private methods.

Sometimes, it’s not enough to treat a Flex component as a black box implementation.  Sometimes, you need to familiarise yourself with the code, and override private methods.  Why did Adobe make them private?  Why are they sacred?  Why not just protected?

10. Thou shalt not embark on sophisticated projects.

Flex makes simple things a little simpler.  But, In the author’s opinion, more sophisticated projects, and highly customised interfaces should be approached using Pure Actionscript.  It is easier to write a custom component from scratch than to change and rewrite custom Flex components to do precisely what you want.

As a hard-core Pure ActionScript programmer, it’s often quicker for me to write something that to search for, and understand, a third-party object.  (Why use a DataGrid? – when you can write a couple of nested for loops that set up a grid of TextFields.)

. . . . .

I set out to present a polarised and contentious argument, and to promote discussion.  But, the process of contrasting two approaches started leading me into constructive ideas about how the Flex environment could be improved for the benefit of Pure ActionScript developers.

Automatic generation of ActionScript from a design view and a simpler set of Flex components designed and documented for the programmer who likes to use inheritance and override methods.  If these Flex components were small and simple enough, then perhaps they could be appropriate for mobile devices, and Open Screen deployment.

An introduction to e2spreadsheet

This is my second video.  A quick tour of the features in e2spreadsheet.

This application has been around a long time.  It was originally written for flash 5, it was ported to Macromedia Central and then to AIR.

e2spreadsheet can be downloaded from here.

An introduction to e2vector

As promised, here is a video tour of e2vector’s features.  Occasionally, I’ll also twitter about hints and tips for using my AIR applications.

e2vector can be downloaded from my website.

Advanced Simplicity

I’ve always considered the challenge of designing a sophisticated AIR application was to hide that sophistication from the user.

It’s a challenge to make the complicated appear easy.

Conversely, it’s easy to make something simple appear complicated.  And Flex is a wonderful tool for making things look difficult.  Dazzle your user with DataGrids, List components and Buttons, and glue it together with data-binding and a few lines of ActionScript.  It doesn’t take a lot of effort to build something in Flex that really confounds the user with information, and lacks navigational structure.

If you build yourself a showcase of such poorly designed Flex apps – you can probably pass yourself off as a Flex expert.  Customers will be so baffled that they’re going to assume you must be some kind of genius!

Personally, I’ve taken the path less travelled.  Incredibly sophisticated software projects.  Months of intense development.  Devilishly clever algorithms.  Hundreds of pure-actionscript classes.  All hidden behind a deceptively simple and intuitive interface.

e2preadsheet incorporates an algorithm that enables it to evaluate all the formulas in the right order (data dependencies), but avoid unnecessary re-calculations.  It refreshes the spreadsheet behind the scenes, yet the naive user would be oblivious to its existence.  The automatic scaling on graphs is also something I’m proud of.

e2vector incorporates a very sophisticated algorithm that enables it to splice paths.  Pulling apart overlapping arcs so that they split at the points where they overlap.  It takes a lot of code to achieve something that seems so simple and intuitive to use.  Shape intersection and union are not trivial either.

A potential customer wrote to me recently, saying that he’d seen what was on my website, but was looking for something more sophisticated!  I considered spending ten minutes in Flex to impress him with a DataGrid/ListBox monstrosity.

Instead, I’m preparing some online videos about my applications and their features.  (Coming soon).  Users tend to be too passive when they evaluate internet-related applications.  Like watching TV.  Actually, more like channel-hopping with a small attention span.  That’s a problem with developing software for the browser.  I’m sure that users are only impressed by entertaining Flash-like eye-candy.  All style and no substance.

I thought that AIR might create a new niche.  Running alongside conventional desktop applications would raise the bar. Applications with more substance that would change expectations about what the Flash platform was capable of.  But I’m probably just wasting my time here…

Open Screen Project

Last month, a consortium of companies including Adobe and Nokia announced a ten million dollar Open Screen Project fund.  The Open Screen vision is to “enable consumers to engage with rich internet experiences seamlessly across any device anywhere”.

It’s not mobile phone applications that are important – it is the mobility of the user and their information. Ubiquitous applications and services conveniently allow the user to access their data anywhere.  I’ve never regarded the mobile phone as a replacement for the personal computer – but its a complimentary technology.

It looks like a future version of AIR is going to support mobile device deployment.   A unified portable platform, which is can run on any enabled device -  desktop, TV-top, mobile, handheld, fridge-door, or anywhere else.   Exciting stuff.  I’m as excited as I was five years ago when I first read about this idea in the Macromedia Central white paper.  Good to know we’re nearly there now.

I always thought Flash Platform support of Bluetooth was a cool idea.  But I haven’t heard any rumours that it’s going to happen.  Imagine, for example, the user walks up to their computer/console while accessing their service on a mobile phone. The phone AIR automatically tells the desktop AIR what’s going on – enabling the user to seamlessly move from one client device to another.  There are other scenarios too, such as bluetooth conferencing of (close proximity) mobile phones.  If you give developers a Bluetooth API – I’m sure they’d think of all kinds of uses for it.

Ok, snap back to reality…

I’ve submitted some proposals for Open Screen funding.  If we get the funding, we intend to blog and twitter at each stage of this project – so that other developers can learn from our approach.  So let’s start by sharing our proposals…

The first two proposals involve a desktop AIR application that enables the user to make rich content for a mobile client player application.   e2info is like PowerPoint/KeyNote/Hypercard for mobile phones.  e2teach is an e-learning content management system.

http://www.e2easy.co.cc/e2info.html

http://www.e2easy.co.cc/e2teach.html

My third proposal is the most interesting.  My e2vector application on a mobile phone.  But it’s a sophisticated application – so targeted at future devices that will support ActionScript3.  Possibly AIR++ for mobile.

http://www.e2easy.co.cc/e2vectormobile.html

What do you think of our proposal ideas?  Please leave a comment.

Twitter

Everyone has gone twitter crazy, so it was this blog post by David Deraedt that prompted me to jump on the bandwagon.  I’ve always been a little quiet about my AIR application development.  Afterall, coding is an internal meditation thing – what’s to share?  But I’ll give it a go.

http://twitter.com/e2easy

Come back Josh! All is forgiven.

This is an interesting article (especially for a developer of the quirky persuasion):  “Are quirky developers brilliant or dangerous?“

It is written from the point of view of a manager.  It tells the story of “Josh”. (Not OUR Josh, of operatic Flex fame – another Josh).

Josh is a gifted but anti-social Software Engineer and project champion.   An apparently invaluable and over-utlised resource.

In my opinion, Josh worked for knee-jerk managers who react to one crisis after another, but don’t know how to implement or manage something sustainable.   These managers call the shots. Quality or Fast? – they always want the latter.  So Josh works miracles to do what he can in the time allowed.  But if there are issues over quality – they blame Josh.

A large company is like an organism.  It has an immune system.  If your face doesn’t fit, eventually you’ll trigger a antibody response.  Corporate grey corpuscles.

The comments are worth reading.  There was plenty of agreement that management was at fault here.  Other than that, it’s clear that Software Engineers and Traditional Managers are two different species.  From different planets.  With completely different mindsets.

I found the following comments particularly insightful:-

By Turtle   March 16 2009 12:46 PMPDT

MOST of the time — the issue is not with the developers, it’s with nontechnical or insufficiently-technical management swooping in insisting on trying to “lead” a development team. You. Will. Fail.

By Pete   March 16 2009 1:26 PMPDT

Wow. For an inside-the-box guy (xSTJ), Josh is an evil monster. For an outside-the-box guy (xNTP), Josh was just an introverted intuitive and creative problem solver with a bit of an attitude.

Josh, as described, definitely had some issues. My guess is that 95% of those could have been easily been handled by even a mediocre manager or a decent team-mate. Stick him in an office full of robots with an average IQ of 90 and under a manager completely unprepared and untrained to actually MANAGE, and you can easily turn an INTP into a Josh.

 Josh has some real problems and issues in his workplace, but no one was prepared to try to solve them. So Josh just did what he best to get his mission accomplished.

Eventually the company addressed the issues, and got rid of Josh at the same time. I imagine they’d be MUCH more profitable if they had simply addressed the issues and KEPT Josh. Josh wasn’t the problem, he was just a symptom of how incompetent management was. His “convoluted” code was still brilliant. I am certain it formed the basis for the cleaned up version the “in-the-box” coders eventually produced. Good teams and management know how to get the most out their people.

My personality type is INTP. I have first-hand experience of the situation that Pete describes.

I was once a “Josh”.

I didn’t work in a room full of robots. Their IQs were high. Half of the people in my group had PhDs.  I mostly had a problem with one manager who I had most dealings with.

He considered himself to be a logical and rational person.  But his logic was simplistic. A blunt instrument.   He was equally incapable of grasping technologically complexity, or the nuances of human behaviour.  I withheld information and fed him half-truths in order to protect the project.   The more he tried to control and interfere – the more I became like “Josh”.  A quirky and arrogant prima-donna.

There were basically two types of people where I worked.  Lions lead by donkeys.  Lions – Intelligent and capable project champions, motivated by a passion for what they were doing.  And the donkeys – parasitic politically sycophantic ladder-climbers motivated by self-interested ambition.

When I eventually left the company – it was like being propelled forward on a slingshot.   No longer held back by paper-clip counters.  This phase of my life was more creative than ever before.  I expressed myself through writing, theatre directing, film-making, fine arts and programming.  In the corporate world, I had never been promoted.  Although I was a manager myself, I was never trusted with more team responsibility.  But now, in the real world, I set up my own company, and successfully lead ambitious team projects, with noone to stop me.  And this was the REAL world.  Not just political games inside a large protective corporate arena.

The Doldrums

We all know that demand for RIA and Flex jobs in America and the England have remained high, despite the recession. But that’s little comfort to Flex experts who live elsewhere in the world. (Badu and Marin, for example).

It’s ironic. Within their borders, America and the England are desperate for skilled Flex/ActionScript experts. But all they have to do reach beyond those borders.

I’ve tried applying for jobs in America. Most don’t write back. One sent me a short email, reminding me that I was a British citizen, not an American. The streets of London may be paved with gold – but I’ve no desire to return to England.

I’ve been happy working around Asia. And often busy. I’d lined up two jobs over the next few months.

But suddenly both turned out to be mirages. Now I’ve noticed fewer opportunities. And more local skilled candidates chasing those opportunities than there were previously. The locals are cheaper than I am.

So I’ve been searching the internet for opportunities. In Asia, elsewhere, in industry, and in universities.

Nothing yet.