Perl Dancer Conference 2015 Report—Conference Days
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.
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.
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:
- Alleviates “password fatigue”
- 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
- 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
- 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:
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.
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.
- 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)
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.
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).