London Perl Workshop 2012

I am happy that I had the opportunity to be present at what I think is the second most important European Perl conference: the London Perl Workshop. I'll try to describe the short but intense journey in a way that will convince even more people to be present in the future.

We were 19 members of cluj.pm present at LPW - I think we were the second largest mongers group (after the london mongers, of course) and this wouldn't have been possible without the support from Evozon who paid half of our expenses. We woke up at 4 am (2 am - London time ) and we were all at the airport at 5:30 am. After a flight of about 3 hours (the landing was delayed because the foggy weather in Luton) and another 1 hour trip with the train from Luton, we were finally in London at 9:30 am (London time). We reached Westminster University (the avenue of the London Perl Workshop) around 10:30.

London Perl Workshop - Talks

First talk I attended was Documentation For Fun And Profit - presented by James Aitken (‎LoonyPandora‎). It was a nice reminder why we have to write documentation. What I liked most was his point regarding profit: "If one has to choose between two software solutions, he will likely chose the one that is more documented, even if it is not necessarily a better solution".

Next, it was Aaron Crane's Calamitous Context: Stop Breaking My Code!. As he mentioned himself in the presentation, many of the ideas he presented were inspired by Damian's Conway Perl Best Practices. The conclusion I left was that my programming style - returning either an array ref, either using an empty return is good enough (as Aaron pointed out there are cases when returning an array ref adds more complexity to the code that processes that result - but I think that the headaches avoided by using only scalar contexts for function calls is definitely worth that extra complexity ). It was nice to have an addendum to Damian's chapter and definitely worth spending my time watching Aaron. 

Matthew Bloch showed us the architecture behind Bytemark's BigV cloud platform. It was a little too much information for me to grasp at that time of the day and I am waiting for the supporting slides to made public to re-read the stuff that I missed.

Yandex.Direct (the equivalent of Google Adsense in Russia, Ukraine, Kazakhstan  and Turkey) showed us more of their Perl toolbox by having Elena Bolshakova talking about Looking into the program. It was a nice talk, but I think Elena focused too much on the already existing debugging cpan modules instead of talking more about Devel::YCallTrace - a debugging/profiling/tracing module that seems to fill the gaps and unite in a single place all the nice features that existing packages offer separately.

DuckDuckGo (a newcomer, but important player in the search engine world industry) had Torsten Raudssus (‎Getty‎) talking about Moving the needle or what I (should have) learned at DuckDuckGo. This was a business oriented presentation - for software developers. The main idea is that us, developers, should focus on bringing more business value to the product, rather than on the number of features that a project has. I liked the explanations for 2 of duckduckgo's increases in number of users - they were both unrelated to product features:

• one took place when they placed a billboard on the road that goes to Google's headquarter
• the other one (the big one, marked by point J in the graph) took place when Google changed their privacy policy (when they demanded that they'll use their users data however they want)

It followed the lunch break. It was longer than an hour, and the meal was pretty expensive (about 8 pounds for a shaworma with fries) but it was well worth - I took these pictures of myself and some of my colleagues on the famous Oxford Street:

The conference started abruptly after my extended launch break with Matt S Trout (MST) talking about Fast, furious, fatpacked and fun. As always, it was a pleasure watching Matt presenting. I liked most the way he implemented the generic and reusable request dispatchers for the supporting framework behind shadowcat's blog.

It followed the discussion about The state of the Perl jobs market. The conclusions were that there is a high demand for Perl developers on the market (only in that room there were people who needed more than 40 Perl devs right away). Interestingly enough, employers don't need the candidates to know Perl, they have programs to (cross) train them. We also found out that it seems there is also a good side of the fact that Perl is not so popular anymore: there are not so many self taught (many having low programming skills) developers like in the world of PHP and recently Ruby and Python. 

This means that employers have smaller chances to hire bad devs. Also, the scarcity of Perl developers makes our payment rates to be higher than Ruby, PHP or Python developers.

From the lightning talks, I found out that the UK's government is an open source contributor, having a public github profile, and working with Perl.

Visiting London.

Taking into consideration that we were supposed to be back in Cluj on Sunday, and the tight schedule, I thought we won't be able to see anything in London. Happily I was mistaken and we got to visit quite much.

As a general point of view, London is impressive - there is no single thing that I could say that had left me bad feelings: the buildings are clean and very well conserved, the streets are very clean (although there are rather few bins), there are virtually no cars parked on the sidewalks and the traffic is light (probably because it was Saturday and because of the tax that drivers have to pay for circulating inside the city). 

Prices are high for food (8 pounds for a shaworma) and transportation (4.3 pounds for a subway), but low for clothes (I could find known branded clothes cheaper than in Romania).

Because, we couldn't take part in the post conference social event, AND visit London, I skipped the social event, teamed with Tudor, Adela, Florentina and Diana and took a fast walk through London:

I'd like to say thanks to Mark Keating and all the volunteers involved in organizing this great event and also to Mircea Patachi who had the idea of replacing Evozon's semester Perl department team building with this trip to LPW, and also implementing it.

When we got back home, I had the pleasant surprise to find out that Cluj-Napoca won the competition and will be European Youth Capital in 2015 - congratulations to Democratic Liberal Party and especially Emil Boc for all the efforts you've made to make this possible. I think this is a good sign and hope that Cluj will become the European Capital of Culture in 2021.

Read More

Repainting the Monastery

Every time I search for something related to Perl, I stumble upon the Perl Monks site - I stay as little as possible on the site, because I can't stand how it looks - everything is too cluttered.

I feel like I am this guy

travelling 20 years back in time. My opinion is that everything that is more than 10 years old in IT is completely irrelevant and the Perl Monks site looks like it was build in '95.

Besides the aesthetics, there are also ergonomic issues that makes me want to run away:

• the fonts are too small - my eyes hurt if I stay on the site for too long
• the code snippets font is even smaller - sometimes I find myself copy/pasting from the site in notepad in order to comfortably read the code 

We, the Perl community, are trying in many ways to attract fresh brains among us - with sites that look like Perl Monks is looking now, we just scare them away. 

I don't want to be misunderstood, Perl Monks is one of the biggest diamonds in the Perl's tiara. We should make it sparkle. It already attracts the views of thousands of people because of the high quality brain capital that its member bring in. We can and should make those thousands of people feel good when talking and reading about Perl.

This is how Perl Monks looks right now:

In about 2-3 hours of HTML forging and with the help of Bootstrap from Twitter, I made it look like this:

The beautiful part is that, by simply changing the referred css file you get quite different aspects of the site. Of course, this is what's supposed to happen with a CSS file. But the fact that so many people are using Bootstrap means that there are lots of CSS themese available out there.

Bootswatch offers open source bootstrap themes, and Wrapbootstrap offers paid ones.

Have a look at the links below and see how the Perl Monks would look on Bootstrap:

• Default Bootstrap the theme in the screenshot
• Cerulean theme from bootswatch this is the closest in colors to the actual Perl Monks look
• Superhero theme from bootswatch
• Readable theme from bootswatch

What do you think, would it be worth the effort to change the look of the Monastery?
Wich of the themes do you like more?

Read More

Mojolicious Boilerplate Evolution

A while back I wrote about the awesomeness of Mojolicious with Bootstrap from Twitter.

I was then introducing the Mojolicious Boilerplate - a light github repository which is meant to give a head start to any Perl developer who wants to create modern, shiny, good looking (Bootstrap) web apps in simple, logical, easy to learn and really, really fast manner (Mojolicious).

I didn't knew if other Perl developers will share my enthusiasm regarding this combination, but it seems that you  did. I think that the most important factor that helped this idea to get traction is the fact that Gabor Szabo also considered this combination (Mojolicious + Bootstrap)  as one with good potential, so my introductory article got published in the issue 34 of Perl Weekly Newsletter.

There are now 2 months since I first added code to the repository and the statistics are:

• 33 people are watching the repository
• 5 of them forked it
• 2 contributors (they both sent patches this week, thank you Tudor Crisan and Christian Sturm for helping)

As I said earlier, I wanted this repository to be just a starting point for web application development, but it seems that now it's also used as a starting point for learning new technologies like Behavior Driven Development with Perl, Mojolicious, Bootstrap and (not quite bleeding edge, but very useful) working with github and deploying on dotCloud (I'll write about this soon).

Since it started, some new and shiny features were added to the Boilerplate:

• configurable application menu
• easy ways to send custom notifications to the UI from the application 
• examples of working with sessions
• example of testing with BDD (tests which are working now thanks to the patch sent by Tudor Crisan)
• configurable google analytics tracking code
• a velociraptor as the .ico image (one of the features I like most)

The main vision for the Mojolicious Boilerplate is to keep it as simple and as light as possible while adding as many general purpose features as possible. 

If you reached this far reading this article, please consider giving your feedback on the following:

• How would you want to see the Boilerplate evolving?
• What do you consider as a must have for the Boilerplate and what do you want as nice to have ?

The things I want to do next in order to make the Boilerplate as usable as possible are:

• Add more documentation
• Split the already existing documentation in pages/sections
• Integrate this documentation in the Boilerplate itself in order to let the developer get the docs upfront when he/she clones/forks the repo
• Document the deployment on dotCloud process
• create a Mojolicious application generator that will generate a reduced form of the boilerplate
• create Mojolicious generators for resources (based on some DBIx::Class models or something)
• many many more that I don't remember right now

Read More

The cost of technical debt: 3.61$ / line of code

We've all heard of all kinds of metaphors regarding technical debt, but until recently, I never knew of any study that could put a price tag on it.

 I guess I'm not the only one unaware of the existence of such a study because I've heard of developers almost crying (before flying away from there) because businesses are not keen on writing tests or refactor code, mainly because the cost of this walk on thin ice is not quantifiable in money.This is an issue of the past, because this study from CAST exposes millions in very well hidden IT costs.Some conclusions from the above article:

• technical debt costs companies $3.61 per line of code
• outsourced and in-house developed applications didn’t show any difference in structure quality
• neither did onshore and offshore applications
• established development methods such as agile and waterfall scored significantly better in structural quality than custom methods
• waterfall scored the highest in transferability and changeability (a surprise from my point of view)
• government systems tend to be the lowest in maintainability (I thought this was expected only in Romania)
• the more frequently the code is released the higher the technical debt (another surprise for me)

In recent years I've seen an increased interest from companies in paying for QA - rapidly moving from manual testing to more automated testing.

I believe that until recently (the last 5-10 years), since most applications were desktop based, an app was either rewritten in its entirety in order to make it look&feel modern, or replaced by a competing, good looking one. 

Since the web got traction, a company gets a much lower cost in just changing the UI and keeping adding features in the backend than rewriting the whole app. 

One issue with this, is that there are pretty small chances that code that is 10+ years old is up to date with the latest technologies (like for example, using Memcached for keeping context). 

Every developer that has to interact with that code, has to work like 10+ years ago - what developer wants that? (maybe COBOL developers, who might consider code of that age as being bleeding edge )

On the other hand, 10+ year old code brought money and it still does - who would risk the business in order to rewrite that? (I wouldn't allow such a risk on my software)

The solution is to have unit tests for all the code you intend refactor so that you can be almost sure that the changes you make don't have negative side effects.

Is this a personal impression or we really getting an ascending trend regarding automated testing?

Update:

This post is mentioned in the Perl Weekly Newsletter - there Gabor asks some good open questions regarding potential conclusions like what should we do :

• Throwing away the old and partially broken code?
• Adding automatic tests to the existing application? 
• Nothing?

I'd conclude, that first of all, we should have a general impression regarding the price we have to carry on with us because of the technical debt. I have written a follow-up article regarding possible ways to get a cost for technical debt in Perl . 

I think it is possible to get an application to a stage in which is much more profitable to rewrite the whole application or parts of it instead of continually paying interest for the debt. 

With a technical debt calculator, we could take much more pertinent decisions to questions like:

• Is it profitable going on like this, or we should do a rewrite?
• Why we pay so much for maintenance instead of bringing new features to market?
• Why in the early life of the application 2 developers were bringing 3 features per week, and now, 5 developers get out 2 features in 3 weeks?

And the questions could go on and on.

Read More

Perl Teasing Challenge

I am pretty new to Perl - will have 2 years in August 2012 - and I am in love with it. From those 2 years, I spent 8 months on a project which although was written in Perl, was in maintenance mode and I didn't have to code too much.

 I feel guilty and some kind of selfish because I don't have a short list of stuff that, showing to other developers would persuade them into start using Perl and finally making them reach the euphoria and Zen that we, the Perl Monks, have.

Having read Gabor Szabo's post I recalled to create this teasing short list of stuff that Perl will offer you.

So, if I were to create a Perl promotional presentation (a thing I hope I'll be get the time to do in the near future ) I'd go like below

The Structure of the Promo Presentation

• don't delve too deep into the syntax and only show the different type of variables that Perl has.
• reference some of the many freely available Perl Tutorials
• show some easy to understand yet useful Perl one-liners. Get inspired from this list
• introduce the often imitated(ruby gems, python's PyPI) but never duplicated CPAN

Go on with practical, hands on stuff

• the law mandates a scraping example in absolutely every Perl presentation
• going with yet another Perl trend setter WWW::Mechanize is a safe bet
• scrape the site in parallel with Parallel::ForkManager and your audience will start salivating
• keep the coolness on the ascending trend and include a demo of how straight forward it is to integrate popular services - for example the Google Spreadsheets API, with Net::Google::Spreadsheets
•  you could create a Spreadsheet form and use your Perl script to give an aggregated overview of the answers 

After showing the above, your audience should be pretty convinced that Perl has a great power as a backend language - now it's time to show them how they can glue all of those components, package them beautifully and deliver great products:

• take the above Spreadsheet integration and wrap it in a Mojolicious or Dancer web application - no need for webserver configuration, filehandler settings in Apache or other time consuming setup tasks
• you could use the Mojolicious Boilerplate in order to have out of the box neat and shiny, production ready web application

At the end of the presentation if the people in the room are not coming to you like

to ask for that list of Perl Tutorials, they should be suggested that a career in flipping burgers at McDonalds might be a viable alternative for them.

Conclusion

We are all hurried people, we are all in shortage of time and besides that, unfortunately, for many of us learning new stuff is done when we are out of school. What will motivate a person in taking action and learn something new, is something that will offer sex, fame, money or power. 

Giving a concise, easy to follow presentation, emphasizing the short path from idea to the final product will help your audience become more productive, helping them to spend less time coding and more time innovating and who knows, maybe when they'll achieve success, they'll have a job offer for you as a CTO, so talk to as many people as possible about the awesome Perl ecosystem.

What do you think are the characteristics of a highly efficient Perl Teasing Presentation?

PS: I managed to help myself from using the word Awesome, although I was tempted to in almost each phrase

Read More

Cluj.PM launch on 2nd of March 2012

It's the first meeting in Cluj and I am happy to be one of the speakers. Especially because Matt S Trout (the creator of DBIx::Class) is holding two talks.

This is my first public tech presentation and I will talk about a (what I consider to be) a High Productivity Toolchain: Mojolicious and DBIx::Class in the backend/middlelayer and Bootstrap from Twitter with some jQuery components as frontend.

Chisel Wright from net-a-porter.com will hold a presentation regarding the awesomeness of DBIx::Class - I have to warn you that you might want to leave your ORM in favor of this.

If you are programmer, sys admin or QA and want to learn more about the wonderful Perl community and how powerful Perl is as a language, feel free to join us. Please register youreself first here (details for localizing the event in space and time are also available at the above link).

In the future I wish we'll become a great community, sharing knowledge, learning new things and have fun. 


See you there!

Read More