NASA's Wayne Hale offers a fascinating discussion of the "black zones" in crewed spaceflight - the periods during flight when saving the crew from an emergency is impossible, and how the various types of vehicles we've flown over the years compare. (The original blog postings can be found at NASA Blogs, but SpaceRef has performed a useful service by collecting the multiple segments of the "Black Zones" piece into a single page.)
Sunday, November 23, 2008
I recently returned to my explorations of the Mandelbrot fractals, using my custom, multi-processor implementation of the classic algorithm. One rude surprise: Java's Bicubic interpolation, which my code had counted-on for antialiasing the images, has spontaneously ceased to work somewhere in the couple of years since I last went diving in Dr. Mandelbrot's seas. One custom down-sampler later, and I'm back in business, but still wondering what happened to the Bicubic interpolation support. (Some Google searches confirm the issue, but don't explain why it ever worked, or how to get it working again.)
Anyway, some of these images are new, while some are higher-resolution renderings of images I'd previously produced. All use 16:1 antialiasing for clarity. Unfortunately, Blogger has scaled-down the images in accordance with its internal size limits. To see these, and other Mandelbrot images, at full resolution, visit my Mandelbrot fractals page.
The image above had to be computed to a depth of 2.5 million iterations. At lesser depths, the structure appears to be a part of the Mandelbrot set. How many other apparent parts of the set would turn-out not to be, if they were examined deeply enough?
Tuesday, November 4, 2008
Barack Obama will be President of the United States of America. An eight year nightmare is ending, and what an ending. It'll take a while to fully sink in for me.... We have a staggering mess to cleanup, but now the process can begin. At long last. Wow.
And just to anticipate a question: No, I don't trust electronic voting machines one iota more now than I did before the candidate I supported won, and neither should you.
Monday, November 3, 2008
My show of photographs over at the New World Deli & Café continues, basically because the owners like the look of my work on their walls. Which suits me fine. The longer it's up, the more time there is for confidence in the economy to grow to the point that some people can think about spending serious money on art again. And, wandering in on Saturday for a meal and a chance to spend a few hours reading a good book (The Eternal Frontier by Tim Flannery), what to my wondering eyes should appear but a "SOLD" sign on one of the canvases. Specifically, "Lake, Turtle, Sunset", artist's proof no. 1. It was purchased by the Café's owners. Here's wishing them many years of enjoyment from it.
I'm still operating at a significant loss on this show (no surprise), but it's nice to sell a piece, regardless.
Tuesday, October 28, 2008
I was just startled from my work by a running volley of explosions coming from south of the U.T. Austin Tower, where I work. I had no idea what they were, but they were coming fast and furious, echoing off of neighboring buildings and making themselves very clearly heard from my north facing office on the 25th floor. I went to the south-facing windows in our elevator lobby / conference room to find that the brilliant explosions were occurring directly outside of our windows. If I'd opened one of the windows (it's an old building, so we do have windows that open), the smoke and burning projectiles would have come right in. As it was, I could hear material pelting the window.
It turns out that the campus was staging a fireworks display for some event being held down on the South Mall, below the tower. The fireworks were being launched almost straight-up the length of the Tower and were bursting at heights ranging from the 25th floor and up. Until you've seen fireworks from inside the exploding balls of color, believe me, you have not seen fireworks.
Had I only known this was going to happen, I'd've brought proper camera equipment. As is, you'll have to settle for the vague impression shown above, which was captured by the camera in my iPhone through our permanently grungy windows.
Saturday, October 25, 2008
Friday, October 24, 2008
Tuesday, October 21, 2008
51 Orionid meteors seen between between 4:00 AM and 6:44 this morning. Air thick and wet. (95% humidity, condensing.) Moon like a giant nightlight with no "off" switch. Nonetheless, I saw 51 little pieces of Haley's comet burn-up. Not bad, all things considered. And the new lens warmer worked like a champ. Without it, all I'd've photographed would have been the dew on the lens. With it... well, it remains to be seen what I did photograph, but it wasn't dew.
The Bamberger Ranch Preserve's main valley seen by moonlight.
Five meteors were photographed, but the moonlight made them too faint to be interesting.
Tuesday, September 30, 2008
Qwicap—the Java web development "framework" that advances the (apparently) unpopular idea that the structure of a web application should be no more dictated, or even affected, by sending a web page to a user and processing the resulting input than a conventional application is affected by reading from, or writing to, a file*—turned five years old today.
Work on it began June 4th, 2003 while I was a member of U.T. Austin's Networking group, and the first plausibly complete version (1.0) was ready four months later, on September 30, 2003. It was open-sourced a little less than three years later, in August of 2005, with the release of version 1.3. The current version, as of last Friday, is 1.4b25. (Work on 1.4 has been ongoing since the beginning of 2006, which makes it a fine example of setting too many goals for one release of a product. I anticipate declaring it finished as soon as there's time to give its multi-lingual features a good workout.)
From the start, Qwicap's development was driven by the goals of simplicity, security and standards-compliance. I believe it has proved that those are not opposing concerns, as it delivers first-rate intrinsic security, by far the simplest development experience of any Java web framework I've seen, and compliance with all relevant IETF and W3C standards. The design decisions that followed from those goals, especially the simplicity, mean that Qwicap will never be suitable for developing, say, the web interface for Bank of America, but they make it a very good choice for developing the hundreds of much smaller web applications that most large organizations use internally, or to serve other relatively small user communities.
It'd be an enormous pain in the ass if conventional applications had to exit after every read or write operation they performed, and then start over from scratch when they were later notified that the read or write had completed. (That description may sound somewhat similar to asynchronous I/O, but even that doesn't require the application to exit between I/O operations.) For some reason, however, it is commonly accepted that web applications should have to operate in exactly that manner, if you understand the writes to be equivalent to sending web pages to users, and reads to be equivalent to acquiring the input produced by those web pages.
Why have web application developers been willing to have such an absurd burden dumped in their laps? The fact that many of us started by writing CGIs may have something to do with it, but that was a long time ago – there's been ample time to reconsider the CGI structure since then. Scalability is probably one reason, but what percentage of the web applications developed in the world really need to scale to thousands of concurrent users? My belief is that it's a small percentage, and that the tools suited to high scalability aren't ideal for smaller apps. HTTP's statelessness may be another reason for believing that it's appropriate to process each hit in isolation, but how many web applications are, or can be, truly stateless? Reality is inherently state-rich and I don't believe that most web applications can really get away from that, nor do I believe that it's generally worth trying to do so.
Qwicap was, and is, my response to that absurd burden. Its most basic principle is that sending a web page to a user and obtaining the resulting input should be a blocking operation – the application should simply halt after sending a web page, and it should resume exactly where it left off when the user's input from that page arrives. Not so much as a local variable should be disturbed in the process. It shouldn't be any different from the blocking that automatically occurs when a program reads from, or writes to, a file or stream.
Of course, for some purposes, blocking I/O isn't the most efficient approach to I/O, but it is the hands down winner for most applications. I imagine that most developers have never done anything other than blocking I/O. By the same token, I believe that most web application developers should never have to do anything other than blocking user interaction. Qwicap makes that possible. Therefore, a Qwicap web application is not only a set of plain-old-Java-objects (POJO), but is also a plain-old-application that begins execution at its "main" method, interacts with the user when it needs to, and exits when it has accomplished its purpose. It'd be hard to make things any simpler than that.
Nonetheless, gentle reader, you'll have noticed that Qwicap has not taken the industry by storm. I don't think the industry is even aware of it. Well, I've never been any damn good at self-promotion (I really hate the idea, in fact, and I don't even like writing this post), so Qwicap's obscurity is, perhaps, unsurprising. But, if any of the above struck a chord with you, take a look at Qwicap, and let me know how it goes. (What works? What doesn't? What do you find yourself doing repeatedly or clumsily that Qwicap might simplify or even handle for you?) Over the years, I've incorporated a lot of feedback from local developers into Qwicap's design and/or API, and I remain interested in incorporating more developer feedback, where possible.
Monday, September 29, 2008
Congratulations to SpaceX on the first successful flight of their Falcon 1 launch vehicle. Decreasing launch costs to ⅓ or ¼ of current costs is quite a goal, and their road to success hasn't been cheap or easy. Meanwhile, the boldness of their plans, including the Falcon 9 launch vehicles and the 7-person Dragon capsule, is impressive, along with their willingness to pursue these projects in parallel. Here's wishing the folks at SpaceX continued success.
Sunday, September 21, 2008
A perpetually current lunar illumination table, that always shows the lunar illuminations for the current month. All illuminations represent the state of the moon at local midnight, which is why the illumination images span day boundaries.