Rain City Consulting

I've decided to use Ivy (http://ant.apache.org/ivy) in my projects instead of checking my dependency jars into source control.

My goals are as follows:
* Don't check in jars
* Allow multiple developers to work
* Snapshot versions for intra-module development (e.g. if I have a common jar, I want to be able to get the latest snapshot in my web project)
* Fast - I don't want this to slow me down

I use these tools every once-in-a-while, which puts them in the category of "I know what they do and kind of how to use them, but I always have to spend time reading the man pages and searching the Internet for usage instructions".* So, here are instructions for me.

Here's my situation. I have a codebase on my localhost. I have a copy of that codebase that I edited while at a client. I need to merge the two codebases. The general idea is that I need to create a patch file by diff'ing the two codebases and apply it to my localhost codebase. This should be straightforward...

I usually start with the base Canonical EC2 AMI. I just installed ami-ab15f6c2 (listed here: http://alestic.com), ran

$ apt-get update
$ apt-get upgrade

Then listed all packages

$ dpkg --get-selections

And here's what we have:

adduser
apparmor
apparmor-utils
apport
apport-symptoms
apt
apt-transport-https
apt-utils
aptitude
at
base-files
base-passwd
bash
bash-completion
bind9-host
bsdmainutils
bsdutils
busybox-initramfs
byobu
bzip2
ca-certificates
command-not-found
command-not-found-data
console-setup

I've had a hard time finding this data in one place, so here it is. "It" being a listing of EC2 types, names to use with the command line tools, and prices.

Of course, it is not possible to simply flip a switch in MySQL and turn off all triggers (lame). There is an ACTION_CONDITION column in the information_schema.TRIGGERS table, so I would not be surprised to see something like this in the future. In any event, here's my work-around:

1) Dump all triggers to file
2) Drop all triggers
3) Do what you need to do without triggers
4) Add triggers back in using file created in step 1)

Step 1) is difficult because there is no MySQL tool or mysqldump option to just get the triggers. So we get to use diff and some other command line tools:

About every 6 months, I have a need to understand fstab (/etc/fstab). It's one of those times, so here's what I am learning:

* fstab is read by programs; it is never written by programs
* Each filesystem on the localhost is described in a line in fstab
* Columns are separated by TABs or spaces
* The first column identifies the filesystem by specifying its device node (e.g. /dev/sda1). One can also specify a filesystem by using its UUID or label (this is good for removable media).
* The second field is the mount point for the filesystem

I'm going to be launching a site that will be running in on EC2 using Relational Data Service (RDS). This post is my notes for setting up this site.

I'm starting with a fresh account, so I went to http://aws.amazon.com and signed up for EC2, CloudFront, S3, and RDS. I think that's all I'll need.

I need to create a security group so I can log in to my EC2 instance:

$ ec2-add-group ssh -d'Port 22'
$ ec2-authorize ssh -Ptcp -p22
$ ec2-add-group http -d'Port 80'
$ ec2-authorize http -Ptcp -p80
$ ec2-add-group sg -d'Soundgarden'

I maintain a large (~20G) MySQL InnoDB database. This database is currently replicated to a single MySQL instance. I need to replicate this database to another MySQL instance. To do this, I must

1) Get a snapshot of the data
2) Get the binary log position of the data snapshot
3) Load the data snapshot in the MySQL instance
4) Configure and run the slave MySQL instance

Get a Snapshot of the Data

I want to build a horizontally scaled, highly available, fault tolerant web application. I have an application that is all of these, to a certain degree. The main thing that's holding it back from completely satisfying these requirements is the fact that sessions are stored locally, so when a node goes down (crash or deployment), the session is lost. A typical solution for this problem is to store the sessions in a database. This is great, but adds considerable load on the database (constantly reading and writing sessions) - not good if you want to keep your application snappy.

I have a fairly large data/user-driven web application written in Java (using a lot of the Spring Framework). You can see this site on http://cfreference.net. Today, I'm planning on migrating this to Scala.