www.BrettDaniel.com

West Virginia with the Outdoor Adventure Club (Updated)

Last weekend I went camping, hiking, and whitewater rafting in West Virginia with the Outdoor Adventure Club. We drove through four states, camped for two nights, got rained on, and had an absolutely grand time.

The trip began with a marathon 10-hour road trip from Champaign, Illinois to Fayetteville, West Virginia. I rode with four other people— Scott, Bianca, Amanda, and Greg— crammed into Scott's Chevrolet Impala. We were one of the first groups to arrive at the campsite. Other groups trickled in all night. I am told that the last group arrived sometime around 5 AM local time.

We drove through sporadic rain to get to the campsite, and it rained during that first night. This would become a common theme for the weekend. Fortunately, the tent held up with only minor drips.

I awoke on Saturday, donned my PVC rain suit, and ate a breakfast of dry granola on a wet picnic table. The rain let up around 10 AM, after which the majority of the group emerged from their tents. It took a while to get organized, but eventually one of the OAC veterans declared that we were to find a car, drive to the New River Gorge visitor center, and split off to do whatever we wanted from there. Several groups walked down 800+ stairs to the banks of the New River. Others went to hike through some abandoned coal mines. Scott, Bianca, and I decided to hike the Endless Wall Trail that follows the cliffs bordering the gorge.

I think we made the best choice.

The trail began on the opposite side of the ridge from the river. There, the woods were lush and moist like a rain forest.

After we crossed over the ridge, the forest became more rocky and dry. We soon came across the first of many amazing vistas overlooking the gorge.

I lost count of how many beautiful overlooks we came across.

At one point, a train went by on the tracks far below us. It looked like a miniature toy.

We also saw some tiny kayaks and rafts navigating the rapids. We could faintly hear their whoops and laughter from where we sat.

After admiring two or three more overlooks, we came across a “climber access point". We learned that this was where the park rangers have set up ropes and ladders leading to popular rock faces. Scott went down the precarious-looking rope first, and Bianca and I followed.

The rope led into a cave beneath a building-sized rock that had broken off from the main cliff face.

Beyond the cave we found two ladders that took us through a crack in the rocks to the bottom of the cliff.

We explored the woods at the bottom of the cliff and found some impressive rock faces that had obviously seen some use by climbers. We could see chalk marks and rope hardware in many places.

We eventually made our way back up the ladders and through the cave to the main trail. We admired several more amazing overlooks and saw some interesting wildlife.

None of us were able to identify a pair of strange birds we saw on a rock outcropping.

It turns out they were American black vultures.

We soon found another climber access point. It had a knotted rope leading through a narrow crack in the rocks followed by a very intimidating ladder.

At the bottom we saw more climbing walls, hundreds of enormous spiders (no pictures of those!), and some interesting rock formations.

We found a final climber access point near the end of the trail. This one had a very Myst-like staircase curving between the rocks.

After that, a ladder deposited us on a very steep, very slippery slope. Strangely, it was easier to climb back up the slope than it was to scramble and slide down it.

We had been hiking for several hours by that time, so we quickly finished the last leg of the trail and walked along a one-lane country road back to the car.

None of us expected such an amazing and adventurous hike. We would have been perfectly content with the views of the gorge and the trail itself, but the side trips down the climber access points made the trip many times more fun and surprising.

We ate dinner at a highly-recommended Mexican restaurant and returned to camp just as the night’s rain started. We knew we were fortunate that it had not started pouring while we were on the trail. A few folks were optimistic enough to start a fire despite the rain, but I decided to get some sleep in preparation for an early morning. Everyone in the club had to be awake, packed, and ready to go whitewater rafting by 7 AM.

I almost made the deadline. I had all of my stuff packed except for the tent which I planned to take down after I returned from rafting. The morning was lukewarm and overcast. I arrived at the camp general store just as the first rafting group was leaving. This left me time to eat some more granola for breakfast while waiting for the second trip’s group to gather. It wasn’t long before we boarded a bus and made our way to the dam at the start of the Gauley River.

The Gauley is one of the top whitewater rivers in the country. I am not sure how far we traveled, but the guide told us we traversed five class five rapids and numerous threes and fours. Obviously I was unable to bring my camera, but I seriously considered buying a waterproof enclosure just for this trip.

I sat at the front of the boat for most of the ride down the river. I caught all of the splashes right in the face but only fell off twice. The first time, everyone but the guide was forcefully ejected when we slammed into a rock. The second time, the entire boat flipped for some reason I was unable to determine. Just before I hit the water, I remember noting calmly that the boat was tipping an unusual amount. I also swam through the “swimmer’s rapid" and jumped off one of the diving rocks.

The most exciting part of the river was one especially long class five. After my boat ran it successfully, we sat in a calm area to watch the other boats navigate a rock funnel that my boat missed. Several rapids earlier, we succeeded in “surfing" our raft on a particularly large current.

Unfortunately, my enjoyment of the trip was tempered by the rain that started about halfway through the river. It caused the air temperature to drop and prevented me from drying between rapids and swims. Despite wearing a layer of wool over polyester, I was shivering by the time we reached the end of the river. It is disappointing to think how much more enjoyable rafting could have been had the weather been sunny and 80 degrees.

We returned to the campsite exhausted and dripping from the adventure. I ate the lunch provided by the rafting company, packed up my tent, and not long after rejoined my carpool for the trip back to Illinois.

I cannot wait to do it again.

Update

Bianca posted some of her pictures in this Facebook album. It is interesting to see pictures from a different point of view.

Software Product Lines

Today in my software engineering class, Professor Johnson said something like, "the TA and I noticed that some of you are slowing down on your weblog posts." I have a backlog of stuff that I would like to write about, so I will take his statement as a hint to start posting some of it ASAP.

For this post, I would like to focus on SAIP's chapter 14 entitled "Software Product Lines". I found this chapter especially interesting because I have often told people that if and when I join industry, I envision myself in a chief architect role for a large system or suite of systems. Alternately, if I decide to stay in academia, I see myself researching or consulting on the design of such systems.

I find product lines interesting because their architecture has many of the same concerns as single system architecture, but with larger components and more emphasis on modularity, modifiability, and reuse. For example, if one designs a component for one product, it is usually beneficial to generalize the component for use across the entire product line. This requires very careful, well-planned development which would likely yield a better product overall.

Reuse is a valid design concern for any system, but it works especially well in a product line for several reasons. First, almost everything can be reused. The book mentions reusing requirements, software elements, analysis, testing, people, and many other architectural elements. Second, all of these architectural elements fall under the assumptions and constraints of entire set of systems. The book echoes this idea nicely when it says, “Software product lines make re-use work by establishing a very strict context for it.” Contrast this to simple code reuse in which one uses a library or framework built elsewhere. The library may have made assumptions about its use that contradict the needs of the user or it may be too general or specific for the desired task.

I also find it interesting that a company’s success can be driven by the quality of the software used to drive its products. In this case, it benefits a company greatly to have a common software framework. When many of a company’s products rely on the same software, it changes the emphasis from quick, get-it-out-the-door coding to careful maintenance and incremental expansion of the common software product line.

Nodebook Doodle: Ogre

Canoeing with the Outdoor Adventure Club

I know what you probably thought after reading the title of this post: "Brett joined a club?! What is he doing in a social organization?" Yes, I joined UIUC's Outdoor Adventure Club. They go on all sorts of fun trips throughout the year and this weekend went canoeing on Sugar Creek in western Indiana.

We carpooled to the campground separately throughout the day on Friday. The group occupied a large tree filled campsite right next to the river.

Friday night turned into a big outdoor party. The 50 (!) of us gathered around various campfires and socialized late into the night. I brought my harmonica, and at one point I was jamming with a guy who brought a ukulele and another who brought a mandolin. It was a great time.

I slept terribly since I my sleeping bag was still in my Indiana home. Instead, I used a makeshift bedroll made from some extra blankets from my apartment. Luckily, I was able to snag a tent, but several people chose to sleep under the stars.

I was the second person—after the club president—to wake up the next morning. People slowly trickled out of their tents, and we ate a breakfast of bagels and PBJ. Someone eventually realized that with the time change, we had only 30 minutes to pack up the tents and meet at the canoe rental place across the river. We must have made it in time because not long after that we were in a repurposed school bus driving to the headwater. We cast off about five miles upriver.

The river was cool and clear, the weather was absolutely ideal, and the scenery was spectacular.

Much of the river was lined by steep rocky banks.

Near the end of our portion of the river, we stopped at a beach nestled against a sheer rock face. There, we ate our lunches, and a few of us followed a small stream a few hundred yards back into the woods.

We were only on the river for maybe two hours. Everyone agreed that it was too short, but that it was definitely worth the trip.

Familiar Concepts

I like reading about software because often a writer will attach a descriptive name to a familiar concept or describe it in a new and interesting way. This week’s software engineering lectures and readings in Software Architecture in Practice brought up several such names and descriptions that stuck with me.

Architecture as Early Decisions

The early chapters in the book echoed the class discussion about the definition(s) of software architecture. Its main definition says the following:

The software architecture of a program or computing system is the structure of structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships between them.

This is as good a definition as any, but it did not ring as true in my mind as a passage that appeared several pages later in the book:

Software architecture represents a system’s earliest set of design decisions. These early decisions are the most difficult to get correct and the hardest to change later in the development process, and they have the most far-reaching effects.

The second definition emphasizes the thought process behind an architecture; the first describes any system whether or not any thought was put into building it. Granted, a bad architecture is still an architecture, but I prefer to focus on the good ones—those that made the right decisions early on.

Professor Johnson paraphrased this idea in class today when he said, “Architecture is the stuff you wished you did right in the beginning.”

Transaction Scripts

I am sure all programmers have encountered a particular style of programming that seems to willfully ignore object-oriented programming practices. Rather than encapsulate behavior in classes and split an application into well-defined modules or layers, a programmer will instead make many monolithic functions that probably contain SQL directly in the code. This style may work well on small applications—I am certainly guilty of using it—but it breaks down as common functionality is duplicated and bugs appear.

Tuesday’s lecture described these types of programs as “transaction scripts”. This term is much more descriptive than “procedural-style programs” and easier to say than “non-object-oriented programs”.

Software Business Cycle

A common theme in the early lectures and the first chapter of the book involved the interaction between the architecture of a system and the organization that develops the system. For example, an organization that implements a client-server architecture will probably have two teams: a client development team and a server development team. That is, the module divisions in an architecture will usually define the divisions in an organization.

Obviously, the influence can travel in the opposite direction as well. The people and expertise in an organization will affect the final architecture. For example, a group of PHP/MySQL experts will probably not design an architecture around .NET and Microsoft SQL (though a good architecture may not even specify the implementation language or database).

The book calls this interaction the “Software Business Cycle”. It is a good thing to keep in mind for when I eventually enter industry, and something that I have been insulated from in my previous programming jobs.

Unrelated

I found it interesting that with a quick search on Getty Images’ website I was able to find the original picture that the book publishers chose for the cover of the book. It seems like an odd, random choice. Why is a person standing alone in the entryway at night? Why did the publishers crop out the fountain, leaving what appears to be a strange discoloration in the sky?











Большая бухгалтерская компания оказывает услугу регистрация ооо надежно со скидкой