I have concluded that I really ought to learn some Perl. In my experience, while reading the fine manual is a good start, having some sort of project in a new language is the way to really cement my learning.
I have also been thinking for a while that it might be nice to have some record of beers I have drunk. Partly so I can avoid the real stinkers, and partly so that when faced with a beer festival list, I can try and pick new beers. And also because I'm a bit of a sad geek.
Things to note about a beer would be: name, brewery, abv, rating (I am persuaded by Ben that /5 is the way to go here, rather than the /10 I've used in the past), comment, and maybe date and occasion of tasting and country of origin? I guess you might want the opportunity to add repeat tastings in the event of changing one's mind substantially.
Obvious features would be: interactive or bulk import, various search and sort routines for output (cli and maybe web-based too?), and the ability to feed in a beer list (from e.g. a festival) and get back new beers, and perhaps beers I've liked a lot previously.
Less obvious features would be: tweeting new beers as they are added to the system, links to Open Beer DB, beermad, Cyclops, etc., export in odd formats...?
I don't think there's much of great difficulty in implementation - some sort of SQLish storage should get most of the searching and sorting pretty much for free, and the rest is just some text processing (with a bit of thought about reliable updates, future spec changes and the like). What have I missed?
I'm sure this is a wheel that has been invented before, but maybe someone else will want to use it :)
And finally, now would be a good time to pass on any pearls of wisdom that you wish someone had imparted to you when you started to write Perl ;-)
I have also been thinking for a while that it might be nice to have some record of beers I have drunk. Partly so I can avoid the real stinkers, and partly so that when faced with a beer festival list, I can try and pick new beers. And also because I'm a bit of a sad geek.
Things to note about a beer would be: name, brewery, abv, rating (I am persuaded by Ben that /5 is the way to go here, rather than the /10 I've used in the past), comment, and maybe date and occasion of tasting and country of origin? I guess you might want the opportunity to add repeat tastings in the event of changing one's mind substantially.
Obvious features would be: interactive or bulk import, various search and sort routines for output (cli and maybe web-based too?), and the ability to feed in a beer list (from e.g. a festival) and get back new beers, and perhaps beers I've liked a lot previously.
Less obvious features would be: tweeting new beers as they are added to the system, links to Open Beer DB, beermad, Cyclops, etc., export in odd formats...?
I don't think there's much of great difficulty in implementation - some sort of SQLish storage should get most of the searching and sorting pretty much for free, and the rest is just some text processing (with a bit of thought about reliable updates, future spec changes and the like). What have I missed?
I'm sure this is a wheel that has been invented before, but maybe someone else will want to use it :)
And finally, now would be a good time to pass on any pearls of wisdom that you wish someone had imparted to you when you started to write Perl ;-)
(no subject)
I learned from the Camel Book. The Perl I subsequently produced was well received by experts who viewed it, so I must have been doing something right as a result.
Other bits of advice: it sounds like your motivating problem is actually database schema specification more than coding; there's famously more than one way to do it, but choose carefully because most involve polymorphing into a millipede then running off several clips from an automatic weapon without bothering to take aim.
(no subject)
(no subject)
(no subject)
(no subject)
When they say "there's more than one way to do it", they mean there's no right way to do it.
Get your head around refs sooner rather than later.
{ is not the same as ( is not the same as [ - if using one does something random, try the other; similarly with $ % and @. Being Perl, you won't always get an error for using the wrong one, just unexpected behaviour.
Just dump all your data into a bunch of hashes, it's easier.
$myData is not the same as $mydata; however both will happily work.
Nearly everything useful is in a CPAN library. CPAN won't be available in the next place you want to run your code. If it is, then chasing down all the package dependencies will be a major headache.
Date/time handling is terrible in the base language. (See above re CPAN).
Despite all that, it's sometimes the easiest option to use Perl.
(no subject)
use strict; - means you can't implicitly declare variables which traps a lot of typos and scope problems. I never bothered with the -w flag which always seemed to me to generate too many warnings to which the response was "yes, I know I'm doing that".
I like Nigel Chapman's "Perl: The Programmer's Companion", which assumes you know how to program already and just need to get up to speed with a new language (but also deals with some of the advanced features that "get going quickly" books tend to skip over, if I remember correctly). Seems to be out of print, but there are reasonably-priced new and second hand copies on Amazon marketplace.
(no subject)
People often make the mistake, when moving from Perl to Python, of trying to use regular expressions for all string handling. It's a mistake because regular expressions are an integral part of the Perl language, whereas in Python they're an extension, where they should only be used when they're the right tool. Going the other way, precisely the same is true about object orientation.