Testing this compression can be a little tricky, because often clients handle it so seamlessly you may not know it ever happens. Additionally, server configuration may further complicate testing, compressing data for some requests and not others, i.e. Nginx's gzip_http_version directive, which may only serve compressed data for HTTP 1.1 requests.

Curl provides a simple tool for checking server responses.

First, a few curl arguments that will come in handy:

• "--silent" prevents curl from showing progress meter
• "--write-out 'size_download=%{size_download}\n'" instructs curl to print out the download size
• "--output" instructs curl to throw away the output, sending it to /dev/null

Using these arguments, we can make a simple request for a path on the server:

ns:~ nick$ curl http://example.com/Service?wsdl --silent --write-out "size_download=%{size_download}\n" --output /dev/null
size_download=31032

Here, you can the response was 31032 bytes. Next up, lets make the same request, this time adding the Accept-Encoding header to ask for compressed content.

ns:~ nick$ curl http://example.com/Service?wsdl --silent -H "Accept-Encoding: gzip,deflate" --write-out "size_download=%{size_download}\n" --output /dev/null
size_download=2553

Nice! This downloaded only 2553 bytes of data, so it the data is definitely being compressed. Up next, lets try making the request a third time, now making the request a HTTP1.0 request.

ns:~ nick$ curl http://example.com/Service?wsdl --silent --http1.0 -H "Accept-Encoding: gzip,deflate" --write-out "size_download=%{size_download}\n" --output /dev/null
size_download=31032

This response was not request, which makes sense when using Nginx with the gzip_http_version set to '1.1'. Additionally, this method can easily be applied to POST requests if you add the appropriate arguments to curl.

References:

• Nginx Http Gzip Module
• Apache mod_deflate
• Mod Deflate example/logging
• Curl homepage
• Curl man page

Going with the Flow

Despite my feelings that the title Dr. should be strictly reserved for those that save lives, Dr. Nic Williams does have plenty of good advice to offer (and he offers it in a nice format on his website). After having made some of the same mistakes and asked the same questions he has, I decided to try out the new and improved open-source project workflow. There are several things to be achieved from these open-source projects:

• Have fun
• Learn something new
• Share code

There are also some thing that should be avoided, less favorable outcomes:

• Write code, but don't go the full 9 yards to distribute + share it
• Spend too much time on setup/distribution
• Tie yourself down with maintaining your projects (they should set you freeeeee!)

Two great presentations can help you achieve these goals, and avoid the pitfalls. The first is a a great presentation about what an open-source project should be, what it shouldn't be, and how they can make your life better, not worse.

The next presentation is about how to quickly and effectively distribute and share your projects.

In order to get this all down, the good Dr. describes a workflow and a set of tools for each step.

• Packaging - RubyGems
• SCM - GitHub
• Continuous Integration - RunCodeRun
• Blog/Resume Integration - RunCodeRun Sexy Blog Badge

The Project

I decided to write a little ruby wrapper for the 'ddate' command, part of the 'util-linux-ng' package, that convert Georgian dates to Discordian dates. Why? Because I like it, and if you are going to pick a project to learn on, it might as well be ridiculous. I got attached enough as it was to this project, even though I don't think anybody could come up with an excuse to use Discordian dates, let alone happen to be using ruby.

Snafoos

One thing that started to bug my is the gem, class, module, and github repository names. It seems simple enough, but sometimes you are so excited to get you idea down in code that you rush through this first step. It will be around for a while, and is kind of a pain to change once you get it all set up. So take a few minutes and think about a name. One without WeIRd caps or anything that might annoy you in the future.

I also found newgem to be a little wonky. It a nice tool to have around, but I think (rightly so) it is tailored to Dr. Nic's workflows, and might not work for everybody.

Lastly, I found myself wresting with Hoe. The 'rake pacakge' task was failing if I added the Hoe require statement, and runcoderun was failing without the statement. That brings me to a little tangent. I didn't really dig into what was going on there, but this is an example of something that is unexpectedly not idempotent; you should be able to require and require and require, then run some code and everything should be fine and dandy. I'm not sure how or why requiring Hoe (when it is clearly used, anyway) would break anything, and it almost annoys me enough to find out. Almost.

Good stuff

I like RunCodeRun. It is simple continuous integration that makes sense. I also like the blog badge, although it currently looks horrible on my blog.

Stuff I'll add

Speaking of blog badges, I want to see if I can get the github projects blog badge working. Associating myself with a project is another step for creating a fully-rounded project. This badge helps integrate that step right into the existing workflow.

For learning projects, I plan on adding some non-standard notes to the README, including sections about what I learned and what would have done differently. Open source the code, and open source the learning process. Its not like I have any customers to scare away with honest comments.

As Nic Williams said, "Don't attach your self-worth to your code - your code probably isn't that good." Its true. I am a better software developer than I am a coder, and I aim to be. You can write code quite a few different ways and it all compiles down to the same thing. To me, nailing the workflow and the tools is the hard part, and the part that deserves the most attention.

Working with software, your code will always improve and you will keep learning new tricks. But too many people let their workflow and tool-set become stagnant, which can leave you further behind than knowing a few extra tricks in this language or that one.

[nick@Dev1 ~]$ sudo gem install mysql
Password:
Building native extensions.  This could take a while...
ERROR:  Error installing mysql:
	ERROR: Failed to build gem native extension.

/usr/bin/ruby extconf.rb
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... no
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/usr/bin/ruby
	--with-mysql-config
	--without-mysql-config
	--with-mysql-dir
	--without-mysql-dir
	--with-mysql-include
	--without-mysql-include=${mysql-dir}/include
	--with-mysql-lib
	--without-mysql-lib=${mysql-dir}/lib
	--with-mysqlclientlib
	--without-mysqlclientlib
	--with-mlib
	--without-mlib
	--with-mysqlclientlib
	--without-mysqlclientlib
	--with-zlib
	--without-zlib
	--with-mysqlclientlib
	--without-mysqlclientlib
	--with-socketlib
	--without-socketlib
	--with-mysqlclientlib
	--without-mysqlclientlib
	--with-nsllib
	--without-nsllib
	--with-mysqlclientlib
	--without-mysqlclientlib

Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out

Yikes! Look familiar? Bummer. First step, brute force install everything I could think might be missing

sudo yum install gcc mysql-server mysql-devel ruby ruby-devel

Turns out, the gcc was having some issues:

[nick@Dev1 mysql-2.7]$ sudo yum install gcc
Loading "rhnplugin" plugin
Loading "security" plugin
intensive-rhel-i386-serve 100% |=========================| 1.2 kB    00:00
rackspace-int-rhel-i386-s 100% |=========================| 1.2 kB    00:00
Excluding Packages in global exclude list
Finished
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package gcc.i386 0:4.1.2-42.el5 set to be updated
--> Processing Dependency: libgomp = 4.1.2-42.el5 for package: gcc
--> Processing Dependency: cpp = 4.1.2-42.el5 for package: gcc
--> Processing Dependency: libgomp.so.1 for package: gcc
--> Processing Dependency: glibc-devel >= 2.2.90-12 for package: gcc
--> Running transaction check
---> Package cpp.i386 0:4.1.2-42.el5 set to be updated
---> Package glibc-devel.i386 0:2.5-24.el5_2.2 set to be updated
--> Processing Dependency: glibc-headers = 2.5-24.el5_2.2 for package: glibc-devel
--> Processing Dependency: glibc-headers for package: glibc-devel
---> Package libgomp.i386 0:4.1.2-42.el5 set to be updated
--> Running transaction check
---> Package glibc-headers.i386 0:2.5-24.el5_2.2 set to be updated
--> Processing Dependency: kernel-headers >= 2.2.1 for package: glibc-headers
--> Processing Dependency: kernel-headers for package: glibc-headers
--> Finished Dependency Resolution
Error: Missing Dependency: kernel-headers is needed by package glibc-headers
Error: Missing Dependency: kernel-headers >= 2.2.1 is needed by package glibc-headers

Googling around a little, I found this helpful page which indicated that the default RHEL yum configuration excludes updates from the kernel. That is probably good practice in general, but right now it is preventing us from doing what "needs to be done."

Looking at my /etc/yum.conf file, indeed the kernal was excepted from updates:

[nick@Dev1 ~]$ cat /etc/yum.conf
[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1

# Note: yum-RHN-plugin doesn't honor this.
metadata_expire=1h

# Default.
# installonly_limit = 3

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
exclude=kernel*

So I commented out that line, yum installed gcc, and then off to the races. My googling also noted that passing the --with-mysql-config saves you some trouble, essentially letting it configure itself.

[nick@Dev1 ~]$ sudo gem install mysql -- --with-mysql-config=/usr/bin/mysql_config
Building native extensions.  This could take a while...
Successfully installed mysql-2.7
1 gem installed

Just in case, you might want to uncomment the kernal extension from your /etc/yum.conf file!

Anyway, hats off to Joey, with his simple instructions about a RHEL 5 SMTP server in Linux Gazette.

Here are a few things that might help. Before you get started with Joey's instructions, run

sudo yum install sendmail-cf
export PATH="$PATH:/sbin:/usr/sbin"

Additionally, the auth system goes off your linux users, so just add a user and give it a password if you want to authenticate.

Firstly, the ability to add arguments was added somewhere along the line, so you might as well make sure you have a recent version of Rake:

nicks-computer:~ nick$ sudo gem install rake
Password:
Successfully installed rake-0.8.3
1 gem installed
Installing ri documentation for rake-0.8.3...
Installing RDoc documentation for rake-0.8.3...

Great. Now, lets dig in to an example rake file. You can put this in a file name 'Rakefile' anywhere you like, or in RAILS_ROOT/lib/tasks/some_file.rake if you are rails-ish.

desc "An example task that uses a single argument"
task :example_with_argument, :arg1 do |t, args|
  puts "Running 'example_with_argument' with '#{args.arg1}' as the argument"
end

desc "An example task that uses multiple arguments"
task :example_with_multiple_arguments, :arg1, :arg2 do |t, args|
  puts "Running 'example_with_argument' with '#{args.arg1}' and '#{args.arg2}' as the arguments"
end

desc "An example task that uses multiple arguments, and has defaults"
task :example_with_multiple_arguments_and_defaults, :arg1, :arg2 do |t, args|
  args.with_defaults(:arg1 => 'default_arg1', :arg2 => 'default_arg2')
  puts "Running 'example_with_argument' with '#{args.arg1}' and '#{args.arg2}' as the arguments"
end

Now, for how to run them. Without specifying arguments, the defaults (or an empty string if no defaults are specified) will be used:

nicks-computer:~ nick$ rake example_with_multiple_arguments_and_defaults
(in /Users/nick)
Running 'example_with_argument' with 'default_arg1' and 'default_arg2' as the arguments

nicks-computer:~ nick$ rake example_with_multiple_arguments_and_defaults[myarg1, myarg2]
(in /Users/nick)
Running 'example_with_argument' with 'myarg1' and 'myarg2' as the arguments

TaDa!

UPDATE:

Rake a a great tool, and widely used, but there are some new tools that surpass rake in some areas. For example check out Thor and how OpsCode uses it with their Knife tool.

checking for SSL/TLS toolkit base... none
checking for OpenSSL version... checking openssl/opensslv.h usability... no
checking openssl/opensslv.h presence... no
checking for openssl/opensslv.h... no
checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no
no OpenSSL headers found
checking for SSL-C version... checking sslc.h usability... no
checking sslc.h presence... no
checking for sslc.h... no
no SSL-C headers found
configure: error: ...No recognized SSL/TLS toolkit detected

Simple fix, thanks to YUM.

sudo yum install openssl-devel

FYI, if you're not on RHEL 5, you could try

apt-get install openssl libssl-dev

OS X comes with a to-the-point but not terribly inspiring "Welcome to Darwin!" Spice that up a little.

Note that in addition to a message, maybe a little ascii dude is all you need.

            (peace out)
    _     _  /
  o' \,=./ `o
    (o o)
ooO--(_)--Ooo