This is fairly straight forward.  Download and install Visual SourceSafe 2005 on the server designated as the version control server.  VSS 2005 doesn’t need to setup an actual db system, like SQL Server.  Follow the installation wizard and choose “New Database”, unless you need to connect to an existing VSS database, which is actually just an indexed directory tree with flat file data files.  Make sure the directory path set as the VSS “database” is accessible by all necessary users.  If the directory is a network share drive, make sure to explicitly remove “everyone” as a user permission option on the folder, so only VSS named account users can access the VSS database directory.  Also, once installation is complete, create any necessary user accounts.  Don’t just use one admin account!

On the developer/client machine, install VSS 2005 in pretty much the same way, except select the database option to connect to an existing VSS database and browse to the VSS directory.  After installation, test trying to connect and logging in using a newly created user account.  Now from the development environment, you should be able to “check in” an initial trunk codebase.  Have fun!

 

This awesome one-liner will search all of the files, matching the “-name” or “-type f” criteria, then use sed to do a global inline search and replace.

find . -name “*.php” -print | xargs sed -i ‘s/172.16.0.22/ors3.scrra.net/g’ {} \;

The company website runs on a Apache/PHP environment but uses Oracle as the backend database.  The site ran fine, pulling most of the content from Oracle.  Unfortunately, all of the database connections were embedded throughout every page using the OCILOGON function to connect.  The database hose parameter was listed as a hard-coded IP address (I didn’t do this, but inherited it from previous party).  PHP’s OCI8::OCILOGON accepts an IP address as the “hostname” and then a full domain name for the SID of the Oracle database, like this “OCILOGON(‘username’,'password’,'http://74.125.235.16/webdatabase.domain.com’).  So far, this seems OK, although not pretty nor ideal.

Then for some reason, if the “hostname” of the database server is changed from an IP format to using the server’s domain, such as “oracleDB.company.com”, then you will receive an Oracle error (ORA-12541).  The SID must be changed to just the Oracle DB’s listener service name, without the full domain, so just “webdatabase” instead of the previous “webdatabase.domain.com”.

I’m not sure why this requirement changes in the “hostname/SID” parameter, but it does and I found it out the hard way.

I discovered this the hard way, but when setting up virtual hosts in Apache 2.2.x and the virtually hosted site performs URL rewrite using the “mod_rewrite” Apache module, which is required for any MVC application or any site utilizing .htaccess rewrite conditions and rules.  According to Apache’s documentation, it is recommended to always use virtual hosts, even if a web server is only hosting 1 site.  It does make the setup and configuration more portable for the future.

Anyway, the scenario was I needed to setup up a virtual host on a server, which would reside in a subdirectory of the main web root.  I had previously set up a site in the main web root directory, which did not use .htaccess files, although the “mod_rewrite” Apache module was installed and enabled.  I followed Apache’s documentation about setting up a virtual host config file for the default site, which is the site in the web root.  In the “vhosts.conf”, virtual host config file, I set the <Directory> tag to point to the web root, “/srv/www/htdocs” in my case.  I also set the “Options” directive to “Indexes FollowSymLinks”, (FollowSymLinks is required for URL rewriting).  Then I also set the “AllowOverride” directive to “All”, which is also required for using any functions in an .htaccess file.

According to Apache’s documentation, the <Directory> settings affect the current directory as well as all of the subdirectories.  So I continued to setup a 2nd “<VirtualHost>” tag for the MVC site I uploaded to a subdirectory from the web root.  I set the “<Directory>” tag to point to the proper local subdirectory, “/srv/www/htdocs/subdirectory”.  I assumed the <Directory> options would trickle down and my MVC site would function properly.  (Of course not, that would be too easy!)  Anyway, after hours of scouring Google and coming up with nothing but copies of the same tutorials, I tried adding “<Directory>” tag and local directives for “Options” and “AllowOverride” for the 2nd <VirtualHost> settings and it finally worked.

I’m sure system admins around the world know this, but I’m not a system admin, but have to do these tasks, because no one else will do them.  Anyway, for any others, including myself, when setting up <VirtualHost> in Apache, each virtually hosted site must have its own local settings and directives, even though, the sites are sitting in subdirectories and should inherit the settings for the parent directory, but that is not the case with virtual hosted sites.

    Recently, I was given a Excel/CSV file with 1000s of database record IDs, that I needed to do a mass update on.  My goal was to copy and paste the record IDs into a SQL statment, but I didn’t want to manually add commas after each ID to format the syntax.  Converting an Excel file to CSV doesn’t add commas at the end of each line.  In order to easily copy and paste into my SQL builder client, I needed to prep the file first.

    I first exported the Excel file as a CSV file, then just renamed the file extension to .TXT.  Uploaded the new text file from my Windows workstation to a Linux server, where I could use more robust shell scripts.  I then removed the header row, just to have a text file with a record ID on each line ended with just an \n end of line character.  Then I executed the magic that is “sed”.

>sed -i ”’s/$/,/’ filename

     The “-i” flag means to change the file “in place”, meaning the source and destination file are the same.  Otherwise, the output will go to standard out, which is good to first test.  The first “s” is to substitute, the “$” means end of line in this context, the 3rd parameter, “,” was in my case what I needed to append to the end of each line.  Then finally specify the filename of the file to be updated.  For generic cases, the “$” can be replaced with a regular expression and the “,” can be replaced with whatever text you want to add to the end of the matched expression.

According to the Zend Framework 1.9.x documentation, when using the Zend_Application to load a config file, you can specify which section of the config file, such as either “production” or “development”.  Then when loading the config file, assuming it’s properly formatted, will load the desired configuration section within the designated config file. 

For example, if you list your “production” settings at the top of the config file, then list your “development” settings as “[development : production]” which is just like all the examples, then when instantiating the Zend_Application object providing the path to the config file and which setting to load, the LAST config setting listed in your config file will be loaded, regardless of your parameter.

This is an undocumented bug in at least Zend Framework 1.9.8, but I haven’t tested it in later versions, like 1.10.x.  So no matter what parameter you specify when invoking the Zend_Application object, the actual loaded configuration settings will be whatever the last section is.  The last config settings section will override any previous settings, even if you do not choose to load that section.  A solution to this is to maintain separate configuration files, one for production, one for test, one for development.  I know this defeats the whole purpose of the use of Zend_Config and formatting the application’s config file according to the Zend Framework’s requirement, but this is why it’s a bug and deserves to be fixed.

I spent weeks trying to find the root cause and not to mention halting a production application causing minor hysteria.  I just tried “what if I do this…” to see if it would have any effect and that’s how I discovered the root problem.