MJ Ray wrote:
Version control command lines suck. If possible, either put the common commands into a Makefile (I've usually got "make download" to update to the latest version and "make check" to run git status, cvs status or whatever) or use a plugin for your editor (Emacs VC-mode seems pretty good to me).
That sounds like a good idea (although for someone like me who doesn't normally play with my own makefiles a bash script would do too).
Do you need to use version control at first?
In this case that's the only mechanism by which the source is available. I'm sure the author would have emailed me a .zip/.tar.gz but I'd rather I learnt SVN.
They're no dummies books, not free-software-specific but http://www.robson.org/gary/writing/becomeahacker.html and http://www.catb.org/~esr/faqs/hacker-howto.html may help.
I'll take a look, thanks.
Beware bad advice, though. I ranted about this recently in http://mjr.towers.org.uk/blog/2006/software#bewarewebadvice and if I had a fiver for every time I saw a web app install guide that instructs users to chmod 777 (a+rwx) a directory (a bad idea 9 times out of 10), I'd be buying all the beer at ALUGs.
Yes, this is common even in the INSTALL instructions supplied with a web application (which I obviously ignore!).
Learning programming well is a good idea. I think it helps if you have at least understood a bit more than 'Hello world' with at least one from each of these lists:
- Mostly imperative: C, Perl, PHP, BASIC, ...
Well my C is rusty but I've written some fairly big C projects in the past. I use PHP daily, Pascal frequently, Perl I know far too little about. Did quite a bit of Sinclair and BBC BASIC but had "outgrown" them by the time I did my computing 'O' level (I used Z80 assembler for that).
Which category would you put assembly language and similar into?
- Mostly object-orientated: objC, C++, Smalltalk, Ruby, ...
C++ I used a lot in the past (mostly TurboC++ under DOS), but none of the rest of them. I did get my grounding in OOP from Bjarne Stroustrup's C++ book (I got my C from K+R too) so I understand the idea fairly well, but it still seems like overkill for so many small projects, and so many large projects start as small projects.... I think OOP is ideal for stuff like interactions with a GUI, and there I obviously use it a lot (Object Pascal, C++, VB (if I really really have no choice)).
- Mostly functional: Scheme, CLisp, Elisp, Haskell, ...
Yay, a category I've avoided! Unless Prolog fits in there?
- Mostly unusual: Forth, PostScript, SQL, Tcl, ...
Forth I tried but never had an application for (although I did play around with a Forth-based games development package for the Spectrum). PostScript I've used in some devices completely unrelated to printers and never understood why it was there. SQL is routine for me, but I should push the database far harder than I do (I'm too used to mySQL!). Tcl I've not played with but I did use Expect for a bit which is Tcl based, I believe?
I think the most interesting point (and the only reason I went through the above) is that a good proportion of the above I learnt to some degree at school, when computers were a rarity. Now that they're everywhere, how many languages does a typical GSCE candidate get exposure to these days?
I think the biggest problem I have as I get older is remembering that nearly all software problems are either: a. easy; or b. easy after redesigning the software; but it's not always easy to tell which is which if the documentation isn't understandable to you, and redesigning is often more work than it's worth, especially if you face flamey opposition from the present designers!
Also, "if it ain't broke ...". Its too easy to introduce new bugs (or break old workarounds for bugs in external code) to make a redesign a good choice in a lot of cases. There are some very good exceptions, however. Anyone here done anything around the PHP-based osCommerce or any of its derivatives? That would be my shining example of an application that's grown with a lot of help from coders with little experience or training.