Thoughts while changing the API of a massive framework...


Originally posted as: Thoughts while changing the API of a massive framework... on

At the Bank we have a home-grown ETL framework that we've been using for quite some time. We recently completed a total rewrite, but unfortunately we left out a few changes. Had I gotten those changes in 5 months ago, I would have only had to break the API of about 10 modules. Today, in order to make those changes, I have to break the API of 122 modules.

What follows is an account of this ordeal, provided for entertainment value only. There will be a future post that explains some of the things I did to make this task surmountable.

Continue reading Thoughts while changing the API of a massive framework......

Chicago.PM - Dependency Injection (also: Beam::Wire)


Originally posted as: Chicago.PM - Dependency Injection (also: Beam::Wire) on

At this month's Chicago.PM meeting, I gave a presentation on Dependency Injection and my new module, Beam::Wire.

[EDIT: The presentation doesn't appear to work on mobile devices. I'm trying deck.js, and I'm not sure I like it.]

Continue reading Chicago.PM - Dependency Injection (also: Beam::Wire)...

Chicago.PM - Mojolicious


Originally posted as: Chicago.PM - Mojolicious on

February's meeting was about the Mojolicious Web Framework. Joel Berger has written a minimal Perl CMS called Galileo, and agreed to give a talk about the benefits of Mojolicious.

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:

  • Websockets
  • 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).

Testing is a Feature of Your Service


Originally posted as: Testing is a Feature of Your Service on

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?

Continue reading Testing is a Feature of Your Service...