We had a pretty long email thread today at work about the pros and cons of using UUID’s vs. Auto-Incremented id’s as primary keys in a database. Here’s a synopsis:
UUID
Category Archives: Software Development
Software Development Tools
I’m guessing that in every trade or craft, the ‘craftsmen’ delight in sharing (or not sharing!) their favorite tools, the objects that make their day. For cooks, maybe it’s a special pot or pan; for writers, maybe it’s a special pen. For software developers, well.. we just have software. Scott mentions a list of tools he used in a recent demonstration at Microsoft, most of which were new (and very interesting) to me. I’m pasting below so that I don’t have to check out his page every time I want to remember where something was:
pattern recognizers
Scoble posted a great analogy 2 days ago which was ignored amidst the religious context. He said this:
“Our brains are extraordinary pattern recognizers (think about it sometime — why can you look at a tree and instantly recognize it as a tree?). Our brains totally freak out when presented with something that has no pattern. Hey, look at the white noise on your TV sometime. You’ll start seeing patterns. You brain HATES not being able to see patterns.”
10 minutes ago I was trying to figure out why I’m so frustrated with the information architecture of the site I’m developing at work and the idea of the brain as a pattern recognizer helps makes perfect sense of that frustration. The client (in this case represented by anywhere from 1 to 8 people of a 1200 person company) has decided that they want a 3 column layout AND a 2 column layout and a single column layout… each with different navigation schemes, and with no apparent order. This frustrates me to no end, but there’s not much I can do or say to change their mind.
Is Big Brother our only hope against bin Laden?
On the list of things I’d like to do someday: sit next to the guy or girl who writes the code for this project
Why should I care what color the bikeshed is?
via rc3.org: “Why should I care what color the bikeshed is?” I suppose bike shed discussions happen at every job, but they seem to rear their ugly heads more when you develop websites for a living because really, everyone can make a website, right?
Ootips – Object Orientation Tips
Ootips – Object Orientation Tips: The purpose of ootips is to allow developers to keep up-to-date with object oriented technologies, without having to read through high volume, low signal-to-noise sources.
Cool apps..
From StevenBerlinJohnson.com:
· TinderBox: a ‘personal’ content management system, maybe the child of Groove and a blog. By the way, have you checked out Groove? I’m really impressed. The application has almost everything in it that I do with various web applications we use internally at work (ie: project management, document review, design comp review, IM, discussion, sketching, note taking, meetings, shared whiteboard…), I tried to get some sparks flying at work about it but no one bit… plus it *hogs* memory.
· connectedland: an interesting essay on convergence of computer and device and the implications that convergence brings our society
· freegorifero: another interesting blog
and I’m not sure why I find this amazing, but isn’t it cool that you can comment and presumably communicate with a guy like Steven Johnson via his blog? It’s one thing to read someone’s book, it’s another to read their book and then be able to read what their thinking about AND shoot’em an email (or a comment) if you think they’re way off. Pretty cool.
Upcoming seminars at W3C
Upcoming seminar entitled “Web pages you can speak to and gesture at” upcoming at MIT by Dave Raggett (who developed HTML Tidy, among other things..).
Loosely Coupled
So when I first started this weblog, I called it “Loosely Coupled”, which probably means nothing to people outside the software industry. Since then I’ve vamped the title, but I the term still interests me. I forget how I found this article on Friday, but it’s a wonderul introduction to what the term means and how it applies to hardware, software and business in general. “Loosely Coupled: A Term Worth Understanding” defines loosely coupled as
“… loosely coupled is an attribute of systems, referring to an approach to designing interfaces across modules to reduce the interdependencies across modules or components – in particular, reducing the risk that changes within one module will create unanticipated changes within other modules. This approach specifically seeks to increase flexibility in adding modules, replacing modules and changing operations within individual modules.”
John focuses mainly on business practices in his article, while I find myself drawn more toward exploring loose coupling within software applications. Much like a writer of books or songs spends the majority of his or her time searching for that perfect word or rhyme, software developers spend inordinate amounts of time trying to reduce complex business functions into abstract and manageable (but useful) software functions or objects… and then spend the rest of their time trying to tie them all back together into a useful application. I think that loose coupling is the idea that when you’re designing your abstract and manageable functions & objects, you design them in such a way that getting them to work together is as easy as putting together a couple of Lego pieces. Implicitly then, you should be able to swap out a Lego piece for a different colored or shaped piece, as long both pieces share a common interface. Here’s a real world example:
I’m finishing up work on a ASP/.NET project that included commerce capabilities. The credit card charge and credit functions would be taken care of by a product that could only be interfaced using the HTTP POST mechanism and which returned it’s results not as XML (why not!!!?) but as HTML with hidden form elements (who thought this would be a good idea by the way?). A couple years ago (because of my knowledge, although the technology available was a hinderance as well) I would have hardcoded the ASP app to make an HTTP POST call to this app and then would have used a regular expression to parse and display the results. This results in a very tightly coupled design. If for some reason the credit card merchant came out with new software that returned an XML stream or if we decided on using a new credit card merchant, we would have to tinker directly with the ASP code, re-test that code, and deploy that new code to the n servers this project required. Note that this may have been (and still might be) the *fastest* (as far as execution time) method of fulfilling the requirements. A loosely coupled implementation (which I chose to use) would build a layer on top of the credit card merchant software, abstracting the web application built in ASP from having to know the details of the hidden form fields returned in the HTML generated by an HTTP post. I wrote two modules: a) a module that interfaced directly with the credit card merchant software, posting and retrieving information from the software, and b) a web service with an immutable interface (ie: the ASP web application with always be able to depend on the interface being the same, no matter what credit card merchant we use) that uses the aforementioned module to instantiate the credit card merchant application. While this might seem more complex (and it is), it’s also extensible (ie: wanna add some logging to the credit card charge/credit process? wanna cache results? wanna cluster the application? great! As long as the interface stays the same, you can could swap out the C# web service for a Java web service (or Perl… or ColdFusion). You could begin logging the transactions to a database. You could write some type of caching mechanism to remember credit card details, *all without modifying your core ASP web application code*.
I mentioned in my example that doing a direct HTTP post to the merchant software *might* be the fastest in terms of execution time. Going back to John’s article, it’s interesting to note that a loosely coupled system
“…creates a safe harbor for experimentation within the module. Greater ability to experiment enhances the ability to learn. New approaches can be tried more frequently and participants can learn which approaches yield higher performance within each module. As these successful experiments yield better results, the performance of individual modules tends to improve at a faster rate. The cumulative effect of this performance improvement across an entire loosely coupled system can be significant.”
Couple books mentioned in the article that might be worth checking out:
Design Rules – Vol. 1 : The Power of Modularity by Carliss Y. Baldwin, Kim B. Clark
Out of the Box: Strategies for Achieving Profits Today & Growth Tomorrow Through Web Services by John Hagel
The Component-Based Business: Plug and Play by Richard Veryard
Thoughts?
ADA requirements
I’m working on a small consulting project for a local chemical company that wants to make sure that they meet ADA requirements. Looks like there are a ton of resources on the web regarding accessibility, here are a few I need to read more on:
Practical accessibility: Core concepts [from Dartmouth]
Section 508 Web Standards & WCAG Priority 1 Checkpoints [JimThatcher.com]