Was going to email this list of vi cheat-sheets to a co-worker, but I'll post instead:
http://www.kcomputing.com/vi.html
http://cac.uvi.edu/miscfaq/vi-cheat.html
http://ase.tufts.edu/mechanical/compstudio/help/vihelp.html
(that list is from page 164 of my book.... :-)
Thursday, October 27, 2005
Sunday, October 23, 2005
PHP Comes to Eclipse
Martin Brown blogged about PHP coming to the Eclipse platform (back on Oct. 18th.) This interests me because I find that Eclipse currently is the best cross-platform IDE for Perl, a language I like very much. (See my article at perl.com, "Perl Needs Better Tools")
Wargaming - another way of modeling the universe
I found a reference to myself in Kevin Trainor's blog, Wombat Rampant. The posting is about the decline of paper-based combat simulation games. Back in the 1970's I used to design and play wargames, which to me, are part of my lifelong involvement with building things.
Saturday, October 22, 2005
Take Control of Permissions in Mac OS X
My long-time friend and colleague Brian Tanaka has written a new eBook "Take Control of Permissions in Mac OS X" that provides a bunch of help for the average Mac user in dealing with the often mysterious subject of "permissions" and "ownership" of files and folders in Mac OS X.
Permissions and ownership of files and folders are a tough subject.
Part of the reason, I think, is that there isn't a really good physical-world analogy - objects in the physical world don't have -rwxr-xr-x attached to them, so it's a pretty alien concept - in the physical world, if you can touch it you can write on it, now maybe you shouldn't write on it, because of laws, social custom, etc. but there are no attached permission settings, and no operating system to enforce permissions. Ownership is an easier concept for people to grasp, because of the extensive real-world analogs.
Brians' eBook is a good, searchable, handy guide to dealing with these issues, and it's only ten bucks. You do not need to know, or care about Unix to benefit from his guide, and even experienced users will find stuff they didn't know - for example what "Repair Permissions" and "Ignore Ownership" actually do.
If you want to really dive into learning the Unix layer of Mac OS X, and can handle a higher price-tag, and dealing with a paper book, then I recommend my book (shameless plug, I know) "Unix for Mac OS X Tiger", but to focus on just Permissions and Ownership, Brians' book is a fine place to start.
Permissions and ownership of files and folders are a tough subject.
Part of the reason, I think, is that there isn't a really good physical-world analogy - objects in the physical world don't have -rwxr-xr-x attached to them, so it's a pretty alien concept - in the physical world, if you can touch it you can write on it, now maybe you shouldn't write on it, because of laws, social custom, etc. but there are no attached permission settings, and no operating system to enforce permissions. Ownership is an easier concept for people to grasp, because of the extensive real-world analogs.
Brians' eBook is a good, searchable, handy guide to dealing with these issues, and it's only ten bucks. You do not need to know, or care about Unix to benefit from his guide, and even experienced users will find stuff they didn't know - for example what "Repair Permissions" and "Ignore Ownership" actually do.
If you want to really dive into learning the Unix layer of Mac OS X, and can handle a higher price-tag, and dealing with a paper book, then I recommend my book (shameless plug, I know) "Unix for Mac OS X Tiger", but to focus on just Permissions and Ownership, Brians' book is a fine place to start.
Wednesday, October 12, 2005
How to estimate memory usage for a large hash?
I had a conversation recently about how to estimate the size of storage for hash keys when processing a huge data set.
Let's say you are gonna process 100,000,000 name/value pairs and you want to estimate how much memory is needed to store the list of unique names - is there a current "best practice" for this?
Let's say you are gonna process 100,000,000 name/value pairs and you want to estimate how much memory is needed to store the list of unique names - is there a current "best practice" for this?
Problems with log files and daemontools
Daemontools is a software suite for Unix that makes it easy to run any program or script as a daemon.
I recently ran into an interesting problem with daemontools - none of the STDOUT output from my daemon was showing up in the log file.
It turns out that your daemon must use unbuffered STDOUT or it won't go into the log file. In my case the daemon is a Perl script so I added automatic flushing of output buffers to the script, and it works. That means I added this:
$| =1;
to the Perl script.
I recently ran into an interesting problem with daemontools - none of the STDOUT output from my daemon was showing up in the log file.
It turns out that your daemon must use unbuffered STDOUT or it won't go into the log file. In my case the daemon is a Perl script so I added automatic flushing of output buffers to the script, and it works. That means I added this:
$| =1;
to the Perl script.
Subscribe to:
Posts (Atom)