Slashdot Mirror

Please read what U.S. District Judge Thomas Penfield Jackson has to say about why Microsoft felt it was important to break the law to put an end to cross-platform API's.

Scroll up to the top of the page and read about why I feel cross-platform development is essential to the developer and the public.

Thank you for your attention.

Regards,

Mike

Can anyone tell me where I can get a rack mount, not the cases for the PC's, but the actual rack that you'd mount a bunch of them in, in New England?

Mail ordering one of these babies from far away would be expensive, and I suspect the UPS man would stop talking to me.

I live in mid-coast Maine. Portland, Maine is about an hour and a half drive away, Boston a little less than three. There's a lot of industry and some high-tech in South Portland, so maybe I can rent a truck or a van and get a rack there.

Advice on rackmount uninterruptible power supplies would be helpful too.

I do cross-platform development and I'd like to set up a build and test farm of lots of twisty little 1U machines all running different Linux and *BSD distros, QNX, Solaris x86, UltraSparc Solaris at some point, BeOS and of course Mr. Bill's operating systems. I do Mac OS too but probably won't rackmount those, as it would mess up the nice Flower Power look.

BTW, I'm finally about to break down and by a Belkin Omniview 4-port KVM Switch with a Mac video/ADB keyboard adapter. Maybe if I save up I can get the 8 port with On-Screen Display.

While the Belkin may be expensive, the switching is electronic. I've worn out a Manhattan mechanical VGA switch in about four months sharing a monitor between a Mac and a PC - I have to fiddle with the knob each time I switch it to get the connection right or the colors are all wonky. Also I'm sure to start shooting from the rooftops the next time I type into the wrong keyboard!

Mike

Can anyone tell me where I can get a rack mount, not the cases for the PC's, but the actual rack that you'd mount a bunch of them in, in New England?

Mail ordering one of these babies from far away would be expensive, and I suspect the UPS man would stop talking to me.

I live in mid-coast Maine. Portland, Maine is about an hour and a half drive away, Boston a little less than three. There's a lot of industry and some high-tech in South Portland, so maybe I can rent a truck or a van and get a rack there.

Advice on rackmount uninterruptible power supplies would be helpful too.

I do cross-platform development and I'd like to set up a build and test farm of lots of twisty little 1U machines all running different Linux and *BSD distros, QNX, Solaris x86, UltraSparc Solaris at some point, BeOS and of course Mr. Bill's operating systems. I do Mac OS too but probably won't rackmount those, as it would mess up the nice Flower Power look.

BTW, I'm finally about to break down and by a Belkin Omniview 4-port KVM Switch with a Mac video/ADB keyboard adapter. Maybe if I save up I can get the 8 port with On-Screen Display.

While the Belkin may be expensive, the switching is electronic. I've worn out a Manhattan mechanical VGA switch in about four months sharing a monitor between a Mac and a PC - I have to fiddle with the knob each time I switch it to get the connection right or the colors are all wonky. Also I'm sure to start shooting from the rooftops the next time I type into the wrong keyboard!

Mike

It has to work on Windows...

Do yourself a favor and get the efficiency of native machine code without the headache of making your users get a Java virtual machine - or caring what version of the JVM is available for a given platform.

Apple has announced it has no plans to support a JVM later than 1.1.8 on the classic Mac OS so you can't use all those great collection classes in Java 1.2 and be cross platform! (See Apple's Java Developer page and scroll down to where it says "Mac OS Classic Java".)

Use a cross-platform application framework. That way you can program on Linux, Mac, BeOS, Windows or maybe even QNX and deliver for all those schoolkids running Windows ME on their parents' PC.

One such framework, for C++, is ZooLib. There are many others, as you can see from The GUI Toolkit, Framework Page.

Read about why it's important to write cross-platform code.

I'm most familiar with ZooLib, because I've been working with it on the products I write for my clients, and I helped ZooLib author Andy Green prepare it for open source release late last year under the MIT License.

ZooLib offers all of the following implemented as C++ classes:

• Multithreading, with cross-platform C++ thread classes and various kinds of locks (simple mutexes, reader/writer locks) - multithreading is important for something like a servent. For systems like the Mac OS that don't have preemptive threads it has a handrolled thread scheduler.
• GUI, with a uniquely flexible layout method. The widgets are rendered by platform appropriate renderers, and you can make custom widgets. There's a renderer that will call through to the Appearance Manager on the Mac OS, if it's running.
• platform-independent TCP networking, it's implemented in terms of sockets on Linux, WinSock on Windows, sockets on BeOS and MacTCP on Mac OS. I think Open Transport may be working too on the Mac, I'm not sure - but on all platforms you use the same C++ classes for your networking with no platform-specific client code needed.
• Thread-safe reference counted smart pointers, for quick, efficient memory management that's free of leaks.
• Extensive debugging support - assertions in core components and a debugging memory manager, handy macros for assertions and the like
• Single-file database format with C++ interface. Create ZDatabase objects with ZTables in them. Much zippier than SQL and more pleasing to the object-oriented soul.
• File objects - you instantiate a ZFile object from a ZFileRef object, then use its Open, Close, Read and Write methods
• Platform-specific file open and save dialogs with an API that's consistent with the rest of ZooLib. Filter by filetype on the Mac or filename three letter extension on windows. While ZooLib is cross-platform, it breaks out into platform specific code in cases like this where it's appropriate, in a way that's considered entirely sacreligious by the Java community.
• Streams that can be chained to provide filtering, somewhat like the iostreams classes in the C++ standard library but more appropriate for use with binary data. This is how you typically read or write to a file or network connection.
• Handy preprocessor macros to deal with platform specific code or selecting options like debug builds.
• Offscreen graphics buffers that may be manipulated directly via pointers or accessed in a manner that is transparent to the bit depth via GetPixel and SetPixel calls. All platforms have the same API that provide a wrapper around platform bitmap buffers. I believe there's a purely homegrown in-memory implementation, plus platform implementations bounds to the native GUI layer like GWorlds on the Mac OS.

However, ZooLib doesn't yet have everything it needs. Read about that here. But I think it will work fine for the application suggested here, and the needs given in that page are being addressed.

ZooLib 0.81 is known to build with MetroWerks CodeWarrior on Windows and Mac OS, gcc on Linux, and gcc on BeOS for Pentium.

If you use CodeWarrior you can cross-compile and cross-debug; check out Thursby Software for some filesharing solutions that work well for this. (Tip - on Windows, select the "MacBinarize" post-linker in the target linker prefs when building a Mac target - you also need to derez all your resource files and include them as Rez text source).

While it should ultimately work, there are known build problems with BSD, CodeWarrior for BeOS PowerPC and Visual C++ on Windows. These are all being worked on and full support for all these platforms is expected before long.

Other cross-platform frameworks I'd like to note are:

• The Adaptive Communications Environment for cross-platform networking
• GTK - yes, that's right, GTK! but you must forgo using XLib calls and POSIX calls that are not in the ANSI C Standard Library
• The Netscape Portable Runtime for the non-GUI aspects of cross-platform development
• The Mozilla XPToolkit for cross-platform GUI
• Mozilla Netlib for network and file stream access
• Mozilla XPInstall for cross-platform installation, packaging and updating.
• Also check out AbiWord, a great cross-platform WYSIWYG word processor that's open source, with an open file format. As far as I know the only product coded in AbiWord's XP framework is AbiWord itself, but it's worth looking into for another look at how people architect these things.

While there are undoubtably many powerful advantages to the Mozilla framework, it often receives a great deal of criticism for being heavyweight - hard to code to, slow, and hungry for memory.

People often mistake these problems for valid arguments that one should not do cross-platform development, or perhaps not render your own widgets when doing so but depend on platform specific ones (like AWT vs. Swing), but I think the lightweight, well architected, efficient and easy to use ZooLib answers those arguments very eloquently.

Help me teach the Free Software community to write quality code.

Mike

ZooLib and SDL appear to be different cross-platform frameworks.

One would do very well to use them together in an application, and now that you've been so helpful as to tell me about SDL, I'll investigate how we might do a ZooLib/SDL integration.

ZooLib is for doing the following in a platform-independent way from C++:

• threads with various kinds of mutexes, reader/writer locks and so on
• thread-safe reference counted smart pointers
• Simple vector graphics
• fonts and text
• creating and using various kinds of windows (but not what the X folks refer to as "window management - dragging and so on)
• platform-appropriate graphical user interface widget creation, drawing, input and layout
• TCP networking
• single-file databases (the databases, being entirely contained in single files, can be used as user documents, so the user could double-click on on a desktop to open it in an editor after receiving it via email).
• streams and filters, conceptually like C++'s iostreams, but more appropriate for binary data formats
• Debugging memory allocator and debugging support through widespread use of assertions

Ah, but one thing it's completely lacking is any support whatsoever for multimedia! That's because the original developers primarily targeted Mac OS and Windows, for which the cross-platform QuickTime API was readily available, but not open source.

Now don't fault me if I leave something out, because I only just now found out about SDL, but lets see what SDL says it has:

• Simple, portable direct access to the graphics framebuffer, audio device, mouse and keyboard
• Support for OpenGL (the actual GL support must come from a separate library, many of which are available)

There's probably more but it's not readily apparent from the page.

What I'd suggest you do in writing a game is use ZooLib for the overall GUI and threading support, and have a pane in the middle of the screen where your main action takes place. In that pane you do direct-to-screen drawing with SDL and if you're doing fancy 3D, consider using OpenGL. Use SDL for your sound.

Again, thank you for bringing this to my attention.

Mike

Yes, it is complicated to do something very, very simple in ZooLib.

But it is much, much easier to do something complex in ZooLib than many other means that might be available.

And yes, you can probably set the background color much quicker by programming to the native API of your OS, but then you wouldn't have a cross-platform app, and to ship one, you'd have to port and maintain multiple parallel codebases.

The learning curve pays off the larger the application you write.

Mike

If a company wants to develop software that will run on both Windows and Linux (and Mac OS and BeOS too), one application framework they can use is the ZooLib cross-platform application framework.

There's still some work it needs for complete Linux support as you can read here but it's a lot less than developing your own framework.

ZooLib requires very little in the way of system graphics support so it wouldn't be too hard to port it to the framebuffer if you prefer doing that to running your game under X.

Because ZooLib uses the MIT License (also known as the X11 License) it is appropriate for use in both proprietary and Free Software programs.

If ZooLib doesn't suit your needs, have a look at the GUI Toolkit, Framework page.

Mike

I'm not much of an expert on databases, so I can't really comment on your offer to mentor Rob, but let's have a look at what the W3C Validation Service has to say about the slashcode:

Click here to validate:

• Slashdot's homepage
• This article

I think the situation could be improved a bit by adding a DOCTYPE declaration at the beginning (for a DTD). DTD validation, yeah right.

If you're writing files by hand and prefer to upload them for validation from your local hard disk, try this form.

Mike

It's not the troll you might think it is from the subject line. I think it merits at least "Insightful".

Mike

While I was out for a while I thought of a few more things to post that should have been included in the above.

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Haim can write the most difficult code, and it doesn't just work right, it is unquestionable.

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

Reading Risks for many years is what has made me such a zealot for software quality. It has also made me tend to avoid using software for anything of real importance in my life, and to feel uneasy while flying aboard modern aircraft - even though, with a B.A. in Physics, I am very comfortable with the aerodynamic principles that hold airplanes up and used to enjoy flying as a kid.

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

The ACCU is interested in more than just C and C++ these days, if you program in those languages, Java or (dare I say it) C-sharp you should join. The mailing lists is pretty low traffic and has some of the best signal-to-noise ratio of any list I've seen (except Risks). The ACCU's technical journals, with articles written by the members, are a valuable source of information on such things as how to write exception-safe code.

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

After reading Effective C++ and More Effective C++, if you're programming with g++ (or using gcc to compile ".cpp" files) then you should use the -Weffc++ option to g++ to warn you about style problems. From the GCC Online Manual:

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

Importantly, in any language, make sure your code compiles cleanly without warnings with all the warnings enabled in the compiler - use the -pedantic option in gcc.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

People who write in any programming language, from assembler on through C and way out to prolog, really should go back to our roots and read the early book:

• The Elements of Programming Style

Sadly, this book is out of print, but see the "E" Titles Section at ACCU for other Elements of Style books.

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

Looks like I missed one when I spoke about Bounded Pointers for GCC, Spotlight, etc. in my previous post. Parasoft offers:

• Insure

But note that these products use patented algorithms - number 5,581,696 and 5,860,011.

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

Finally, to make sure your HTML is valid, test it with the W3C HTML validation service. You have two choices of how to get your documents processed:

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Try this link for an example of running a popular web application through the W3C validator.

Mike

Use auto_ptr and other templates from the STL.

Garbage collection is for kids who haven't learned to reference count.

Mike

First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

• Study Fundamentals Not Tools APIs or OSes
• Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
• Secrets of the Debug Meisters: MacsBug Tips and Tricks (MacsBug is a Mac OS assembly debugger)

I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

• Pointers, References and Values - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style

Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

• Bounded Pointers for GCC
• Spotlight for Mac OS PowerPC
• BoundsChecker for Windows
• Purify for Windows and Unix (but I think it doesn't support Linux)

If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

• OptimizeIt

Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.

Mike

First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

• Study Fundamentals Not Tools APIs or OSes
• Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
• Secrets of the Debug Meisters: MacsBug Tips and Tricks (MacsBug is a Mac OS assembly debugger)

I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

• Pointers, References and Values - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style

Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

• Bounded Pointers for GCC
• Spotlight for Mac OS PowerPC
• BoundsChecker for Windows
• Purify for Windows and Unix (but I think it doesn't support Linux)

If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

• OptimizeIt

Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.

Mike

First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

• Study Fundamentals Not Tools APIs or OSes
• Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
• Secrets of the Debug Meisters: MacsBug Tips and Tricks (MacsBug is a Mac OS assembly debugger)

I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

• Pointers, References and Values - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style

Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

• Bounded Pointers for GCC
• Spotlight for Mac OS PowerPC
• BoundsChecker for Windows
• Purify for Windows and Unix (but I think it doesn't support Linux)

If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

• OptimizeIt

Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.

Mike

First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

• Study Fundamentals Not Tools APIs or OSes
• Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
• Secrets of the Debug Meisters: MacsBug Tips and Tricks (MacsBug is a Mac OS assembly debugger)

I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

• Pointers, References and Values - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style

Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

• Bounded Pointers for GCC
• Spotlight for Mac OS PowerPC
• BoundsChecker for Windows
• Purify for Windows and Unix (but I think it doesn't support Linux)

If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

• OptimizeIt

Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.

Mike

First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

• Study Fundamentals Not Tools APIs or OSes
• Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
• Secrets of the Debug Meisters: MacsBug Tips and Tricks (MacsBug is a Mac OS assembly debugger)

I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

• Pointers, References and Values - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style

Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

• Bounded Pointers for GCC
• Spotlight for Mac OS PowerPC
• BoundsChecker for Windows
• Purify for Windows and Unix (but I think it doesn't support Linux)

If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

• OptimizeIt

Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.

Mike

First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

• Study Fundamentals Not Tools APIs or OSes
• Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
• Secrets of the Debug Meisters: MacsBug Tips and Tricks (MacsBug is a Mac OS assembly debugger)

I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

• Pointers, References and Values - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style

Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

• Bounded Pointers for GCC
• Spotlight for Mac OS PowerPC
• BoundsChecker for Windows
• Purify for Windows and Unix (but I think it doesn't support Linux)

If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

• OptimizeIt

Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.

Mike

I think Tim does have a point, in that much open source software has quality problems, but my argument is that I haven't observed closed-source to be any better - one can point out glowing examples of good process in both camps, and bad process too.

What I am trying to do with the Linux Quality Database is twofold - make it easier for regular users to participate in the quality process for the Linux kernel, and to encourage improvement in the quality of free software in general, by giving tips on how to do so and links to resources that enable you to do it.

I think one problem is perfectly natural - a lot of programmers are just not very experienced, and have not had the opportunity to work in a way the encourages quality yet. And this goes for both closed source and open source programmers.

It's a matter of education; a lot of people may try to get the bugs out of their products, but simply struggling valiantly is not the right way to approach it - I hate to repeat this tired old phrase, but "Work smarter, not harder".

Mike

Tim,

I think we've met, or at least corresponded when I was at Apple.

I was on the Traditional OS Integration team during System 7.5.3 and 7.5.4, and then later worked on PowerBooks. When I started, my manager was Jennifer Ahlquist. I worked with Dave Lyons, Jim Murphy and those guys.

I'm afraid my work on PowerBooks didn't lead to much, but I managed to do some good as a "debug meister". Some of what I learned I pass on to other mac developers in my page:

• Secrets of the Debug Meisters - tips and tricks for MacsBug

You might be a little shocked by what I have to say on the next page though. I don't think there could ever have been anybody more loyal to the Macintosh platform than me (bleeding in six colors, etc.) - but then read:

• Freeing the Developer from OS Vendor Shackles

I'm afraid the page about why I became a BeOS developer is temporarily disabled. It's at my old ISP in Santa Cruz and I'm always late paying my bill now that I'm living in Maine. Once I send them a check you'll be able to read it again. Eventually I'll move it to my own domain.

Anyway, one more way to lower the upper bound on the bugs is to build assertions into the core of one's development framework. Lots of people use assertions when they're looking for a specific bug (and that's my style), but the ZooLib cross-platform application framework is riddled with assertions, and the more frequently a class is likely to be used, the more likely you'll find an assertion in it.

This is something that's available to anyone, but ZooLib was the first time I found it very widely used, and the result was that the product I wrote with it had the least bugs of any substantial program I've ever had the pleasure to work with (note - I also did a little unit testing).

While Instant Makeover is not open source, ZooLib is, under the MIT License.

By the way, the reason the Mac version of Instant Makeover is "coming soon" and not already available is because those deadbeats stiffed me for seven weeks pay - and told me they were going to at the end of a 29-hour workday trying to get the beta out.

During the development of Instant Makover, I usually delivered Mac and Windows builds simultaneously from the same source base. My guess is they can't find a Mac programmer since we parted ways.

I didn't even take a honeymoon after I was married last summer because of the pressure they were putting on me to ship.

It was the largest program I'd ever written by myself (but note the extensive use of libraries), although the one thing I feel was worthwhile is that working on it made me a better programmer, something I'm trying to pass on.

And yes, I did use Radar quite a bit, probably more than most software engineers at Apple because of my job debugging the system software, but read about what I'd really like to see in a bugbase - the idea of having preset, named hardware configurations that a tester can quickly select when they file a bug report is a feature that I was asking for in Radar when I was at Apple.

Not afraid to speak my mind....

Mike

Tim,

I think we've met, or at least corresponded when I was at Apple.

I was on the Traditional OS Integration team during System 7.5.3 and 7.5.4, and then later worked on PowerBooks. When I started, my manager was Jennifer Ahlquist. I worked with Dave Lyons, Jim Murphy and those guys.

I'm afraid my work on PowerBooks didn't lead to much, but I managed to do some good as a "debug meister". Some of what I learned I pass on to other mac developers in my page:

• Secrets of the Debug Meisters - tips and tricks for MacsBug

You might be a little shocked by what I have to say on the next page though. I don't think there could ever have been anybody more loyal to the Macintosh platform than me (bleeding in six colors, etc.) - but then read:

• Freeing the Developer from OS Vendor Shackles

I'm afraid the page about why I became a BeOS developer is temporarily disabled. It's at my old ISP in Santa Cruz and I'm always late paying my bill now that I'm living in Maine. Once I send them a check you'll be able to read it again. Eventually I'll move it to my own domain.

Anyway, one more way to lower the upper bound on the bugs is to build assertions into the core of one's development framework. Lots of people use assertions when they're looking for a specific bug (and that's my style), but the ZooLib cross-platform application framework is riddled with assertions, and the more frequently a class is likely to be used, the more likely you'll find an assertion in it.

This is something that's available to anyone, but ZooLib was the first time I found it very widely used, and the result was that the product I wrote with it had the least bugs of any substantial program I've ever had the pleasure to work with (note - I also did a little unit testing).

While Instant Makeover is not open source, ZooLib is, under the MIT License.

By the way, the reason the Mac version of Instant Makeover is "coming soon" and not already available is because those deadbeats stiffed me for seven weeks pay - and told me they were going to at the end of a 29-hour workday trying to get the beta out.

During the development of Instant Makover, I usually delivered Mac and Windows builds simultaneously from the same source base. My guess is they can't find a Mac programmer since we parted ways.

I didn't even take a honeymoon after I was married last summer because of the pressure they were putting on me to ship.

It was the largest program I'd ever written by myself (but note the extensive use of libraries), although the one thing I feel was worthwhile is that working on it made me a better programmer, something I'm trying to pass on.

And yes, I did use Radar quite a bit, probably more than most software engineers at Apple because of my job debugging the system software, but read about what I'd really like to see in a bugbase - the idea of having preset, named hardware configurations that a tester can quickly select when they file a bug report is a feature that I was asking for in Radar when I was at Apple.

Not afraid to speak my mind....

Mike

Tim,

I think we've met, or at least corresponded when I was at Apple.

I was on the Traditional OS Integration team during System 7.5.3 and 7.5.4, and then later worked on PowerBooks. When I started, my manager was Jennifer Ahlquist. I worked with Dave Lyons, Jim Murphy and those guys.

I'm afraid my work on PowerBooks didn't lead to much, but I managed to do some good as a "debug meister". Some of what I learned I pass on to other mac developers in my page:

• Secrets of the Debug Meisters - tips and tricks for MacsBug

You might be a little shocked by what I have to say on the next page though. I don't think there could ever have been anybody more loyal to the Macintosh platform than me (bleeding in six colors, etc.) - but then read:

• Freeing the Developer from OS Vendor Shackles

I'm afraid the page about why I became a BeOS developer is temporarily disabled. It's at my old ISP in Santa Cruz and I'm always late paying my bill now that I'm living in Maine. Once I send them a check you'll be able to read it again. Eventually I'll move it to my own domain.

Anyway, one more way to lower the upper bound on the bugs is to build assertions into the core of one's development framework. Lots of people use assertions when they're looking for a specific bug (and that's my style), but the ZooLib cross-platform application framework is riddled with assertions, and the more frequently a class is likely to be used, the more likely you'll find an assertion in it.

This is something that's available to anyone, but ZooLib was the first time I found it very widely used, and the result was that the product I wrote with it had the least bugs of any substantial program I've ever had the pleasure to work with (note - I also did a little unit testing).

While Instant Makeover is not open source, ZooLib is, under the MIT License.

By the way, the reason the Mac version of Instant Makeover is "coming soon" and not already available is because those deadbeats stiffed me for seven weeks pay - and told me they were going to at the end of a 29-hour workday trying to get the beta out.

During the development of Instant Makover, I usually delivered Mac and Windows builds simultaneously from the same source base. My guess is they can't find a Mac programmer since we parted ways.

I didn't even take a honeymoon after I was married last summer because of the pressure they were putting on me to ship.

It was the largest program I'd ever written by myself (but note the extensive use of libraries), although the one thing I feel was worthwhile is that working on it made me a better programmer, something I'm trying to pass on.

And yes, I did use Radar quite a bit, probably more than most software engineers at Apple because of my job debugging the system software, but read about what I'd really like to see in a bugbase - the idea of having preset, named hardware configurations that a tester can quickly select when they file a bug report is a feature that I was asking for in Radar when I was at Apple.

Not afraid to speak my mind....

Mike

Tim,

I think we've met, or at least corresponded when I was at Apple.

I was on the Traditional OS Integration team during System 7.5.3 and 7.5.4, and then later worked on PowerBooks. When I started, my manager was Jennifer Ahlquist. I worked with Dave Lyons, Jim Murphy and those guys.

I'm afraid my work on PowerBooks didn't lead to much, but I managed to do some good as a "debug meister". Some of what I learned I pass on to other mac developers in my page:

• Secrets of the Debug Meisters - tips and tricks for MacsBug

You might be a little shocked by what I have to say on the next page though. I don't think there could ever have been anybody more loyal to the Macintosh platform than me (bleeding in six colors, etc.) - but then read:

• Freeing the Developer from OS Vendor Shackles

I'm afraid the page about why I became a BeOS developer is temporarily disabled. It's at my old ISP in Santa Cruz and I'm always late paying my bill now that I'm living in Maine. Once I send them a check you'll be able to read it again. Eventually I'll move it to my own domain.

Anyway, one more way to lower the upper bound on the bugs is to build assertions into the core of one's development framework. Lots of people use assertions when they're looking for a specific bug (and that's my style), but the ZooLib cross-platform application framework is riddled with assertions, and the more frequently a class is likely to be used, the more likely you'll find an assertion in it.

This is something that's available to anyone, but ZooLib was the first time I found it very widely used, and the result was that the product I wrote with it had the least bugs of any substantial program I've ever had the pleasure to work with (note - I also did a little unit testing).

While Instant Makeover is not open source, ZooLib is, under the MIT License.

By the way, the reason the Mac version of Instant Makeover is "coming soon" and not already available is because those deadbeats stiffed me for seven weeks pay - and told me they were going to at the end of a 29-hour workday trying to get the beta out.

During the development of Instant Makover, I usually delivered Mac and Windows builds simultaneously from the same source base. My guess is they can't find a Mac programmer since we parted ways.

I didn't even take a honeymoon after I was married last summer because of the pressure they were putting on me to ship.

It was the largest program I'd ever written by myself (but note the extensive use of libraries), although the one thing I feel was worthwhile is that working on it made me a better programmer, something I'm trying to pass on.

And yes, I did use Radar quite a bit, probably more than most software engineers at Apple because of my job debugging the system software, but read about what I'd really like to see in a bugbase - the idea of having preset, named hardware configurations that a tester can quickly select when they file a bug report is a feature that I was asking for in Radar when I was at Apple.

Not afraid to speak my mind....

Mike

Tim,

I think we've met, or at least corresponded when I was at Apple.

I was on the Traditional OS Integration team during System 7.5.3 and 7.5.4, and then later worked on PowerBooks. When I started, my manager was Jennifer Ahlquist. I worked with Dave Lyons, Jim Murphy and those guys.

I'm afraid my work on PowerBooks didn't lead to much, but I managed to do some good as a "debug meister". Some of what I learned I pass on to other mac developers in my page:

• Secrets of the Debug Meisters - tips and tricks for MacsBug

You might be a little shocked by what I have to say on the next page though. I don't think there could ever have been anybody more loyal to the Macintosh platform than me (bleeding in six colors, etc.) - but then read:

• Freeing the Developer from OS Vendor Shackles

I'm afraid the page about why I became a BeOS developer is temporarily disabled. It's at my old ISP in Santa Cruz and I'm always late paying my bill now that I'm living in Maine. Once I send them a check you'll be able to read it again. Eventually I'll move it to my own domain.

Anyway, one more way to lower the upper bound on the bugs is to build assertions into the core of one's development framework. Lots of people use assertions when they're looking for a specific bug (and that's my style), but the ZooLib cross-platform application framework is riddled with assertions, and the more frequently a class is likely to be used, the more likely you'll find an assertion in it.

This is something that's available to anyone, but ZooLib was the first time I found it very widely used, and the result was that the product I wrote with it had the least bugs of any substantial program I've ever had the pleasure to work with (note - I also did a little unit testing).

While Instant Makeover is not open source, ZooLib is, under the MIT License.

By the way, the reason the Mac version of Instant Makeover is "coming soon" and not already available is because those deadbeats stiffed me for seven weeks pay - and told me they were going to at the end of a 29-hour workday trying to get the beta out.

During the development of Instant Makover, I usually delivered Mac and Windows builds simultaneously from the same source base. My guess is they can't find a Mac programmer since we parted ways.

I didn't even take a honeymoon after I was married last summer because of the pressure they were putting on me to ship.

It was the largest program I'd ever written by myself (but note the extensive use of libraries), although the one thing I feel was worthwhile is that working on it made me a better programmer, something I'm trying to pass on.

And yes, I did use Radar quite a bit, probably more than most software engineers at Apple because of my job debugging the system software, but read about what I'd really like to see in a bugbase - the idea of having preset, named hardware configurations that a tester can quickly select when they file a bug report is a feature that I was asking for in Radar when I was at Apple.

Not afraid to speak my mind....

Mike

I don't know what commercial projects you've had the pleasure to work on, but that's not been my experience, and I've worked for a lot of closed-source companies.

Some of the most amazing excuses for "software" get packaged up by commercial companies all the time and sold to an unsuspecting public.

This is not always what the companies want, not by any means, but often they feel they have no choice.

Scientific American did an article called "The Risks of Computing" a while back, I'm not sure if Neumann wrote it but it was where I found out about the Risks forum, and what it documented is that in any software system, the number of bugs steadily increases over time but the reproducibility of each individual bug goes down, so in the end you have 100,000 bugs each of which you will experience just once in your career.

There are ways to lower the upward bound of bugs, for example on Linux you can use Bounded Pointers for GCC and make great strides in a hurry - but then although you'll have fewer bugs you'll have different kinds of them.

Improving QA by using test suites is another important step, as I discuss in this article on Using Test Suites to Validate the Linux Kernel.

You think your commercial vendor uses test suites? Guess again. It's so frustrating when I have a client who I cannot convince there's a reason to actually perform QA of any sort, let alone use test suites.

Another way of lowering the upward bound is to use Unit Tests - but despite the fact that I've seen unit tests advocated in many places, and I guess they're more popular, the one time I have ever seen them put into practice on a project I've personally worked on is when yours truly used them on a consulting project last year.

Mike

I don't know what commercial projects you've had the pleasure to work on, but that's not been my experience, and I've worked for a lot of closed-source companies.

Some of the most amazing excuses for "software" get packaged up by commercial companies all the time and sold to an unsuspecting public.

This is not always what the companies want, not by any means, but often they feel they have no choice.

Scientific American did an article called "The Risks of Computing" a while back, I'm not sure if Neumann wrote it but it was where I found out about the Risks forum, and what it documented is that in any software system, the number of bugs steadily increases over time but the reproducibility of each individual bug goes down, so in the end you have 100,000 bugs each of which you will experience just once in your career.

There are ways to lower the upward bound of bugs, for example on Linux you can use Bounded Pointers for GCC and make great strides in a hurry - but then although you'll have fewer bugs you'll have different kinds of them.

Improving QA by using test suites is another important step, as I discuss in this article on Using Test Suites to Validate the Linux Kernel.

You think your commercial vendor uses test suites? Guess again. It's so frustrating when I have a client who I cannot convince there's a reason to actually perform QA of any sort, let alone use test suites.

Another way of lowering the upward bound is to use Unit Tests - but despite the fact that I've seen unit tests advocated in many places, and I guess they're more popular, the one time I have ever seen them put into practice on a project I've personally worked on is when yours truly used them on a consulting project last year.

Mike

SRI researcher and computer reliability and security expert Peter Neumann is promoting open source to the in various fora, including to an IEEE meeting and the military. His general thesis is that "open box" software promotes reliability because you can both inspect the source code and fix it.

Go to Neumann's page above and search for "Robust" using the "Find in Page" function of your browser.

Neumann is the moderator of The Forum on Risks to the Public in Computers and Related Systems and the author of the book Computer Related Risks, so he should know whereof he speaks.

Please also read Open Source and These United States.

In the previous article, someone suggested the problem of how to compose a letter to congressional representatives to promote open source - perhaps simply printing out that paper and mailing it to them with a brief cover letter explaining how you've found a way the U.S. Government and Military can achieve substantial savings in its software purchases, along with gains in reliability, would be helpful.

Mike

I certainly didn't intend it for this purpose, but my program Last Resort for the Mac OS from Working Software was instrumental in one of the editors of MacUser magazine discovering that his girlfriend was having an online affair.

This was before widespread use of the Internet by the public (although I was using it at the time). I don't know what network his girlfriend was using, but it was some proprietary system like Compuserve or AOL.

Last Resort patched the GetNextEvent trap in the MacOS to save all your keystrokes into a file. The buffer is flushed and the volume flushed too every few keystrokes, so if you're writing the next Great American Novel and lose power, while the text may be a little garbled, you'll at least get your words back.

Unfortunately for this fellow's girlfriend, this editor was an enthusiastic Last Resort user and he discovered her steamy letters to her online lover in his keystroke files.

I was utterly horrified to find this out but the fellow came up to me at the MacWorld trade show and thanked me profusely.

Last Resort was my first shipping commercial software product (now one of many). It was a simple program that took 8 kb of ram during operation, but we were well aware of the privacy implications. It doesn't try to hide itself - it shows up in your control panels under the apple menu and it displays it's "resort logo" with a palm tree by a beach (an early attempt at art by Yours Truly) at startup.

There are numerous more invasize products meant to snoop on your lovers - or capture passwords. For example, I received some spam from someone who was selling software that would hide itself well and save its keystroke files encrypted on a disk, then make an encrypted network connection to a server to upload the keystroke files from the hapless user's machine.

This wasn't your government snooping on you, this guy was looking for a distributor to publish the program.

This MacUser editor later published a novel about the software industry in which many fictitiously named but software applications that were thinly disguised versions of real products (I guess for trademark reasons) played central roles in the plot. I'm proud to say that his thinly disguised clone for Last Resort was responsible for saving the world!

Now if I could remember his name I'd give you a URL to the book...

Mike

I certainly didn't intend it for this purpose, but my program Last Resort for the Mac OS from Working Software was instrumental in one of the editors of MacUser magazine discovering that his girlfriend was having an online affair.

This was before widespread use of the Internet by the public (although I was using it at the time). I don't know what network his girlfriend was using, but it was some proprietary system like Compuserve or AOL.

Last Resort patched the GetNextEvent trap in the MacOS to save all your keystrokes into a file. The buffer is flushed and the volume flushed too every few keystrokes, so if you're writing the next Great American Novel and lose power, while the text may be a little garbled, you'll at least get your words back.

Unfortunately for this fellow's girlfriend, this editor was an enthusiastic Last Resort user and he discovered her steamy letters to her online lover in his keystroke files.

I was utterly horrified to find this out but the fellow came up to me at the MacWorld trade show and thanked me profusely.

Last Resort was my first shipping commercial software product (now one of many). It was a simple program that took 8 kb of ram during operation, but we were well aware of the privacy implications. It doesn't try to hide itself - it shows up in your control panels under the apple menu and it displays it's "resort logo" with a palm tree by a beach (an early attempt at art by Yours Truly) at startup.

There are numerous more invasize products meant to snoop on your lovers - or capture passwords. For example, I received some spam from someone who was selling software that would hide itself well and save its keystroke files encrypted on a disk, then make an encrypted network connection to a server to upload the keystroke files from the hapless user's machine.

This wasn't your government snooping on you, this guy was looking for a distributor to publish the program.

This MacUser editor later published a novel about the software industry in which many fictitiously named but software applications that were thinly disguised versions of real products (I guess for trademark reasons) played central roles in the plot. I'm proud to say that his thinly disguised clone for Last Resort was responsible for saving the world!

Now if I could remember his name I'd give you a URL to the book...

Mike

I married a woman I met after she sent me an email to say she liked my web page.

She wasn't all that impressed, it was just a brief note to compliment my page, and I get such notes all the time.

What mattered was that we began corresponding, and after a month or so I asked for her phone number, and we began talking on the phone occassionally. I really impressed her by calling her in Nova Scotia while I was visiting a friend in Rome.

She lived in Truro, Nova Scotia, I in Santa Cruz, California. I soon discovered the need for cheap long distance - before I got my rate lowered I received a $2500 bill for just one month, and even after getting AT&T one rate international my bills were running $1100 per month.

She didn't own her own computer so voice over IP wasn't an option, and I tried to make it one by sending her my old 486 and Speak Freely. While she was able to negotiate Speak Freely's complex UI the 486 wasn't up to the task of the signal processing.

I also made three visits to her (the first on January 18, 1998, in wintry Canada from sunny California, bringing a rose with me all the way on the plane), and she made two to me.

It was when I offerred to buy her a brand new Pentium-II machine to run Speak Freely on that she decided to finally come out to Santa Cruz and live with me.

She soon found work doing biotech and was able to stay for a year on a TN-1 visa, an option also available to americans and mexicans in each other's countries who hold bachelor's degrees and work in various professional fields (tip - computer programming qualifies).

We were married July 22, 2000 in Pippy Park, St. John's Newfoundland just outside the Fluvarium where we held our reception. It was a beautiful day - outdoor weddings are not common in Newfoundland because of the northern climate, and in fact we rented a big tent.

We moved back to the U.S. a few weeks ago and now live in Owl's Head Maine in a house we could have never hoped to have afforded in Santa Cruz.

Mike

Speaking as a cross-platform developer, I beg to differ with you on the point that cross-platform code is unimportant.

I'd like you to understand why cross-platform code is incredibly important (note that this page quotes Judge Jackson of the MS vs. DOJ case as to why Microsoft felt it was so important to put a stop to cross-platform code as to break the law.)

But I think what we have lost sight of is maintaining both the usefulness of our code and our independence as programmers by not remembering how to write cross-platform code.

What Sun got wrong was not making Java cross-platform, but trying to bind us all into proprietary platform of Java while sweetly singing into our ears that it was platform independent. Sun did this and continues with it to serve its own marketing and political purposes, purposes which may not serve the interests of either the public or the independent developer.

You too can write cross-platform code, in almost any compiled language. Check out the ZooLib cross-platform application framework for C++, as well as the Boost C++ Libraries.

Jon Watte of Be, Inc. told me "Portable, to some people, means it builds on at least two linux distributions with several flavors of GCC".

Here's a list of a bunch of application frameworks, many of which are cross-platform, and many of which are open source - so there's more than just ZooLib to pick from.

Get off your duff and ship your executables for all platforms in common use - and not just ones with POSIX system call APIs!

And here's a hint for making your code buildable cross-platform - ever try to run "./configure" on a computer that doesn't have a command shell? Pretty hard. Makes folks like me struggle to write all the makefile's and config.h's by hand. But look at how many platforms the Independent JPEG Group's JPEG codec library builds on - DOS, MacOS, Cray, you name it, and it builds with both ANSI-C and old K&R c compilers (using macros for the function interfaces).

Kids these days... damn it makes me mad.

Michael D. Crawford
GoingWare Inc

Do you know what "second sound" means in thermodynamics? If you have liquid helium cooled to superfluidity, then it will be the same temperature throughout always. You can change the temperature in one local area, but rather than raising conveciton currents, the temperature will come to equilibrium throughout the body of the liquid at the speed of this second sound.

The Internet is like that - in that information spreads effectively instantaneously throughout its body, and it helps a great deal with ethical problems with business (as well as failures in things like customer service) and is discussed extensively by The Cluetrain Manifesto.

To make the most effective use of the Cluetrain, we must be willing to speak out in public fora on the Internet, and the book version of the Cluetrain quotes a profound speech made a hundred years ago that urges us to Make a Bonfire of Your Reputations - that is, when you have something important to say, say it, and don't let fear of others' scorn stop you.

Michael D. Crawford
GoingWare Inc

As a consultant, I get a lot of calls from headhunters and contract employment brokers.

But as a result of many horror stories from my own experience and that of my friends, I decided to stop dealing with them and I explain why publicly in Important Note to Recruiters and Contract Agencies.

To make it easier for other consultants to not have to deal with recruiters, I wrote Market Yourself - Tips for High-Tech Consultants.

To directly address the question, though, I think ethics are of the highest importance in the work of a consultant, and are probably the most important guide for you to follow, more important than writing good code. You at least have the hope of debugging bad code.

The question goes both ways though, clients are occassionally unethical and many clients who wouldn't think of screwing you if you were a full-time employee would be happy to short you for weeks of pay earned as a consultant.

You have to protect yourself, start early by finding a good attorney before taking on work - certainly before trouble starts - and have your attorney review all your contracts before you sign them.

Also trust in your feelings and don't do business with someone you feel is not ethical. It's just not worth the heartache.

Michael D. Crawford
GoingWare Inc

As a consultant, I get a lot of calls from headhunters and contract employment brokers.

But as a result of many horror stories from my own experience and that of my friends, I decided to stop dealing with them and I explain why publicly in Important Note to Recruiters and Contract Agencies.

To make it easier for other consultants to not have to deal with recruiters, I wrote Market Yourself - Tips for High-Tech Consultants.

To directly address the question, though, I think ethics are of the highest importance in the work of a consultant, and are probably the most important guide for you to follow, more important than writing good code. You at least have the hope of debugging bad code.

The question goes both ways though, clients are occassionally unethical and many clients who wouldn't think of screwing you if you were a full-time employee would be happy to short you for weeks of pay earned as a consultant.

You have to protect yourself, start early by finding a good attorney before taking on work - certainly before trouble starts - and have your attorney review all your contracts before you sign them.

Also trust in your feelings and don't do business with someone you feel is not ethical. It's just not worth the heartache.

Michael D. Crawford
GoingWare Inc

The ZooLib cross-platform application framework has a platform independentent C++ thread and mutex library for Linux (and other POSIX), Win32, Mac OS (with handrolled threads), and BeOS.

I'm pretty perplexed why Linus should think that thread programming is harder. This makes me wonder whether he's ever really tried in a serious way - a lot of programs are much easier to write when you use threads.

Just ask anyone who's had to write their own task scheduler for private use within one program, as I have when writing my Raindrops screensaver for the Mac, or when I wrote a test tool for MacTCP, that enables up to 64 TCP streams and UDP pseudo-streams between any combinations of a Mac on a network - I wrote that in 1990 at Apple, well before threads were available on the Mac OS and it was a pain.

But personally I don't see the point of having threads not implemented in the kernel. It means all your threads block if any of them do. That's the point of kernel threads. I think solaris threads work the way they do because the solaris schedular isn't so efficient, so it's more efficient to multitask some of your threads in user space.

This also relates to why multithreaded programs are more efficient and responsive than single threaded ones, even on uniprocessor machines. If your process blocks to await a resource in a single threaded program, you get to wait while time is wasted. This is OK for servers where avergage efficiency is the main concern but is not appropriate for interactive or near-real-time use.

With a multithreaded program, if one thread blocks for a resource, another thread can run, and if it's another thread in the same program your program's utilization of the CPU will be greater. This is especially the case if the kernel is preemptible and multithreaded, as it is on the BeOS and can be with experimental patches on the Linux kernel.

For an experiment, using the same machine, compare the interactice responsiveness of Windows, the BeOS and Linux, and I can assure you that even for uniprocessor machines the BeOS will be much more efficient, because all native BeOS programs are multithreaded. Threading is available on Linux and Windows but are not yet that widely used.

Michael D. Crawford
GoingWare Inc

I have proposed writing one more or less from scratch at the Linux Quality Database Project.

It's just a proposal so far, I want to find a few developers to collaborate with before I start, but I'm also writing and posting articles there on the general topic of making Free Software of better quality and also testing the kernel in particular.

While this doesn't provide an answer to your question, some of what I plan would be useful to think about in selecting a bugbase.

The number one feature that I wished to have in bugbases at companies I've worked at in the past was for the user to have an ability to describe a configuration of a machine and then give it a name in the database.

Each user would have some number, one or many, preset machine configurations, particularly the hardware configurations in my case, and the components of these configurations would be drawn from a database describing every piece of hardware that could conceivably be placed in a Linux box.

Then when you go to report a bug, you log in (so your contact info and presets are available), select the config that has the bug, and describe it.

For the Linux kernel, you'd paste in or upload your .config file (this is created by the kernel configuration process).

Then kernel developers could do boolean searches, say "find me all the crashes involving TCP that had a WhizzyNet card installed but in which PPP is not configured in the kernel".

The other part of this is that it is meant to be easy to use for both those who test new kernels (to report bugs) and kernel developers (to research bug reports).

I got the idea to develop the database after subscribing to the linux-kernel mailing list to resolve a bug on my laptop during the 2.4.0-test series kernels.

I was able to work with the list to resolve the bug and see that the patch stuck in the kernel sources, but I felt that many people who might otherwise like to contribute to testing new kernels might be put off by the process of dealing with the list - it's not sufficient simply to report a bug, sometimes patches don't "stick" and you've got to hang around until you're sure your bug stays fixed, but linux-kernel has one of the highest amounts of traffic of any internet mailing list.

Michael D. Crawford
GoingWare Inc

Eh?

Tell that to the psychiatrists and psychologists who treated me in the psychiatric hospital where I spent the summer of 1985, when I was diagnosed with schizoaffective disorder.

Or to my insurance company at the time, who sprung for the $10,000 treatment.

I know it may be fashionable to claim one is manic depressive, but I can assure you it's unmistakeable in me, and it's not something I would choose. There's no Hell so deep as what I experienced in my college days.

If you don't believe me, maybe you'll at least believe I do some good in my writings. I regularly receive emails in response to my website on Manic Depression from people who've experienced it - either they have it or their loved ones do - and they don't know what to do about it.

There is a lot of information available about the illness but because of the stigma which is perpetuated by ignorant people such as yourself, not a lot of folks have the confidence in themselves to speak out about their experience publicly as I do, occasionally here on Slashdot and permanently on that website.

I speak out in part because of my confidence in my position in my career and also my belief that speaking out on what is right is one of the most important things you can do, even when it comes at great personal cost.

The people who write to me tell me the fact that I speak out personally as I do makes a tremendous difference in their lives. It has happened many, many times that someone has written to me to tell me that I'm the first person they've shared the fact that they think they're mentally ill, or contemplating suicide.

You should know that that page receives about 3,000 hits a month, and I recieve several emails a day from people looking for advice, about half of them people who have the illness and the others from people who are closely involved with a sufferer and don't know how to deal with them.

By the way, I'm happily married. I first met my wife three years ago, and we were married in St. John's Newfoundland on July 22, 2000. We just bought our first house together, in Midcoast Maine, and moved into it last weekend.

Michael D. Crawford
GoingWare Inc

I was in and out of my University physics studies a number of times, and having a generally bad time, because of a serious illness, and at some point decided I should get out and get a programming job because I figured I'd be better at that than school.

I didn't really know how to program, I knew a little FORTRAN, C and Basic from doing data analysis during summer jobs, and I didn't really like it all that much. I used to really have to struggle to spend several weeks writing a 500 line program, and I'm sure I'd be embarrassed if I had to look at the source code to those programs today.

I figured I'd program for a while because it paid the rent (I was making $20k a year doing Sun administration and writing image processing software), but when I figured out what I really wanted to do for a living I'd quit programming and get a real job.

That was in 1988. Then some consultant visited and installed GNU Emacs on our machines (two Sun 3/160's, one diskless, both with terminals and no workstation monitor, but with frame grabber cards and NTSC color monitors). He explained about the GNU manifesto.

I thought it was pretty cool but didn't see it affecting me personally in a big way. I was mostly annoyed that I had to wait up while the consultant installed the software on what was supposed to be my day off while a ladyfriend was visiting from away.

Then my friend Jeff Keller, who went to MIT for a while and vaguely knew Richard Stallman, spent an evening with me singing the praises of Emacs. What I really wanted was VI with macros you could program to include conditional branches, and he said it had all though and much much more.

So I learned to actually use Emacs, and soon learned that it was quite extensible, but it wasn't made too clear how to extend it. The online manual was useful mainly to people who already knew what they were doing.

So I read the source code. One thing I was interested in doing was writing C functions that were callable from Emacs lisp as lisp functions. There are many such functions built into Emacs (usually for performance) and you can add your own. There's this big DEFUN macro that even makes the C API look like Lisp.

I learned that and a lot more. I learned what an eloquent statement of software architecture Emacs is.

I learned that there really was something worth my while doing in the way of software.

I wanted to write a program like that someday. Not another big editor, but a program that would someday strike other young programmers the way Emacs struck me.

During the course of reading the source code, one day I stayed at my terminal 24 hours straight, arising only to get coffee and use the restroom, not even eating. I only realized how much time had passed when I started to fall asleep.

That was when I started to take programming seriously. I began to put serious effort into studying programming, and studying it deeply.

For example I would read Knuth's The Art of Computer Programming on the bus on the way to work and I would stay up all night after work learning to program better on my Macintosh at home.

For many years I selected all of my jobs based mainly on what I could learn from them.

I've become a very skilled programmer. You can see this from my consulting business website, my resume (on my resume the place where I first encountered Emacs is the Programmer job at Verde Technologies) and my programming tips pages.

So in a very direct and profound way I owe it all to Richard Stallman and Emacs.

I still haven't written my great program yet. I don't even know what it will be. One project I've worked on peripherally is the ZooLib cross-platform application framework and a project I've just started up but not gotten too far with yet is the Linux Quality Database.

I did finally get my B.A. in Physics, from UC Santa Cruz, but only after being out of school working at a programmer for a number of years.

Michael D. Crawford
GoingWare Inc

I was in and out of my University physics studies a number of times, and having a generally bad time, because of a serious illness, and at some point decided I should get out and get a programming job because I figured I'd be better at that than school.

I didn't really know how to program, I knew a little FORTRAN, C and Basic from doing data analysis during summer jobs, and I didn't really like it all that much. I used to really have to struggle to spend several weeks writing a 500 line program, and I'm sure I'd be embarrassed if I had to look at the source code to those programs today.

I figured I'd program for a while because it paid the rent (I was making $20k a year doing Sun administration and writing image processing software), but when I figured out what I really wanted to do for a living I'd quit programming and get a real job.

That was in 1988. Then some consultant visited and installed GNU Emacs on our machines (two Sun 3/160's, one diskless, both with terminals and no workstation monitor, but with frame grabber cards and NTSC color monitors). He explained about the GNU manifesto.

I thought it was pretty cool but didn't see it affecting me personally in a big way. I was mostly annoyed that I had to wait up while the consultant installed the software on what was supposed to be my day off while a ladyfriend was visiting from away.

Then my friend Jeff Keller, who went to MIT for a while and vaguely knew Richard Stallman, spent an evening with me singing the praises of Emacs. What I really wanted was VI with macros you could program to include conditional branches, and he said it had all though and much much more.

So I learned to actually use Emacs, and soon learned that it was quite extensible, but it wasn't made too clear how to extend it. The online manual was useful mainly to people who already knew what they were doing.

So I read the source code. One thing I was interested in doing was writing C functions that were callable from Emacs lisp as lisp functions. There are many such functions built into Emacs (usually for performance) and you can add your own. There's this big DEFUN macro that even makes the C API look like Lisp.

I learned that and a lot more. I learned what an eloquent statement of software architecture Emacs is.

I learned that there really was something worth my while doing in the way of software.

I wanted to write a program like that someday. Not another big editor, but a program that would someday strike other young programmers the way Emacs struck me.

During the course of reading the source code, one day I stayed at my terminal 24 hours straight, arising only to get coffee and use the restroom, not even eating. I only realized how much time had passed when I started to fall asleep.

That was when I started to take programming seriously. I began to put serious effort into studying programming, and studying it deeply.

For example I would read Knuth's The Art of Computer Programming on the bus on the way to work and I would stay up all night after work learning to program better on my Macintosh at home.

For many years I selected all of my jobs based mainly on what I could learn from them.

I've become a very skilled programmer. You can see this from my consulting business website, my resume (on my resume the place where I first encountered Emacs is the Programmer job at Verde Technologies) and my programming tips pages.

So in a very direct and profound way I owe it all to Richard Stallman and Emacs.

I still haven't written my great program yet. I don't even know what it will be. One project I've worked on peripherally is the ZooLib cross-platform application framework and a project I've just started up but not gotten too far with yet is the Linux Quality Database.

I did finally get my B.A. in Physics, from UC Santa Cruz, but only after being out of school working at a programmer for a number of years.

Michael D. Crawford
GoingWare Inc

I was in and out of my University physics studies a number of times, and having a generally bad time, because of a serious illness, and at some point decided I should get out and get a programming job because I figured I'd be better at that than school.

I didn't really know how to program, I knew a little FORTRAN, C and Basic from doing data analysis during summer jobs, and I didn't really like it all that much. I used to really have to struggle to spend several weeks writing a 500 line program, and I'm sure I'd be embarrassed if I had to look at the source code to those programs today.

I figured I'd program for a while because it paid the rent (I was making $20k a year doing Sun administration and writing image processing software), but when I figured out what I really wanted to do for a living I'd quit programming and get a real job.

That was in 1988. Then some consultant visited and installed GNU Emacs on our machines (two Sun 3/160's, one diskless, both with terminals and no workstation monitor, but with frame grabber cards and NTSC color monitors). He explained about the GNU manifesto.

I thought it was pretty cool but didn't see it affecting me personally in a big way. I was mostly annoyed that I had to wait up while the consultant installed the software on what was supposed to be my day off while a ladyfriend was visiting from away.

Then my friend Jeff Keller, who went to MIT for a while and vaguely knew Richard Stallman, spent an evening with me singing the praises of Emacs. What I really wanted was VI with macros you could program to include conditional branches, and he said it had all though and much much more.

So I learned to actually use Emacs, and soon learned that it was quite extensible, but it wasn't made too clear how to extend it. The online manual was useful mainly to people who already knew what they were doing.

So I read the source code. One thing I was interested in doing was writing C functions that were callable from Emacs lisp as lisp functions. There are many such functions built into Emacs (usually for performance) and you can add your own. There's this big DEFUN macro that even makes the C API look like Lisp.

I learned that and a lot more. I learned what an eloquent statement of software architecture Emacs is.

I learned that there really was something worth my while doing in the way of software.

I wanted to write a program like that someday. Not another big editor, but a program that would someday strike other young programmers the way Emacs struck me.

During the course of reading the source code, one day I stayed at my terminal 24 hours straight, arising only to get coffee and use the restroom, not even eating. I only realized how much time had passed when I started to fall asleep.

That was when I started to take programming seriously. I began to put serious effort into studying programming, and studying it deeply.

For example I would read Knuth's The Art of Computer Programming on the bus on the way to work and I would stay up all night after work learning to program better on my Macintosh at home.

For many years I selected all of my jobs based mainly on what I could learn from them.

I've become a very skilled programmer. You can see this from my consulting business website, my resume (on my resume the place where I first encountered Emacs is the Programmer job at Verde Technologies) and my programming tips pages.

So in a very direct and profound way I owe it all to Richard Stallman and Emacs.

I still haven't written my great program yet. I don't even know what it will be. One project I've worked on peripherally is the ZooLib cross-platform application framework and a project I've just started up but not gotten too far with yet is the Linux Quality Database.

I did finally get my B.A. in Physics, from UC Santa Cruz, but only after being out of school working at a programmer for a number of years.

Michael D. Crawford
GoingWare Inc

Who's incompetence?

The developers were out their shipping many fine, supported commercial products that worked very well - Gobe, Steinberg was onboard developing audio applications, Thomas Dolby spoke at the developer conference about supporting Be with his audio software (he was wildly enthusiastic).

No, the incompetence was not the developers. It was Be's press relations and marketing (or to be more precise, the lack thereof). Be's technical staff is highly competent, and they produced a fine product, something Linux developers would do well to study because of it's ease of installation, smooth and trouble-free performance, and clean integration. It's also a joy to program.

My wonderfully positive experiences with using the BeOS and my sadness at having to leave the platform behind in order to have currently supported hardware and software is another component of what motivates my effort to improve the quality of Linux and Free Software in general.

But Be's business management was always, and still is, incompetent. There was never any effort made to convince people to make the move to the BeOS - they were always waiting for more applications to appear, even when there were plenty of applications for the average user to do almost all their daily work.

Even though almost anyone who ever laid eyes on the system became an instant convert - and many of those became evangelists, such as I especially after I got it running on my laptop, Gassee never felt it was ready for the mass market and kept holding it back from the people who could have done him the most good - the public who was eager to try something better if only they knew it existed and where to get it.

For example, I never once saw a banner ad on a website that was run on a non-Be related site directing the user to Be's website or BeDepot (Be's now-defunct eCommerce site).

And speaking of BeDepot - Gassee very early on spoke repeatedly about the problem of penetrating software channels for new developers, especially developers for new platforms like the BeOS, and how Be was going to be very advanced in its thinking by offerring software for sale via download at BeDepot.

And we all have seen what has become of eCommerce in general - it's the only way you can get many products for mainstream platforms - but BeDepot was one of the most ineptly run operations I have ever seen.

BeDepot's ineptitude was murder to developers for whom it was the only sales channel - so you've got a newly released product? What do you do when it takes three months to appear on the website because they're either too understaffed to deal with it or too incompetent to just upload the damn file? I've heard lots of complaints from developers who had to wait months to receive their contract from Be that would enable them to sell on BeDepot.

It's not like it's so hard to run a good online Be software site, as demonstrated by the folks who founded BeBits, in part to make up for BeDepot's and BeWare's inadequacies. (BeWare was for free downloads).

If you won't listen to me because of Be's lack of character, listen to me because of Be's demonstrated incompetence, and know that if they couldn't keep an eCommerce site with a few dozen titles running efficiently, how are they going to provide adequate support for a bunch of disparate embedded hardware vendors?

By the way, you should note that many of Be's most prominent engineers left when Be made the decision to drop the desktop and move to Internet Appliances, folks like Dominic who wrote the BFS Journaled Filesystem (with indexed file attributes - there's a read-only version of BFS you can get for Linux, that I'd like to make read-write, and would make a great addition to the system).

Michael D. Crawford
GoingWare Inc

If anyone from Sony is reading this, I'd like you to understand that Be, Inc. does not possess the moral fiber that is necessary for a company you will be trusting for a business-critical component of any product.

This lack of integrity goes to the heart of Be's corporate culture, and is in particular exemplified by the attitudes and practices of Be's CEO, Jean Louis Gassee.

Read about the experience of one of Be's formerly most-loyal and most enthusiastic business partners in:

• The Valley is a Harsh Mistress

Note: the page gives the URL's for a number of alternative vendors for Internet Appliance operating systems, many of which are open source (an important consideration in a market where your vendor may abandon you). Also see the Embedded Linux Journal.

I have no doubt that BeIA has tremendous technical advantages. See what this once-ardent BeOS developer is doing to harden the competition for Be Inc. at The Linux Quality Database and Freeing the Developer from OS Vendor Shackles.

Michael D. Crawford
GoingWare Inc

Well I guess I was hoping there would be more widespread testing before the -nothing release was released, because now that 2.4.0 final has been released, some distros are likely to use it right away rather than wait for bugs to stabilize and some people will put it straight into production use.

So just yesterday I wrote:

• Why We Should All Test the New Linux Kernel

on Advogato.

It's got some helpful, practical tips on downloading and building a kernel from sources as well as providing feedback to the kernel developers. All of the information in the article is available somewhere, but when I first began testing with 2.4.0-test1, I found some things difficult to figure out, so I felt that it would be nice to put what I learned all down in one place.

This is part of an overall effort to improve the quality of Free Software. Another part of the effort is the just-founded Linux Quality Database, so far just a proposal - contact me at crawford@goingware.com if you want to help.

And finally, some interesting trivia for you:

After a long beta testing period and many delays, Windows 2000 shipped with 64000 documented bugs of which 25000 were considered serious by Microsoft itself (the figures are quoted from memory, I might be a bit off). The Windows trade press reported that the opinion was widely held by IT managers that one should not install Windows 2000 on any machine until a few service packs had been released, with Windows 2000 server not being considered ready for use until much later than the desktop user version.

The BSD/Mach based Mac OS X, derived from the NeXT operating system and now in beta testing, is Apple's first operating system to support protected memory that is expected to be widely used. (Another was A/UX, Apple's Unix port, but it served only a niche market).

Apple has been trying for ten years, longer than Linux has been in existence, to write a modern operating system. The first was Pink, renamed Taligent when Apple collaborated with IBM on it. In the end all that came of it was a little-used object-oriented programming framework.

The next was Copland, and I don't know why it was never completed exactly, but I was offerred a job as a performance engineer on the Copland project when I worked at Apple, but I turned it down - I didn't tell them this but I had the sense that Copland was a project that would never ship.

And Linus wrote Linux when he was a college student, which combined with the GNU utilities forms the operating system we know and love today.

These huge, well-funded corporations can't get it together to program their way out of a wet paper bag but a bunch of freaks on the Net have written the fastest growing operating system in use today.

Michael D. Crawford
GoingWare Inc

Stroustrup has some things to say about C++ education. I think he mentioned it in his QA a while back here on slashdot in C++ Answers with Bjarne Stroustrup.

In general Stroustrup feels that a lot of the trouble people have with C++ is that it's not taught very well and he's making an effort to address that. One concern he has is that a common teaching approach is to teach C first and then "move up" to C++.

But this is a huge problem because you really don't want to do things the same way in C and C++ - for example, you learn char-array based strings in C and then have to forget them to use the string template in C++ - and often instructors don't bother to teach the different styles or worse don't know them themselves.

He discusses this in his paper Learning C++ as a New Language (PDF format) which you'll find on his papers page.

I didn't have too high a regard for C++ until I read the abovementioned slashdot Q&A but I decided then that it would be really worth my while to devote some serious effort to studying it. I did, mostly last spring and summer and the results immediately paid off, in terms of writing cleaner code, more efficient code, having fewer bugs and architecting things that I couldn't have hoped to have done before I'd put that effort into study.

I discuss that in Study Fundamentals Not APIs, Tools or OSes.

Michael D. Crawford
GoingWare Inc

I am dismayed my the comments here that report that AP Computer Science does not teach much about classes or object-oriented programming. I think it is crucial to teach OOP. Consider this for a second:

Compare how frequently you have to design and implement classes in your own work to the frequency with which you need to design and implement algorithms. These days, all the algorithms and data structures that would be taught in an AP class are provided by libraries that you just use. I know the vast majority of code anyone writes just sort of does stuff, it can hardly be called an algorithm. But making good choices about program structure (and these days this means class structure) is crucial to having any hope of ever getting a program to work, let alone run efficiently.

A while back the San Jose State University Professional Development Center asked me to teach some programming classes.

I proposed to teach two classes, one on the fundamentals of object-oriented programming, and the other an OOP project - writing a program of some significant size (considering the experience level of the students).

My descriptions of the two classes are given here. The links to the original course descriptions in that page seem to be dead now.

I felt that these two courses addressed two signicant flaws in most introductory programming education - one was an inordinate focus on the particulars of a language without concentrating on how to program well, and the other was that the exercises done in a course rarely took more than a week to do, and even if there was a term project, it usually was mixed in with other work, and so it wouldn't be of significant size.

This means that exercises in most introductory courses typically gloss over important issues that crop up in real software development, like robust error handling and dealing with the architecture of your program on a large scale.

These courses weren't meant to be that long so I really couldn't get that far into it but the point was that I would be neither teaching the language nor computer science (algorithms, data structures, etc.). Instead, I would be teaching what I could probably get flamed at for calling The Art of Software Engineering.

In the first course, I would concentrate on how to make good choices for what classes to use in your program and how they should relate to each other (when to use inheritance vs. composition, for example), basically how to acquire a good sense of aesthetics for the best way to divide your problem into maanageable parts. There are an infinitude of ways you can write a program, but a far lesser number of good ways to write a program, and this is not commonly taught.

I would use Java in the class, but cover the bare minimum of the language required to cover the conceptual material. Someone else was planning on teaching a course on Java itself.

I also felt that the project course would be of significant value in helping the students find real programming jobs. While they may have to expand on the projects after leaving the class, I knew that (at the time anyway), noone would hire a novice programmer until he'd shipped a product (oh how times have changed) - free software and shareware does count as a real product, but the important thing is that you have to have completed a program of some significant size.

Ironically, the courses were canceled after only two students signed up for them by the enrollment deadline.

Our general theory was that the students didn't percieve this classes as having an immediate payoff in a marketable job skill (SJSU Prof Dev was in good part a fundraising component of the regular University so the classes were frequently targeted towards marketable skills) - when really I felt it would do you more good than a class concentrating on Java or any particular language - it's not hard to pick up a language out of a book but what I meant to teach really would need personal interaction and discussion with an instructor and one's classmates.

I'd still like to teach the classes. I am doing just that in one form by writing GoingWare's Bag of Programming Tips.

Michael D. Crawford
GoingWare Inc

I am dismayed my the comments here that report that AP Computer Science does not teach much about classes or object-oriented programming. I think it is crucial to teach OOP. Consider this for a second:

Compare how frequently you have to design and implement classes in your own work to the frequency with which you need to design and implement algorithms. These days, all the algorithms and data structures that would be taught in an AP class are provided by libraries that you just use. I know the vast majority of code anyone writes just sort of does stuff, it can hardly be called an algorithm. But making good choices about program structure (and these days this means class structure) is crucial to having any hope of ever getting a program to work, let alone run efficiently.

A while back the San Jose State University Professional Development Center asked me to teach some programming classes.

I proposed to teach two classes, one on the fundamentals of object-oriented programming, and the other an OOP project - writing a program of some significant size (considering the experience level of the students).

My descriptions of the two classes are given here. The links to the original course descriptions in that page seem to be dead now.

I felt that these two courses addressed two signicant flaws in most introductory programming education - one was an inordinate focus on the particulars of a language without concentrating on how to program well, and the other was that the exercises done in a course rarely took more than a week to do, and even if there was a term project, it usually was mixed in with other work, and so it wouldn't be of significant size.

This means that exercises in most introductory courses typically gloss over important issues that crop up in real software development, like robust error handling and dealing with the architecture of your program on a large scale.

These courses weren't meant to be that long so I really couldn't get that far into it but the point was that I would be neither teaching the language nor computer science (algorithms, data structures, etc.). Instead, I would be teaching what I could probably get flamed at for calling The Art of Software Engineering.

In the first course, I would concentrate on how to make good choices for what classes to use in your program and how they should relate to each other (when to use inheritance vs. composition, for example), basically how to acquire a good sense of aesthetics for the best way to divide your problem into maanageable parts. There are an infinitude of ways you can write a program, but a far lesser number of good ways to write a program, and this is not commonly taught.

I would use Java in the class, but cover the bare minimum of the language required to cover the conceptual material. Someone else was planning on teaching a course on Java itself.

I also felt that the project course would be of significant value in helping the students find real programming jobs. While they may have to expand on the projects after leaving the class, I knew that (at the time anyway), noone would hire a novice programmer until he'd shipped a product (oh how times have changed) - free software and shareware does count as a real product, but the important thing is that you have to have completed a program of some significant size.

Ironically, the courses were canceled after only two students signed up for them by the enrollment deadline.

Our general theory was that the students didn't percieve this classes as having an immediate payoff in a marketable job skill (SJSU Prof Dev was in good part a fundraising component of the regular University so the classes were frequently targeted towards marketable skills) - when really I felt it would do you more good than a class concentrating on Java or any particular language - it's not hard to pick up a language out of a book but what I meant to teach really would need personal interaction and discussion with an instructor and one's classmates.

I'd still like to teach the classes. I am doing just that in one form by writing GoingWare's Bag of Programming Tips.

Michael D. Crawford
GoingWare Inc

I have written a proposal for an organized linux QA effort that will center around a bug database that is accessed via the web.

I think actually the kernel is of very high quality, compared to competing operating systems like the windows kernel or the Mac OS system, but it does take a long time for the kernel to get the kinks worked out.

I realized when I got onto the Linux-Kernel mailing list to report a bug in 2.4.0-test a few months ago that people who were less hardcore developers would probably be put off by the process of reporting bugs to the kernel, and suggested this database to the kernel mailing list. It was generally well received.

In the long run, I'd like all of Free Software to be more rigorously tested for quality. This is just a start - but the database source, and parts of the database itself could be reused for other projects.

If you'd like to participate, please email me at crawford@goingware.com

Michael D. Crawford
GoingWare Inc

I have written a proposal for an organized linux QA effort that will center around a bug database that is accessed via the web.

I think actually the kernel is of very high quality, compared to competing operating systems like the windows kernel or the Mac OS system, but it does take a long time for the kernel to get the kinks worked out.

I realized when I got onto the Linux-Kernel mailing list to report a bug in 2.4.0-test a few months ago that people who were less hardcore developers would probably be put off by the process of reporting bugs to the kernel, and suggested this database to the kernel mailing list. It was generally well received.

In the long run, I'd like all of Free Software to be more rigorously tested for quality. This is just a start - but the database source, and parts of the database itself could be reused for other projects.

If you'd like to participate, please email me at crawford@goingware.com

Michael D. Crawford
GoingWare Inc

I've been employed as a full-time, independent consultant for two years and eight months. By independent, I mean I don't work through agencies.

Please read why I feel you shouldn't either:

• Important Notes to Recruiters and Contract Agencies
• Market Yourself - Tips for High-Tech Consultants

At the very least, recruiters and contract agencies take 30% of your pay - recruiters take 30% of your first years pay, agencies take it the whole time you're a contractor. But if they can get away with it, they will take far more.

And they're pushy and ignorant besides. How many of you have gotten a phone call from an agency who wanted to place you who clearly hadn't even read your resume, let alone understood it? The above two pages contain many horrifying anecdotes of recruiter and contract agency abuses, unethical practices and just plain stupidity.

Michael D. Crawford
GoingWare Inc

I've been employed as a full-time, independent consultant for two years and eight months. By independent, I mean I don't work through agencies.

Please read why I feel you shouldn't either:

• Important Notes to Recruiters and Contract Agencies
• Market Yourself - Tips for High-Tech Consultants

At the very least, recruiters and contract agencies take 30% of your pay - recruiters take 30% of your first years pay, agencies take it the whole time you're a contractor. But if they can get away with it, they will take far more.

And they're pushy and ignorant besides. How many of you have gotten a phone call from an agency who wanted to place you who clearly hadn't even read your resume, let alone understood it? The above two pages contain many horrifying anecdotes of recruiter and contract agency abuses, unethical practices and just plain stupidity.

Michael D. Crawford
GoingWare Inc

It's usually in the contract that the client isn't told how much you make and isn't even allowed to ask. You can be sure that as your skills increased your agency charged more. They just kep the difference and you didn't see any of it. This is very common, especially with the less experienced contractors.

There was one poor guy on alt.computer.consultants that was making $30 an hour from his agency, but they were billing him to the client at $90 per hour!

This is one of the instances of unethical agency practices that led me to write Market Yourself - Tips for High-Tech Consultants

Michael D. Crawford
GoingWare Inc