Our Blog

Perl Dancer Conference 2015 Report—​Conference Days

By Josh Lavin
October 30, 2015

In my last post, I shared about the Training Days from the Perl Dancer 2015 conference, in Vienna, Austria. This post will cover the two days of the conference itself.

While there were several wonderful talks, Gert van der Spoel did a great job of writing recaps of all of them (Day 1, Day 2), so here I’ll cover the ones that stood out most to me.

Day One

Dancer Conference, by Alexis Sukrieh (used with permission)

Sawyer X spoke on the State of Dancer. One thing mentioned, which came up again later in the conference, was: Make the effort, move to Dancer 2! Dancer 1 is frozen. There have been some recent changes to Dancer:

• Middlewares for static files, so these are handled outside of Dancer

• New Hash::MultiValue parameter keywords (route_parameters, query_parameters, body_parameters; covered in my earlier post)

• Delayed responses (asynchronous) with delayed keyword:

  • Runs on the server after the request has finished.
  • Streaming is also asynchronous, feeding the user chunks of data at a time.

Items coming soon to Dancer may include: Web Sockets (supported in Plack), per-route serialization (currently enabling a serializer such as JSON affects the entire app—​later on, Russell released a module for this, which may make it back into the core), Dancer2::XS, and critic/linter policies.

Thomas Klausner shared about OAuth & Microservices. Microservices are a good tool to manage complexity, but you might want to aim for “monolith first”, according to Martin Fowler, and only later break up your app into microservices. In the old days, we had “fat” back-ends, which did everything and delivered the results to a browser. Now, we have “fat” front-ends, which take info from a back-end and massage it for display. One advantage of the microservice way of thinking is that mobile devices (or even third parties) can access the same APIs as your front-end website.

OAuth allows a user to login at your site, using their credentials from another site (such as Facebook or Google), so they don’t need a password for your site itself. This typically happens via JavaScript and cookies. However, to make your back-end “stateless”, you could use JSON Web Tokens (JWT). Thomas showed some examples of all this in action, using the OX Perl module.

One thing I found interesting that Thomas mentioned: Plack middleware is the correct place to implement most of the generic part of a web app. The framework is the wrong part. I think this mindset goes along with Sawyer’s comments about Web App + App in the Training Days.

Mickey Nasriachi shared his development on PONAPI, which implements the JSON API specification in Perl. The JSON API spec is a standard for creating APIs. It essentially absolves you from having to make decisions about how you should structure your API.

Panorama from the south tower of St. Stephen’s cathedral, by this author

Gert presented on Social Logins & eCommerce. This built on the earlier OAuth talk by Thomas. Here are some of the pros/cons to social login which Gert presented:

• Pros—​customer:
  • Alleviates “password fatigue”
  • Convenience
  • Brand familiarity (with the social login provider)
• Pros—​eCommerce website:
  • Expected customer retention
  • Expected increase in sales
  • Better target customers
  • “Plug & Play” (if you pay)—​some services exist to make it simple to integrate social logins, where you just integrate with them, and then you are effectively integrated with whatever social login providers they support. These include Janrain and LoginRadius
• Cons—​customer:
  • Privacy concerns (sharing their social identity with your site)
  • Security concerns (if their social account is hacked, so are all their accounts where they have used their social login)
  • Confusion (especially on how to leave a site)
  • Usefulness (no address details are provided by the social provider in the standard scope, so the customer still has to enter extra details on your site)
  • Social account hostages (if you’ve used your social account to login elsewhere, you are reluctant to shut down your social account)
• Cons—​eCommerce website:
  • Legal implications
  • Implementation hurdles
  • Usefulness
  • Provider problem is your problem (e.g., if the social login provider goes down, all your customers who use it to login are unable to login to your site)
  • Brand association (maybe you don’t want your site associated with certain social sites)
• Cons—​social provider:
  • ???

Šimun Kodžoman spoke on Dancer + Meteor = mobile app. Meteor is a JavaScript framework for both server-side and client-side. It seems one of the most interesting aspects is you can use Meteor with the Android or iOS SDK to auto-generate a true mobile app, which has many more advantages than a simple HTML “app” created with PhoneGap. Šimun is using Dancer as a back-end for Meteor, because the server-side Meteor aspect is still new and unstable, and is also dependent on MongoDB, which cannot be used for everything.

End Point’s own Sam Batschelet shared his work on Space Camp, a new container-based setup for development environments. This pulls together several pieces, including CoreOS, systemd-nspawn, and etcd to provide a futuristic version of DevCamps.

Day Two

Conference goers, by Sam
(used with permission)

Andrew Baerg spoke on Taming the 1000-lb Gorilla that is Interchange 5. He shared how they have endeavored to manage their Interchange development in more modern ways, such as using unit tests and DBIC. One item I found especially interesting was the use of DBIx::Class::Fixtures to allow saving bits of information from a database to keep with a test. This is helpful when you have a bug from some database entry which you want to fix and ensure stays fixed, as databases can change over time, and without a “fixture” your test would not be able to run.

Russell Jenkins shared HowTo Contribute to Dancer 2. He went over the use of Git, including such helpful commands and tips as:

• git status –short –branch
• Write good commit messages: one line summary, less than 50 characters; longer description, wrapped to 72 characters; refer to and/or close issues
• Work in a branch (you shall not commit to master)
• “But I committed to master” –> branch and reset
• git log –oneline –since=2.weeks
• git add –fixup
• The use of branches named with “feature/whatever” or “bugfix/whatever” can be helpful (this is Russell’s convention)

There are several Dancer 2 issues tagged “beginner suitable”, so it is easy for nearly anyone to contribute. The Dancer website is also on GitHub. You can even make simple edits directly in GitHub!

It was great to have the author of Dancer, Alexis Sukrieh, in attendance. He shared his original vision for Dancer, which filled a gap in the Perl ecosystem back in 2009. The goal for Dancer was to create a DSL (Domain-specific language) to provide a very simple way to develop web applications. The DSL provides “keywords” for use in the Dancer app, which are specific to Dancer (basically extra functionality for Perl). One of the core aspects of keeping it simple was to avoid the use of $self (a standby of object-oriented Perl, one of the things that you just “have to do”, typically).

Alexis mentioned that Dancer 1 is frozen—​Dancer 2 full-speed ahead! He also shared some of his learnings along the way:

• Fill a gap (define clearly the problem, present your solution)
• Stick to your vision
• Code is not enough (opensource needs attention; marketing matters)
• Meet in person (collaboration is hard; online collaboration is very hard)
• Kill the ego—​you are not your code

While at the conference, Alexis even wrote a Dancer2 plugin, Dancer2::Plugin::ProbabilityRoute, which allows you to do A/B Testing in your Dancer app. (Another similar plugin is Dancer2::Plugin::Sixpack.)

Also check out Alexis’ recap.

Finally, I was privileged to speak as well, on AngularJS & Dancer for Modern Web Development. Since this post is already pretty long, I’ll save the details for another post.

Summary

In summary, the Perl Dancer conference was a great time of learning and building community. If I had to wrap it all up in one insight, it would be: Web App + App—​that is, your application should be a compilation of: Plack middleware, Web App (Dancer), and App (Perl classes and methods).

conference dancer interchange perl