[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).
My job at Bank of America consists largely of data collection and storage. To collect data in Perl, I have to write XS modules to interface with the vendor-supplied native libraries. Because I want to know my code works, my XS modules come with robust test suites, testing that everything works correctly.
Since the XS module was intended to be used by other, larger systems, I decided to help those larger systems test their dependency on my module: I included a Test::MockObject that mocked my module's interface. By using my test module, the tests can try some data and see if their code works.
But the hardest part to test is always the failures. How do they test if the news service goes down in the middle of a data pull? How about if it goes down between data pulls but still inside the same process? How do they test if the user has input an invalid ID for data?
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.
For a large application, configuration files become a necessity. They help flexible code be used in multiple instances across multiple modules. But they are, for the most part, only data structures, which can be a problem if the configured object is expecting another configured object.