 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2006-04-01Does Visual Studio Rot the Mind?Does Visual Studio Rot the Mind? Thanks to Doug Mahugh having a dreary day indoors, I’ve found this October 2005 gem from Charles Petzold. Petzold gives voice to a number of problems that have been nagging at me and for which I haven’t found a clear view. Petzold (who’s April 1st 2006 parody on XAML is also brilliant) sharpens the difference between programming fast, programming well, and programming clearly. Doug’s grey-day post and Petzold’s appraisal are instant candidates for Best Software Writing II when Joel Spolsky gets around to it. {tags: software development Visual Studio conceptual integrity software engineering programming practice computer science education [update: There were some nasty typos and mangled wordings. “Does Visual Studio Rot the Mind?” is already on Joel Spolsky’s list, but I was happy to add my vote.] I only recently learned that Petzold has a blog. The RSS feed quickly went into my WinDev category among others including Larry Osterman, Michael Kaplan, Raymond Chen and, of particular relevance here, the MSDN Forum for the Visual C++ 2005 Express Edition. I learned of Doug’s blog through his involvement on the new site on Office Open XML formats and their use in document interchange. I notice that seeing each new offering from him has me smile. First, I think that Doug’s use of a kind of Structured English (what is also known as pseudo-code) for high-level characterization of a programming approach is classic. It’s a recognized software-engineering methodology and is a recognized way to work on the conceptual organization and essentials of a procedure before dealing with the syntax and low-level details that can easily obscure the important overall organization. It’s literally classic: it goes back to the very early days and Grace Hopper’s efforts to make programming languages match that level of expression more closely. (I watched a dismal failure on that, ambitiously and prematurely advertised as “English Spoken Here,” but Cobol has to be counted as the eventual success.) I can even recognize how that approach, which I have used and which I preserve in comments that introduce the detailed sections of code, fits into my breaking down of mainline procedures into use of components. There, I find that I am designing header files with descriptions of interface principles and stub procedures with pseudocode, all to be filled in progressively and confirmed with successive layers of tests as more function is available to exercise. This works great for procedural logic and decomposition of the approach, something that remains a valuable practice. It also ties into how we can tell we’re done and that we have produced what it is we started out to provide. It should also let someone else confirm Where structured-anything doesn’t work very well without a lot of careful preparation and practice is when our code consists of fragments/components of something not in view (and that we may not understand how to debug). For example, our bits might form a cohesive interactive performance only when integrated with a not-so-well understood User Interface threaded-messaging process. We should be concerned about Petzold’s observation that we are losing something with tools that hide this mystery and leave developers with an uneasy sense of incompetence. Old hands can adjust to it by bringing solid experience along with a willing beginner’s mind. That’s advantageous to finding out what is going on and One of the great qualities I find in Petzold’s work is his appreciation for the beginner. I value his care in making sure that his readers are advised about what they need to already know, while letting them operate with as little tool support and startup-cost as possible. You don’t need Visual Studio for his classic Programming Windows (ending with the 1999 5th edition for Win32) and its sequel, Programming Microsoft Windows with C# (2002). You just need the compiler, understanding of command-line operation, and some standard developer utilities plus the appropriate and freely-available SDK. Another common feature of Petzold's work is progressive learning by doing and then doing more, backed up by worked examples that actually do something it is valuable to know about. My interest in the Visual Studio Express Editions is not just that they are currently available for free 2006-03-29Grady Booch on the Limits of SoftwareBlog (Handbook of Software Architecture). Grady Booch makes a gracious observation about the furor concerning the announced delay for Windows Vista on his blog (no permalink: current article will scroll off). He looks at the angst posted by Microsoft developers and observes
{tags: software architecture pattern language forces system constraints system requirements Grady Booch orcmid} Booch’s depiction of the limits of software and the situational factors that originate many of those limits is a must-read. The registration process is painless. I heartily recommend the draft materials in the on-line Handbook of Software Architecture to anyone interested in architectural considerations that apply to software systems design and development. One tangential value for me, on my third or fourth scan of the limits page, is that I finally have come to understand where “Forces” come from in templates for pattern languages. I’m still uncomfortable with that metaphor for patterns of non-physical systems, and will stick to concerns. I also notice that it is important to identify important constraints as well as requirements, especially non-functional ones and I haven’t looked at that in the context of patterns for computer-based applications. (I also see that I have one more David Harel book to track down.) Modeling the Office Open XML Packaging ConventionsOpenXML Developer - Modeling OOX Packages. I've been waiting for an open forum for discussion of the ECMA TC45 Office Open XML Document Interchange Specification (now at draft 1) and especially the OOX package conventions, apparently a subset of the Microsoft Open Packaging Conventions. Now there’s openXMLdeveloper.org (I hate the name — XML is already open — but love the place). I just posted about my interest in the packaging model and though it would be useful to share that more widely. {tags: Open Packaging Conventions Office Open XML conceptual models data models document processing orcmid}
The package model is a very interesting application of Zip files as containers for more-complex related components that may carry references to each other and to material that is elsewhere. The package allows the essential relationships (and the nature of the package components) to be determined without having to know how to process the individual parts themselves. That makes for some interesting opportunities in document processing and in the interchange and preservation of digital assets. |
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |