Friday, June 26, 2015

McAfee's Knob @ Cawtaba VA - Overnight Hammock Camping

My good 'ol buddy Kevin came for a weekend visit from Chicago last weekend. When I asked him what it was he wanted to do he had one thing to say:

"Get me up on a mountain, man!"

Not being one to argue, we made plans to take a two day sojourn along the Black Mountain Crest Trail. Unfortunately, poor planning and some bad weather put the kibosh on that trip, and lost us one of the two nights we were planning on spending out in the woods. I wasn't about to let Kevin go home without the experience he came down for, so I began to brainstorm some alternate plans. I remembered the day hike up to Dragon's Tooth near Roanoke, VA that I had taken the summer before and I had really wanted to see more of that section of the AT. So I suggested we head back up that way and hike around McAfee's Knob. The drive up there was short enough that we could do just one night and get back in time for Kevin to make is Monday evening flight to Chicago, so off we went.

We left the house at 6am sharp Sunday morning. After stopping for some delish biscuits and gravy, and spending 30 minutes trying to find the right trail head, we were at the AT parking lot ready to set sail by 10:45

The first mile or so was just a straight shot up the mountain. We were feeling like a couple of fat dudes...

Starting feeling a little better once we could see some view off this beautiful mountain.(Though that feeling went away when Kevin sprained his ankle.. he toughed it out).

After three hours of hiking, we made it up to McAfee's Knob, the most photographed spot on the Appalachian Trail... for obvious reasons.

After hanging out on the Knob for 30 minutes or so and taking a ton of pictures, we started our hike down the other side to our camp site. For whatever stupid reason, I forgot to take any pictures of our campsite. Maybe Kevin has some.

I did get a shot of the camp fire.

The next morning we had to hustle on back to the car and get kevin back to the airport, so we left in some haste. Kevin, being hobbled from the day before, took off before me to get a head start. He may or may not have gotten lost on the trail at one point... perhaps we'll never know.

Did stop to take one last picture of the Knob on the way back.

I found Kevin, and we made it back to the car.

Post hike catfish breakfast!

Even the drive back was a lot of fun. Any time Kevin and I are together we get into some serious harmonizing. Also stopped at Baldwin Farms and picked up some good meat.

Monday, September 23, 2013

New House

I've had an offer accepted on a house in West Raleigh. Pending inspections, etc., will be closing on Oct 30. Pretty Exciting!!!

Monday, January 14, 2013

Managing Web Projects with Mercurial

A walk through of using mercurial for web application deployments

Many times I work on websites or web software projects where content management is not an option. Even when it is an option, I find myself wanting to maintain multiple copies of the site - one (or more) for testing plus a production site. Trying to maintain and keep track of these copies using FTP has many times left me confused, frustrated and often ends with me throwing my mouse across the room and then re-writing lots of code.
Enter Mercurial, an open source, cross-platform source control system which has made this task much easier for me. The good thing about using Mercurial to maintain a website is that once you get set up, IT WORKS! The downside is that, at least for me, it can be very confusing trying to figure out how to set it up. It took me four tries, lots of "Googling", posting to mailing lists, and a bit of trial and error before I was able to get my website updating the way that I wanted it to.
Since I don't want anyone to have to go through the same trouble that I went through I am going to try and shed a little light on how, from my understanding, Mercurial operates and how you can take what I did and adapt it to your own web project. This will just be a very basic setup to get you started, and I'm not going to explain anything that's not absolutely necessary.
For those of you who have worked with version control software such as CVS or Subversion, like I have, the first thing you need to forget is the traditional server-client relationship between a remote repository and the various local copies that are committing changes to the server. Mercurial is a single piece of software that can act as both a client or a server or both depending on how you use it. In other words, you install the same component on your local machine as you would on your web server. This allows you to theoretically set up a chain of "stages" on which to test your project. Your local machine could push changes to an alpha site, which could then push to a beta site, which would push to production and each process would be exactly the same other than the host address and file path (if you wanted to you could even push in reverse!).
Ok let's get started. Firstly here is a list of requirements/assumptions of things you need or should have set up in order to follow this tutorial.
  • Linux-based Web server to which you have SSH access and has Mercurial (hg) installed. To see how to install mercurial, check out the project site:
  • Local machine with any linux flavor. While Mercurial is available in all platforms and the process is fairly similar, I will be showing you using Linux, specifically Ubuntu.
  • Mercurial installed on your local machine. For Ubuntu users can install it using the package manager:
  • # sudo apt-get install mercurial
    Alternatively any Linux user who has the python-dev and python-setuptools installed can install mercurial using:
    # sudo easy_install -U mercurial
    Visit the mercurial project site for source downloads and other installation alternatives.
The first thing we need to do is to set up a directory on our web server for our new project. Open up a terminal window and log into your web server via Secure Shell. Enter your password when prompted.
# ssh
Change directories into the web root of your server.
# cd ./public_html
Create a directory for your web project and move into that directory. I will name it my_project.
# mkdir my_project
# cd my_project
Ok, now its time to create the repository in your new project directory.
# hg init
The hg command refers to Mercurial's executable file, named "hg" after the chemical symbol for mercury. Calling hg init creates a hidden directory called .hg in your my_project directory. This is where Mercurial will store all of the changes to your repository. To verify that this worked, just type ls -a to display all files (including hidden files). The output should look like this:
# ls -a
.  ..  .hg
Now logout of your web server by issuing an exit or logout command. You should now be back in your local terminal. Create a directory on your machine for your local project.
# mkdir ~/workspace/my_project
Create a local repository in your my_project directory the same way we did on the server.
# cd my_project
# hg init
# ls -a
.  ..  .hg
While I work on my web project, there will be certain files that are created in my project directory that I do not want to be pushed to the server. This includes temporary files and configuration files that are specific to my local environment and could potentially cause problems if they are pushed to the production site. Luckily, Mercurial allows us to create a file that allows us to define files that we would like to have ignored by the repository. This file is called .hgignore and goes in the main project directory, not the .hg directory. My .hgignore file looks like this:
# less ~/workspace/my_project/.hgignore
syntax: glob
It is now time to create a basic website. I made four files and a subdirectory - index.html, bio.html, contact.html, and css/main.css.
Once I have a site to manage, I need to run the add command which will search the main directory and all subdirectories and add all files not specified in my .hgignore file. Running hg add will flag the files that will be tracked by the repository and output a list of all included files. Mine looks like this:
# hg add
adding .hgignore
adding bio.html
adding contact.html
adding css/main.css
adding index.html
Now the files are flagged to be tracked. However, the repository will not contain the most current version of the tracked files until they are committed. This is done using the hg commit command. The commit command also allows you to specify filenames. The -m flag specifies the commit message.
# hg commit -m "Initial Commit" (to leave comment blank, hg commit -m "")
Ok, the files are now current in the local repository. Time to push the changes to the server. The hg push command takes the ssh server address as its argument. You will be prompted for your password and hg will output something similar to this:
# hg push ssh://username@myserver.tld/public_html/my_project
username@myserver.tld's password:
pushing to ssh://username@myserver.tld/public_html/my_project
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 5 changes to 5 files
You may optionally want to view a record of changes made in your repository. To do this enter hg log. This will display the user, date, and commit message of each repository event.
The hg update command looks for recent changes in the repository and updates the files in the main directory. If you open your project space in a browser you'll notice that nothing has been published yet. Running hg update will get the changes from the remote repository and copy them to the main project directory.
# ssh username@myserver.tld
# cd public_html/my_project
# hg update
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
Now if you go back and refresh your browser, your project will be live.

Tuesday, September 4, 2012

Labor Day Camping in South Haven, MI

Took the new bike on its first long trip to South Haven, MI for some Labor Day camping. Total round trip mileage: 260. Total time on the bike: 20 hours.

Click for more Photos

Thursday, August 30, 2012

What I've been up to for the past two weeks... Bike Build

I decided earlier this summer that I was in need of a bicycle upgrade. My Motobecane Mirage circa 1975 road bike, which was purchased from a used bike shop in town, had been a smart investment and still works great for getting around town, but after a broken pedal, bent chain ring, and several flats during weekend trips, I realized the time had come for a ride the better suited my needs. I also decided that since I enjoy doing long, unsupported overnight trips it was time for me to better understand bicycle components and maintenance. What better way to do that than to build this new bike myself? So I set out to do some research.

After looking at over a dozen frames I finally settled on a Soma Double Cross. Why, you ask?

  • I often carry load on by bike for long rides, but I wouldn't consider what I do most to be loaded touring (carrying 80+ pounds cross country for months at a time). Generally the weight is less than 40 pounds, and I wanted something that was build with a more aggressive, speedy geometry than something like the Soma Saga or the Surly Long Haul Trucker. The Double Cross fit the geometry I wanted, being build for an aggressive posture but with a bit more length in the chainstays so that bags don't interfere with feet.
  • The double cross is a cyclo-cross frame, meaning that it is build for racing, but unlike road racing, must be able to handle off-road riding. As such, these bikes must be just as sturdy as they are fast.
  • As I do carry some weight basically all the time, I am not concerned with the frame or components being ultralight. The Double Cross is a steel frame with a bit more weight to it than an average road frame, which will help to control weight on the back as I ride.
Double Cross frame and fork in stand
The process of building up from parts was a long one. Some of the parts took weeks to come in, other orders came in with the wrong parts. I began the research process in mid June, and did my first ride during the last weekend in August.

In addition to assembling the bike, I also built the wheels myself. Hand built wheels are far superior to wheels build by machine, as machined wheels are trued by spoke tension measurements and do not accommodate for variances in rim or spoke construction. Learning to build wheels was a slow process at first (I think I put 6 hours into my first one!), but I learned a great deal about how and why the bicycle wheel works the way it does which will prove very useful while out on the road.

Soon-to-be bicycle wheels

After many late nights over several weeks, I took my new ride out on its first real test last Friday, riding 85 miles to Bourbonnais, Illinois where my family was helping my sister move in to college. The ride was insanely hot and very uncomfortable, as the Soma (new bike) is set up very differently from my Mirage (old bike), but the bike itself held up very well. I had to stop a few times to adjust the breaks, as the new cabling was still stretching and settling, but beyond that all components performed very well. I am riding out again tomorrow on a 130 mile journey from Chicago to South Haven, MI for some labor day weekend camping. Hopefully all goes well!

Monday, July 16, 2012

Brew Day - Australian IPA

It was a sweltering 90 degrees on this particular Sunday, so we decided to do what any old Chicagoan does to beat the heat... brew a beer. Shane took a trip over to the local home brew store, and was sold on a kit for a IPA using a rare Australian galaxy hop known for its citrus and passionfruit aroma. Opening one of the hop packets for a sampling got us very excited about this beer.

The process, by far, went more smoothly than it ever has before.

Since this is my first post, I'm going to go through the general process for brew day:

  • Steeping the grains: Heating the fresh malts to between 155 - 165 degrees. The purpose is to release the sugars from the malts.
  • The Boil: We add more water to the steeped grains, as well as malt extract. We also added hops in 3 stages:
    • Beginning of boil. This batch of hops will cook the longest, bringing out bitter flavors from the flowers, which is meant to balance out of the sweetness that comes from the malts.
    • Middle of the boil. This is meant to add flavor to the beer (known as wort during the boil).
    • End of the boil. The hops doesn't get cooked much at all, and adds the fresh citrus aroma
  • Cooling: Before the wort can be transferred into the fermenting bucket and yeast gets pitched, the wort must be cooled down from boiling to around 70 degrees (so the yeast can survive). In the past we used an ice bath around the pot. This took a very long time (several hours). Not only does this make things take longer, it also gives a larger window for bacteria to accumulate in the beer. This time around, we used a wort chiller Shane bought at a garage sale, and got the wort cooled in less than 30 minutes.
  • Transfer and pitch yeast: Once cooled, we siphoned the wort from the pot into a fermenting vessel. Ours is a plastic, seal-able bucket with a temperature indicator on the side. We then pitched the yeast, stirred, and sealed the container.
Three weeks later, we bottled the beer after mixing in some priming sugar, indented to feed the yeast and get it working again, which creates the carbonation in the beer. Now that's left is to sit and wait for it to condition. It should be ready to try in a few weeks!

Indiana Dunes S24O

I packed up my camping gear again to do a Saturday-Sunday overnight at Dunewood campground. (70 miles each way). Funny story, I snapped off my right pedal 4 miles away from the campground, was able to call a bike shop and convince them to stay open 30 minutes late so I could drag my crap back 2 miles to get them replaced. 

Anyways, enjoy the pictures.

Apparently, the town of Beverly Shores, IN is famous for its "Neck Tie 5k" race.

 The Dunewood campground has a section of walk-in only sites. Great for a biker looking to get a little more seclusion.