Paradigmatic Software Development: Week 1

I started my first UMass Dartmouth class last week, it’s called “Paradigmatic Software Development”. You can read all about the syllabus and course objectives here if you’re so inclined. Following are my notes from the first reading assignment (Chapter 1 of Object-Oriented and Classical Software Engineering):

· The book starts off with a story about a man who received a bill for $0 and after receiving it multiple times, he sends in a check for $0, which then proceeds to crash his bank account. Funnier still is that this story appears to be an urban legend. I’m sure the bigger point is that errors like the one mentioned are all too common, hence this course. In case the author ever reads this, there is a much better list of famous bugs on wikipedia; see also Off-by-one error, fencepost error.

· Definition: software engineering is a discipline whose aim is the production of fault free software, delivered on time and within budget, that satisfies the clients need. Additionally the software must be easy to modify when the users needs change.

· There are 5 aspects of software engineering: historical (a very low percentage of software products have been completed sucessfully), economic (tech ‘a’ is 10% better than tech ‘b’ so if we switch to using ‘b’ we should be able to complete project ‘x’ in 10% less time), maintenance (requirements, analysis, design, implementation, post delivery maintenance, retirement)

· Real life example of the life cycle model mentioned above: at Mindseye we a) met with the client to get the project [requirements], b) produced a features and functions document which was agreed upon before work started [analyis], c) produced the black lines / specifications [design], d) implemented the site [implementation], e) entered into support contract [post delivery maintenance] or existing resources took over the project. The one thing we didn’t do was design of the software itself, our design / specification document was made up mostly of an object model and black lines (similar to what most people would call information architecture).

· Maintenance often happens before the project is released ( because of changes to the design etc…). Only good software actually makes it to post delivery maintenance phase because bad software is thrown away well before that time (or is never implemented)

· The book at this points presents a trivial example of how encapsulation is “a good thing” by showing how it would be much better to use this:

public static final float salestax = 6.0;

than to insert 6.0 in multiple places in your code (obviously). The funny thing is that by using a float to represent sales tax, he unwittingly introduced a bug into his code.

· Average cost percentages per phase (requirements, analysis, design, etc..) has hardly changed over the 20 or so years (~20% to requirements, ~20% to design, ~35% to coding / unit testing, ~25% to integration) but much more interesting is the fact that more than 75% of the total cost of a project is related to post delivery, so anything that can reduce the amount of time and money that you spend in that phase should probably be closely looked at.

· requirements / design / analysis:
  — fixing costs more when you find it later (if you’re using the classical software development model)
  — techniques that help you complete the requirements / analysis / design phase better will help save quite a bit of money and time up front

· planning phase: Not included because planning is usually carried out all through the life cycle; mostly during the beginning of the project and the software project management plan

· testing: needs to be happening all the time althoguh the book seems to think more of a QA group than of unit / automated testing

· documentation phase? No because the documentation should be kept up at all times so there ahould never be a time when it is out of date

· Object Oriented
  — strengths of OO: post delivery maintenance is easier because of information hiding, OO makes more sense when modeling (which should lead to higher quality software), encapsulation (OO is sometimes referred to as responsibility-driven design or design by contract), classical paradigm results in a set of modules that is conceptually a single uit, OO results in smaller largely independent units ,OO promotes reuse
  — diff between OO and classical:
    — OO has workflows, classical has phases
    — OO starts integrating classes almost right away while classical doesn’t integrate modules until the design phase.

ProFTPD and jailing users

I moved all my sites to a couple months back on Joe’s recommendation and I’m hosting sites for a couple buddies on it right now. One of the problems with opening your server up to your buddies is that, trustworthy as they may be, you don’t want them mucking around with the system by CD’ing up to places they shouldn’t be hanging out. The guys at VPS Center have provided a nice web-based app for the creation of FTP users, but you can’t lock down the users to a specific directory via the web. I did some research today and found out that you can edit the ProFTPD configuration file so that users are “jailed” (a ProFTPD term, not mine) into their websites and can’t muck around outside their own sandbox.

The configuration file lives on my system at /etc/proftpd.conf, open that puppy up and add:

DefaultRoot /usr/hosts/ groupname

where /usr/hosts/ is the directory containing the site that you want to lock down and groupname is the name of the group (usually the same as the username) that you want to restrict. Restart the server (/etc/rc.d/init.d/proftpd restart) and the next time the user in question logs in, they’ll be automatically redirected to the ‘jailed’ directory and they won’t be be able to browse directories above the one you’ve established as the base.

On a related note, if it seems like your FTP connections take forever to establish, add:

UseReverseDNS off
IdentLookups off

to the ProFTPD configuration file as well (restart required). You’ll see a dramatic decrease in the amount of time it takes to make an FTP connection.

dropcash and Java

If you’ve ever needed to raise a couple bucks for a project, a birthday or a fundraiser, you should check out dropcash (by Andre Torres). dropcash lets you set up a personal fundraising campaign using paypal and TypeKey. The campaign can be dropped into your site using a simple JavaScript include just like Flickr or Google Adsense, but you can programatically access the status of your campaign using the XML feed. There are a couple different implementations of the API (COM, MovableType, TextPattern and ColdFusion, more…), but no Java so I wrapped up a Java version and a JSP version. JSP is simpler of the two:
<%@ taglib prefix="c" uri="" %>
<%@ taglib prefix="x" uri="" %>
<c:import var="dropcash" url=""/>
<x:parse var="dropcashxml" doc="${dropcash}"/>
campaignid: <x:out select="$dropcashxml//@id" />
typekey_user: <x:out select="$dropcashxml//typekey_user"/>
receiver: <x:out select="$dropcashxml//receiver"/>
title: <x:out select="$dropcashxml//title"/>
goal: <x:out select="$dropcashxml//goal"/>
total_collected: <x:out select="$dropcashxml//total_collected"/>
description: <x:out select="$dropcashxml//description"/>
percentage: <x:out select="$dropcashxml//percentage"/>

Java less straightforward:
URL url = new URL("");
HttpURLConnection uc = (HttpURLConnection)url.openConnection();
InputStream is = uc.getInputStream();
DocumentBuilderFactory docfactory = DocumentBuilderFactory.newInstance();
InputStream inputXML = url.openStream();
DocumentBuilder docbuilder = docfactory.newDocumentBuilder();
Document document = docbuilder.parse(inputXML);
Element campaign = document.getDocumentElement();
System.out.println("campaignid = " + campaign.getAttribute("id"));
NodeList nodes = campaign.getChildNodes();
for (int i=0; i
Download the full JSP and Java source code.