It’s been a little over a year and 4 months since Nolan and I started Hakano after the acquisition of Vocalocity. We have spent a lot of time during the past year trying to help a few companies build and launch rich Internet applications. It was hard and painful in the beginning. And, early on, we decided it was just still too hard to do interesting stuff these days. Javascript really sucks, and the cross-browser issues are a killer. Being software guys, we really wanted to solve the problem using a platform approach to the problem. That’s just the way we think, it’s our DNA.

Late last year, after spending the summer and Fall building some web2.0-style applications and struggling with tons of Javascript, stomping on each others variables (yeah, we eventually moved to namespacing in JS), playing with lots of javascript/ajax frameworks and learning the hard way about how to do complex RIAs in a lopsided browser world – we decided to build something to help solve the problem. We code named it Seamless and developed it with a few customers that were gracious enough to provide us with interesting enterprise projects that benefited from next-generation web features. We’ve continued to refactor it over and over this past year and today, I’m proud to announce that we’ve officially launched the product and company as Appcelerator.

Appcelerator is a name that signifies what we want to accomplish: More App. Less Code. It takes way too much code to do interesting web applications that push the limits of great user experience and a rich-application feel. And, throw in a little requirement to support IE6, IE7, Opera, Firefox, Safari, iPhone, Camino and a ton of other mutations and variations – and you’ve got entirely too complex of situation for even the most talented web developer.

There’s a lot of approaches out there. And ours is different and we think it revolutionizes the way people develop web applications today. We think model-view-controller (MVC) is no longer the best approach to building SOA-enabled web applications. We believe that SOA should include Service-Oriented Application architectures – a lot like the good old days of Client-Server. We believe that there should be a clean separation between the application and the services the application uses. And, the service should be developed with a clean contract and be available to different types of applications. Some people would call that a mashup (and if you get really fancy, an “enterprise mashup”) – where you can integrate multiple services using disparate pieces of information interwoven into a useful app. We think this is really just good SOA design. If you develop your services in an SOA architecture – and then cleanly separate your application from those services – you’ll get mashup capabilities out-of-the-box. It will also be much easier to layer cross-cut concerns across your architecture – such as security, auditing, governance, aggregation and composition and complex work flow – to name a few.

Separation also has the benefit of separation of concerns from a workforce standpoint. OK, we’ve been talking about this for a long-time – especially in the Java EE world. But have we realized this yet? No, c’mon. We still work with a designer (generally) to wireframe the design, we turn that into a page template (dependent on the server-side framework in use) and then we wire it up with our controllers (if you’re really good, otherwise, you just code it all inline) and call them “views”. Yea, right, “views” – nothing more than a fancy word for something that was really invented for tightly coupled graphical user interfaces of yesteryear. In Appcelerator, you have true separation between the application and services that the application interacts with.

Additionally, service-level separation provides a good demarcation for contract-driven programming (or as some might say, interface-driven programming but without real language interfaces). When you can cleanly separate services – you can now independently develop the application from its services – and even switch out those services underneath the cover (sounds like SOA, huh)? For example, application development can progress even before integration of services has even commenced – or can run in parallel. You can even completely mock out the entire application without any real back end services – which is how we recommend you do it – such that the user interface becomes true use-case driven development. And it’s very iterative – unlike traditional MVC where you have to re-templatize, re-wire and then re-integrate code for every UI change.

There are so many other great things about what we’re doing – way too many to discuss in one blog post. So, I’ll spread them out here and on our new developer community blog just launched, called Appcelerant (get it, rant!). Stop by sometime and subscribe with your RSS reader – we’ll be having some fun and interesting discussion over there.

A little bit about the company and the model. We’ve released Appcelerator under a GPL version 2 license and our business model is a traditional professional open source model. We’ll be offering strategic consulting, training, commercial licensing and a subscription model for support.

We also have grown quite a bit since we started. We’re now at 12 employees and we have some very interesting people that are joining our team very soon that I can’t wait to talk about.

We have a good bit of work to do to really round out the product and community. We’d really like your feedback and support. If you’d like to join the community, please do so at http://www.appcelerator.org. The first 250 people to join will get a special gift and forever be known as “Early Appdopters”. Come out and support us and you’ll forever be famous (at least in our eyes).

appcelerator ria soa atlanta web2.0 hakano

Last night was the Atlanta Web Entrepreneur’s group meeting – which was held down at the ATDC, thanks to Lance Weatherby. The main discussion was “Selecting a Technology for your website”.

I served on the panel as the representative for Ruby on Rails. The other panelists were:

• Calvin Yu, Partner at MyNextDive and representing Java
• Neil Green, Partner at MyNextDive and representing PHP
• Rick Copeland, Senior Software Engineer, ExchangeFrame – representing Python
• Brendon Schwartz, Atlanta .NET Regular Guys, representing of course, Microsoft .NET

Rusty Zarse was suppose to moderate but had a family conflict – so Alan Pinstein stepped in and did a fine job. I had met Alan the previous night at the Capital Connections event and his real estate web business is very interesting.

We spent most of the night debating the merits and weaknesses of each of the different languages and frameworks. Much of the discussion blurred between comparing features of the language with the framework itself. The audience seemed to have a varying degree of backgrounds – some technical, some non-technical, others in the middle. It was challenging to talk about the pros and cons of specific frameworks and not get too geeked out. I think the main consensus we all seemed to get across was that (a) a technology platform and toolset is really about the people that are building the product/service and (b) it depends on the requirements of the business. Several of us made the point at different points that what really mattered the most was getting quality technical folk. If you did that, they would figure out the right frameworks to use.

As in almost all technology discussions, I try and think about it from a total cost of ownership standpoint. And, that often conjures up thoughts of how much my hardware costs are and what the amortization of the upfront buy will be. And then, certainly, the cost of labor or contract services assistance. And training, etc. But, recently, I had a long conversation with a customer that had made a couple of bad technology selections – not because of the technology itself – but because they neither had any internal expertise (or just plain experience) with the selection nor did they have any access regionally to people on a contract basis that could be hired to bridge the gap. While both products they selected are open source, they’re both extremely complex and their codebases are impossible to learn on a whim – especially by an average programmer. In their case, they did the simple buy-vs-build equation and technology evaluation – but completely eliminated probably the most important part: who’s going to be able to “do this”. Several questions last night centered around a similar flaw in thinking: “Which framework should I as an entrepreneur make for my technical team?” Hello…. None. If you’re an entrepreneur with no deep technology background and you have a team — you shouldn’t be making any framework decision – they should. You need to provide the requirements, the financial working parameters and the support they need — and you should get out of the way and give them the ability to execute. If you’re an entrepreneur with a technology team, go fetch them pizza while they code their butts off. I promise you, it will go a long way — especially much longer than trying to make the decision for them.

So, I thought I’d try and address in written form some of the questions that were asked last night:

What kind of websites is your technology best suited for? Which is it not so well suited for?

Ruby on Rails is really making a lot of debuts in more recent Web2.0 websites. This is partly because it’s the latest new thing. But, also, because it has a large concentration of libraries that have been specifically created for the next generation of capabilities such as tagging and geocoding. That’s not to say that you couldn’t build a traditional enterprise website in RoR, it can. RoR lacks support for some of the more enterprise integration tasks that some enterprises need – but there are plenty of backed in options like Active Messaging that allows you to talk with a JMS service for messaging. Support for web services and REST is also backed into to RoR – so it’s easy to integrate into a enterprise service bus or other SOA architecture.

What famous web2.0 sites are using your technology?

37Signals has made RoR not only possible, but popular, based on its nice utility software-as-a-service applications such as Basecamp, Campfire and most recently, Highrise. But also, the more recent challenges at Twitter has also proven that RoR based applications have a way to go to get to massive scale.

What does it cost to use your technology (e.g. hardware, software and support)?

RoR is open source and free. Hardware is not. Support is based on the community model – and I’m sure you can find a number of people who will support your rails effort if you really need it. Like almost all technology decisions, the largest factor in cost is people cost. Not just their salaries, but how efficient and productive they are. Most frameworks are chosen to help solve this problem – and RoR really succeeds in making development not only pleasant and fun again, but also extremely productive and hassle-free.

How steep is the learning curve for newcomers?

I’ve found that RoR is a little harder to un-train developers that have a lot of Java experience – simply because RoR (and Ruby itself) is just plan straightforward. It supports traditional syntaxes like the for-loop.

Let me illustrate:

In most traditional languages, you can iterate over a loop such as:


for (x=0;x<len;x++)
{
// do something here
}


In ruby, you can do something much easier:


len.times do |x|
# do something here
end


OK, certainly that was a very trivial example. But let’s take another simple one. Let’s say you need to pass in a number of milliseconds to represent how long you should sleep before you wake up. Unless the unit of time is very simple, most people have built or used libraries to assist them in calculating the value. Not in RoR:


sleep (10.minutes)


Any integer value in RoR supports any number of time unit conversions automatically. Is that enough to choose RoR over .NET? No, of course not. But, it’s pretty easy to pickup and exteremely fast to get proficient in it. It’s also one of those rare frameworks that you have moments of fun finding new ways of doing things – and when you do, you say “yes, of course, that’s so obvious!”.

How easy have you found it to find skilled people? How about in Atlanta?

Finding skilled people in RoR has been a little challenging – but that’s simply a function of time. There are certainly way more Java and .NET shops in Atlanta and the greater world than there are Ruby shops.

How much support is there for your technology? Who have you found to be reliable?

Support is amazing on the web for RoR. If you think you have a need for something, it probably already exists as a Ruby Gem on RubyForge.

What issues (if any) did you encounter being an evangelist for your technology in your organization? How did you overcome them?

For us, it was simply a matter of two variables: (a) total cost considerations of RoR – which was fractions of the Java alternatives and (b) pleasure of working with it. For our customers, it’s not that easy. We have to adapt to what our customer environments and constraints are – and in all cases to date, that’s still Java. For our own projects, we’re now 100% RoR.

What add-ons, plug-ins, tools, etc. would you recommend using?

For RoR, I’d recommend the following:

• Capistrano
• Ferret
• Monit (not specific to rails, but a great tool)
• Memcached (not specific to rails, but good for caching)
• Seam(less) - I gotta plug my own stuff!

What are some sites you’d recommend?

Some RoR sites I read often:

• the { buckblogs : here }
• err.the_blog
• The Rails Way
• Ruby Inside

All in all, I think the biggest problem with RoR is the fact that it’s new and hasn’t been hardened to the point of Java, .NET and PHP. However, that will come in short time I believe. In my previous business, we were one of the first Java based products in the telecommunications software industry. We spent many years pleading with our customers and partners that Java would scale – and it did fine. Now, there are a large number of Java based telecom products.

RoR has a long way to go and a short-time to get there.

technorati tags: ror, rails, rubyonrails, ruby, atlanta, atlantaweb, web2.0, seamless

I got notified today by the RFC Editor of the IETF that one of the specifications I co-authored with Dave Burke of Voxpilot, Mark Scott of Genesys Labs, RJ Auburn of Voxeo and Scott McGlashan of HP last year has been published as an informational draft and now available.  The draft is called draft-burke-vxml-02.txt.
In the specification, we described a standard mechanism for a SIP interface to VoiceXML media services, which is commonly employed between application servers and media servers offering VoiceXML processing capabilities. Many of the modern VoiceXML browsers support a SIP interface – however, at the time, each of them had a different way to address them, how they dealt with media and how data was passed back and forth. In this specification, we tried to lay out a standard way that all VoiceXML Browsers supporting SIP should implement.

I’m not as active in the VoiceXML or W3C community as I have been in the past 5 years – however, I recently began a very interested project for a call center doing an Ajax, Web 2.0 enabled Agent Desktop and using VoiceXML and CCXML for the backend. We’re using the Voxeo software to build the application. It’s been fun getting back involved with these types of capabilities – but what is most interesting is the merging of modern web capabilities with next generation telecom and IVR to build a next generation call center application. This makes Asterisk look like a play toy. We’re using our new open source framework, called Seam(less), to rapidly built the application and integrate it into the Voxeo CCXML platform in a very unique way. I’m hoping that we’ll have the opportunity to open source some of the messaging we’ve built from the Seam(less) message broker to the Voxeo CCXML Event I/O interface. It’s truly a very interesting and powerful integration.

technorati tags: ietf, sip, call, control, ccxml, vxml, voicexml, voxeo, hp, genesys, voxpilot, seamless, asterisk, voip

Today, we introduced the Seam(less) web application framework. The project uses the open source Apache Software License, version 2.0 for flexibility. You can download Seam(less) from Sourceforge. We have also setup a Google discussion group.

We started Seam(less) because we believe that Ajax has enabled much more than rich web client interfaces. We believe it has paved the way for a paradigm shift in web programming – a shift away from MVC-based frameworks towards lightly coupled Client/Server-based frameworks.

We believe these next generation frameworks should have the following characteristics:

• Server language independence

Developers should be able to use any language for sever development (e.g., Java, Ruby, PHP or .NET) and this choice should not impact the development of the user interface in any way or vice versa.

• Integrate the Client and Server via a lightweight, language independent message protocol

You should be able to develop client and server components independently. The contract between the client and the server should be a very simple message-based protocol. This is the primary principle behind a Service Oriented Architecture (SOA), and we believe it’s mandatory if you want to rapidly build and deploy web-based services.

You should also be able to develop fully functional client prototypes without writing a single line of server code. Furthermore, client prototypes should be convertible into production clients with little to no change.

• Leverage Ajax and DHTML without Javascript

Using Ajax and DHTML requires a significant amount of Javascript. We believe that rich client functionality should be possible without writing a single line of Javascript, but there should be Javascript-based hooks available for developers that desire more control.

• Cross-browser Support

Application developers should not have to worry about the complexities of running an application across multiple web browser products and versions.

With these characteristics in mind, we developed Seam(less). We’ve been using the framework for almost six months. It has been used on all of our projects since its development, and it has saved us hundreds of hours in development time.

We decided it was time to give Seam(less) to the community. We hope you enjoy using it as much as we have. We welcome any suggestions, comments or contributions that you would like to make. We will continue to update this site with examples that demonstrate how to use the Seam(less) framework.

technorati tags: seamless, javascript, ajax, web2.0, programming