Google AppScripts: Power, Beauty, and, well, actually, a lot of work still needed

I was lucky enough to be part of Google's AppScript hackathon in Chicago.  I enjoyed meeting several people in the hacking community, and learned a bit about what AppScript is all about.  Short story: JavaScript in the cloud, connecting calendar, email, spreadsheet, powerpoint, docs, forms, databases, and everything else together, relatively seamlessly.  Think of it as VBA for the cloud

Long story: We had several tutorials, got a basic idea of how to build class files with scripts in them, how to set some properties, trigger changes, send emails, and a few other odds and ends.  My initial attempt was to scrape Craigslist based on a search query, and post all results into a new spreadsheet page (sortable) based on the results and an xml template (I missed that api).  If I have time, I'll actually build it.

Honestly, debugging was horribly slow, writing the scripts wasn't easy, and the bouncing back and forth between pages to reload was relatively unfriendly.  If there was a way to test this on the command line, or even better, have a plugin to a real environment that could save the code locally and back up instantly (or when optimized), then I'd be a fan.

This can be a really powerful step forward for business analysts, interns, and other folks who don't know a lot about programming, and want to just connect apps together with simple functionalities.  Honestly, one of the cooler ideas I saw was someone using Flex mobile to write the app, storing the js code in StageWebView, and then running their form that way...I left before I had a chance to see it in action, but it sounded quite promising.

For anyone interested in trying this out, the website developers.google.com/apps-script has good documentation, but some of it is quite buried (or relies too heavily on GWT UI toolkit documentation).  That documentation could use some examples embedded with the code, but that's just my opinion of the docs.  Otherwise, there are plenty of scripts to help you get started with writing off a few quick innovative app ideas.  Hopefully you have time to work on something and show the world.  But for right now, it has some maturation to be more robust for full development.

Why everyone should avoid Adobe Connect

Aside from the fact that it sucks, support is by a bunch of people who, shall we say, aren't speaking clear American English, and do not actually understand the technical bits behind the system, including the SyncSwfEvent.  Anyways, after hours, days, and weeks, of screaming, yelling, and cursing, I can tell you that I will never recommend to any client to go forward with this product.  Its documentation is horrendous, and as I said, the support is even worse.  sorry for the rant, just angry at it...

Polyglotting it

This is more of a ramble than a post on learning to do something...

Holy cow this railscast guy moves fast.  However I do find his tutorials quite interesting.  I moved through about 7-8 of these last night (http://railscasts.com/) and found some good gems in there (pun intended).

I spent a lot of time last year learning Rails 2.x, and Ruby 1.9.x.  Not that I'm becoming a professional rails dev (yet), I'm getting into it, especially because I want to be able to create my own servers and connect to my data source while avoiding Java and php (Scala not included cause I still like it).

I've spent a good amount of time with Rails, and while it is still maturing, using TextMate is awesome for debugging, git is hella better than SVN, and I become less dependent upon other systems/companies if I can roll my own.

Expect to hear more from my blog on other things I discover about the languages (Scala, Python, Ruby) I've been going through over the last 2 years, and their associated frameworks (Play, Django, Rails), as well as my foray into noSQL databases (Mongo).  Lots to learn, and lots to understand, but when things work, then I'm happier and more excited to build.

Cheers!

Apache Flex Logo [sexy]!

Check out this awesome new logo:Now there is a lot to be done in Apache, and hopefully I'll be able to help contribute to the future of Flex. In the meantime, congrats to the team at Fuse Collective and Tomasz Maciąg who created this piece of beauty!

I know there is some very positive energy around Apache Flex, and a bit of an uphill battle for the future of Flex, but let's keep the momentum going!

Javascript error in Flex: Why my html won't load my swf...oy!

Boy, I hate Javascript...actually I don't hate it, but I hate the errors it can throw.  Anyways, in this issue I explain why a spurious error actually was correct.  I haven't done much Flex 3 in a while, but a current client project asked me to stay within these bounds.  I checked out the code from CVS (ugh) and got everything up.  But when I tried to run the project, I never launched the swf in the html.  Finally I found the error.

Using FireBug, I found that the DetectFlashVer() wasn't firing.  Huh?

I checked the files, made sure I hadn't changed any configuation, double checked with the team that I all the code.  Everything was there, as they had it.

Only upon further investigation did I realize that I was missing the AC_OET.js and /history from my template.  This seemed strange in the beginning, but the client insisted everything was running fine for them.  I had to assume it was my configuration, trying to run Flex 3.5 from Flashbuilder 4.6, I must've been doing something wrong.

My only guess is that because AC_OET.js didn't exist a long time ago (I actually don't know when it was introduced to the SDK), when I tried to build the package, because it wasn't in the html-template folder, it wasn't going to just show up, and because the html template was probably based on the newer SDK, it was looking for the javascript, and because it couldn't find that, never loaded...

Case solved.

Old html:
if(DV(6,0,65)&&!hV){document.title=document.title.slice(0,47)....

New html:

var hasProductInstall = DetectFlashVer(6, 0, 65);

This made a big difference.  Hope this helps you.

Flex a Spoon, Flash some AIR, and stick around for a while

Hoyt’s last Chicago Flex preso and Labriola’s SpoonProject

Kevin Hoyt and Michael Labriola both were the guest speakers at our CFUG meetup (www.chicagoflex.org).  The great news is that this was the first time either of them had spoken together in the same room at the same time.  The sad news is, this will be the last time both of them will be together at CFUG to ever talk about Flex again.

If you are interested in watching the near 2-hour discussion, please go here: https://experts.adobeconnect.com/_a204547676/p7xqmnpakcd/?launcher=false&fcsContent=true&pbMode=normal

Otherwise:

First off, I want to discuss a few things that I feel will help clarify where I am coming from.  Often times I have discussions with multiple clients about what Flash is, how Flex fits in, and we can accomplish with AIR.  For this post (which is long – way too long perhaps, but long enough to see the point), I am going to just quickly reference and review, then I will discuss: Adobe’s PR (the reason for this meetup and me asking Michael and Kevin to come and talk); Adobe’s strengths, position, and vision for the future; The Spoon Project; Spoons opportunities and dilemmas; and my own 2 cents.

What is Flash?

Plain-speak: A plugin.  Want more information, check here: http://en.wikipedia.org/wiki/Flashplayer.  It is Adobe’s bread and butter when it comes to content management regarding video and video games.  More on that later.  For now, know that it is a highly evolved virtual machine (VM) that can execute code (AS3) for a rich and interactive experience.

What is Flex?

Plain-speak: A framework built on top of Actionscript 3.  It is a powerful tool for building applications, especially enterprise apps.  It has a terrific life cycle, amazing APIs, and is several years ahead of any other technology for delivering secure, robust, and data-driven applications

What is AIR?

Plain-speak: A desktop version of the web browser version of the flashplayer.  It has some much cooler APIs than the standard flashplayer, and because it isn’t sandboxed by the browser, you get a few other neat things.  Still, it’s mainly a desktop version of the browser version.

So?

Adobe’s PR (fubarred, snafu, or intended)

Adobe is great at one thing, making tools for creative people to create things.  In my experience as a developer, consultant, analyst, and everything else, I’ve learned that when it comes to businesses and software development, you get one of two things: an agency approach, or an enterprise approach.

As a quick definition, and agency approach is the short term.  These are products that don’t have much shelf life, are short lived in the wild, and even if they win an award will fade into obscurity soon.  The enterprise approach is the opposite.  While enterprise apps are notoriously slow to come to fruition, they last (what seems) forever.  Normally they are a 5-10 year package that sells for a large amount, and comes with upgrades, new features, and snazzy options as the life of the product wears on.

In the world of Adobe, Adobe has no clue how to deal with the enterprise.  They can only see one thing, and that is the bleeding edge.  As a four-plus billion dollar ($4,000,000,000+) a year company, Adobe makes most of it’s money on creative tools.  This means Creative Suite, Photoshop, and a few other choice applications is where Adobe makes its money.  It does it by selling tools, or packages of tools, to companies and users.  Since the inception of Flex, Adobe has never really figured out how to make money off of it.  Flex uses the flashplayer and AIR, but AIR and the flashplayer don’t need Flex.  In fact, one of the biggest complaints of Flex is the bloat it brings with its myriad libraries, download times can be severely impacted. Not to mention the speed of an application because it is using the Flex messaging framework.  These have been, and will be, hotly contested for some time to come. 

Regardless, Adobe never made (“real”) money by creating the framework.  It did make some money by consulting on projects, but the 25+ team members it has allocated to the sdk never generated revenue (unlike the large group of folks who work on Photoshop or AfterEffects, whose products do make money).  Flashbuilder does generate some revenue, but not at the same volume as the other products.  Adobe looks to start projects that can generate at least a hundred million dollars ($100,000,000) a year, and Flex never even came close.  Sure it might be a multi-million dollar venture, but is that worth the resources when those resources could be dedicated to a larger project and make more money somewhere else?  Adobe says, “Nope.”

So Adobe made the bold move and told the world it is no longer interested in developing Flash for mobile (completely unrelated to Flex), and making Flex completely open source, giving it, and its support to the Apache Foundation (http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html).  Make no mistake about it, Adobe will support the flash player, especially for the desktop, and it WILL support AIR.  AIR makes the flashplayer available everywhere that isn’t a browser, so video content and games have a way to live on.  And Adobe keeps its cash cow.

And don’t worry, Flex isn’t going anywhere too quickly, but we’ll get there in a bit.

The message from Adobe is messy, sloppy, poorly handled, but think of it like teenage angst, where the person has lost control of their emotions, and finally just said, “Enough! Enough! We can’t have it our way, we don’t want it any way!”  Adobe has not been able to capitalize on innovations that are not tools “creative” people need. 

Adobe’s position (including Natobi/PhoneGap)

So what does Adobe want to do going forward?  For starters, they have their Interactive Developer Evangelist team spearheading a PR campaign to tell all developers that HTML is the future.  Their message has become pretty consistent, with their twitter feeds basically dropping any mention of Flex.  They seem to ignore everything Flex, and stick with the standards of the future.  Let’s not get caught u p in rhetoric. Adobe is not interested in maintaining Flex any longer than it has to.  Flex is a dead weight to the hipster, creative, entrepreneurial type.  And Adobe cannot wait to release itself from that death grip.  To prove that it is over Flex, it bought Natobi, Typekit (http://blog.typekit.com/2011/10/03/adobe-acquires-typekit/), Efficient Frontier (), and a few other online real estate properties, pointing towards a desire to enter and again dominate the tool making process for online advertising (because the flashplayer hasn’t been there for the last decade).  From the 8/18/11 anouncement, Adobe is building up to be the leader of “…Content Authoring and Digital Marketing.” 

Enterprise applications are not either of those.

Adobe bought Natobi because Natobi created PhoneGap.  PhoneGap is a software application that essentially turns any application you create into an HTML5/JS/CSS application, wraps it in a pseudo-browser, and deploys like a native app.  So, for example, on iOS this is a standalone instance of Safari running on your device, and it appears to be a standalone, native app, but you are only seeing Safari rendering web pages that are considered the app.  The library works quite well, and for all intents and purposes, it acts just as good as a native application.  Adobe supports it and suggests you use it as well.  For them, this is the bleeding edge of technology, pushing mobile application development.

There is no Spoon?

During the 2011 Flex|360 conference in Denver, it was announced that the Spoon Project was taking off.  If you don’t know what Spoon is, read here: http://www.spoon.as/

Short take – it’s meant to help the Flex development team fix bugs faster.  It’s got an architecture of people and processes to resolve conflicts and promote fixes faster than Adobe’s Jira and engineers could handle. Spoon has PR, it has volunteers, it has a lot!

Spoon’s dilemma

It might actually conflict with the Apache Software Foundation (ASF).  This is not detailed out yet, and Spoon, Adobe, and ASF have some work to do to hammer out the details.  There are a lot of license agreements, IP rights, and whatever else a lawyer wants to earn fees to help disentangle Adobe from the Flex framework.  Spoon might be a problem only because it is a separate entity ready to run and fix problems, and Adobe is saying, “Actually, let’s let the big boys handle this.  We’re gonna give it to ASF, and see that they take good care.”  Nothing is set in stone yet, and Spoon may or may not be involved.  That is to be determined.

Future

If there’s anything that is certain right now, the Flash player and AIR are going to continuously be improved upon, upgraded, and pushed out to be as ubiquitous, easy to use, easy to get, and easy to update.  Adobe has a lot at stake to make sure these tools remain potent sources of DRM content providers, and will keep them up to date.  But Adobe also wants users to buy their products if they are making cutting edge products.  The amazing thing about HTML advertising is that you can’t disable it without disabling your browser.  With Flash, there were plugin disablers galore that allow users the ability to block any flash-related medium trying to load on your computer.  However, now with the advent of video and canvas in HTML5, unless you disable javascript on your browser, you can’t stop the ads from coming.  It is a marketers wet dream to know that’s where we’re going.  And guess what, Adobe is looking to blaze the trail by providing you with the latest and greatest tools to make them.  Adobe is not promising Apps, they are promising rich web pages, rich ads, rich user experiences.  It is cutting edge, but not anything with a long tail.  Flex is a long-tailed beast.

And just for a quick summation, here's Peter Elst's post about the exact same subject:

http://www.peterelst.com/blog/2011/12/13/flex-summit-updates-on-the-open-source-strategy-and-runtimes/

The Flex Summit has had some interesting notes and should help provide information about the future of this industry!

Balanced decision on the future of Flex

Essentially, Adobe has come to the realization that the world does not
want plug-ins on mobile devices.  Unfortunately Adobe has done a
terrible job communicating what their intention is, and the initial
feeling many Flash/Flex users and developers had bordered on
pandemonium.  But this announcement is actually great news.  Adobe did
a poor PR job, so here's a post that really clarifies the good from
the bad: http://david.realeyes.com/?p=214.  And Adobe about their
strategy: http://www.adobe.com/devnet/flashplatform/articles/recent-updates.html

These are long posts, so if you don't have time, here's my summary:

First and foremost, Flash was never really viable on mobile devices.
The actual Flash player has always been clunky, resource intensive,
and just buggy on mobile.  It was created for a world of users that
had a mouse and could interact with the screen via a cursor.  On
mobile devices this is different, and the rules of
human-computer-interaction have changed.  That said, Adobe won't put
resources into something that isn't meant for mobile.

Second, Adobe is finally giving us (developers) the ability to fix
Flex faster than Adobe could.  Since Flex 1.0, Adobe has controlled
the entire update and release process of Flex, often times ignoring
blatant problems and publishing updates with a strange sense of
priority.  As an open source technology, the community of developers
gets to enhance it, much like Sun made Java open source, and aids
development, but doesn't control where it goes.  The community gets to
enhance a mature technology and improve on it, with resources from
Adobe and the rest of the world.  Adobe is finally making good on its
original promise from years ago to make Flex truly open source.

Third, the Flash player for the desktop will continue development
because it is viable, extremely robust, ubiquitous, and provides a
uniform experience regardless of which platform you are on.

Fourth, for mobile development, Adobe stands behind AIR and the
continued improvement and development of this tool.

I am not urging anyone to simply take the path of one technology over
another.  HTML5 is definitely here to stay, but its tools, frameworks,
and community are very immature compared to the Flash platform.
Conversely, native development is expensive in time and resources, and
both paths cost a lot in regards to testing every browser on every
device and OS.

There are arguments for why companies should begin acquiring and/or
developing talent in native and web-based technologies, but these are
bets being made for a future that might pan out one direction or
another.  I think it is beneficial to all companies that have used
Flash in the past to realize that not much has changed or will change.
 Flex is an awesome enterprise development tool that can be used to
rapidly build projects.  Flash and AIR are great resources with an
excellent community.  Adobe just needed to openly realize that Flash
on a mobile device wasn't realistic, and that the community will
benefit more by having Flex be truly open sourced.

For the future of your projects, I truly believe Flex is very strong,
secure, and viable.  The wariness of Adobe's commitment is
understandable.  Regardless, Flex isn't going anywhere, and will be
here (specifically in the enterprise) for many years to come.