This weekend is Daylight Savings Time. As I learned in college the "Spring forward, Fall back" policy means that we all get an extra hour of sleep Sunday morning. It came as a shock when I learned that Congress recently legislated that Daylight Savings Time will start weeks later next year. This potentially means that millions of dollars will be spent before March on updating computers -- from embedded system in elevators to the servers that power large online stores -- to comply with the new time zone rules. Sleep well Sunday!

Noam Chomsky Is an Idiot

Noam Chomsky is not a genius. Further proof? A crackpot dictator promoted one of his books on the floor of the United Nations.

Read Steven Pinker's The Language Instinct instead. He makes the case that language is an instinct breed into humans after years of evolution. This contradicts Chomsky's assertion that language is innate and the same for all humans where differences in languages are accounted for by tweaks to a small set of parameters.

I tend to subscribe to Pinker's theory. Also, reading Pinker won't make you puke.

Security Testing

Operational Validation Testing

Performance Testing

Performance testing, or load testing, investigates how well your software system performs under load. Your software may behave differently when there is one user and when there are fifty simultaneous users. I am loath to admit that I worked on a system that locked up when there were five simultaneous users. Hey, it wasn't my design!

The point is that some errors only manifest themselves when a load is applied to the system. This testing finds things such as deadlock, memory leaks and invalid use of such things as shared memory, semaphores and threads. Any change that could adversely affect performance should be tested.

This week of testing topics continues tomorrow with my discussion of operational validation testing. Don't miss it!

Verification Testing

Verification testing, or requirements testing, is testing to make sure the software meets the project's requirements. This testing is usually done by a third party, i.e. not the developer. Many companies have a dedicated test team for this function.

If you work with an independent tester, be sure to make them a part of the project from the being. This includes design meetings. Their job is to look at the requirements and figure out how to test them. Take the time to explain your design and development to your test engineer. Do not focus so much on the coding that you neglect your team.

Speaking of requirements, the only hurricanes New Orleans requires are the mixed drinks. Don't ya think?

Tomorrow I plan to discuss performance testing.

Integration Testing

Integration testing, or end-to-end testing, tests how well software components integrate. For large projects there may be several different components that are written by different people or even teams. There is a potential for a breakdown in communcation. For example one component may feed another component by placing a value on a database table.

While unit testing is focused on source code modules, integration testing is concerned about the system as a whole. In this testing data may be fed into the system to watch how it behaves when it reaches your source code and, in turn, how your code affects other components.

It is important to understand the system architecture as whole. Write a formal plan that describes two things: 1) what you plan to test and 2) what you expect the results to be. Document any results that differ from your expected results. They should either be fixed or explained.

Holy Batcars! Don't miss tomorrow's blog entry when I will discuss verification testing. Boffo!

Unit Testing

Fundamentals of Software Testing

This coming weeking I plan to discuss various topics in software testing. Today I am going to cover the fundamentals. Unfortunately, I do not recall formal testing being taught in college. My experience has come from on-the-job lessons learned.

To start with you should have at least three classes of servers. Your company and budget may be small. In that case the development and staging server could potentially share the same box.

TYPES OF SERVERS

• Development Servers
• Staging Servers
• Production Servers

A development server is a server on which code is developed. Once development is completed, then it is installed on a staging server. A staging server should match the production server as closely as possible. This includes, the same version of operating system, the same software and the same configuration. The staging server is your last chance to discuss bugs before it hits the production server. The production server is the server that runs your code live. It is what your customer uses.

By seperating the servers in this way you can test on the staging server and develop on the development server. This is particularly useful if the test takes a long time. The developers can start working on bug fixes even before all of the tests complete.

Stayed tuned for tomorrow's topic: Unit Testing

Krugle and the Microsofties

There is an interesting project that aims to be the google of freely available source code. I have high hopes for krugle. It is a search engine that is smart about how source code is organized. Instead of just treating code just like lines of text, krugle organizes it into projects and displays it with syntax highlighting. Right now the site is in closed beta. I cannot wait to try it live.

Microsoft Research scientists say that schools and colleges are not training the next generation of scientists with the necessary computer skills. Hey Microsoft, how about you give us the next version of the Windows operating system before you judge? The last Microsoft Windows release was Windows XP in 2001! Computer journalists initially forecasted the next version in 2003. But after a redesign, streamlining planned features and a recent restructuring, we can look forward to seeing Windows Vista sometime next year.

Disaster Recovery For Technology

One of my first tasks when I joined the staff of the U.S. District Court was to write a disaster recovery plan for the IT department. While everyone knows the importance of backups (right? RIGHT?), not everybody considers the importance of establishing offsite backups.

Offsite backups are critical for disaster recovery. You will need them in the event a disaster causes physical damage to your computers.

Things have changed since I wrote that first disaster recovery plan. Nowadays renting space on a managed Internet server is cheaper than tape backups. Take a look at file hosting providers and online backup and recovery services.

Tangled Brier of Dependencies

When dealing with project schedules, a dependency occurs when one task must complete before the next one can begin. Ideally you want to minimize the impact of dependencies on your schedule. One method is to schedule many tasks in parallel. If a developer is waiting for another task to complete, the schedule can give another task on which she can work.

Joel on Software says that dependencies are so obvious that he thinks that they should not be tracked. I agree that they can appear obvious to experienced project managers. But project managers are not the only people to use schedules. A new employee may want to use your schedule as a basis on which to estimate their schedule. Remember that your "customer" can also include your team and your company.

So, identify dependencies, document them and manage them with parallelism. Your project and your customer will benefit.

More Choice, New Hope

Lets face it. We are all different. We have different tastes and like different things. Wouldn't it make sense that having choices would better please more people? In a recent article in the Linux Journal entitled "Separation of Church and Choice" the author made a case that choice alone is not a good reason to create software. While his article is churlish and bashes religion, it did make me think of an interesting question: Are too many choices in software bad?

The short answer is, of course not! I snicker when I hear about the supposed "tyranny of choice". Competition is good. The fact is that the strong will survive. The weak will adapt or find a small niche of supporters.

Having said that I see a case for cutting through the clutter. If you put together an integrated software system and plan to support it, then you will limit the number of supported choices. This makes fixing problems manageable. Also, provide a help system, e.g. a software wizard, to guide novice users by recommending common choices. It will keep them from becoming overwhelmed with new software.

Now, who wants some pie? What kind of pie?

Coding Standards Give Software Quality

How do you measure the quality of software? What distinguishes good source code from bad? Coding standards measure software quality.

Well-written coding standards define naming conventions. They also describe how comments document code. They discuss the layout of source code modules. They forbid the use of goto statements and self-modifying code. They may discuss the management of dependecies. In general coding standards draw on developer experience to produce guidelines that make code functional, readable and maintainable.

Your organization may bristle at the idea of a formal coding standards document. A coding checklist may suffice in its place. This gives guidance to the developer and may give a good discussion point for a peer review.

Speaking of quality, why isn't there anything good on TV?

When Web Applications Want a State

One of the lovely things about the Web is that you can traverse pages in any order you like. Sometimes it is necessary to remember information between pages. Think about Amazon.com's shopping cart. As you find items you like, you can add them to the shopping cart. When you are ready to check out, the items selected are displayed. In order to remember information as you navigate between pages, a web application has to maintain 'state'. In computer geek terms we say that the shopping cart application is stateful.

In order to remember your shopping cart items the application uses a server provided construct called a session. A session persists for a specified period of time across multiple connections and page requests from the same client. Using the session and a database we can store, retrieve and associate session data with a given user ID.

One mistake to maintain state is to use hidden form fields. This is a security risk open to an exploit known as cross-site scripting. It is much better to store such values on a database instead. You can use the session id as a key field. On subsequent pages the value can be looked up.

Another mistake is to try to maintain state by trying to persist data in objects declared in servlet code. This breaks down when there are multiple users. These objects are not thread-safe. That is, one user's data can corrupt another user's data.

So a good way to implement state in a web application is to use a database in conjunction with the session. By avoiding some common mistakes you can protect your website.

Plan Multiple Phases

It has been my experience that short-term projects with a small team are the most rewarding way to produce software. Long running projects tend to suffer team turnover and burnout. A large team introduces new issues such a potential breakdown in communication.

Unfortunately not every project can fit inside of a three or six month schedule. It may be necessary to divide a project into phases. The purpose of each phase would be to fit into a short-term schedule.

The customer may be enthused by early versions of the software and may want to add new features. Also, the engineers may want to write geeky stuff that could help the project but whose scope is outside that of the project requirements. I recommend that you avoid this feature and requirements creep. Track the requests and assign them to later phases.

By focusing on short-term projects your customer will appreciate the quick turnaround of new software releases. Your team can take pride in their accomplishments. A successful project release will help motivate them as they start the next phase of the project.

Rocking the KLOC

Management might want to measure how productive their computer professionals are. One way to determine this is to count the lines of code (LOC) that have been produced. The term KLOC means 'a thousand lines of code'. The thinking is that the more KLOC written, the more productive the team is. Lets take a moment to examine this more closely.

Do comments count toward the KLOC count? If not, why do you wish to penalize programmers for documenting their work? If yes, is a developer who writes a two hundred lines of comments accomplishing more than a coder who wrote fifty lines of code?

It may seem counterintuitive, but a programmer who writes fewer KLOC may actually be good for a project. Writing good software is a matter of managing complexity. An experienced developer will identify code that does the same work and will refactor the code to eliminate redundancy. So, eliminating lines of code is actually a good thing for a project. It helps reduce complexity which improves the time it takes to make code fixes.

There are better ways by which to measure productivity. One such method is to measure project hours. Project tasks are written down in a schedule called a work breakdown structure. Then an hour estimate is assigned to each task. Before a project starts the developers review the schedule and make any adjustments. Then developer productivity can be measured against how closely they follow the schedule.

Onions to the KLOC, orchids to project hours! Agree? Disagree? I'd love to hear about it.

Version Control Saves Sanity

Sometimes when you change code to fix a problem, a new error is uncovered. Sometimes the error was introduced by your fix. Other times the error existed but was masked by another error. When the error is found, you will want to compare the latest version of source code against old versions to see what has changed. A version control tool is invaluable for this task because it keeps track of the all versions of files.

Without version control two coders may attempt to change the same file. Changes can get lost. One coder might save his work over another coder's work thus clobbering her changes. Some types of version control software work as a library. That is, they allow only one coder to check out and change a file at a time. Other software permits multiple coders to each work on private copies of source code and merges their changes when the code is checked in.

Team members can easily update their copies of all the project's files to the current versions. Without version control software this process can be time consuming and tricky.

If you mess up code badly, version control software can revert any file to a previous version. This frees developers to try bold, daring ideas.

Version control software can allow projects to fork off the main baseline into seperate branches. In fact multiple projects can each work on seperate branches of source code. Once a project is completed its branch can be merged back into the main baseline.

Integrating version control software with defect tracking software gives a powerful tool to maintain projects. You can use identification numbers assigned by the defect tracking tool to identify code changes. Then it is possible to examine of the history of file changes to see that bugs were fixed.

I have been amazed by the number of places that attempt to write software without version control software. It is not strictly necessary to have a version control tool in order to write software. But I would not try to work on a project without such a tool.

Code Comments That Work

Document your code. This is done by inserting comments. The computer ignores them but they are read by other programmers. Almost all serious programming languages allow comments. However, not everyone agrees on how many comments to write and what they should contain.

A common practice I have seen is to write program prologues. These are a collection of comments found at the very beginning of a source code module. Usually it documents: a copyright notice, the source code module name, a description, the date created, the author's name and the revision history.

Each method can also have a prologue that documents: the method name, a description, the parameters and the return type. I have heard it said that these comments are not necessary since code is self-commenting. The argument goes that if the author chooses a descriptive name for a method and its parameters, then no comments are necessary. In practice this is never true. Don't be that lazy and arrogant developer who needs a swift kick in the posterior.

It is possible to go overboard and document too much. The problem here is that as code changes you now have an additional task of maintaining the comments. A good rule of thumb is:

Comments should document the "why" not the "how"

For example if the developer choose to implement a splay tree he should not document the fact that it is a splay tree. Why? Because another developer may decide that a red-black tree performs better and replace the original implementation. Now the comment has to change, too. It is better to document things like hacks and decisions that maintaining developers should notice. For example, if there is a bug in the third party library you use to format a date, a workaround may be developed to fix it. A comment should be written to document the fact that the code has been written to work around the problem.

Remember that comments are written for humans. Be aware that other developers read them. Do you really want them to remember you as a foul mouthed crank? Think about that before vent your frustrations in your code comments. Just a thought.

Can Programming Be Art?

I was thinking about the whiny outburst of former Winamp programmer Justin Frankel a few years ago. He started Nullsoft, made Winamp and then sold it to America Online (AOL) for $86 million. Then the renegade developer released a piece of file sharing software that was embarassing in light of the proposed AOL and Time Warner merger. When AOL did the corporately responsible thing by blocking the software. Frankel threw a fit. In his blog entry he states: "For me, coding is a form of self-expression" and "The company controls the most effective means of self-expression I have". Boo hoo, poor millionaire! He did not get much sympathy from us professional developers.

So, I pondered these questions: Is coding really a form of self-expression? Can software engineers express themselves in code? Can programming be considered art?

Let me clear us something. Coding, or programming, is only one-fifth of the complete software engineering process. All of the steps are: design, programming, documenting, testing and maintaining.

I like to compare software engineering to building a car. Is car building art? The process of assembling a car can hardly be considered a form of self-expression.

There are certainly cars that people think are beautiful. But mechanics do not sit around with stacks of auto parts and try to make a Mustang. There usually is a design first. Also, most cars are safety tested. I think it is irresponsible to release software without testing it thoroughly. Why aren't more software companies held responsible for the financial impacts that their buggy products cause? How is it we have come to expect computer software to fail? That is a discussion for another blog entry.

How does software get written? In the corporate world it starts with a business problem. For example a chain of Mexican restaurants might ask: "How many fajitas did I sell yesterday?" The initial step in software engineering is to identify the business problem and gather requirements. Then a design is developed. If a design is good, then the process of coding is almost mechanical. Of course, there are issues that arise that need creative solutions. I think the structure of software code and creative solutions to issues are the closest a coder really comes to self-expression.

So, can programming be art? No. Coding is best accomplished by a disciplined engineering approach rather as an art project. The resulting software can be admired and maybe even be considered art. But sitting at a computer and writing code is not a form of self-expression. That's best saved for blog entry comments. Practice self-expression. Please post a comment.

Sync Your Clocks

Flavor Flav knows what time it is. He wears a clock around his neck to help.

A common problem I have encountered in software development and testing is clock synchronization. Internal computer clock time will drift to inaccurate values even when initially set accurately. PC clock circuits only cost a few cents to make and are notorious for becoming wrong over time.

This causes a variety of problems. Developers on Unix systems like to use the 'make' command. This command compiles new and modified code without having to recompile unchanged code. It uses the clock to deteremine which files need to be recompiled. If source code resides on a separate server and the clocks are not synchronized then the make program will not work correctly.

Another problem manifested by unsynchronized clocks is correlating test results. Imagine running a load test on system where the client, database server and application server all have different times. Someone trying to analyze the results of the test will go cross-eyed trying to examine critical events in the test. I have seen this problem at two different companies now.

A network time server should be used to keep every computer's time in sync. The most used solution for clock synchronization is the Network Time Protocol (NTP). It utilizes a client/server architecture based on UDP message passing. Fortunately, it is also built into the latest versions of Windows and most Linux distributions.

In order to keep your clock in sync in Windows right-click on the date/time in the task-bar. Now click on 'Adjust Date/Time'. Now click on the 'Internet Time' tab. Yeeeeaaaahhhh Booooyyyy!

Amazon's Mechanical Turk

An email arrived today from Amazon announcing the Amazon Mechanical Turk web service. It is named after a famous 19th century chess playing machine that turned out to really have a person inside.

Amazon touts the service as "Artificial" Artificial Intelligence. It works like this. A company may send trucks through a business district taking photos. They then need somebody to pick the best ones for a database of store images. In exchange for a couple cents a human can take a look at a few photos and select the one that best looks like a storefront.

Developers can use web services to submit tasks to the Amazon Mechanical Turk web site, approve completed tasks and incorporate the answers into their software applications. To the developer the application sends the request to the web service. In turn the service returns the result. Behind the scenes the results are the product of human input. Humans come to the web site, search for and complete tasks and receive payment for their work.

Got spare time? Earn a few cents.

Elements of Web Design

This weekend I discussed potential web page designs for Atomic Squash with Jason. Our conversation reminded me of some slides I wrote for an advanced HTML class at work. Over the years I have seen many poorly designed websites. Web page authors, it seems, tend to make some of the same mistakes when first learning HTML.

The following is a list of elements of good and poor design.

Elements of Poor Design

• Avoid gaudy backgrounds. A simple color is better.
• Avoid unreadable text and background combinations. You know about what I am talking.
• Do not make "Under Construction" pages. It is best just not to show a page that does not have content.
• Avoid frames. They break bookmarks. Use a table or div tags for layout instead.

Elements of Good Design

• Make a site map. If you have a large collection of web pages, this is invaluable.
• The top of the page is the most valuable part. Put a navigation bar and the most important content there.
• Use footers. Footers provide a visual cue to the end of content.
• Use context. Avoid "Click Here".
• Give file sizes for files over 100kb in size. This prepares the user for large downloads.

Computer Science Projects That Interest Me

Dijkstra, a famous computer scientist, once said: "Computer science is no more about computers than astronomy is about telescopes." Computer science deals with design principles, requirements analysis, implementation of hardware and software, documenting and testing solutions and maintaining production systems. As you can see programming is only a small part of what is involved.

An article I read earlier this year lamented the fact there have not been any notable innovations in technology in recent history. So I thought about what innovations are possible given today's technology. The following is my list of computer science projects which are ripe for innovation and which interest me:

COMPUTER SCIENCE PROJECTS THAT INTEREST ME

1. Compiled Javascript

Javascript is an interpreted scripting language built in to most web browsers. Most interactive web pages utilize javascript to do things like validate input or dynamically change form elements. One of the weaknesses with javascript is that all of the comments are sent, too. For pages with large amounts of javascript this amounts to lots of wasted bandwidth. It should be possible to compile javascript into codes that can be run in a sandbox within the browser. The process of compilation would eliminate comments and distill the code into a compact collection of byte codes.

2. Wired Elvis

A computer science professor once wrote a program to algorithmically generated jazz riffs using a functional programming language. I've always wondered what rock and roll could sound like if it were generated by a computer. Lets put the core in Haskore.

3. Anonymous P2P Networking

Peer-to-Peer (P2P) networks have made headlines lately. A fundamental issue with today's P2P networks is that once you connect to the network your IP address is publicly available. This makes you a target esp. since information about your data transfers are routing through super nodes. It is theoretically possible to anonymize connection information. Some work has been done lately about obfuscating routing using a concept known as onion routing. It is not easy but I think it is possible to anonymize all connection information including the IP address. The question becomes, is it possible to ensure successful transfer given an anonymous destination? I think it is as long as you have at least three trusted servers. I haven't worked out in my head how to protect the servers against untrustworthy servers or servers colluding to "poison the well".

4. Whipping the WIMP

We can been using the same windows-icon-mouse pointer paradigm since it was invented in the 1970s. But people are still intimidated by using computers. Lets face it speech is a more natural means of communication. Advances in voice recognition mean that computers understand us better than ever before. Isn't time that we at least augmented our system software with voice and gesture recognition?

5. Morose Pointer

Alan Turing proposed a test in which a computer program tries to fool human testers into thinking that they are communicating with a human. Every year there is a contest in which competitors try to see who does their best to meet the Turing Test. I'd like to go step beyond this. Can a computer make you cry? Can we care enough about a computer program to feel emotion? The mind boggles.

6. Parallel Compiler

In college I did independent research in the area of parallel computing. The compilers available at the time were poor. The best available was a compiler that took the C programming language and did its best to parallelize the instructions. There were other compilers and languages but they were awkward and difficult to program. As multiple processor PCs appear on mainstream desktops, the question is: is it time for a new programming language? I believe it is time for a language and compiler that is designed around explicit parallelism.

Wikis Do Not Work for Technical Documentation

Open source software developers need to give credit and respect to documentation developers. The hard work needed for technical documentation is underappreciated. Unfortunately, the prevelant attitude among software developers is to install a Wiki and depend on the good will of others to document their projects.

Wikis do not work for technical documentation. For technical documentation to be usable it must be clear, complete, correct and current. Wikis fail on all of these points.

:: CLEAR

Most technical documentation Wikis are a mess. They are an unorganized pile of articles that can duplicate or contradict each other. Most Wikis are unmanaged by anybody responsible enough to purge the junk and reorganize the entries. I lament the revert war that may follow anyone brave enough to attempt to the clean the mess up.

The 'search' feature of most Wikis is inadequate. Multiple words in a search phrase causes the search engine to lose its brain. If your phrase does not match the words of entries exactly, the search engine will not be able to find what you need. You often can have better luck with a Google search.

:: COMPLETE

Wiki zealots want documentation to be incomplete. They feel the best way to encourage participate is to post stubs. Stubs are woefully inadequate articles that are the Wiki equivalent of the "under construction" signs once popular on web pages. Remember those? Stubs are just as pointless.

:: CORRECT

Not too long ago Google announced a project to scan in books and make their digitized contents searchable. Why not? Books have been subjected to the scrutiny of an editorial review. The author's name is prominently displayed on the book.

Software developers have their superstars such as Alan Cox and Linus Torvalds. Can you name a technical documentation author whose work is as respected? Technical documentation Wikis do not reward either editorial scrunity or correctness. In fact who wants their name associated with anything that can be changed so easily to be incorrect.

:: CURRENT

A neglected Wiki is not a good source of current documentation. In fact technical documentation in general usually trails the release of project software. I challenge open source developers to make technical documentation a part of a 'release'. In other words a software project is not ready for release until its technical documentation is updated. I am frustrated by outdated documentation in projects like Gnome and Cloudscape.

:: WHAT TO DO

Open source projects must find a documentation maintainer. That person is a developer -- a documentation developer -- who is just as important as any developer actively working on source code. Consider her part of your team. Give her CVS privileges. Answer her questions quickly and in a friendly manner. Give her credit in your project documentation and on your project web site.

A documentation maintainer's job is to handle document submissions. He ensures that your documentation is clear, complete, correct, current, and consistent. Also, users may find a bug but will complain that the manual is wrong. If he cannot explain a feature, it may be a usability problem with your interface.

Wikis suck for technical documentation. But with the right attitude and a serious commitment open source projects can have decent technical documentation.

The Joy of bash

I have come to realize the complete joy it is to work with the bash shell. When forced to work in Unix in some other shell -- lets say C shell -- I quickly discover all of the features to which I have grown accustomed. Features such as file completion, job control and command history make a developer's life so much easier.

Improving Performance of Web Apps

To the improve the performance of Web applications I have five ideas that will help.

1) Determine your metric. In order to improve performance you have to be able to measure your changes. Pick your metric, or unit of measure, whether it is packet throughput, perceived response time or number of visits by cannibal pygmies.

2) Synchronize the clocks. This may seem obvious. But it is often overlooked. If the web server, proxy server, database server and client PCs have the same time, it is easier to establish a timeline of events. Spikes of activity in a timeline can help identify performance hot spots. Your task will be complicated if you need to compensate for late clocks. Pity that, White Rabbit!

3) Log it. Most web servers have log files. Write your application to log information, too. Log files with timestamps not only aide with debugging, but help measure performance.

4) Establish a baseline. Run an unmodified version of your application. Take a measurement. This is the baseline you can use for future comparisons. Scientists call this a control experiment.

5) Change one item at a time. If you do not limit your changes to a single item and your changes actually hurt performance, it is difficult to determine which item is the problem. Ambitious mega-patches can cost you hours of changes and re-tests.

The topic of improving software performance has and will continue to fill volumes of books. I hope these ideas will help you as you tackle your performance challenge.

Adventures with automake and autoconf

I sorted through GNU's automake and autoconf utilities. They are used to automate the installation and compiling of source code distributions. It is sparsely documented. But I got it to work. Now lets see if I can figure out how to add Windows portability and support for static libraries.

Use the Profiler

I know somebody is reading this because I received the most cryptic email yesterday. *shrug* If you send me questions, please be more specific than "show me how to program".

CODING TIP: Do Not Fear the Profiler. So now that you have written your program, you would like to optimize it to run better. A profiler tool helps identify the areas in which you spend the most time and of which you call most often. These areas are good candidates for optimization. As an aside I would love to see debuggers and profiling tools for the next generation of in-game scripting languages.

Profiling tools work by doing two things. First of all code is automatically added by the tool to the prologue of each function. When the calling program enters a function, the function name and program time are recorded in a file. Secondly, a profiler has a clock-driven information gatherer. At regular intervals the profiler examines the location of the program instruction pointer and records the function in which it is located to a file. This data is then analysed to produce a call graph and do statistical analysis.

Armed with this analysis you can target those functions where optimization will give you the best payoff. I will mention optimization techniques in future plan updates. For a good discussion of graphic code optimization check out M. Abrash's Black Book of Graphics Programming.

Unreal Tournament on Linux

Last night I compiled and ran Unreal Tournament in Linux on my TNT2. I have to say I was not impressed. I have to agree with whoever at Epic said, "[Linux UT] does not rock." My Linux game session was stripped of its windows header and a stuck at the absolute upper left hand corner of the screen. Whenever I was shot in the game, my screen turned black for a few seconds. Also, the intro fly-by showed mostly blackness until about five seconds into it. I think there might be issues with texture management. Alas, I already have too much on my plate to consider fixing it. *sweats*

Our quota issue was worked out quickly. So far I am pleased with the service we have received from dreamhost.com.

Flu? We are experiencing an outbreak of the flu here. My mother called me yesterday to see if I had picked it up. Fortunately I have not yet. But I am not out of the woods, so to speak. Flu season lasts until March. *crosses fingers*

CODING TIP: Write debug code. Experienced developers know what I mean by this one. It is a fairly common mistake for inexperienced software hackers to produce code that does not have debugging statements. Retrofitting debugging code can be a chore. You can save time and suffering by writing error handling into code as you develop your software.

Exporting Models Step-by-Step

I wrote a tutorial, crushtut.zip (250 kb), showing step-by-step the process of exporting a model from Crusher and importing it into Unreal.

Blitz asks: Unreal demands that the dimensions of skin textures be equal to a power of two. If anyone knows a good way of addressing this problem, please send me email at blitz (at) gazpacho (dot) .net.