I would have agreed with all the flamebait posts, except that the Plex Media Center team, which makes an otherwise super-user-friendly front end and back end for managing their media center, requires the use of a CLI for even basic operations like updating the library.
From the rm manpages:
-i Request confirmation before attempting to remove each file,
regardless of the file's permissions, or whether or not the
standard input device is a terminal. The -i option overrides
any previous -f options.
Or just the simple case of "cp a b c/", only you eagerly hit enter before "c/" so you blow away b with no checks.
from the mv manpages:
-i Cause mv to write a prompt to standard error before moving a file
that would overwrite an existing file. If the response from the
standard input begins with the character `y' or `Y', the move is
attempted. (The -i option overrides any previous -f or -n
options.)
The key to estimating software development time is to use historical metrics along with quantitative analysis. You don't want to be in a situation where you're just pulling numbers out of nowhere.
Define your problem and break it up into enough high level and low level requirements such that the entire software solution could be written by somone with no knowledge of the program using only the softare requirements. (This will vary depending on the size and scope of the software solution)
Using this data, you should be able to derive the size of the application in terms of SLOC (software lines of code), number of bugs that you'll likely found, and how long it will take to develop in terms of man hours/labor months/whatever using a multiplyer derived from past metrics. (ex: each Requirement = 25 SLOC, 1 SLOC = 1man hour, for every 100 SLOC there will be 1 bug, and it takes 8 man hours to fix a bug. You can also make allowances for particularly difficult learning curves, drop in productivity due to OT, etc, but this should give you a ball park figure.
If this is your first time and no historical data, there are plenty of software metrics available online (or if you work at a company, they are likely available there) for predicing SLOC, bugs, labor months, etc.
The more you use this process, the better your historical data will get and the more likely you are to have better predictions. They key however, is writing good requirements up front and keeping track of all time spent along the way.
I remember back when I was 10 or so in the early/mid 90s I helped my dad set up an appletalk localtalk network throughout my whole house. It was just crappy speaker wire on a bus typology style network and it was slow as anything, but it allowed us to move files around and do all that other "network" stuff (which back in the day wasn't all that much). I thought this article was interesting because at one point I actually did write a series of hypercard stacks that I called the "internet". I would run one on our "server" which was actually just an old mac classic and a different stack on each of the other computers in our house. The stacks would link to the cards in the stack on the "server" and it allowed me to set up a very simple internal email system. I think I even rigged something up to use hypercard as an instant messenger at one point. The idea came after my cat fell out of the second story window because me and my sister used to send messages to eachother's rooms using a pice of yarn and a sticky note. (The cat slept in the window and we didn't secure the screen afterwards)
Looking back, the whole implementation was pretty silly but I definitely know first hand that hypercard could have taken off in a different direction. As a 10 year old, I stretched the networking capabilities of hypercard but if someone had caught on to those earlier hypercard may have been synonymous with webpages and hypercard with javascript.
Slashdot Mirror
I would have agreed with all the flamebait posts, except that the Plex Media Center team, which makes an otherwise super-user-friendly front end and back end for managing their media center, requires the use of a CLI for even basic operations like updating the library.
You shouldn't have to use the command line to use plex, especially for things like updating the library. Each Plex install has a full GUI administrative web interface hosted at http://localhost:32400/manage/index.html (replacing localhost with the IP of the machine). The little refresh icon works rather nicely for forcing an update of the library. You can read all about the options here: http://wiki.plexapp.com/index.php/PlexNine_PMS_MediaManager#Manually_Refreshing_Sections
sudo rm -Rf ~/bin
is one keystroke from
sudo rm -Rf ~ /bin
From the rm manpages: -i Request confirmation before attempting to remove each file, regardless of the file's permissions, or whether or not the standard input device is a terminal. The -i option overrides any previous -f options.
Or just the simple case of "cp a b c/", only you eagerly hit enter before "c/" so you blow away b with no checks.
from the mv manpages: -i Cause mv to write a prompt to standard error before moving a file that would overwrite an existing file. If the response from the standard input begins with the character `y' or `Y', the move is attempted. (The -i option overrides any previous -f or -n options.)
alias rm='rm -i'
alias mv='mv -i'
Problem Solved
The key to estimating software development time is to use historical metrics along with quantitative analysis. You don't want to be in a situation where you're just pulling numbers out of nowhere.
Define your problem and break it up into enough high level and low level requirements such that the entire software solution could be written by somone with no knowledge of the program using only the softare requirements. (This will vary depending on the size and scope of the software solution)
Using this data, you should be able to derive the size of the application in terms of SLOC (software lines of code), number of bugs that you'll likely found, and how long it will take to develop in terms of man hours/labor months/whatever using a multiplyer derived from past metrics. (ex: each Requirement = 25 SLOC, 1 SLOC = 1man hour, for every 100 SLOC there will be 1 bug, and it takes 8 man hours to fix a bug. You can also make allowances for particularly difficult learning curves, drop in productivity due to OT, etc, but this should give you a ball park figure.
If this is your first time and no historical data, there are plenty of software metrics available online (or if you work at a company, they are likely available there) for predicing SLOC, bugs, labor months, etc.
The more you use this process, the better your historical data will get and the more likely you are to have better predictions. They key however, is writing good requirements up front and keeping track of all time spent along the way.
I remember back when I was 10 or so in the early/mid 90s I helped my dad set up an appletalk localtalk network throughout my whole house. It was just crappy speaker wire on a bus typology style network and it was slow as anything, but it allowed us to move files around and do all that other "network" stuff (which back in the day wasn't all that much). I thought this article was interesting because at one point I actually did write a series of hypercard stacks that I called the "internet". I would run one on our "server" which was actually just an old mac classic and a different stack on each of the other computers in our house. The stacks would link to the cards in the stack on the "server" and it allowed me to set up a very simple internal email system. I think I even rigged something up to use hypercard as an instant messenger at one point. The idea came after my cat fell out of the second story window because me and my sister used to send messages to eachother's rooms using a pice of yarn and a sticky note. (The cat slept in the window and we didn't secure the screen afterwards) Looking back, the whole implementation was pretty silly but I definitely know first hand that hypercard could have taken off in a different direction. As a 10 year old, I stretched the networking capabilities of hypercard but if someone had caught on to those earlier hypercard may have been synonymous with webpages and hypercard with javascript.