Radiant, CMS

The past couple of weeks I've had a change of pace and have been spending some working on content and css for the company website. I say change of pace because it involves a new technology that I haven't used before, a plugin called Radiant. Radiant is a Content Management System which means that the content which would normally be in views in a normal rails app are stored in the database. This system is convienient for sites that have a lot of content, but less going on the backend. The only hiccup that I've hit with Radiant is that since the content is the database, it becomes hard to put in source control. So, if you have made a bad change to content and want to revert it, you better remember what it was. (If anyone knows a way to remedy this, it would help) Radiant also has a lot extensions which add functionality similar to rails such as pagination and extensions that add new features like permanent redirection. Another question I've ran into while working on the site is where does the CSS files belong in this kind of structure. Does it belong in the CMS with the rest of the content or in the repository which contains the radiant plugin? I'm starting to be more convinced that maybe it belongs with latter (after working with the former). Unlike the rest of the content, the CSS files are more prone to change and tweaking than the other content files and would have more benefit being part of source control. However this does cause the developer to have two seperate environments open, the CMS for page content and a text editor or IDE for the CSS, additionality I don't know how this would work Radiant's page caching. At this point, if starting from scratch I would choose to put CSS in source control. However, if mid-flight, I don't think source control adds enough to demand the time for a switch over.....but then again I may be converted yet. I had been wondering for a while if there was a Ruby option for content-based sites and have found that Radiant is overall a good solution.

Searching for the Answer

It's remarkable how much time as a programmer I spend scouring the web for answers to problems or for some sort of example of the use of a function due to under-documentation. Which always brings to mind how to adequately search for solutions. The two stages are choosing your keywords carefully, and trying to find relevant results. This occurred to me today while I looking for uses of Cucumber involving seeing whether or not with_tag could take a regular expression as an argument.

The first part is trying to choose keywords. Obviously, I didn't want use just Cucumber otherwise I'd a hundred salad recipes but nothing to do with testing. (As it turns out a search for Cucumber wields links to the github repository at 2 and 4 with an article about it at 3) so to narrow my search I added the method I was looking for. After a few tries of various combinations of keywords (including Rspec, regex, :text, etc.), I found a set of results that I could search through for the answer I was looking for. Using the small blurbs of the websites included, I had to make sure that all my keywords were found within the same portion of text. In the end, after several searches I found that with_tag ('td', /#{regex}/) was possible and was able to go green with my tests.

This is a process that many of us go through at least a couple times each day, and most of the time we don't really think about what we are actually doing. We just go through the actions that we believe will get us to the most viable and relative answer the fastest. But underneath, there is a certain level of practice and skill needed to make sure that our time is not spent wasting away through piles of unrelated content, but rather quickly finding that nugget of knowledge needed to move forward.