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

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.

It's done

I've been spending my time since November of last year working on a Co-Curricular Transcript System for my school. I just finished it.

A few caveats:
-Only the user's side is done. I need to whip up an administrator's control panel of sorts. This shouldn't be too hard.

-I want to keep working! I didn't think this would happen, but I'm itching like crazy to optimize my code. My SQL is highly inefficient and novice and needs a facelift. My perl is also far too verbose.

-I need to release it. This could be a struggle too.

but...Hurray.