Cobain Backup: Example of How to Exclude Directories Using Masks

Cobain Backup is a very useful file backup tool. I have been using it for years without any problems. In general it's easy to use. However, I find its mask syntax for excluding directories and all contents in those directories a little confusing. Here's some help.

Exclude masks (or include masks):

• *\*svn\*\* - Exclude all subdirectories and files in them below any directory with a suffix of svn
  
• *\*svn\* - Exclude any files in directories with svn as a suffix
• *\*svn - Exclude empty directories with svn as its suffix
  
• Note that slash direction is important

To exclude .svn directories and all files in them:

• If empty directory pruning is enabled, two masks are required: *\*svn\*\* and *\*svn\*
• Otherwise three masks are required: *\*svn\*\* and *\*svn\* and *\*svn

Software Engineering Dead Tidbit

There has been conflicting conclusions ("take-aways" if you like) from Tom DeMaroc's article Software Engineering: An Idea Whose Time Has Come and Gone? [1]. As an example, see Jeff Atwood's blog Software Engineering: Dead? and the many comments at the end. I won't re-hash any of what was said there. But I will says this: regardless of whether SE is dead or not, we must continue to strive for the professionalism found in other engineering fields. This includes establishing best engineering practices, forming professional organizations, defining our responsibilities to the public, defining paths of entry, defining codes of ethics and enforcing them, requiring certification and/or licensing, and more.

That aside, my own tidbit from this article is the project management advice captured in these quotes:

Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much.

and

So, how do you manage a project without controlling it? Well, you manage the people and control the time and money.You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

[1] Tom DeMarco, Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009.

Top 25 Most Dangerous Programming Errors

The MITRE Corporation hosts an excellent document, entitled 2009 CWE/SANS Top 25 Most Dangerous Programming Errors, of what they, in collaboration with other organizations in the US and Europe (e.g. SANS Institute, and sponsored by National Cyber Security Division of the U.S. Department of Homeland Security), consider to be the top most dangerous programming errors.

Here's snapshot of its contents:

• Improper Input Validation
• Improper Encoding or Escaping of Output
• Failure to Preserve SQL Query Structure ('SQL Injection')
• Failure to Preserve Web Page Structure ('Cross-site Scripting')
• Failure to Preserve OS Command Structure ('OS Command Injection')
• Cleartext Transmission of Sensitive Information
• Cross-Site Request Forgery (CSRF)
• Race Condition
• Error Message Information Leak
• Failure to Constrain Operations within the Bounds of a Memory Buffer
• External Control of Critical State Data
• External Control of File Name or Path
• Untrusted Search Path
• Failure to Control Generation of Code ('Code Injection')
• Download of Code Without Integrity Check
• Improper Resource Shutdown or Release
• Improper Initialization
• Incorrect Calculation
• Improper Access Control (Authorization)
• Use of a Broken or Risky Cryptographic Algorithm
• Hard-Coded Password
• Incorrect Permission Assignment for Critical Resource
• Use of Insufficiently Random Values
• Execution with Unnecessary Privileges
• Client-Side Enforcement of Server-Side Security

The Manifesto for Software Craftsmanship

I came across the following well intentioned manifesto the other day. Quote:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

The above is quoted from The Manifesto for Software Craftsmanship.  Dr. Dobb's Agile Update 03/09 describes the above in more detail, and also the Agile Manifesto, from which it is derived.

The manifesto is a concise set of ideals all practicing professional software developers should follow. I also suggest adhering to the IEEE-CS and ACM endorsed Software Engineering Code of Ethics and Professional Practice (also found on the online ethics site, as a PDF, and at the ACM site), perhaps even more so, given the status of these organizations. The short form (i.e. preamble) is:

Software Engineering Code of Ethics and Professional Practice

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices (version 5.2)