mike.mainguy

An anti-pattern is a commonly recurring software design pattern that is ineffective or counterproductive. One architectural anti-pattern I've seen a number of times is something I'll call the "Through the Looking Glass" pattern. It's named so because APIs and internal representations are often reflected and defined by their consumers. The core of this pattern is that the software components are split in a manner that couples multiple components in an inappropriate manner. An example is software that is split between a "front end" and a "back end", but they both use the same interfaces and/or value objects to do their work. This causes a situation where almost every back end change requires a front-end change and visa versa. As particularly painful examples, think of using GWT (in general) or trying to use SOAP APIs through javascript. There are a number of other ways this pattern can show up... most often it can be a team structure...

In my continuing comparison of ruby on rails to groovy and grails I've discovered another big difference. Grails has excellent support for job scheduling, whereas the existing rails plugins are confusingly complicated. In grails, to set up a job, install the quartz plugin grails install-plugin quartz grails create-job MyJob and edit the new class called MyJob class MyJob { static triggers = { simple name: 'mySimpleTrigger', startDelay: 60000, repeatInterval: 1000 } def group = "MyGroup" def execute(){ print "Job run!" } } Done, you now have a job running inside your application running at a repeating interval. The pluging supports cron-like syntax as well as custom triggers. Rails, on the other had (much like perl ;) has more than one way to do it. The biggest thing I notice is that most of the rails plugins either #1 require you to schedule a unix cron job example or #2 require you to run another ruby process to do the...