I'm heading into three straight days of intense requirements meetings, do I don't expect to offer any more updates until at least Thursday. Have a good few days ...
Alvin Alexander | Java, Scala, Unix, Perl, Mac OS X
A couple of best practices today. First, a brief discussion on how to estimate software development projects using Function Points. Second, a discussion on the impact of physical distance between users and developers in the software development process.
I used to be one of the three worst software development estimators in the world. Okay, I was probably *the* worst. I could not estimate the time or cost of a software development project to save my life. Then I learned about this thing called Function Points, and Function Point Analysis, and other common sense things, like the Law of Averages, and my estimating life is much, much better. I might even challenge someone to a contest one of these days.
In the software development industry, the physical distance between developers and users is an important, often-overlooked variable to the success of a project. I'm currently working on a project where my development team is several hundred yards away from our users, and we're also in another building. Because developers don't seem to like telephones, or perhaps don't like talking to other people that aren't developers, I contend that this 300 yards could easily be 30 miles.
Okay, it took me forever to find the OMG's formal UML Specification v1.5, so here's a direct link to the page it is on. I'm not sure why, but I started at www.omg.org (don't go to omg.org without the "www" prefix because that doesn't work), and they bounced me to www.uml.org, and they bounced me back to www.omg.org for the actual doc. Argh.
Here's a tip courtesy of Computer Shopper: Every once in a while I've found a need to print a directory listing on my Windows computer. It only happens once or twice a year, but there are definitely times when I go "Man, I wish I could print the contents of my C:\Projects directory", or something similar. I don't know why MS hasn't built this into Windows.
I haven't used the Unix/Linux
tee command in a million years, but needed it today. In honor of that occasion here's a quick tip on "how to use the tee command."
Today I ran into a need for my old friend the Linux
tee command. With the tee command you can read input from an input stream, and split the output stream in two directions, so it is both displayed on screen (stdout) and also re-direct it to a file. I needed to do this today when I wanted to monitor something that was running slow, and also keep an output log of the long-running process.
Here is a LaTeX example file where I'm experimenting with the LaTeX "ifthen" package (ifthen.sty).
These are simple examples, where I'm playing with the if/then decision making capability with the LaTeX "ifthen" package. These two examples are pretty easy, but make a nice introduction to the "ifthen" package.
Without any further ado, here are my LaTeX if/then examples:
I've created several new LaTeX tips in the last 12 hours and posted them in my LaTeX blog area. This includes tips/tutorials/examples on how to create your own commands; how to use the "html" package; and how to use the "versions" package.
LaTeX question: Can you show a simple example of creating your own LaTeX command?
Here is an example LaTeX file where I'm experimenting with various newcommand and renewcommand capabilities. The file actually contains six LaTeX examples, and in each step I add one more LaTeX feature that is a little harder than the previous step.
The LaTeX "
html" package (html.sty) can be very useful for the times that you want to conditionally controlling the output in LaTeX documents, but very specifically, when you want one set of output for normal Latex processing (LaTeX PDF output), and another set of output for LaTeX HTML processing.
Here's a very simple example of how you can use this LaTeX HTML package to conditionally control what is output by the LaTeX processor:
versions" package (versions.sty) can be very useful in conditionally controlling your output in LaTeX PDF and HTML documents.
LaTeX conditional output
Here's a very simple example of how you can use this package to conditionally control what is output by the LaTeX processor:
Here's a link to an "FTP applet" (named "U-Upload") a company is selling. The applet can serve as an FTP client for your customers. This may help solve a problem that we have with an existing client.
I also created a quick tip that shows how to create multine comments in LaTeX documents. I found out how to do that today, and it's extremely useful.
I often have a need to create LaTeX comments that span multiple lines. Of course you can create single line comments in LaTeX using the percent character like this:
% this is a comment
But I want to be able to create LaTeX comments that go on for multiple lines. Fortunately, if you know that you're supposed to include the
verbatim package, this is pretty easy.
LaTeX multiline comments example
The first step is to include the verbatim package, like this:
If you've never heard of the "Golden Ratio" and how it applies to user interface design, you may want to search it up at google.
Here's one link where the author refers to it as the "Golden section ratio (phi)". It doesn't get into the UI part, but has a nice history with references to Euclid, pyramids, and Fibonacci numbers.
Yawn ... nothing major so far today. I spent a long night last night working on a manuscript for something totally not related to computing, so I'm pumping in the coffee this morning.
Have you ever had one of those mind-blowing experiences where you are really, really struggling with a problem ... struggling for hours, days, or weeks, and then suddenly - bam! - you find exactly what you need? I had that experience this morning, and it was truly awesome.
Last week during a meeting a user at a customer site asked why it wasn't easy to "copy" behavior from one part of an application to another. My answer to this is so general that I thought I would include it here. Here's a link to an explanation of why some changes to application behavior aren't as easy as a user might think.
(From an email I sent to one of my clients regarding our software project.)
Last week we left the meeting with an open item to have [CUSTOMER_NAME] IT staff work w/ [DEVELOPER_NAME] to understand why some programming changes are easy, and some are not. More specifically, I think the question pertained to times when an application works one way in one part of the application, and then a user would like to see that same behavior in another part of the application. The question was something to the effect of "Why isn't this easy?"