From scottp at dd.com.au Mon Jul 3 19:18:22 2006 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 4 Jul 2006 12:18:22 +1000 Subject: [Melbourne-pm] Apache Cache Message-ID: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> Hey Dudes I need to cache some thumbnails in a mod perl Apache module. The way that most systems seem to do it on CPAN is to use a "." directory in the same location, or some other top root directory via configuration. However it occurs to me with Cache::Cache, and other cache systems - and things like Apache::Cache, and lots of cache abilities built into top level apache etc etc - that there might be a better way. Unfortunately Apache::Cache is a shared memory cache for memory between calls - which is not really much help for thumbnails (too much data). I could just do a directory cache, but then if someone wanted to move to Memcached (for example) that might make it harder. Anyone any experience in this? Ta dudes Scooter -- * - * http://www.osdc.com.au - Open Source Developers Conference * - * Scott Penrose Open source developer http://linux.dd.com.au/ scottp at dd.com.au Dismaimer: Open sauce usually ends up never coming out (of the bottle). Please do not send me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Microsoft is not the answer. It's the question. And the answer is no. From lists at holsman.net Mon Jul 3 19:34:50 2006 From: lists at holsman.net (Ian Holsman) Date: Tue, 4 Jul 2006 12:34:50 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> Message-ID: what about using memcached ? i'm guessing thumbnails are about 40-50k each.. you could just stick the things in memecache and let it cache a couple of thousand that way. http://www.danga.com/memcached/ I wouldn't use the CPAN module though, there are 2 others which are being used at the moment. there is a discussion about the Perl Client here: http:// lists.danga.com/pipermail/memcached/2006-June/ and http:// lists.danga.com/pipermail/memcached/2006-July/ regards ian On 04/07/2006, at 12:18 PM, Scott Penrose wrote: > Hey Dudes > > I need to cache some thumbnails in a mod perl Apache module. > > The way that most systems seem to do it on CPAN is to use a "." > directory in the same location, or some other top root directory via > configuration. > > However it occurs to me with Cache::Cache, and other cache systems - > and things like Apache::Cache, and lots of cache abilities built into > top level apache etc etc - that there might be a better way. > > Unfortunately Apache::Cache is a shared memory cache for memory > between calls - which is not really much help for thumbnails (too > much data). I could just do a directory cache, but then if someone > wanted to move to Memcached (for example) that might make it harder. > > Anyone any experience in this? > > Ta dudes > > Scooter > -- > * - * http://www.osdc.com.au - Open Source Developers Conference * > - * > Scott Penrose > Open source developer > http://linux.dd.com.au/ > scottp at dd.com.au > > Dismaimer: Open sauce usually ends up never coming out (of the > bottle). > > Please do not send me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > Microsoft is not the answer. It's the question. And the answer is no. > > > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm From jarich at perltraining.com.au Mon Jul 3 19:36:31 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Tue, 04 Jul 2006 12:36:31 +1000 Subject: [Melbourne-pm] Meeting next week: 12th July Message-ID: <44A9D42F.5090402@perltraining.com.au> G'day everyone, Don't forget that your OSDC paper proposals are due on Wednesday, the 12th July. The same day as this meeting. You and all of your friends, family and other interested people are invited to our meeting next week. Date: Wednesday 12th July Time: 6:30pm Location: (Usual place) Level 8, 14 Blackwood Street, North Melbourne Paul's talk will go for about 30 minutes, so this will give us plenty of time to spend at the pub later. Unless you'd like to give a talk. For those who've never joined us on a trip to the pub, it's a great time to socialise, talk more about the talk topics, network and generally have a good time. The food's pretty good too. Human Interfaces for Geeks -- by Paul Fenwick --------------------------------------------- As technical professionals we excel at understanding protocols, standards, file-formats, and APIs. Whenever there is a doubt as to the correct way to do things, one merely needs to read the fine manual or source code. Unfortunately the reference manual for humans was lost a long time ago, and the source code is poorly documented. We've been struggling with inter-human communication ever since. Paul Fenwick will present his findings at reverse-engineering the human communication protocol. If you have a talk topic you'd like to give - for this meeting or for one in the future - please send it through to the list. We're always interested in more talks. If you know someone who might be interested in this meeting's talks. In fact, try to bring someone else along anyway, the more the merrier! Your friends, family and work colleagues are all invited! Attendance is free. Next Meeting ============ The next Perl Monger meeting will (probably) be on Wednesday, the 9th August. OSDClub ======= OSDClub will (probably) be hosted by the Melbourne PHP User Group in August and will therefore be taking place on Thursday August 4th. For talk topics and other information please visit: http://www.osdc.com.au/osdclub/index.html -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From daniel at rimspace.net Mon Jul 3 19:39:42 2006 From: daniel at rimspace.net (Daniel Pittman) Date: Tue, 04 Jul 2006 12:39:42 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> (Scott Penrose's message of "Tue, 4 Jul 2006 12:18:22 +1000") References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> Message-ID: <87odw6ytxt.fsf@rimspace.net> Scott Penrose writes: > I need to cache some thumbnails in a mod perl Apache module. > > The way that most systems seem to do it on CPAN is to use a "." > directory in the same location, or some other top root directory via > configuration. > > However it occurs to me with Cache::Cache, and other cache systems - > and things like Apache::Cache, and lots of cache abilities built into > top level apache etc etc - that there might be a better way. > > Unfortunately Apache::Cache is a shared memory cache for memory > between calls - which is not really much help for thumbnails (too > much data). I could just do a directory cache, but then if someone > wanted to move to Memcached (for example) that might make it harder. Well, they could just use Cache::Memcached or Cache::Memcached::XS to replace the storage infrastructure under the unified cache module with a memcached backed store. :) Seriously, Cache::Cache seems like the best generic interface to storing the data available. It is good, generic, widely available and supports a large number of persistent and non-persistent storage models. Provide a couple of configuration options and you should be able to let the end user select their storage -- be that file storage, shared memory, memcached, or whatever else. Regards, Daniel -- Digital Infrastructure Solutions -- making IT simple, stable and secure Phone: 0401 155 707 email: contact at digital-infrastructure.com.au http://digital-infrastructure.com.au/ From scottp at dd.com.au Mon Jul 3 19:57:00 2006 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 4 Jul 2006 12:57:00 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> Message-ID: On 04/07/2006, at 12:34, Ian Holsman wrote: > what about using memcached ? If you read my original mail, I actually specifically suggested memcached. >> I could just do a directory cache, but then if someone >> wanted to move to Memcached (for example) that might make it harder. :-) > i'm guessing thumbnails are about 40-50k each.. you could just > stick the things in memecache and let it cache a couple of thousand > that way. > > http://www.danga.com/memcached/ > > I wouldn't use the CPAN module though, there are 2 others which are > being used at the moment. > there is a discussion about the Perl Client here: http:// > lists.danga.com/pipermail/memcached/2006-June/ and http:// > lists.danga.com/pipermail/memcached/2006-July/ Hmm... we use the cpan module at work without hitch. But if there is other solutions why are they not being put on CPAN ? Anyway, my point is NOT to tie into one solution. The File Cache method most cpan apache gallery type code uses is bad, but forcing memcached only would be worse - as we may be dealing with terabytes of images. In some places though where performance is key and usage is small, then memcached - and of course the possibility of both for performance. The point is that there should be an Apache module for caching which does all this for me - the problem with the modules available is that they do everything themselves - so lots of repetition, lack of flexibility etc. Probably the best is to use something like Cache::Cache, write a Memcached plugin for that (I started one but have not yet finished it) and then have something like a Apache Cache plugin for Cache::Cache as well - then you have a totally flexible solution. I wonder if a cascaded Cache::Cache system could be implemented - e.g. Memory -> Disk -> Original - so you have a way of caching the most popular disk entries in memory (by memory that can of course be Memcached) :-) Oh my problem is that I want the world :-) Ta Scott From scottp at dd.com.au Mon Jul 3 19:58:07 2006 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 4 Jul 2006 12:58:07 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: <87odw6ytxt.fsf@rimspace.net> References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> <87odw6ytxt.fsf@rimspace.net> Message-ID: <8BB77A69-370F-4BD7-BAF2-DAC18DAA7EB0@dd.com.au> > Well, they could just use Cache::Memcached or Cache::Memcached::XS to > replace the storage infrastructure under the unified cache module > with a > memcached backed store. :) > > Seriously, Cache::Cache seems like the best generic interface to > storing > the data available. It is good, generic, widely available and > supports > a large number of persistent and non-persistent storage models. > > Provide a couple of configuration options and you should be able to > let > the end user select their storage -- be that file storage, shared > memory, memcached, or whatever else. Yes I agree. Cache::Cache with a Memcached backend, and possibly look at some of the built in Apache cahce backends - and we have the best solution. Scott From lists at holsman.net Mon Jul 3 20:06:29 2006 From: lists at holsman.net (Ian Holsman) Date: Tue, 4 Jul 2006 13:06:29 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> Message-ID: <64124063-EF67-4B40-BFF2-D19F63F2D79B@holsman.net> On 04/07/2006, at 12:57 PM, Scott Penrose wrote: > > On 04/07/2006, at 12:34, Ian Holsman wrote: > >> what about using memcached ? > > If you read my original mail, I actually specifically suggested > memcached. that would be cheating. >> >> I wouldn't use the CPAN module though, there are 2 others which >> are being used at the moment. >> there is a discussion about the Perl Client here: http:// >> lists.danga.com/pipermail/memcached/2006-June/ and http:// >> lists.danga.com/pipermail/memcached/2006-July/ > > Hmm... we use the cpan module at work without hitch. But if there > is other solutions why are they not being put on CPAN ? it's more the performance.. if you read the threads it goes into it in more detail. > > > I wonder if a cascaded Cache::Cache system could be implemented - > e.g. Memory -> Disk -> Original - so you have a way of caching the > most popular disk entries in memory (by memory that can of course > be Memcached) :-) why not use squid? I believe it does the memory -> disk -> original thing. or a CDN like akamai/Coral also are you sure that serving the images out of memory is faster than using sendfile and local disk? (or using a thin webserver to serve them instead of involving mod-perl at all) > > Oh my problem is that I want the world :-) > > Ta > > Scott From daniel at rimspace.net Mon Jul 3 20:17:06 2006 From: daniel at rimspace.net (Daniel Pittman) Date: Tue, 04 Jul 2006 13:17:06 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: (Scott Penrose's message of "Tue, 4 Jul 2006 12:57:00 +1000") References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> Message-ID: <878xnays7h.fsf@rimspace.net> Scott Penrose writes: > On 04/07/2006, at 12:34, Ian Holsman wrote: G'day Scott. [...] > Anyway, my point is NOT to tie into one solution. The File Cache > method most cpan apache gallery type code uses is bad, but forcing > memcached only would be worse - as we may be dealing with terabytes > of images. In some places though where performance is key and usage > is small, then memcached - and of course the possibility of both for > performance. > > The point is that there should be an Apache module for caching which > does all this for me - the problem with the modules available is that > they do everything themselves - so lots of repetition, lack of > flexibility etc. I disagree with you here: Apache is the *wrong* place to put this functionality. What happens if I want to use the same sort of cache with a FastCGI interface[1]... > Probably the best is to use something like Cache::Cache, write a > Memcached plugin for that (I started one but have not yet finished > it) and then have something like a Apache Cache plugin for > Cache::Cache as well - then you have a totally flexible solution. That is a much better solution. An Apache specific backend may make sense in some cases, but not for most. > I wonder if a cascaded Cache::Cache system could be implemented - > e.g. Memory -> Disk -> Original - so you have a way of caching the > most popular disk entries in memory (by memory that can of course be > Memcached) :-) Not that I have run across. Cache::Squid - I see a great need. ;) Daniel Footnotes: [1] This is a common desire of mine, since it insulates both Apache and the application from each other, at a fairly minimal cost. -- Digital Infrastructure Solutions -- making IT simple, stable and secure Phone: 0401 155 707 email: contact at digital-infrastructure.com.au http://digital-infrastructure.com.au/ From scottp at dd.com.au Mon Jul 3 20:39:24 2006 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 4 Jul 2006 13:39:24 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: <64124063-EF67-4B40-BFF2-D19F63F2D79B@holsman.net> References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> <64124063-EF67-4B40-BFF2-D19F63F2D79B@holsman.net> Message-ID: > why not use squid? I believe it does the memory -> disk -> original > thing. > or a CDN like akamai/Coral > > also are you sure that serving the images out of memory is faster > than using sendfile and local disk? (or using a thin webserver to > serve them instead of involving mod-perl at all) I am speaking purely generically. i.e. We need a cache api for Apache (or is there one already?) so that you don't have to care about any of the above - as such - So tomorrow when I do a bit of code that caches database requests, and the next which rewrites HTML::Mason cache, and today when I do Thumnail - they are all the same cache. However your idea about squid is similar to the use of mod_cache in Apache. I have considered that, mod_cache does memory or file caching based on URI - which you just plug in front - excellent - but I have to yet confirm if it supports the ability to wipe a cache entry (I am assuming it has the ability to get headers and do it that way). The nice things about something like mod_cache is that you just enable it infront of anything in Apache - although if it is as simple as that, why is anyone doing any other caching? Scott From scottp at dd.com.au Mon Jul 3 20:46:15 2006 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 4 Jul 2006 13:46:15 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: <878xnays7h.fsf@rimspace.net> References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> <878xnays7h.fsf@rimspace.net> Message-ID: <3EAC6E90-A49F-455A-ADA2-FBA24F8EB054@dd.com.au> On 04/07/2006, at 13:17, Daniel Pittman wrote: > Scott Penrose writes: >> On 04/07/2006, at 12:34, Ian Holsman wrote: > > G'day Scott. > > [...] > >> Anyway, my point is NOT to tie into one solution. The File Cache >> method most cpan apache gallery type code uses is bad, but forcing >> memcached only would be worse - as we may be dealing with terabytes >> of images. In some places though where performance is key and usage >> is small, then memcached - and of course the possibility of both for >> performance. >> >> The point is that there should be an Apache module for caching which >> does all this for me - the problem with the modules available is that >> they do everything themselves - so lots of repetition, lack of >> flexibility etc. > > I disagree with you here: Apache is the *wrong* place to put this > functionality. What happens if I want to use the same sort of cache > with a FastCGI interface[1]... Actually that was my fault in the way I wrote it. I agree 100% that it should not be IN apache. This is true recently for modules too - I would like to write a thumbnail module that can be used in Apache or in Catalyst or ... What I meant about Apache above is more that Apache already has a heap of built in cache stuff - shared memory and more, so in a way we should do the reverse - i.e. have a Cache::Cache module that can use the Apache stuff. > That is a much better solution. An Apache specific backend may make > sense in some cases, but not for most. :-) yep, as above. I like the idea of having one cache system. I HATE the fact that CPAN has two that are not name spaced. If one was called Cache::API and the drivers were Cache::API::* and the other was Cache::Cache and the drivers were Cache::Cache::* that would be fine - but they are not, they are a complete and utter mess ! I will send a mail about that soon. Paul and I were discussion this a few weeks ago - about getting them sorted out a bit, and writing a memcached, sql cache and a few others. >> I wonder if a cascaded Cache::Cache system could be implemented - >> e.g. Memory -> Disk -> Original - so you have a way of caching the >> most popular disk entries in memory (by memory that can of course be >> Memcached) :-) > > Not that I have run across. Cache::Squid - I see a great need. ;) Yes good plan. I think it would be dedicated driver - something like "Cache::MemoryDiskCache" or as above "Cache::SquidCache" This conversation has been excellent, I think it has solidified in my mind that using an api such as Cache::Cache and letting that use Apache is the correct approach, rather than the other way around. But it has also alerted me again to the fact that we need to clean up the Cache APIs. Ta heaps guys Scott From mathew.robertson at netratings.com.au Mon Jul 3 21:03:46 2006 From: mathew.robertson at netratings.com.au (Mathew Robertson) Date: Tue, 04 Jul 2006 14:03:46 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> <64124063-EF67-4B40-BFF2-D19F63F2D79B@holsman.net> Message-ID: <44A9E8A2.9010906@netratings.com.au> >> why not use squid? I believe it does the memory -> disk -> original >> thing. >> or a CDN like akamai/Coral >> >> also are you sure that serving the images out of memory is faster >> than using sendfile and local disk? (or using a thin webserver to >> serve them instead of involving mod-perl at all) > > I am speaking purely generically. i.e. We need a cache api for Apache > (or is there one already?) so that you don't have to care about any > of the above - as such - So tomorrow when I do a bit of code that > caches database requests, and the next which rewrites HTML::Mason > cache, and today when I do Thumnail - they are all the same cache. > > However your idea about squid is similar to the use of mod_cache in > Apache. I have considered that, mod_cache does memory or file caching > based on URI - which you just plug in front - excellent - but I have > to yet confirm if it supports the ability to wipe a cache entry (I am > assuming it has the ability to get headers and do it that way). > > The nice things about something like mod_cache is that you just > enable it infront of anything in Apache - although if it is as simple > as that, why is anyone doing any other caching? It seems to me that people have forgotten "Caching 101"... -> cache effectiveness largely depends on how far it is (logically and physically) from where it is being used. ie: it is not "as simple as that"... eg: memcache'ing of application objects (say a web page) is fine when your app needs to generate those objects from a database which happens to live out over a network. If the database was sitting on the same machine as the application, you would definitely need to profile to determine whether caching was worth it. Likewise, caching of urls is grand, provided that no POST data is being sent. Also, there is the matter of invalidating cache entries ("Caching 102"...? :-) - when can / should cache entries be invalidated? As to the origonal problem -> we want thumbnails, thus caching was suggested. Why caching? What is the problem that we are trying to solve? To generate smaller images automatically? Mathew From scottp at dd.com.au Mon Jul 3 21:46:01 2006 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 4 Jul 2006 14:46:01 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: <44A9E8A2.9010906@netratings.com.au> References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> <64124063-EF67-4B40-BFF2-D19F63F2D79B@holsman.net> <44A9E8A2.9010906@netratings.com.au> Message-ID: <976DC312-2250-4191-93D4-0A97D3A1BCAD@dd.com.au> What you wrote about Caching 101 and 102 is good, but I think we are aware of it, all of those issues you mentioned have been explicitly mentioned in this thread :-) But valuable none the less. On 04/07/2006, at 14:03, Mathew Robertson wrote: > As to the origonal problem -> we want thumbnails, thus caching was > suggested. Why caching? What is the problem that we are trying to > solve? To generate smaller images automatically? The original problem - YES - the extended problem - NO - the question was - is there a standard way of using caches in Apache, as it seems every module does its own thing - in this particular case I don't think I should use a cache API. Explanation... For Thumbnails - most likely: (n hours is configurable) * Create image with reasonable expiry (e.g. n hour) * On a request for IMS (if mod since) - pass it through to the subrequest (i.e. leave it to the original file) (this may be inefficient - might make it configurable) * On new request get local file, if modified longer than n hours, then check headers of original file * If out of date - regenerate, write to disk * If in date - redirect to local file and update expiry * Note: check the pragma nocache and expiry of original and inherit if smaller (for generated objects). Nice thing about the solution above is that the cache is just files on the disk sure, but it is then using Apache to do all the hard work. And Apache is already insanely fast at providing files. The only work it is therefore doing is checking some dates and generating the thumbnail if it must. By checking pragma and expiry it covers the cases when thumbnails can't be cached (e.g. generated on the fly). HOWEVER... If I write code that always generates the thumbnail from the original, and plug in mod_cache in front - it is the same thing :-) mod_cache already does almost all of the above. Scott -- * - * http://www.osdc.com.au - Open Source Developers Conference * - * Scott Penrose Open source developer http://linux.dd.com.au/ scottp at dd.com.au Dismaimer: Open sauce usually ends up never coming out (of the bottle). Please do not send me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Microsoft is not the answer. It's the question. And the answer is no. From mathew.robertson at netratings.com.au Mon Jul 3 23:13:05 2006 From: mathew.robertson at netratings.com.au (Mathew Robertson) Date: Tue, 04 Jul 2006 16:13:05 +1000 Subject: [Melbourne-pm] Apache Cache In-Reply-To: <976DC312-2250-4191-93D4-0A97D3A1BCAD@dd.com.au> References: <4C7D187E-B7AA-4D8E-8041-76429F7BF43B@dd.com.au> <64124063-EF67-4B40-BFF2-D19F63F2D79B@holsman.net> <44A9E8A2.9010906@netratings.com.au> <976DC312-2250-4191-93D4-0A97D3A1BCAD@dd.com.au> Message-ID: <44AA06F1.8090606@netratings.com.au> >> As to the origonal problem -> we want thumbnails, thus caching was >> suggested. Why caching? What is the problem that we are trying to >> solve? To generate smaller images automatically? > > The original problem - YES - the extended problem - NO - the question > was - is there a standard way of using caches in Apache, as it seems > every module does its own thing - in this particular case I don't think > I should use a cache API. Explanation... > > For Thumbnails - most likely: (n hours is configurable) > > * Create image with reasonable expiry (e.g. n hour) > * On a request for IMS (if mod since) - pass it through to the > subrequest (i.e. leave it to the original file) > (this may be inefficient - might make it configurable) > * On new request get local file, if modified longer than n hours, > then check headers of original file > * If out of date - regenerate, write to disk > * If in date - redirect to local file and update expiry > * Note: check the pragma nocache and expiry of original and inherit > if smaller (for generated objects). > > Nice thing about the solution above is that the cache is just files on > the disk sure, but it is then using Apache to do all the hard work. And > Apache is already insanely fast at providing files. > > The only work it is therefore doing is checking some dates and > generating the thumbnail if it must. > > By checking pragma and expiry it covers the cases when thumbnails can't > be cached (e.g. generated on the fly). > > HOWEVER... If I write code that always generates the thumbnail from the > original, and plug in mod_cache in front - it is the same thing :-) > mod_cache already does almost all of the above. As you just said, in this example caching buys you nothing as Apache can already serve the files quite fast. I guess what I was asking was, why cache at all? What is it that you are trying to do with the cache? - Reduce CPU load when the inbound request asks for a thumbnail, by pre-generating the thumbnails, rather than loading the origonal file then making a temporary thumbnail? (The original question sounded like it might be this.) - Are you trying to save bandwidth by sending smaller files? Can you not cache? ie: when you upload the image, you generate a thumbnail there and then - no caching needed. Mathew From david.talamelli at oracle.com Thu Jul 6 17:55:51 2006 From: david.talamelli at oracle.com (David Talamelli) Date: Fri, 7 Jul 2006 10:55:51 +1000 Subject: [Melbourne-pm] 2x Positions at Oracle Corporation (Melbourne) Message-ID: <20060707105551882.00000002172@dtalamel-au> Good morning, I am a Senior Recruiter for Oracle Corporation. We are currently looking to take on two Technical Architects in our Retail Business Unit. While retail exposure would be good it is not necessary. More important is that we find people with strong technical and consulting skills. The roles are permanent positions and are based out of Melbourne, however they may involve up to 50-60% travel across the APAC region (travel could be anywhere from 2 weeks - 3 months depending on projects). Technically we are looking for people with Oracle, UNIX, Perl, C, Java skills. I have put a brief summary of the roles below, which I hope helps. Brief Posting Description The Technical Architect provides client assistance by applying technical knowledge, Oracle specific product knowledge and industry knowledge. These services include installation, Quality Assurance, Hardware sizing , configuration ,support and trouble-shooting for specific Oracle Retail products. A Technical Architect provides leadership to ensure successful implementation of our products and provides quality assurance for the technical aspects of the project. Technical skills we are seeking: UNIX Admin, Oracle DBA, Middleware skills (e.g. SeeBeyond) , Java/J2EE Deployment experience, application server experience, Hardware architecture skills. You will provide engagement delivery services both as an individual and as a team member. Services include identifying needs, developing, influencing and implementing proposals. Able to lead, support and participate on project teams. Please feel free to contact me if you have any questions or wish to discuss further. Thank you. Regards; David Talamelli Senior Recruiter Oracle Corporation Australia Pty Limited Level 7, 324 St Kilda Road MELBOURNE VIC 3004 Tel - +61 3 8616 3364 Mob - +61 402 681 632 Web - iRecruitment.oracle.com Oracle Recruiting: "Continuously selected by our clients as the exclusive vendor of pre-eminent talent" The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. No internal Oracle email, except that clearly intended for public distribution (e.g. Oracle Press Releases) should be sent to any party outside of Oracle. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/melbourne-pm/attachments/20060707/b36ef68e/attachment.html From scottp at dd.com.au Sat Jul 8 15:51:31 2006 From: scottp at dd.com.au (Scott Penrose) Date: Sun, 9 Jul 2006 08:51:31 +1000 Subject: [Melbourne-pm] Perl T-Shirts Message-ID: <45ACFF02-9F45-49EA-84DB-4AA77EEF3294@dd.com.au> Hey Guys, In case you are interested in getting an order together for T-Shirts http://omaha.pm.org/shirts.shtml :-) Scott -- * - * http://www.osdc.com.au - Open Source Developers Conference * - * Scott Penrose VP in charge of Pancakes http://linux.dd.com.au/ scottp at dd.com.au Dismaimer: If you receive this email in error - please eat it immediately to prevent it from falling into the wrong hands. Please do not send me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Microsoft is not the answer. It's the question. And the answer is no. From ajsavige at yahoo.com.au Sat Jul 8 20:31:50 2006 From: ajsavige at yahoo.com.au (Andrew Savige) Date: Sun, 9 Jul 2006 13:31:50 +1000 (EST) Subject: [Melbourne-pm] Perl T-Shirts In-Reply-To: <45ACFF02-9F45-49EA-84DB-4AA77EEF3294@dd.com.au> Message-ID: <20060709033150.68864.qmail@web56404.mail.re3.yahoo.com> --- Scott Penrose wrote: > In case you are interested in getting an order together for T-Shirts > > http://omaha.pm.org/shirts.shtml As described here: http://www.oreillynet.com/pub/a/oreilly/perl/usage/ O'Reilly have a trademark on the use of a camel in association with Perl. To comply, the T-shirt (and the web page advertising it) must at least contain something like: The use of a camel image in association with the Perl language is a trademark of O'Reilly Media Inc. Used with permission. Avoiding this copyright business is one reason why Portland Perl Mongers chose a design without a camel for their 2006 T-shirts: http://scratchcomputing.com/tmp/final_mockup.png /-\ ____________________________________________________ On Yahoo!7 Dating: It's free to join and check out our great singles! http://www.yahoo7.com.au/personals From jarich at perltraining.com.au Sun Jul 9 21:45:49 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Mon, 10 Jul 2006 14:45:49 +1000 Subject: [Melbourne-pm] Meeting this week: Wednesday 12th July, 6:30pm Message-ID: <44B1DB7D.3080403@perltraining.com.au> G'day everyone, To help entice you out of your warm offices or homes and along to this week's Melbourne Perl Monger meeting, we're throwing a little party. Come along for a social night, a chance to meet everyone and have a little fun. Paul will still be giving his talk which should be a light hearted affair, accessible to audiences of most ages and interests. Bring along your friends and family and it should be a great night for all. Date: Wednesday 12th July Time: 6:30pm Location: (Usual place) Level 8, 14 Blackwood Street, North Melbourne If you're a member of another user group and you'd like to encourage some of their members to join in, please pass on this invitation. We look forward to seeing you there! Jacinta -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From scottp at dd.com.au Mon Jul 10 04:34:34 2006 From: scottp at dd.com.au (Scott Penrose) Date: Mon, 10 Jul 2006 21:34:34 +1000 Subject: [Melbourne-pm] Perl T-Shirts In-Reply-To: <20060709033150.68864.qmail@web56404.mail.re3.yahoo.com> References: <20060709033150.68864.qmail@web56404.mail.re3.yahoo.com> Message-ID: <34A41292-5FC5-4B3E-A0D2-F3775EAB3AD8@dd.com.au> On 09/07/2006, at 13:31, Andrew Savige wrote: > --- Scott Penrose wrote: >> In case you are interested in getting an order together for T-Shirts >> >> http://omaha.pm.org/shirts.shtml > > As described here: > > http://www.oreillynet.com/pub/a/oreilly/perl/usage/ > > O'Reilly have a trademark on the use of a camel in association with > Perl. To comply, the T-shirt (and the web page advertising it) must > at least contain something like: > > The use of a camel image in association with the Perl language > is a trademark of O'Reilly Media Inc. Used with permission. > > Avoiding this copyright business is one reason why Portland Perl > Mongers > chose a design without a camel for their 2006 T-shirts: > > http://scratchcomputing.com/tmp/final_mockup.png Hi Andrew, Firstly - O'Reilly has yet to refuse any perl group using the camel - they are good custodians, you need someone to protect things like that - of course I would be happier if it was the Perl Foundation :-) However... this is a world wide effort - not just Melbourne :-) And is being done with blessing. Scott From jarich at perltraining.com.au Mon Jul 10 19:10:15 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Tue, 11 Jul 2006 12:10:15 +1000 Subject: [Melbourne-pm] OSDC Paper Proposals due tomorrow! Message-ID: <44B30887.6090304@perltraining.com.au> G'day everyone, This is a final reminder that OSDC papers are due tomorrow. Our conference is nothing without speakers, so I encourage you all to get your proposals in as soon as possible! http://www.osdc.com.au/papers/cfp06.html For those who've never submitted a proposal before, or spoken at at conference: fear not! A proposal is just a couple of paragraphs about what you think you might like to say. If your talk's direction changes somewhat when you start writing it, that's okay! Further, we encourage you to give your talk(s) to your local user groups (for example OSDClub) before the conference. This will give you some great practice time and give us the chance to give you some feedback. If you have any friends or family members who might also want to present, please feel free to pass this invitation on. Likewise if you know of any related user groups who haven't heard from us, please invite them to participate. Our goal is to make this conference truly representative of Australia's amazing Open Source development community! We look forward to seeing your paper submission. Jacinta PS: If you're interested in being part of the paper selection committee, please contact Richard, our Programme Chair: richard osdc.com.au -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From leif.eriksen at hpa.com.au Wed Jul 12 16:25:20 2006 From: leif.eriksen at hpa.com.au (leif.eriksen at hpa.com.au) Date: Thu, 13 Jul 2006 09:25:20 +1000 Subject: [Melbourne-pm] Shuttle launch video Message-ID: Mongers!, I described a video of the Discovery shuttle launch last night at MPM, and here is the link http://mfile.akamai.com/18566/wmv/etouchsyst2.download.akamai.com/18355/wm.nasa-global/sts-121/right_aft_srb_camera.asx It shows the launch from the perspective of a camera near the tail of a SRB. Notice the white vapour plume near the shuttle nose as it passes through the sound barrier, then the sky getting darker. Also note the glow from the other SRB exhaust slowly fade. At about 2:58, the SRB separates and you get a fantastic shot of the shuttle on full main engine thrust passing off to the left of screen, still with main tank attached. Then there are a few minutes of tumble reentry, parachutes open and splashdown (probably somewhere in the Atlantic) and a slow float almost to the surface. Its enough to make you apply to NASA for a job as a "whatever the hell you want, just give me a job here - your stuff is cool". The main site for this shuttle mission (STS-121) is here http://www.nasa.gov/externalflash/sts-121_front/index.html L -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.10/385 - Release Date: 11/07/2006 ********************************************************************** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, postmaster at hpa.com.au, then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments, check them for viruses and defects. Our liability is limited to resupplying any affected attachments. HPA collects personal information to provide and market our services. For more information about use, disclosure and access see our Privacy Policy at www.hpa.com.au ********************************************************************** From adam.clarke at strategicdata.com.au Tue Jul 25 00:39:28 2006 From: adam.clarke at strategicdata.com.au (Adam Clarke) Date: Tue, 25 Jul 2006 17:39:28 +1000 Subject: [Melbourne-pm] Perl Monger T-Shirt Order Message-ID: <44C5CAB0.5000503@strategicdata.com.au> Hi Perl people, Scott Penrose and I decided to organise a Perl Monger T-Shirt order on the back of these guys efforts ( http://omaha.pm.org/shirts.shtml ). Strategic Data have volunteered to put in a bulk order and handle shipping for all Australian Perl Mongers. We will put in an order for and invoice anyone who fills in the form referenced below and responds to our confirmation email. The final price is not yet known but it will be in the $20 - $25 range. When the T's arrive we'll re-bundle them into Perl Monger batches and re-ship them to the appropriate contact person. Anyone who has not paid their invoice by shipment time (whenever that ends up being) can pay a bit extra to have it shipped direct to them from us. You can place an order here ... http://tinyurl.com/gz829 ... feel free to organise joint orders amongst yourselves as long as their is someone who is happy to get an invoice for the whole order. Otherwise have people put in an order individually. Please pass this on to your network. The deadline for orders is the 4th of August, 2006. Cheers -- Adam Clarke www.strategicdata.com.au From peter at machell.net Tue Jul 25 03:50:49 2006 From: peter at machell.net (Peter Machell) Date: Tue, 25 Jul 2006 20:50:49 +1000 Subject: [Melbourne-pm] Help - I barely speak Camel. Message-ID: <1F18B99A-617B-43E3-8DFE-688C21AD6765@machell.net> Hi list. Jacinta Richardson suggested I join. I'm a fairly junior sysadmin, by no means a programmer. I have hacked bits and pieces in Perl over the years and find it very good for glue, but do this so infrequently that I need to relearn even the basics each time. I need to develop a simple application and would like to do so in Perl. Is this list an appropriate place to ask questions about this with a view to better understanding and refining my code? Assuming that it is, can I start with the workflow and see if it makes sense? I need to interface with a number of different databases to pull out some demographic information, feed this into an array, regex it to get the formatting right, then send it, and a message containing variables from this info, to an API for which I have a Perl example. Returning from that API will be some debug, which I'd like to combine with the information and print out to a HTML file for reporting. As I'm dealing with a number of different database engines, I figure I'll do the initial data mining using those engine's tools, and start the Perl code with pulling data from a CSV file. This seems easier to me than trying to get a DBI going for each engine and using Perl to do the queries. I'm sure there are many on this list that could knock this up in a few minutes, but I'd really like to do it myself so that I can completely understand the process, and continue to develop and support it. Please let me know if this is an appropriate forum for this sort of thing, and if not, where I may find one. Thanks in advance, Peter. From adam.clarke at strategicdata.com.au Tue Jul 25 04:42:58 2006 From: adam.clarke at strategicdata.com.au (Adam Clarke) Date: Tue, 25 Jul 2006 21:42:58 +1000 Subject: [Melbourne-pm] Help - I barely speak Camel. In-Reply-To: <1F18B99A-617B-43E3-8DFE-688C21AD6765@machell.net> References: <1F18B99A-617B-43E3-8DFE-688C21AD6765@machell.net> Message-ID: <44C603C2.9060908@strategicdata.com.au> Hello Peter, Peter Machell wrote: > I need to develop a simple application and would like to do so in > Perl. Is this list an appropriate place to ask questions about this > with a view to better understanding and refining my code? I'm no grand pooh-bah of melbourne.pm list etiquette however it sounds like a pretty reasonable thing to be doing to me. > I need to interface with a number of different databases to pull out > some demographic information, feed this into an array, regex it to > get the formatting right, then send it, and a message containing > variables from this info, to an API for which I have a Perl example. Sounds like a job for Perl, do you have any specific questions about those steps? > Returning from that API will be some debug, which I'd like to combine > with the information and print out to a HTML file for reporting. This sounds like a job for a templating module. Take a look at Template Toolkit ... http://www.template-toolkit.org/ http://search.cpan.org/~abw/Template-Toolkit-2.15/lib/Template.pm ... you want to abstract the markup generation from your code as early as you can. If you find yourself printing out HTML from within Perl then you should almost always be using some kind of templating solution. > As I'm dealing with a number of different database engines, I figure > I'll do the initial data mining using those engine's tools, and start > the Perl code with pulling data from a CSV file. This seems easier to > me than trying to get a DBI going for each engine and using Perl to > do the queries. If you can afford the time, I'd bite the bullet and try to get DBI going. It will help keep all the stuff you are needing to do for this job in one place. If you do decide to go the CSV route, don't try to parse this yourself, see one of the Perl modules Text::CSV_XS (fast) or Text::CSV_PP (slow) or better yet DBD::CSV and use the DBI to access that gathered data. The latter option will allow you to move to direct DBI access to your data more easily since the code will likely be very similar. Cheers -- Adam Clarke www.strategicdata.com.au From alecclews at gmail.com Tue Jul 25 07:05:19 2006 From: alecclews at gmail.com (Alec Clews) Date: Tue, 25 Jul 2006 07:05:19 -0700 Subject: [Melbourne-pm] Help - I barely speak Camel. In-Reply-To: <1F18B99A-617B-43E3-8DFE-688C21AD6765@machell.net> References: <1F18B99A-617B-43E3-8DFE-688C21AD6765@machell.net> Message-ID: <1153836320.3147.6.camel@voga1.clews.local> You may the information on perl.net.au of help, it includes sections for newbies (try http://perl.net.au/wiki/New_to_Perl) and pointers to further information. We are keen to improve it so please make any changes to things you thing can be improved or suggest them here. On Tue, 2006-07-25 at 20:50 +1000, Peter Machell wrote: > Hi list. Jacinta Richardson suggested I join. I'm a fairly junior > sysadmin, by no means a programmer. I have hacked bits and pieces in > Perl over the years and find it very good for glue, but do this so > infrequently that I need to relearn even the basics each time. > > I need to develop a simple application and would like to do so in > Perl. Is this list an appropriate place to ask questions about this > with a view to better understanding and refining my code? > > Assuming that it is, can I start with the workflow and see if it > makes sense? > > I need to interface with a number of different databases to pull out > some demographic information, feed this into an array, regex it to > get the formatting right, then send it, and a message containing > variables from this info, to an API for which I have a Perl example. > Returning from that API will be some debug, which I'd like to combine > with the information and print out to a HTML file for reporting. > > As I'm dealing with a number of different database engines, I figure > I'll do the initial data mining using those engine's tools, and start > the Perl code with pulling data from a CSV file. This seems easier to > me than trying to get a DBI going for each engine and using Perl to > do the queries. > > I'm sure there are many on this list that could knock this up in a > few minutes, but I'd really like to do it myself so that I can > completely understand the process, and continue to develop and > support it. > > Please let me know if this is an appropriate forum for this sort of > thing, and if not, where I may find one. > > Thanks in advance, > > Peter. > > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm -- Alec Clews Melbourne, Australia. Jabber: alecclews at jabber.org.au PGPKey ID: 0x9BBBFC7C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.pm.org/pipermail/melbourne-pm/attachments/20060725/8ec1933c/attachment.bin From mathew.robertson at netratings.com.au Tue Jul 25 16:29:50 2006 From: mathew.robertson at netratings.com.au (Mathew Robertson) Date: Wed, 26 Jul 2006 09:29:50 +1000 Subject: [Melbourne-pm] Help - I barely speak Camel. In-Reply-To: <44C603C2.9060908@strategicdata.com.au> References: <1F18B99A-617B-43E3-8DFE-688C21AD6765@machell.net> <44C603C2.9060908@strategicdata.com.au> Message-ID: <44C6A96E.1060509@netratings.com.au> >> Returning from that API will be some debug, which I'd like to combine >> with the information and print out to a HTML file for reporting. > > This sounds like a job for a templating module. Take a look at Template > Toolkit ... > > http://www.template-toolkit.org/ > http://search.cpan.org/~abw/Template-Toolkit-2.15/lib/Template.pm > > ... you want to abstract the markup generation from your code as early > as you can. If you find yourself printing out HTML from within Perl then > you should almost always be using some kind of templating solution. Also there are a number of alternatives to Template-Toolkit, eg: HTML::Template. >> As I'm dealing with a number of different database engines, I figure >> I'll do the initial data mining using those engine's tools, and start >> the Perl code with pulling data from a CSV file. This seems easier to >> me than trying to get a DBI going for each engine and using Perl to >> do the queries. > > If you can afford the time, I'd bite the bullet and try to get DBI > going. It will help keep all the stuff you are needing to do for this > job in one place. If you do decide to go the CSV route, don't try to > parse this yourself, see one of the Perl modules Text::CSV_XS (fast) or > Text::CSV_PP (slow) or better yet DBD::CSV and use the DBI to access > that gathered data. The latter option will allow you to move to direct > DBI access to your data more easily since the code will likely be very > similar. Seconded - if you can connect directly to the database, then do so. Using the DBI interface is far easier than people give it credit for, since you have direct access to SQL (some of the data mining tools dont give you access to the SQL). Mathew From blm at woodheap.org Tue Jul 25 22:33:47 2006 From: blm at woodheap.org (blm at woodheap.org) Date: Wed, 26 Jul 2006 06:33:47 +0100 Subject: [Melbourne-pm] Melbourne Perl Mongers Meeting 9 August 2005 Message-ID: <20060726053347.GA13182@woodheap.org> Hello all, In August it is Melbourne PHP group's turn to host the OSDC Club meeting on 2 August. Consequently there is a Melbourne Perl Monger meeting scheduled for 9 August 2005. I would love to schedule some talks for this meeting. As I understand it, Simon Taylor may talk to us about OSCON. Since OSDC Conference is approaching this represents an opportunity for people to practise and further refine talks that have been submitted to OSDC. So if you want to give a talk to the group on Wednesday 9 August let us know. Regards, Ben Marsh Treasurer Melbourne Perl Mongers. From ben at benbalbo.com Sat Jul 29 23:47:35 2006 From: ben at benbalbo.com (Ben Balbo) Date: Sun, 30 Jul 2006 16:47:35 +1000 Subject: [Melbourne-pm] OSDClub meeting - 3rd August 2006 Message-ID: <44CC5607.2050008@benbalbo.com> Sorry for the late notice: We invite you to join us for the next OSDClub meeting: When: 6:30pm, Thursday 3rd August 2006 Where: Room 56-5-88, RMIT Building 56, corner of Queensbury & Lygon streets More details: http://www.osdc.com.au/osdclub/ Please invite your friends, family and workmates to join us if you anticipate they may be interested. Our featured talks will be: Zaltana Window Manager Widget, Table Sort Widget and Asynchronous Search Widget by Scott Penrose ------------------------------------------------------------- Scott will be talking about his latest work on the Zaltana project. Review of OSCON by Alec Clews ------------------------------------ Alec will chat about the goings-on at OSCON. If there is time, he will also give his OSCON presentation on how to implement change management and project management using current OSS tools. (approx 15 mins) Talk Proposals ============== We invite you to offer talk proposals for future meetings. To be involved, send your talk topic to clubadmin at osdc.com.au Presentations can make use of a particular programming language to illustrate examples, but should be accessible to programmers from a range of backgrounds. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://mail.pm.org/pipermail/melbourne-pm/attachments/20060730/f4d38dd0/attachment.bin From jarich at perltraining.com.au Mon Jul 31 22:26:25 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Tue, 01 Aug 2006 15:26:25 +1000 Subject: [Melbourne-pm] Offer from Perl Training Australia Message-ID: <44CEE601.3010808@perltraining.com.au> Bundle and Save up to 30% per course ==================================== Book on multiple Perl Training Australia courses at once and SAVE 25% on each subsequent course! With our "Bundle and Save" special simply book on multiple courses in the same set; pay full price for one and receive a discount of 25% on all the rest. For example, book on the full Melbourne set in September (Programming Perl, Object Oriented Perl, Database Programming with Perl, Web Development with Perl and Perl Security) and save $990 per person! Or skip Programming Perl and still save $715 per person! Even better, if you book 3 or more attendees on each of these courses, you'll also be eligible for the "Group discount" of an additional 5%! For more information visit our Specials page: http://perltraining.com.au/specials.html In addition, we are proud to offer our User Group special. Mention Melbourne Perl Mongers to receive an extra 5% off any full price course. Upcoming courses in Melbourne ============================= http://perltraining.com.au/bookings/Melbourne.html Course Date -------------------------------------------------------- Programming Perl 12th - 15th September 2006 Object Oriented Perl 19th - 20th September 2006 Databases and Perl 21st - 22nd September 2006 Web Development with Perl 23rd - 24th September 2006 Perl Security 25th September 2006 Bookings before the early bird date (11th August) will receive one free book per full price course! Should we receive insufficient bookings on any course by the early bird date, that course may be cancelled. Corporate Courses ================= http://perltraining.com.au/corporate.html All of Perl Training Australia's courses are available for corporate bookings. If you have a large group or want training at a particular time then let us know. We're happy to send you a no-obligation quote to provide courses in the time and place that suits you. For more information visit http://perltraining.com.au/corporate.html or call us on 61 3 9354 6001.