Perlbal is something I always wanted to learn. A recent DDOS made sure I learned it in an hour or so. Apparently the regular stuff take about 4-5 minutes with it. This post will try to make it shorter.
Suppose you have three servers:
Web1 - webserver number 1 - 10.2.3.1.
Web2 - webserver number 2 - 10.2.3.2.
GW - your gateway server, which you want to use as a reverse proxy for Web1 and Web2.
What you basically need is 2 things:
- Perlbal configured for Web1 and Web2.
- Web1 and Web2's Apache (which is what I'm using) should set the forward headers correctly. This is optional but most people will want this. Also, it might be supported in Perlbal, but I didn't find it yet.
For the Apache, on Web1 and Web2 you just download and compile mod_rpaf using: apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c
Then you follow the simple 5 config lines available at the mod_rpaf page.
I wouldn't say that many of these count in the "best" category, some of the tasks can be accomplished with system utilities and some are obfuscated or golfed. But I find it useful to keep these around to remind me of solutions that I might otherwise forget or have to re-invent.
It's more than a touch frustrating for me, but I need help processing an Atom feed (having never done this before). Specifically, I need help with the gitpan Atom feed. Github has a useful API, but it can't handle the huge number of repos which gitpan has, not does it appear that the Github API offer any paging facilities.
I've already seen modules like XML::Atom, but what I'd like to see is something which allows me to pull past Atom entries (I know this is available because Google Reader can read the past entries. Heck, even reading the HTTP headers hasn't allowed me to decipher the exact incantation needed. Basically, I'm looking at the following (pseudo-code):
my $atom = Some::Atom::Module->new($atom_url);
my ( $limit, $offset ) = ( 100, 0 );
while ( my $results = $atom->fetch(
{ limit => $limit, offset => $offset } )
{
process($results);
$offset += $limit;
}
I see a number of Atom modules on the CPAN, but I've not found one which offers paging. Have I missed one? Is there a clear resource online to explain how I can at least fetch past Atom results via curl?
Josh McAdams and I are about to finish off Effective Perl Programming, which is already on Amazon for pre-order. We just have to finish off the last item, a list of really cool Perl one-liners. We have the stuff that we use ourselves, but we know there is a lot more out there.
What's in your login files? Have you written a really cool Perl one-liner?
We're especially interested in one-liners that do interesting Windows things. Do you have something that interacts with Office (or maybe plays MineSweeper for you)?
Maybe you have something that you type in the SSH shell on your iPhone? Are you doing something with Perl and Android?
Show us what you have, give us a couple of sentences about what it does, and how you'd like your name to appear in the book.
Like many projects, Plumage wants as many active contributors as it can get. In order to bring in new contributors, any project needs to do a few things:
Get users interested in contributing (more on this another time)
Let them know how to contribute
Make it as easy as possible for them to do so
One big way to address that list is to invest in contributor (AKA "hacking") documentation. The word "invest" is intentional -- you will need to put quite a bit of time into writing the documentation, and you hope that it will bring enough additional contributions (that you wouldn't have otherwise gotten) to more than make up for the time you invested.
Hacking docs are over and above the low-level API documentation, covering object attributes, method signatures, exception types, and so forth. Those API docs will certainly make development easier for your contributors, but they don't capture the workflows, mental checklists, and rules of thumb that guide you when implementing new features or tracking down bugs.
I like playing around with 3D software such as Autodesk Maya and Blender. I gave Blender a much greater focus during the last few months, as I developed a tendency to prefer opensource solutions whenever I can.
At the beginning I had some annoying problems with it, which surprisingly or not, aren't Blender's fault at all. Most of them are Nvidia's fault.
I have a graphics card based on the Nvidia GeForce 8600GT chipset.
On Ubuntu 9.04, my OpenGL didn't work at all, so I couldn't even get Blender to start.
Gladly, with the upgrade to 9.10 and the new ver 185 Nvidia drivers, that problem was solved and I could finally use Blender on a Linux platform.
All was well for a couple of months, and I greatly enjoyed the amazing speed at which Blender loads and runs on my 'Buntu.
Ever since Moose::Role came to life, I have been dying to refactor the default CRUD implementation in Reaction to use Roles. Over the last couple of months I slowly did that work as I had tuits, and today, after months of being finished, I finally got the chance to merge and push back the branch to trunk. As of today, all of the CRUD functionality in Reaction is supplied by independent roles. Which means one can do something like the following:
Which all-in-all is a pretty easy way to create Create / View / List functionality for one of the Collections in your Model. Look for more actions to be added in the near future.
At present, the web interface to the Reaction repo is undergoing maintenance and possibly migration, so I don't have a better link for you, but I hopefully will soon.
Fun:
When Brian mentioned the sale on Learning Perl and Mastering Perl, I went and purchased two of each. Presumably one for me and one for my girlfriend. I haven't read mine but instead gave it to my younger brother who decided to learn Perl. I've been helping him almost daily with the material and the homework.
Yesterday I presented him the idea of tests and showed him Test::More. You see, until now he's been manually running each exercise in the book and comparing the output with what the book says it should be.
Instead he can now write what the book expects it to be as a test and run the code, then just see if it's "ok" or "not ok". Much simpler. He likes it very much.
Being a cautious type (usually), I kept on to my recently created use.perl.org journal despite the justified acclaim this new platform gained when it was annouced.
It was worth the wait, seems like all the early illnesses have been cured, and it's safe to join this much improved perl blogging sphere!
Glad to join, and happy to use these great new blogging tools. Thanks to all those involved in the creation and maintenance of blogs.perl.org!
It has been another month since the last time I posted a Plumage work log, back on the old u.p.o blog. Mostly this was because I was getting actual work done on Plumage, so I hope you'll forgive me.
Just like last time so much time had passed, I'm just going to post the (mildly edited) #parrotsketch reports here; the format is a bit terse, but it should give you an idea of the pace of development:
Bad news! It's written in C#. C# is lovely, but this will likely limit its adoption in the non-Windows world. I'm curious to know if it will compile and run under Mono. More important, how would we write a Perl interface for it? True relational databases seem to eliminate the object-relational issues which ORMs traditionally have. It would be nice to see how well it translates in practice.
Quite often I read about whether Perl is "legacy" or "modern". It all comes down to "is Perl dead or alive?"
Here is an example to show how well it's sanity status is and why it might need marketing:
I try to "do email". :-)
I read myself through modules on cpan. There are a lot. Now, where to begin, which modules to choose? Instructions for beginners are rare or I am too stupid..
I find emailproject.perl.org
Same here. Plus most of the pages are a little older in date.
Few days later, emailproject.perl.org has shrunk down to one page.
So I finally do what I should have done at the very beginning.
I ask my questions on #email. Some minutes later I'm chatting with the authors of the modules I try to use. They expect me to ask clever questions but help anyway as I fail to do so. ;-)
My questions are promptly answered, I'm helped through the initial steps and my first "hello_email.pl" is working in no time.
Stability seems to be coming to these shores, so I guess it's about time I created an account here and started posting. For a while at least, most of my posts will be about Plumage, for which I am the current lead developer.
Plumage is a cross-language module ecosystem, designed to work with CPAN, LuaRocks, RubyGems, Rake, distutils, and so on. Plumage itself is implemented in NQP (Not Quite Perl 6), which is part of the PCT toolset used to implement languages and modules for Parrot.
The original design document for Plumage is available on the Parrot wiki, and the source repository is hosted on Gitorious. You can check it out by doing the following:
(Note: this is a repost due to some of the beta-ness of the site).
BioPerl is a commonly-used toolkit for bioinformatics, but it does have it's share of problems. As educated_foo has pointed out, it can be slow, documentation is spotty for some modules, classes can be overly complex in some cases, and there are interface issues. And, for simple formats like FASTA it's probably overkill if you are just parsing data. Not to mention the monolithic nature of the beast; I think it's over 1000 modules now.
We in the BioPerl community haven't heard much about these issues from users. What (specifically) bugs you about BioPerl? What could be improved? In other words, what are it's weaknesses? Specifics would be nice.
(Just for some balance, I'll blog about some of BioPerl's strengths at a later point)
Rattling off a couple, from educated_foo and myself:
Make it less monolithic. Break up 'core' into more manageable bits.
Simplify classes.
Better tests?
Maybe a BioPerl Manual? (we do have HOWTOs that could work as starter material...)
Moose? Some of those interfaces fit nicely into Roles...
Allow parsers to return simple data structures (hash refs?) as well as objects.
Re-evaluate interface? educated_foo mentioned problems, but specifics would be nice.
Monty Widenius, the creator of MySQL, needs your help to save MySQL from Oracle. In short, Sun bought MySQL. Oracle wants to buy Sun. Get the picture? Oracle has already let InnoDB languish after acquiring it. There's no doubt that they would like to do the same thing with MySQL. After all, many companies look at the price of Oracle versus the price of MySQL and Oracle loses another sale. Oracle does not want MySQL to succeed.
Frankly, this might be a strange blessing in disguise as it could increase adoption rates for PostgreSQL. That being said, I support open source software, even if it's software which represents the Platonic ideal of a "love/hate relationship."
