Skip to content

PGDay UK – User Group meeting

2015 July 30

PGDay UK took place at 30 Euston Square on July 7th. The location is perfect as it’s easy to get to via underground, buses or trains.

After the usual registration, refreshments, welcome and introductions came the long-awaited talk “Working in Open Source” by Liam Maxwell, CTO for Her Majesty’s Government. This talk was followed by Magnus Hagander, President of PostgreSQL Europe, who alerted us to the new key features of the next release which is now available in alpha and soon to be available in beta before the final version is released towards the end of the year. Some new key features include:

Magnus Hagander - New features in 9.5

Magnus Hagander – New features

“Upsert” (INSERT … ON CONFLICT): 5 brings support for “UPSERT” operations.

BRIN (Block Range Indexes): BRIN stands for Block Range INdexes, and store metadata on a range of pages. At the moment this means the minimum and maximum values per block.

pg_rewind: pg_rewind makes it possible to efficiently bring an old primary in sync with a new primary without having to perform a full base backup.

Import Foreign Schema: with PostgreSQL 9.5, you can import tables en masse. You can also filter out any tables you don’t wish or limit it to just a specific set of tables

Inheritance with foreign table:  Foreign tables can now either inherit local tables, or be inherited from.

David Kennaway showed us the challenges presented in a financial services environment and how PostgreSQL fits into the strategy at Goldman Sachs.

Mike Lujan from Manchester University talked to us about the AXLE project… but what is the AXLE project? AXLE, advanced analytics for extremely large European databases, brings together a diverse group of researchers covering hardware, database kernel and visualisation all focused on solving the needs of extremely large data analysis. The project partners are 2ndQuadrant, Barcelona Supercomputing Center, Portavita, the University of Ljubljana and the University of Manchester. The project, like PostgreSQL, is of course Open Source.

With “PostgreSQL Back Up and Recovery: Best practices and tools” by Devrim Gunduz, we discovered solutions for common issues along with pros and cons for each of them. There are of course many backup solutions – both open and closed source.

Gianni Ciolli gave us some “PostgreSQL Administration Recipes”. These recipes should enhance the user’s experience of PostgreSQL by making it speedier and more effective.

Marco Slot discussed the internals and performance of pg_shard and some of its latest features. pg_shard is a free, open source extension for scaling out PostgreSQL across a cluster of commodity servers.

In his “Fun Things to Do with Logical Decoding” Mike Fowler looked at trigger-less auditing, partial replication and full statement replication. Was that fun? I am not so sure!

The next talk had a great title – “The Elephant and the Snake” – could it be a story by Rudyard Kipling or one of Aesop’s fables? No, but Tony Locke told us how to connect from Python to PostgreSQL, including tips and tricks.

Simon Riggs - The future

Simon Riggs: The Future

The day ended with a plea from Simon Riggs for users to upgrade and test the new 9.5 release to ensure the version is bug-free, helping the PostgreSQL community currently working on the 9.6 release and beyond.

With around 100 people attending the conference, PGDay UK 2015 was one of the most dynamic PosgreSQL meetings that I have ever attended. The audience was very diverse, coming from universities, big corporations, small companies and government institutions.

Thanks to the sponsors 2ndQuadrant, EDB, Brandwatch and CitusData, we were provided with good food and a drink reception at the end of the day.

Interested in PostgreSQL? Why not come to the PostgreSQL conference Europe 2015, which will take place in Vienna on October 27th to 30th? Hope to see you there!

Pycon Sei (17/19 April) – What’s new in Python or how to enjoy a bunch of friends

2015 April 29

A few weeks ago, I received the most wonderful email – an invitation to attend Pycon Sei in Florence. Who could refuse such an invitation – not me for sure!

IMG_0226

IMG_0162

IMG_0202

IMG_0214

 

 

Florence, the cradle of the Renaissance, home to some of the most classical maestros: Leonardo da Vinci, Michelangelo, Botticelli, Giotto, Masaccio. Florence where you discover the most beautiful buildings: Palazzo Vecchio, Palazzo Pitti, Ponte Vecchio, il Duomo, Santa Croce, San Miniato. At every street corner, you discover some wonderful sights – a statue, a building, a view on the Arno, a look at the street market (mainly leather goods). I could spend weeks there enjoying the views, the food and going mad at the number of tourists! Unfortunately Florence is loved by many people and sometime you feel that you are not going where you want to but you are carried somewhere.

bagIn Italy the Pycon meetings started in 2007 in the centre of Florence and continued until Pycon Quattro – I fell in love with Florence during Pycon Due when Richard Stallman gave a talk at the Palazzo Vecchio. In 2011, Florence held EuroPython – a partnership that lasted 3 years (pretty good when EuroPython had to move on to another city after 2 years). Unfortunately the hotel in the centre could not cope with 1000 delegates and the conference was moved to the Grand Hotel Mediterraneo, a few yards from the Arno and almost opposite to the Piazzale Michelangelo. 2014 saw the return of Pycon with Pycon Cinque. During that year, the Associazione Python Italia with Tinker Garage also organized Django Village. For 2015, they decided to combine the two conferences and produced Pycon Sei with a minimum of 4 tracks: Python, Django, PyData and Odoo. Two training tracks were sometimes added to the schedule. They were: Introduzione a Genropy with Giovanni Porcari; Building an Interpreter in RPython with Julian Berman; Creare la propria PaaS (Platform as a Service) con uwsgi.it with Roberto De Ioris and OOP: Object-Oriented Python partendo da zero with Leonardo Giordani.

Alex M

Alex Martelli

gabriele

Gabriele Bartolini

Lots of the talks were in English. My favourite speaker, Alex Martelli (Google), started the day with Modern Python patterns and idioms first in Italian and later on in English – I do not understand Italian nor Python but to see Alex’s passion is pure magic – all of his body is moving. He is the epitome of Italians, the way we like them and sometime make gentle fun of them. I must admit that his English version of the same talk is not as dramatic, at least not for the technophobe as my admiration is just about the show, the sound, the music. Other good presentations included Asynchronous Web Development with Python 3 by Anton Caceres; PostgreSQL 9.4 for Devops by Gabriele Bartolini; Odoo disaster recovery con Barman by Giulio Calacoci; Does Python stand a chance in today’s world of data science by Radim Rehurek; Packaging Django projects for PyPI by Roberto Rosario and many more.

Saturday saw a recruiting session – it was very interesting to see the different ways that companies will entice new recruits. It went from the big PR spiel to the down to earth approach: that’s the job, that’s what we want from you, that’s what you get from us. Companies hiring are: InfoCert; Zalando, Kuldat, Develer; 2ndQuadrant.

There are no techie conferences without networking and the first event was PyBeer on Friday which took place at the James Joyce Pub. This was an occasion to relax and enjoy the time together drinking, chatting and actually learning to know each other as Pythonistas. To consolidate our new friendships, on Saturday we met at the Ristorante Zazà for PyFiorentina. There you can taste the famous bistecca alla fiorentina – a T-bone steak grilled over a wood or charcoal fire, to be eaten with a glass of wonderful Italian red wine.  Just delicious!

Pycon Italy is organized by the Associazione Python Italia but I know that Develer srl spend a lot of time and resources putting the show together. You can find this lovely company between Prato and Florence. They boost of being a team of developers and design engineers who average age is just over 30 years. All Develeriani are selected through accurate tests and constantly trained to provide the most innovative technologies.

 

All about Mojolicious – interview of Sebastian Riedel part 2

2014 December 3
by Nikos Vaggalis

mojo

 

NV: Does the dependency free nature of Mojolicious act as an invitation to people familiar with other frameworks (i.e. Ruby on Rails) and languages (i.e. PHP)? That aside, what other factors/features would lure such developers to the framework?

SR: The dependency free nature of Mojolicious is actually more of a myth, the truth is that installing Mojolicious is simply a very fast and pleasant experience.

One of the ways in which we’ve done this, is to make hard to install 3rd party modules like IO::Socket::SSL and Net::DNS::Native optional.

I think what makes Mojolicious special is best explained with an example application:

 use Mojolicious::Lite;
 use 5.20.0;
 use experimental 'signatures';

    # Render template "index.html.ep" from the DATA section
    get '/' => {template => 'index'};

    # WebSocket service used by the template to extract the title from a web site
    websocket '/title' => sub ($c) {
      $c->on(message => sub ($c, $msg) {
        my $title = $c->ua->get($msg)->res->dom->at('title')->text;
        $c->send($title);
      });
    };

    app->start;
    __DATA__

    @@ index.html.ep
    % my $url = url_for 'title';
    <script>
      var ws = new WebSocket('<%= $url->to_abs %>');
      ws.onmessage = function (event) { document.body.innerHTML += event.data };
      ws.onopen    = function (event) { ws.send('http://mojolicio.us') };
    </script>
   

This is actually the first example application you encounter on our website (http://mojolicio.us).
It doesn’t look very complicated at all. But once you start digging a little deeper, you’ll quickly realize how crazy (in a good way) it really is, and how hard it would be to replicate with any other web framework, in any language.

To give you a very quick summary:

  1. There’s an EP (Embedded Perl) template, in the DATA section of a single-file web application. That template generates an HTML file, containing JavaScript, which opens a WebSocket connection, to a dynamically generated URL (ws://127.0.0.1:3000/title), based on the name of a route.
  2. Then sends another URL (http://mojolicio.us) through the WebSocket as a text message, which results in a message event being emitted by the server.
  3. Our server then uses a full featured HTTP user agent, to issue a GET request to this URL, and uses an HTML DOM parser to extract the title from the resulting document with CSS selectors.
  4. Before finally returning it through the WebSocket to the browser, which then displays it in the body of our original HTML file.

Next year at Mojoconf 2015, I’ll be giving a whole talk about this one application, exploring it in much greater detail.

NV: It’s a framework that you use in pure Perl. Why not go for a DSL like Dancer does?

SR: There are actually two kinds of web framework DSLs, and they differ by scope.

First, you have your routing DSL, which usually runs during server start-up and modifies application state. (application scope)

    get '/foo' => sub {...};

Second, there is what I would call the content generation DSL, which modifies request/response state. (request scope)

    get '/foo' => sub {
      header 'Content-Type' => 'text/plain';
      render 'some_template';
    };

Mojolicious does have the first kind, and we’ve already used it in the examples above, but not the second. And the reason for this, is that the second kind does not work very well, when you plan on handling multiple requests concurrently in the same process, which involves a lot of context switching. It’s a trade-off between making your framework more approachable for beginners, that might not know Object-Oriented Perl yet, and supporting modern real-time web features.

Which object system is Mojolicious using and which can I use in my code?

Mojolicious uses plain old hash-based Perl objects, and we take special care to allow for Moose and Moo to be used in applications as well.

NV: With Dancer you can easily integrate jQuery and Bootstrap with the templating system. How does Mojolicious approach this integration?

Mojolicious is completely JavaScript/HTML/CSS framework agnostic, and will work with all of them. Some frameworks, including jQuery and Bootstrap, do have plugins on CPAN, but we don’t discriminate.

NV: Mojolicious vs Mojolicious::Lite. When to use each?

SR: I usually start exploring ideas with a single-file Mojolicious::Lite prototype, like we’ve seen above, and slowly grow it into a well-structured Mojolicious web application, which looks more like your average CPAN distribution.

This is a rather simple process, because Mojolicious::Lite is only a tiny wrapper around Mojolicious, and both share like 99% of the same code.

NV: What can we expect in the future and what is the greater vision for the project’s evolution?

Mojolicious has an amazing community, and I hope we can expand on that to reach more people from outside the Perl community in the future. Not a day goes by where I don’t receive requests for a Mojolicious book, so that’s a pretty big priority too.

Feature wise, with the release of the final RFC, I expect HTTP/2 to be a very big topic in 2015.
And hopefully we will get to play more with new Perl features such as signatures, I can’t wait for a polyfill CPAN module to bring signatures to older versions of Perl.

NV: Finally, prompted by the news that Perl 6 will officially launch for production use by 2015, I’d like to hear your thoughts on Perl 6 and if it could or would be used, with or as part, of Mojolicious.

SR: I’ve had the pleasure to see Jonathan Worthington talk about concurrency and parallelism in Perl6 at Mojoconf 2014, and to say that it was quite inspiring would be an understatement.

But “production use” can mean a lot of different things to a lot of people. Is it feature complete? Is it as fast as Perl5? Would you bet the future of your company on it?

I love Perl6 the language, it solves all the problems I have with Perl5, and if there’s an implementation that’s good enough, you bet there will be a Mojolicious port!


nikos1
Nikos Vaggalis has a BSc in Computer Science and a MSc in Interactive Multimedia. He works as a Database Developer with Linux and Ingres, and programs in both Perl and C#. As a journalist he writes articles, conducts interviews and reviews technical IT books

All about Mojolicious – interview of Sebastian Riedel part 1

2014 November 26
by Nikos Vaggalis

mojo

 

 

 

 

Our journey into the world of Perl’s Web frameworks would not be complete without Mojolicious, therefore we talked to Sebastian Riedel, Mojolicious’ mastermind and Catalyst’s original founder.

We looked at Mojolicious’ history: why Sebastian left Catalyst for Mojolicious, present: what does the framework actually do, the project’s future: Sebastian’s long-term plans, and whether Perl6 will have an effect on the project. We also get more technical with questions like why not opt for a DSL like Dancer does, what is meant by ‘real time web framework’, whether the framework is dependency free and much more.

NV: Do you think that now with Mojolicious, Catalyst and Dancer we are experiencing Perl’s newest and most successful Web revolution since the 90’s?

SR: It’s certainly a great time for web development with Perl, and it has been a lot of fun seeing Catalyst and Mojolicious take the Perl community by storm.

But for a real revolution, along the lines of CGI.pm in the late 90s, I think we have to get a lot better at reaching people outside the echo chamber, which is not really a technical, but a public relations problem.

NV: Why did you leave Catalyst for Mojolicious?

SR: Creative differences. At the time I was still experimenting a lot with new ideas for Catalyst, many of which are now part of Mojolicious, but what the majority of core team members really wanted was stability.

So rather than risk harming Catalyst with a drawn-out fight, I decided to leave for a fresh start.
It was very disappointing at the time, but the right decision in retrospect.

NV: Is Mojolicious a MVC framework and if so how does it implement the MVC pattern?

Yes, it is very similar to Catalyst in that regard. But we don’t highlight the fact very much, Model-View-Controller is just one of many design patterns we use.

Out of the box, Mojolicious is Model layer agnostic, and we consider web applications simply frontends to existing business logic. Controllers are plain old Perl classes, connecting this existing business logic to a View, which would usually be EP (Embedded Perl), or one of the many other template systems we support.

NV: There are many web frameworks out there each one targeting various areas of web development. Which ones does Mojolicious address and how does it compare to Dancer and Catalyst?

SR: There was a time when I would jump at every opportunity to learn more about all the different web frameworks out there, searching for inspiration.

But these days there’s actually very little innovation happening, almost all server-side frameworks follow the same basic formula.Some are trying to optimize for projects of a certain size, but it’s mostly just programming languages competing now.

So I only really pay attention to a very small number that is still experimenting with different architectures and technologies, usually written in languages other than Perl. Some recent examples would be Meteor (JavaScript) and Play Framework (Scala).

What’s really important to me with Mojolicious, and what I believe really differentiates it from everything else in Perl, is that we are always trying new things. Like we’ve done with tight integration of WebSockets and event loops, or the ability to grow from single-file prototypes to well structured web applications.

NV: What is the term ‘real time web framework’ referring to? To the capability of doing WebSockets, non-blocking I/O and event loops? Can you walk us through these concepts? Do such features make Mojolicious a prime platform for building Web APIs?

SR: The real-time web is simply a collection of technologies that allow content to be pushed to consumers with long-lived connections, as soon as it is generated. One of these technologies is the WebSocket protocol, offering full bi-directional low-latency communication channels between the browser and your web server.

I’m not actually a big fan of non-blocking I/O and event loops, but they are the tools that allow us to scale.So a single WebSocket server process can handle thousands of connections concurrently.

Sounds rather complicated, doesn’t it? But with Mojolicious all you need are these 9 lines of Perl code, and you have a fully functioning real-time web application :

   use Mojolicious::Lite;
    use 5.20.0;
    use experimental 'signatures';

    websocket '/echo' => sub ($c) {
      $c->on(message => sub ($c, $msg) {
        $c->send("echo: $msg");
      });
    };

    app->start;

You tell me if this makes Mojolicious a “prime platform for building Web APIs”. :)

NV: How easy is to extend the framework with plugins and what are some of the most useful one?

Mojolicious has 415 reverse dependencies on MetaCPAN, so i’d say it is pretty easy to extend. While there are many many good ones, I have a weak spot for Mojolicious::Plugin::AssetPack, which takes care of all those annoying little asset management tasks, like minifying JavaScript and CSS files.

Mojolicious::Plugin::I18N and Mojolicious::Plugin::Mail are also very commonly used, and I guess I should mention my own Mojolicious::Plugin::Minion, which is a job queue designed specifically for Mojolicious.

In the next and final part, Sebastian shares his views on DSL’s, the project’s dependability and the upcoming release of Perl 6 for production use among others.


nikos1
Nikos Vaggalis has a BSc in Computer Science and a MSc in Interactive Multimedia. He works as a Database Developer with Linux and Ingres, and programs in both Perl and C#. As a journalist he writes articles, conducts interviews and reviews technical IT books

Saving money with Open Source software

2014 November 18

“In the end, Postgres looks to me like it’s saving us like 5X in hardware costs as we continue to grow.”

This comment  was published on Redit about an article that compares PostgreSQL with MS SQL Server. I will not join the raging battle between the two clans and I am leaving the field to those who know best.

This article made me rethink the reasons why I like Open Source.

Why do I like Open Source?

This might be a very romantic view but I still believe people are good at working together for the benefit of our society.  So what is Open Source? Open Source software is software whose code can be modified or enhanced by anyone.

Born from a grassroots movement, Open Source brings:

  • Collaboration between people who may never meet but have the same vision
  • Delivery of lower cost products as there are no big companies or shareholders behind the projects
  • Strong motivation from individuals who have a huge interest in writing code, making other members of the community enthusiastic about their projects
  • Flexibility as individuals make improvements which are then made available to the public

For all these reasons and a lot more, PostgreSQL is a good example of Open Source software and its movement. For example, 2ndQuadrant employees are significant contributors to the development of PostgreSQL with many of the features found in the current version developed by their people. Their latest addition is BDR (Bi-directional replication), an extension to PostgreSQL, free and Open Source which will be integrated to future versions of PostgreSQL.

Will Open Source saves us money? That I suppose will be the question for many years to come?

Bi-Directional Replication or Asynchronous multi-master replication for PostgreSQL

2014 July 11

As mentioned in my last post, I went to CHAR(14). There I learnt about Bi-Directional Replication (BDR).  BDR is an asynchronous multi-master replication system for PostgreSQL, specifically designed to allow geographically distributed clusters. Supporting up to 48 nodes (and possibly more in future releases) BDR is a low overhead, low maintenance technology for distributed databases.

BDR Basic Schema3_display

BDR is created by 2ndQuadrant and is the first of several replication technologies the company will announce this year to dramatically enhance PostgreSQL. Features of BDR have, and will continue to be moved into future releases of PostgreSQL. It is well-known that 2ndQuadrant develop code that all users of PostgreSQL can benefit from. The company has a long history of advancing the development of PostgreSQL, and specifically is accredited with making improvements to replication techniques.

2ndQuadrant’s CTO, Simon Riggs, commented: “BDR is a major enhancement to replication design and, with up to 48 master nodes supported, it offers a significant opportunity to reduce the overhead and headaches experienced with previous approaches to replication. For any organisation with distributed PostgreSQL databases replicated across multiple master nodes, BDR should be seriously considered.”

BDR is available as open source software, direct from 2ndQuadrant, with consultancy and support contracts available to ensure users can successfully design and implement a stable replicated environment. 2ndQuadrant’s Production Support service provides direct help from the development team behind BDR.

The company has been working with a number of early adopter clients, including BullionByPost®, and a leading antivirus software developer, to fine tune and evaluate BDR in demanding environments, ahead of this announcement.

I forgot to say that BDR, an extension to PostgreSQL, is free and open source; licensed under the same terms as PostgreSQL. PostgreSQL is released under the PostgreSQL License, a liberal Open Source license, similar to the BSD or MIT licenses.

You can get a lot more information on the website –

There you can also describe your replication requirements or sign up for the quarterly Newsletter.

 

From books to software

2014 June 18
by Josette Garcia

logo_color-(JPEG)_display2I have some exciting news to share – I have joined 2ndQuadrant as Community Manager. It is a rather different role for me even though I have been working with the Open Source community for years – Perl, Python, PHP, Linux have no secrets but then why am I so nervous?  Could the reason be that a book is a very physical thing and even though I did not understand the content, I could always grab one and read the preface or about the animal on the cover. Software for a non-techie is rather elusive, full of mysteries –can’t see anything, can’t touch anything but I am sure I will get used to it.

Why 2ndQuadrant?

  • You guessed 2ndQuadrant work with the Open Source community and provide lots of add-ins to PostgreSQL which are free for everyone to work on.
  • I like the philosophy of 2ndQuadrant as a big part of the revenue is ploughed back into the community.
  • It is a worldwide company with offices in US, UK, France, Italy, Germany, Nordic region and South America.
  • Collectively 2ndQuadrant provide over 100 man years of PostgreSQL expertise in all areas of the Database Lifecycle Management process.

First days out

I will be attending the following conferences:

  • CHARChar(14), Milton Keynes, 8th July – for anybody interested in  Clustering, High Availability and Replication and much more. 2ndQuadrant and Translattice will be presenting the important new technologies of BiDirectional Replication (BDR). BDR will be explained in more details offering you the first opportunity to understand how it works and understand what implementation options are available – directly from the developers.
  • PG Day LogoPGDay, Milton Keynes, 9th July – With talks on PostgreSQL features in 9.4, Migrating rant & rave to PostgreSQL, Business Intelligence with Window Functions, New BI features from the AXLE project and much more, PGDay focuses on bringing PostgreSQL users to a whole new level of understanding. It will cover the core topics you need to be successful with PostgreSQL and will give you the opportunity to network with fellow users.

“My community”

If the members of your User Group, colleagues from your Company or Institution are interested in PostgreSQL, please let me know as I would like to build a bigger, stronger community around this database.  Also please let me know of any conferences, events we should attend or anything else I should look into.  You will find my email on the “About Me” page.

All about Dancer – interview of Sawyer X part 3 and last

2014 May 14
by Nikos Vaggalis

dancer-logoNV: Dancer and web services, where do I start ? Conceptually, is REST only about web services ?

SX: While REST (REpresentational State Transfer) is not limited to web services, it’s most widely used in that context. It’s a declared structure with which you can define and provide a consistent and understandable web service.

As Dancer tries to be opinionated in moderation, it provides a plugin (Dancer::Plugin::REST and Dancer2::Plugin::REST) to help you go about defining RESTful routes. It helps you to easily define resources in your application so you get serialization and routes easily set up.

Sometimes it’s hard for me to get used to new tools, so I haven’t used that plugin yet. I generally define my own paths for everything. While I suggest you take a look at it, I should probably do the same.

NV: What’s in the project’s wish-list, where is it heading at, and what can we expect in the future?

SX: We’re focusing on several issues at the moment, which all seem to be congruent with each other: transition users to Dancer 2, overhaul the documentation, improve our test coverage, further decouple internal entities, streamline our coordination, and strip code further.

We’ve made a lot of progress recently, much of it thanks to new core members, and more corporate companies (such as Booking.com) sponsoring hackathons, allowing us to focus more time on these. The attention we receive from our community is invigorating, and pushes us to continue work on the project, and invest time in it. It gives us an insight on how worthwhile it really is, and it makes our work a pleasure.

NV: Perl vs PHP vs Ruby vs language X, for the web. Why Perl has fallen out of favour with web devs and what can be done about it?

SX: While I have been working with Perl for a long while, and started back when CGI was pretty much it, others have much more experience, and might be able to answer this question better than I can. This is my rough reasoning, and I may be completely off on this.

I believe the downfall of Perl as the dominating web language was due to our apathy at the time. As soon as we ruled the web with CGI we were lulled into a false sense of security in that position. In the mean time, other languages were trying to get their bearings and come up with something that could compete with it. It took some time, but they came up with better things, while we pretty much stalled behind.

WSGI was done in Python. Then Ruby’s Rack came around. It took some time until we realized those were good and we should have that too, finally provided by Miyagawa as PSGI/Plack. Now our problem is that a lot of people are still not moving onwards to it, and are stuck with arcane methods of web programming, not understanding the value of moving forward.

It’s important to remember that no single language can truly “rule” the web anyway. Perl had its glory days, and they are over. Then PHP had its, and it was over as soon as people realized PHP is not even a real language, and so happened with Ruby and with Rails. Others will have their turn for 15 minutes of fame, and that will be over as well. We will eventually end up with multiple languages (and PHP) and a multitude of web programming abilities, which is a bright future for all of us – except those who will have to work with PHP, of course.

The crucial bit is not to stay behind the curve on new developments, and to push to create new things where appropriate. We shouldn’t just relax with what we have, we should always demand more of ourselves and try and create it, and not wait for other languages to say “hey, this sucks, let’s try fixing it”. That’s what we’re known for, so let’s get back to that.

NV: Your “CGI.pm must die” talk has gone viral. Is CGI.pm really that bad ?

SX: CGI.pm wasn’t the module we deserved, but the module we needed. At the time, it was the best thing that happened for Perl and for the web. However, those days had passed. Unfortunately, while Perl evolved, some people stayed at the decade of CGI.pm. We won’t reach far if we’re still sticking to the best and latest of 1995. Some of us are quite literally stuck in the previous century, it’s not even funny. Well, it is a bit. It’s also sad.

People often ask me “is CGI.pm that horrible?” and the answer is that, in all honesty, yes, it really is! But that’s not why I go completely apeshit about it. If I may quote a great poet, “it’s about sending a message”. If I would have given a talk entitled “use PSGI/Plack”, it wouldn’t stick as much as suggesting to kill a module with fire, now would it?

We should all be thankful to Lincoln D. Stein who gave us CGI.pm, and now retire it in favor of PSGI/Plack. I had received an email from Lincoln saying he watched the talk I gave, enjoyed it (which was a great honor for me), and fully agrees with moving forward. And while we’re moving onwards to bigger and better, we should check out the new stuff Lincoln has been working on, like his VM::EC2 module.

NV: Would you someday consider switching from Perl 5 to Perl 6? If so, what are your thoughts on Perl 6 and given the opportunity, would you someday re-write Dancer in it?

SX: I would love a chance to work with Perl 6 in a professional capacity, but I don’t see it in the near future. It’s a shame, because, in my opinion, it’s by far the most innovative and interesting language available today.

We’ve all been hoping Perl 6 will hit the ground running, and it took some time to realize it isn’t that simple. However, nowadays Perl 6 interpreters have been releasing regularly, and there’s work being done to get Perl 5 and Perl 6 closer, both community-wise and technically-wise.

Some amazing ideas came out of Perl 6, some of which were ported to Perl 5, some of which successfully. When it comes to language features and ability, Perl 6 has done a lot of right, even though it also made several mistakes. Hindsight is 20/20, and if we could go back, things would have been done differently. All in all, I think it’s best for us all to concentrate on the current state and the future – and those look bright.

I will likely not have to rewrite Dancer in Perl 6 because a bare-bones Dancer port has already been written by tadzik (Tadeusz Sosnierz) called Bailador. I haven’t looked at the internals too much, so I’m not sure if the design flaws we had to deal with exist there too. Either way, I’m certain it’s in good hands, and I hope that in the future I will be able to contribute to that.

I just want to add one last note, if I may. I want to thank our community, who push us closer together, while pushing us to work harder at the same time. It’s a great joy and delight. And I want to also thank the core team for being a wonderful gang to work with, each and every single one. And I’d like to thank you, for giving me the opportunity to talk about Perl and Dancer.

nikosNikos Vaggalis has a BSc in Computer Science and a MSc in Interactive Multimedia. He works as a Database Developer with Linux and Ingres, and programs in both Perl and C#. He writes articles, conducts interviews and reviews technical IT books

All about Dancer – interview of Sawyer X part 2

2014 May 2
by Nikos Vaggalis

NV: Is Dancer 2 a complete re-write and why? what shortcomings of the first version does it address ?

SX:Dancer 2 is indeed a complete rewrite of the code, and for good reason.

Dancer started as a fork of a fun web framework in Ruby called Sinatra. The founder of Dancer, Alexis Sukrieh, being a polyglot (programming in both Perl and Ruby), had used Sinatra, and wished to have a similar framework in Perl.

As Dancer evolved through its users and community, gaining numerous additional features, it became apparent that some of the original design decisions regarding architecture were a problem. Specifically, engines, which are the core tenants of Dancer, are all singletons. This means every Dancer subsystem (and consequently, every code you write in Dancer in the same process) will share the same engine.

An interesting example is the serializer. This means that one piece of code in which you want automatic serialization would require all your other pieces of code to work with serialization. You cannot control that.

When we realized we could not force Dancer to do the right thing when it came to engines, we resorted to rewriting from scratch. This allowed several improvements: using a modern object system (Moo), having contextual engines and DSL, and decoupled mini-applications, called Dancer apps.

NV:There is a lot of talk on Plack/PSGI. What is it and what is the advantage of hooking into it ?

SX:PSGI is a protocol, which means it’s literally a paper describing how a server and application should speak to each other. It includes the parameters each expects and how they should respond. In essence, it’s an RFC for a new standardized protocol.

Plack is a set of tools for writing PSGI applications and servers. We can use Plack as reference implementation, or as actual utilities for working with any layer of the PSGI stack, whether it’s the server or the client.

PSGI, inspired by Python’s WSGI and Ruby’s Rack, has many qualities which rendered it an instant success: it’s simple, understandable, works across web servers, includes advanced features such as application mounting, middlewares, long polling requests, and even asynchronous responses.

This deemed Plack/PSGI a solid foundation for writing web servers and web frameworks. All major web frameworks in Perl support PSGI, and many web servers started appearing, offering ranges of features from pre-forking to event-based serving: Starman, Twiggy, Starlet, Feersum, and many more.

NV:What functionality do I get out of the box and what tasks does Dancer take care of for me so I don’t have to? For example does it include measures of preventing XSS attacks or SQL injection? Or implementing a variety of authentication schemes?

SX:Dancer attempts to be a thin layer over your application code. It provides keywords to help you navigate through the web of… web programming. :)

If you want to define dispatching for your application paths, these are our routes. If you want to check for sessions, we have syntax to store them and retrieve them across different session storages. If you need to set cookies, we have easy syntax for that.

The idea with Dancer is that it gives you all the small bits and pieces to hook up your application to your web users, and then it vanishes in the background and stays out of your way.

We make an effort of making sure we provide you with code that is flexible, performant, and secure. We take security patches seriously, and our code is publicly available, so security audits are more than welcome.

NV:Plugins and extensibility. How easy is to extend the DSL, consume CPAN modules, hook plugins into it ? What are some of the most useful plugins that I can choose from? (engines for template,session,authentication,dbms etc)

SX:When you call “use Dancer2″ in order to write your web code, DSL is generated explicitly for your scope. It can be different than another scope. The reason for this is so you could use modules that extend that DSL. This is how plugins work.

It’s very important to note that we promote using Plack middlewares (available under the Plack::Middleware class), so your code can work across multiple web frameworks. Still, there are quite a few Dancer plugins to achieve various tasks through Dancer.

There is a list of recommended modules in Task::Dancer and here are a few I would recommend checking out:

  • Dancer::Plugin::REST – Writing RESTful apps quickly
  • Dancer::Plugin::Database – Easy database connections
  • Dancer::Plugin::Email – Integrate email sending
  • Dancer::Plugin::NYTProf – Easy profiling for Dancer using NYTProf
  • Dancer::Plugin::SiteMap – Automatically generate a sitemap
  • Dancer::Plugin::Auth::Tiny – Authentication done right
  • Dancer::Plugin::Cache::CHI – CHI-based caching for Dancer

NV:What about dependencies to third party components? is it lightly or heavily affected?

SX:I love this question, because it allows me to talk about our lovely community.

We try to be community-oriented. Our community is what fuelled Dancer from a simple web dispatching piece of code to a competitor for full-fledged production websites and products.

The original assumption with Dancer was that dependencies are a problem. While it is possible to reinvent the wheel, it comes at a cost. We tried to balance it out by having as few dependencies as possible, and reinventing where needed.

With time, however, the community expressed a completely different view of the matter. People said, “we don’t give a damn about dependencies. If we can install Dancer, we can install dependencies.”

By the time Dancer 2 came around, we already had so many ways to install dependencies in Perl, that it really wasn’t a problem anymore. We have great projects like FatPacker, local::lib, carton, Pinto, and more. This allowed us to remove a lot of redundant code in Dancer, to make it faster, easier to handle, more predictable, and even add features. The community was very favorable to that, and we’re happy we made that decision.

So our current approach is “if we need a dependency, we’ll add it”. Last release, actually, we removed a dependency. We just didn’t need it. Our current stack is still relatively small. I think we have a balance, and we’re always open to more feedback from the community about this.

I’ll take every chance to talk about how the community is driving the project. :)

nikosNikos Vaggalis has a BSc in Computer Science and a MSc in Interactive Multimedia. He works as a Database Developer with Linux and Ingres, and programs in both Perl and C#. He writes articles, conducts interviews and reviews technical IT books

All about Dancer – interview of Sawyer X

2014 April 25
by Nikos Vaggalis

dancer-logoAfter we looked into Catalyst, we continue our exploration of Perl’s land of Web Frameworks, with Dancer.

We talk about it to one of the core devs, Sawyer X, who kindly answered our questions in a very detailed and explanatory way, rendering the interview enjoyable and comprehensible even by non techies.

The interview, which spans three parts (to be published weekly), did not stop there however; we also asked his opinion and knowledge on finer grained aspects of the craft that is developing for the Web, such as what the advantage of routing over query strings is, MVC vs Routes, Perl vs PHP vs Ruby, and why CGI.pm must die!

NV:The term might be overloaded, but is Dancer a MVC or should I say a “Route” based framework ? what’s the difference?

SX:Usually MVC frameworks are defined by having a clear distinction between the model (your data source, usually a database), the view (your display, usually a template), and the controller (your application code).

While Dancer helps you to easily separate them (such as providing a separate directory for your templates called “views”, by default), it doesn’t go as far as some other frameworks in how much it confines you to those conventions.

I like to describe Dancer as “MVC-ish”, meaning it has a very clear notion of MVC, but it isn’t restrictive. If you’re used to MVC, you will feel at home. If you’re not, or don’t wish to have full-fledged MVC separation, you aren’t forced to have such either.

Most web frameworks use – what I would call – namespace-matching, in which the path you take has an implicit translation to a directory structure, a function, and the optional arguments. For example, the path /admin/shop/product/42 implicitly states it would (most likely) go to a file called Admin/Shop.pm, to a function called product, and will provide the parameter 42 to the function. The implicit translation here is from the URL /admin/shop/product/42 to the namespace Admin::Shop::product, and 42 as the function parameter.

Route-based frameworks declare explicitly what code to run on which path. You basically declare /admin/shop/product/$some_id will run a piece of code. Literally that is it. There is no magic to describe since there is no translation that needs to be understood.

NV:What is the advantage of routing and why the traditional model of query strings is not enough?

SX:The route-based matching provides several essential differences:

  • It is very simple for a developer to understand
  • It takes the user perspective: if the user goes to this path, run this code
  • It stays smaller since it doesn’t require any specific structure for an implicit translation to work, unlike namespace-matching

The declarative nature of route-based frameworks are quite succinct and dictate which code to run when. As explained, you are not confined to any structure. You can just settle for a single line:

get ‘/admin/shop/product/:id’ => sub {…}

This provides a lot of information in a one line of code. No additional files, no hierarchy. It indicates we’re expecting GET requests which will go to /admin/shop/product/:id. The :id is an indication that this should be a variable (such as a number or name), and we want it to be assigned the name id so we could then use it directly. When that path is reached, we will run that subroutine. It really is that simple. We could reach that variable using a Dancer keyword, specifically param->{‘id’}.

NV:Dancer is a complete feature-rich DSL. Does this mean that I write code in a dedicated language and not Perl?

SX:All the web layer done through Dancer can be done in the DSL, but the rest of your application is done in Perl. Dancer just provides a comfortable, clean, beautiful language to define your web layer and to add parts to it (like cookies, different replies, template rendering, etc.). In Dancer2 the DSL is built atop a clean object-oriented interface and provides nice keywords to it.

That is really what a web framework should do: provide a nice clean layer on top of your application.

I guess a better way would be to say you write your code in Perl with dedicated functions that look nicer. :)

NV:There are many web frameworks out there each one targeting various “problem” areas of web development. Which ones does Dancer address?

Dancer provides a sane thin layer for writing stable websites. It introduces relatively few dependencies, but doesn’t reinvent everything. It uses sane defaults and introduces basic recommended conventions, but isn’t too opinionated and remains flexible in the face of a multitude of use cases.

NV:What about the other Perl frameworks, Catalyst and Mojolicious? How do they compare to Dancer?

SX:Catalyst, as great a framework as it is, is pretty big. It uses an enormous amount of modules and clearly very opinionated. This is not necessarily a bad thing, but it might not be what you’re interested in.

Mojolicious pushes the boundaries of HTML5 programming, proving all the eye-candy features HackerNews buzzes about, and is very successful at that.

Dancer fills in the niche between those. It provides a stable base for your website. It does not depend on as many modules, but it does not reinvent every single wheel in existence. It’s the “oh my god, this is how my production websites now look like!” call of gleeful cheer. :)

nikosNikos Vaggalis has a BSc in Computer Science and a MSc in Interactive Multimedia. He works as a Database Developer with Linux and Ingres, and programs in both Perl and C#. He writes articles, conducts interviews and reviews technical IT books