From time to time I find myself needing to explain what OO programming is. I've written that Objects are Experts, but as usual, there's a deeper lesson to be learned here.
Imagine that you've hired a new barista (espresso bartender) and you're teaching him how to make a latté. You explain
how to pull the grounds and start the espresso brewing
how to steam the milk and get a good foam
pouring the milk into a cup
pouring the espresso through the milk (and maybe making a nifty pattern on top)
You explain this over and over. That's procedural programming. Finally, one day you can walk in and just ask for latté. You don't have to tell your new barista how to do it, you just ask. Congratulations: your barista is now an object.
Everyone knows how frustrating it can be to try and fail to install a Perl module. I'm writing an article that will help people troubleshoot the common causes of a module not installing. I've made a list below but have I missed any common installation issues that you've experienced?
Unmet Perl dependency (cannot find module in @INC)
Even though newer scripting languages are now in vogue, Perl is still the workhorse of the internet. The job market for Perl developers is going strong and Perl has a long history of use in major web sites such as Ticketmaster, Booking.com and The New York Times. Perl is well suited for database processing tasks due to the mature, unified DBI database interface and the numerous database-related modules, templating solutions and ORM frameworks available from the CPAN repository.
NuoDB provides a truly scalable, cloud database that is SQL-compatible at the same time. By connecting to NuoDB, legacy database applications can continue to run and scale into the cloud era while taking advantage of automatic redundancy and easier management.
I was asked on twitter recently what impact my restarting the p5-MOP project will have on Moe. My response was basically that my time would be split between the two projects, so momentum would probably slow. But that's actually not true, my time right now is completely focused on p5-MOP, and Moe is kind of on the back burner (for me at least, the other contributors need not wait for me).
But this question got me thinking, specifically thinking about the relationship between these two projects.
I realize now that when I started the p5-MOP project I was lacking some very crucial knowledge and experience. I had spent the last 7 years just building features on top of a language, and really had no experience building them inside of a language. I can see now that my approach reflected that lack of knowledge and experience, and that it ultimately lead to the issues that suffocated that project.
Because we take confidentiality very seriously, all of the names (except mine and my wife's) have been changed, along with the countries. Also, my wife handles most of the recruiting side. I'm a freelance consultant/trainer, so no, I'm not giving up programming.
Nisar (not his real name) lives in Unknownistan (not his real country) and was extremely concerned about the climate in the country he was seeking work in. We were confused. He was willing to accept just about any programming job for any pay rate. With his desperation to get out of his third-world country, why would he really care about the weather?
The answer, it turns out, was rather simple, though surprising to Western ears: if Nisar couldn't find a place to live with heating, he was worried about being able to handle the winter.
Last night I managed to get all the talk and tutorial feedback emails out to the speakers from YAPC::NA 2013. If you were a speaker at the event, and haven't received an email from me, first check your spam filters, and then contact me, and I can resend yours.
This year we had 351 talk evaluation responses, 29 course evaluation responses and 121 conference survey responses.
I seem to have started a whole controversy. I feel like I should be blushing: all this attention is probably assigning far more importance to my opinions than I deserve.
First, a recap: There were a couple of blogposts about pre-modern Perl. Then I responded with a bit of a defense of post-modern Perl. This engendered a lot of comments; certainly more comments than I’ve ever had on any of my other blog posts (in fact, more than twice as many as the previous record-holders). Then the author of the post that initiated the discussion made a fuller response.
This past Thursday we tried something new at Toronto.pm We decided to try having our in-person meeting also available online via Google Hangout. So far all feedback has been positive and it allowed us to have a meeting of 15 people rather than just the 10 who made the trip to our usual location. We had participants from as far as Texas and Alberta as well as some local mongers who weren't able to make it to the location but were still interested in the topic being presented.
We're going to make a few tweaks to the setup in the actual meeting room in order to let the online participants better hear the questions asked in the room and vice versa, but moving forward it looks like we're going to stick with this format and likely publicize the hangouts so that just anyone can check in and participate. At least one of our lightning talks in our coming September meeting will be from a remote participant, which seems like a great way to get access to more speakers than the usual suspects who attend our meetings in person.
If you've toyed with the idea of broadcasting your meetings, this may also be a good solution for your local monger group.
You know the good feeling when you find a solution for a problem after it hounted you many months or even years. I had such a moment today when i finally found (with the help of the excellent Mark Dootson++ of course ) a way to load icons from a set a data and not from a file. Now I can have a complete set of default configs inside a Module so Kephra can boot fully featured no matter what. Yes the Kephra rewrite is alive. I just reorganized the branches and the development model. It runs now under mac and we have full (more?) utf safety. The internal models are still in flux and I plan to drop Moo. Next stop will be the creation of a customized status bar that will be able to have coloured always right aligned labels, icons, fitting context menu and more. Like I always wanted it to be. A new dawn :).
“Let’s free ourselves from the shackles and do something bold!”
I always cringe when I hear this battle cry. Isn’t that sentiment exactly what set the trajectory for the Perl 6 effort? Maybe it’s just been so long that people have forgotten.
But that is precisely how Perl 6 became such an amazingly long trek: once you remove the constraint of staying compatible, everything is suddenly, potentially, up for reconsideration. Then when you start changing things, you discover that changes in one part of the language also affect several other, remote parts of the language. So it starts with the simple desire to fix a handful of obvious problems in obvious ways… and spirals out as you make changes, and further still as you make changes in response to your changes, ever further and further.
So when I started the p5-mop-redux project I purposefully avoided getting too deep into the meta-layer swamp. One of the things that became really difficult with the previous attempt was the level of complexity in the meta-layer bootstrapping. For this new version I decided I was going to favor a simpler and more manual bootstrapping process, and so proceeded to punt on it until I got the regular class layer working.
Well today I decided it was time to dive into that meta-layer swamp, and I am happy to say, ... it works!! (after a bunch of tweaking and fiddling that is).
Here is one of the tests from the previous prototype converted to work with the specifics of this MOP. It implements a simple metaclass which will auto-generate public accessors for all your attributes.
Additionally here is another converted test which does the same thing, but takes an optional validator to do validation on values being set (similar to Moose). This also demonstrates has variables being able to take in extra metadata.
Flux is the framework I've been meaning to release for a very long time [1].
What's it good for? Message queues; organizing your data processing scripts in a scalable way; de-coupling your processing pipeline elements, making them reusable and testable; seeing your system as a collection of lego-like blocks which can be combined and replaced as you like. With Flux, your code is a series of tubes.
Flux is a rewrite of Stream framework which we wrote and used in Yandex for many years. Stream:: namespace on CPAN is taken, though, which gave me the reason to do a cleanup before uploading it, as well as a chance to rewrite everything with Moo/Moose.
I'm planning to release Flux in small chunks, explaining them along the way in separate blog posts, as time will allow. Today, I'll explain the main ideas behind it, some core classes, and how all its parts are working together.
I'll be giving a presentation about Pinto to the Los Angeles Perl Mongers on July 17th. Pinto is the ultimate tool for creating a private repository of Perl modules, so you can build your application with the right modules, every time.
While I'm in town, I'd like to visit some of the local Perl shops. I'd love to meet your team and learn about how you manage your Perl modules, and give you a personal hands-on tour of Pinto.
So let me know if you've got a conference room available on July 18th or 19th. I'll bring the catering! You can reach me as jeff@stratopan.com.
So far this year, I've given talks at both OPW and YAPC::NA about where I see Perl headed as a language and as a community. While both talks made heavy use of hyperbole to drive my points home, the overall concern I was trying to convey was my belief -- my fear -- that our beloved Perl 5 had stopped evolving as a language. In my opinion, this is largely due to the problem of backwards compatibility and our community-wide commitment to maintain it. I also wanted to express my desire to see Perl continue to grow and move forward, and my intent to shake things up a bit to help make that happen.
Continuous Integration (CI) is the autotesting of unit tests.
Why autotest?
There are many good answers. First and most importantly, developers get fast notification of when and where defects were committed to the source code repo. Testing on multiple platforms and environments also becomes possible and automatic. Invoking a unit test build manually is silly when we have computers. Let's be smart and lazy.
I haven't followed all of it, but the discussions about whether or not the "Modern Perl" tools like Moose are a good thing reminds me of Steve Yegge's essay about the "software political axis." If you haven't read it, I'll give you the super short summary: he says that a major source of tension between developers is their differences in risk tolerance, as seen in attitudes toward such things as type checking, adding new syntax to a language on the fly, well-defined schemas vs NoSQL, QA cycles before code rollout, etc.
With this framing, embracing Modern Perl is indicative of a lower risk-tolerance and a desire for more safety in software development, while objecting to it shows a willingness to accept more risk in exchange for lower overhead.
What do you think? Do you agree with this analysis? Have you seen any other interesting writing on this subject beyond Yegge's essay?
This new Perl hackathon is named patch -p0 (yes, there'll be more), and will be held (as usual) in the Carrefour Numérique de la Cité des Sciences et de l'Industrie (niveau -1), in Paris, from Friday, July 27 2013, to Sunday July 29, 2013.
Since trying to hide from the cloud, I've solved my problem of synchronizing address books and calendars with my home machine through (paid) Android CalDav adaptors and Davical. What I'm now looking for is a nice RSS reader to supply me with well-prepared information during my daily subway ride.
