OMG you put Java code in the view!!

One of the unique joys of developing anything with Java Server Pages is encountering the Scriptlet Police.

Scriptlets, as you probably know, are little bits of Java code embedded into the JSP. I think of JSPs as being servlets turned inside out. In a servlet, everything is Java by default, but you can throw in some HTML in the form of strings. In a JSP, on the other hand, everything is HTML by default, but you can throw in some Java in the form of scriptlets, like this:

<ul>
  <% for (Foo foo: listOfFoos) { %>
    <li><%= foo.getName() %></li>
  <% } %>
</ul>

But God forbid you do this and then admit it on a mail group or message board. Any hint that you're actually putting Java code in your JSP will attract a lecture from the Scriptlet Police, for example:

Question: "I am a complete JSP beginner. I am trying to use a java.util.List in a JSP page. What do I need to do to use classes other than ones in java.lang?"

Helpful answer 1: "Not to mention that this is not the best practice ;)"

Helpful answer 2: "FYI - if you are importing a List into a JSP, chances are pretty good that you are violating MVC principles."

and

Question: "I wish to access [a model attribute] in a scriptlet (within a JSP)."

Helpful answer: "It's stored as a request attribute. ... Unrelated to the concrete problem, I suggest to ask a new question wherein you ask how to achieve the functional requirement without the need to fall back to legacy practices."

The irony of course is that when the members of the Scriptlet Police write their own JSPs, they write something like this:

<ul>
  <c:forEach items="${listOfFoos}" var="foo">
    <li>${foo.name}</li>
  </c:forEach>
</ul>

Which of course is the exact same thing, just written in a slightly different "language" consisting of JSTL tags and JSP expression language (EL) expressions. So why is it verboten to write a loop as a scriptlet but not using JSTL?

If you're using Groovy and Grails, it becomes even more ironic. The code looks about the same, although the tag is called <g:each> instead of <c:forEach>. But the big difference is that the code inside the ${} is Groovy code, not some language that's been deliberately watered-down so as to make it difficult to implement "business logic" in the view.

The members of the Scriptlet Police think that they're enlightened. But in fact, they are confused. Someone told them a long time ago that they shouldn't put any "business logic" in the view, and somehow that got associated with "no Java in the view," because obviously Java is what you use to implement business logic, right? So in their minds, they are keeping business logic out of the view by only using JSP tags and Expression Language in their JSPs. In fact, instead of keeping business logic out of the view, they're only keeping Java out of the view, which isn't the same thing at all. But it's a simple criterion to apply (Expression Language good, Java bad) and enables them to avoid actually thinking about the difference between the view and... well, what?

What, because it's inevitable that there is going to business logic in the view. Applications exist in order to implement business logic. If you format one number as a currency and another as a percent, you're implementing business logic. If you only display the "Delete" button when the user is an administrator, you're implementing business logic. If you have hundreds of lines of JavaScript on your page, it's all but guaranteed that you have some business logic in there. If you have an N-tier application, you're going to have business logic in every single tier. So what's the point of all this worry about business logic in the view? What are we really trying to accomplish?

What's important isn't keeping business logic out of the view, but rather establishing some useful separation of responsibility among components. JSP is a view technology, so ideally we should limit its use to the view, and implement non-view-related logic elsewhere. For example, entitlement checks and form-saving logic are probably best implemented in a controller written in Java. If we tried to implement form-saving in JSP, we'd wind up with a JSP that had lots of logic paths and performed different functions depending on whether it was being called with GET or POST. It would no longer be a view and would be harder to understand and maintain than a simple view with two different Java controllers.

But as long as we limit ourselves to implementing view-related logic in the view, it doesn't really matter what language we use. Go ahead and write some scriptlets. Normal programming best practices still apply, of course; don't go cutting and pasting the same scriptlet into a dozen different JSPs. But don't worry that the scriptlets will pollute your view with "business logic." If a scriptlet is the best solution to your view problem, just do it.

Alex Papadimoulis also wrote about embracing business logic on his web site The Daily WTF.

Scala and Kotlin

I've been spending the last three years writing code in Scala. In general I've been pretty happy with the language. It's much more compact than Java, and its higher-level features, such as closures (which have been around forever but which were popularized, I think, by Ruby), enable me to discard several of the Java tools and frameworks that I've had to drag around. Scala also comes with a very powerful collection library that I use on just about every line of code.

Lately I've been following Kotlin, which looks very promising. I'm old enough to realize that this may just be a case of the grass looking greener on the other side of the fence. Every programming language has its flaws, and Scala is no exception. There's always the sense that maybe the next language will be The One. The One that does everything perfectly. The One that incorporates all that is good about Java and Scala and C# and C and C++ (well okay, maybe not C++), introduces exciting new concepts, yet has no egregious flaws (like green threads, or no reflection, or different-just-for-the-sake-of-being-different keywords, etc.), and for that matter, no minor ones either. A language the bridges the divide between OO and functional, and between OO and relational, and between functional and relational, and between relational and non-relational, and... Well, you get the idea.

Back to Kotlin. I'm hoping that Kotlin will give us most of the benefits of Scala, but without some of Scala's more unusual features.

Consider operators. C++ offered operator overloading, which meant that every math geek could now write "m1 * m2" to multiply two matrices instead of writing (in C) "matrixMultiply(m1, m2)". It also meant that the C++ designers could create a completely new I/O library, in which you don't write data or read it but rather shift it into or out of streams. You can even shift formatting functions into a stream to change its state! Unfortunately they declined to give this new I/O library the obvious name, Shift Happens. But what can I say, I wasn't on the team.

Anyway, with C++, you were limited to overloading a subset of the operators supported by C++. You could overload "+" and "-" and even "," (the comma operator, which most folks don't even realize is an operator), but not "." (the member selection operator) and "::" (scoping operator). There were lots of advantages to sticking with the existing operators. No changes were required to the parser, which must have been a major consideration for Bjarne Stroustrup, the guy who had to write the damn thing. Nor did Stroustrup have to worry about how random new operators might fit into the precedence table. The existing operators also had certain meanings, and so when used judiciously, could actually improve code readability. While "matrixMultiply(m1, m2)" has a fairly obvious meaning, "m1 * m2" is better, and shorter too.

Of course people often did not use operators judiciously, and James Gosling decided to leave the whole business out of Java, and that's where things stayed for about 10 years.

The along came Scala, which eliminates the distinction between methods and operators entirely. Method names can have any character in them. Literally any character. If you want to call your method ";" (normally the statement delimiter in Scala), you can do it:

def `;` { println("Don't try this at home") }

You have to enclose it in backquotes every time, so that Scala know you're calling your stupidly-named ";" method and not trying to end a statement. But it's possible.

Naturally this leads to some questions about how exactly these strangely-named functions should work.

If the programmer writes "a*b," how does Scala know that's "(a) * (b)" and not a method called "a*b"?

The method name can't be completely arbitrary. It must follow a prescribed format. If it starts with a letter, then it cannot include a non-alphanumeric character other than "_" unless those characters follow a "_". So a method called "a*b" is not allowed, but "a_*" is okay. If a method name starts with a non-alphanumeric character, then all of the characters must be non-alphanumeric. So "*" and "**" are both okay but "*a" is not. (However, I should note that these rules only apply to method names not enclosed in backquotes. If you are willing to use backquotes, then anything goes.)

How to the precedence rules work for unusual operators?

Precedence is determined by the first character of the method name. Except when it isn't; Scala requires some special rules so that precedence works as expected. If the operator name ends in "=" then it gets the precedence of "=". Unless it's "<=" or ">=" or "!=" or also starts with an "=" (like "==").

If I define an method called "-", is that the infix subtraction operator or the prefix negation operator?

Infix. To define the prefix negation operator, you have to create a method called "unary_-". Also, the only prefix operators that are allowed are the usual suspects: "+", "-", "!", and "~".

If I define a method called "++", is the pre-increment operator or the post-increment operator?

Okay, actually this is a trick question. Scala doesn't recognize the "++" and "--" operators as such. You can define a "++" method, but it won't do what you expect, that is, assign back to the variable on which it's called. To increment you must use "x += 1".

Method names ending in "=" are special. If you write "a += 3" and there is no method called "+=" on "a" then Scala will try to interpret the expression as "a = a + 3". This only works if the method name starts with a non-alphanumeric character that's not "=".

By far the strangest aspect of Scala's method-operator unification is that if the name of the method/operator ends in ":" (a colon), Scala invokes the method on the object to the right of the operator rather than the left. So while "a*b" means "a.*(b)", "a*:b" means "b.*:(a)". As far as I can figure, this was done solely so that the "::" operator could be used to build singly-linked lists.

Now I have to admit, when I first read the Scala language specification, I thought that method/operator unification was pretty cool, even with the quirky bits described above. But after a few years, I'm not so sure.

Obviously, method and operators cannot be completely unified, at least not in a language in the C family tree. People want precedence to work the way it does in C, more or less, and also want certain conventions retained (like += performing an assignment), so Scala has to recognize a lot of special cases. And Scala had to do away with the increment and decrement operators, which just didn't fit into the generalized model.

But the biggest problem with Scala's strategy is that non-standard operators have no implicit meaning. When we see "+" in the code, we read that as "plus," and we expect it to do act something like addition, or concatenation, or union. We would be very surprised if it, in fact, performed multiplication, or closed a file. That's why operators work: they are symbols that identify specific concepts or specific operations.

But what does the "/:" operator do? Would you have guessed "fold left?" That is what it does, but of course only if the object on the right is a Scala collection. If it's something else, then who knows, it's whatever that object defined. Anyone who's writing in Scala is probably using the collections constantly and has probably reconciled with "/:".

But what if you're writing something with Dispatch, an HTTP client library for Scala? Dispatch implements a typical Scala "domain-specific language," or DSL. In the context of Scala, a DSL is a block of code that looks nothing like Scala and is nearly impossible to read, yet somehow conforms to Scala's syntax rules and produces some desired effect. Let's say you wanted to parse the headers from the HTTP response. You might go looking for a method called parseHeaders or getHeaders or something like that, but you'd be out of luck. The method that introduces a header handler is called ">:+". How do you even pronounce that?

Getting back to Kotlin again. Kotlin takes a much more pragmatic approach to operator overloading. When designing Scala, Martin Odersky recognized that making "==" be the equality method wasn't going to work, because Java had already established that the equality method was named "equals." So in Scala, the "==" operator actually invokes the "equals" method (and cannot be redefined). Kotlin just extends this concept to the other operators as well. The "+" operator invokes the "plus" method, "%" invokes "mod," etc. Notably, the comparison operators "<", ">", etc. invoke compareTo, in keeping with Java's Comparable interface.

In taking this approach, Kotlin loses some flexibility. You can't define a ">:+" operator in Kotlin. But that isn't such a loss, and in exchange, you get some potentially more-useful features that Scala can't support. For example, Kotlin maps ".." to the "rangeTo" method, and maps "[]" to the methods "get" or "set" depending on context, and supports the increment and decrement operators. I think that Kotlin's approach will prove more useful practical over the long run.

No-NoSQL

Anyone who's been around for a little while knows that the idea of storing data outside of a relational database is hardly new. Unix, for example, stores essentially all of its data in flat files, often with keys. Have you looked at your /etc/passwd file lately? It's just a little database, and it certainly doesn't use SQL.

So I'm confused as to why the idea of a non-relational database is being treated by so many people as a novel idea. It's as if a generation of developers wrote a few web systems using the LAMP stack, noticed that MySQL wasn't ideal for everything, and concluded that the whole relational model was at fault and needed to be replaced. Is this increased attention simply due to the fact the this collection of non-relational data stores now has a name?

I think that we've all worked with a relational database that is big and slow. In my case, that would describe maybe half the databases that I've encountered. But those databases aren't big and slow because the relational model is bad. They're big and slow either because they aren't designed very well or because they are being used for something that's not a good fit for the relational model.

The fact that there are some relational databases that are slow and some use cases that don't call for a relational database doesn't mean that the relational model is inherently flawed. It just means that it's not the right solution for everything, which is something that can be said about every technology out there. Every technology is a compromise because, as is the case with almost everything that exists in the real world, optimizing the design to improve certain characteristics inevitably degrades others.

Even a cursory review of the available NoSQL databases strongly reinforces the notion that they are not overall better than relational databases, just different. They have been optimized for different use cases, and as a result, they are better-suited for some use cases than regular relational databases, but less suitable for others. And the optimizations tend to follow a pattern: almost all of the NoSQL offerings trade off functionality for speed. I can understand the motivation behind that, since relational databases are most often criticized for being slow. But it's important to understand what's being traded. MongoDB, for example, does not support multi-document transactions or queries. By omitting support for those features, MongoDB is able to deliver better performance for the features it does support. If you're basically storing independent documents and don't need to relate them in any way, then great. But if you want to make an atomic multi-document update at some point, you'll be out of luck. You'll have to roll your own transactions with version numbers or lock flags. VoltDB also trades off flexibility for speed. It's way faster than any traditional relational database, but that's because it runs entirely in memory and doesn't support locking or concurrency of any kind. If you're working with a relatively small data set and are only executing fairly simple queries, then you're golden. But it also has limitations that general-purpose databases don't.

I think it's also important to keep in mind that relational databases didn't spring up from nowhere. There were non-relational data stores like IMS long before there were relational databases. Relational databases were developed in response to the perceived flaws of those earlier database technologies. We've been here before.

So when I need to store some data, I'll probably think relational first. But since I might encounter a use case that would benefit from a different type of data store, I'll be happy to have NoSQL in my toolbox.

An Ode to My Macs

About 18 months ago, Sara and I bought new Macs.

I know it was about 18 months ago because I just finished paying for them. Apple and Barclaycard were offering 0% financing for 18 months on purchases over some amount. An amount we could have reached with just one Mac, but since we were both feeling limited by our computers for various reasons, we decided to get two.

These two Macs are, without a doubt, the nicest and most useful computers I've ever bought. I suppose some of that is due to their being the newest, but there have been plenty of computers that I've bought new but that have merely been okay. That includes most of the Windows PCs that I've bought over the years.

The problem with all the Windows PCs that I've ever owned is that they've all been beige boxes. Sometimes they haven't been strictly beige, but they've all had a certain plasticky, generic feel to them. They've all come with generic keyboards, generic mice, generic power cords. Many of them have booted to a desktop overflowing with crudware. (John Dvorak once pointed out how absurd it was to spend a thousand dollars or more on a computer and then have to immediately run a program called "PC Decrapifier" on it just to get it into a usable state.)

I've had four Macs prior to these two--two laptops (including one PowerPC machine) and two iMacs, and they've all been quite good, certainly way nicer than any of the PCs I've owned. But I found the white MacBook a little underpowered, due to its relatively slow processor (it was an original Core Duo) and small screen, and the 24" iMac was limited to 4G of RAM, which was fine for a while, but once Sara started doing more photography and keeping Lightroom open all the time, our inability to increase the RAM became a real problem.

My new machine is a 15" MacBook Pro with a 2.66GHz Intel i7 dual-core processor, 8G of RAM, and a 128G SSD. For the first time in my life, my primary computer is a laptop. It's a beautiful machine and works flawlessly. The SSD is amazing; the system only takes about 10 seconds to boot, and programs open almost instantaneously. The memory is sufficient to keep all the programs I'm likely to use open at once. The battery lasts an exceptionally long time considering that my usage tends to be processor- and disk-heavy (compiling and running programs). The screen is gorgeous and has tons of contrast.

Sara's new computer is, for the first time, substantially more powerful than mine. She has a 27" iMac with a 2.8GHz quad-core i7, 16G of RAM, and a 1TB hard drive. Not even Lightroom can slow down this machine. The 27" screen is absolutely amazing.

But despite the enormous screen, the machine just doesn't take up that much space. It's a big screen, but that's it. Ever since I bought my first iMac (this is the third), I've been so happy not to have a big ugly box sitting on the desk or on the floor with a bunch of wires everywhere. And speaking of wires, this iMac has exactly one: the power cord. The keyboard and mouse are both wireless. And because this is an iMac and not a beige-box PC, the plug on the computer end of the power cord is specially designed to fit into a receptacle in the back of the computer such that nothing but the cord itself is left sticking out. The folks at Apple care how the back of the machine looks.

And the iMac is quiet. It's normal for a laptop computer to be quiet, especially one with an SSD. Their low-power processors don't generate a lot of heat in the first place, and spinning fans to dissipate it takes energy. The iMac is plugged into the wall and could spin fans 24/7 if it wanted. But it doesn't, because it's been designed to work as a little convection heater: heated air flows up through the case and out a vent at the top, while cooler air gets pulled in through a grille at the bottom. Most of the time the iMac is silent save for the slight whir of the hard drive. If I start doing lots of work in Lightroom, then the fans will spin up, but even then the noise is not obtrusive, and in any case I'm obviously doing something with the computer; it's not like it's making noise while I'm trying to watch TV, which is something that always irritated me with my Windows PCs.

Anyway, thanks to Apple for producing such great gear. Sara and I will enjoy these two Macs for a long time.

Best Album Closers

I'm not a musician, but if I was one, I think that I'd want each album to stand on its own as a complete work instead of just being a random bag of singles. I'd want people to know the album ("Sgt. Pepper") and not a few songs from it ("the album with A Day in the Life on it"). I'd want to be recognized for having excelled at the difficult task of putting together an hour or more of music that people want to hear. Not to mention that being known for making great albums makes it more likely that those albums will remain available instead of disappearing as the singles are rolled up into "Greatest Hits of the 21st Century" collections.

By the way, this idea of an artist either being known for complete works or for singles is hardly new. Bach is known for complete works. Other composers are forgotten but for an entry in the encyclopedia and one or two pieces in the local symphony's "An Evening of Baroque" program (the classical music equivalent of those "Greatest Hits" collections). Search for Jean-Joseph Mouret on iTunes and you'll find dozens of performances of the same two-minute piece of music, which you might recognize as the theme from Masterpiece Theater.

I think that the last track of an album says a lot about how the composer approached the work. One random-bag albums, the first track is usually the strongest song, so as to pull in people who are only giving the album a 30-second preview, and the last track is usually nothing special, since nobody is expected to listen to the album all the way through. But when the composer is taking the album as a complete work, the last track is important because it's the last thing that listeners will hear.

So I like albums that have a good closer. I've put together this list of them. Please comment and add any that you know, so I can check them out.

• Billy Joel, Piano Man (Captain Jack)


• The Beatles, Sgt. Pepper's Lonely Hearts Club Band (A Day in the Life)


• The New Pornographers, Twin Cinema (Stacked Crooked)


• Bruce Springsteen, Born to Run (Jungleland)


• Foo Fighters, The Color and the Shape (New Way Home)


• Coldplay, A Rush of Blood to the Head (Amsterdam)


• Rush, Signals (Countdown)


• Jackson Browne, Running on Empty (The Load-Out/Stay)


• Nirvana, Nevermind (Something in the Way)


• The Shins, Wincing the Night Away (A Comet Appears)


• Oasis, (What's the Story) Morning Glory? (Champagne Supernova)


• Tori Amos, Under the Pink (Yes, Anastasia)

Here are some albums that have the title track in the last position.

• Sarah McLachlan, Fumbling Towards Ecstasy


• Sinead O'Connor, I Do Not Want What I Haven't Got


• Stars, In Our Bedroom After the War


• Steely Dan, The Royal Scam


• Tori Amos, Little Earthquakes

How to make a YouTube video that no one will want to watch

Let's say you want to make a YouTube video that no one will want to watch. How could you do that?

First, make sure that your video has lots of loud, obnoxious music, especially if your video depicts something that normally has nothing to do with music. People might like your video of your dog and cat playing on the floor together, so why not ruin it by replacing the sound with Ted Nugent? For extra points, dial the gain up until it distorts. It's important to choose the right music, too. You don't want something with a quiet intro. Ideally you want to lure people into clicking on your video, then hammer them with decibels so that they jump out of their seats and scramble for the volume control. As a side benefit, you'll help the economic recovery by exposing people who are browsing YouTube at the office when they should be working.

You also want to go for the worst quality possible. Find lots of videos that are already low-quality, then re-encode them at an even lower bit rate. Twice! You can also use this opportunity to screw up the aspect ratio: if the original video was wide, then squeeze it so it's narrow, or vice-versa. If you quickly cut between dozens of low-quality clips, then the viewer will never know what's happening!

Better yet, don't even use video. Just make your "video" a long slide show of still photos. Programs that generate slide shows, like iPhoto, often add some hokey pan, zoom, and transition effects, so remember to shut those off, since they may make the slide show (barely) watchable. Of course, just because you've successfully tricked the user into watching a slide show when they wanted a video doesn't mean that you should neglect the other points. You should still include inappropriate, high-volume music and only select low-quality photos for your show.

Using still photos instead of video works because it makes the user feel duped, which is a fantastic turn-off. You can achieve the same effect by using your video's thumbnail image and description to mislead visitors. Everyone knows that YouTube generates the thumbnail image from the middle of the video, so put a high-quality photo of a swimsuit babe on the screen for a few seconds, right at that point. For the description, enter: "This video is all about pussy!" Won't they feel fooled when they click on the video and get to watch your amateur reporting from the local cat show!

Another way to make users pay for clicking on your video is to use half the video for your own stupid title and credits sequence. There are many ways to drag this on. Users already know what your video is called, but that doesn't mean that it shouldn't be on the screen or five or ten seconds anyway. Lots of moving-text effects can waste a lot of time too. Have the title scroll in from the bottom, Star Wars-style. Then plug your web site, make some call outs to your friends, identify the video to which you're "responding," and give credit to the artist who unknowingly provided the sound track without compensation from you. There's no reason not to take as long as possible with the title sequence. Storage and bandwidth are cheap!

Now maybe you're thinking that this all seems too hard. It's tough to gather together all that loud music and all those crummy still photos and put it all together into a video with a long title sequence. Fortunately there's another way to make crappy, boring videos on the cheap. All you need to do is mount your camera on top of your monitor (iMac users can just use the built-in camera), look straight into it, and talk forever about something that's incredibly boring. Include lots of ums and ahs so we all know that you're not used to public speaking and will never be able to work in broadcasting. And provide your viewers with long-winded descriptions of things instead of actually using the camera to show them. Just because this is video doesn't mean that you can't treat it as radio!

The slow march of technology

I had some dental work done recently. I had crowns put on four teeth in the back of my mouth, two on either side. Since crowning teeth is a one-way trip, I did some research before I went forward with it. While reading about crowns, I also found information about dental implants. Implants are fake teeth, but unlike old-fashioned bridges or dentures, which receive support from the patient's other teeth and gums, implants are actually screwed into the patient's jaw. The actual tooth that extends above the gum line is typically made of porcelain and is indistinguishable from a natural tooth.

If you think about it for a minute, implants are pretty amazing. They're completely artificial aftermarket parts for your body that work at least as well as the original equipment, and unlike natural teeth, they can't decay. Losing teeth will always be a drag, but now you can have them replaced.

When I was growing up in the 1970s, I read a lot of books and magazines that made predictions about what life would be like in the near future. There would be moon bases, and artificial intelligence, and supersonic airplanes cruising through the sky, and flying cars, and abundant cheap energy from nuclear fusion.

Obviously pretty much none of that came to pass, but it's not hard to fault the writers of that period for making such predictions. The world had changed drastically in their lifetimes. They witnessed the arrival of television, the proliferation of the automobile and the construction extensive road networks (including the interstate highway system), the breaking of the sound barrier and a reduction in intercontinental travel time from weeks or days to hours, and new skyscrapers reaching ever-greater heights, and the development of the atomic bomb and nuclear power. The United States was landing human beings on the moon. It was reasonable to think that airplanes would keep getting faster, that the scientists who mastered fission would figure out fusion, that buildings would continue to climb higher, and that that human beings would travel to farther planets and perhaps even to other stars.

As it turned out, there were practical issues that got in the way. Supersonic aircraft are loud and inefficient. Fusion turned out to be really hard. Mile-high skyscrapers are disproportionately expensive. Moon bases are useless, and other planets are just too far away. And civilization in general turned away from the industrial-age quest to build bigger, taller, faster. Instead, we spent the next decades focused on information and communication. We're not traveling to the stars yet, but if you're reading this, you almost certainly have your own Star Trek-style personal communicator that you can use to reach pretty much anyone in the world from anywhere you happen to be.

However, something that I've noticed over time is that people are still working on the bigger, taller, faster stuff. It's showing up. It's just taking a little longer.

Something that you may not realize is that for the past eight years, without interruption, human beings have been living and working in an orbital space station. Spacecraft launched from, well, let's call them spaceports, in Florida and Kazakhstan take new people and supplies up to the station and bring returning folks home. As of this writing, these spacecraft have made a total of 77 trips to the station and back. The space station has undergone continuous expansion and now looks like something out of a science fiction movie. Really, have a look at it. But it's real. That's pretty amazing. As for the science that goes on there, we don't hear too much about it, and maybe it isn't going to change anyone's life. But the research isn't the story; the story is that launching people into orbit and keeping them there for months at a time has become routine.

Nobody's built a mile-high skyscraper yet, but there's one that's a half-mile high called Burj Dubai. It dwarfs by a considerable margin anything previously built by human beings, neatly ending all the debates over whether it's more important to have the tallest building or tallest "free-standing structure" or tallest structure of any kind and whether or not antennas count toward building height. It's made of reinforced concrete instead of steel, so it doesn't have the problems with flexing in the wind that a supertall steel building would have. It's only recently that engineers have been able to build anything even approaching this height using concrete, but it's the future of construction. And Burj Dubai isn't an isolated case of extreme construction; in recent years, supertall skyscrapers have been built or at least started in Taiwan (Taipei 101), China (Shanghai World Financial Center), Malaysia (Petronas Twin Towers), Russia (Russia Tower), Chicago (Chicago Spire), and New York (Freedom Tower). Saudia Arabia is planning the first true mile-high skyscraper, and Kuwait is building a Burj Dubai-class structure. Could people eventually start building gigantic archologies, buildings housing entire neighborhoods or even cities? We're a long away from that. But at least after a half-century, the 100-story barrier has been decisively broken.

On the nuclear energy front, scientists have been diligently chipping away at the engineering challenges of fusion power. Just last year work was completed on the first fusion reactor engineered to generate more power than it consumes. The reactor, which has a name that only a bureaucrat could love--the National Ignition Facility--can only generate fusion power in bursts, but is nevertheless an important milestone on the road to commercially viable fusion power. Meanwhile work has begun on another reactor, one with an equally-bureaucratic name: International Thermonuclear Experimental Reactor, or ITER. ITER is designed to be an honest-to-God fusion power plant, producing 500 megawatts of power for up to 1,000 seconds. It won't actually generate electricity, but if the engineers can keep the reactor going for 16 minutes, it's easy to imagine the next reactor going for 16 hours or 16 days.

Something that all of these projects have in common is that they're all money-losers. The ISS, NIF, and ITER are government-funded research projects and therefore are expensive and wasteful almost by definition. The Burj Dubai is ostensibly a commercial enterprise, but it is clearly a monument to excess built at the height of a real-estate boom in a country where the line between private and government funding is blurry. It remains to be seen whether it will ever able to produce a return for its investors.

But on the other hand, the Internet was originally a government-funded research project too. Governments also used to be the only players in the rocket-launching business, and now there are several for-profit corporations that will put your satellite in orbit for you. So maybe we're just in an engineering lull. After all, when people watched Star Trek in the 1960s, they probably didn't think that inside of 50 years they'd have personal access to communication equipment that puts anything on the Enterprise to shame. (Captain Kirk's communicator can only reach his other Enterprise crew members. Lame.) Perhaps 50 years from now, people will be thinking, wow, that Mr. Fusion power plant from Back to the Future looks so clunky compared to what we have now!