stevedoria.net

let's not and say we did

Archive for the 'Software Engineering' Category

Conveying Progress through Mockup Subchannels

October 15th, 2007 Posted in Software Engineering | Comments »

Kathy Sierra’s Don’t Make the Demo Look Done provides excellent advice for conveying the state of a project while presenting the project’s functionality. It also discusses advantages such as improved user feedback. With a very rough presentation, users will be comfortable providing inputs on significant system features rather than the particular fonts used in the […]

Code Refinement

October 11th, 2007 Posted in Personal Development, Software Engineering | Comments »

Everyday is an opportunity to learn something new. Today, I learned how to set the tab width for vi (set tabstop=2) while trying to format the picture for this blog entry, for example. Daily learning is a form of personal refinement. Accumulated knowledge allows people to do things better. If the lesson relates to development, […]

Shall, Should, and May

September 16th, 2007 Posted in Software Engineering | Comments »

The text of RFC2119, which describes the use of these phrases in system documentation, is presented here: Network Working Group Request for Comments: 2119 BCP: 14 Category: Best Current Practice S. Bradner Harvard University March 1997 — Status of this Memo — This document specifies an Internet Best Current Practices for the Internet Community, and […]

Secure Coding: Principles & Practices

August 28th, 2007 Posted in Security, Software Engineering | Comments »

I read Graff and van Wyk’s Secure Coding: Principles & Practices to completion, but not because each page was more enlightening than the previous. I realized that the same themes and adages were being repeated constantly after having read half the book. Because it was pretty easy to get midway through the book, I decided […]

On the Lack of Exceptions

August 9th, 2007 Posted in Software Engineering | Comments »

Lately, I’ve been helping develop a reasonably sized application, which detects errors at every operation. Checking the return value of every function call seems awkward when compared to code that is written in rather informal working environments. Writing code that checks each return value is frustrating when a feature that exists in another language is […]