If there is one thing that is more abundant than Hello World programs, it is password generators. Yet, one of the things I could never get right when working on my system administration job (all of them) was comfortable password generation.
There were various methods I've learned from people:I really haven't done a huge amount of work on Test::Harness since it was released as core, so I decided to take a look at how it is now. I was reading a blog post where someone commented that Perl's Test::Class doesn't offer a progress bar and I thought, that should be easy to hack into prove.
I think I started to reinvent XPath. I hate when that happens.
It started simply enough. I had a directory with 12,000 YAML files in it. I wanted to grep them, but I can't do that from the command line:
-bash: /usr/bin/grep: Argument list too long
Although slightly annoying this isn't a big deal. I can write a Perl script to do the job and get the files through opendir. I hardcoded the bits that I wanted to get out, and when I needed something else, I just changed the source.
I made a couple of these quick scripts before I realized I was going to be doing this a lot. I refactored it so I could specify on the command line the path to the YAML thingy I wanted, and called it, well, it was called extract, but I renamed it ypath to put it on Github.
% ypath dist_info/dist_file *.yml
I could do it for multiple values:
For some time now I have been promising to publish the list of CPAN Authors who for one reason or another, appear to be uncontactable. These are authors, who when using their PAUSEID @ cpan.org address, generates a rejection of some form. Typically this appears to be for addresses which are set up to be used in redirection, which have since been made obsolete (perhaps from changing jobs or personal domain), but there are a few that are just not setup to receive emails.
I have now created a Missing In Action page, which I will keep updated as I receive bounce backs from the CPAN Testers daily summaries. In some cases bounce backs require verification from a real person, and I do eventually get round to those, but the ones listed are specifically for emails that are outright rejected. If you have not been receiving any CPAN Testers summaries or reports and have been expecting some, please first check this list to ensure that you haven't had your preferences disabled.
If you are on the list, please read the instruction on the page, to learn how to enable your PAUSE email, and to get your CPAN Tester preferences re-enabled.
Cross-posted from the CPAN Testers Blog.
First, a very very big thank you to people who have filled in the survey and spread the word. After a little less than a week, we have 2500 responses. For this kind of survey, that kind of response is incredible, and many researchers will be envious of obtaining a sample that large, that easily.
The rate of responses is about double that of the 2007 survey which stayed open for about two months to obtain 4000 completed questionnaires. In all likelihood I'll close this survey down at the end of the first week of June (after 2.5 weeks), so to get more interesting data I'd like your help.
Please can you pass on details about the survey to less committed Perl programmers that you know - we don't just want to know about the core of the community, but also more casual users. This group are clearly more difficult to reach, so it's important to spread the word. Just point them to the link http://survey.perlfoundation.org and let them know that the work is sponsored by The Perl Foundation.
Just a quick note: if you can legally work in the UK and you're near London, drop me a line every once in a while if you're looking for work. I'll treat it with confidence. I keep getting contacted by recruiters and sometimes I want to pass leads on to others.
Actually, if you need to be sponsored for a work permit and you're really good at what you do, still let me know. Sometimes the recruiters tell me their company will sponsor permits.
Last Sunday, my brother and I had a discussion about Israel not allowing Noam Chomsky to enter the country because he is "a satanist nazi demon out to get Israel wiped off the map". It was mostly absurd but one point is worth mentioning: my brother claimed that Chomsky is doing a disservice to his goal of further expanding people's understanding of politics by lecturing where people already know oppression (Palestine) instead of where people are relatively oblivious to it (Israel).
While I know this is a touchy subject for most people, it still resounds in my head as the "I think you're wrong because you're not doing what I think you should do" claim which we're so used to in open source.
Recently Leo Lapworth updated several of the perl.org sites he's been working on to list the current stats for CPAN, as was previously seen in the footer of each search.cpan.org page. It's good to remind people (even subconsciously) just how big CPAN is. In his post Leo also wondered what the 20,000th distribution was. With the CPAN Testers database holding lots of stats about CPAN, as well as the CPAN Testers reports, it was fairly straightforward to extract some numbers. In fact it proved so straightforward I promised to include it in the CPAN Testers Statistics website.
I'm pleased to say I finally found some time to do just that, and have revamped the CPAN Statistics page to include the CPAN Milestones. Now you can keep up to date with what distributions are hitting some significant milestones.
Cross-posted from the CPAN Testers Blog.
Event: Birmingham.pm Technical Meeting Date: Wednesday 26th May 2010 Times: from 7pm onwards (see below) Venue: The Victoria, 48 John Bright Street, Birmingham, B1 1BN. Details: http://birmingham.pm.org/tech/next
This month we welcome a returning guest speaker, Richard Wallman, who will be taking a look at how Catalyst has eased the development lifcycle of websites, from his own experiences. In addition I'll be looking at the progress of the CPAN Testers 2.0, and looking at some of the near future plans for CPAN Testers.
We are a few days away from the Portuguese Perl Workshop. We still have some spots left for the training sessions and are still accepting presentations submissions. Workshop official website here.
Good advice for both building a house and performing a database update.
So you're writing an IRC script for irssi and you want to strip formatting codes (including colors, bold, underline, etc) from some variable. This is possible with s///, and google will show many (usually not very readable) examples.
But there's an easier way: irssi has an undocumented function called Irssi::strip_codes that does all the work for you. And since irssi exports all functions into your script's namespace unconditionally, you don't even need to type the Irssi:: part:
my $clean = strip_codes($dirrrty);
This will remove so-called “mIRC colors”, irssi's internal formatting codes, and ANSI color sequences.
I recently invested some tuits to rebase my Perl6 enhancements in Emacs cperl-mode to the latest version 6.2 that Ilya Zakharevich provides on his homepage.
After wading through tears and blood (well, it was more about different levels of fatigue) I felt strong enough to also finally merge "the other big branch"(tm) that Jonathan Rockway maintains for MooseX::Declare syntax enhancements.
The result is yet another branch mxd-perl6-merge on github. The leading version is ilyaz' (including useless whitespace left as is), then Perl6 adaptions, then MX::Declare which in turn also made some things more clever for the Perl6 changes.
If you ever tried one of the cperl-mode hacks for Perl6 or MooseX::Declare, please switch to this merge. It should work the same or even better for you. If not, report it to me.
Note: this is part of an occasional series of posts aimed at newer programmers, or newer Perl programmers. I'm going to talk about what objects are, but even programmers who think they know the answer might benefit from some of this. That includes myself. You might take exception to some of what I write, so feel free to chime in with counter-arguments.
For many older programmers such as myself (I'm 42 as of this writing), their first computer program is often a variant of the following BASIC program:
10 INPUT "What's your name? ", N$
20 PRINT "Hello, "; N$
30 GOTO 10
That's already pretty interesting. In just three lines of code we have some idea about:
The error of abstract reason is, in short, forgetfulness. It forgets that its abstractions are designed to try to capture the infinitely elusive real. It begins to use these same abstractions as yardsticks by which to judge the real.Harris was summarizing a lengthy criticism of Enlightenment-era political thought, and the failure of the various radical philosophies that attempted to wipe away and reconstruct society from the ground up. I find the same lesson applies to good software: it's often imperfect, but those imperfections are there because reality demands them, and scrapping a working, if imperfect solution in favor of building a new one inspired by a new abstraction is a project often doomed to failure.
... and Larry Wall.
Deutsch: [...] that is Lisp is lexically pretty monotonous.
Seibel: I think Larry Wall described it as a bowl of oatmeal with fingernail clippings in it.
Deutsch: Well, my description of Perl is something that looks like it came out of the wrong end of a dog. I think Larry Wall has a lot of nerve talking about language design - Perl is an abomination as a language.
I wonder what the right end of a dog is?
L. Peter Deutsch (of Ghostscript fame) in Coders at Work
I'm using DateTime objects a lot these days: anytime I get some date/time data from outside of Perl, the first thing I do is convert them to DateTime object, to avoid calculation/formatting hassle ahead.
However, the dumps are not pretty.
% perl -MDateTime -MData::Dump -e'dd [DateTime->now]'
@foo = map { s/bar/foo/g; $_ } @baris not legible. Probably better to use
@foo = @bar; s/bar/foo/g for @foo;While I understand that the substitute operator return value is useful and relevant, I wonder if there is a cleaner syntax for this behavior with map.
There have been a lot of solutions to solve the hierarchy in a relational database. I'm pretty sure that I've tried them all, but ultimately they all fell short for one reason or another. Nested Sets are a beautiful answer, but fall short if you have too much data. Materialized paths are great except that they don't maintain ordered siblings. Many others require complex joins, special triggers, or stored procedures that you can't use in SQLite, or would require you to do something different in each database you support.
Through much trial an error, I solved the problem with a mechanism that is easy to use, fast, and will work with any SQL database. It doesn't require stored procedures, triggers, joins or anything else, so it will work even on the simplest of databases. I call that solution Lineage.
I see code…
my @showart;
my @articles;
map {push(@showart, $_) if($_->{'article_description_cat'} eq $category);} @{$alteration};
@articles = sort {$a->{'article_description_rank'} <=> $b->{'article_description_rank'}} @showart;
So what do we have there?
@showart.map that explicitly throws away map’s return value and goes for the side-effects only.blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
