[EDIT: The presentation doesn't appear to work on mobile devices. I'm trying deck.js, and I'm not sure I like it.]
Best of all, the talk itself was written in Mojolicious! As Joel was talking, he was able to edit the code and display the results, showing off various features of Mojolicious like:
- Easy testing (even of websockets)
- Helper scripts
- Mojo templates
There are quite a few interesting parts of Mojolicious that make it worth giving a look to, and I hope to be able to do so with some web projects that have been sitting in my queue for a while (I wrote a nice ticket tracker with AngularJS, but the backend is Python, I'd like to fix that glaring mistake).
This month's presentation was on the Git::Repository Perl module, given by me. In both my jobs, I use the Git::Repository module to automate releases.
At Double Cluepon, I use it to create the release packages based on tagged commits, so that releasing our software is exactly: git tag vX.X.X && git push --tags. A Perl script builds every package and then pushes them to our update server, where the game will check for a new release.
At Bank of America, we use it to combine our 20-30 Perl distributions into a single release. Using git submodules, we have a "release repository" that holds references to all the modules for each team's releases (some are team-specific, others are shared between teams). A Perl script manages the submodules, determines when the submodule refs need to be updated, tags and branches for each release, and finally builds and installs our modules using Module::Build and local::lib.
All this Git stuff gave me some ideas for possible useful code I can release, perhaps leading to me finally recovering my CPAN ID.
This month's project night focused on Joel Berger's Alien::Base module. The final bugs are either squashed or very close, and we got an introduction to how the whole thing works.
I learned some interesting things about DynaLoader that helped cement the idea that it's an interface on to the system's dynamic linker. I've never dealt with DynaLoader from the Perl side of things, except when it broke, and I would solve those problems in system-specific ways. I learned that DynaLoader could solve those problems in a cross-platform way.
I started writing my own Alien::Base module for libusb, but unfortunately ran out of time. We had some interesting side-discussion on human interface devices and augmented reality.
In two weeks, I'll be giving a talk on scripting Git with Perl. Come on down and check it out!
This month's technical presentation at Chicago Perl Mongers was about Sean Blanton's project called App::Services. It's an interesting project that uses Bread::Board to access resources like databases, logging, ssh, and others.
Along the way, we discussed logging practices (most of us are using Log::Log4perl), and the best way to get a Perl module ready for CPAN (I suggested using Module::Build directly, but Dist::Zilla outvoted me).
Sean mentioned in passing the Salt stack for executing commands across multiple machines, which looks like a very interesting alternative to more detailed tools like Puppet or Chef. Salt seems to be just a simple way to execute commands on multiple machines. Those commands could be administrative (restart httpd), or they could be the application.
One other very interesting thing from App::Services was providing a role for the larger system to use. So one creates App::Service::Log::Log4perl and App::Service::Log::Role, and in other services you consume the App::Service::Log::Role and then can use the Log4perl service. What's interesting about this is that the role is provided alongside the logging service, it isn't something that you have to create yourself. Doing it this way improves interoperability and simplifies adoption by giving you the tedious bits already. It's the difference between "Here's a service, figure out how to use it best" and "Here's a service, and here's a good way to use it" (I've been doing something similar by providing Test::MockObject implementations of my modules for testing purposes in the same distribution as the module itself. An "official" mock object).
In two weeks we have another project night, which I'm hoping is as productive as the last. If you're in the Chicago area, check us out on the Chicago Perl Mongers meetup page.
There were some small ideas to make the program more user-friendly, and some larger ideas like an IRC client and guided tutorials based on the same format that http://perltuts.com uses.
I'm hoping that if I keep saying this, I'll be embarrassed into doing it: I would really love to see the Ruby Koans translated into Perl (in spirit, if not in actual content). I've started writing down ideas for chapters, but there is a lot of content to cover.
I added a -I flag and a -M flag to the prima-repl command-line launcher that work as close to perl's flags as I could get. This is one of the things I love about prove and plackup: Where it makes sense, they work like perl does. So now the prima-repl can have subs and modules imported on the command-line.
Altogether it was a wonderfully productive evening and I'm looking forward to the next one.