Every project spawns new ideas, whether additions or changes, that just aren’t possible with the current (workload, budget, time-frame, all of the above). When a project creates a nice and clean foundation, the possibilities often become infinite. Sometimes they’re just small changes, but most often they’re large changes that seem much more exciting than the current project ever did.

Changes that are large are almost always out of scope, and often become their own project. I always spend some time talking with clients about the ideas that they’ve had, as well as some possibilities that they’re not aware of yet. We begin keeping a list of each idea and as time goes by we re-evaluate the potential benefit and cost values for each idea. Months later when they’ve had time to think about which ideas are worth the investment we proceed with a project that we’re both excited for.

It’s very important to keep a ’someday’ list no matter who you are - I keep a someday list for my own projects. Some of the ideas are just for fun and wouldn’t be of much use, and some might really increase the usability of an application. As time passes I get an idea of which items on the list I would like the most, and when the time comes, they’re the items I tackle first.

I’ve always focused on creating an application using a very clean and clear framework of code. Other developers, designers, and hopefully even the weekend web warrior should be able to go in and figure out what’s going on. By utilizing a myriad of classes and functions that work well together I allow for an excellent amount of scalability and expandability. This saves time not only in the beginning of a project, but makes future additions easier and cheaper for the client.

It’s also a list that let’s you have fun with projects. If you’re intentionally trying to add items to the list you often think outside the box, which is what it takes to be successful on the web today.

It’s just a place for the “wouldn’t it be cool if…”.

I’ve been using subversion a lot recently - from using repositories with client development companies to installing it for clients - it seems to be the SVN month.

Anywhere, here’s how I did it. Using CentOS 4.2. For anyone learning or using Subversion I highly recommend that you read the book.

First you need to get the package and install it.

# wget http://subversion.tigris.org/downloads/subversion-1.3.2.tar.gz
# gunzip subversion-1.3.2.tar.gz
# tar -xvf subversion-1.3.2.tar
# cd subversion-1.3.2
# ./configure
# make
# make install

Then you’ll need to setup at least one repository. I’m going to need multiple repositories that I can use for different clients so I have a bit of extra admin work ahead of me. You can setup as many repositories as you need, but no matter what you’ll need at least one. Here create the folders…

# mkdir /svn
# mkdir /svn/repo

Then we need to tell subversion to make our first repository.

# svnadmin create /svn/repo/myproject

For the time being, I’ll use the default svn server called svnserve. You can use apache to get a ton of extra features and better security. Click here for more information on using Apache with subversion. I need do some additional research for my multiple-repository setup before switching to apache though.

First, I need to setup a config file for svnserve.

# vi /svn/repo/conf/svnserve.conf

Then, look for variations of the following code and edit it as necessary. By default any anonymous user can access the code so to disable that you must include anon-access = none, just commenting the value out will not prevent anonymous access.

anon-access = none
password-db = passwdfile
realm = My SVN Repository
auth-access = write

The password-db is just a path to a file containing usernames and passwords. You’ll create this file especially for SVN. I create each file inside of the repository conf directory. So, save your changes and then we’ll create said user file.

# vi userfile

Enter in something like:

[users]
username = password

Yes, pretty basic. See what I meant about svnserve and security? The password is in plain text so if someone ever got your system or that file, they’ll have the passwords inside. That’s one more reason to move to apache.

Anyway, you’ll need to start the svn server.

# svnserve -d

One side note - svnserve just runs and doesn’t have a way to stop besides killing the process. If you make changes to the svnserve.conf or user file you’ll need to restart svnserve.

# killall svnserve

Then, go ahead and test (best to do so on a different machine).

# svn co --username=myusername svn://mydomain/svn/repo/myproject


The system should then ask you for your password and off you go!

I’m still rather disappointed with my options for weighting random results in MySQL, but I’ve done the best I can do with it. It’s more about figuring out what numbers you use for the weighting rather than the calculation itself. The query itself ends with:

[mysql]
ORDER BY RAND() * weight_fieldname
[/mysql]

Now, my possible weights from weight_fieldname are 5, 20, 100. 5 is the default weight for every record - 20 increases the chances of the record a bit and 100 pretty much sets the record as an exclusive result. Now, if you only have a single weight applied then setting it to 0 will reduce the weight of an item, however this is very difficult when you start having multiple weights.

One additional problem is that if you have a serious amount of records, using ORDER BY RAND() is going to be a performance hit.

One of my recent projects was using Smarty - I found myself in a position where I needed to access a variable assigned to a Smarty template directly - I could not access it before/while it was being assigned and Smarty doesn’t provide enough resources to interact with it directly before it’s actually transferred to the template. Smarty does allow you to edit other variables by using the global command in php, but not those that have already been assigned.

What did I end up doing? I just accessed the Smarty template object itself.

[php]$this->_tpl_vars['name_of_template_var_here'];[/php]

I had to perform some fairly fancy tests on that data. Then, if you want modify that data you can just save it back to the above variable or re-assign it:

[php]$this->Assign(”name_of_template_var_here”, $new_value_here);[/php]

I was setting up an installation of subversion for a client (and I will be for myself soon here - it’s about time to move from CVS) and I needed to enable it to send an email to folks each time a commit was made. This tidbit assumes that you’ve already installed SVN on a linux machine.

First, you need to visit your hooks dir (created when you create a new repository (which is done using svnadmin)).

# cd /path/to/repo/hooks

You need to download a copy of the commit email perl script, which you can get from here.

# wget http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/commit-email.pl.in

Then, rename it to .pl. You’ll need to rename the special file that SVN uses to activate the email. This file is post-commit.tmpl and you’ll need to rename it to post-commit.

# mv commit-email.pl.in commit-email.pl
# cp post-commit.tmpl post-commit


Next you need to edit the post-commit file so that it sends your email out. At the bottom of the file, add the following:

/path/to/repo/hooks/commit-email.pl "$REPOS" "$REV" --from svn@example.com "me@example.com" "you@example.com"

Then just save the file. Now you’re ready to test. You can either make a commit or run the below command. First call the post-commit, then provide the path to a repository to watch, then provide the revision number you want to run a test on. If you’ve just imported code and don’t have any other revisions, just provide the number 1 - but beware the possibility of a really long email.

# ./post-commit /path/to/repo 40

Things should be working fine by this point, but I ran into a problem. I saw the error message Global symbol "@SVN_BINDIR" requires explicit package. In that case, just go into the commit-email and change the @SVN_BINDIR variable on line 46 to the full path of svnlook.