Man With Dog

With the power of CSS (and quite a bit of hacking).

I going to tinker a bit more with the layout and formatting of the various pages until either (a) I am completely satisfied—-unlikely—-or (b) I just get fed up with wrestling with HTML and CSS an then move on to other things.

The site structure is starting to take some shape. Once I complete the tinkering, I’ll move on to site organization.

Basically, the site will be divided into two parts.

• The Jeffie Part there will be stuff for me… probably lots of stuff.

• The Wiffie Part this will mostly be her quilt works and other projects.

So, there will be a landing page, a “home” page for each of us, and then the whole organizational mess underneath that.

I’m hoping to capture many of the stories/lessons/experiences I find myself repeating to people I meet. I’ll try not to blather. And if I organize my blog adequately, useful topics should be easy to find. As always, time will tell.

I’ve had enough of this messing about with HTML and CSS for today. So tedious, so cumbersome. I really wish CSS and HTML had a built-in macro-preprocessor, much like C does. That way you could set things in a very consistent manner across a wide variety of HTML properties. Sure, there are HTML preprocessors out there; yeah, I know. But that’s just another step in the process, another layer in the stack, and really just another set of gunk to wade through when things don’t go as expected.

This, then, is the look for the site: colors, fonts, sizes, general layout. This layout should work well enough on full screens as well as tablets and on little phones. Maybe later—-much later—-I’ll attempt to minimize the CSS so it’s much cleaner.

Now I can focus on the overall organization of the site. Once I do that that, then I can figure out which bits of Blosxom will generate static pages (once and done) and which bits will have to be dynamic. Ideally, this can be done in an obvious way so that 6 months, 1 year, 5 years from now, I can reproduce what I’ve done—-exactly like leaving good comments in source code. So expect a bunch of mucking about with the site as it might go through some real gyrations as I figure things out.

Until I get to the final, or near final, organization, these blog posts are going to be more blather than I otherwise would want. Sorry for the blather. Ultimately, these posts will end up in the Colophon.

As I consider the development of this blog, I am at somewhat of a crossroads. Which technologies to use: Perl *gasp!*, PHP *gasp!*, node.js *gasp!*, Python *ugh*, or some “snazzy-whazzy” blog framework *barf*.

For each of these technologies, there are as many proponents as there are opponents.

So I’m going to go “first principles”: what do I really need and then how do I get there.

Here are some needs:

• Dynamic web pages: no. My web host has deprecated Perl—okay, that’s their decision—so plan B is to go with static ent pages.

  Static pages will be fine. These I’ll generate on my local machine and then “data cannon” them up to my web server, UltraWebHosting.com

• Comments and user feedback: no. Enabling this capability would require far too much moderation and would open my site to the sewage slough of bots, scammers, etc. that is the current internet.

  The simple solution is that if you have something meaningful to add, email me your comment and I might consider adding to the post.

• Flexibility. Yes. Right now, this blog is stupifyingly simple. But I have much bigger plans and I need most of the features Blosxom provides, especially, categories and what they call flavors.

• “Security”/”performance”/”ease of use” of *blah-this* or *blah-that* or that new technology: No. If I go with purely static pages with some client-side JavaScript sprinkled in, I don’t think I’ll ever need them. Time will tell.

  Sure, security and performance will always be concerns but with static pages, these concerns are greatly mitigated.

• Is any one of current web technologies more secure or more performant or easier to use? I don’t think so. Perl can be made more secure, especially since Perl 5. PHP is not inherently secure and sloppy practices can make is much less so. For my needs, none of them will perform significantly better than the other—my needs are just too small. (Remember in Big-O analysis, when n is small, complexity of the code is more significant.)

  The other thing that concerns my about any new or “emerging” technology is that the hype for them is driven largely by marketers—they just don’t tell you enough to make an informed decision about them. So you end up spending a LOT of time learning the gizmo only to find out later that “oh, we’re still working on that feature” or something like that.

• Cost: definitely no.

• Focus on content: definitely yes. On the web, “content is king.” This was true when the web was new and despite all the glitzy graphics, shading effects, whatever, this is still true today.

  Once I get things set up, I will have succeeded if adding new content is both straightforward and fast. Ideally, the process can be automated.

So here we are.

There are a few things that appeal to me about Blosxom. These are

• file-based entries. Each blog entry is a file. I like this because I can have have several topics I’m working on/thinking about in separae files. When one is “done,” it only needs to be moved to the proper directory on my web server and voila!, there it is.

• dynamic and static. Out of the box, Blosxom is a dynamic file processor/html generator. As I learn Blosxom I’ll likely move more an more of the content from dynamic HTML to static HTML pages. I suspect it’ll be just another step in the process.

• simple. The simplicity of Blosxom appeals to me as a developer. It is very similar to the source, build, run approach for developing programs. I am also fond of the way Blosxom takes the details of HTML out of the process; these are details I tend to obsess over, which means waste time over. I hope today to add a Markdown plugin which will make creating posts nearly completely eliminated the need to use HTML markup.

• extensible. The simple plug-in facility makes Blosxom seem highly extensible. And with the careful use of CSS, JavaScript, Perl/PHP, and embedded HTML, Blosxom currently feels unbounded. Experience will tell.

• flexible. With the ability to mix static and dynamic pages, markdown text and HTML tags, the variety of plug-ins gives me the feeling of enormous flexibility. With experience, I anticipate the feeling turning into actual knowledge.

I found this article about Blosxom: Less Is More about his use of Blosxom and subsequently the site Jason Blevins that he created with it. Lovely. This is the direction I intened to take my site.

Please stand by as we adjust the dials…

So, today, I have finally gotten around to installing a web logger, called Blosxom (pronounced “blossom”). Each entry is a file, which is a feature I particularly like.

There’s a bit more to do, such as formatting and adding more content; so please stand by.

More to come…