Highly recommended: Focus Night & Day Contact Lenses. I had pretty much given up on contact lenses as my eyes have become less tolerant over decades of staring at a computer monitor for mumble, mumble hours per day. After saving my pennies for Lasik, I decided the operation wasn’t right for me (it’s a cruder process than I imagined, generally resulting in less-than-20/20 vision and at-night “blooming” of bright objects, which I absolutely would hate). So I went on a mission of trying out all the “high-end” contacts. Even when I was younger, I was never able to wear any brand of contacts overnight; I’ve been wearing Night & Days since mid-July and now routinely wear them for a week or more at a time (I just went two weeks before taking them out the other day). The boxes are expensive, but you actually get 8 lenses per box, so the per-lens cost is not that much greater than other high-end lenses like Acuvue 2s or Bausch & Lomb PureVisions (which I would wear if I couldn’t get Day & Nights). If you wear contacts, try them out. For me, Acuvue’s feel better going in and for the first couple of hours, but after that, it’s all Night & Day.
It’s interesting to see the java bloggers are starting to agree that EJB isn’t a good idea.
There was another interesting thread about this a week ago, which is well summarized in James Strachan’s weblog.
One of the reasons that I embraced the .NET Framework stemmed from a real wake-up call I had about EJBs last year. I was contracted by a company to write an EJB-based product that integrated with a legacy mainframe system; I did so, it worked fine, they wanted to move ahead with a full implementation. But the CTO challenged me as to whether we could do it without EJBs. I said “Hey, they aren’t really that hard, you just got to know a couple of things.” But he made the point that there was no real clear need, in our case, for EJBs. So I moved ahead and headed the team that wrote a “plain vanilla” Java program: I had forgotten how good Java could be. We wrote a killer Web Service, met all our deadlines, and, as consultants, put ourselves out of work. (I guess that’s why I’ll never be rich: I’m not interested in being a Perma-Consultant.)
Anyway, a huge point for me is that EJBs increase edit-compile-debug cycle from seconds to minutes. Over the years, the task of doing enterprise work in Java has been like the proverbial frog that’s boiled in a pan of water that slowly gets hotter and hotter: It started out great and no single thing ruined it, but at some point, you realize that it doesn’t have to be this way. Switching from EJBs to “just” Java reduced our edit-deploy-debug time from minutes to seconds, simplified all aspects of the architecture, decreased deployment costs, and had killer scaling attributes.
I had originally jumped from MFC and C++ to Java precisely because with Java I felt like I had discovered in regards to things like network programming: “Hey, it doesn’t have to be as painful as they said.” Last year, I had that seem feeling with C# and .NET versus J2EE: here you have this new language and framework that seems to make enterprise-level development easier and the main thing keeping you in J2EE is the assertion that “it has to be this painful.” Well, I’ve been working in .NET on a daily basis for more than a year now and my conclusion is that it’s at least as good as J2EE in every aspect and better in most.
John Lam has written a cross-language “weaver” for adding aspects (as in aspect-oriented programming) into .NET languages. Aspects allow one to compose behavior based on the method signature of a target program. In that sense, they’re similar to .NET’s native attributes. The difference is that attribute behavior is restricted to programs that interpret that attribute, while aspects inject the behavior into the flow of an existing program. Thus, with attributes, programs like NUnit 2.0 can say “Which methods in this assembly are marked as test methods? Okay, call them all.” While with attributes, one can say “Generate trace output for every method call that returns an integer.” See my September 2001 review of AspectJ in Software Development (although note that I didn’t write that it was “the first aspect-oriented compiler,” which I believe is incorrect).
Just met with Ed Kaim and Melissa Hovis of Microsoft and Waggener Edstrom to discuss the .NET Compact Framework. Without violating NDA, I can say that it is my opinion that post-desktop form factors such as phone-enabled handhelds (especially with GPS or E911 location info) and tablets represent a huge market for innovative applications (the TabletPC is programmed with the full .NET Framework, but my point is that it’s essentially a post-desktop form factor). Although the .NET Compact Framework does not have everything in the .NET Base Class Library, notably some GDI+ stuff, and does not have all the capabilities of the .NET runtime (notably, COM Interop), it does not represent the same level of “downsizing” that one experiences going from Java Standard Edition to J2ME. In my experience, programming the .NET Compact Framework is very, very easy — in Thinking in C#, I have an appendix devoted to it, but half of what I say is, “This looks familiar, huh?”
In this meeting I heard something I hear a lot from vendors, though, which is that many programmers have lost their perspective on certain realities. In this case, I was told that developers complained because they could not use the ALT-TAB key combination to switch out of the PocketPC emulator; this makes perfect sense, since when you’re running in the emulator, you’re sending the ALT-TAB to the PocketPC OS, not to your desktop. And yet, programmers complained. I’ve also been seeing lately that Web Services programmers are sometimes ignoring the cost of transmitting a call over the network, which is a grave mistake.
As big a fan as I am of the precept that programmers shouldn’t be obsessed with hardware, I think it’s equally important to realize that we are bound to certain physical and market realities. While CPU and storage costs decrease at Moore’s rate or better, things like bandwidth and display capabilities are increasing at much, much lower rates. I’d submit that this creates a certain tension that, in turn, may give rise to the killer apps of the future.