It would seem from Read/Write Web’s wrap-up of the Web 2.0 Summit (previously the Web 2.0 Conference) that $3000 and a few days of your time is not worth it. Apparently the Web 2.0 Expo will be more of a technological show case but I have to wonder if any conference, expo or summit is going to tell you anything that subscribing to TechCrunch, Read/Write Web and other sites don’t already tell you. Plus they do it a lot faster and are more responsive.
If you want to network, strike deals or idolise some smart people then by all means keep on attending conferences. And if you speak at them, keep it up, but otherwise are technological conferences outdated in favour of the realtime web?
In a previous post I showed how to use non-conventional tables in your Rails app. A few days on from that and I have found two ActiveRecord model methods that make it even easier and better; set_primary_key and set_table_name.
This means I don’t even need to use any views as I was previously. Hurrah!
We are getting to a point in our project where we want the different bits to start integrating. One part is Java, another is C++ and the part I am responsible for is Ruby on Rails. All of this runs off of a MySQL 5 database.
The database schema is owned by a C++ guy and while he was willing to modify some of his style to fit Rails conventions I told him not to. To be honest I was worried when I said that. It was a risk thinking that Rails would be able to handle a non-standard database. Not only were primary and join tables named completely differently to Rails conventions but the columns were quite different and the data the one Rails app needed to get at was spread over multiple databases.
About 10 minutes ago I sat back in my creaky chair and sighed a sigh of relief. It all works. Rails handles the non-standard setup just fine.
We first made views of the underlying tables (which is why we are on MySQL 5) to get as close to Rails conventions as we could. It wasn’t perfect though as all our views are prefixed. By default Rails won’t handle that unless I bastardised my model naming which we weren’t going to do. The next trick was to use AustinMoody’sdef self.table_name() “mpq.mpqs” end tip to tell Rails what table (actually, views) to use. It also solved the multiple-database problem as you just prefix the table name with the database name.
I then found out about the :join_table option on has_and_belongs_to_many in your models which deals with the join tables.
And that is all it took. I am relieved and impressed with Rails. I get all the good stuff while working on a decidely non-conventional Rails database setup.
Code coverage tools for Javascript are thin on the ground. In fact, I have only found one - JavaScript Coverage Validator - and it isn’t even out of closed beta yet.
Am I to think that all those millions of lines of Javascript out there on all those Web 2.0 sites that espouse agile practies with TDD influences don’t have code coverage? Sure, some may have unit testing but unit testing without code coverage is a less than ideal situation. You simply don’t know if you have tested all functions and all paths in your functions. Unit testing and code coverage go hand in hand, they back each other up.
Do you have a solution to code coverage for your Javascript?
Absolutely. I’ve tried ems and they are more hassle than they are worth. Percentages are too finicky and small/medium/large/etc. is too imprecise. Offer people alternate stylesheets with bigger font-sizes for accessibility in browsers like IE6 that don’t resize px sized fonts.
CSS declarations on one line
I understand Snook’s point but my text-editor supports code-collapsing and putting it all on one line makes it hard to decipher complex styles. Plus I usually use find to navigate my CSS.
Blocking the Styles
Very good advice. I also comment the blocks which makes a find operation really simple. Snook’s comment on not overriding browser defaults is also a good one.
Browser Support
Sadly I just can’t do this. Too many IE5.5 users still on my logs. Though I find stopping at that level makes for only a few cross-browser issues anyway.
Allow Block Elements to Fill Their Space Naturally
Amen to that. Often you don’t even have to think to do this, it is a by product of good HTML structure in many cases.
Use CSS Shorthand
I am mixed on this. Margin absolutely should be short-hand but font or background I often break up. Too many times has a URL problem broken the rest of a background declaration. I think that if you put everything on one line then it is easier to use shorthand.
Avoid Unnecessary Selectors
Definitley. Especially avoid div#content and use #content. It lets you swap to different elements and allows multiple uses of a class on different elements.
I’ve spent the past hour or so with a co-worker trying to get a Cocoon+Java+RSS+MySQL+XSL+DELI system to do the simplest of tasks. What a nightmare. It is incredible in its flexiblitlity. I can’t think of much it can’t do. But what it does do is very little. It seems as though the chaps who built this system spent 90% of their time on the framework of the application and about 5% on the application itself. It has huge potential but all the bits that actually do things aren’t there. String replace? Nope. I had to find an XSL template that someone else had rewritten to get that.
It’s the autobahn without the Porsche. The scaffolding without the building. The bricks without the builder.
It’s cool and wonderful and so much fun to work with but ultimately it is insanity when all you want is to get the job done. The glass without the beer (thanks for that one, Elaine.)
This is where Ruby on Rails is kicking Java and .NET web-frameworks all over the park. They are visionary and capable of far more than Rails. But Rails actually does common tasks that you need to do. It is less flexible but ultimately more productive.
For those few edge cases that it can’t handle I’ll write a function in something else and pipe it in.
Ruby really is more productive. I wanted to add OPML support to a project of ours and from past .NET experience with this wasn’t looking all that forward to it. But rexml and rio came to the rescue.
Here is some sample Ruby code that extracts all the URLs from an OPML file:
That is it. rio does the hard work of saving the web-stored OPML file into a string. rexml does the hard job of parsing that string into an XML document and then we use XPath to find all of the xmlUrl attributes.
rexml comes with most standard Ruby installs and you can install rio with gem install rio. The rio documentation is here.
In this post by Jeff Barr of Amazon, Xen is mentioned as the platform on which Amazon’s Elastic Computing is built. A good friend of mine works over at Xen and I am very impressed.
The rest of Jeff’s post is well worth reading. Playing field leveler indeed.
James Holderness writes on how various feed aggregators attempt to judge the uniqueness of items in feeds:
Detecting duplicate items in an RSS feed is something of a black art. How does one uniquely identify an item in a feed while still allowing for that item to be updated? …
I can’t say for sure what algorithms applications are using, but after running 150 tests on more than 20 different aggregators, I think have a fair idea how many of them work.
He summarises some reasonable ways of judging uniqueness and brings up good arguements for and against.
He goes on to say:
I would recommend you also include a unique link element for each item in your feed, to allow for aggregators that don’t handle guids very well. No two items should ever have the same link element,
Unfortuanately the link element is as abused as dates and GUIDs and while this principle is ideal it isn’t how many feeds are constructed. The link element is meant as a permalink to the item itself. Not to what the item is talking about or any other link. But many linkblogs will put the link they are talking about in the link element. In fact a big source of RSS, del.icio.us, gets it wrong and links to the link being mentioned. Now consider that many people on del.icio.us link to the same link and you suddenly have seperate feed items that some aggregators may treat as duplicates.
So ideally yes, GUID and link are good but in practice sadly not. This is the way of much feed parsing as we have found out in the FeedHenry.com project. Feeds need fuzzy logic to make much sense of.