hooray I will give my first training course at YAPC. As every quarter, i written another wxperl article for $foo which will get part of the teaching material as well as my code examples for the wxperl workshop last year. i really need to prepare better for such incidences.
During the German Perl Workshop I met my friend Mark Overmeer who asked me who financed my trips to the various events promoting Perl. I got lucky that in every place friends gave me free accommodation. The Perl Foundation, and YEF covered the
cost of the conference swag so I only had to pay the flights out of my pocket.
Then I checked and actually I paid 3,446 USD for the 4 trips.
It would be quite a lot of money to spend on my hobby but I see it also as an investment.
It is part of the scheme to get Perl used more and if my grant request at The Perl Foundation gets approved then my work will bring in enough money to TPF to cover my expenses and get compensation for the time I spend working on this.
So I sent them a detailed list of flights and expenses and within a few hours I got an approval from their board to get 500 Euro helping to cover my costs.
That's awesome. Thank you very much Dutch Perl Mongers!
I officially submitted a talk to YAPC::EU (at the appropriate time, of course) this August.
This will be my first YAPC and I'm very excited. I haven't purchased the tickets yet and it's a bit troubling that I have to make all the arrangements before knowing whether the talk is accepted, since I don't know what to ask $work to sponsor - I hope I won't miss out on room vacancy or flights.
My girlfriend (ferret) will probably be accompanying me. Considering last time we went abroad we stayed in a squat and went to protests/shows/squats, I hope she'll enjoy the tour in Pisa.
My talk is on When Perl Met Android and involves the work being done to run Perl on Android using the ASE project (in which I'm in charge of Perl now.) Hopefully the talk will be interesting enough to get accepted (I opted for a 50 minute long talk.)
2 years into my informatics studies and after a lot of java and absolutely no scripting, I'm wondering if I should stay with perl at all.
Here in Switzerland perl jobs are rare. I mean perl jobs, not "further desired skills: perl / bash".
And telecommuting jobs are mostly not that interesting because I live in a quite expensive country.
Most jobs I've looked at so far are maintenance jobs for legacy systems.
Hmpf.
Thanks to Stuttgart.pm I presented the initial results from the Perl Survey at German Perl Workshop last week. Unfortunately due to a combination of jet-lag (after a 36 hour journey) and stupidity, I didn't record the talk.
There appears to be some very good news in that people use and are enthusiastic about new versions of perl, and the cutting edge perl modules like Moose, Catalyst, DBIx::Class and so on.
Most of the analysis and graphs were done with R, a little Perl, and unfortunately for the CPAN and programming languages questions I had to result to a mix of Perl and manual munging with a spreadsheet.
The survey has generated a very large amount of information, and now that I've got an initial cut of the data analysis, I'll be writing a formal report, and investigating any interesting patterns I find on the way.
All the data is available github. The presentation slides are available from here (sorry about the small font size in some of the legends).
I had this nice 13 hours flight from Israel to Atlanta, GA and now I am at
the airport waiting for my connection to Columbus, OH. Quite last minute
but I have now two talks to give at the conference.
Actually we arrived 30 minutes early but the doors could not be opened
as the custom officers were not in their place yet. Go figure.
Anyway I found a nice spot where I could see the sun rising. It was
very nice but I should rather focus on my talks.
(Re)Packaging CPAN modules by downstream distributions
One of them is about packaging CPAN modules for the various downstream
distributions. It is mostly a bunch of whining on how little is being packaged
with some explanation why does that happen. I'll try to provide some ideas on how we
might break out from the vicious cycle of a chicken and egg problem but I
won't go into how to package CPAN modules for Debian, Fedora or FreeBSD.
Especially as I don't know that stuff.
Recently I've been combining the two main approaches to
parsing Perl.
One of these is the
PPI
module.
The other is the parser in the actual
Perl distribution.
This is usually what is meant when
someone speaks simply of
"the Perl parser".
That
can be confusing
in this context,
so I will call the parser in the distribution,
the Traditional Perl Parser (TPP).
I used the grammar in the TPP
(it's in
perly.y).
But I threw out TPP's lexer
(toke.c).
I replaced
toke.c
with
PPI::Tokenizer,
rewrote TPP's bison grammar to use
Marpa
and put the two together.
To my surprise, mating the
PPI::Tokenizer
and
perly.y
has proved almost easy.
PPI
preserves whitespace and the TPP does not,
so I had to throw whitespace away.
PPI
combines some tokens that TPP separates.
(Notably
PPI
often combines sigils with other things.
The TPP never does.)
Also, there was the slightly more complicated issue of the ghostly semicolons,
which I'll deal with in a bit.
I am currently reading through "Effective Perl Programming". Another fine book that I wish my coworkers would read. (And another fine book they are not going to read). The authors not only want you to write effectively, they want you to write concise code that is easy to read for anyone with a bit of Perl experience. For example, there is a piece of advice in there that says "Avoid excessive punctuation": "[...] Excessive puctuation makes programs less readale [...]" Exactly!
But why is code less readable when it's full of parenthesis, e.g.? I think the answer is simply that the puctuation lowers the signal-to-noise ratio. When reading code, you are looking for the signals, the statements that actually do something, the meat, the beef. A corollary of this is that a bit of whitespace here and there will increase your code's signal-to-noise ratio because it will make the beef stand out.
I used to always scrape little bits of HTML properly, but I rarely bother anymore. I wrote this little bit of code today because I didn't find something on CPAN to do it. That is, nothing that didn't require authentication like Net::Twitter:
when (m[//twitter\.com/(?<user>[^/]+)/status/(?<id>\d+)]) {
require LWP::Simple;
LWP::Simple->import;
my $user = $+{user};
if (my $content = get($ARGV[0])) {
my ($when) = $content =~ m[<span class="published timestamp"[^>]+>(.*?)</span>];
my ($twat) = $content =~ m[<meta content="(?<tweet>.*?)" name="description" />];
if ($when and $twat) {
say "Twat by $user $when: $twat";
It prints the full contents of a tweet to IRC given a URL, here's the full program.
Ubic is a toolkit for describing services on Linux in perl. It's been implemented in-house at Yandex as a better way to run daemons than writing ugly SysV-style /etc/init.d scripts, and i've put it on github and CPAN recently.
I also gave a lightning talk about it at YAPC::Russia::2010 in Kiev several days ago, it should explain most of its traits:
So... any feedback? :)
PS: Several Ubic::Service::* modules are not in public domain yet - i'll have to do some cleanup first, hopefully in next week or two.
After Kieren Diments talk in schorndorf I held a spontaneous lightning talk about the state of the project called Perl 6. The slides wouldn't tell you much, since i pushed them together in 1 hour while listening to others. But i had to do it, since lot of people in the audience I talked with had no clear knowledge and some even said things on stage, that were hardly bearable. Get me right. i can listen to any opinion. No problem if someone says perl 6 sucks goats dick because that implementation will never do because... or that idea is ludicrous because it wil brake ..... but when people say things that simply arent true or if they dont even try to use their brain and don't bring spoken information in the context of the speaking person, I get a bit aggressiv.
I use git for my own projects, and the day-by-day stuff does not involve
much messing with remote repositories. Anyway, it's a fantastic tool to keep
track of the code and avoid losing anything.
getting started (installation apart!)
In the directory for the new project, just init:
git init
Initialized empty Git repository in ...
At this point, there's nothing tracked, so after editing some files
you can add whatever you want to track, either by filename or by
directory name. The fastest thing to do is probably:
git add .
Note that at this point nothing has actually been put inside the
tracking system - you'll have to commit your change:
Today is the last day for proposals for YAPC::EU::2010. I have already the travel tickets, I have already a room in the Hotel. Now, I need to make something to lower my costs in Pisa, for example, to have an accepted talk, and get free entry.
To maximize my chances I proposed two talks, in very different perspectives of Perl:
The problem is that I have various .sql files containing database creation statements like:
DROP TABLE IF EXISTS foo;
CREATE TABLE foo ...
...
...;
It would be wonderful to execute these sql files using DBI’s do method, but do can only execute one statement at a time. Ok, simple enough, just split the file on semicolon, right? Well, often you have stored routines that change the delimiter, mid-statement.
One of the worst programming habits I know of, is assuming that everything will
work out; you just perform the command/function call, and it has to work. In
other words: do not bother checking for error conditions or propagating them,
because they are not going to happen anyway. right?
Wrong.
But the code works. Mostly. Except when an error condition occurs. And it
will, eventually.
In some instances, such code is a glorified
shell script
. I have ranted about that before. But catching error
conditions properly can be tricker than with in-Perl functions and modules.
Especially if you have no control over what the external program does, but the
original programmer did.
Even with in-Perl functions and modules, you
might run into, ehrm,
interesting usage
.
Usually, the root of
the problem is that the original programmer did not foresee that some his code
could grow into something else.
While it may have been a good idea to
create an SQL query wrapper to hide parts of what DBI does for
I'm currently at the stage of reading the Python docs and considering what I'll have to keep track of as regards C type objects, and how to do so. The Python ctypes code is delightfully well documented, particularly this nugget. The Ruby and JS projects unfortunately seem to be entirely lacking in any documentation of their internal functioning, but I think I've got enough to work on.
Para ello, deberemos conocer la ruta absoluta de sendmail (en el ejemplo /usr/sbin/sendmail) y redirigiendo el correo que queremos enviar al mismo sendmail usando la entrada estandar, conseguiremos realizar el envío que deseamos.
El procedimiento es muy sencillo, veamos un ejemplo y despues explicare que es exactamente lo que se está haciendo:
When starting an application, I always strive to reduce dependencies as
much as possible, especially if I know that there's some way that does
not take me too much time to go.
It turns out that I chose one of the worst possible examples.
Check out the comments below and - more importantly - check out
lib documentation!
This happens when I use lib, for example to add ../lib to @INC.
For my own stuff I usually head towards Path::Class:
use Path::Class qw( file );
use lib file(__FILE__)->parent()->parent()->subdir('lib')->stringify();
but when I want to reduce dependencies I revert to
File::Spec::Functions (which is CORE since perl 5.5.4 and now part of
PathTools):
Not sure I agree with the list but figured it was worth posting anyway.
Best Web Design Agencies, the independent authority on the best web designing companies, has announced the best Perl developer in the industry for May 2010. Numerous applicants have contacted the independent authority seeking to be ranked. An independent research team was assigned to review each applicant. After extensive review each of the firms on the list were determined to be the best at PHP development.
An extensive evaluation process performed by an experienced research team with bestwebdesignagencies.com is what separates the best development firms on this list from the rest of the industry. The team also contacts at least three clients of every vendor in order to obtain an evaluation from their perspective. Questions are asked of clients such as, "How easy is the web application to use for various users?" or "Is the code simplified to allow for developers to add onto and document code easily for future development?".