As a developer for Appcelerator, Inc. one of the most important aspects of my job is keeping in touch with the community through our Developer Network community site.  It’s where people ask for help, suggest ways to make our product better and discuss all things Appcelerator. Therefore, the Groups page is always open in a browser tab on my desktop.

This approach has a few drawbacks. The groups page does not automatically refresh. There’s also no real good way to tell if there is something new to look at. Now, of course, I work for Appcelerator, so I can grab the Developer Network source, make the necessary changes, and push a new version. But what if I was just a plain user of another site using Appcelerator? Is there anything I can do to get the experience that I want?

Enter Todd Ditchendorf’s Fluid project (Mac only). You could probably do something similar in Mark Finkle’s Prism if you aren’t on a Mac.

Fluid lets me do two things. It gets the developer network out of the browser and into an application. This means that it shows up as it’s own entity on my Dock. The second is that since it’s integrated into OSX, I can write a little bit of javascript to display a Dock badge and display a Growl notification.

By itself, this is really neat, but there are a few problems. If you auto-refresh a page, you’re going to lose all client state. This is less than useful if you want to show a notification if something changes.

This is where the SOUI (service oriented user interface) paradigm of Appcelerator really shines. To refresh the groups page, all I need to do is send a message. To display a notification, all I need to do is read the message response. That’s it. No funky regex based parsing required.

If you want to set this up for your Fluid Developer Network app, then you can grab the latest version of the user script, and a nifty icon off our svn server.

This post is cross-posted on Tejus’s Blog.

Popularity: 17% [?]

As the Appcelerator Developer Network continues to expand, we thought it would be nice to start highlighting the efforts of some of our most active community members to help facilitate further interaction and collaboration. For our first Developer Spotlight, we’ve selected Kevin Whinnery, a Systems Engineer with ERP powerhouse Lawson Software.

What’s a “day in the life” of Kevin Whinnery like?
At Lawson, I’m currently involved in developing an application to monitor behavior and performance of our SaaS offering for human resources. I have designed and developed a solution built with an Adobe Flex front-end and backed by a Java-based query engine.

Outside of work, I’m actively involved in other development projects with my business LightRail Systems, LLC, where you can follow my efforts through my blog. One example is a student information system developed with Ruby on Rails. We’ll be looking at ways to possibly leverage Appcelerator in this and other applications we’re developing.

How did you hear about Appcelerator?
I originally read about Appcelerator when I was trolling blogs. I made a mental note to check it out, but then got sidetracked with my other projects. A few weeks later, somebody commented on my blog that I should check out Appcelerator, so I set aside some time and took it for a test drive. I downloaded the SDK and took a crack at building something with it. I got hooked immediately and have been using Appcelerator for six months now.

What was your first impression of Appcelerator?
I’ve been developing with Flex for a couple of years now. Event handing isn’t overly complicated, but it does require a lot of code. What caught my eye with Appcelerator was the Web Expression Language – specifically, how elegant message and event handling are with Appcelerator. Compared to what I was used to with Flex, I was very impressed by Appcelerator’s capabilities right out of the gate. It’s a young framework with a few rough edges, but Appcelerator features some unique innovations that make it destined to command a large share of the growing RIA development space.

The messaging system and hand-in-glove integration with backend services are truly unique among RIA frameworks, and they represent Appcelerator’s greatest differentiators. The amount of code required to do basic things, like fire an event containing user input, is immense in an RIA framework like GWT or Flex. With the Web Expression Language and other innovations (like fieldsets – you’re going to love fieldsets), Appcelerator makes these things, which should be simple, exceedingly so.

While Appcelerator’s widget library is useful, I see that more as a future strength of the framework. There needs to be more documentation around integrating third-party widgets, but the fact that you can extend and customize Appcelerator to support any other framework, library or widget is a forward thinking strategy. While you would have to do a lot by hand today, as community support increases, there will be few more efficient ways to build RIAs than with Appcelerator.

Are you using Appcelerator for any applications you’re working on right now?
I was originally planning to use Appcelerator for the student information system we were building, but I didn’t get up to speed with the product soon enough. Given our need to launch this summer, we opted to stick with straight Ruby on Rails. We are working on a new product which will be using Appcelerator, which I could tell you about – but then I’d have to kill you. But we’re excited about showcasing some great Appcelerator features.

I’m also using Google’s App Engine for a muscular dystrophy web site I’ve created. I think Appcelerator currently is the best web framework for Python out there, and will see wide adoption as App Engine grows in popularity.

What would you like to see improved on the Appcelerator Platform?
The widget framework is still young. It’s not as developed as other tools. Flex is more customizable, with a class library that you can customize and extend as needed. While Appcelerator has set the foundation for extensibility here, there is still some work to do.

The SOA integration points are great, but I’d like to see them become a little more general purpose. While all SOA integration points serve the Appcelerator UI, I’d like to see well-known ways to invoke Appcelerator services for other clients. Eventually, I would like to see Appcelerator services behave like true RESTful web services, so they could easily serve other clients.

So you’re a big Flex supporter… what would you tell other Flex users about why they should consider Appcelerator as a complement?
First and foremost, Appcelerator’s Web Expression Language and event handling is a breakthrough in RIA technology. The messages are lightweight and easy to publish and subscribe to. The amount of event handling code you write in an Appcelerator app will go down significantly from a Flex app – especially written with Cairngorm. I can tell you this from personal experience.

Second, there’s no need to use a browser plug-in with Appcelerator. When you create an app with Appcelerator, it will be more accessible and will not need as large an initial download.

Finally, Appcelerator provides you with hand-in-glove integration with a variety of server-side technologies, with no glue code that needs to be written.

While I still like Flex, it really only makes sense to use it in situations where you are going to need to have a graphically intensive or data intensive application. For most applications, you would be swatting a mosquito with a bazooka if you chose Flex. Appcelerator is a much better choice for rich web applications that don’t need to function like fat clients.

So you’re literally writing the book on Appcelerator. What’s that about?
I am genuinely impressed with what you guys are doing. Somebody finally got how to do event driven RIA in an elegant way. This is the first breakthrough innovation we’ve seen in the next wave of Web-based application development. I fell in love with Appcelerator and wanted to get more involved with the technology. I decided to submit a proposal to Manning Publications (publishers of the “In Action” series of books, among others), and they were similarly convinced of Appcelerator’s potential.

Early access to the book should begin sometime this week, with development scheduled to continue into the fall, with a release scheduled for early 2009. I’m hoping lots of folks will join the early access program and offer some feedback during the process.

Any final thoughts you’d like to share with others that might be considering Appcelerator?
Yes. Get involved with the community. I’ve seen Appcelerator continue to innovate on a weekly basis, and thanks to the responsiveness of the development team, community members can have a say in the direction of that innovation.

About Kevin Whinnery
Kevin is a Systems Engineer at Lawson Software, and is also the President and CEO of LightRail Systems, LLC, publisher of the Recess Student Information System. He lives in the Twin Cities of Minneapolis and Saint Paul in the great state of Minnesota with his wife Kendra and two gifted and adorable children, Emmett (3) and Grace (1). When not cranking out code, Kevin enjoys some combination of coaching, playing, or watching baseball, football, and wrestling. If you’d like to get to know Kevin, reach out to him in the community - you can view his profile here.

Popularity: 17% [?]

It was 1997 and I hadn’t really embraced the web yet as a programmer. While I had played with HTML, I was convinced that real developers wrote in C/C++ and PL-SQL. HTML was for sissies. One of my co-workers was building an online search engine for an e-commerce company and he introduced me to CGI programming. The idea of redirecting the incoming HTTP request to a script that generated HTML on the fly instead of regurgitating the contents of a file seemed immensely cool to me at the time. Technology advanced and I followed with SSI, then servlets, then ASP, then JSP, then taglibs, then struts, then JSF, etc.

However, I never really questioned the basic premise that web applications are essentially a simple collection of scripts which dynamically generate HTML documents and share a server-side context (http session). Afterall, all of the server-side web technologies I had used were based on the same fundamental concept that CGI had introduced back in 1995. Most innovations in this area were just further abstractions built on top of this concept (e.g. JSP custom taglibs). But abstraction is a double-edged sword. It eliminates the need to understand everything going on under the covers. However, each abstraction layer typically includes its own configuration (struts XML hell), quirks, and conventions. Which results in the need for someone to define “best practices” based on their personal pain of figuring out where the friction points are between the layers of abstraction that live just above and just below it (e.g. ValueObjects/DataTransferObjects).

Building web applications has become much more complex than necessary and the the development community has responded with simplification efforts (think Ruby on Rails, annotations, configuration by exception, etc.). Each of these efforts were a significant evolution of web application development, but none were revolutionary. While undeniably valuable, they were still just lipstick on CGI.

True Web Clients

There is an opportunity today that really hasn’t existed until recently (outside of building GUIs completely inside a proprietary player like Flash). Stop generating HTML on the server-side. Write rich web applications as standalone clients based on open standards such as HTML, CSS, and JavaScript. Call it Client-Server 2.0 if you like, but without the baggage of software distribution, version management, and platform dependencies. While JavaScript was the foundation of this revolution it was the introduction of CSS, DOM manipulation, and finally AJAX that allowed us to build truly standalone web clients.

So how do you go about building true web clients? Until recently it was actually rather painful to do so. You had to be a JavaScript guru and even then you typically were weaving together multiple 3rd party JavaScript libraries and frameworks to provide the necessary event handling, DOM manipulation, parsing, etc. Appcelerator was designed specifically to simplify the development of web clients so that mere mortals can develop them (not just the PhDs @ Google). Yes, you can use all of the Appcelerator widgets and even leverage the client messaging bus without giving up your HTML generation scripts (and many people do). But once you’ve experienced the elegant simplicity of developing true standalone web clients that invoke services for business logic & data access, you will never go back.

The shift is already underway. The client operating system IS the browser. See the rise of offline, single-site-browsers, and desktop web integration. The clients call services and re-render themselves accordingly. The only question remaining is… how long before you starting writing webapps as standalone web clients?

upcoming blogpost teaser : HTTP sessions are so 1998

Popularity: 17% [?]