
One of the nice things about living in the middle of nowhere is that you can strum away on your front porch without worry about upsetting the neighbors.
I do wonder how far the sound carries, though. Did the kids at the bus stop down the road hear me mangling Drowsy Maggie this morning?
After nearly four years of being stuck with dial-up internet (no, really — we can’t get DSL or cablemodem service out here in the sticks) I’ve taken the plunge and signed up for Verizon’s EVDO wireless broadband service and ordered a RevA card.
The EVDO signal we get here isn’t the strongest, but it should be enough to get better speeds than 56K dial-up.
If, for some reason, it does not work as advertised, I’ll be interested to see how difficult it is to call them on their “cancel within 15 days with no strings attached” policy.
One of the things I’m most excited about is not having to remind everyone I know that I don’t have dialup when they send me links to YouTube.
Sunny, mild, early-summer day + Back in Black = utter perfection.
Whenever the super-annoying “Jitterbug” (easy to use cell phone for seniors) television commercial comes on, I find myself wondering what advertisements targeted at me are going to be like in 30-40 years.
Will my generation be portrayed and advertised to as though we’re mildly retarded, as they are in the Jitterbug ad?
I’ve been tinkering with Drupal 5.1 in one capacity or another for the last 2 or 3 months, but by and large it’s been from an on-and-off, complete-newbie perspective; install some modules, click around, add some lorem ipsum content, and wonder if you did it right.
I have spent some time learning about module development, but not knowing enough about the “right” way to do things, even the successes I’ve had there feel like a bit of a question mark.
One thing that has helped fill in some of those knowledge gaps are Lullabot’s podcasts, specifically Deprecated! and Top 40 Projects.
The biggest problems with open source projects that have been around for a long time are that
and/or
Drupal is better than a lot of projects in both regards, but whenever a platform has widespread adoption there’s always the problem of best practices. If a stable way of doing something gets enough of a foothold, you find a lot of resources that guide you in that direction.
In a great many cases, what used to be the best (or only) way to do something in Drupal can now be accomplished using CCK and Views. Probably the best example of that as described in the Deprecated! podcast is the Event module. Calendaring is a deep, sticky mess of a problem and I’m grateful not to have invested any misguided time learning the older, more inflexible way of doing it.
Overall, I find Drupal very intriguing. Everyone has gotten religion about MVC in the last couple of years, probably because of Ruby on Rails. It’s a very sensible way of building a solution, but it does have some limitations when it comes to mingling different aspects of a system’s data model, business logic, or UI… you can do those things, but a lot of times the hoops you have to jump through result in kruft and complexity. In contrast, Drupal’s system of hooks allows you to develop modules in such a way that they remain completely separate from the core while integrating very deeply with just about any aspect of the core system or other modules. It feels like a smart way of doing things that takes advantage of the way PHP works.
People like to slag on PHP for not being a “real” language as compared to Java/Python/Ruby/whatever, but they always seem to miss the point that PHP was written for doing stuff on the web, and has evolved to meet the needs of people who do stuff on the web… using a built-in PHP function like
echo("Hello, World!")
to send content to the browser may not give you the same manly feeling that
resp = HTTPResponse;
writer = resp.getWriter();
writer.println("Hello, World!");
does, but it sure feels like it makes a lot more sense. Drupal feels like it makes sense in that same way.
Somebody put this at the end of a post on the Mandolin Café message boards yesterday:
“Old-time music: It’s better than it sounds!”
It can mean whatever you want it to mean, but I think it’s just about perfect.
I’m taking a break from my module development frustrations and turning my attention to design. It’s been quite a while since I actually designed a site from top to bottom, versus taking an existing theme like Kubrick or Bonsai and fiddling with colors and a graphic or two.
It’s hard work to style every last class and ID that a CMS gives you, and to do it in such a way that your overall site looks like it just came out of Adobe Illustrator, with every color deliberately chosen and every graphic placed just-so.
I’m going to give it a shot… there’s no reason I can’t have a CMS and a nice looking site, as long as I’m willing to spend the extra time and effort to cover the small details.
Looking around at “model” web sites in the first half of 2007, designs with fixed-width, centered content areas are very much de rigeur. It makes sense from a design standpoint; it’s usually much easier to control how a design behaves when you don’t have to worry about stuff sliding all over the place or wrapping strangely when the browser window expands or contracts.
What I don’t get is why it’s fashionable to make your main content area so damn skinny… even sites who look like they’re targeting a minimum resolution of 1027x768 seem to use two sidebars at 175+ pixels apiece! With another 50-100 pixels’ worth of padding on either side, that doesn’t leave much more than 500 pixels for your content, which is arguably the most important element of your design. As larger monitors get cheaper and resolution widths start getting into the 1200-1600 pixel range, that seems like a terrible waste of space. A List Apart gets away with it because their font size is rather small, but sites that drink the Web 2.0 kool-aid and use large fonts with lots of whitespace make you scroll endlessly. It looks nice at a glance, but the constant scrolling is annoying, especially when there are gaping whitespace voids on either side of the design.
When it comes to programming problem-solving, I usually do pretty well thanks to the internet; you can find an explanation and/or example of darn near anything if you choose your search terms carefully.
That’s usually all I need; it might take me a while to absorb whatever new technique or classes/functions I’m using, but the path is usually clear.
Once in a while, though, I’ll get stuck on one problem, and kill an entire weekend on it - because it always seems like the solution is just one more tweak away… and finally I reach the point where I just keep tweaking, not remembering why I’ve moved things around, or where they were originally.
It’s been a while, but I’m definitely in that hole tonight - I’m working on a Drupal import module, and this is one of those times when I’m critically aware of my lack of formal training when it comes to algorithms. All I’m trying to do is walk a nested array structure recursively, create new nodes from those arrays, and create nested menu items that match the structure of the array.
Sounds easy enough, but the menu part is killing me. The tricky part is handling the combination of string and numeric indexes in my array, which comes from from YAML parsed by spyc. I’ve tried changing the source document structure a couple of different ways without success. I’m trying to avoid making the structure so verbose as to defeat its original purpose.
I’ve reached the point where I will probably throw all of the problem code out the window and start over. What I really need is a whiteboard.
I’ve finally started getting my hands dirty with Drupal over the last couple of weeks, going through the process of actually building a site versus adding a couple of pages and menu links here and there to see how it works, and now poking around under the hood to learn how to extend it.
Adding a bunch of pages in a row using the standard interface is usually a pain in any CMS, and Drupal is no exception: Click to expand all of the option fields, click through another screen to attach the new page to a menu, try and remember the weight of the last item you added, repeat.
Half the problem when trying to learn a new language or platform on your own is finding a practical application for it. You never get very far with “Hello, World”.
I’m really surprised there are no Drupal modules out there facilitating the import of existing content and/or menu structures. At least, none that I have been able to find other than the excellent WordPress Migration Utility . I used that to move the last 5 1/2 years’ worth of blog entries over to Drupal.
So, there’s my first practical application: a module that imports either a page hierarchy, creating a menu and stub Page nodes, or possibly even importing actual content.
I’m not sure what the import format will be. The smart way to develop this would be to make the import tool pluggable, so other people could write drivers to import whatever format they need. I think that’s overly ambitious for the first version of this plugin, but I’m beginning to get a sense of how that could be accomplished without too much trouble in Drupal.
31 January, 2009 It took me a while, but I did ultimately build just such a module. It’s in the Drupal contributions repository, and it’s called Bones.