My grandpa had this table for years, and it was always our favorite place to discuss projects and random thoughts.  All through high school, I remember spending afternoons out on the patio with him at this table, and when he died I brought it to Lincoln to live in my yard. 

It has always been a patch-work of fixes and it probably has eight layers of paint, but I decided to take measurements and mock it up so I can build a replica. I think he would approve :)

Anyway, I'm building this in SketchUp first, then I'm going to actually build it.  This post is a placeholder for my progress.

This morning, Mike Gunderloy announced the launch of Rails Bridge, which sounds like a great way to repair some of the damage that has been dealt to Rails over the last few years. I'm not one to hand-hold newbies, but I do think that if someone asks a good question, it should be answered without insult. If the same question is asked a dozen times, then clearly it's worth a full explanation somewhere, it shouldn't be met with anger and bad attitude. 

I've been wondering for awhile about a git-style wiki system, and I think this might be a good way to get started on it.  In my vision, you'd basically have wiki pages that would be articles, info pages, or tutorials.  A user could fork one of those pages, make changes, and request that they be merged back into the official page/article/tutorial.  You could also 'watch' pages or users that contribute to topics that you care about.

While all of that is going on, it'd be super awesome to be able to note the relevant libraries, then when one of those is updated it pops up a flag asking if the article needs to be updated for the new version.  An article wouldn't necessarily need to follow the edge updates, but if it was updated at the stable versions, then it'd be *way* ahead of anything else out there.  Some kind of relevant notification would be needed to tell followers of that page/topic that it might need attention, then one of them would need to make the changes.

I think the following issues would be solved by such a system:
    1. Nice way to keep newbie intro info up-to-date and easily linkable
    2. Would help to ease some of the blog plagiarism we see with copy/paste tutorials that go out of date quickly
    3. Would encourage people to make small incremental updates to tutorials without re-writing everything from scratch

Allowing Comments/Suggestions Properly

Now... would people be able to comment on pages/articles/tutorials? A lot of wikis have a separate discussion area per page where policy, best practices, and suggestions are made.  Comments can be added to commits on github now, so perhaps that'd be the way to handle comments on something like this?  The problem I see with comments is that you have a huge percent of them that are just 'thanks' messages that don't add any real value (even though they are appreciated), another large percent are people debating techniques you used and making their own suggestions, and another part is random off-the-wall stuff that may or may not be useful.  I think that overall, if people have suggestions, they should fork & write, or they should use a proper discussion area to make a case.  Perhaps traditional comments could be turned on/off per page/topic/whatever.

Moderating/Approving Changes

The creator of any page/topic/article should be the one that approves modifications and assigns permissions to it.  If someone doesn't like the info or if they have another strategy, they can fork it and make changes.  If that fork becomes higher rated than the original, then it'll be the one that gets found on the search first.  I think the relevance of the information will win and people that create pages that aren't ever updated will quickly fizzle out. 

Just noting some random projects around the house that need to get done.  

Todo:

1. Rebuild motor cover for hot tub

- 3/4" Plywood 41"x24"

2. Build hanging planter for tomato plants & herbs

3. Build small garden shed for tools

4. Build doghouse for Riley and Bella

We're starting to put some real effort into combining our separate systems under a central authentication system and i have a lot of random thoughts. 

1. Rubycas server code is readable and very easy to understand. I had issues with gems and conflicts, though and ended up spending a bunch of time upgrading to RubyEE, paths, reinstalling gems, and then upgrading passenger.  Once I had everything back to normal, I installed rubycas-server 0.7.1 with picnic 0.7.0.  No other configuration would work for me on either Leopard or Debian.

2. Unless I'm doing something stupid, it looks like there's a bug in either the way rubycas-server picks up the referring URL/Protocol or in the way rubycas-client is sending it.  I need to dig in a little more, but under Merb I kept getting a camping error complaining about the url.  The simple temporary fix while I look into things was to edit merb/filter.rb and edit this line in read_service_url:

service_url = request.protocol + '://' + request.host / controller.url(params.to_hash.symbolize_keys!)

3. Getting single-sign-out working looks tricky, but I'm going to spend a little time on it and see what happens.  It looks like there are several options that look pretty much reasonable.

4. It's not good to authenticate every request, especially if you think about things like handling uploads and ajax actions. I made a quick modification to filter.rb to add a 'force_cas_check' method that I use on specific actions that I definitely want checked.  For example... I'll use the regular cas_filter on 99% of my actions, but on the primary landing pages or on the first steps of certain processes, I'm going to use this force_cas_check method to make sure they haven't logged out somewhere.

5. OAuth looks like a good option to allow API requests across my aps, but I havent tried anything with it yet.

Everyone remember a few months back when Facebook adjusted their TOS with "scary" wordage that got the whole community in an uproar, then apologized profusely and re-directed themselves? It was seen by many as a 'positive step in the right direction' and showed that they 'really care what their users think.'  I saw dozens of facebook groups talking about how "angry" people were about the new TOS... people threatening to leave Facebook and never come back, or something.  Seriously, guys? 

Now Digg has this awful framejacking toolbar thinger that clearly was designed to just boost their own stats, and it's causing a similar fuss.  Digg will undoubtedly backtrack and 'listen' to their users and remove it.  As if they wouldn't have seen this coming if they had done even the tiniest bit of research.  To suggest that they didn't know in advance what the reaction would be seems pretty naïve to me.

Companies from all industries have to be more agile, pay more attention to their customers, etc., but this isn't an example of that in action, in my opinion.  To me, being agile means being able to learn and adapt quickly to build what your customers actually want... not shifting your direction at the whims of whatever marketing dept. came up with these ideas, then shifting back when you 'realize' you've ticked people off.

People for whatever reason (probably because most people don't actually have real problems) want to feel like they have a 'cause' to go after.  It feels to me like it's becoming a trend to just do something completely off the wall so you give them the cause, then once it's big enough, backtrack and act apologetic.

Apparently, my cause du jour is to fight against idiotic causes.

Our sites use several applications and legacy systems that don't automatically crop/resize graphics and whatnot.  Ideally, the apps would take whatever they are given, convert to a nice format, crop/resize accordingly, then put them in the right place.  Some of our apps do this already, but some of the older ones don't have this ability.

We also have a lot of random users using a lot of different projects, and it is hard to keep the limits for each project straight.  Over time, more and more people involved forget the limits, so they do whatever they think looks good, and by the time several months go by, there is no more standard.  

Using imagemagick, twitter, and hpricot, I wrote a short ruby script that grabs the pages that end up getting published & checks them for consistency.  If it finds a problem, it'll send me a quick msg on twitter & log the error so we can put real eyes on the problem and get it fixed.  I tossed this into a cron job that will run every morning, so I don't have to remember to run this script all the time.

It's quick and dirty, but it gets the job done.  I'm sure there are ways to clean it up and make it more efficient, but I'm not going to worry about that right now.

A lot of rails guys like their plugins and magic helpers and junk, but I've never been a fan.  I prefer to write full HTML & use simple methods that are easy to understand 8 months later when you look back at the code. I've seen a lot of weird methods for splitting CSS & JS files for layouts, but I think my way is one of the simplest.  

I like things clean and consistent.  If I have CSS that applies to only one part of one page, then I'll split the CSS into a file just for that purpose.  I do the same thing with javascript for unobtrusive JS.  So, let's say I have a 'new' and 'edit' action, which also needs a custom CSS file.  I would do something like this:

You can easily see which JS & CSS applies to each action, so you can just grab & edit those ones instead of digging through some giant file that has everything in it.