Ok, so I've finished the book. And first off, I should say that I think Jason Rudolph is a very good author in communicating Grails to the newbie. He really has a skill in taking you organically into the subject matter, and his writing style is relaxed and 'easy on the eyes'. Nice one Jason!
So I finished my last post as I was about to head into authentication. Again, I was impressed with how easy it was to add 'security' to my application, at the method level. It was a closure at the top of my controller class, and I was done. Very slick. I do recall this is how Rails works as well, so wasn't completely taken by surprise.
The rest of the book went into tweaking the UI with improved layout, which uses Sitemesh. For those not familiar with Sitemesh, it was created by the very capable Joe Walnes, and was part of the OpenSymphony suite of frameworks, along with other capable frameworks like WebWork, and OSCache. I've used Sitemesh on former web application projects and it was very capable. Grails uses Sitemesh under the covers but you don't actually realize it until you see the Sitemesh configuration file in the WEB-INF folder - though you don't actually have to edit the file at all. It's just, there. There's also some coverage of CSS tweakage, but that was fairly standard and as expected.
Grails has built-in support for testing, just like Rails. It generates placeholder test classes for you to embellish. I won't testify to being an uber-unit-tester, but it's there, and should I develop the discipline further, it'll be handy. Testing your application, once you've filled out the tests, is as simple as 'grails test-app'.
Grails has built-in support for logging using log4j. From what I can tell it logs error messages by default. I'm not sure if you can use other levels, like INFO or WARN, but there must be a way. The author didn't indicate what that way was though. I'll have to look into that. Nevertheless, there are separate log4j.properties files for development, test and production, which is again slick. It's never pleasant leaving a logging level at DEBUG on a production deployed application.
Lastly there's the deployment of your application. A very nice touch is that 'grails war' will package your app for you in your chosen environment (dev, test, prod), with all the targeted settings, into a neat deployable WAR. 'Production' is the default but you can type 'grails dev war' for instance, and you'll get a development WAR with your development settings.
So, what conclusions do I have? Well I certainly am very impressed with how 'complete' grails is. At v0.4 I almost expected to see lots of "To be done" comments and sections, but really it's quite mature for such a young project. I've done some reading in blogs and such, and there are doubts cast about its maturity and readiness for enterprise deployment, but it's clear from the core developers intent that enterprise is their target. I certainly can see how Grails will be a productive framework to develop with. And I do plan to use it on a greenfield project I'm about to embark on. It's a personal project, but one aimed for an enterprise environment. So we'll see how it goes. I'm still ignorant as to how Grails works once deployed. Are those Groovy scripts reinterpreted on every request/response, or are they compiled to bytecode on the first execution and reused from there. I don't much fancy a 'reinterpret' design to a web application that I'd like to scale to high load. But these things can be subjective, and the proof of the pudding is in the eating.
Pudding anyone?
Wednesday, February 28, 2007
The Angels Sang
The angels sang, no doubt about it. And it wasn't just a benign little "Aaaaah", it was like a full Mormon Tabernacle Choir sonate.
Man, I can't believe how impressed I am with Grails. Where on earth do these Grails developers find the time to implement all this stuff, for free?! Since my last post I've been tweaking the basic auto-generated scaffolding and code that Grails produces by itself. I've tidied up some error messages, which in itself was impressive in how Grails scaffolding builds validation and error notification automatically into form submission. Validation with the 'constraints' static object is very easy. Customising your error messages follows a class.action.constraint format, also - dead easy. You edit or add to a single messages.properties file and that's it.
And here it's worth mentioning the 'flash' context, which is something I'm not aware of in other Java web frameworks, but is also something borrowed from Rails. In Java you typically have page, request, session and application context. For short-lived objects, you usually place them in page or request context. Session is more long-lived, and application obviously is the longest lived in terms of web application object lifespan. Flash context slots in somewhere around page and request, in that while page and request contexts 'die' after a response has been made to the user, flash context lives until the next request. So it lives sort of from 'response - next request' and then Grails cleans it out. Why this is useful is because often, after you've completed a use case, you want to redirect your user to a different URL, not just simply forward them. With page and request context, anything you place in those contexts will be gone when the redirect request comes back. With flash however, objects placed in 'flash' context live until the redirect request is completed. I recall from past web applications, where something like that would have been useful. Giving a confirmation message with a redirect, for instance, is very useful. I can't recall off-hand but most likely I placed stuff like that in the session context and nuked it after the next request was done, which is probably similar to how it works in Grails, but I didn't have a formal concept for it; more like a stab in the dark.
Anyway, moving along. Adding taglibs is also very easy, and has a special place in a Grails application. The conciseness of Grails - or actually - Groovy code, is very convenient here too. I followed the book and created formatting taglibs to format my numeric, date and currency fields, and all within a minute or two. Of course, I was surprised that these tags weren't already in the core Grails taglibs, but hey, it's only v0.4 at the moment, so, baby steps.
This also bears mention of the GString (*snicker*) class which allows for transformation within a String. That probably doesn't make much sense, so allow me to copy and paste from the official Grails API docs:
Now, one thing that blew me away was how easy it was to setup search capabilities, using default search syntax for simple searches, but also integrating very intuitively with Hibernate's Criteria building. Here again, no XML files to configure, just fairly straight-forward, simple code and naming conventions.
The similarities of Grails to Rails are very obvious, and one can see the Grails developers have done a good job with this. I find myself understanding this book very quickly simply because of my understanding of Rails. Those of you who haven't ever read up on Rails may find some concepts confusing at first. So take my word for it, they are good ideas. Each controller action is defined by a closure, and convention over configuration means you don't have to tweak 2 or 3 XML files to add an action to your controller. View resolution is determined by your controller and action, and the brevity with which you can accomplish much is also a Rails testament.
Now if you're anything like me, you're probably thinking "Ok, all of this is cool, but honestly, this is not complex stuff, and all this proves is that Grails accomplishes simple goals, simply." True, very true, which is why it's reassuring to see that one of the headings of the next chapter, "Not Just For Intranet Apps", is "Beyond CRUD". This is where I add authentication to my application, with specific permissions to specific views etc. Stay tuned as I delve into the unknown.
Man, I can't believe how impressed I am with Grails. Where on earth do these Grails developers find the time to implement all this stuff, for free?! Since my last post I've been tweaking the basic auto-generated scaffolding and code that Grails produces by itself. I've tidied up some error messages, which in itself was impressive in how Grails scaffolding builds validation and error notification automatically into form submission. Validation with the 'constraints' static object is very easy. Customising your error messages follows a class.action.constraint format, also - dead easy. You edit or add to a single messages.properties file and that's it.
And here it's worth mentioning the 'flash' context, which is something I'm not aware of in other Java web frameworks, but is also something borrowed from Rails. In Java you typically have page, request, session and application context. For short-lived objects, you usually place them in page or request context. Session is more long-lived, and application obviously is the longest lived in terms of web application object lifespan. Flash context slots in somewhere around page and request, in that while page and request contexts 'die' after a response has been made to the user, flash context lives until the next request. So it lives sort of from 'response - next request' and then Grails cleans it out. Why this is useful is because often, after you've completed a use case, you want to redirect your user to a different URL, not just simply forward them. With page and request context, anything you place in those contexts will be gone when the redirect request comes back. With flash however, objects placed in 'flash' context live until the redirect request is completed. I recall from past web applications, where something like that would have been useful. Giving a confirmation message with a redirect, for instance, is very useful. I can't recall off-hand but most likely I placed stuff like that in the session context and nuked it after the next request was done, which is probably similar to how it works in Grails, but I didn't have a formal concept for it; more like a stab in the dark.
Anyway, moving along. Adding taglibs is also very easy, and has a special place in a Grails application. The conciseness of Grails - or actually - Groovy code, is very convenient here too. I followed the book and created formatting taglibs to format my numeric, date and currency fields, and all within a minute or two. Of course, I was surprised that these tags weren't already in the core Grails taglibs, but hey, it's only v0.4 at the moment, so, baby steps.
This also bears mention of the GString (*snicker*) class which allows for transformation within a String. That probably doesn't make much sense, so allow me to copy and paste from the official Grails API docs:
Represents a String which contains embedded values such as "hello there ${user} how are you?" which can be evaluated lazily. Advanced users can iterate over the text and values to perform special processing, such as for performing SQL operations, the values can be substituted for ? and the actual value objects can be bound to a JDBC statement.Can't deny some of that strikes fear into me - I mean linking a String to JDBC SQL operations just screams 'security hole', but I probably don't fully understand that definition. I'll be sure to investigate this more in the days to come. But it does mean you can do things like the transformation indicated in that definition, and determine the final value in real time.
Now, one thing that blew me away was how easy it was to setup search capabilities, using default search syntax for simple searches, but also integrating very intuitively with Hibernate's Criteria building. Here again, no XML files to configure, just fairly straight-forward, simple code and naming conventions.
The similarities of Grails to Rails are very obvious, and one can see the Grails developers have done a good job with this. I find myself understanding this book very quickly simply because of my understanding of Rails. Those of you who haven't ever read up on Rails may find some concepts confusing at first. So take my word for it, they are good ideas. Each controller action is defined by a closure, and convention over configuration means you don't have to tweak 2 or 3 XML files to add an action to your controller. View resolution is determined by your controller and action, and the brevity with which you can accomplish much is also a Rails testament.
Now if you're anything like me, you're probably thinking "Ok, all of this is cool, but honestly, this is not complex stuff, and all this proves is that Grails accomplishes simple goals, simply." True, very true, which is why it's reassuring to see that one of the headings of the next chapter, "Not Just For Intranet Apps", is "Beyond CRUD". This is where I add authentication to my application, with specific permissions to specific views etc. Stay tuned as I delve into the unknown.
Tuesday, February 27, 2007
The Race Continues
So this is day 2 (I think) of my Grails journey and so far I'm really impressed. Everything has gone as advertised and the angels are going to sing any day now.
Yesterday I started on Jason Rudolph's very excellent free eBook called "Getting Started With Grails", which basically gives a primer on Grails using a Running Club registration application as the basis. His coverage is very well done, and explains each concept (so far) in just enough detail to keep the pace interesting. I'm on page 44 of 133 already and believe it or not, when I started, I can honestly say I had a simple Race Registration web application up and running within 2 minutes. Hard to believe. And Grails is extremely similar to Rails, which I'm thrilled about, since I do think Rails is onto something with their development approach. As with Rails, so much adheres to convention over configuration.
One thing I haven't found yet with Grails is whether it has any schema migration support as per Rails. Since I haven't seen any such headings I'm guessing the answer is 'no'. I'll have to find out from the Grails evangelists what their response to that is. I found that the Rails migration support was very useful, and followed my strategy in C# and Java applications I'd written that had a 'moving target' schema. I had a SchemaMigrater utility that would apply the latest SQL scripts depending on version numbers in the code. It works really well. Anyway, I've made a mental note of that and will follow up later.
The step I'm at currently is to replace all implicit scaffolding with the explicitly generated scaffolding, which is something you can do with Rails. Jason has basically led me through the basic setup, relationship definitions and domain validation steps. Currently I have a default CRUD application that links Races to Registrations, and it does basic validation on the Race and Registration inputs. Next, apparently, we're going to tweak the default layouts etc.
Oh one other note. Grails uses Hibernate, Spring and Sitemesh under the covers. What's impressive is that so far I've not touched a single Hibernate, Spring or Sitemesh configuration file. Everything thus far has been convention over configuration. Impressive. I'm kinda excited to click the 'Next Page' button in Acrobat. Tweakage, here we come.
Yesterday I started on Jason Rudolph's very excellent free eBook called "Getting Started With Grails", which basically gives a primer on Grails using a Running Club registration application as the basis. His coverage is very well done, and explains each concept (so far) in just enough detail to keep the pace interesting. I'm on page 44 of 133 already and believe it or not, when I started, I can honestly say I had a simple Race Registration web application up and running within 2 minutes. Hard to believe. And Grails is extremely similar to Rails, which I'm thrilled about, since I do think Rails is onto something with their development approach. As with Rails, so much adheres to convention over configuration.
One thing I haven't found yet with Grails is whether it has any schema migration support as per Rails. Since I haven't seen any such headings I'm guessing the answer is 'no'. I'll have to find out from the Grails evangelists what their response to that is. I found that the Rails migration support was very useful, and followed my strategy in C# and Java applications I'd written that had a 'moving target' schema. I had a SchemaMigrater utility that would apply the latest SQL scripts depending on version numbers in the code. It works really well. Anyway, I've made a mental note of that and will follow up later.
The step I'm at currently is to replace all implicit scaffolding with the explicitly generated scaffolding, which is something you can do with Rails. Jason has basically led me through the basic setup, relationship definitions and domain validation steps. Currently I have a default CRUD application that links Races to Registrations, and it does basic validation on the Race and Registration inputs. Next, apparently, we're going to tweak the default layouts etc.
Oh one other note. Grails uses Hibernate, Spring and Sitemesh under the covers. What's impressive is that so far I've not touched a single Hibernate, Spring or Sitemesh configuration file. Everything thus far has been convention over configuration. Impressive. I'm kinda excited to click the 'Next Page' button in Acrobat. Tweakage, here we come.
Monday, February 26, 2007
Grails Kick - er, Quick Start
Well I'll be. I've just completed the Grails Quick Start and I must say, I almost heard the angels. They weren't singing yet but I think I heard them warming up their voices.
The Grails Quick Start is fairly intuitive to follow. Just do what the instructions suggest and you should be fine. I won't run you through it blow by blow because it's online for your own viewing convenience at: http://grails.codehaus.org/Quick+Start, but this is a précised summary of what I did.
I ran a script to create the project outline. That worked as advertised. At this juncture the Quick Start points out that you can change the data source for your brand spanking new web application if you so desire. Or it'll start with an in-memory HypersonicSQL DB for your convenience so you can get up and running immediately. I'm good with the HSQL DB for now. I'm just having fun right now anyway.
Following this you create a domain (or model) class, using a Grails script. The Quick Start offers a 'Book' domain class with a 'title' and 'author'. Just do that. Then in a Groovy bootstrap script you setup some test data. Easy-peasy. Done.
Lastly, like any well-behaved MVC prodigy, you need to create a controller for your model. Again, call your controller 'Book', and Grails will create a 'BookController' for you. Schweet. That worked too! So far so good.
(Quick aside: the Quick Start indicates you can do a 'grails generate-all' and give that the 'Book' name and it'll create your model and your controller, but I did each step on its own. Now that I think of it, I had to do a 'grails help' to figure out that they do a 'grails create-controller' because the Quick Start doesn't indicate that, but I'm sure generate-all will accomplish the same thing at the end of the day.)
Now of course you need to have view stuff, but like Rails, Grails offers the concept of 'scaffolding' which provides the basic structure for CRUD (CreateReadUpdateDelete) operations on your brand spanking new domain/model class. So a quick edit of my BookController to tell it to scaffold the Book model class, and I'm ready to rock and roll.
The rock and roll part is as sexy and as simple as typing 'grails run-app' from my project root folder. Baddabing! My web application launches. I haven't yet looked at what Grails uses but it's obviously a lean instance of Tomcat or Resin or some such. That's irrelevant to me at this time, since I'm itching to find out whether my browser can make sense of: http://localhost:8080/myproject/book/list.
I type in the URL, hit Enter and wait with pregnant anticipation.
Whooooot! It works!
I am impressed. Like I said earlier, I'm sure I heard the angels doing voice warm-ups. I get a list of the books I typed into the bootstrap thingy, and I can add books, delete books, or go to a home page for my web application that indicates which controllers exist in my web application. And I didn't type a single line of view 'stuff'. This is neat! It took me all of about 2 mins to get a Java web application up and running. I'll be done with my new project in about 4 hours. Okay, okay, I'm getting ahead of myself. But so far so good, which is not often the case when I play with open source (i.e. open sores) stuff.
My curiosity now wants to know how Grails will cope with changes to my domain, controllers and views. That's still a bit of an unknown. Onwards we march.
The Grails Quick Start is fairly intuitive to follow. Just do what the instructions suggest and you should be fine. I won't run you through it blow by blow because it's online for your own viewing convenience at: http://grails.codehaus.org/Quick+Start, but this is a précised summary of what I did.
I ran a script to create the project outline. That worked as advertised. At this juncture the Quick Start points out that you can change the data source for your brand spanking new web application if you so desire. Or it'll start with an in-memory HypersonicSQL DB for your convenience so you can get up and running immediately. I'm good with the HSQL DB for now. I'm just having fun right now anyway.
Following this you create a domain (or model) class, using a Grails script. The Quick Start offers a 'Book' domain class with a 'title' and 'author'. Just do that. Then in a Groovy bootstrap script you setup some test data. Easy-peasy. Done.
Lastly, like any well-behaved MVC prodigy, you need to create a controller for your model. Again, call your controller 'Book', and Grails will create a 'BookController' for you. Schweet. That worked too! So far so good.
(Quick aside: the Quick Start indicates you can do a 'grails generate-all' and give that the 'Book' name and it'll create your model and your controller, but I did each step on its own. Now that I think of it, I had to do a 'grails help' to figure out that they do a 'grails create-controller' because the Quick Start doesn't indicate that, but I'm sure generate-all will accomplish the same thing at the end of the day.)
Now of course you need to have view stuff, but like Rails, Grails offers the concept of 'scaffolding' which provides the basic structure for CRUD (CreateReadUpdateDelete) operations on your brand spanking new domain/model class. So a quick edit of my BookController to tell it to scaffold the Book model class, and I'm ready to rock and roll.
The rock and roll part is as sexy and as simple as typing 'grails run-app' from my project root folder. Baddabing! My web application launches. I haven't yet looked at what Grails uses but it's obviously a lean instance of Tomcat or Resin or some such. That's irrelevant to me at this time, since I'm itching to find out whether my browser can make sense of: http://localhost:8080/myproject/book/list.
I type in the URL, hit Enter and wait with pregnant anticipation.
Whooooot! It works!
I am impressed. Like I said earlier, I'm sure I heard the angels doing voice warm-ups. I get a list of the books I typed into the bootstrap thingy, and I can add books, delete books, or go to a home page for my web application that indicates which controllers exist in my web application. And I didn't type a single line of view 'stuff'. This is neat! It took me all of about 2 mins to get a Java web application up and running. I'll be done with my new project in about 4 hours. Okay, okay, I'm getting ahead of myself. But so far so good, which is not often the case when I play with open source (i.e. open sores) stuff.
My curiosity now wants to know how Grails will cope with changes to my domain, controllers and views. That's still a bit of an unknown. Onwards we march.
Grails - The Journey Begins
Grails has a fairly neat and intuitive home page. You can find the most important stuff there like, er, well, documentation. Imagine that! Along with an 'Installation' page, and a 'Quick Start' page, there's also a 'User Guide', 'Tutorials' and 'FAQ'.
There's 'Reference' links as well as the obligatory mailing lists, wiki, issue tracker and SVN pointers.
The content of the main page bares some testimonials including one that says:
Wow, that's quite a testimonial. So far I haven't heard the angels, but I'll let you all know, the moment I do.
Nevertheless, while listening out for the angels, I followed the instructions from the Installation page and all went according to plan. Installed Grails, set some necessary environment variables and typed 'grails' in expectation of a help screen and guess what happened... it worked! Pleasantly surprised by this, since a lot of open source projects I've tried DON'T work 'out of the box'.
One point to note is that from previous sandbox activity on my part, I already have Groovy installed on my machine, so I wonder if that installation would have still worked if Groovy wasn't installed. *shrug* I'm not going to investigate that further. I'll leave that as an exercise for the reader. *grin*
There's 'Reference' links as well as the obligatory mailing lists, wiki, issue tracker and SVN pointers.
The content of the main page bares some testimonials including one that says:
"I found Grails and it was like the heavens opening and angels singing "AAAAaaaaawh". - Les Hazlewood
Wow, that's quite a testimonial. So far I haven't heard the angels, but I'll let you all know, the moment I do.
Nevertheless, while listening out for the angels, I followed the instructions from the Installation page and all went according to plan. Installed Grails, set some necessary environment variables and typed 'grails' in expectation of a help screen and guess what happened... it worked! Pleasantly surprised by this, since a lot of open source projects I've tried DON'T work 'out of the box'.
One point to note is that from previous sandbox activity on my part, I already have Groovy installed on my machine, so I wonder if that installation would have still worked if Groovy wasn't installed. *shrug* I'm not going to investigate that further. I'll leave that as an exercise for the reader. *grin*
In Search Of The Holy 'Grails'
Are you like me and you develop in Java but you keep encountering this constant raving about this Ruby On Rails phenomenon that keeps getting so much bandwidth in the online rags? Not? Well okay, but that's been my experience, so sit there and pay attention anyway. It'll be interesting, I hope.
In preparing to develop a greenfield web application recently I decided to get my hands dirty with this holy grail known as Ruby On Rails. I have to say I was very impressed with it. From the outset I was constantly thinking "Hmm, well that's quite clever, I wish Java web development was more like that." Honest, over and over again. From how it creates this complete project skeleton, to how the scripts generate all this stuff for you, to their philosophies of Don't Repeat Yourself (DRY) and Convention over Configuration. And I thought to myself: "Self, this Ruby On Rails thing isn't new anymore, and you haven't done Java web development for a while, so why not see if there's anything that's been done in the Java web world to address this approach that Ruby on Rails has taken?" So I went to look for something holistic in its approach, like Rails, but that leverages the wealth of Java technology that already exists.
At first I didn't find anything that was obvious from the usual headlines on The Server Side, or on InfoQ or on OnJava, or Javaworld and so on and so forth. The usual suspects of Struts 2 , Tapestry and Spring's WebMVC grabbed most of the headlines, and I was trying to get away from their XML configuration conflagration (sorry, that was a mouthful). I did encounter a web framework called Stripes, which seemed to make a reasonable effort, but that still wasn't quite what I felt I was looking for. Then by chance I came across Grails.
As the name implies, it borrows heavily from the philosophies of Rails and at last I'd found something that 'seemed' to do what I felt a Java approach could do, if it mimicked Rails. Like Rails, Grails uses Groovy just like Rails uses Ruby. Groovy is, for all intent and purpose, a Java scripting language. Grails uses Groovy to empower itself and accomplish various tasks with a minimal set of lines. Grails was initiated by Guillaume LaForge and founded by Steven Devijver and Graeme Rocher - who is the current Project Lead. It's still fairly young but I've communicated with an Australian, Glen Smith, who is using v0.4 in production projects. As a South African, trusting an Australian defies common sense, but hey, us Southern Hemispherians have to stick together.
So I thought I'd try out Grails and log my experience here. If you just kick the tyres it won't reveal much about the vehicle. You need to take it for a test drive, and not just amble up and down the road.
So seatbelts on, here we go.
In preparing to develop a greenfield web application recently I decided to get my hands dirty with this holy grail known as Ruby On Rails. I have to say I was very impressed with it. From the outset I was constantly thinking "Hmm, well that's quite clever, I wish Java web development was more like that." Honest, over and over again. From how it creates this complete project skeleton, to how the scripts generate all this stuff for you, to their philosophies of Don't Repeat Yourself (DRY) and Convention over Configuration. And I thought to myself: "Self, this Ruby On Rails thing isn't new anymore, and you haven't done Java web development for a while, so why not see if there's anything that's been done in the Java web world to address this approach that Ruby on Rails has taken?" So I went to look for something holistic in its approach, like Rails, but that leverages the wealth of Java technology that already exists.
At first I didn't find anything that was obvious from the usual headlines on The Server Side, or on InfoQ or on OnJava, or Javaworld and so on and so forth. The usual suspects of Struts 2 , Tapestry and Spring's WebMVC grabbed most of the headlines, and I was trying to get away from their XML configuration conflagration (sorry, that was a mouthful). I did encounter a web framework called Stripes, which seemed to make a reasonable effort, but that still wasn't quite what I felt I was looking for. Then by chance I came across Grails.
As the name implies, it borrows heavily from the philosophies of Rails and at last I'd found something that 'seemed' to do what I felt a Java approach could do, if it mimicked Rails. Like Rails, Grails uses Groovy just like Rails uses Ruby. Groovy is, for all intent and purpose, a Java scripting language. Grails uses Groovy to empower itself and accomplish various tasks with a minimal set of lines. Grails was initiated by Guillaume LaForge and founded by Steven Devijver and Graeme Rocher - who is the current Project Lead. It's still fairly young but I've communicated with an Australian, Glen Smith, who is using v0.4 in production projects. As a South African, trusting an Australian defies common sense, but hey, us Southern Hemispherians have to stick together.
So I thought I'd try out Grails and log my experience here. If you just kick the tyres it won't reveal much about the vehicle. You need to take it for a test drive, and not just amble up and down the road.
So seatbelts on, here we go.
Labels:
configuration,
convention,
dry,
grails,
groovy,
java,
rails,
ruby
Tuesday, February 20, 2007
I love coffee but I hate Java beans
If you've done any Java development, you'll have encountered the all-too-popular-but-oh-so-lame naming convention of using the word 'bean' in your class names. It's everywhere in Java technology, you get ActionBeans, you get JavaBeans, you get Enterprise JavaBeans, and then you get "Netbeans". I can't stand it. If there's anything I can't stand about 'open source'-ish technology it's the often lame naming conventions that you find. Word to the wise, Gnu is NOT a cool name to prefix everything with. You feel like somebody with a speech impediment every time you refer to something under the Gnu 'brand'. Then you get the daft Unix/Linux naming stuff of xEdit, or kEdit or whatever. All these terms are symptomatic of developer types also doing the 'marketing' of the product since it's 'open source'.
For some reason, while Java was rooted in the commercial company known as Sun Microsystems, it seems the developer types there should have gotten some help from the marketing department when they gave names to their technologies. Who was the dolt who thought "Well Java has to do with coffee and you get coffee beans, so I know, let's use the word 'bean' everywhere we can to describe stuff." And all the other geeks around him started snorting and snickering in childlike glee at the brilliance of his epiphany. Notice I said 'his', since I am convinced a woman would have been way more original.
I wish I had a Men In Black magic pen, and could flash that red light from a website somewhere that would make everybody just forget about the word 'bean' in any other context than a coffee shop or a food source that encourages flatulence. It's lame, and it should go! I feel like a kid in a playschool sandpit everytime I have to type the word 'bean' anywhere in my code or in documentation. What's next? Do we extend the idea to other aspects of our code. In future instead of having:
Thanks, I feel better now.
For some reason, while Java was rooted in the commercial company known as Sun Microsystems, it seems the developer types there should have gotten some help from the marketing department when they gave names to their technologies. Who was the dolt who thought "Well Java has to do with coffee and you get coffee beans, so I know, let's use the word 'bean' everywhere we can to describe stuff." And all the other geeks around him started snorting and snickering in childlike glee at the brilliance of his epiphany. Notice I said 'his', since I am convinced a woman would have been way more original.
I wish I had a Men In Black magic pen, and could flash that red light from a website somewhere that would make everybody just forget about the word 'bean' in any other context than a coffee shop or a food source that encourages flatulence. It's lame, and it should go! I feel like a kid in a playschool sandpit everytime I have to type the word 'bean' anywhere in my code or in documentation. What's next? Do we extend the idea to other aspects of our code. In future instead of having:
private Person person;I'll make it:
private Person personWerson;Instead of:
private ShoppingCart cart;I'll make it:
private ShoppingCart trolleyWolley;You get the point. It's all just dumb, and poorly envisioned. Why does an ActionBean have to be an ActionBean. Just call it an Action. Isn't that enough? If you must add something else, call it an ActionComponent, or ActionController, or something more grown up for goodness sake, but whatever we do, let's stop calling stuff 'beans'!
Thanks, I feel better now.
Subscribe to:
Posts (Atom)