We stayed just a few blocks from the start so the logistics were nice and simple. No bus to catch at 4am, just a short 10 minute walk in the dark. The race started at 6am on the dot. We ran the initial 3 miles through downtown and then hit the first big hill between Miles 3 and 4.
Once we hit Mile 5, the scenery began to change into the beautiful wine country of the Edna Valley. The course was green with a number of vineyards on the way out to Mile 13. There were a lot of rolling hills, some fairly steep.
After a brief out and back for Miles 12 and 13, we headed West and then back towards town. The hills didn't let up! By Mile 20, my calves were screaming and my quads were hoping the rollers were coming to an end.
At Mile 23, we re-entered town and had a net downhill to the finish. There were a few uphills, especially having to climb up to a footbridge to go over the railyard and a sadistic last hill at Mile 25.8 (who does that?!?) The last half mile was all down hill and made for a very fast finish.
Overall, here's how the run rates in my book:Organization – Well organized, marked course. The expected inagural challenges were nowhere to be found. Grade: A
Course - Scenic Edna Valley. Big hills in multiple spots. Grade: B+
Aid-stations - Frequent aid-stations with water that wasn't from a garden hose. No Gatorade. Plenty of volunteers. Grade: B
Swag – Nice medal and dri-fit long sleeve shirt. Grade: B+
MVC is a great pattern that provides nice abstraction and allows for an easy way to divide tasks amongst a team. Driving site navigation, externalizing connection info, messages and other properties is a great idea and allows for changes to a site that doesn't require recompilation of binaries.
Coupling the above with Tomcat and the ability to hot deploy makes for a great agile team. Things can work in a Continuous Integration/Continous Deployment model. Drop the files in, tell Tomcat to reload and life is good.
Well, almost.
Unfortunately, if you've utilized hot deploy, you find pretty quickly that there are a number of strange OutOfMemoryError exceptions in the logs. They are difficult to reproduce. Something is just not right ...
As I learned last week at the SV Web JUG meeting entitled "Is Instant Redeployment Really Possible", there are a number of reasons that hot deploy doesn't really work and the solutions to making it work aren't easy to accomplish.
Through the use of numerous code examples (and a few Starbucks gift cards), the meeting's guest speaker Sang Shin explained in detail why hot deploy is an idea not ready for primetime.
If your code has statics or singletons (and what code doesn't), the references to these objects are not neatly handled. Enough redploys and boom, you are out of memory. Essentially, the class loader holds a reference to each of the classes it has loaded and any class that can't be unloaded cleanly causes a memory leak.
It turns out to be that simple really - without purchasing one of the various commerical products that purpotedly handle the reference issue (which they do by creating an individual class loader for each and every class, property file, etc) you're hosed.
Not exactly the promise of hot deploy. Which is why I always have n + 1 servers running behind mod_jk
The marathon was small, with about 500 runners and 100 three-person relay teams.. The weather was cool (40F), dry with little wind. As this was a January race in Northern California at an elevation of 1000 feet, I was happy there wasn't snow on the ground.
We got up at 5:30am and took the 7am bus from the finish to the start. The driver didn't get lost and we arrived with plenty of time. The starting line was the top of the Shasta Dam, which turns out to the second largest dam in the United States. They opened the Visitors Center where everyone hung out until race time, which was nice as it was warm! With five minutes to go, they asked us all to head to starting line.
The race began on time and was well-organized. The first 1.5 miles of the course went directly across the top of Shasta Dam and then headed steeply downhill to the river's edge (outflow of the dam) for another mile. Once we got to the level of the river, we ran along a "Rails to Trails" route that followed the river for approximately 23 miles. The views were incredibly beautful and the numbers of marathoners was small enough that it felt more like a nice long run than a race.
We ran through the old train tunnel at Mile 4 (stopping for photos of course) and continued on to the first set of hills at Mile 12. Along the way we were on the lookout for ice on the course - parts of the trail were in the shade and were slippery for the first few hours of the run. Miles 12 - 14 had some hard hills; we also passed the first hand-off for the relay so there were lots of kills (me) after that.
After another mile long hill from 15 to 16, we did an out and back then headed across the Ribbon Bridge at Mile 22.
The last four miles followed along the Sacramento River through downtown Redding and we finished by crossing the Sundial Bridge.
Overall, here's how the run rates in my book:
Organization – Well organized, marked course. Grade: A
Course - Beautiful, remote course. Big hills at Miles12-14. Grade: A-
Aid-stations - Fewer stations than a large marathon, but spaced apart approximately every 2 or 2.5 miles. Well stocked, super friendly volunteers. Water that wasn't from a hose and Gatorade (the Smurf one) that wasn't too strong. Grade: B+
Swag – Great medal, nice dri-fit long sleeve shirt. Grade: B+
The "new" Google Reader
The "new" GMail
Twitter's Bootstrap site and their commentary on buttons
Is the "Compose" button supposed to tell me when I'm sending mail that is dangerous? I don't get it. Or is the danger here that a designer at Google is actually trying to drive away users?
SVJUG held their January meeting on 1/18/2012 with guest speaker James Ward, a Principal Developer Evangelist at Heroku.
James did a rapid-fire 90 minute presentation covering multiple web frameworks. He started each project from scratch, wrote code, configured, tested locally, pushed to Heroku, built and scaled each app.
Whew.
It was fun to watch.
We covered the following frameworks:
Spring Roo
James created the basic "Pets" app using Spring Roo commands. He made minimal configure changes, built and ran everything locally. To push to Heroku, he created a Git repository (the push mechanism for Heroku at this point, didn't sound they support SCP, etc) and then pushed this repository to the Heroku Git repository. After starting a Maven build (interesting in that Git only contained his source and configs, no binaries/jars), all binary assets were obtained, a build was run and then deployed and instantiated.
Play Framework
There was a lot of interest in the Play Framework. James built a basic CRUD app, creating a basic input screen and a service that emitted the items in JSON. He showed us how modifying both the markup and the source caused no noticable pause to rebuild (no service tomcat6 restart to reload the binaries)
Utilizing a bit of JQuery, he took the JSON output and included it on the input screen to demonstrate the ease of using Play with JQuery. His IDE was IntelliJ because he noted that IntelliJ v11 has built-in support for the Play Framework while Eclipse currently does not.
His demo was using Play 2.0, which no longer uses Groovy for templates as Play has moved to Scala templates instead. Additionally, he noted that Play 2.0 uses SBT (Scala Build Tools) instead of Maven..
Like SpringRoo, the Play CRUD app was pushed to Heroku via Git, built, instantiated and scaled on Heroku. It all looked quite simple from the audience.
Scala with Twitter Finagle
The last demo of the night built an app using Scala instead of Java and used Twitter's Finagle framework (we didn't cover Lift unfortunately). James discussed the trials and tribulations he has had learning Scala ("challenging") and demonstrated building a basic app. Like the prior frameworks, he pushed via Git to Heroku, built, ran and scaled the app.
Discussion Items/Links
- Demos - James put all his demos (including a few we didn't have time to cover) up at http://java.herokuapps.com.
- Bootstrap, from Twitter - highly recommended taking a look at Bootstrap for help with design.
- Netty - Next gen app server built with Java NIO
Overall, a great talk - we covered three very interesting frameworks in 90 minutes and discussed basic pros/cons of each. Time to try them out!
Some words of wisdom to try and follow in this New Year
1. Exercise six days a week for the rest of your life
2. Do serious aerobic exercise four days a week for the rest of your life
3. Do serious strength training, with weights, two days a week for the rest of your life
4. Spend less than you make
5. Quit eating crap!
6. Care
7. Connect and commit
(from "Younger Next Year" a book that I'm not old enough to be in the author's demographic, but one that has a number of very interesting ideas)
Last Sunday, 12/4/2011, I ran the California International Marathon (CIM), five weeks after running the Marine Corp Marathon.
Revisiting the race that was easily my biggest bonk ever was a bit intimidating. I went over my running plan fifty times to make sure I wouldn't suffer the same outcome (plus my wife wasn't going to pace me the last 13 miles like last time).
CIM had 8000 marathoners and 1000 relay people this year (full as usual). The weather was cool (36F), dry with no wind. As a bonus, the CIM folks decided to become the marathon with the most port-a-potties in the U.S. (apparently 1 unit for every 26 runners).
We got up at 3:30am and took the 5:30am bus from the host hotel to the start. Our bus driver got lost in the dark as did a number of the others. Luckily we made it to the starting line with plenty of time to spare. Riders were allowed to remain on the bus until 5 minutes before the start, which was nice.
The race began on time and was well-organized. The event is billed as a fast net downhill race ("A very fast course, if not THE FASTEST, course in the country") which is true, however, there are a number of rolling hills in the first 20 miles or so.
After a 0.5 mile downhill start, the course followed various semi-rural roads, always with a not-too-steep incline followed by a not-too-steep-but-a-little-steeper-than-the-incline decline. I worked to maintain a consistent pace and not charge ahead on the downhills.
Luckily, I had some amazing crowd support at Miles 8 and 21 which gave me something to look forward to during the race.
The rollers end at just about Mile 20 when you pass through "The Wall". The last 6 miles of the course are extremely flat and many runners fly on this last part of the course. Those of us with screaming quads cheered as the kills multiplied!
The last few miles were rough but somehow I crossed the finish line intact. My legs were killing me from the rolling hills but I managed to avoid repeating a major bonk. Tired but happy I closed the book on my 13th marathon and slept in the car on the way home.
Overall, here's how the run rates in my book:
Organization – Well organized, marked course with good crowd support. Grade: A
Course - Rolling hills. Make sure to train for them. A few scenic spots. Last six miles are the best part. Grade: B
Aid-stations - Well distributed and staffed. Water in garbage cans, from rubber hoses. Ultima. Yuck. Grade: C+
Swag – Great medal, nice dri-fit long sleeve shirt. Grade: B+
The goal of Dart is ultimately to replace JavaScript as the lingua franca of web development on the open web platform.
The Silicon Valley Google Technology User Group's December 2011 meeting (stream) was focused on the new structured language, Dart. Google released Dart in a technology preview in October 2011 with the goal of moving web programming into the future ("removing 15 years of cruft").
The majority of the presentation was given by Steve Ladd, a Developer Advocate at Google. Steve has previously worked with Rails, HTML5 and Java and MVC frameworks (he authored "Expert Spring MVC
Dart looks extremely familiar if you understand OO, particularly Java. Dart has a compiler that emits Javascript capable of running on any "modern" browser (defined as Chrome, Safari 5+, Firefox 4+ and IE9) or it can be run in a Dart VM. The Dart team is also advocating a new MIME type "application/dart" that will allow Dart to be run directly in browsers that support it.
Currently, Dart does not have support for Refection, so there isn't (yet) a jUnit type unit testing framework available. In a nod to building large scale apps, Steve Ladd made sure to walk through code samples that made use of mocks, emphasizing the value of interfaces.
Dart also has a number of things that are missing in Javascript:
Libraries
The core library contains support for Collections, Maps, Hashtables and more.
Classes - look quite a bit like their Java counterparts
class Rectangle {
final num height, width;
Rectangle(num this.height, num this.width);
}
Interfaces - very Java-like as well
interface Shape {
num perimeter();
}
class Rectangle implements Shape{
final num height, width;
Rectangle(num this.height, num this.width);
num.perimeter() => 2*height + 2*width;
}
Static Types
Well, kinda sorta. You can turn on enforcement during compilation if you want (throws an error). However, during run-time, the VM will determine the actual type and execute (even if I do something like take a Rectangle object and erroneously declare it as a String). This "feature" seems pretty dangerous to me.
Dart Editor
At the meeting, we got a preview of the Dart Editor, which runs inside Eclipse. It was an early version, but many Eclipse basics were working including auto-complete and the ability to drill into declarations. It looked almost ... Java-like.
Conclusion
Dart looks pretty interesting. Javascript is pretty messy, especially without jQuery. With a friendly open source license (BSD) and native support in Chrome, the language might have some legs.