Category: Programming

Posted on

The software patent monster impedes innovation

Bruce Perens tells us that patents impede innovation his article, The Monster Arrives: Software Patent Lawsuits Against Open Source Developers:

Patents were created as a means to get inventors to disclose their inventions, rather than keep them secret. The disclosure of an invention was supposed to allow others to more easily build on that invention, thus creating more inventions. But the patent system has evolved into something useless for the purpose of disclosure, and engineers are now instructed to avoid looking at other companies’ patents because if the victim of a patent lawsuit can be shown to have known of a patent, the award to the patent holder is tripled. There have been no reliable studies that show software patenting to have encouraged innovation, and there is much evidence that they actually impede it.

Posted on

Mongrel web server

Here’s an interview with Zed Shaw, the author of the Mongrel web server — a web server for the Ruby programming language that is good for use in combination with Ruby on Rails and other Ruby-based web-app frameworks. It’s interesting in that it’s fast, secure, cross-platform, and it’s not a heavyweight solution (compared to Apache). Why is it more secure than Apache at the HTTP protocol level? Mongrel utilizes the Ragel State Machine Compiler
 to generate the protocol parser, “and that is very strict and seems to block a huge number of attack attempts simply because it is so exacting.”

Posted on

Why migrate a C++ project to Visual Studio 2005?

New and better tools are usually a good thing. So it is when moving from Visual Studio 2003 to the 2005 edition. Advantages of moving C++ development to Visual Studio 2005, Team Edition Developer include…

  1. Global/shared property sheets allow developers to change a setting in one place and have it apply to all projects. This makes it vastly easier to add new include paths and libraries, etc.
  2. New /analyze static analysis option goes the extra mile in identifying bugs such as buffer overflow, memory leaks, failure to check return types, etc. This feature is only available in VS 2005 Team Edition Developer.
  3. Better debugger supports tracepoints and displays STL containers in a human-readable format! See http://blogs.msdn.com/andypennell/archive/2004/06/29/169002.aspx for more information.
  4. Improved remote debugging.
  5. More standards-compliant C++ compiler. See http://msdn2.microsoft.com/en-us/library/ms177253(vs.80).aspx
  6. Built-in profiler.
  7. Const-correctness checks in functions such as strchr, strstr, etc. help identify and prevent bugs.
  8. Organize sub-projects into solution folders.
  9. Can substitute more secure versions of strcpy, strcat, etc. automatically under certain conditions if we define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES. There’s also _CRT_SECURE_NO_DEPRECATE.
  10. More and better warnings.
  11. Dependency checking is faster. This means, for example, that cleaning a solution is much faster than with VS 2003.
  12. Stack smashing protection (the /GS flag) is more robust.
  13. printf family of functions support the C99 Standard of “%ll” and “%ull” for 64 bit integers in addition to the non-portable, Microsoft-only VS2003 “%I64d” syntax.

Costs of migrating to VS 2005:

  1. Compiled code size is slightly larger.
  2. The IDE requires more memory to run.
  3. Third party libraries and libc
  4. Template code may need to be modified.

Additional resources:

Migration Strategy

It’s usually not a good idea to migrate a code base immediately, although it could be good way to anger management. Here’s what I recommend:

  1. Copy your top-level solution mysolution.sln to mysolution.vs2005.sln.
  2. Copy all sub-projects *.vcproj to *.vs2005.vcproj.
  3. Edit mysolution.vs2005.sln and chang all .vcproj references to .vs2005.vcproj.
  4. Open mysolution.vs2005.sln in VS 2005. It will migrate the project automatically.
  5. Add the new solution and project files to your source control system (Subversion, Perforce, CVS). This way, you won’t affect the day-to-day development operations of the rest of your team. You could write a script to automate the above steps so that it is easier to keep in-sync with the additions, renames and removals of includes, source, and so on from the VS 2003 solution.
  6. Compile and fix errors gradually.
    • You may need a new version of Microsoft’s WTL, which is backwards compatible with VS 2003.
    • You may need to fix template syntax issues.
    • Fix const-correctness issues.

Eventually your team will become comfortable with VS 2005, and you can switch.

Posted on

Best essays on software

Are you interested in reading quality essays on subjects related to software development? If so, then treat yourself to Neil Kandalgaonkar’s Links to essays in the book Best Software Writing I, or buy the hardcopy.

In the interest of letting people get to the links quickly, I’m copying-and-pasting Neil Kandalgaonkar’s links:


Joel Spolsky – Introduction

Posted on

Refactoring Rules

Tried-and-true refactoring rules:

  1. Find the smallest change that could possibly work, and check it in. “If I make this change, it will change nothing else.”
  2. Revert early, and revert often. If you lose a half-day of work because the refactoring change is too large, that’s okay. Better to start over than to cost the rest of the team precious time struggling with a broken build.
  3. Do not write new code while refactoring.
  4. Always use cut-and-paste, never copy-and-paste.
  5. Just because the unit tests pass, doesn’t mean that the product still works after your refactor. You may need to add new unit tests before you refactor. And you may need to do some acceptance-testing for things that aren’t unit-testable.

General Advice:

  1. Don’t checkin changes to the version control system just before you go home. Wait for the next day.

Types of Refactoring:

  1. Refer to Martin Fowler’s “Refactoring” book
  2. Refer to Fowler’s website: http://www.refactoring.com/ and his catalog of refactorings
Posted on

Is open source software sustainable?

Recently, a genuinely concerned coworker expressed concern that “not paying for software [may] ultimately kill the industry” because it encourages people expect something for nothing.

For those who would like this and other common concerns about open software answered, I recommend reading Open Source-onomics. Here’s a list of concerns it addresses:

  • “Open Source is not economically viable”
  • “Not paying for software will ultimately kill the industry”
  • “Why will programmers continue to contribute code if they can’t make money from it?”
  • “Even Open Source development involves effort, so there has to be payment for that effort”
  • “Are Open Source programmers writing themselves out of their jobs?”
  • “But free isn’t natural. There’s no such thing as a free lunch.”
  • “Is software a commodity?”
  • “Who will invest in software development if it doesn’t yield a return?”
  • “Open Source may have a niche, but proprietary commercial products will continue to rule”
  • “Customers will never trust something that is free”
  • “Open Source may release value, but it doesn’t create value”

For those who would like even more detailed reading, I recommend David Wheeler’s “Why Open Source Software? Look at the numbers!“

Posted on

Refactoring C++ with Ref++

IntelliJ IDEA has world-class refactoring support for Java. I’ve never seen a good tool for refactoring C++ code, until now: Ref++ for Visual Studio 2003 and 2005. Admittedly, it isn’t nearly as good as the refactoring tools available for Java code, but it’s a start, and Ref++ saves time.