14 October 2007

Ruby see, Ruby do!

Was reading some books and after a few discussions with a friend of mine, Greg, who's the boss of EyeTools and a Ruby fan. For a database-centric guy, this is one heck of an eye-opener: migrations, a Ruby on Rails tool (or a gem), that helps you manage your database through classes, no SQL Queries to write at all! Note, Ruby is a language, and Ruby on Rails is an entire framework that consists of ready-built classes that you rarely need to poke around with that rides on top of Ruby.

I won't go to much details on how to get going on using Ruby on Rails or setting up a database as there's well written documentations only a "Google" away.

Migrations is something a non-SQL programmer could potentially use to add columns, primary keys, etc to your tables. It can even be effective for guys in other langauges like C#, C++, VB.NET, etc... let me show you some code examples -- yeah, some of the Ruby on Rails code syntax may throw you off -- looks too easy!

Let's create a table:


class AddClientTable < ActiveRecord::Migration
def self.up
create_table :clients do |table|
table.column :name, :string
table.column :address, :string, :null => false
table.column :city, :string, :limit => 32, :null => false
table.column :email, :string
end
end

def self.down
drop_table :clients
end
end

The self.up stuff is obviously the new stuff, and the self.down stuff is in case you need to backtrack from the changes you're making. Point is.. using migrations, all changes are self-documenting and easy to revert back. Excellent for DBAs with OCD.

Notice there's no ID field? Well, Ruby on Rails Migrations automatically adds it for you and sets the increment to 1. If you don't want an ID field, just replace the above crate table line to:
create_table :clients, :id => false do |table|

The possibilities are endless! unique constraints, text columns, varchar, char, foreign keys, default values, etc, etc... there are some limitations where you'll have to write up straight-up SQL like numeric(8,4) or whatever... but that SQL can be embedded in the class tho' so it still retains that self-documentation.

All in all, an awesome tool for the budding DBA.

08 October 2007

Building exe/dlls into a zip file

Right now, I'm working for a client out in San Francisco -- yup, left my heart in SF. Anyhow, this client, after providing them the install package consisting of .NET 2.0 Framework, Crystal Reports, the build's EXE & DLL(s), any third-party DLLs, etc...

Well, there's always enhancements and bug fixes that needs to be done. Why should I send my client a HUGE install package that they would have to go uninstall/install on a daily basis? Why not just quickly overwrite their existing EXEs and DLLs? Usually, I include a SQL Script, Word doc with notes, and the EXE/DLLs. That wasn't a problem if I have only one exe, but as the project grew, we now have a total of 7 DLLs.

I was looking for a solution to package the entire build of the project into one folder and automatically zip them all up and then I'll just attach the zip file to my daily emails to my client. See, I'm lazy.

Came across Visual Studio 2005 post-build event command dialog. If you have VS 2005, go to the solution's StartUp project, right-click, Properties, Build Events -- you'll see there's a textbox under the "Post-build event command line:" -- this'll be where you can type out the path to your .bat file.

Perfect...step one out of the way. Using a .bat file that I can have executed after Visual Studio completes the build, I can move files from my bin/Debug (or bin/Release) folder over to a My Document folder that I set up for the client. Easy 'nuf. However, I don't want to move files around every day -- human error can creep in. See, I'm still lazy.

Besides, most email programs balk at sending/receiving EXEs and DLLs, especially Outlook, therefore I cannot send it as is. I would need to compress them into a zip file. I cannot imagine doing that manual work EVERY single day, perhaps twice a day. Now, let's look for a zip program that you can run off using the command-line or a .bat file. Amazingly Windows XP doesn't have a built-in command-line zip program, you have to use the UI to unzip/zip the files.

Lo and behold! I found a solution: 7-zip -- http://www.7-zip.org/ -- downloaded and installed it. Pretty much self-explanatory.

Now, the tough part -- piecing them all together.

Let's create a new plain ol' text file via Notepad consisting of all the files you want zipped.

BuildFiles.txt:

Program1.exe
ProgramAdmin.dll
ProgramConnection.dll
ProgramControls.dll
ProgramData.dll
ProgramReports.dll
ProgramShared.dll
MyGeneration.dOOdads_2005.dll

8 lines in that text file. Saved it as BuildFiles.txt, and put it in my bin/Debug folder. Next, let's create the .bat file zipping all those EXE and DLLs into one neat and tidy package.

Let's see... created a file aptly named zip-em.bat, and also put it in the bin/Debug folder:
"C:\Program Files\7-Zip\7z" u -tzip "C:\Documents and Settings\rob\My Documents\Clients\Program1\6.0\ProgramZipped.zip" @"C:\Documents and Settings\rob\My Documents\Visual Studio 2005\Projects\Program1\Program1\bin\Debug\BuildFiles.txt"

All in one line, quoted, and see the end of that command line -- the know-it-all BuildFiles.txt.

Now... it'll run the zip-em.bat file AFTER the project compiles and builds all those EXE & DLLs. Here's the text that's from the screenshot:
call "C:\Documents and Settings\rob\My Documents\Visual Studio 2005\Projects\Program1\Program1\bin\Debug\zip-em.bat

See! Easier said than done, or was it perhaps the other way around? :-) If you got a way to increase my productivity or ways of making me more lazy, please add a comment.