Monthly Archives: October 2007

Red5 wicked cool

I have been playing around with Red5 Media Server, the open source flash server. I have to say – wicked cool. I’d never be able to afford a working version of Flash Media Server but always wanted to play around with the functionality.

I’m amazed at the way the Red5 developers have been able to reverse engineer the protocol for the RTMP by observing byte streams – who wooda thunk. Check it out at – http://osflash.org/red5/discovery or check out this email discussion thread – http://osflash.org/pipermail/red5_osflash.org/2005-September/000134.html

Anyway, for anyone unfamiliar with the Red5 technology the server is built in Java (Ruby version to come soon???) and the install was fairly easy. You can install both as a standalone server (Mac OSX) and deployed as Tomcat app (series of WARs). The standalone version uses Tomcat under the covers.

The demo flash apps included in the install were:

An app acting as as video broadcaster
An app that records a video stream to the server using flash
An app that is a chat room
An app that uses Shared Objects
A couple others…

They all worked fairly well, however, I ran into two problems. The first problem was not related to Red5 but that Flash did not recognize the video drivers (using an Intel MacBook Pro) and I had to change the preferences for Flash movies to use the USB Video Class.

The second problem was that the video quality was a little rough for the video recorder. Still working on the issue, please leave a comment if you have any ideas.

Finally, I found a great video tutorial site that covers some basics to setting up the Red5 server. It also, helped me setup a free development environment for Flash movies. Check it out – http://www.flashextensions.com/tutorials.php

Some of the videos are really basic and geared towards actionscript developers – i.e., setting up Eclipse – but I found some of the others pretty useful.

I have been playing around with Red5 Media Server, the open source flash server.

How Healthy is Grails?

One question we get a lot at Cantina is that of whether Grails is a passing fad, or if it is something that has some staying power. We have gotten that question (in some form or another) quite a bit, so it might help to explain where we’re coming from.

I agree with Adam’s thoughts in his previous post and have been very impressed with the activity in the Grails community. I subscribed to the user mailing list. Each day I receive from this list anywhere from 40-60 emails from users running into various issues on projects and folks from the Grails community providing their suggestions or troubleshooting tips. The activity of user/developer mailing lists is one of the most important benchmarks in determining the health of an open source framework – along with supplied functionality (obvious), core technology, the architects driving the vision, commercial support, documentation, check-in velocity and discussion in the blogosphere. To give an indication of the acceleration of activity in the Grails community, in October 2006 the same mailing list was averaging around 5-6 emails – almost a 10 fold increase in one year.***

Also, last week on the Grails user mailing list, there was some spirited debate on the level of Grails documentation (or lack of it) and whether it was appropriate for the release level of the framework. The amount of documentation right now doesn’t really concern me. What struck me the most about the dialog was the intensity of the debate. It shows the community is excited about what has been developed, are passionate to help out in whatever way they can, and care deeply about the frameworks success. And the community’s passion/enthusiasm for Groovy/Grails is clearly indicative of the framework’s ability to meet a need and fill a gap, something the community is looking for. IMHO this enthusiasm will be the driving force of success and perpetuate Grail’s momentum. And while more formal documentation is sure to come down the road, I’ve found the answer to most of the issues i’ve run into by querying the mailing list. It has been an excellent source of living documentation. – http://www.nabble.com/codehaus—grails-f11860.html

Of course with every new open source project there is always a lot of user/developer mailing list activity in the beginning. The question always becomes: Does this activity last, does it have staying power? With over a year and half of Grails development under their belt, a pending 1.0 release, and the clear need for a rapid application development framework in the J2EE architecture landscape, I have the feeling Grails is here to stay. Now I’m just trying to find the best way to support the growth… :)

That being said, one of our goals here at Cantina will be to leave some tips/issues that we run into as we develop plugins for the framework. Although it will not be formal documentation – we get our kicks from developing functionality – there may be some issue/tips that we run into that can be helpful to you. And please feel free to weigh in by leaving a comment if you know a better approach.

*** fyi, this calculation was performed with a VERY informal last year inspection of the mailing list on Nabble

UPDATE – 10/31/2007

I guess I should be been paying attention to the email threads a little better… :) Two email threads -

http://www.nabble.com/number-of-people-companies-using-Grails-tf4721318.html

and

http://www.nabble.com/Mailing-lists-statistics-tf4693805.html#a13416495

also discuss the growing activity of the mailing list.

One question we get a lot at Cantina is that of whether Grails is a passing fad, or if it is something that has some staying power.

What I like about Groovy on Grails

First let me congratulate all the folks that have been going crazy getting the Groovy on Grails (grails.org) framework to version 1.0 (almost there!). Just when I think my 0.5.6 version is going to be around for a while, they start releasing more versions, with a fury.

We’ve used Java here at Cantina on innumerable projects with a great deal of success. The toolset is very complete and Spring and Hibernate have been a godsend for allowing us to focus on the intellectual “meat” of a project. Then, in an effort to explore some new technology for a couple prototypes we were working on we found Grails.

I think the first thing that drew us (me) to Grails was the mantra that I heard over and over again at a talk given by Venkat Subramaniam at Sun a while ago regarding Groovy on Grails have more “signal to noise”. Less syntactical noise, more code signal (i.e., the “meat”). In his talk he threw together an AJAX enabled form in about 10-15 minutes with all the CRUD and validation you need.

Once we started using Grails in house, it quickly became apparent how deep the mantra of having a greater “signal to noise” went. We love Spring and Hibernate but we hate XML configuration. Yes, XML is ubiquitous, very readable, and supported everywhere, but, as technologies like Spring and Hibernate put more of our application structure into XML, it makes it very hard to debug all of our application when some of the structure sits in very static XML.

Grails provides a great approach to this. Through the Grails BeanBuilder, you specify all of that lovely Spring configuration within a very readable and debuggable Groovy syntax. This makes for a much more powerful way to configure the structure of your application as well as allows you to actually step through parts of your configuration with a debugger.

Of course, Grails does a whole lot more than that (including a lot of the auto-wiring in Spring so that you don’t have to do any configuration), and here are just some of the things that caught our eye:

  • GORM (Grails Object Relational Mapper): as if Hibernate wasn’t powerful enough, Grails adds some useful methods of querying and mapping your object model that go above and beyond Hibernate. With dynamic methods, you can query against properties of your object model classes (domain classes) via methods that you never have to write, like this:

    // Assuming you have a domain class called “Person”
    // with a name property and a type property that

    // can be “employee” or “customer”  
    def allPeople = Person.findAll()
    def onlyEmployees = Person.findByType(“employee”)
    def howManyEmployees = Person.countByType(“employee”)I didn’t have to write any of these find* or count* methods, they come free of charge with GORM which makes the simple queries a lot easier to manage.
  • Auto-reloading: one thing that has always plagued us as Java developers is the development cycle of fix -> deploy -> start -> test. There are certainly ways to reduce this cycle in Java, but sometimes the project just doesn’t allow for it. Grails is built with the mindset that changes to most code assets should be reflected instantly in the running application, thus reducing the time it takes to test code changes
  • TagLibs: Creating GSP (analogous to JSP) tag libraries requires much less code and no configuration to get your tags and and running
  • Intellij IDEA Integration: I love TextMate as much as the next guy, but code completion and debugging are things I’ve just gotten too used to (call me lazy). The Groovy/Grails plugin for Intellij IDEA has come a long way towards making Grails a first class IDE citizen.
  • Legacy Integration: A lot of the projects we work on involves an existing Java application and SQL database. There is often business logic already implemented in Java classes (Spring or otherwise) that really don’t need to be rewritten. Since, at the end of the day, Grails is Java, we can make use of the existing codebase in a way that is much more seamless than if we were to introduce another web technology. Also, the fact that it’s all Hibernate under the hood makes it easier to adapt a set of domain classes to an existing database schema. This makes Grails an easier sell on those technical re-architecture projects in the Java world.

Beyond the technology, there’s just a lot of momentum in the Grails community. Within the last year that I’ve been watching, Grails has gone from a 0.4 to just about 1.0 (I’ve been using PHP frameworks that haven’t bumped the minor version number in over 2 years). There’s a healthy and growing list of plugins (grails.org/Plugins) that seem to be addressing the core needs of new application development.  We’re really looking forward to the next Grails project and experiencing a lot more signal and a lot less noise.

First let me congratulate all the folks that have been going crazy getting the Groovy on Grails (grails.org) framework to version 1.0.

Benvenuto!

Greetings and salutations to all, and welcome to the very first blog post at Cantina.

First things are always first, and in the spirit of blogging as a new form of journalism (not http://en.wikipedia.org/wiki/New_Journalism) let’s get the main questions that any reporter would ask out of the way:

Who

We’re a new boutique internet technology shop specializing in whatever it takes to effectively produce web things (see About section).

What

What do we do? Well, sometimes it involes banging our heads against the wall, but at the end of the day we make great web sites and applications using best of breed practices and technologies (yes, you can read Web 2.0 in there).

When

We’ve been doing this for over 15+ years combined, but the blog starts today.

Why

We often ask ourselves that same question, but in the end, we love what we do!

How

Using some of these: agile methodologies, iterative design and development, rapid development frameworks and lots of testing.

In the process of doing what we do, we end up figuring some things out, and as part of the open source credo of “share what you know” (which sometimes comes in the form of “patch it if it’s broken”), we decided to start blogging about our little victories against buggy code. We hope that you find at least something that we’ve written here useful, and who knows, maybe someday we can do business together.

Greetings and salutations to all, and welcome to the very first blog post at Cantina.