So it has been some time since I made a post. Been busy but I hope to manage my time better in future so that I can post my thoughts more often. The main reason I do this is to benefit myself in terms of aligning what I see and experience in the community into a coherent philosophy.
I wanted to touch on several things in the last few weeks I have been interested in. Actually sitting down and writing this was sparked by this news item (Adobe to take Photoshop online at Cnet) that caught my eye in my RSS feeds.
It caught my eye due to a discussion I had with Josh, where we debated a bit this very concept. Word processing and excell spread sheets aside it seemed unlikely that the on-line application model as exemplified by Google docs would work for something like GIMP or Photoshop. It is interesting to look at this in light of things like Joyent though. Correl is looking to take a variation of Word Perfect into a model that uses both on-line and off-line elements in collaboration with Joyent. This mix of on-line and off-line aspects to an application is very interesting to me. It is all part of the development that is taking place where API's like XUL, XAML etc are getting attention in the same context as GTK and QT. However, how much application API's matter is up to debate. Is it only the movement and management of information in an open and extensible manner that really is important?
One element of that did catch my eye was Remix which uses Flex. This is more interesting to me as it brings up the issue of rich client development. I have been watching XUL, XAML (Windows Presentation Foundation) and things like FLEX and Laszlo for some time now. Mix in things like the rich client platforms from Eclipse and Netbeans and you have the making of new "internet aware application API's" forming. This would be great. GTK, QT, Cocca etc. aside what is more interesting to me is the ability to make "application" that come to the user over the net.
Grails Update
Grails has a new major number out and a major shift in the way it deals with incorporating third party features. A very nice plug in approach. The jump from .3 to .4 was a bit painful as you have to un-weave the code you have done in the old approach for the new. I updated an Acegi security based application from .3 to .4. The biggest pain is removing the controller, domain, and other classes that were required prior to the plugin approach. Though this was a bit tedious it is well worth it for the nice new plugin based system. Hopefully such a major effort will not be required in the future. I suspect the Acegi package is one of the bigger ones to migrate.
Seems they also changed the way to they do the creation of URL's and several of my relative links got broken. I should be using more of the Grails link tag (http://grails.org/Tag+-+link) more than using relative URL linking.
This blog visualization is cool
This is neat.. http://twingly.se/ScreenSaver.aspx useful? Not so sure, but for sure neat. If I ran windows I would likely install it and play with it some.
Yahoo Pipes
Yahoo Pipes came out, this one one of those things I was interested in blogging about. I even retrieved/reactivated my Yahoo account just to play with this. While I found it very interesting, I can not say I found it highly useful. This idea implemented as an API I could embed in my app server, that would be far more interesting.
There are several other packages like this out there too. xFruits and even www.yourminis.com.
Don't get me wrong, the idea behind Pipes is very much along the route I would like to see things going. Mechanisms to collect, relate and cross reference data generated on the net. I'd just rather have it as an API for my applications rather than a third party service provide to/for me.
Get things done
I was only tangentially aware of the GTD approach. The book has spawned several packages on-line and I reviewed a few of them listed in the post at Center Networks. One, Tracks, caught my eye and I actually installed and got ruby working (which can be a pain with regard to DB access at times). (rant) The Ruby on Rails database API and interface is archaic in comparison to Java JDBC let alone persistence aspects (/rant)
I got it set up and working and played around with it some. It took a while to get this done due to the poor, IMHO, ruby database approach. Anyway, Tracks is interesting, but I think I was more interested in the experience it gave me with Ruby on Rails than anything else. I may try and play with it some more in the future though and revisit it as a utility and approach to time management. On a side note the Joyent package mentioned above is a Ruby on Rails application. The note some interesting news coming from them based on the collaboration with Sun. One might speculate on them switching to jRuby in the near future. jRuby plus the Java VM could be a very powerful combination for an application like this. I am still a Grails person until jRuby evolves more. When it does I will give it a try again.
Thursday, March 01, 2007
Saturday, January 27, 2007
XML UI's revisted (XAML, XUL and AJAX)
Back in October I made a post about WPF and my concerns around it. Now the European Committee for Interoperable Systems (ECIS), has raised similar concerns. To be fair some of the points raised by the people at the respectable Ars Technica site are valid on this point. Their article on this development raises many issues that indicate XAML (WPF) is not quite a full scale attack on standards (not yet anyway). A review of WPF at Wikipedia.
This was interesting news for me to wake up to since I have been thinking about XML based GUI's lately in relation to the Grails development I have been doing. Grails recently added OpenLaszlo as a build option for interfaces. (Ref: http://grails.codehaus.org/OpenLaszlo+plugin)
The combination of XHTML and JavaSript to make user interfaces via AJAX that one can embedd into XHTML is currently all the rage. One can contrast this with XUL as yet another plus JavasScriptUI toolset. The process of embedding XUL UI's into XHTML might not be so clear to me at this time. Though perhaps XHTML in XUL is more likely anyway. I need to investigate this and also how CDF might play into this. Blending AJAX and XUL approaches might be an interesting gadonkin.
In the same manner that the grails generate-views command can be used to make XHTML interfaces the grails generate-laszlo is used to scaffold artifacts for Laszlo. So why not a grails generate-xul command? Indeed, as the Ars article points out it is hard to imagine anything that could compete with the ubiquitous presence of HTML. However, for web applications the ability to auto generate different UI's (XHTML, XUL, OpenLaszlo, etc) has some appeal. If this is done automatically from the domain classes with common class extensions to a set of scaffold'ed artifacts then a developer can simply worry about the application and the elements a UI needs and leave the final implementation of the UI up to the user. If the user wants XUL, then give that, if the user wants OpenLaszlo then give that. This might have more appeal yet as the web moves toward things like the iPhone, or the OpenMoko.
Also of note in that regard is the development of things like Wazaabi which brings XUL to the Eclipse RPC environment which can be used develop rich client applications. A friend of mine has used Eclipse RPC in his efforts related to work in Antarctica. :)
In conclusion I believe that the generation of richer UI's delivered across the web to browsers or brokered out to supporting apps by browsers is a developing trend. I'm interested to see how the Grails application framework could be used to generate XUL interfaces that are used from within Mozilla based browsers like Firefox. Combine this with the Mircoformats based semantics I have written previously about and I start to see a component framework built around Web standards and protocols. I need to build an example of some of this to truly investigate it.
This was interesting news for me to wake up to since I have been thinking about XML based GUI's lately in relation to the Grails development I have been doing. Grails recently added OpenLaszlo as a build option for interfaces. (Ref: http://grails.codehaus.org/OpenLaszlo+plugin)
The combination of XHTML and JavaSript to make user interfaces via AJAX that one can embedd into XHTML is currently all the rage. One can contrast this with XUL as yet another plus JavasScriptUI toolset. The process of embedding XUL UI's into XHTML might not be so clear to me at this time. Though perhaps XHTML in XUL is more likely anyway. I need to investigate this and also how CDF might play into this. Blending AJAX and XUL approaches might be an interesting gadonkin.
In the same manner that the grails generate-views command can be used to make XHTML interfaces the grails generate-laszlo is used to scaffold artifacts for Laszlo. So why not a grails generate-xul command? Indeed, as the Ars article points out it is hard to imagine anything that could compete with the ubiquitous presence of HTML. However, for web applications the ability to auto generate different UI's (XHTML, XUL, OpenLaszlo, etc) has some appeal. If this is done automatically from the domain classes with common class extensions to a set of scaffold'ed artifacts then a developer can simply worry about the application and the elements a UI needs and leave the final implementation of the UI up to the user. If the user wants XUL, then give that, if the user wants OpenLaszlo then give that. This might have more appeal yet as the web moves toward things like the iPhone, or the OpenMoko.
Also of note in that regard is the development of things like Wazaabi which brings XUL to the Eclipse RPC environment which can be used develop rich client applications. A friend of mine has used Eclipse RPC in his efforts related to work in Antarctica. :)
In conclusion I believe that the generation of richer UI's delivered across the web to browsers or brokered out to supporting apps by browsers is a developing trend. I'm interested to see how the Grails application framework could be used to generate XUL interfaces that are used from within Mozilla based browsers like Firefox. Combine this with the Mircoformats based semantics I have written previously about and I start to see a component framework built around Web standards and protocols. I need to build an example of some of this to truly investigate it.
Sunday, January 14, 2007
Microformats
I was interested to see some news items that on the surface don't seem related but to me have a lot to say about trends.
Mozilla has started talking about Firefox 3 (http://www.readwriteweb.com/archives/mozilla_does_microformats_firefox3.php) and in particular has mentioned microformats and a broader role for the browser as broker of information and service on the net to other applications. As a long time UNIX person I believe in the vision of small dedicated programs that do what they are meant to do and do it well tied together via piping. So the idea of data described by microformats, discovered or retrieved by broker and routed (piped) to other more dedicated applications has appeal to me.
Also of note was Songbird talking about plans for an API for site developers. I hope this evolves into a microformat or RDFa that allows a music centric site developer to place data directly into their web page that allows browsers like Songbird or even machine searching and indexing of music by the likes of Google or Singing Fish to use structured data from within a page or site.
This could get very exciting with things like Apple TV and The Venice Project (which is also using Mozilla technology) coming up and extending this possibility into video. With browsers getting more extensible and smarter about how they can handle structured data site developers will actually be able to see a reason (ie benefit) to doing something (anything) with metadata. Which to this point has has little to no use or benefit (IMHO).
Mozilla has started talking about Firefox 3 (http://www.readwriteweb.com/archives/mozilla_does_microformats_firefox3.php) and in particular has mentioned microformats and a broader role for the browser as broker of information and service on the net to other applications. As a long time UNIX person I believe in the vision of small dedicated programs that do what they are meant to do and do it well tied together via piping. So the idea of data described by microformats, discovered or retrieved by broker and routed (piped) to other more dedicated applications has appeal to me.
Also of note was Songbird talking about plans for an API for site developers. I hope this evolves into a microformat or RDFa that allows a music centric site developer to place data directly into their web page that allows browsers like Songbird or even machine searching and indexing of music by the likes of Google or Singing Fish to use structured data from within a page or site.
This could get very exciting with things like Apple TV and The Venice Project (which is also using Mozilla technology) coming up and extending this possibility into video. With browsers getting more extensible and smarter about how they can handle structured data site developers will actually be able to see a reason (ie benefit) to doing something (anything) with metadata. Which to this point has has little to no use or benefit (IMHO).
Friday, December 29, 2006
404... your app no longer works
How many more buzz words could I get into to the title? Been a while with Christmas this month, but there is something I have been meaning to think/write about. Google says it will do no evil. So why then am I some what concerned when I see things like the news at: http://code.google.com/apis/soapsearch/. While I might not be surprised to see the SOAP end point go away, replaced by a ReST end point, I am a bit shocked to see an AJAX replacement.
This Google search box is definitely exactly what I have been working with myself (and many others). The ability to place a software component directly into a remote DOM. It is also very analogous to the OpenDoc approach I have been advocating for sometime.
However, an AJAX component is not a service. It is not something that I can invoke like a SOAP or ReST end point. Obviously (I think) that a dissection of what is occurring with Google Search AJAX component would reveal a ReST based response system, likely returning XML or most likely JSON(P). However that doesn't mean that the average user will be able to use it or even access that ReST end point (if it is there).
This whole issue with services is interesting. A development group might say they are going to create all their service components as open ReST or SOAP end points. For them to then eat their own dog food is important. That is they should use what they offer others. However, this can have issues like performance and scaling factors. These are issues that might be avoided in a group just used native environment services like (for Java) RMI, Jini, beans, EJB, etc. The lure of SOAP and ReST is that others can use them regardless of platform. However, we don't have an environment right now where many service consumers rely on or trust remote data services to build web apps on. Aggregated RSS/ATOM feeds don't count as a service.
In fact, most groups create and use their own services to build their final value added result, not for others. In that case however, the argument for SOAP or ReST is even harder to make. Indeed that very argument favors the use of components in the primary language(s) of the development group.
Yes, the argument can be made that in the case of Google, driving or presenting the brand is more important from a business POV than "doing good" by giving out a SOAP (or ReST) end point for people to use with potentially no reference to Google at all. However, I am not going to dwell on the business model aspect of this action in this post (perhaps tangentially I will).
No the real wonder I have is since there is no real market for services, will the SOAP and ReST efforts just wither and die for now? Until a need (a want) for the ability for sites like Slashdot and Digg, or TV listing sites or Mac rumors sites or whatever to actually work together for the benefit of each other (and as a result the users) we wont see much need for services. This is unlikely to occur in our current environment where the business model for sites is to get readership and eye balls across adds or to the fewer "pay for premium access" sites. It may occure in other groups less driven by economics and more by altruistic endeavours like science, social good, etc. Even then though, how many groups are willing to risk the operations of their web app on the existence and reliability of services provided by completely autonomous groups?
Had UDDI or any other directory service actually succeeded in gaining use perhaps some of this might have been avoided (perhaps... not likely though). However, that didn't happen. I am curious about an approach that involves more server side logic where an "agent" like application downloads logic and data into a local cache. From there execution of local code can produce results based on the remote logic and data. This has many issues though since many disciplines have so much data that transferring the all the data is not feasible (or logical).
Don't get me wrong. Services are not dead and things like SOAP and ReST may find more affection from things like mobile devices, web aware game consoles (for things like Wii weather) or the recent Google / NASA efforts that might show up in Google Earth than they might from server farm based efforts.
Additionally, ReST based service end point information embedded into a page perhaps via some microformat syntax might be interesting if more value added browsers (rich internet apps (RIA)) like Songbird become more popular. In that example a web site devoted to music might inform a browser like Songbird about its local offering via ReST end points rather than Songbird scrapping the sites content and page DOMs.
Perhaps services are just waiting for that killer app (RIA or agent) to come along and actually make people want all this.
Ref:
http://developers.slashdot.org/developers/06/12/20/0155238.shtml
This Google search box is definitely exactly what I have been working with myself (and many others). The ability to place a software component directly into a remote DOM. It is also very analogous to the OpenDoc approach I have been advocating for sometime.
However, an AJAX component is not a service. It is not something that I can invoke like a SOAP or ReST end point. Obviously (I think) that a dissection of what is occurring with Google Search AJAX component would reveal a ReST based response system, likely returning XML or most likely JSON(P). However that doesn't mean that the average user will be able to use it or even access that ReST end point (if it is there).
This whole issue with services is interesting. A development group might say they are going to create all their service components as open ReST or SOAP end points. For them to then eat their own dog food is important. That is they should use what they offer others. However, this can have issues like performance and scaling factors. These are issues that might be avoided in a group just used native environment services like (for Java) RMI, Jini, beans, EJB, etc. The lure of SOAP and ReST is that others can use them regardless of platform. However, we don't have an environment right now where many service consumers rely on or trust remote data services to build web apps on. Aggregated RSS/ATOM feeds don't count as a service.
In fact, most groups create and use their own services to build their final value added result, not for others. In that case however, the argument for SOAP or ReST is even harder to make. Indeed that very argument favors the use of components in the primary language(s) of the development group.
Yes, the argument can be made that in the case of Google, driving or presenting the brand is more important from a business POV than "doing good" by giving out a SOAP (or ReST) end point for people to use with potentially no reference to Google at all. However, I am not going to dwell on the business model aspect of this action in this post (perhaps tangentially I will).
No the real wonder I have is since there is no real market for services, will the SOAP and ReST efforts just wither and die for now? Until a need (a want) for the ability for sites like Slashdot and Digg, or TV listing sites or Mac rumors sites or whatever to actually work together for the benefit of each other (and as a result the users) we wont see much need for services. This is unlikely to occur in our current environment where the business model for sites is to get readership and eye balls across adds or to the fewer "pay for premium access" sites. It may occure in other groups less driven by economics and more by altruistic endeavours like science, social good, etc. Even then though, how many groups are willing to risk the operations of their web app on the existence and reliability of services provided by completely autonomous groups?
Had UDDI or any other directory service actually succeeded in gaining use perhaps some of this might have been avoided (perhaps... not likely though). However, that didn't happen. I am curious about an approach that involves more server side logic where an "agent" like application downloads logic and data into a local cache. From there execution of local code can produce results based on the remote logic and data. This has many issues though since many disciplines have so much data that transferring the all the data is not feasible (or logical).
Don't get me wrong. Services are not dead and things like SOAP and ReST may find more affection from things like mobile devices, web aware game consoles (for things like Wii weather) or the recent Google / NASA efforts that might show up in Google Earth than they might from server farm based efforts.
Additionally, ReST based service end point information embedded into a page perhaps via some microformat syntax might be interesting if more value added browsers (rich internet apps (RIA)) like Songbird become more popular. In that example a web site devoted to music might inform a browser like Songbird about its local offering via ReST end points rather than Songbird scrapping the sites content and page DOMs.
Perhaps services are just waiting for that killer app (RIA or agent) to come along and actually make people want all this.
Ref:
http://developers.slashdot.org/developers/06/12/20/0155238.shtml
Saturday, December 02, 2006
A groovy week on grails
So the Ruby on Rails people asked the group that started the "Groovy on Rails" effort to stop using the term "on Rails" (whatever). That is why they have the name Grails now. They didn't ask me and I have to say that this week of building a first end to end app for production use with Grails was quite groovy.
First, I do like the coding by convention approach that allows less code and less configuration to be used. I also like that what configuration is there is in the form of classes not XML. We made an app for the ANDRILL effort and it should see the light of day soon (ie be reviewed and deployed).
During the course of this development I was very impressed with how the various packages in Grails: Hibernate, Quartz, AJAX (via prototype in my case), Spring (obviously) and the GORM objection relation mapping all work. I am very keen to make up a Quartz job and then use the jabber resource to make a job that looks for changes or additions to the database and then IM's me. That is more for me, the real version would likely report via email.
We did run into some issues (Grails is only version .3 after all). An issue with binary uploads in a none scaffolded controller (I assume the generated static code is somehow out of sync with the dynamic scaffold generated code). Also had an issue with using the remotelink tag for AJAX calls vs using the remoteform tag for the same effect. We resolved this by just not using them :) but I need to report this to the Grails people to see if it is a known issue or something I was doing wrong. Getting used to the scope of certain classes and methods took some getting used to as well, but that is more just my ignorance with how the plumbing was working at the start of this effot.
Having full access to the all the wonderful Java classes makes Grails a no brain-er for me over Ruby on Rails. I have to admit I am a bit sad that Sun seems to be in love with Ruby (via jRuby which ironically is also a codehaus effort at http://jruby.codehaus.org) and pays little if any attention to Grails so far (hopefully this will change). Yes, though jRuby the Ruby syntax gets access to the classes as well. We will see how this all works out. I was interested to find that one of the key people in the Apache Geronimo effort is also one of the key Groovy people as well. Ruby has some very cool aspects to it, but I think the JVM is a better host for it than as a stand alone app directly on top of the OS.
In a final experiment (ref: InfoQ Grails + EJB and a Graeme Rocher blog entry) we used entity classes (not entity beans) that we generated via Netbeans for a database and dropped the POJO's into a grails app and were able to get read and write access to the db via the grails app using these entity classes as our domains with simple generated controllers and views. We had some issues with primary key mappings, but nothing too hard for us to work around. This was interesting to me since I could use the entity classes along with Hibernate to do the data access work and then Grails as an lightweight flexible dev layer on top of that. Grails lacks sophisticated buses like Service mix and others, but I am not certain I need or want those at this time (or that I can't do what I really want inside the Grails framework anyway).
First, I do like the coding by convention approach that allows less code and less configuration to be used. I also like that what configuration is there is in the form of classes not XML. We made an app for the ANDRILL effort and it should see the light of day soon (ie be reviewed and deployed).
During the course of this development I was very impressed with how the various packages in Grails: Hibernate, Quartz, AJAX (via prototype in my case), Spring (obviously) and the GORM objection relation mapping all work. I am very keen to make up a Quartz job and then use the jabber resource to make a job that looks for changes or additions to the database and then IM's me. That is more for me, the real version would likely report via email.
We did run into some issues (Grails is only version .3 after all). An issue with binary uploads in a none scaffolded controller (I assume the generated static code is somehow out of sync with the dynamic scaffold generated code). Also had an issue with using the remotelink tag for AJAX calls vs using the remoteform tag for the same effect. We resolved this by just not using them :) but I need to report this to the Grails people to see if it is a known issue or something I was doing wrong. Getting used to the scope of certain classes and methods took some getting used to as well, but that is more just my ignorance with how the plumbing was working at the start of this effot.
Having full access to the all the wonderful Java classes makes Grails a no brain-er for me over Ruby on Rails. I have to admit I am a bit sad that Sun seems to be in love with Ruby (via jRuby which ironically is also a codehaus effort at http://jruby.codehaus.org) and pays little if any attention to Grails so far (hopefully this will change). Yes, though jRuby the Ruby syntax gets access to the classes as well. We will see how this all works out. I was interested to find that one of the key people in the Apache Geronimo effort is also one of the key Groovy people as well. Ruby has some very cool aspects to it, but I think the JVM is a better host for it than as a stand alone app directly on top of the OS.
In a final experiment (ref: InfoQ Grails + EJB and a Graeme Rocher blog entry) we used entity classes (not entity beans) that we generated via Netbeans for a database and dropped the POJO's into a grails app and were able to get read and write access to the db via the grails app using these entity classes as our domains with simple generated controllers and views. We had some issues with primary key mappings, but nothing too hard for us to work around. This was interesting to me since I could use the entity classes along with Hibernate to do the data access work and then Grails as an lightweight flexible dev layer on top of that. Grails lacks sophisticated buses like Service mix and others, but I am not certain I need or want those at this time (or that I can't do what I really want inside the Grails framework anyway).
Sunday, November 26, 2006
coding by convention vs prior convention
Been a while since I posted. I have still be doing some work with Grails and Java EE5. I completed out my test for UI's via AJAX as well but I thought I would put down some thoughts on coding by convention.
I am new to the Rails approach and I have to say I quite like it. The idea that the file system, file names and such carry meaning and that the framework uses these to look for things that might otherwise be designated in XML configuration files is quite nice.
Until of course you create a domain image. I created the domain image in Grails. This has the effect of telling Grails that any URL with /app/image in it should be processed by the controllers, services and such associated with that domain. Unfortunately this also means that img tags with src attributes that use /app/image in their path don't load images from a directory in that path, but that pass the request on to the domain controller.
It's a small point perhaps, but it does make me wonder what else I might run into. Domains with names like image, pdf or I am sure many other (conventional names) just might interfere with the convention of the framework.
I am new to the Rails approach and I have to say I quite like it. The idea that the file system, file names and such carry meaning and that the framework uses these to look for things that might otherwise be designated in XML configuration files is quite nice.
Until of course you create a domain image. I created the domain image in Grails. This has the effect of telling Grails that any URL with /app/image in it should be processed by the controllers, services and such associated with that domain. Unfortunately this also means that img tags with src attributes that use /app/image in their path don't load images from a directory in that path, but that pass the request on to the domain controller.
It's a small point perhaps, but it does make me wonder what else I might run into. Domains with names like image, pdf or I am sure many other (conventional names) just might interfere with the convention of the framework.
Monday, November 06, 2006
Working on contrasting EE5 and Grails (Rails)
It has been a while since I did a post. I have been busy at work on some new architecture designs and intend to make a good entry contrasting Grails and Java EE5 efforts soon. However it has been a while and thought I would post up some errata thoughts I have had. It has been very interesting to see how the two efforts (Grails and EE5) deal with similar goals compared and contrasted to each other. Trying to do the same thing in two different frameworks has definitely made it easier to see how each is addressing needs. Of particular interest is comparing how grails deals with call backs from ajax widgets to server side logic compared to the Java Jmaki effort. I've got a longer post with my lessons from this that I am working on for a later date.
I must say I have come to really like closures. A programming concept I have not used much to this point. Groovy (which Grails is based on) does closures and I also found an interesting page on closures for Javascript. Ruby also obviously does this well.
I selected Grails over Ruby on Rails mostly due to the access I would have to the JVM combined with the Rails approach. Also since I was wanting to contrast against a pure EE5 approach this made more sense. By pure EE5 I mean an entity bean approach combined with JSF. With the hiring of Nutter and Enebo by Sun Microsystems, Jruby (another codehaus.org effort) could becoming an interesting option too since then "Ruby" will have access to the Java API's. It has that access now I believe, however I don't believe the Ruby and Rails aspect of Ruby is fully over to the JVM yet. I do like the coding by convention vs. the XML configuration approach however. I love XML, but think we have done too much with it in places where we could just use the coding language we have available. I definately will be looking at Ruby in general and the Ruby on Rails community more.
A very interesting interview is given by Tim Bray on InfoQ. It's a great listen for anyone interested in dynamic languages, RAILs concepts, ReST vs WS and some of the issues surrounding them.
I must say I have come to really like closures. A programming concept I have not used much to this point. Groovy (which Grails is based on) does closures and I also found an interesting page on closures for Javascript. Ruby also obviously does this well.
I selected Grails over Ruby on Rails mostly due to the access I would have to the JVM combined with the Rails approach. Also since I was wanting to contrast against a pure EE5 approach this made more sense. By pure EE5 I mean an entity bean approach combined with JSF. With the hiring of Nutter and Enebo by Sun Microsystems, Jruby (another codehaus.org effort) could becoming an interesting option too since then "Ruby" will have access to the Java API's. It has that access now I believe, however I don't believe the Ruby and Rails aspect of Ruby is fully over to the JVM yet. I do like the coding by convention vs. the XML configuration approach however. I love XML, but think we have done too much with it in places where we could just use the coding language we have available. I definately will be looking at Ruby in general and the Ruby on Rails community more.
A very interesting interview is given by Tim Bray on InfoQ. It's a great listen for anyone interested in dynamic languages, RAILs concepts, ReST vs WS and some of the issues surrounding them.
Subscribe to:
Posts (Atom)