Matt Woodward's Blog
ColdFusion, OOP, and Miscellaneous Other Stuff
- Home
- About
- Contact
-
Archives
June 2008 (13) May 2008 (13) April 2008 (4) March 2008 (17) February 2008 (9) January 2008 (13) December 2007 (2)
Flash/Flex Remoting on Open BlueDragon
Another Open BlueDragon screencast, this one showing how integrating BlazeDS and OpenBD enables remoting from Flex over HTTPService (CFML page) and RemoteObject (CFC). Paul Bonfanti wrote the adapter that allows BlazeDS to hit a CFC as a remote object. Cool stuff!
Flash/Flex Remoting With Open BlueDragon from Matthew Woodward on Vimeo.
And the Worst Web Site of the Day Award Goes to ...
Wow. Just wow. This is some awful, awful stuff. No offense to whomever created this monstrosity, but seriously, you're better off not having a site than having this one. The typo under the "Under Construction" gif is just icing on the cake.
Connecting to Cisco VPN on Ubuntu
Made yet another step forward in my pursuit of full-time Linux usage today, namely connecting to a Cisco VPN. I did try the vpnc application that several people suggested but, to put it in technical terms, it "didn't like" our VPN hardware. (I'm sure there's just some setting that needs to be tweaked.) It imported my PCF file fine but would always timeout on the connection.
So I got a hold of the official Cisco VPN client for Linux (version 4.8.01), and while it did need a bit of compiling and a patch applied for Ubuntu 8.04, it works great! I did find one blog post in particular that was helpful (thanks Arun!), and if you get an error on Ubuntu 8.04 (which I didn't) you might check out another post on Arun's blog.
Yes, you do have to fire the VPN client up from a terminal so it's not as pretty as the Mac version, but it works just fine and is overflowing with geek cred.
Since I also fixed the LDAP lookup issue in Evolution that I mentioned in my post yesterday, I think the remaining piece of the puzzle is finding something that's compatible with Microsoft Messenger (not the public network side of it), which is a huge nice to have but might be asking a bit much.
Connecting to Exchange from Linux with Evolution
I've always had a pretty non-plussed reaction to Evolution as a mail client for Linux, much preferring the simplicity of Thunderbird, but that opinion changed substantially today when I was listening to LugRadio (sad to see the LugRadio guys calling it quits!) and they explained in detail how Evolution connects to Exchange.
I was always under the assumption that Evolution connected to Exchange only if you enabled POP access on the server, which isn't an option in my case (and really isn't "connecting to Exchange" in any real sense at all). I was rather amazed to hear that it doesn't use POP, but instead uses the WebDAV API for Outlook Web Access. (Older versions of Evolution did really nasty screen scraping of OWA from what I understand.)
So I decided to give it a whirl and sure enough, it works! You just plug in your credentials and the URL to your OWA server and everything works great. I'm having trouble connecting to LDAP for addresses but that's a rather minor issue. Even the calendar works!
One step closer to using Linux full time. ;-) Next up, the Cisco VPN.
Code Quality, Architecture, Archaeology, and Free Software
I read a pair of articles today courtesy of my daily ACM tech notes newsletter (join ACM now if you aren't already a member--it's an amazing resource on a bunch of different levels). Even though they were listed separately I saw them as related in an interesting way, and it got me thinking about a variety of things that have been formulating in my head for a while so the time seemed right to try and share some of these thoughts in a semi-coherent fashion.
As is probably no surprise to people who know me or have had any interaction with me in the past year or so, I've been thinking a lot about the importance of free software (which is a preferable term over "open source") on a much bigger scale. I've always been a big fan of free software but for various reasons and through various influences, free software for me has become less of a fascination and more of a firmly held belief. Software is everywhere, it has (or can have) a profound impact on every aspect of society, and because of this power I believe we have to be increasingly cognizant of what software does, the reach it has, whether or not we're free to use it as we wish and, more importantly, whether or not we're free to verify what it's doing for practical or more purely academic reasons.
First and foremost, free software isn't about getting something free of charge. That's not even a consideration in my mind. Free software is about transparency and openness, it's about freedom of choice, and it's about the freedom to share with and learn from one another. I have a much greater interest these days in learning things by studying code and subsequently using that code than I do in paying someone for a product that I may use only in a restricted way and have no ability to see what's going on inside the software.
As Richard Stallman says in many of his talks, software started out in the best traditions of academia and programmers shared knowledge freely. Somewhere along the line for some factions of programmers, software became more about intellectual property and less about learning and sharing, and these two different philosophies are what we see playing both against and with one another in the software industry today. Given the degree to which free software is influencing and being integrated into traditionally proprietary segments of the industry it's clear that the free software movement is making inroads. In some cases the uneasy partnership between proprietary and free software is far more about marketing than it is about freedom, while in other cases there is true synergy between what some would call the Utopian aspects of the free software movement and more commercial interests.
I hope that's a nice background into how I view free software and it may even shed some light on some of what I've been saying and doing over the past few months. The real reason for those few paragraphs, however, was to provide a backdrop for the discussion of the two articles I mentioned above, namely "Software's Dirty Little Secret," which is an interview with Grady Booch on the Scientific American web site (a CFML powered site no less!), and the even more scary sounding "Flaws in medical coding can kill: Spread of computers creates new dangers, FDA officials warn" from the Baltimore Sun's web site.
I'll start with the scarier of the two first, which opens with the rather gripping line, "After a routine piece of medical equipment started mysteriously killing hospital patients a few years ago, the federal government turned to a small team of its software experts in suburban Maryland for help." Now I don't know about you, but even the coding I do may seem life and death at times, in the grand scheme of things it's rather inconsequential and, regardless of how it may feel in the heat of a tense project, it certainly won't literally mean life or death to anyone if I have a bug somewhere in my code.
FDA recalls on medical devices were previously due solely to mechanical failures in the devices, but now there are an increasing number of recalls based on software problems. To quote Larry Kessler, director of the FDA's Office of Science and Engineering Laboratories, "Where it gets to be scary is, we used to have more human intervention. With software doing more now, we need to have a lower tolerance for mistakes." And perhaps more ominous is a quotation from Paul Anderson, president of engineering at a company that makes forensic software to detect errors in medical devices: "If architects worked this way, they'd only be able to find flaws by building a building and then watching it fall down."
Not a ringing endorsement of how we do things in our discipline, and it goes right to the heart (literally) about the importance of software in modern society. People with embedded medical devices literally rely on software, written by human beings potentially under unrealistic deadlines and all the other pressures that are commonplace in software development, to live. I can't even begin to imagine how differently I'd think about the code I write if I knew it was going to be keeping someone alive, and even with that in mind, mistakes are still making their way into medical device software. Clearly a change in how we do things is in order, and you can probably guess what in my opinion a big part of the solution must be.
This leads directly into the interview with Grady Booch, who is a fellow at IBM and a "self-proclaimed 'software archaeologist.'" Booch reaches many of the same conclusions as the FDA software experts: how we're doing things isn't working. In the first article the solution pointed mostly towards extensive and highly rigorous testing, which is of course is of vital importance in general and particularly in the medical field. Booch is focused more on the mainstream consumer device segment of the software world and looks at things a bit differently, but again uses more traditional engineering and architecture disciplines as a point of comparison.
So what's the dirty little secret in software? There's little to no discipline in our discipline.
To be fair, software development has evolved largely through trial and error since its inception, but the problem Booch sees is that the bulk of this trial-and-error knowledge exists in the brains of the people who have been through it as opposed to in publicly available resources. (Keep that "publicly available" bit in mind because we'll come back to it later.)
If software has architecture, it's more by chance than by design, and this may have been tolerable for the first few decades of the software age. Now however, Booch states, "society ... runs on software," and much of that software is developed by hook or by crook over a period of years without much regard to its initial architecture let alone how it will be maintained as it ages. In many cases, Booch points out, companies are their software. Google and eBay, for example, don't have any tangible products to speak of, and since these companies in turn drive the economy, a lot is riding on the roughly 33 billion lines of code produced in the world each year.
I encourage you to read both of these articles in their entirety to get a real sense of how important software is to society. If you haven't considered this before, now is the time, and once you start getting a sense of it I guarantee you'll start thinking about how you write your seemingly inconsequential code a whole lot differently. From the small applications we write that drive our companies, to the communications devices we rely on to connect to one another, to the voting machines that we entrust to accurately record our choices for our national and world leaders, to the medical devices some of us rely upon to live, software is a big deal, and programmers are entrusted with a huge responsibility that will only become more massive as every aspect of society becomes nearly completely reliant upon software to function.
Now that I have everyone scared, motivated, or hopefully a bit of both, we'll turn back to free/open source software because I think it's an absolutely critical part of the discussion. Booch (from the "Software's Dirty Little Secret" interview) calls himself a "software archaeologist," and I thought his description of what this means was absolutely fascinating. With Booch, as with Stallman, it seems that software is about sharing and learning. For Stallman the sharing and learning leans perhaps a bit more towards the philosophical side, while for Booch there is a very practical aspect of sharing and learning: how else are we going to learn from our mistakes over time, and how else are we going to finally begin to create the architectural manuals of our discipline?
One computer mecca that I hope to visit someday very soon is the Computer History Museum in Mountain View, CA. I'm a total geek when it comes to old computer hardware and the evolution of computers, and how far we've come so quickly fascinates me to no end. Booch has another idea that I find extremely compelling: in addition to the hardware history museum, we need a software history museum. Imagine what we could learn from studying the source code of things like early operating systems and early versions of programs that we still use today (how much of Word 1.0 code is still in Word 2008?), and how we could all benefit from having access to a historical timeline of how software has been developed over our relatively short history as a discipline.
This of course presumes that all this code would be made publicly available. Much of it likely never will be, which is tremendously regrettable in my opinion. Companies with historical gems of proprietary software that no longer have commercial value should figure out a way to set this knowledge in the form of code free, and free/open source projects must each have stewards to record the history of the project and the lessons learned and carry these forward. We all spend far too much time writing code and far too little time sharing with and learning from one another, and if we don't share everything we can, our collective knowledge suffers greatly for it.
Free software is the key to learning and sharing, but it's also the key to surviving as a society. We all rely on software a great deal every day and although that fact has probably been in the back of all of our minds for quite some time, it didn't really hit home for me personally until I read these two articles in succession. The back of our minds isn't where such an important notion belongs, and behind compilers isn't where something as important as software belongs. Eric S. Raymond is famous for the statement, "Given enough eyeballs, all bugs are shallow." As we move forward through time and depend on software for nearly everything, this statement becomes far more than a quaint Utopian ideal held by the fringe faction of the software world. It's an ideal that we all need to move firmly into the practical realm to improve our coding practices, our discipline, and our society as a whole.
Screencast: Building Open BlueDragon WAR from Source on Mac OS X
Since we're still getting started on the Open BlueDragon project and don't have an official release cycle quite yet, if you want the latest and greatest code you'll have to grab it from the source, and you'll likely want to build a WAR for deployment to a Java application server.
Don't fret; it's very easy! I did a quick (7 minute) screencast showing how to build a WAR for Open BlueDragon directly from the source code using Eclipse on OS X. I'm going to try to do one for Windows and Ubuntu as well, and I'll follow it up with another showing how to deploy the WAR to various Java application servers and where to put your CFML code.
I'm embedding the video below or you can go to Vimeo to watch it in a larger size.
Build Open BlueDragon WAR from Source on Mac OS X from Matthew Woodward on Vimeo.
Posted 6/25/08 @ 9:43 AM by Matt Woodward
Stop OS X Archive Utility from Automatically Unzipping Zipped JAR Files
Mac OS X tries to be as helpful as it can be, but when it comes to unzipping it's perhaps a bit too helpful. If you have a zipped JAR file and double-click to unzip the file, OS X unzips the JAR file as well. Luckily there's a way to turn this off.
Open up the Archive Utility (/System/Library/Core Services/Archive Utility), go to Preferences, and uncheck the checkbox next to "Keep expanding if possible." Now this does mean if you have a .tar.gz file you'll have to unzip the gzip, then the tar, but to me that's preferable to having it automatically unzip JAR files.
Open BlueDragon BOF at CFUnited
If you're attending CFUnited don't miss the Open BlueDragon BOF that's being led by Adam Haskell (potentially with a bit of help from me). It's Wednesday night, 8:30 pm, in room 140A.
We'll be announcing the very cool stuff we've already added to OpenBD as well as some of the things we're working on, and everyone can feel free to bring any questions you have about the project.
See you Wednesday night!
Posted 6/17/08 @ 7:11 AM by Matt Woodward