strange constraints; gui malfunction; the need for a sane build environment

problem: webhost is stonewalling me on SSH access
current solution: use Dolphin's FTP browser to access files remotely; open them in gVim and live-edit production files.

problem: Dolphin failed to FTP gVim's saves before KDE's cache got wiped.

So, here's a testament to the inherent danger of GUIs - anybody could've written the abstraction interface between your machine and whatever GUI(s) you're using, and there's absolutely no guarantee that that person wrote that one assertion() call that would've saved your data from getting over written. A simple check on KDE (well, Dolphin's) part that ensured network files were transferred before caches were cleaned would've prevented the loss of about 1.5hrs of work.

new solution: a sane, low level build environment
resources: 'net accessible personal development server, personal laptop, science building work machines, remote webhost

download a snapshot of the current web directory on the webhost to development server.

commit snapshot to SVN.
create production directory
svn up in production directory when have new working copy in SVN

write ftp_update.py, which will:
erase current remote web directory
FTP production directory's copy of web directory

only problem is postgres access; for now I will:
migrate current remote postgres functionality to development server's postgres instance

and either:
a) think of similar scheme for 'copying' db updates to remote postgres
or
b) migrate back when my job is over

megalomaniac robot parade

largely for archiving but also up for review:

idea for part of a larger story:

corporate workers convinced that the massive cluster super computer they work on is the biggest in the world; the over-computer; the omega...

through a series of whatevers one of the workers departs from the company...wanders...discovers equally powerful computers...

discovers that there is a level of super computer siblings which their computer is a member of; turns out that each sibling is actually a virtual entity comprising one massive computer...

this thus lends itself to (seemingly) infinite and eternal recurrence up to....what? a false history written by a megalomaniac supercomputer with millions of hierarchically organized corporate children, each of which parades itself as Omega to its worker-followers?

every company thinks it's competing with the others; but each one is just representing another sibling in this huge cluster grid.

what implication does this have for the individual living/working in this system? for the eventual (?) 'real' Omega computer?

(
http://en.wikipedia.org/wiki/Henotheism ?
http://en.wikipedia.org/wiki/Neuromancer ?
)

living inside the body of a thinking machine

let's make an entity that just sits on the internet and slowly propagates itself in a non-threatening way and responds when people talk to it

how...?

write a daemon process. put it on a 24/7 server (socrates). teach it to find/join social networking sites. have it be honest ("i am not a person"). have it join IRC channels. have it merely wander around and introduce itself and, maybe, record things said to it (posted to its pages, directed towards it on irc).

why...?

something to discover for the interested...humanize a computational process...and make the internet a more mysterious place. also to gauge peoples' reactions to talking programs.

let's stop writing READMEs and make the internet more wiley...you will encounter strange things...bots programmed to do nothing but troll on irc and quote edgar allen poe...strange bots advertising sockets...when you telnet to them you get marquis de sade books in XML...leave accounts on a server open to SSH access and people log in dump them in a sandbox dir where they can make notes and leave files or messages...create an undernet of connected "strange places" and bots that only uses the internet as a means of transport...black market thinking.

let's program bots to make art and post it in strange places....people will stumble on it (the bot randomly posted its art on craigslist or IMed it to a random screen name using a text-based aim client) and maybe seek out its other works....

program bots to play online games. bots join WoW and run marathons for cancer while reciting ts eliot...or they join an fps match and just wander around talking to people while getting shot and killed over and over...or join online chess games and win...or join a starcraft game and just build a million SCVs...

remind the meat-based entities that they're living inside of thinking machines.

Neato .bashrc functions

Saw these three functions in this thread on the Arch Linux forum and thought they were neat. Since I'm on the parents' computer I thought I'd stick them here for the next time I'm on my eee (which is happily running Arch) or for when someone is googling about for .bashrc stuff :).

# from user semperfiguy's .bashrc
extract () {
 if [ -f $1 ] ; then
     case $1 in
         *.tar.bz2)   tar xjf $1        ;;
         *.tar.gz)    tar xzf $1     ;;
         *.bz2)       bunzip2 $1       ;;
         *.rar)       rar x $1     ;;
         *.gz)        gunzip $1     ;;
         *.tar)       tar xf $1        ;;
         *.tbz2)      tar xjf $1      ;;
         *.tgz)       tar xzf $1       ;;
         *.zip)       unzip $1     ;;
         *.Z)         uncompress $1  ;;
         *.7z)        7z x $1    ;;
         *)           echo "'$1' cannot be extracted via extract()" ;;
     esac
 else
     echo "'$1' is not a valid file"
 fi
}

# from user kaKTuZ's .bashrc
function remindme()
{
sleep $1 && zenity --info --text "$2" &
}

# from uer Daenyth's .bashrc
function weather ()
{
 links -dump "http://google.com/search?q=weather+${1:-02135}"
  | grep -A 5 -m 1 '^ *Weather for' | grep -v 'Add to'
}

it's the little things

I always roughly equate Perl and Python in my head. I recognize that they are good for different things but I forget that there's such a peculiarly "Perl" way of doing stuff (or, at least, 'my' Perl way - I don't profess to have tapped into some kind of universal Perl zeitgeist).

Here's some ultra simple code I wrote because I didn't feel like messing with getopt stuff, in both Python and Perl.

Python
commands = ['init','rebuild','destroy']
if len(sys.argv) != 2 or sys.argv[1] not in commands:
print "Error: Specify one of (%s)" % ' '.join(commands)
sys.exit(2)

Perl
my @commands = ('init', 'rebuild', 'destroy');
die "Error: specify one of (", join(', ',@commands), ")\n"
unless $#ARGV == 0 and index( join(' ', @commands), $ARGV[0] ) >= 0;

It's just...........different.

burning my object oriented church

When brainstorming I always tend to immediately develop a needlessly complex O.O.P. way of doing something. To date this has succeeded once. It seems that OOP simplifies everything when I'm designing but when I'm coding it just gets confusing - where does responsibility lie among my data? Is it an object's duty to update itself from a relational database? Or should a polling loop do that? Should objects be self-displaying? I can never get past these questions.

I always end up discarding the oop design in favor for a procedural solution. The lesson, it seems could be one of two things:

1.
Don't start with OOP. Come up with a procedural process, start writing some code, and wait for object ideas to rise up from the process itself. Starting with OOP molds the task - the program - to whatever objects you think you need. Going to opposite way will result in using objects that you do need and the bulk of code you write will be fleshing out the process of the program and not its data members

2.
I'm simply bad at thinking OOPishly. Starting with OOP principles and developing a process is a fine way to go and I just mess it up every time.

Though humility is a good thing, I'm leaning towards 1. It seems unreasonable to expect to come up with a good way to abstract data when you have no clue, yet, how that data is being used.

The goal of a program is to get information from point A to point B. The intelligent way to route it through a bunch of objects wouldn't become apparent, I think, until you make the connection between A and B to begin with: even if it's with less-extensible, (potentially) more verbose procedural code.

Perhaps the best way to think about it is: Start Stupid. Refactorization is easy (and fun); coming up with a genius, modular, efficient way of doing something right off the bat (as a relatively young programmer) is nigh on impossible.

troglydization

today, i laughed at dilbert

i drank my coffee

i burrowed inside the corpse of a dead goliath and expired