Natural Order Development

Programming requires the use of a fixed width (monospaced or fixed-proportional font) screen font so that all characters occupy the same width when displayed on screen. This is because some languages (Python, Scala, Java, C, etc.) depend on indention to block code together or to align up rectangular columnar blocks for code clarity.

From on high a message came down at my place of work that meetings were not being dealt with well. The message included a complete description of "Meeting Etiquette" and a stern warning that we needed to "follow some protocols when it comes to business meetings."

So what to do? Well here are some things to ponder and suggestions from some respectable sources that offer the same advise I have for years (only better):

Software quality encompasses a number of factors such as number of defects, complexity, functional behavior coverage, and usability. The higher the quality of a solution the lower the total cost of ownership (TCO) as well as the higher the return on investment. As obvious as this idea is many developers fail to consider any of it while producing a solution. In the fast past world of software engineering most people involved get caught up in the idea that motion equals progress.

At my office we have this thing called the "Dude Protocol." When I first started working here I thought it was a neat idea to make people a little more security conscience. The procedure is that if any workstation, laptop, or terminal is left logged in but without someone sitting there using it everyone is allowed (in fact directly ordered) to pull up the email client and send an email message to the "Fun" email list with the subject of "Dude" and then to LOCK the terminal.

This is from a place I worked at. It is a really great idea so I have summarized it here in case some other place wishes to implement a similar procedure. The original work was done by a really great guy named Marc Wensauer (http://www.linkedin.com/in/marcwensauer).

Purpose

A mechanism to provide an indication to a user that he or she has left a system unattended with an unprotected, active user interface.

Many times a day I sit and wonder about why something is (or is not). (Sounds pretty Zen I know, however, it is still true.) Technology is evolving so fast as to seem out of control. Yet, there are still fundamental elements we should be following. One of these is usability.

Good URLs are a great thing. I am trying to make them come out here. In running around to find the right mix of code to make them nice I ran over this excellent article on "Best URLs". Since I agree with it entirely, and cannot think of anything to add to it just going to reference it and say "ditto". Also in the interest of vanishing Internet resources and articles I include the complete article here (with permission from Gary Love granted on 9/24/2010):

In developing project criteria/use cases/stories a certain point is reached where it is concluded that "enough" has been done and the results are "good" to begin work. Which is to say that the requirements are "good enough."

It is not unusual to wonder, after work begins, if the information really was good enough. It is worth re-evaluating the requirements once a little effort has been done. This helps to flush out missing details. A reasonable set of questions to ask are:

• Were any important variables missed in collecting the data used to produce the requirements?
  

Just had a reason to open up my code archives. Not a big deal, just checkout the older stuff from the Subversion archives and add some new Eclipse projects.

Lions, tigers and bears oh my. What the heck are all those warnings!?

Lets talk about exceptions for a moment. At the office a discussion came up that essentially was about if we should group our exception objects together into a single module/subsystem wide package or have them called out in the packages next to the code they were used by.

Personally I think packages specific to exceptions are bad ideas because it detaches them from the business objects they are supposed to be supporting. An exception should represent the possible result of a direct action on a domain object. I think they should be subsystem/object specific.

Honestly I am getting real tired of dealing with developers who seem to feel the need to rebel against any change in their thinking process. I have no problem taking classes, seeing something I haven't tried before and if I feel it might be helpful being willing to give it a solid try for a few cycles. And I fully admit it that I am an unabashed process freak.

Been dealing a lot of SCRUM items and it seems to me that a lot of teams keep missing the mark because of not clear "done criteria". For the record I think a minimum done criteria is:

• Code is checked-in into a central version control system
• A detailed code review (including comparison to any company and/or team coding standards) has been complete, any suggested changes implemented and final code has been checked-in
• Unit tests with demonstratable cover coverage of more 80% for non-integration / "out of container"

Best Practice #1 Do Input Validation

Input validation verifies or cleans up inputs to the application. Essentially trust no data from any source until it has been proven to be safe based on some established format verification process. Input validation is a critical part of a web service's reliability and security (or any software application for that matter). By failing to validate input data an application may do very unexpected things given a garbled (accidentally or intentionally) input leading to a security violation or a vulnerable state.

Input Validation:

Warning this is amazingly boring.



Web containers are things like Apache Tomcat, WebSphere, Java Systems Webserver, JBOSS, Weblogic, and lots more.



There are some common things:

• Web applications created by developers
  
  
• Security needs for a given web application are usually deployment-specific
  
  
• Deployers should be able to specify security settings without changing application code

Cryptography is effective only if it is used properly. It is way too easy to use very strong cryptography libraries very wrong. The most common problems with cryptography implementations are:

• Use of home grown algorithms (lets face it unless you have a PhD in mathematics and another in cryptography you should not write a cryptographic algorithm for a production system.);
  
  
• Cryptography depends on REALLY random seed data and the standard rand() calls are NOT random enough for strong enough cryptographic functions let alone strong cryptographic solutions;