Re: [ANNOUNCE] London Perl Hack Day, Saturday 20th September 2014
Joel in being Joel shocker :p Though there's a fair point in there somewhere, I'm sure... On 25 Jul 2014 18:28, "Sue Spence" wrote: > On 25 July 2014 17:59, Joel Bernstein wrote: > > > On 25 July 2014 18:22, Tom Hukins wrote: > > > > > We invite anyone who would like to work on anything > > > Perl-related to attend. Everyone from complete Perl beginners to > > > experts is welcome. > > > > > > > How do you define Perl-related? Perl itself? Perl modules? Apps in Perl? > > Apps partly in Perl? Apps in Ruby (essentially another Perl dialect)? > > > > > We don't have to define it because it's blindingly obvious. > > > > > > Hopefully the answer is "we don't, it's up to the attendees to define > what > > it means for each of them". > > > > > >
Re: [ANNOUNCE] London Perl Hack Day, Saturday 20th September 2014
On 25 July 2014 17:59, Joel Bernstein wrote: > On 25 July 2014 18:22, Tom Hukins wrote: > > > We invite anyone who would like to work on anything > > Perl-related to attend. Everyone from complete Perl beginners to > > experts is welcome. > > > > How do you define Perl-related? Perl itself? Perl modules? Apps in Perl? > Apps partly in Perl? Apps in Ruby (essentially another Perl dialect)? > We don't have to define it because it's blindingly obvious. > > Hopefully the answer is "we don't, it's up to the attendees to define what > it means for each of them". > >
Re: [ANNOUNCE] London Perl Hack Day, Saturday 20th September 2014
On 25 July 2014 18:22, Tom Hukins wrote: > We invite anyone who would like to work on anything > Perl-related to attend. Everyone from complete Perl beginners to > experts is welcome. > How do you define Perl-related? Perl itself? Perl modules? Apps in Perl? Apps partly in Perl? Apps in Ruby (essentially another Perl dialect)? Hopefully the answer is "we don't, it's up to the attendees to define what it means for each of them". /joel
[ANNOUNCE] London Perl Hack Day, Saturday 20th September 2014
On Saturday 20th September, 2014, London Perl Mongers will host our first hack day. We invite anyone who would like to work on anything Perl-related to attend. Everyone from complete Perl beginners to experts is welcome. This event will take place at the London Hack Space between 12pm and 5pm. See https://london.hackspace.org.uk/ for more information about the Hack Space. If you want to attend, you will need to sign up at http://www.meetup.com/London-Perl-Mongers/events/194285872/. If you find you can't attend, please cancel so that someone else can take your place. So, what will we do? Well, everyone's free to hack on anything Perl-related that they fancy. If you have an idea, please share it on the Meetup page or on the London.pm mailing list at http://london.pm.org/join/. You'll be free to work on your own or collaborate with others to whatever extent you choose. You might want to ask other attendees for help with your work, or offer help to others: probably both. Make sure you bring a laptop that you can write code on, or one that you would like us to help you install Perl on, an enthusiastic, open mind and a cheerful demeanour. Please spread the word to anyone who you think might want to attend. See you for fun Perl hacking in September! Tom
Re: Deploying perl code
On Fri, 2014-07-25 at 12:08 +0200, James Laver wrote: > On 25 Jul 2014, at 11:54, Andrew Beverley wrote: > > > The main problem is that it seems to be a victim of its own success: > > there is a huge backlog of merge requests. I'd like to provide some > > simple patches to a couple of modules to make them work better for me, > > but have little hope that they'd be merged this side of Christmas. I > > provided a really simple patch a while ago - it's not been touched and > > now no longer merges cleanly. > > I won’t even try and submit a patch after my experience reporting a > documentation bug. I was at the time regularly tweeting with their CTO, > so I let him know on twitter. He then pointed me at the bug tracker, > where I proceeded to file my bug. Immediately, ‘ansibot’ informed me > that my bug would be closed in a few days if I didn’t reformat my bug > to correspond with their designated format for bugs, which included > such things as “steps to reproduce” (because you know, we all have > difficulty reproducing documentation bugs). I think the only way I > actually got that doc bug fixed was by complaining loudly and > repetitively on twitter about how ridiculous their processes are, but > they showed absolutely no willing to make it easier to contribute > towards their projects, so I’m showing absolutely no willing to help > them grow their company. And therein proves my point. I'd love to fork it, but that's not going to help of course. They'd do themselves a massive favour by splitting out the modules à la CPAN.
Re: Deploying perl code
On 25 Jul 2014, at 11:54, Andrew Beverley wrote: > The main problem is that it seems to be a victim of its own success: > there is a huge backlog of merge requests. I'd like to provide some > simple patches to a couple of modules to make them work better for me, > but have little hope that they'd be merged this side of Christmas. I > provided a really simple patch a while ago - it's not been touched and > now no longer merges cleanly. I won’t even try and submit a patch after my experience reporting a documentation bug. I was at the time regularly tweeting with their CTO, so I let him know on twitter. He then pointed me at the bug tracker, where I proceeded to file my bug. Immediately, ‘ansibot’ informed me that my bug would be closed in a few days if I didn’t reformat my bug to correspond with their designated format for bugs, which included such things as “steps to reproduce” (because you know, we all have difficulty reproducing documentation bugs). I think the only way I actually got that doc bug fixed was by complaining loudly and repetitively on twitter about how ridiculous their processes are, but they showed absolutely no willing to make it easier to contribute towards their projects, so I’m showing absolutely no willing to help them grow their company. /j
Re: Deploying perl code
On Fri, 2014-07-25 at 10:11 +0200, James Laver wrote: > Ansible I do like for the most part I'm a fan of Ansible, and am in the process of using it to deploy code (although more by accident than design). The main problem is that it seems to be a victim of its own success: there is a huge backlog of merge requests. I'd like to provide some simple patches to a couple of modules to make them work better for me, but have little hope that they'd be merged this side of Christmas. I provided a really simple patch a while ago - it's not been touched and now no longer merges cleanly.
Re: Deploying perl code
Hey, We're in a similar boat to Leo for our use of Puppet - used to manage stuff in /etc/ and the general Debian packages we have installed - but mostly we build our own. We have an /opt/lokku/pkgs which contains our own Perl, Apache, Percona DB, node.js, etc. We manage /opt/lokku/bin with swpkg - old school technology but it works ;-) For distributing code we just push out tarballs, untar them, flip a symlink and restart services. It's shell scripts with the distribute being based on rdist. We build the tarball with the 'git-archive' command. And to throw some even more ancient tech in there we use wigwam framework for managing roles (environment variables and service lists per role) and services (stop, start, restart, etc.) I'm not proud of it, but we launch multiple times a day so clearly it works. - Alex On 25 July 2014 08:40, mascip wrote: > I've loved using Ansible on a personal project recently. Almost zero set up > and learning. > Compared to bash scripts, I love the reuse with Roles, the fact that many > tasks and roles exist (Ansible Galaxy is Ansible's CPAN), and the > idempotence: you can run a playbook as many times as you like, it should > have just the same effect as running it once (true for most Ansible > things). > > -- Pierre Masci > > > On 25 July 2014 07:52, Ben Tisdall wrote: > > > >> On 24 July 2014 22:31, Paul Makepeace wrote: > > >>> > > >>> capistrano is a (the?) winner for sure. > > >> > > > > I've used Capistrano a bit - it's ok but too much magic for my liking > > (and in general I'm a big fan of the Ruby ecosystem). Fabric is a more > > sensible alternative IMO (you might find > > http://www.slideshare.net/panopticdev/fabric-a-capistrano-alternative > > useful). > > > > However, I would urge you to spend a day each investigating Ansible & > > SaltStack, the latter in salt-ssh mode if you want to make a direct > > comparison. Both of the aforementioned tools do ad-hoc remote > > execution, task orchestration and configuration management. > > > > FWIW I spent 3 days last week evaluating orchestration tools for $WORK > > last week, looking at dsh, Capistrano, Fabric, MCollective (covered > > that in one sentence - it's way heavy), Ansible & SaltStack. I liked > > both Ansible & SaltStack but concluded that the former was the best > > for the project in question because it was easier to get started with > > and it came with a lot of modules that were useful to us out of the > > box. > > > > HTH. > > > > -Ben > > >
Re: Deploying perl code
On 25 Jul 2014, at 09:40, mascip wrote: > and the idempotence: you can run a playbook as many times as you like, it > should > have just the same effect as running it once (true for most Ansible things). That’s in stark contrast to my experiences. I found ansible requires you to think about the side effects of everything so that you can write idempotent code. Where the default puppet library and constraint resolution mode of thinking basically gives you the idempotence for free, ansible pushes the responsibility back to the developer. Chef is even worse at this. Without idempotence for free, the only compelling reason to use it over a shell script is the reusable roles. James
Re: Deploying perl code
On 25 Jul 2014, at 08:52, Ben Tisdall wrote: > However, I would urge you to spend a day each investigating Ansible & > SaltStack, the latter in salt-ssh mode if you want to make a direct > comparison. Both of the aforementioned tools do ad-hoc remote > execution, task orchestration and configuration management. Ansible I do like for the most part, but there are a few sharp edges. I don’t think it was usable up until they put out 1.3 (was it 1.3? it’s been a while since i’ve written a playbook) which added a bunch of useful stuff in the standard library — I was running out of git master for ages. I don’t think it’s the right solution for this case, though. Salt: just no. Really no. I’m really surprised to see a recommendation for it, because it’s a terrible piece of software. James
Re: Deploying perl code
I've loved using Ansible on a personal project recently. Almost zero set up and learning. Compared to bash scripts, I love the reuse with Roles, the fact that many tasks and roles exist (Ansible Galaxy is Ansible's CPAN), and the idempotence: you can run a playbook as many times as you like, it should have just the same effect as running it once (true for most Ansible things). -- Pierre Masci On 25 July 2014 07:52, Ben Tisdall wrote: > >> On 24 July 2014 22:31, Paul Makepeace wrote: > >>> > >>> capistrano is a (the?) winner for sure. > >> > > I've used Capistrano a bit - it's ok but too much magic for my liking > (and in general I'm a big fan of the Ruby ecosystem). Fabric is a more > sensible alternative IMO (you might find > http://www.slideshare.net/panopticdev/fabric-a-capistrano-alternative > useful). > > However, I would urge you to spend a day each investigating Ansible & > SaltStack, the latter in salt-ssh mode if you want to make a direct > comparison. Both of the aforementioned tools do ad-hoc remote > execution, task orchestration and configuration management. > > FWIW I spent 3 days last week evaluating orchestration tools for $WORK > last week, looking at dsh, Capistrano, Fabric, MCollective (covered > that in one sentence - it's way heavy), Ansible & SaltStack. I liked > both Ansible & SaltStack but concluded that the former was the best > for the project in question because it was easier to get started with > and it came with a lot of modules that were useful to us out of the > box. > > HTH. > > -Ben >
Re: Deploying perl code
>> On 24 July 2014 22:31, Paul Makepeace wrote: >>> >>> capistrano is a (the?) winner for sure. >> I've used Capistrano a bit - it's ok but too much magic for my liking (and in general I'm a big fan of the Ruby ecosystem). Fabric is a more sensible alternative IMO (you might find http://www.slideshare.net/panopticdev/fabric-a-capistrano-alternative useful). However, I would urge you to spend a day each investigating Ansible & SaltStack, the latter in salt-ssh mode if you want to make a direct comparison. Both of the aforementioned tools do ad-hoc remote execution, task orchestration and configuration management. FWIW I spent 3 days last week evaluating orchestration tools for $WORK last week, looking at dsh, Capistrano, Fabric, MCollective (covered that in one sentence - it's way heavy), Ansible & SaltStack. I liked both Ansible & SaltStack but concluded that the former was the best for the project in question because it was easier to get started with and it came with a lot of modules that were useful to us out of the box. HTH. -Ben
