Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2021

Over at ye ole Salon we find a somewhat ramblerific article on software evolution which pretends it's mostly about "Meir 'Manny' Lehman", apparently the first guy to do a paper on software evolution, in his case OS/360 at IBM.

Ole Manny apparently came to the following conclusion:
OS/360 was heading over a cliff. IBM, in stressing growth over source-code maintenance, would soon be in need of a successor operating system.

IBM reportedly ignored his report, but 3 years later were splitting OS/360 into two more manageable branches.

The bottom line of Manny's theory, which is apparently relatively hotly disputed in the right circles, is that software tends to grow in a curve that's the inverse (I think... been a while since I had geometry) of Moore's law (which has processor power growing at a geometric rate). The blame seems to be laid at the feet of programmers, who'd rather add something new than test something old, making larger software projects grow into a more chaotic system, in a fashion, when it comes to "bugs over time". In other words, any program that's been around long enough, unchecked, left to software developers' own devices, " all software programs are ultimately doomed to succumb to their own internal inertia" (From Frederick P. Brooks' "The Mythical Man Month", quoted by the above article, and reportedly based on ole Manny's work). Without adding energy to the system, in a sense, specifically for the removal of this chaos, software development produces poorer progress per unit of work added over time.

That software developers like to add new instead of understanding old isn't a new idea. Old man Joel has said something similar about refactoring code instead of rewriting it. Strangely, though, it would seem that keeping old code, according to Manny, would make it so that keeping this old code puts you on a one way course towards "succumbing to your own inertia", so to speak.

I'd guess Joel's response would be that most people aren't working on OS/360 or a likeminded project, and that you're generally much better off keeping what you've got [and the lessons the code's already learned]. There's also the obvious possibility that we're talking apples and oranges -- developers would prefer to add something new than to fix something old, which I believe is a complaint of the open source software movement (that things are added all the time, but not well-tested).

But the apples and oranges arguement aside, it would seem that if there was only a system where many programmers could add their "fresh, new, inertialess" code to a living whole, you wouldn't find yourself smacked on the head by the continually more complicated vortex products like [traditionally created] operating systems or Microsoft Words possibly produce.

Hrm. That process sounds familiar, doesn't it?

Another poorly edited ramble by ole Rufbo there.

I've been reading SAMS' Programming Data-Driven Web Applications with ASP.NET written by the two dudes that run dotnetjunkies. So far the book is thorough in the number of elements it touches and attempts to explain, but very surface level. "Here's widget A, here's a description B of widget A, here's an example code dump of me using widget A's closest cousin to 'Hello World!'."

That's not bad, but so far has had about 250 pages that have involved nothing more than skimming. I like a book with more tofu (trying not to offend anyone other than my own sense of taste, there), but it could be that I'm just that far along with my knowledge of ASP 3.0 and html that this is pretty much all old ideas.

Anyhow, the point of the post is that I notice these two dudes, who I often hold up as the representation of the archetypal higher-end ASP.NET programmer, have a bad habit of having 8 lines of asp.net code where one of html would do. For exmaple, here's what they do to place a name/title over top of a list of checkboxes:

<asp:Label
width="100%"
runat="server"
text="<center>Pick Products</center>"
BackColor="white"
ForeColor="Navy"
Font-Bold="true"
Font-Size="13"
/>

Why not just use <center>Pick Products</center>? Maybe couch in header tags? Backcolor is white over the whole page already... Anyhow, here's the code you get on the page:

<span style="color:Navy;background-color:White;font-size:13pt;font-weight:bold;width:100%;"><center>Pick Products</center></span>

At least MS uses css for the boldness, but shouldn't they double tag? (ie, use b tags in the middle) I don't know.

The big idea is that there are so many places for expressing personal preference in how html is rendered, I just can't imagine leaving it all up to MS. Even then, we're adding the "center" tag to this label's text attriubte. Seems wacked.

I also wonder about learning to add tags like the above with all these attributes defined within. That is, with codebehind you're supposed to be able to place all the code for a page in a page the web designer never has to see. Should this part of the code be for the web designer or shouldn't it? Shouldn't you just have a "label" there and let the web designer's stylesheet determine how it's displayed? Set/change the text and font, etc, in codebehind, and then only if you have to.

Phew, that was a poorly directed rant.

Oh yeah, my port of furthurnet to Mac OS 9 is coming along. No word from the devvers about my bug questions as of this morning though.

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Tuesday, April 16, 2002
While web programmin', I'm finding that Mozilla might be a tester's best friend. I'm quite impressed with how well behaviour of a particular build works across platforms. Does it work in Windows? Well then you can nearly take it to the bank it'll work the same way on MacMoz or UNIX, which also makes you feel pretty good about being able to get your "advanced dhtml functionality" to the maximum users. Heck, Moz even runs on Mac OS 9. I'm almost to the point that I'd stop testing Moz xplat and know I've got something working, but that's a pretty big no-no even to a lazy feller like myself. Here's one place where a little dhtml code shows that the browsers are still on different platforms (and any change in behaviour is good to spot). This is a javascript function that I'm using to change the way a cursor looks on a web page when something's loading. `function changeCursor(menuOff) { if (document.layers) { daMenuOff = document.layers[menuOff]; } else if (document.all) { daMenuOff = document.all(menuOff).style; } else if (document.getElementById) { // DOM1 daMenuOff = document.getElementById(menuOff).style; } //alert(daMenuOff.cursor); if (daMenuOff.cursor == 'wait') { daMenuOff.cursor = 'crosshair'; } else { daMenuOff.cursor = 'wait'; } }` Half-way expected the wait cursor to be an hourglass in Moz on Mac (like it is on Windows), even though Mac IE 5 shows a watch, like a "good Mac should". Nope. Moz is making a native API call in both builds. Interesting. Wonder how they wrap those calls in an xplat API -- or if they do? Also makes you wonder what other, less innocuous native calls are going on in other places... Anyhow, just a reminder that you write once, test everywhere, write again, keep testing everywhere. posted by ruffin at 4/16/2002 10:19:00 AM

From another 15 seconds list post: ..Where MyControls:body is the webcontrol I'm writing, how do I access the stylesheet data from within my control? I would have thought it would be something like.. string fontsize = this.Style("font-size"); ..but that doesn't seem to work. I've also tried working with the .ControlStyle and .CssClass properties but to no avail. There's something wrong with a set-up that makes it difficult for a web programmer to find out how to set cascasding style sheet properties. That's right, it's our friend .NET. posted by ruffin at 4/16/2002 09:32:00 AM

Monday, April 15, 2002
Interesting Q&A with Blogger owner dude at Internet Magazine, whatever that site is: Q: Tell us a little about the premium product on offer and how takeup/feedback has been so far. After talking about it for two years or so, we finally launched Blogger Pro at the end of January this year. So far, it's just Blogger with a few add-on features -- things like spellcheck, image uploading, email out, etc. It's also a bit faster and more reliable than the free version because it runs on separate servers for the most part, and if there are any scaling problems, Pro users get priority. The plan is for it to be much more, so the uptake for just starting out has been great. I didn't really expect a ton of subscribers until we launched some of the cooler stuff we have in the works, so I'm happy with how it's doing. It's a testament that people will pay for web services that are important to them or make their lives easier. Kinda scary that it's that easy to sell web services to the masses. Looks like Ballmer and Co. (and whoever that guy was that just got released) are right. posted by ruffin at 4/15/2002 11:47:00 AM

Who'd've thunk forcing a web page to print in a landscape layout would have been so tough, even in IE ( which requires an ActiveX script). Usually at least IE lets you do crazy stuff like this, so that you can create a prototype to show the team before saying, "So there it is. And that's never going to work crossplatform." They usually like that answer a lot better than, "Forget it." So am I advocating a better user experience in IE than in other browsers, the same way .NET does? Um, tell me why I shouldn't in this case (were there some non-ActiveX way of doing it). Anyhow, this looked promsing, but no go (unless you really like Opera). More links brought to you by the letter E, the number 3, and Matt. posted by ruffin at 4/15/2002 11:44:00 AM

Wednesday, April 10, 2002
By far the most interesting series of articles I've read in a while, this group of jive on IBM's future and its dependence on Java is a great read. This bit was featured on Slashdot, but don't stop at the article entitled When Will IBM Buy Sun, or, even worse, at the title of the article like so many Slashdot posters seemed to have. The idea that IBM would buy Sun in a hostile takeover is just an extended metaphor for what kind of power IBM needs. The author continues this line of thinking by showing how IBM doesn't need to buy Sun, it's only got to get Java open sourced or changed into a true open standard, though that article is more about how IBM's used open source as a weapon to make its proposed standards into de facto ones before any ruling body has a chance to change the proposal. Here's a key quote on that subject: If Sun, the Java Community Process, or the other ebXML supporters had any objections, it wouldn't matter. When code like this is given away, it has the same effect on developers that the price of Microsoft's Internet Explorer (free) has on end users. A standard is born. Clever, eh? Overall incredibly interesting. "Personal revelations" from the list included... * Me finally figuring out just how ballsy the name Eclipse is for IBM's open source competitor to Sun's Netbeans (duh, sun, eclipse, even if IBM claims the name was a coincidence) * IBM's Standard Widget Toolkit is doing what got yesterday's article author so fired up about the Mac, but in a much more cross-platform friendly manner. Both are intended to make Java a true player on the client-side to compete against Windows. * Lingua franca means "a common language consisting of Italian mixed with French, Spanish, Greek, and Arabic that was formerly spoken in Mediterranean ports", according to Merriam-Webster Online (which gives a little more meaning than my previous understanding which was limited to "a common lang"). I think I knew that before, but it doesn't matter if I'd forgotten. * Netscape 6.2 for Win2k has real issues with cleaning up after you close a window, pegging the processor. This problem is compounded when you have multiple windows open at once to read all these articles. Enjoy. posted by ruffin at 4/10/2002 11:14:00 AM

Tuesday, April 09, 2002
Somebody on the java-dev list at Apple (for discussion Java development on the Mac, no less) posted a link to this article on eweek strangely titled, "Hot Java Revives Mac Programming". At the end, the author asks for reasons why he shouldn't go back to the Mac based on how great Java is now in OS X, and the poster on java-dev said it'd be great if we all emailed him with reasons why he should stay with the Mac. Whoops. I, of course, emailed the dude with what I really thought. Here are some bits [of my email to the author]. ... it's important to remember that most iBooks and many PowerBooks don't have a video card that's powerful enough to take advantage of this graphics acceleration [that Apple has built into its virtual machine that got the eweek guy so excited], so those users (not to mention any poor schmoe with OS X on an unupgraded Rev A-C iMac) are still in performance purgatory.... The bottom line is you now need to know not only that you're running on OS X but what hardware you're using -- turning HWaccel on when you're on a less than optimal system has reportedly caused slowdowns on some machines... "Write on the Mac, 'Run anywhere,'" is definitely not the take home message to me from Apple's HWaccel implementation. ... [vent about Project Builder compliments in the article, mention Java 3D is lacking and no release date for Java 1.4 on Mac -- and I started with the general perception that speed of Java on Mac is too slow, causing some programmers not to release for OS X]... Hey, I love the Mac. I use a dual-USB iBook at home to test and program Java apps, and I've always been happy with the user experience Apple provides. But to program with anything less than the highest end, 1 GHz DP system running Netbeans (okay, now I'm trolling a little), much less to expect your finished product to run well on any client with OS X, is giving Apple too much credit. There's a lot of work ahead before you get me to give up Windows as a development, not just target, platform. So there you have it. Just spent so danged long writing that I thought I'd blog. posted by ruffin at 4/09/2002 06:20:00 PM

Abstract ADO.NET is trying to make ADO.NET more JDBC-like. Why? Here's a pretty insightful quote. The most heinous problem is the exception heirarchy. No matter what goes wrong in JDBC, you will get a SQLException. In ADO.NET, depending on the underlying provider is what type of exception you will get. [sic] Using the SqlClient classes, you will get SqlException. Using the OleDb classes, you will get OleDbException. Using the Oracle classes, you will get OracleException. And so on and so forth. The ADO.NET architecture really is only half-done. As long as you're only using one type of backend, things are great, but one of the best parts of "classic" ADO is the ability to transfer [again, "classic"] ASP 3.0 code from a, say, SQL 7.0 backend to Access 97 with the change of a connection string (problems with the way Jet handles date strings, etc, ignored for now). JDBC is similar. It'll be interesting to see how Abstract ADO.NET works out, and how they'll write code so that it doesn't lose some of the advantages gained by having finely tuned object models for many different rdbms systems, not to mention how it'll handle 3rd party ADO.NET connectors written in the future. posted by ruffin at 4/09/2002 03:07:00 PM

Monday, April 08, 2002
Over at ye ole Salon we find a somewhat ramblerific article on software evolution which pretends it's mostly about "Meir 'Manny' Lehman", apparently the first guy to do a paper on software evolution, in his case OS/360 at IBM. Ole Manny apparently came to the following conclusion: OS/360 was heading over a cliff. IBM, in stressing growth over source-code maintenance, would soon be in need of a successor operating system. IBM reportedly ignored his report, but 3 years later were splitting OS/360 into two more manageable branches. The bottom line of Manny's theory, which is apparently relatively hotly disputed in the right circles, is that software tends to grow in a curve that's the inverse (I think... been a while since I had geometry) of Moore's law (which has processor power growing at a geometric rate). The blame seems to be laid at the feet of programmers, who'd rather add something new than test something old, making larger software projects grow into a more chaotic system, in a fashion, when it comes to "bugs over time". In other words, any program that's been around long enough, unchecked, left to software developers' own devices, " all software programs are ultimately doomed to succumb to their own internal inertia" (From Frederick P. Brooks' "The Mythical Man Month", quoted by the above article, and reportedly based on ole Manny's work). Without adding energy to the system, in a sense, specifically for the removal of this chaos, software development produces poorer progress per unit of work added over time. That software developers like to add new instead of understanding old isn't a new idea. Old man Joel has said something similar about refactoring code instead of rewriting it. Strangely, though, it would seem that keeping old code, according to Manny, would make it so that keeping this old code puts you on a one way course towards "succumbing to your own inertia", so to speak. I'd guess Joel's response would be that most people aren't working on OS/360 or a likeminded project, and that you're generally much better off keeping what you've got [and the lessons the code's already learned]. There's also the obvious possibility that we're talking apples and oranges -- developers would prefer to add something new than to fix something old, which I believe is a complaint of the open source software movement (that things are added all the time, but not well-tested). But the apples and oranges arguement aside, it would seem that if there was only a system where many programmers could add their "fresh, new, inertialess" code to a living whole, you wouldn't find yourself smacked on the head by the continually more complicated vortex products like [traditionally created] operating systems or Microsoft Words possibly produce. Hrm. That process sounds familiar, doesn't it? Another poorly edited ramble by ole Rufbo there. posted by ruffin at 4/08/2002 02:11:00 PM

Thursday, April 04, 2002
I've been reading SAMS' Programming Data-Driven Web Applications with ASP.NET written by the two dudes that run dotnetjunkies. So far the book is thorough in the number of elements it touches and attempts to explain, but very surface level. "Here's widget A, here's a description B of widget A, here's an example code dump of me using widget A's closest cousin to 'Hello World!'." That's not bad, but so far has had about 250 pages that have involved nothing more than skimming. I like a book with more tofu (trying not to offend anyone other than my own sense of taste, there), but it could be that I'm just that far along with my knowledge of ASP 3.0 and html that this is pretty much all old ideas. Anyhow, the point of the post is that I notice these two dudes, who I often hold up as the representation of the archetypal higher-end ASP.NET programmer, have a bad habit of having 8 lines of asp.net code where one of html would do. For exmaple, here's what they do to place a name/title over top of a list of checkboxes: <asp:Label width="100%" runat="server" text="<center>Pick Products</center>" BackColor="white" ForeColor="Navy" Font-Bold="true" Font-Size="13" /> Why not just use <center>Pick Products</center>? Maybe couch in header tags? Backcolor is white over the whole page already... Anyhow, here's the code you get on the page: <span style="color:Navy;background-color:White;font-size:13pt;font-weight:bold;width:100%;"><center>Pick Products</center></span> At least MS uses css for the boldness, but shouldn't they double tag? (ie, use b tags in the middle) I don't know. The big idea is that there are so many places for expressing personal preference in how html is rendered, I just can't imagine leaving it all up to MS. Even then, we're adding the "center" tag to this label's text attriubte. Seems wacked. I also wonder about learning to add tags like the above with all these attributes defined within. That is, with codebehind you're supposed to be able to place all the code for a page in a page the web designer never has to see. Should this part of the code be for the web designer or shouldn't it? Shouldn't you just have a "label" there and let the web designer's stylesheet determine how it's displayed? Set/change the text and font, etc, in codebehind, and then only if you have to. Phew, that was a poorly directed rant. Oh yeah, my port of furthurnet to Mac OS 9 is coming along. No word from the devvers about my bug questions as of this morning though. posted by ruffin at 4/04/2002 05:33:00 PM

Tuesday, April 02, 2002
Talk about your interesting and useful but not necessarily "short-term productive" timesinks. Some Randmo AIMer sent me news that KaZaa included a pseudo Trojan horse that's potentially about to be activated on its users' computers. This thing will turn "unused" hard drive space and bandwidth into a commodity that KaZaa's partner, the makers of the piggyback app, can use freely. It's all in the KaZaa license and I'd guess nothing illegal is happening, but it's a little sneaky. But the more I think about it, the cooler the concept of mainstreaming distributed computing seems. SETI@home really pioneered the modern [or is that "post-modern" now?] version of this idea from where I'm sitting, and some good work with everything from finding these aliens to cures for cancer to compounds to kill Anthrax have received help from all those computers that are sitting around the nation idle. Heck, I've done 545 work units for SETI@home -- and counting. Though I'm not big on KaZaa's slick introduction of the piggyback distributing computing app, if you think about it, it's a very very good idea. Why not employ what's traditionally a client as a server? Every new PC sold today is more powerful than the traditional web servers of three or four years ago, I'd think. As long as the server part is backgrounded (given a low priority when it comes to gaining processor time) when you're, say, playing Quake, it's a great use of resources. As noted on slashdot by another poster, let's face it, this unused processor time and bandwidth is a huge, untapped resource, and has every trait needed to be a traded commodity like pork bellies or something similar. [colorful, eh?] I'm actually finding myself happy to hear this idea has left the desks of researchers at Microsoft looking for a new way to employ operating systems (another great idea, imo) and has hit Main Street. That said, I'm not planning to use anything other than Furthurnet to get new music for the cost of bandwidth and hard drive space online for the foreseeable future! posted by ruffin at 4/02/2002 11:01:00 AM

<< Older \| Newer >>