We’re very pleased to add CargoTel to our list of growing sponsors for YAPC::NA 2012.
CargoTel, headquartered in Baltimore MD, provides transportation and field-service web and wireless applications in North America and is expanding its offerings in South America, Europe and Asia. It’s software is centered around Perl and delivered on a SAAS basis using many of the latest technologies such as HTML 5 on Android browser-based wireless applications. CargoTel hosts Baltimore Perl Mongers and is a supporter of other Perl organizations. http://cargotel.com
Params::Validate is a very useful module, which lets you easily enforce rules such as "the 'foo' parameter to the 'bar' subroutine should be an arrayref". It also has some very basic support for dependencies - eg, that the 'baz' parameter must always be used in conjunction with the 'bar' parameter.
But for a problem I had, it didn't go far enough. So I've extended it. Params::Validate::Dependencies (Github link; not yet on the CPAN) extends the validate() method to add support for things like "must have exactly one of 'alpha', 'beta' or 'gamma', or both of 'foo' and bar'".
I would appreciate if some kind person could take a look over the code and tests and tell me if they're any good, and also let me know if the documentation makes sense.
Had a great chat with the Thousand Oaks PerlMongers last night, as an ongoing series of conversations I've been having recently about finding a compelling reason for Perl6.
I was inspired by Larry's Onion talk to continue thinking about the relation of Perl5 and Perl6 (and frankly, me and Stonehenge as well).
First, Perl6 is not "the next Perl5". Perl5 will be alive and well for another decade at least, independently maintained and released. That's happening quite efficiently and effectively already. (Translated: "I will quite possibly be able to continue making money off Perl5 for years to come".)
So, what is Perl6 then? It's a different language. Businesses aren't going to migrate from Perl5 to Perl6, but they will consider Perl6 for a new project, just as if they'd consider Ruby or Python or Grails or Scala or any other language.
What's missing is the equivalent for what Rails did for Ruby: a compelling web framework.
Dyn is looking for a Perl developer to join our ecommerce back-end development team. The successful candidate will work on “nuts and bolts” back-end projects that deliver the functionality and experience our marketing team and users expect. Some familiarity with web development would be helpful. However, this is not a front-end web development role.
Required Skills
Sets realistic expectations and delivers on schedule
Able to focus and avoid scope creep while minimizing workarounds
Enjoys not only writing code to deliver function, but also writing and using tests to validate. Feels a project is complete when the results are proven via tests and understood via documentation
Collaborates with technical and non-technical colleagues to identify and deliver excellent solutions
Familiar with OO programming
Understands the core concepts of relational databases
Enjoys working on complex systems in a fast paced environment with changing requirements
Desired Skills
Able to keep user experience in mind during planning and development
Prior experience with ecommerce
Familiarity with revision control systems (CVS, Subversion, etc.)
This is the culmination of quite a long development cycle since the last release. This was made longer than it should have been due to the discovery of a bug not long after I had branched version 0.88 from trunk.
The release was then held up while people got to sorting out the problem at the time, which in turn saw more work done and more of the internals changing until it got to the point that it made sense to merge all changes in the branch ( all of them translations by our hard working translators ) back to trunk with a new branch taken for the 0.88 release.
Normally in the release announcement I take you through the changes and bugs fixes to be found in the release at the time, this is typically done by taking the Changes from the Padre distribution and grouping together various changes people have made to give a "face" to the name.
As I've written in my previous post, we've been making visits to our potential YAPC::Asia Tokyo 2011 (Oct 13-15) sponsors for the last few weeks. After today, we only have *one* more visit that we need to make our potential sponsors for YAPC::Asia. Here's a picture from today's visit.
As you can see, we have last year's YAPC::Asia Tokyo pamphlet, and we're discussing how this sponsor (who shall remain nameless for now) can make the most out of their presence at YAPC::Asia Tokyo.
It's always a nice idea to bring stuff (novelties, pamphlets, time-schedules) from previous YAPCs, as not all potential sponsors share the same image of how a YAPC sponsor ought to help / take advantage of the event.
Dyn is looking for both junior and senior system administrators with Perl experience. Much of their administrative systems are written using Perl.
Junior System Administrator
Description
A Junior System Administrator is responsible for keeping Dyn’s global IP anycast network available and performing well. Job responsibilities include deploying new systems to production, upgrading existing deployments to handle additional load and/or to address security issues to managing vendor maintenance events and debugging complex network and system troubles. Junior System Administrators should enjoy working in a FreeBSD/Linux environment, be comfortable with scripting in shell (bash), perl, and/or python, and have familiarity with networking equipment from Cisco Systems and Juniper Networks.
Update: This is not the actual release announcement, just a couple of big changes that I think deserve some coverage in depth.
This is an immense release for the Padre team, the changes file entry alone is 140 lines.
Most importantly, this release completes the refactoring work on a number of internal subsystems.
Padre's threading architecture Padre::Task has been returned to full maturity after a long period of instability following the landing of the second generation Padre::TaskManager implementation.
Fixing the last thread leak bugs allows the reintroduction of our "slave mastering" technique, where we spawn a clean "master" thread as early as possible during startup, and then spawn background worker slave threads off this master thread rather than off the foreground thread. For a typical Padre instance, slave mastering results in a reduction of 15meg of RAM per thread (and there is further improvements to be gained in this area by requiring less of Wx to be loaded at startup).
A long time ago I had a very silly conversation with a developer where we both agreed that we weren't too concerned about algorithms and data structure memorization because, hey, we could look them up, right? We don't need to use that fancy-pants computer sciency stuff in our jobs because we've never needed to. Of course, that's like saying because you've never had a driver's license, a driver's license is useless. When you don't have a car, you naturally tend to look at problems and solutions without considering the options a car may provide you.
That's why I've been brushing up on my comp-sci lately. I've been working through a bunch of sorting algorithms (insertion sort, merge sort, and quick sort) to better understand their characteristics when I started to think about how I might find if an item is in a list. If it's a large list, I typically use a hash. Most of the time this is fine, but I wanted to understand better what I could do.
I needed to do this yesterday, so that a developer could work on a project on his own machine while accessing some REST services I developed on an intranet server. Cross-domain requests are prohibited by the same origin policy security that govern client-side Javascript programs. JSONP gets around this by sending back a Javascript function which encloses the JSON data, rather than just the JSON data. This is known as a callback and is used like this:
Rob Hoelz, the leader of our software team for YAPC::NA 2012, is holding an Act workshop from 5pm to 7pm at the Essen Haus tonight. Don’t worry if you can’t make it for the entire two hours. People are free to come and go as they please. But if you want to learn about how you can help enhance Act for YAPC, then you should definitely try to make it.
Bring a laptop with you, preferably with Perl already installed. If you don’t have a laptop, then we can buddy you up with someone that does. Rob will take care of the rest once you arrive. Hope to see you there.
NOTE: These are the two hours before our normal MadMongers meet up in the same place, which starts at 7pm. Feel free to stay for that. Jesse Thompson and I will be giving dueling talks about Data Munging where we will show you how to extract data out of nearly everything.
Creating them has been quite the learning curve. My initial inspiration was Vimcasts, and although I don't have the hip accent, I figured I could put something interesting together for...something. It didn't take to long to settle on Perl and my preferred source of Perl unicorns, Mojolicious.
A Vimcast has a very cool, down-to-earth presentation; the music, the tone of voice, and the presentation as a whole tell the viewer, "Yeah, Vim is just that cool, and if you learn this, you'll be that cool as well". Presentation is vital: the Apple logo on most of my devices state as much.
I wrote Data::Compare::Plugins::Set::Object (blech, what a mouthful) a couple months into my job at GSI. At the time I wasn't sure what if any their policy was on open source releases, so I was careful to do it on the side and assign copyright to myself. I still haven't found an explicit policy beyond my manager's "just use your best judgment" statement. Maybe that's for the best.
Lots is happening in the Perl Web framework world these days. The threemainframeworks are getting better at a faster-and-faster rate, great screencasts are starting to appear, and — finally — Perl is moving into the cloud, thanks to support from new Platform-as-a-Service vendors like dotCloud.
Now, I’ve been known to kvetch a bit about “Perl in the cloud” once or twice before. But this is not a kvetch. No, no, my friend: this is a “Forget the ode, show me the code” post.
One of the things we’re toying with for YAPC::NA 2012 is the idea of an unconference track. The idea is that we’d provide a whiteboard for people to write out ideas for ad-hoc presentations at the beginning of the conference, and others would sign up to attend those ideas. The topics could be about Perl, CPAN, or something completely unrelated. We’d provide a room with a projector and a whiteboard, specifically for this track. The most popular ideas would be given time slots.
What do you think of this idea? Is there room for an unconference track at YAPC?
I originally started DBIx::Class::Schema::Critic as a code sample for a job application, but I thought it was worth releasing and continued independent development. Inspired by Perl::Critic, it's a package for comparing relational database schemas against a collection of best practice policies using the DBIx::Class Object/Relational Mapper.
At mst's behest I converted it from the Moose object system to his more lightweight Moo. But now that I've accumulated a few policy modules I'd like to refactor their commonalities out into roles.
Trouble is that Moo doesn't have an equivalent to Moose's MooseX::Role::Parameterized, and I can definitely see use for that in creating a bunch of similar roles for each DBIx::Class object a policy applies to.
So what to do? Can/should I port parameterized roles to Moo, while avoiding the overhead of a meta-object protocol like Moose's Class::MOP (which Moo explicitly rejects)? Or just make a bunch of more-or-less identical roles that differ only in name and attribute content, accepting the repetition as the price of minimalism?
By this time folks know that I've been working hard trying to recruit more people for booking.com. They didn't ask me to, but I do this because I find it fun and I like working with people. Also, if you read my expat blog, you know that I want to help people live and work in other countries. I'm very fortunate that this passion of mine fits very well with my current employer's desire to move people to Europe. Yes, I get paid a bonus for everyone I refer, but I also tell everyone that if they don't want to go through me, they can apply directly to our jobs portal. Extra money is nice, but I'll happily forego that if I can help you live your dream of being an expat.
By now, many of you have seen our advertisement on jobs.perl.org advertising that we're hiring 20+ Perl developers. Many people have speculated as to why. This is to put to rest some of rumors which seem to go around.