Let us know what you think by e-mail or in the blog comments.  =)

There are some strong reasons for this:

• Browsers are fairly inconsistent in their handling of CSS. This means that if you want your design to look pixel-perfect identical in every mainstream browser, you’ll probably be sprinkling your code with all sorts of crazy hacks.
• Floating is the main mechanism for implementing grid-based layout in CSS. Unfortunately, it is a very unintuitive tool for this purpose.  IE’s broken box model (and other bugs) makes this even worse.
• On the other hand, tables render pretty consistently, even for older browsers. Even the best CSS layout will only really work in the modern browsers.  Tables give you everything you need to do grid-based layout and rows and columns are much more intuitive than floating boxes.

But there are also so many benefits to CSS!

• HTML markup is much simpler to write, read, and maintain.  No more scanning through crazy amounts of table markup trying to figure out which tag you forgot to close when your layout broke.
• Separation of content from presentation makes it silly simple to switch presentation styles.  You might not even need to change your HTML at all!
• Tables present an accessibility problem with screen readers that CSS layouts (done correctly) do not. To some this might not matter but I care a lot about web accessibility.
• Styles are reusable! With the right CSS selectors and some careful design of your HTML, you can avoid redundant code to produce similar stylings in different places.  In the old school of web design, you couldn’t avoid style redundancy at all.

So you want the benefits of CSS but none of the pain?  There are CSS frameworks that have been created by some crafty web developers to make CSS a lot less painful.  But these CSS frameworks basically consist of named (read: not semantic) classes which you have to add into your HTML.  If you’re into purely semantic markup, these frameworks don’t really feel like an option.

With Compass, you can have the best of both worlds!  You can use CSS frameworks but you can apply them in a way that still allows you to write your markup in the way that you prefer.  Compass is based on Sass, a meta-language for generating stylesheets written by eccentric Rubyist Hampton Catlin. Sass adds some very nifty features that address some of the main weaknesses of CSS:

• Named constants:  The one thing you can’t get away from in CSS is having to repeat constants like colours or sizes. With Sass, you can define the constant once and use it wherever you’d like.
• Hierarchical styling:  Sass emphasizes laying out styles in a hierarchical manner. While this might not generate the optimal size CSS file (due to larger selectors, for example) it is pretty simple to read.
• Mixins:  In Sass, you can define a set of styles and group them under a name.  Drop that name into the Sass file preceded by a ‘+’ and boom! those styles are all applied automatically.  This is great for applying the same CSS rules to HTML elements that are not semantically related and therefore don’t have the same class.  In edge Sass, mixins can even have parameters!

Mixins are where Compass draws most of its power.  Compass has taken the CSS frameworks and turned them into mixins that can be used in Sass files.  This allows you to use the styles defined for the named classes in the framework without actually forcing you to write those class names into your HTML.  This makes CSS frameworks much more appealing!  Compass also does some other neat things:

• Integration with major Ruby web frameworks such as Rails and Merb.
• Utilities: Pre-defined mixins that reproduce CSS effects like horizontal lists (useful for navigation!) and replacing text with an image.  Compass takes full advantage of parameterized mixins as well.
• Project templates: tell Compass which of its built-in frameworks you want to use and what you want your project name to be.  Compass does the rest!
• Modularity through partials:  Not all Sass files in your Compass project need to generate a stylesheet. Use partials (with filenames preceded by an underscore) to create modules that you can import into your main Sass files that generate the CSS for your project.
• Automatically compile CSS when Sass files change:  Miss the edit-save-reload cycle of web design with CSS and HTML?  Compass can watch your project and regenerate the CSS every time one of your Sass files changes.

I’ve been using Compass for a couple of months now and I can’t recommend it highly enough.  CSS doesn’t have to suck, Compass is the proof.  Seriously, try it now!

Here’s some of the stuff I really like about this appliance:

• Very easy to install.  This installation took almost no effort at all on my part.  I created a VMWare virtual machine with enough RAM and hard drive space and booted the CD.  The graphical installer handled the rest, including partitioning, network configuration, and passwords for root and ingres users.  When the machine finishes rebooting after installation, the web administration interface is already ready to rock.
• Alfresco License management made simple.  Just upload a license file into the web admin interface and presto, your Alfresco license is properly installed.  Heck, I wish Alfresco would implement something just like this.  Sometimes it’s way too confusing to figure out which directory in the deployment the license file needs to be copied into.  Doesn’t seem to be working at the moment, but just having the UI there is already promising.
• Alfresco AMP management made simple.  Just like with licenses, just upload the AMP file in the admin interface and you’re done.  I haven’t gotten a chance to actually try it but just having an interface like this is already a major improvement over Alfresco’s own AMP command-line tools.  I haven’t gotten to try it, but again this looks very promising.
• Automagic backup and restore.  Backup and rollback functionality is, if I remember correctly, one of the main advantages that Ingres states that it has over other databases that Alfresco supports such as MySQL.  The web interface makes scheduled backups easy to configure.  It even allows the administrator to configure where to send the backups, including NFS, Samba/CIFS, and a mountable filesystem (label).
• Automatic updates.  This is another feature that I haven’t gotten a chance to see in action yet but if it works as promised, it’ll be pretty damn slick.

Here are some things I’d like to see the appliance be able to do:

• Extend user management features into Alfresco.  At this point, there’s no way to manage Alfresco users through the web admin for the appliance.  But as we’ve seen for ourselves in integrating Sun IDM, such functionality is not trivial.  =(
• Overview of application health.  During our evaluation, Alfresco actually failed to run and when we tried to get to the login, we got a 404.  We needed to restart the tomcat service to get that working again.  It would be nice if the web admin had a page displaying the basic “health” of the various components (database, application server, Alfresco, and Share).
• Web content management.  Maybe this is a bit out-of-scope since it is an ECM appliance, but Alfresco can support web content management and we’d love to see it in the appliance, at least as a module/add-on.

This is just an initial glance.  At this point, some of the features haven’t worked quite as promised for us.  For example, at the moment we’re still having trouble with the Alfresco license management feature.  But we’re willing to assume for the moment that these might be our own misunderstandings of the appliance and its configuration rather than bugs.  In any case, this all looks really good.  The initial Ingres/Alfresco bundle was underwhelming; it was just Ingres and Alfresco with an installer for Linux.  The full Icebreaker appliance offers so much more and I think it definitely answers the question of what Ingres has to bring to Alfresco.

So here’s how it all works:

1. We’ve developed a set of Java-backed Alfresco web scripts that can perform proper provisioning and deprovisioning of users. These must be installed and accessible on the remote Alfresco server from the IDM server.
2. We’ve developed a custom resource adapter for IDM which must be deployed on the IDM server. An IDM admin can then create an Alfresco resource.
3. When a user is assigned to the Alfresco resource, that user’s account ID, first name, last name, and e-mail address are used by IDM to call the provisioning web script and create a new Alfresco user.
4. When an admin wants to remove a user from the Alfresco resource, IDM makes a call to the deprovisioning web script with that user’s Alfresco account ID.

As you can see, it’s a really basic integration right now but it could be made to do a lot more.  We’re interested in hearing your thoughts on how this can be made even cooler.

If you’d like to see a basic demo, get in touch with Zahid (his name @ tenthline.com) and he should be able to set something up.

Here’s to hoping that this beautiful marriage lasts and bears delicious fruit!  =)

• How to create a WordPress plug-in and define a widget within it.
• How to create a widget control so that the widget’s attributes can be configured.
• How to store and retrieve widget attributes for rendering by using the WordPress options mechanism.
• Use PHP to call on a web API (using PHP’s curl library) and parse the resulting JSON (also using PHP’s library functions).

And all of this took me just a couple of hours after work.  I got into a programming flow and I had fun.  And now my mind is imagining many other cool things that I could do with it:

• Make it possible to have multiple instances of the widget with different settings.  (I just finished this today!)
• Display more information than just a link to the repository (e.g. number of forks, number of watchers) and allow the user to choose how to format that information.
• Create another widget that displays news feed items for a GitHub user.
• Create another widget that displays recent commits for a project.

Some of this doesn’t seem possible through the current GitHub API but there are plans to add more features.  Hopefully I can leverage the new features to build even cooler integrations with WordPress.

Except if you read the article, you’ll quickly realize that service-oriented architecture is not dead.  Phew.  You had me worried for a bit there, Anne.  What really died is “SOA”, the enterprise IT buzzword.  Service-oriented architecture is actually a really great idea. This is not surprising as it has been proven in practice by the largest distributed software system in the world: the world wide web.  The explosion of web application mash-ups using web APIs is the best kind of example of why services are such an awesome idea.

The problem with “SOA” was twofold:

1. Service-oriented architecture is not a silver bullet (nothing is) but like any new architecture/design buzzword, it got marketed as one and the vendors quickly jumped on the bandwagon to provide “SOA” products.  As Anne points out in her article, the technology behind service-oriented architecture largely got in the way of the core idea.
2. Embracing service-oriented architecture is not as simple as buying a product and embarking on a quick (re-)integration project.  It requires completely re-thinking the way you approach enterprise software architecture.

And so, “SOA” joins the legacy of IT buzzwords that have been bludgeoned to death by hype and marketing. But what makes this death a particularly sad one is that “SOA” didn’t die because of its lack of technical merit; it died because it was misunderstood.  And so I too take a moment of silence to honor the memory of “SOA” with the rest of the enterprise IT community.

Happy New Year, everyone! Here’s to hoping that 2009 is awesome!

Happy holidays from Tenthline! We’ll be back in the New Year to continue delivering content and identity management solutions to all of you! =)

I created a GitHub project called enricob.github.com and pushed a local master branch to it. There’s only one file at the moment, index.html. Within about 10 minutes, the site was active and the page could be seen by going to the URL above.  You can see the GitHub project page by going to http://github.com/enricob/enricob.github.com.

This alone is pretty nifty but there’s one more neat feature that I haven’t been able to take advantage of yet: managing pages for other projects and anchoring them on the domain.  For example, if I were to create a GitHub project called sample, create a branch called gh-pages, and push the web page files to that branch, it would become available at http://enricob.github.com/sample. This is really cool!

The more I use GitHub, the more I understand how it is so much different from sites like SourceForge.  GitHub isn’t just a collection of open source projects and their pages: it is social networking with code.  Find a bit of time to try Git and GitHub: you won’t regret it.  =)

I’m writing this post using the new “QuickPress” feature, which gives a way of quickly writing up an article. Quite a nifty feature for the dashboard.