Development is easy. Creating product is hard.
I’m working very long hours at the moment. By day I work on Weceem CMS and by night I am acting as the architect and producer of a new web service that I am developing with some friends.
Of course the web service is being built with Grails – it would be insane to use anything else! Chris our developer is doing an excellent job – Grails is massively empowering. In the timescale we’ve been working to an amazing amount of stuff has been achieved – even when some of it is being learned on the job.
Oh and of course the core idea is there but the details are being fleshed out as it is developed, but Grails reduces the pain for Chris as changing direction on some features is not as heartbreaking as throwing out weeks of work on thousands of lines of code.
Our designer Pat is also working well with editing GSPs directly, something new for her which she is enjoying, along with learning the joys of Blueprint CSS and jQuery UI.
However, what was obvious to me before starting this project, is painfully obvious to me now. Modern tools like Grails take the classically hard part of making a software product and turn the problem upside down.
We don’t spend time fiddling around with config and trying to glue various tech together, writing reams of bean accessors and lame JDBC code etc. – we spend all our time trying to meet the challenge of creating an application that really makes sense to users, hides all the technical detail – while providing features that a few years ago would have been considered very low priority due to the work required to get even the basics off the ground.
Expectations of modern web apps, especially the expectations that come from ourselves as designers and users of such services, are very high.
This is however a “high quality problem” compared to chipping away at a massive mountain of code just to get something half-assed ready, and deferring all the parts that are important and useful to end users (and hence ultimately the business) until later.
Time is of the essence. Grails cuts out maybe first 3 months of dev, and we focus on the business problems.
It’s a no-brainer in that sense.
The future of computing UIs – TV and touch tablets and OS X
I find it hard to imagine we will be plugging away at these cumbersome computers for that much longer, at least not for casual usage.
It is noticeable that Mac OS X and related apps are moving to user interface paradigms that will work much better than conventional UIs on (touch controlled?) TVs and multi-touch tablets.
Some examples of this growing trend:
- Front row started it really
- Several Apple apps with full screen modes. Especially the new quicktime X and its large transport buttons, iTunes/Front row with Coverflow, iPhoto with multitouch trackpad support
- The new exposé screen layout, touchpad gesture and per-app exposé
- Spaces – something that will prove MUCH more useful if every application is full screen, and effectively each Space is a single Application. Then Exposé sort of becomes the current spaces “zoom out”
- Safari “Top sites” is, in my opinion, clearly targetted at touch (tablet) displays.
- iTunes LP media format
- This is the big one – iTunes “Home Sharing”. This is required to solve the problem of your TV/tablet as a media purchase platform. You will typically buy content at home on a TV/tablet and then expect it to be on your laptop and hence iPod.
So I expect, within a few years, for us to see a new paradigm at least for TV and tablets where apps run full screen and you swipe to switch application… and wonderfully simple UIs as a result.
If we can only do away with the keyboard, we might finally be rid of these rather old fashioned apps with lots of menus and shortcuts and yada yada.
Blog feed hacked… now fixed
Thanks to a reader (cheers Paul) it was pointed out that my RSS feed was showing spam, but only in Google Reader and similar popular online readers.
This seems to be a popular hack of WordPress sites, and its not clear to me how it is achieved – presumably through old WP bugs allowing writes.
Interestingly what they do is copy an executable PHP file from one location to an images folder, replace the contents with some encoded PHP scripts, and then add that script to the active_plugins option in the wp_options table. This seems to be a list of scripts WP runs to post-process pretty much anything after rendering.
So what happens is your articles have spam injected only when producing a feed for certain User-Agents, it seems only in the Summary/Excerpt. The fun part is you can’t see this normally on your blog or feed, unless you mimic Google Reader’s user agent, eg:
curl --no-sessionid --user-agent
"Googlebot/2.1 (+http://www.googlebot.com/bot.html)"
http://www.anyware.co.uk/2005/feed/
If you see spam when doing that against a WP site but not on the website itself, this is likely the exploit used.
The solution was to:
- Fix the active_plugins row in the wp_options table so it only pointed to valid plugins
- Remove the script that active_plugins pointed to, that was full of encoded PHP
- Remove the rss_XXXXXX entries in wp_options where XXXXX is a hex string. There are a few options with rss_ prefix that are not to be deleted, which don’t have hex suffixes. What you’re doing here is deleting the cached generated RSS/Atom feeds that have been saved containing the spam.
So what conclusions do I draw from this – which is actually the second time this has happened to me and wasted a lot of time?
First, you get your good friends who have more patience for PHP to update your WordPress for you because you’re sick of the messing around. Thank you very much Seb.
Second, you kneel and give thanks that you write your own sites with Grails and not the exploit-fest that is PHP scripting.
You can hire me
While work is ongoing on the Weceem CMS project, I have 1-2 weeks per month of my time free for contracting work from September 2009.
Just a refresher… I am a Grails contributor (although most code contributions are from a year or more back now, I’ve been too busy with plugins), and I have written the following plugins: functional-testing, navigation, email-confirmation, feeds, authentication, debug, static-resources, postcode and morph-deploy. As a result I have an in-depth understanding of the Grails ecosystem, as well as building real-world sites/applications with Grails for high profile brands.
I have also contributed to the mail plugin, and of course there’s my continued paid involvement in Weceem CMS.
My particular strengths other than coding are in architecting Grails plugins and applications, application usability and developer mentoring, and producing screencasts as training materials.
If you are interested please mail me at marc@anyware.co.uk
Weceem 0.1 to 0.2 – changes under the hood
We released Weceem CMS 0.2 just before I went away on holiday a couple of weeks ago, so I haven’t had time to write anything about it until now.
Weceem is a CMS written purely in Grails, using Grails plugins as much as possible. It has some history at jCatalog AG who have worked on the code and core concepts in various forms for a while now, and for the last 10 months or so I’ve been helping them out with Grails approaches, architecture and a little coding.
We didn’t want to write another CMS just for the sake of it. Lord knows there are so many out there, its almost painful to write another. However we believe we can bring simplicity and novel functionality to the CMS space that is missing in other Java-based CMSes. (Perhaps this is the folly of all who re-invent the wheel?)
Release 0.1 was a line in the sand, whereas 0.2 includes some major overhaul. It took a lot longer to get to 0.2 than we intended, but there were some major changes behind the scenes, aside from bringing it up to Grails 1.1.1 compatibility and splitting it out into a Grails plugin and an app, so you can embed it in your own Grails apps or use it standalone.
Here’s a brief write-up of some of the changes we made, and why. There is also a short screencast that shows these changes here.
Reworking the admin UI
The admin UI desperately needed some love, and we want to move to a much more contemporary and less “Windows app” like feel. Something that is bright, bold and clear.
We also greatly simplified it, reducing the number of screens. We are for the moment at least using BlueprintCSS for the structural layout of the admin UI. It has been a major timesaver for us coders who, if we are honest are not the best cross-browser CSS designers.
What we’ve done so far with the admin styling is begin the migration away from the old UI. The work is by no means complete yet, and the UI will be more polished in time. We’re very much focusing on getting the bare bones functionality working well first before we do anything too fancy with the visuals.
Switching to jQuery and jQuery UI
A wide mix of tech was used in 0.1 for legacy/RAD/prototyping reasons, resulting in a fair amount of bloat, and slow page load times.
As a result we ditched all of the Dojo/Dijit/Dojox stuff that was there and complete rewrote the UI in pure jQuery and jQuery UI. Our code is wonderfully lean now.
We looked at all the libraries out there and decided on jQuery. Its “where its at” as far as we’re concerned. Unfortunately we have had to use a “non-core” tree table widget and some custom behaviours for the draggable content repository, which is currently a bit ugly in places – but it is a work in progress that improves greatly on the old tree UI.
We still have some cross-browser glitches eg badly floated button icons in Safari and a few layout “blow outs” that we will fix in time. Any help with these jQuery UI style issues would be much appreciated – I haven’t received any help on the jquery ui mailing list about the Safari icon issue in particular.
Dynamic content editor
In 0.1, which had effectively evolved from a prototype, each content type had its own controller and views for editing, with lots of duplication. Much of this was modified scaffolding, and we all know that while scaffolding is great for helping you to build a house, nobody lives in a house and leaves the scaffolding up once the work is done!
Extensibility of content types in Weceem is very important to us. So in 0.2 we introduced a dynamic editor framework. There is a single controller and view set for editing all content types in Weceem now.
We achieved this by using some convention properties on the content classes to declare which fields are to be presented in the content editor, and how they should be rendered.
Because of Groovy’s wonderful dynamic abilities and Grails taglib support, we are able to render any custom editor you may wish to use on a content field – you just have to supply a Grails tag that follows a specific naming convention, and use the correct name in the editor declaration of the field in the content class.
For example, rich html editing as used for the “content” properties of HTMLContent and WikiItem, is achieved by specifying the “RichHTML” editor:
static editors = {
template(group:'extra')
content(editor:'RichHTML')
keywords()
}
The editor then invokes the editorFieldRichHTML() tag when rendering the “content” field of a HTMLContent node in the editor. Its as simple as that. We also have hooks for custom editors to pull in extra resources in the <head> section of the page, such as JS and CSS files.
We have grouping of fields into the “Extra” section, and perhaps more in future, and you can force the hiding of certain properties.
This mechanism works with inheritance, which we use heavily in the content model – although the details of precedence rules are yet to be finalized.
Reduced plugin dependencies
We removed our dependency on RichUI and a couple of other plugins, which were either not fully used yet by the CMS’s current features, or were providing unnecessary bloat.
In fact we don’t use any Grails plugins for JS-related UI work now, only the FCKEditor plugin for the rich editor for HTML editing.
Separation into Grails Plugin and Application
This was a bit of an upheaval what with all the refactoring going on too, but Weceem which was formally a Grails application is now 99% encapsulated in the Grails WeceemCMS plugin which you can install into your own Grails applications to instantly add a great extensible CMS with a ready to use admin interface.
The plugin is hosted in the central Grails plugin repository (eg: grails install-plugin weceem).
The other 1% of the original Weceem application functionality remains a standalone application that uses the Weceem CMS plugin and simply adds some config mechanisms for the DataSource, and adds Acegi security and a default content repository, a copy of the weceem.org site. Its literally a run-and-go CMS, the full source of which is under 250KB zipped!
The plugin has a very simple abstraction of security which may be subject to change in coming releases until we hit 1.0, but this allows the plugin to not care about what authentication and authorisation mechanisms you want to use. We simply abstracted this functionality into a service where you can inject your own handlers to obtain the currently logged in user id etc.
Navigation and extensible admin
More work remains to be done on this but we have utilized the Grails Navigation plugin for the admin menus, including the items in the Administration page.
What this means is that applications that use the Weceem CMS plugin can inject their own admin screens into the UI provided by Weceem. This is absolutely trivial to achieve with the navigation plugin, and exactly this approach is used by the Weceem application to add user management screens which are specific to the app, into the Administration screen:
class UserController {
static navigation = [group:'weceem.app.admin',
action: 'list', title: 'users']
...
}
Chowing down
Eating your own dog food is always recommended (who invented that phrase… who eats dog food anyway, I know I wouldn’t recommend it) and we do this in a big way:
- Weceem.org is self hosted with Weceem CMS application
- Weceem CMS application uses the Weceem CMS plugin, and proves that the abstractions work
- The people that are developing Weceem are using it for real world sites other than weceem.org
Next up…
We’re already working on version 0.3 which should bring full blog functionality in, clean up some UI niggles and bugs and flesh out the Wiki functionality too – time permitting. Oh and more test coverage and functional tests. The gap to the next release has to be a lot shorter!
I’ve put together a quick screencast showing a quick run through the admin parts of Weceem from a developer perspective. You can download it here.
