twitter

Sigh :-( "Homeopaths offer to help contain Ebola outbreak" https://t.co/CtZY1vLW5V via @newhumanist

twitter

Remember kids: Never take sweets from strangers. Except on 31st October. Then it's totally fine.

twitter

Here's your annual "Halloween is evil" nonsense from the Christian church - http://t.co/AWt6dribwS

twitter

Heads up: "Goth at the BBC" on BBC4 at 22:00 today - http://t.co/aWv57o5W41

twitter

Perl nostalgia alert: Someone on LinkedIn asking for help with a system written using AxKit!

last.fm

Kate Bush – Wuthering Heights

http://www.last.fm/music/Kate+Bush
last.fm

The Killers – Goodnight, Travel Well

http://www.last.fm/music/The+Killers
last.fm

Ani DiFranco – Untouchable Face

http://www.last.fm/music/Ani+DiFranco
last.fm

Ani DiFranco – Untouchable Face

http://www.last.fm/music/Ani+DiFranco
last.fm

Polly Scattergood – Nitrogen Pink

http://www.last.fm/music/Polly+Scattergood
perl hacks

Upcoming Training

I have a few training courses coming up in the next few weeks which I thought you might be interested in.

Firstly, the London Perl Workshop is on 8th November. I’ll be giving a two hour talk on “Perl in the Internet of Things“. As always, the workshop is free, but please register on the site and star my talk if you’re planning on attending.

Then the week after I’m running two two-day courses in conjunction with FLOSS UK. On Tuesday 11th and Wednesday 12th it’s “Intermediate Perl” and on Thursday 13th and Friday 14th it’s “Advanced Perl Techniques”. Full details and a booking for are on the FLOSS UK web site.

Note: If you’re interested in the FLOSS UK courses, then please don’t pay the eye-watering non-member price (£720!) Simply join FLOSS UK (which costs £42) and then pay the member price of £399.

Hope to see you at one of this courses.

The post Upcoming Training appeared first on Perl Hacks.

github

davorg created repository davorg/perlwebbook

davorg created repository davorg/perlwebbook
books read

I Am Malala: The Girl Who Stood Up for Education and Was Shot by the Taliban

I Am Malala: The Girl Who Stood Up for Education and Was Shot by the Taliban
author: Malala Yousafzai
name: David
average rating: 3.93
book published: 2012
rating: 0
read at:
date added: 2014/10/29
shelves: currently-reading
review:

github

davorg pushed to gh-pages at davorg/hipsterperl

Dave Cross
github

davorg commented on issue THEMA-MEDIA/CPAN-foolishness#1

Dave Cross

Theo, Probably best to just remove this until you have something useful to put there. Currently, you jsut seem to run the risk of annoying people. …

cpan

Array-Compare-2.11

=êå{^žÈ¨ú+r‰©j¸§ªëk+
github

davorg created tag RELEASE_2.11 at davorg/array-compare

github

davorg pushed to master at davorg/array-compare

Dave Cross
cpan

Array-Compare-2.10

=êå{^žÈ¨ú+r‰©j¸§ªëk+
perl hacks

Perl’s Problems

It’s been over six weeks since I wrote my blog post on Perl usage. I really didn’t mean to leave it so long to write the follow-up. But real life intervened and I haven’t had time for much blogging. That’s still the case (I should be writing a talk right now) but I thought it was worth jotting down some quick notes about what I think is causing Perl’s decline.

Reputation

We have a lot to thank Matt Wright for. And I don’t mean that sarcastically. A lot of the popularity of Perl in the mid-90s stems directly from people like Matt and Selena Sol making their collections  of CGI programs available really early on. The popularity of their programs made Perl the de-facto standard for CGI programming.

But that was a double-edged sword. People searching the web for examples of CGI programming found Matt or Selena’s code and assumed they represented best practice. Which, of course, they didn’t. While people were blithely copying Matt’s programming style, good Perl programmers were using CGI.pm to parse their incoming parameters and separating their HTML generation out into templates.

In my previous post, I mentioned that fifteen or twenty years ago Perl was the programming language of choice for internet start-ups. That’s true, but a lot of the code written at that time was in the Matt Wright style. Matt’s style just about works for a guestbook or a form mailer. But when you try to build a business on top of code like that, it quickly becomes obvious that it’s an unmaintainable mess.

Many of the technical architects and CTOs who are making decisions about technology in companies today are the programmers who spent too many late nights battling those balls of mud in the 1990s. They were never really Perl programmers, they were only using it because it was fashionable, and they haven’t been keeping up with recent advances in Perl so it’s not surprising that they often choose to avoid using Perl.

Complexity

A lot of Perl’s reputation as executable line noise is completely unwarranted. The people who were writing those 1990s balls of mud were under such pressure to deliver that they would have almost certainly delivered something just as unmaintainable whatever language they were using. But some of that reputation is fair. I’ve been teaching Perl for almost fifteen years and I know that there are some parts of Perl that people find confusing. Here are some examples:

Sigils – I can explain things like @array, $array[$key] and even @array[@keys] to people. And most of them get it. But it takes them a while. And then it all goes to pieces again when I have to explain the difference between $array[$key] and $array->[$key].

Context – Does any other programming language have the concept of context? Yes, when used correctly it’s a powerful tool. But it’s hard to explain and a good source of hard-to-find bugs. Can anyone honestly say that they haven’t been bitten by a context bug at some point in the last years?

Data Structures – Is the difference between arrays and array references really necessary? Think of all the complexity that is added because you can’t just pass arrays and hashes into subroutines without being bitten by list flattening. As experienced Perl programmers we know the problems and our brains are hard-wired to work around it. But other languages treat all aggregate data structures as references and it all becomes a lot easier.

I know that each of these features (and half a dozen other examples I could list) makes Perl a richer and more expressive language. But this comes at the cost of learnability and readability. Perhaps that trade-off once seemed like a good idea. When you’re trying to encourage people to look at your language then the advantages seem less obvious.

Of course, none of these features can be changed as they would break pretty much every existing Perl codebase. Which would be a terrible idea. But you can get away with a lot more breakage when you increase your major version number. Which Perl hasn’t been able to do for fourteen years.

Perl 6

I need to be clear here. I think that Perl 6 looks like a great language. I am really looking forward to using on production systems. And it looks like the current Perl 6 team are doing great work towards making that possible. In fact I think that our best approach to reviving Perl’s fortunes is to get a production-ready version of Perl 6 out and to make a big noise about that.

However, that name has been a big problem.

Looking from outside the Perl echo chamber, it’s easy to believe that Perl hasn’t had a major release for twenty years. And that can probably explain a lot of Perl’s current problems.

I know that people who believe that are wrong. The current version of Perl (5.20.1 as I write this) is a lot different to the version that was current when Perl 6 was first announced (which was 5.6.0, I think). Perl has gone through huge changes in the last fourteen years. But the version number hides that.

I also know that we no longer tell people that Perl 6 is the next version of Perl. The Wikipedia page makes it clear in its first sentence that “Perl 6 is a member of the Perl family of programming languages“. So why do people continue to think it’s the next version of Perl? Well, probably because people assume that they know how software version numbers work and don’t bother to check the web site to see it a particular project has changed the standard meaning that has worked well for decades.

So Perl 6 has been simultaneously both good and bad for Perl. Good because a lot of Perl 6 ideas have been backported into Perl 5. But bad because Perl 5 has been unable to change its major version number in order to advertise these improvements to the wider software-using world.

Nothing can be done about this now. The damage is done. As I said at the start of this section, it’s likely that the only thing we can do is to bet heavily on Perl 6 and get it out as soon as possible. Perl 5 will continue to exist. People will continue to maintain and improve it. Some companies will continue to use it. But it’s usage will continue to fall. I really think it’s too late to do anything about that.

The post Perl’s Problems appeared first on Perl Hacks.

perl hacks

“I Do Not Want To Use Any Modules”

Almost every day on the Perl groups on LinkedIn (or Facebook, or StackOverflow, or somewhere like that) I see a question that includes the restriction “I do not want to use any modules”.

There was one on LinkedIn yesterday. He wanted to create a MIME message to pass to sendmail, but he didn’t want to install any modules. Because “getting a module installed will have to go though a long long process of approvals”.

And I understand that. I really do. We’ve all seen places where getting new software installed is a problem. But I see that problem as a bug in the development process. A bug that needs to be fixed before anything can get done in a reasonable manner. Here’s what I’ve just written in reply:

Of course it can be achieved without modules. Just create an email in the correct format and pass it to sendmail.

Ah, but what’s the right format? Well, that is (of course) the tricky bit. I have no idea what the correct format is. Oh, I could Google a bit and come up with some ideas. I might even find the RFC that defines the MIME format. And then I’d be able to knock up some code that created something that looked like it would work. But would I be sure that it works? In every case? With all the weird corner-cases that people might throw at it?

This is where CPAN modules come in handy. You’re using someone else’s knowledge. Someone who is (hopefully) an expert in the field. And because modules are used by lots of people, bugs get found and fixed.

A lot of modern Perl programming is about choosing the right set of CPAN modules and plumbing them together. That’s what makes Perl so powerful. That’s what makes Perl programmers so efficient. We’re standing on the shoulders of giants and re-using other people’s code.

If you’re not going to use CPAN then you might as well use shell-scripting or awk.

If you’re in a situation where getting CPAN modules installed is hard, then fixing that problem should be your first priority. Because that’s a big impediment to your Perl programming. And investing time in fixing that will be massively beneficial to you in a very short amount of time.

The obvious solution is to install your own module tree (alongside your own Perl) as part of your application. But that might be overkill in some situations, so you could also consider using the system Perl and asking your sysadmin to install packages from your distribution’s repositories. Of course, that might need a change in process. But it’s a change that is well worth making; a change that will improve your (programming) life immensely.

Update: Some very interesting discussion about this over on Reddit.

The post “I Do Not Want To Use Any Modules” appeared first on Perl Hacks.

cpan

WWW-Shorten-3.06

"{^­öœzÚD»!¢»^ž)à²+^
perl hacks

Perl Usage

In my last blog post, I posted a graph showing that out of 135 companies at a recent Silicon MilkRoundabout recruitment event, only one said that they were using Perl. That has led to some interesting discussions that I’d like to address here.

I should make it clear that I wasn’t presenting my graph as evidence that Perl is dead. Of course you can’t leap to conclusions like that from what I learned at one recruitment event. I do, however, think that the situation is pretty grim.

But firstly, a few points that people made to me in response to my post.

We know that Perl isn’t used in start-ups
Yes. I think we do know that. But I don’t think we’re as worried about that as we should be. Imagine if that job fair was held fifteen years ago. Or twenty years ago. Perl used to be the language of choice for internet start-ups. What happened to change that? (I have some theories that I’ll cover in another blog post) Can this trend be reversed? (Honestly, I don’t think so – but I’m open to arguments to the contrary)

Every programmer I know uses Perl in some way
I think this might have been true fifteen years ago, but it hasn’t been the case for some time. If it’s really true that all programmers that you know still use Perl, then I think you only know a really bizarre cross-section of programmers.

All companies use Perl, but the HR department or management often don’t know
This is similar to the last point. And, again, I think it’s something that used to be true and hasn’t really been true this millennium. But there’s also the idea of Perl being the programmers “secret weapon” that the suits don’t know about. Even if it’s true (and I don’t think it is), then going underground like that is likely to be harmful to Perl’s popularity in the long term.

I think we should stop fooling ourselves here. Perl usage has been declining for over a decade. To a first level of of approximation, Perl is already a dead language.

Of course, The Perl community has spent a lot of the last few years actively denying that. I’ve been responsible for some of that drum-beating myself. But we need to accept that it’s true. For most people outside of the Perl bubble, Perl is a language that they last considered using back in the last millennium.

So, if Perl is dead, why has everyone spent the last five years demonstrating that this isn’t the case? Have they been lying to us? No, I don’t think they have. I just think that they have been looking at the wrong measures of success. Let’s look at some of the arguments I’ve seen.

CPAN is growing faster than ever
We have regular releases of Perl
Some great new features have been added to Perl
These all essentially boil down to the same argument – “Perl isn’t dead because some part of Perl (or its ecosystem) is improving”. I can’t argue with any of those facts, but do they really say anything useful about the long-term viability of the language. It’s great that Perl is constantly improving, but unless the people who are currently ignoring Perl can be persuaded to investigate these improvements, then they do little or nothing to stop Perl’s decline.

Moose might be the most powerful object system in the world. DBIx::Class might be the most flexible ORM available. Projects like these are great. But they don’t seem to be doing much to bring new people to Perl.

There are more YAPCs and Perl Workshops every year
Perl Mongers groups are starting all the time
We get dozens of people to our meetings every month
These arguments all boil down to “the Perl community is growing”. Again, I can’t argue with those facts (well, to be honest, I think the rate of Perl Monger group creation has slowed over the last ten years) but, again, I don’t think they prove what their proponents think they prove.

There is a difference between the Perl community and Perl programmers. Everywhere that I work, I find people who I already know from the community. But I always find far more people who I don’t know because they aren’t at all engaged with the Perl community. And I think it’s that large, untapped, number of non-community Perl programmers who make up the increased numbers of people attending meetings or conferences. This means that we are getting better at bringing our colleagues along to meetings. It doesn’t mean that more people are using Perl.

The number of Perl jobs is rising
Our company can never find enough Perl programmers
We just started a major new project using Perl
Most of the companies who use Perl continue to use Perl. That’s not really news. And some of those companies have grown really big and therefore need lots of Perl programmers to maintain and enhance their Perl programs. And that’s great. But it’s not really evidence of a grow in Perl usage.

Not all the companies who have historically used Perl continue to do so. Over the last five years I know of at least four big Perl-using companies in London who have started to move away from it for new development.

And one reason why people are always looking for Perl programmers is because many programmers have chosen to move away from Perl. I know plenty of people who were regulars at London Perl Mongers meetings ten to fifteen years ago but who haven’t written a line of Perl for over five years. This means, of course, that there is more work to go round those of us who are left. I could probably go through to my retirement maintaining existing Perl codebases. Those of you who are younger than me might not be so lucky.

 

So, to summarise, people who say that Perl is thriving point to three things – technical advances in Perl, the vibrant Perl community and the number of unfilled Perl jobs that always seem to be around. All of these things are great and are, of course, necessary for a living and growing language.

But they aren’t sufficient. You also need people outside of the community to take notice. And that’s not happening.

Ask yourself three questions.

  1. When did you last read a book on general programming techniques that contained examples written in Perl?
  2. When did you last read documentation for a web site’s API that included examples written in Perl?
  3. When did you last hear of a company using Perl that you didn’t previously know about?

This is why I published that graph a couple of weeks ago. Looking at that data, it really hit home to me just how badly we’re doing.

I have a couple of theories about why most of the world started ignoring Perl. I’ll get to those in my next blog posts. But, annoyingly, I don’t have any good ideas about how we might reverse the situation.

To be honest, currently my best advice (and the course I’ll be taking) is “brush up your Javascript”.

 

The post Perl Usage appeared first on Perl Hacks.

perl hacks

Programming Language Usage

Back in May, I spent an afternoon at Silicon MilkRoundabout. Silicon MilkRoundabout is a recruitment fair for techies. It’s specifically aimed at people who want to work for start-ups around the Old Street area (although they aren’t particularly stringent about sticking to that – for example, the BBC were there).

We were given a booklet containing details of all of the companies who were recruiting. Those details usually included information about the tech stack that the companies used.

Over the weekend, I went through that booklet and listed the programming languages mentioned by the companies. The results speak for themselves.

There were 135 companies at the event. About twenty of them unhelpfully listed their tech stack as “ask us for details”.

Here’s the graph:Usage of Programming Languages by Companies at Silicon MilkRoundabout

Usage of Programming Languages by Companies at Silicon MilkRoundabout

I’ll obviously have some more to say about this over the next few days. But I wanted to get the raw data out there as soon as possible.

The post Programming Language Usage appeared first on Perl Hacks.

slideshare

Github, Travis-CI and Perl


A quick introduction to using Github and Travis-CI to test Perl projects
davblog

First Direct Update

Earlier in the week I talked about my concerns with First Direct’s new password policy. I got an email from them about this, but it really wasn’t very reassuring.

But I kept digging. And on Thursday I got a bit more information from “^GD” on the @firstdirecthelp twitter account. It still doesn’t answer all of my questions, but I think we’re a lot closer to the truth. Here’s what I was told.

The obvious question that this raises is why, then, do they limit the length of the passwords. I asked and got this (three-tweet) reply.

To which, I replied

And got the response

I thought that “as a business we are satisfied” rather missed the point. And told them so.

I got no response to that. And @brunns got no response when he tried to push them for more details about how the passwords are stored.

So, to summarise what we know.

I haven ‘t really been reassured by this interaction with First Direct. I felt that the first customer support agent I talked to tried to fob me off with glib truisms, but “^GD” tried to actually get answers to my questions – although his obvious lack of knowledge in this area meant that I didn’t really get the detailed answers that I wanted.

I’m not sure that there’s anything to be achieved by pushing this any further.

The post First Direct Update appeared first on Davblog.

davblog

First Direct Passwords

I’ve been a happy customer of First Direct since a month or so after they opened, almost twenty-five years ago.

One of the things I really liked about them was that they hadn’t followed other banks down the route of insisting that you carried a new code-generating dongle around so that you can log into their online banking. But, of course, it was only a matter of time before that changed.

A couple of weeks ago I got a message from them telling me that Secure Key was on its way. And yesterday when I logged on to my account I was prompted to choose the flavour of secure key that I wanted to use. To be fair to them they have chosen a particularly non-intrusive implementation. Each customer gets three options:

  1. The traditional small dongle to carry around with you
  2. An extension to their smartphone app
  3. No secure key at all

If you choose the final option then you only get restricted (basically read-only) access to your account through their web site. And if you choose one of the first two options, you can always log on without  the secure key and get the same restricted access.

I chose the smartphone option. I already use their Android app and I pretty much always have my phone with me.

Usually when you log on to First Direct’s online banking you’re asked for three random characters from your password. Under the new system, that changes. I now need to log on to my smartphone app and that will give me a code to input into the web site. But to get into the smartphone app, I don’t use the old three character login. No, I needed to set up a new Digital Secure Password – which I can use for all of my interactions in this brave new world.

And that’s where I think First Direct have slipped up a bit.

When they asked my for my new password, they told me that it needed to be between 6 and 10 characters long.

Those of you with any knowledge of computer security will understand why that worries me. For those who don’t, here’s a brief explanation.

Somewhere in First Direct’s systems is a database that stores details of their customers. There will be a table containing users which has a row of data for each person who logs in to the service. That row will contain information like the users name, login name, email address and (crucially) password. So when someone tries to log in the system find the right row of data (based on the login name) and compares the password in that row with the password that has been entered on the login screen. If the two match then the person is let into the system.

Whenever you have a database table, you have to worry about what would happen if someone managed to get hold of the contents of that table. Clearly it would be a disaster if someone got hold of this table of user data – as they would then have access to the usernames and passwords of all of the bank’s users.

So, to prevent this being a problem, most rational database administrators will encrypt any passwords stored in database tables. And they will encrypt them in such a way that it is impossible (ok, that’s overstating the case a bit – but certainly really really difficult) to decrypt the data to get the passwords back. They will probably use something called a “one-way hash” to do this (if you’re wondering how you check a password when it’s encrypted like this then I explain that here).

And these one-way hashes have an interesting property. No matter how long the input string is, the hashed value you get out at the other end is the same length. For example, if you’re using a hashing algorithm called MD5, every hash you get out will be thirty-two characters long.

Therefore, if you’re using a hashing algorithm to protect your users’ passwords, it doesn’t matter how long the password is. Because the hashed version will always be the same length. You should therefore encourage your users to make their passwords as long as they want. You shouldn’t be imposing artificial length restrictions on them.

And that’s why people who know about computer security will have all shared my concerns when I said that First Direct imposed a length restriction on these new passwords. The most common reason for a maximum length on a password is that the company is storing passwords as plain text in the database. With all the attendant problems that will cause if someone gets hold of the data.

I’m not saying for sure that First Direct are doing that. I’m just saying that it’s a possibility and one that is very worrying. If that’s not the case I’d like to know what other reason they have for limiting the password’s length like this.

I’ve send them a message asking for clarification. I’ll update this post with any response that I get.

Update (17 July): I got a reply from First Direct. This is what they said.

Thank you for your message dated 16-Jul-2014 regarding the security of your password for your Digital Secure Key.

Ensuring the security of our systems is, and will continue to be, our number one priority.

All the details that are sent to and from the system are encrypted using high encryption levels. As long as you keep your password secret, we can assure you that the system is secure. As you will appreciate, we cannot provide further details about the security measures used by Internet Banking, as we must protect the integrity of the system.

Our customers also have a responsibility to ensure that they protect their computers by following our common-sense recommendations.  Further information can be found by selecting ‘security’ from the bottom menu on our website, www.firstdirect.com

Please let us know if you have any further questions, and we’ll be happy to discuss.

Which isn’t very helpful and doesn’t address my question. I’ve tried explaining it to them again.

The post First Direct Passwords appeared first on Davblog.

slideshare

Object-Oriented Programming with Perl and Moose


slideshare

Database Programming with Perl and DBIx::Class


books read

The Complete Works of H.P. Lovecraft

The Complete Works of H.P. Lovecraft
author: H.P. Lovecraft
name: David
average rating: 4.29
book published: 1200
rating: 0
read at:
date added: 2014/06/12
shelves: currently-reading
review:

sources

Feed Subscribe
OPML OPML

Powered by Perlanet