"perl" entries
Learn a C-style language
Improve your odds with the lingua franca of computing.
You have a lot of choices when you’re picking a programming language to learn. If you look around the web development world, you’ll see a lot of JavaScript. At universities and high schools, you’ll often find Python used as a teaching language. If you go to conferences with language theorists, like Strange Loop, you’ll hear a lot about functional languages, such as Haskell, Scala, and Erlang. This level of choice is good: many languages mean that the overall state of the field is continually evolving, and coming up with new solutions. That choice also leads to a certain amount of confusion regarding what you should learn. It’s not possible to learn every language out there, even if you wanted to. Depending on the area you’re in, the choice of language may be made for you. For the overall health of your career, and to provide you the widest range of future opportunities, the single most useful language-related thing you can do is learn a C-style language.
A boring old C-style language just like millions of developers learned before you, going back to the 1980s and earlier. It’s not flashy, it’s usually not cutting edge, but it is smart. Even if you don’t stick with it, or program in it on a daily basis, having a C-style language in your repertoire is a no-brainer if you want to be taken seriously as a developer.
Read more…
Full-stack tensions on the Web
How much do you need to know?
I expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.
In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.
Formal separation of concerns among HTML, CSS, and JavaScript made it easier to share responsibilities among specialists. As the dot-com boom proceeded, specialization accelerated, with dedicated designers, programmers, and sysadmins coming to the work. Perhaps there were too many titles.
Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
Read more…
5 ways developers win with PaaS
Powering your app with open source and OpenShift
As a software developer, you are no doubt familiar with the process of abstracting away unnecessary detail in code — imagine if that same principle were applied to application hosting. Say hello to Platform as a Service (PaaS), which enables you to host your applications in the cloud without having to worry about the logistics, leaving you to focus on your code. This post will discuss five ways in which PaaS benefits software developers, using the open source OpenShift PaaS by Red Hat as an example.
No More Tedious Config Tasks
Most of us don’t become developers to do system administration, but when you are running your own infrastructure you end up doing exactly that. A PaaS can take that pain away by handling pesky config and important security updates for you. As a bonus, it makes your sys admin happy too by allowing you to provision your own environment for that killer new app idea you want to tinker with, rather than nagging them for root access on a new VM.
On OpenShift, it goes like this: let’s say you decide you want to test an idea for a Java app, using Tomcat and PostgreSQL (yes, we could argue about the merits of those choices, but work with me here). You can spin that up with a one-line terminal command:
rhc app create myawesomeapp tomcat-7 postgresql-9.2 -s
That -s on the end is telling the platform to make the app auto-scaling, which I will elaborate on later; yes, that’s all it takes. RHC (Red Hat Cloud) is just a Ruby Gem wrapping calls to the OpenShift REST API. You could also use the OpenShift web console or an IDE plugin to do this, or call the API directly if that’s how you roll. The key technologies in play here are just plain old Git and SSH — there’s nothing proprietary.
Six Degrees of Kevin Bacon in six languages
20 years of efficiently computing Bacon numbers
The Oracle at Delphi spoke just one language, a cryptic one that priests “compiled” into ancient Greek. The Oracle of Bacon—the website that plays the Six Degrees of Kevin Bacon game for you—has, in its 20-year existence, been written in six languages. Read on for the history and the reasons why.
1995-1999: C
The original version of the Oracle of Bacon, written by Brett Tjaden in 1995, was all C. The current version, my stewardship of it, and my revision control history only go back to 1999, so that’s where I’ll start. In 1999, I rewrote the Oracle… still entirely in C. Expensive shortest-path and spell-check algorithms? Definitely in C. String processing to build the database? Also C! Presentation layer to parse CGI parameters and generate HTML? C here, too!
Why C? The rationale for the algorithmic component was straightforward: the Oracle of Bacon ran on a slow, shared Unix machine that other people were using to get actual work done. Minimizing CPU and memory resource requirements was the polite thing to do. I needed a compiled language that let me optimize time and space extensively. The loops all counted down, not up, because comparing against zero was fractionally faster on SPARC. It had to be C.
But why were the offline string processing and the CGIs in C? Mostly, I think, to reuse code from the other parts of the code base and from previous projects I’d written when C was the only language I knew.
2004-2005: Perl
As the site added features, I got tired of writing code to generate HTML in C. I wrote new CGIs, then rewrote existing CGIs, in Perl. Simply put, writing the CGIs in an interpreted language made me more productive. I had hash tables and vectors built into the language and CGI support a simple “use” statement away. I didn’t have to compile on one server and then deploy to another—I could edit the CGIs right there on the web server. Good deployment practices it wasn’t, but it made me more productive as a programmer, and the performance of the CGIs didn’t matter all that much.
CPAN’s social continuity of code
Reinvigorate a Perl project today
I contribute heavily in the Perl community, and I’m consistently impressed by the pains we take with code and assets that we personally have no interest in. There’s a group of Perl people who shepherd (camelherd?) code and projects that have lost their maintainers. I’m one of those people.
There’s a very simple system CPAN uses and which has been working since around 1994. Basically, CPAN is a big directory structure that other mirrors rsync (see Jarkko Hietaniemi’s The Zen of Comprehensive Archive Networks). People contribute code through the Perl Authors Upload Server (PAUSE), which does some light verification for identity and permission for the namespaces in that code. No one really “owns” a namespace in Perl, but developers have permissions to control it, including extending that permission to other developers. This is a small bit of a social control. (As an aside, Perl 6’s design handles this differently by allowing people to specify an “authority” for modules)
Parsing HTML with Perl
Efficiently manipulate documents on the Web
The need to extract interesting bits of an HTML document comes up often enough that by now we have all seen many ways of doing it wrong and some ways of doing it right for some values of “right”.
One might think that one of the most fascinating answers on Stackoverflow has put an end to the desire to parse HTML using regular expressions, but time and again such a desire proves too tempting.
Let’s say you want to check all the links on a page to identify stale ones, using regular expressions:
use strict;
use warnings;
use feature 'say';
my $re = qr/<as+href=["']([^"']+)["']/i;
my $html = do { local $/; <DATA> }; # slurp _DATA_ section
my @links = ($html =~ m{ $re }gx);
say for @links;
__DATA__
<html><body>
<p><a href="http://example.com/">An Example</a></p>
<!-- <a href="http://invalid.example.com/">An Example</a> -->
</body></html>In this self-contained example, I put a small document in the __DATA__ section. This example corresponds to a situation where the maintainer of the page commented out a previously broken link, and replaced it with the correct link.
When run, this script produces the output:
Can One Write Readable and Maintainable Perl?
Perl’s flexibility helps you avoid writing superfluous code.
The answer to this simple but somehow controversial question is an emphatic yes! Unfortunately, there is a lot of bad Perl out there owing to Perl’s history of being the language of getting things done in the 90s. It is easy for a newcomer to feel overwhelmed by such examples.
One can avoid that feeling by basically only learning from Perl that does not look like gibberish.
I decided to learn Perl a little late. Or, maybe just at the right time. I had all the tools to learn good habits right from the get go.
In Praise of the Lone Contributor
The O'Reilly Open Source Awards 2013
Over the years, OSCON has become a big conference. With over 3900 registered this year, it was hard not to look at the packed hallways and sessions and think what a huge crowd it is. The number of big-name companies participating–Microsoft, Google, Dell, and even General Motors–reinforce the popular refrain that open source has come a long way; it’s all mainstream now.
Which is as it should be. And it’s been a long haul. But thinking of open source in terms of numbers and size puts us in danger of forgetting the very thing that makes open source special, and that’s the individual contributor. So while open source software has indeed found a place in almost every organization that exists, it was made possible by the hard work of real people who saw the need for it, most of them volunteering in their spare time.
The O’Reilly Open Source Awards were created to recognize and thank these individuals. It’s a community-driven effort: nominations come in from the open source community (this year there were around 50) and then are judged by the previous year’s winners. It’s not intended to be political or a popularity contest, but honest appreciation for hard work that matters. Let’s look at this year’s winners.
Read more…
Open Source convention considers situational awareness in cars, and more
A report from OSCon
Every conference draws people in order to make contacts, but the Open Source convention also inspires them with content. I had one friend withdraw from an important business meeting (sending an associate) in order to attend a tutorial.
Lots of sessions and tutorials had to turn away attendees. This was largely fall-out from the awkward distribution of seats in the Oregon Convention Center: there are just half a dozen ballroom-sized spaces, forcing the remaining sessions into smaller rooms that are more appropriate for casual meetings of a few dozen people. When the conference organizers measure the popularity of the sessions, I suggest that any session at or near capacity have its attendance counted as infinity.
More than 3,900 people registered for OSCon 2013, and a large contingent kept attending sessions all the way through Friday.
Damian Conway weighs in on new features, best practices and Perl’s future
Moose, Regular Expressions and how Perl 6 is influencing Perl 5
Damian Conway is a prominent member of the Perl community, author and presenter.
Key points from the full video of our recent interview include:
- Perl 6 might not be here yet but it is seeping into Perl 5. [Discussed at the 1:09 mark]
- You really should use a more current version of Perl — one reason — Regular Expressions. [Discussed at the 1:48 mark]
- Moose — making object orientation easier. [Discussed at the 2:38 mark]
- Best Practice — Test! Test! Test! [Discussed at the 6:08 mark]
- The Perl Community — 25 years old and still optimizing the fastest dynamic language out there. [Discussed at the 9:42 mark]
You can view the entire interview in the following video.