Bruce Tate's Blog

June 2004 Archives

JDO: Let the games begin

From the very beginning, the JDO specification has been surrounded by controversy. You want drama? Consider the new startup specification against the establishment of relational database vendors and TopLink, the leading OR mapper. You want strangeness? Consider a specification for transparent persistence without any object relational mapping at all. You want a full-out bare-knuckled brawl? Consider the vocal conflicts between vendors like CocoBase and the JDO vendors; the facts and the fud surrounding byte code enhancement, and the pure transparent technologies of the lightweights against the cumbersome persistence of the establishment.

For all of the world, it looked like JDO was going to die a slow, lingering, silent death. EJB succeeded based on the sheer marketing muscle of IBM, BEA, Oracle, and to a lesser extent, Sun. Then, after a backlash against EJB, many returned to JDBC with POJO. TopLink stumbled and slipped, and it looked like persistence in general was going to take a back seat for a while.

But a funny thing happened on the way to the grave. Hibernate awakened the masses with an elegant, pragmatic implementation. And JDO began to show up again. Like the ragged peasant in Monty Python's Holy Grail, JDO just wouldn't hurry up and die; it wouldn't get on the cart (of dead plague victims). Little nimble vendors like SolarMetric effectively evolved JDO technologies, and brought it into the relational mainstream. JDO Genie built a simple and effective user interface.

So the expert group built a very strong 2.0 specification, patching the major holes in JDO. It's actually a model for how the JCP should work: they used practical, real-world experience to dramatically improve the previous version. And the intrigue started all over again. BEA, IBM and Oracle no-voted the JDO spec, and Borland abstained, but everyone else voted for it. EJB 3 announced that CMP as it existed was basically dead, and would be supported for backward compatibility. Instead, it would be replaced with a POJO persistence model. Gavin King, creator of Hibernate, joined the expert group, and it looked like EJB 3 would in fact be Hibernate. And some members of the expert group fed that false impression. The JDO community wailed. Surely, this time, they would have to get on the cart.

Then, many in the standards community got together and decided that it might be important to break persistence away from the EJB specification. As far as I know, the persistence specification is unsettled, and JDO has a tremendous opportunity to take advantage. They’ve put out an early specification. It’s been very well received. And here we are, at JavaOne. And the drama continues, but this time, within the JDO community.

First, Versant and Kodo announced that they were ending their co-marketing relationship. By itself, this would not make sense, because SolarMetric liked the increased visibility in this marketplace, and Versant liked having an increasing presence around relational databases. The move was quickly explained when Versant announced the acquisition of JDO Genie, a lesser implementation with inferior mapping capabilities, but still, a market player based on innovative user interfaces and ease of use. The message from Versant is clear. Relational databases have won. Nowhere in the JavaOne media guide could you even find the word object-oriented database in the Versant literature. They seem to be strongly targeting the relational community, and based on continually declining market for OODBMS, that’s a sound move.

For a return salvo, SolarMetric hired the independent giant, Robin Roos, effectively showing the rest of the persistence industry that SolarMetric planned to compete in Versant’s back yard. Finally, SolarMetric bolstered their application strategy by announcing a tighter integration with Spring. That effectively gives Kodo features like declarative transactions without having a full application server. So SolarMetric’s counter moves look to be aggressive.

So in the shadows of JavaOne, big things are happing all across the JDO landscape. It’s an important one to watch, because I believe that the Kodo product is the best high-end implementation of transparent persistence today. (I like Hibernate on the low end.) What happens next? Stay tuned.

The Illusion of the Wall

So I’m at JavaOne, and listening to the keynote. To summarize, Java is everywhere. We (Sun) really understand how to make money with it. And yes, we’re going to build an IDE for consumers, and people will love it and use it and it will attract 10 billion developers. Mobile is where it’s at. And somehow, we’re going to milk billions of dollars out of that knowledge. And after listening to this, I’m thinking I’ve heard it before. Maybe it’s last year’s keynote. I like it, want it, need it…but am skeptical. And so my mind wanders to the mountains.

I was on the Piedra River in Colorado. My long-time kayaking partner Mike Oehrtman and I had met a couple of locals to guide us through a river that we assumed would be fun enough to get us in trouble, but not too fun for our own good. We watched them put in and shred the river. They played every little hole and toyed around with monster waterfalls. They made it look easy.

But through humorously tragic miscommunication, I found myself on a section of the river that was over my head, both literally and metaphorically. I was not where I thought I was, and my skills could not cope with the power or steepness of the river. After rounding the corner, I meandered into a violent eight-foot twisting drop. It hammered me. I flipped, tried to roll, panicked, bailed, swam. In fact, I swam over waterfalls and under downed trees through frigid waters for nearly a mile, in an incident that should have killed me. After scraping myself out of the river and getting myself and my gear collected, I had barely put my paddle in the water when I screwed up yet again. Wet paddle. Hear roar. Make mistake. Flip. Blow roll. Blow another roll. Panic. Curse underwater. Choke. Bail out. Swim. All in all, I swam four times that day. I felt like Bill Murray in Ground Hog Day. (He lived the same bad day over and over.) Most of the time, I couldn’t tell what mistake that I made to get myself into trouble in the first place. I’d found a river too big for me to run. I’d hit the wall.

Some Java developers that I know feel a little like that right now. They’ve hit the wall. It’s ground-hog day all over again. Get excited. Learn a monolithic API. Start to build it. Make design mistakes. Dig hole. Make mess. Curse. Work overtime. Scratch and claw. Find silver bullet. Lather, rinse, and repeat. While it was great at one time, this object technology doesn’t seem so easy any more.

Enter Ground Hog Day on a grander scale. Those of you who are old enough to remember have seen this before. A long time ago, when we thought we’d taken procedural programming as far as it would go, we hit that unrunnable rapid. People wrote books like the Mythical Man Month and Death March. So we innovated. Object oriented technology was born. We started playing with it in the 1970s, with Small Talk. A few joined the band wagon, and used the technology to good effect. They are like the guides that led Mike and I to the dangerous river. And they had fun, and were incredibly productive. And like Mike and I, other lesser equipped paddlers in the industry followed enthusiastically, but they were in over their head. And they crashed and burned. They heard the roar (inheritance? CORBA? #define?) And they flipped, tried to recover, and swam. Some wailed, “This is truly a river that is too mighty for the layman to run. Let us build a sign, and a wall, to keep the public safely out. Let there be no more good people drown here.”

But it turns out that the river unrunnable after all. In fact, while we were sucking that cold water through our nose, and scratching our way to the shore, we were learning. Our universities taught. Gurus published. We read.

And some smart vendors paid attention, and introduced simpler technologies, like objects with training wheels. COM gave us components without inheritance. The defense industry gave us Ada, or encapsulation without a full-blown object model. C++ gave us the additional object oriented semantics, but left the procedural stuff in tact, so the effect was like a C plus plus, minus minus.

At the time, it looked like we’d hit the wall. These “solutions” often looked like they were doing more harm than good. But we were learning, and absorbing. The collective psyche of the masses was moving, so when we were ready for objects, they not only met modest success, they exploded on the scene with Java. The world was ready for more, and Sun got the product and the timing right. The rest is history.

And that, finally, brings me to the point. We’re in a similar place today. The early guides are putting in on the roaring river, and their kayaks have AOP (Aspect Oriented Programming) all over them. And a few of us are going to foolishly follow them down the river, and maybe even get killed. We’ll hear that AOP really isn’t a seventeen-foot rubber raft that is immune to capsize. But what happens next? Can that particular river be run? I, for one, think so.

You can see the early stages of the first backlash. In fact, if you try to turn everything into an aspect, you’ll crash. Certain aspects are hard to understand. We need to understand implications of performance, and learn to test performance. Some of it seems too much like black magic. And some are saying that maybe AOP is the wrong model.

But a few people are bringing AOP ideas into the main stream. They are giving you AOP with training wheels (pontoons?). JBoss has publicized the idea of interception in an EJB container. Perhaps a better example is the Spring framework, where you can consume AOP services. So, you’re starting to see people talk about the important concepts in AOP, like transparency, and independent services, and generalization of an important problem, and cross-cutting concerns. In fact, in my book (Better, Faster, Lighter Java), I don’t talk much about AOP, because I don’t think that most of us are ready. Instead, I talk about basic principles that we can borrow from AOP, and apply today. And I think I’ve struck a chord that’s ringing true. Today, my book was #3 on the list of JavaOne best sellers.

If you think about it, those ideas are all around us. Spring is a way to consume aspects in Java. JDO is a persistence aspect. JBoss, Pico, Keel, JSF, and many others let you use IOC in meaningful ways. True, these frameworks will not, in and of themselves, introduce the full power of AOP. But don’t view this as the end. While it may seem like we’ve hit that unrunnable rapid, we’re moving forward. We’re learning.

And that’s where I think we are today. We’re learning, and we’re getting ready to conquer that rapid that’s seen experts, but has to date been unrunnable by ordinary Joes, like me. And that’s what I’m looking for at JavaOne. I want little steps toward the next paradigm. I want chicken instead of elephant. Simplicity. Transparency. Interception. Attachable services. Inversion of control. Testability. I’ll find it in pockets—at JetBrains with IDEA; Kodo-Spring integration at the SolarMetric booth (where I present on Wednesday at 2); in the experiences of the expert guides; in BOF (Birds-of a-Feather) sessions; in the bars. But for the most part, I don’t think it’s going to happen at the keynotes, or in the big booths. This year, the action’s with the little guy.

So fast-forward to 2002. After another mistake in judgment, I found myself on a flooded creek, once again, far more difficult than any I’d ever encountered. That day, one expert kayaker died, and two were rescued by helicopter. I shouldn’t have been out there. But I had learned enough, on the Piedra and other places. I coped, and survived, and even thrived. I can’t say that I’ll ever jump on that creek in flood. I may not even try my luck on the Piedra again: I’m getting a little old for that stuff. But on that day, the knowledge meant survival. Today, for Java, it means the same thing.

People of the elephant

The "elephant" article that java.net published last week was probably my favorite that I've ever written. Your responses made me work. After hundreds of blogs, e-mails, forums and phone calls, I'm still amazed that it struck such passionate feelings from my audience. (In an amusing twist of fate, Amazon chose that week to report that my new book, Better, Faster, Lighter Java, had not yet shipped, though they were taking orders. Rather than answer each blog in a boring tit-for-tat, I'm going to make more amuzing but practically useless gross generalizations. These are the groups of people that responded to my article.

• Some just like chicken better. Call this the tribe of chicken hunters. And I say, "More power to the chicken!" Some called me to ask me how to move from a diet from elephants to chicken. I learned that more and more people are learning to hunt chickens. Spring Chickens are now taking off and downloads are in overdrive. Hibernating chickens have never been stronger, and Kodo-chicken is having spikes in orders. Like their prey, some chicken hunters are not as always as bright. That’s OK. You don’t have to be to eat a chicken. Others are brilliant, including those that wrote the manifesto about changing our diets from elephant to chicken. Still others are purely pragmatic, seeing chicken as a way to save time, money and effort. Recognize this tribe from the elephant-sized footprints on their chest. Make them eat an elephant again at your own peril. I firmly believe that most of us will be chicken hunters soon.
• Some are grudgingly still working with elephants, but are having a difficult time. Let's call this the starving hunters. They stare longingly at chicken, but this tribe's betting everything on landing an elephant. They say that they just don’t have time to learn how to hunt chicken, and you can manage and deploy elephants on a much larger scale. They need some of the other parts of the elephant, too. Smugly, they ask, “Have you ever seen a chicken with a 14-foot tusk?”. Sure, they may take a casualty or two to the hunt, but the benefits outweigh the risks, and they believe that nothing but an elephant will save them, anyway. Recognize them by their battle scars, the racing eyes, and the vaguely frantic conversational style. Don't try to comfort them with alternatives. They probably do need the whole elephant. They may not know it yet, but they’ll probably be chicken hunters soon.
• Some don't care at all. They live in elephant hunting grounds with no other game, and are making the best of it. Call them the happy hunters. They’d adopt quickly if other tastier game moved in, or the elephants moved out. They know their station, and are pragmatically doing everything in their power to make elephant easier to eat. They actually like elephant. And it's been so long since they've eaten anything else that to them, it doesn't feel like eating an elephant. They speak a different language, and don't really care when someone says something bad about their elephants. They shop at SAMS for drums of chocolate sauce, and they use sophisticated elephant cannons that would pulverize other game. They don’t care; they’re hunting elephants. Recognize them by the radios that blare “Don’t worry, be happy,” and their nation's flag, that has a big grey border around a rising sun, with a motto around the perimeter that says "It tastes like chicken."
• Another group lives for all things elephant. Call this tribe the mighty elephant warriors. Their sworn enemy is the tribe of the chicken-hunter. To them, elephants are sacred. They are actually misunderstood, and they actually taste like manna from heaven. When I wrote my article, this tribe said that I was really just talking about EJB entity beans, or stateful session beans, or something else. They insist that if I'd really gotten to know their elephant, things would have turned out differently for me. But now, it’s too late; I’ve insulted their elephant. They get a mighty spiritual boost from elephant. They brag about being able to eat an elephant one bite at a time, but they’ve been gorging since adolescence. They've studied the hunt all of their adult lives, and can bring one down with a Swiss army knife and a toothpick. And it's infinitely easier than bringing down a dinosaur, the sacred beast of their ancestors. They may talk about hunting other game, but they will always come back to the elephant. They love everything about the elephant, and some of them actually want to outlaw elephant evolution. Of course, you may want to be a mighty elephant warrior, but most people that try to pass the initiation get trampled into the ground. A few survive the experience and join some other tribe. Recognize the elephant warriors by the "elfant-4-u" bumper stickers on their hummers.
• Another tribe just wants to pick a fight. Call them the cannibals. Don't try to recognize them. Just turn around and run.
• Then there are those that hunt other game. The biggest is the tribe of the whale hunter. They’re so intensely loyal that some are still trying to hunt whale in fresh waters! Some have heard distant tale of whale-lock-in, so all land-based hunters fear them. The visual-Shrimp hunters distain the whale hunters, and look back fondly on the shrimp-hunting days. You can recognize them easily, because they’re more of a cult than a tribe. Find the leader, and the billion whale hunters will be right behind.
• This tribe has actually never seen an elephant. Call them the cloud people. They are genetically superior, and have actually evolved to a higher plane. Cloud-people were already making advanced Smalltalk when chicken hunters learned that the first letter in chicken was C. They hunt unicorn. They’re completely brilliant, but often completely impractical. There are rumors that some of the cloud people actually started the tribe of the chicken-hunters, but that claim has never been proven. Few will ever be lucky enough to meet a cloud person. If you do, you'll recognize him by the eerie soft luminescent glow from their hair and skin from years of slow radiation.

And what do you think?

1. Is EJB an elephant? I'm not just talking about EJB persistence. Throw in the rest of it too. Is it easy enough to digest and understand? Can you buy it in parts, or would you even want to? Can you effectively decouple everything that you need to, so that you can eat it one bite at a time? Is it easy to teach, learn, maintain, and support? Above all, how does it compare to other solutions out there?
2. Are there other elephants out there that you're already dealing with today? Do you see any other large, unwieldy game, trotting around on the horizon that may grow to elephant-like proportions?
3. If you think that there are some real elephants lumbering out there, how will you choose to cope? Will you choose to go to a lightweight container? Will you radically switch programming paradigms, or move over to .NET? Will you instead just try to work harder and smarter?
4. What's your tribe? How would you characterize it?

Water for your rocket?

Have you seen the 2-liter water rockets? My wife Maggie and I recently bought a launcher to entertain our kids. We about killed ourselves drinking enough rootbeer to empty the rockets, and then headed to the park. My daughters Kayla and Julia stood slack jawed, staring alternately at the aqua missle and their crazed daddy.

You basically take a bike pump, a 2-liter soda bottle, and enough piping to tie the two together. Then, you add water (40% seems to be optimal based on the physics models), and "woosh". You can easily launch the thing 100-200 feet, but some water rockets with modifications have gone much higher than 1000. Pennies per launch. Water for fuel. Non-destructive. Lots of bang for your buck.

2003 and 2004 are turning into productive years for me. I want to introduce you to some of my new rocket fuel. I'm sure that you already know about the pyro rockets (Spring, Hibernate, O'reilly, and Martin Fowler). I want to tell you about the alternate fuels that helped to launch me for pennies. These are the lesser-known, or out-of-favor, people, products and ideas that have had a profound impact on me.

• Mike Clark. Mike is one of the most promising new authors in the J2EE space. People are starting to take notice. He's attracted to the most critical problems: automation, testing, productivity, performance. He knows how to communicate, and he's hooked up with a great new publisher (the Pragmatic Bookshelf), with fantastic editing support. It's hard to find good programmers, but he's a great one. It's harder to find people who can communicate, but he makes a great impression to his class rooms, his clients, and his partners. And he delivers, on time and under budget, every time. Mike worked with me to write Bitter EJB, and I used many of his ideas (and those of his publishers) to consolidate into Better, Faster, Lighter Java. His customers, students and readers alike rave. They're right. Read his stuff at clarkware.com.
• Justin Gehtland. Justin, quite simply, is the best co-author I've ever had. He's a zebra who looks equally good in white (Java) and black (.net). He's more popular in the .net space, but he's a very solid Java guy as well. He writes clean, simple code. Further, he knows process. He's got a well-grounded way of dealing with his clients. It's not fair to have such a nice guy, based on solid founding principles, who can also code, write, communicate, and see the big picture. Justin's biggest contribution to our community is that of a pragmatic, who understands what both Java and .net have to offer.
• Jay Zimmerman. Jay is a shrewd businessman who has quietly built an alternate conference to the JavaOnes of the world, and he's done it with a consistent vision and quality. Jay's biggest mark is on local Java communities. He's provided good speakers to Java User's groups, and has brought a high-quality symposium series to local communities not named San Francisco or New York. He's always looking for ways to improve. My favorite thing about Jay is that he always negotiates with a win-win attitude. Where JavaOne has become the voice of the big money, NoFluffJustStuff has become the voice of many important independent consultants. It's a fun conference, and it gives a voice to many who would not otherwise have one.

• Bloomba. If you know about Bloomba and have tried it, and you have a choice, you're probably using it. This e-mail client makes it easy to filter spam (90% plus hit rate for me), and do instant searches (less than a second for over 5000 emails....also searches content of attachments.) I used to spend a whole lot of time organizing into filters. Now, I just leave it all in one big box, and google, er, bloomba, for whatever I need.
• IDEA. I know, I know. It's already a popular tool. But I've rediscovered it after a brief time with Eclipse. It's simply the best refactoring IDE available. Sure, it's not free. But I'd gladly pay to help this great company produce great products. They get it, and refactoring has never been easier. I believe that it's healthy to buy great products, even when a slightly inferior open source alternative is available. It fuels innovation and progress.
• Kodo. I love Hibernate, and frequently recommend it, but for bigger, more sophisticated deployments, I usually recommend Kodo. It's fast, simple, and has some of the enterprise management tools that Hibernate lacks. Their CEO Neelan claims that they've never lost a performance benchmark since they released 3.0, and I believe him. I particularly like some of their performance management add-ons, and their mapping support is among the most flexible in the marketplace.
  
  SShhh. I heard it through the grape vine that the Spring project and SolarMetric are working together at the highest levels to provide first-class integration. I hope that this support is extended to cover JDO 2.0 generically.
• The Pragmatic Bookshelf. Dave Thomas and Andy Hunt are at it again. I've had a great experience with O'Reilly and my editor with Better, Faster, Ligher Java (Amazon got their shipment yesterday!), but you already know about them. I'd like to mention a pseudo-competing publisher in the Pragmatic Bookshelf. (O'reilly handles distribution for them.) They're writing smaller titles with ideas that last. They boil a subject down to the basics. I've loved the three books that I've seen. It's fundamental: we should weigh books on the quality of the ideas, not the quantity of pages. No more phone books!

• Test-driven development. This has been popular in the lab, but has taken a long time to take hold on production teams. Let me be clear. If you want to give your water rocket an extra boost, look to TDD. It's like pure H2O: raw simplicity and power. It forces cleaner designs and injects some automatic discipline. Further, since newer techniques like lightweight containers, AOP and dependency injection make it easier, it's time to give TDD a second look.
• Context inheritance. Spring's biggest impact to my life has been the improvement to testability. I can test out of the container, and I can stage small-scale integration tests, by providing a custom context for test cases. The problem is that this design philosophy leaves me with dual maintenance for my testcase contexts. Instead, I can use Spring's context inheritance to manage my testcases. The root class can use the production context, and every more specialized test case also has a more specialized context. Very interesting. I can then stub out a database witn an in-memory implementation for quick GUI tests, add specialized test data, or simply test a small subset of my overall system...all without undue repetition of contexts.

Water for your rocket. Always remember to launch from a safe distance. The fuel's more potent than you think.

On mountain biking and J2EE

Over this past weekend, I took the family to Durango. Most of the time, I was a good boy, and dutiful father. No near drownings on the Piedra or Animas. No mountain bike overnights down the Colorado trail. Not even a difficult hike. In fact, my body is in no condition to do any of these things...

But I did break away from the wife and kids for just long enough to do a 22-mile ride down Hermosa Creek. It was stunningly beautiful, and fun. I like to challenge myself. Sometimes, when I get on a bike, it's too hard to be fun. But this trail rocked. It pretty much followed the creek. For you geographically challenged readers, water runs downhill, and so does the trail. I screamed down the hill with beautiful Colorado weather, a babbling stream that's frisky with snow run-off, and the mountains around me on all sides. Spring flowers were everywhere.

That's kind of like the early years of Java. Programming was fun. No pointers, a JVM to take out the trash, simple servlets, easy access to the Internet--all downhill. After c++ and CORBA, life was good again. So the first five years of Java were like the first ten miles of the hike. Sure, I might have to hop off of the bike to hop over a little snow drift, or step through a mountain stream, but the trail was simple. It followed the creek. I wasn't encumbered by a map, didn't have to do excessive training, or buy any special equiptment. (In truth, I in fact rented a full suspension bike, but I'll take a little artistic license here and pretend I was on my companion's old school Trek bike without even a front shock.) Java was like that. Simple and unencumbered.

Then, things got fast. The trail got steeper and more serious. The trail left the creek floor for short stretches, and we followed the cliffs along the creek. It was still fun...we were going mostly downhill. And it was still fast. We were insanely productive. We covered huge stretches of trail between stops. But it was getting a little more dangerous. We followed unprotected cliffs on either side of the creek, just a foot to the right or left. Java was like that, too. Though we whine about the problems with the Java platform, we actually built a tremendous number of serious applications. We had enough success that the whole industry jumped onto the trail. But some people crashed. Still, the risk-reward ratio was right in line.

And then we hit the hill. The creek went through a canyon that didn't leave enough space for a trail, so the trail went up, and we followed. After the first 3/4 of a mile, I thought I was going to die. I was having to get off the bike for longer and longer stretches to walk through rocky terrain that was difficult to peddle. It was definitely a whole lot less fun. Truth be told, we could have actually cut the trip short, but the promise of the trail held us captive. I'll admit that my next trip down that trail may be in a kayak.

Finally, we get to the point. This is where Java is today. After EJB and XML Schema and Namespaces and WebServices, we're getting maxed out. Some of us will spend all of our energy and die, right there on the trail. Others will stare longingly at the creek below, and wonder if there's not a better way to get down the trail. AOP, anyone? Maybe something a little bit less dramatic, like one of the dynamically typed languages? Some will take that uber-programmer and muscle their way up the hill. Others will try to find a motor to slap onto the mountain bike, like MDA or other frameworks that try to do all of the heavy lifting.

This is a serious point in Java's history. How will we handle the hill? Will we handle the hill? Some say that we're beyond a point of no return, and the creek will stay in the gorge, fully independent of any trail. It's a tall mountain that the average Java programmer will never climb. Others say that we just have to grind it out, and there are better times ahead.

I think that we've got to simplify. My book, Better, Faster, Lighter Java, comes out in a week or so. It's at the printers, and you can order it today. My premise is that you can make it easier to scale the hills by lightening your load. Most applications are simple, and we don't need to go through artificial steps to complicate them.

The real trail tapered off, screamed down a hill, and went right back down to a natural rhythm of a little up, and a whole lot of down. I think that the Java community actually has a fork in the trail. On the left is a narrow but simple trail that goes back down to the creek. On the right is a huge, wide trail that will accept any type of bike, but it goes straight up. We can abandon the current trail, of heavyweight EJB, and full-blown J2EE containers, but we've got to lighten up. We can use the work that we've done, and the knowledge that we've accumulated, and ride the momentum down for a while. Some fantastic simple, yet sophisticated frameworks lead the way. Spring, Hibernate, Kodo JDO, and IDEA are a mix of open source and commercial products that do it right. Or, we could get overly ambitious, and die on the hill. Think Tomcat with Spring. Think Pico. Maybe some developers are strong enough to make it up that hill, and many will doubtlessly try.

I'm going to lighten up. I'm ready to go downhill again.

This work is licensed under a Creative Commons License.