ideas for a Wordpress theme

some ideas to start on a sort of template Wordpress theme. That incorporates the following presentation elements:

• minimum-height page/content area, which feeds into the next item:
• sticky-footer - ie. that really, properly, sticks to the bottom of the browser window
• a single depth-index for positioning elements in front/behind each other, using a common CSS position/z-index mechanism.
• completely relative or screen-scaling placement of elements (I've recently been reminded how the last-mention 'depth' aspect can interact with simple things like the scrollability of elements).
• this list should grow...

- probably based upon Thematic or something kind of rational like that. Making the relationships that allow the above kind of interactions explicit and obvious: in that case building a theme is probably the way to get the most general value out of the exercise - it's effectively a level above just doing it as an HTML/CSS/some-script combo because it has to conform to the higher-level organisation of a WP theme for a start.

Then if you begin to add some of the very bread and butter functionality that I think is missing from WP - all logic - ie. theme functions... widgets perhaps...

The last few jobs have involved some deeply defective sites that couldn't be rebuilt for various reasons. Items like the above were really just scratching the surface of nasty dependencies and instant breakages possible with fairly poor HTML/CSS when buried in a Wordpress theme. Somethimes you simply can't do the kind of refactoring or even the rebuild-from-scratch. The last item should always be the last resort but code-analysis/refactoring skills seem to be thin on the ground...

samba: running swat from xinetd

(swat - the web-based tool for managing samba servers and accounts)...well, on some (possibly most these days) linux distros it's run out of xinetd, which makes it pretty manageable: After you install your 'samba-swat' package, edit /etc/xinetd.d/swat to enable & configure it.

the critical lines being:
only_from = IP addresses/ranges you want access from
disable = no # the default being 'yes'

Now, less commonly-know it seems is the xinetd directive (ie. would work for all the apps you can wrap with it):

server_args = as-read-from-the-man-page

The server_args in this case being '-P' which limits swat to really only showing the password-change page by hiding the server config and monitoring elements. I don't want normal users to be able to see any of those items.

atypical web applications

on reflection, there's probably no such thing as a 'typical web app' - they all bring their challenges. I often seem to get the slightly off-centre ones. Not that I'm complaining really but people get told either that something is 'impossible' or is going to cost them 8 grand (which is another way of telling the client to go away).

It often seems that there's a lot of software waiting to be written in the small-business, web/print design space - apps that will encapsulate someones workflow in building or maintaining a complex website, converting images en mass or pulling data into some useful order or interface. Some of these would just be scripts & some real, hosted web applications.

How do you bring these opportunities together? the prospective client and their requirements (and some cash too I hope) and someone who can do the work - to the point where it's complete and actually does what the client wants? It's pretty hard, as I've been finding out. I'm wearing out the opportunities I can see in my network of contacts right now...

***
Actually, I really just want to write about data persistence in the context of work I've performed for clients recently - and crucially - the tech (ie. programming languages, web hosting) I've had little choice but to employ... because this aspect has been really central to even small projects.

I keep coming back to the same thought: Java Servlets(& JSP, JSF kinds of teck built on top of the spec) was the only half-way elegant, well thought out web app framework - and they were more or less complete by 2000. Given the rise of scripting in the intervening decade & the decline of Java outside of enterprise systems we are are actually worse off now than then...

Simple Rails app

All you want to do is to get up & running

on OSX Snowleopard (Ruby 1.8.7 - included with the OS & Gem 1.4.2 - after runnning gem update --system) , the sequence of steps to get a simple Rails application up & running:

> rails new app_path/app_name

cd into the  app directory & add anything special  to the Gemfile - which specifies Ruby gems to add to the apps library

> bundle install

>rails server

you should see the WEBrick test server start up

This post is necessary as using this built-in server seems to be really out of favour in Ruby-land (the Mongrel webserver is suggested) & what docs there are about it - well some paths & commands have changed...

gnu screen keyboard commands

tipsheet

I don't know what I did before I discovered Screen but I sure forget the keyboard commands all the time:

OSX SnowLeopard: switch audio

someone just told me: if you have the volume icon in your menubar (ie. this can be turned on/off in the audio preference panel) option-click the speaker icon & it will show you a menu to change input/output on all your audio devices.

this is something I've always wanted. Someone even created a little menubar app to do the same thing (well, it does a bit more really) - so I imagine it's a recent Mac addition. Apple have a long history of additions to the UI like this, stretching basic into System 7 days & it often makes 3rd-party accessories no longer relevant or necessary. I guess it's a risky market - adding functionality that is sort of 'obvious' (but is missing) - your app might suddenly become obselete.

Centos 4: install Ruby, gem & mechanize

what's out there 'in the field' is rarely the latest & greatest version of anything. Given the necessarily arcane ways that software is packaged for varieties of linux (wtf is irb a separate package?) - having 'the latest' version of your OS distro usually only means that you can actually get packages for it:

anyway -  you want to install Ruby & gem on an older centos box.

1. Use the instructions here to get ruby & gem. These are GOOD instructions - as they seem to work across several Centos versions.

2. update gem: 'gem update --system'

you want to install the 'mechanize' gem for some web-scraping, first install libxslt using yum - this should pull in all the dependencies like libxml2 etc.

There's a set of discussions about installing mechanize on ubuntu here.