You can send only echo command in this example for security.
I want to create Web applications more, because ruby web development is active, but Perl is not. I want many people to use Perl. so Web applications which is created by Perl is needed.
I had an idea for the Benchmarking chapter of Mastering Perl but I don't have time to implement it. But, with many of my ideas, someone probably already has.
The DBI::Profile module hooks into DBI calls to monitor database queries. The autodie replaces some built-ins so they error-out differently.
Could we do the same thing with the low level networking calls to measure octets read and sent? Of course, there would be a performance hit (as with the those two modules), but that's what we expect when we benchmark. Maybe it would work like Devel::Cover where it writes intermediate data files that another program analyzes to create the report.
I've been looking around for extra-script solutions to this, and they tend to be uniformly linux-specific and wrong. I also want something that handles the entire process group, so child processes count.
As far as I can see, the various network tools aren't process aware; they can see ports and IPs, but per process stuff. A process can have a local port to itself, but that doesn't mean it keeps it, letting another process use it for a bit.
Recently I released version 1.00 of WWW::betfair. It provides an OO Perl Programming interface to the betfair API.
betfair is a sports betting services provider best known for hosting the largest sports betting exchange in the world. The sports betting exchange works like a marketplace: betfair provides an anonymous platform for individuals to offer and take bets on sports events at a certain price and size; it is the ebay of betting. Unfortunately betfair is not available in all countries including the US. I hope that will change in the future.
Check out the module's documentation for more information about betfair and the available API methods
I was really looking forward to YAPC::Europe next week in Kiev. The talks looked great and I was looking forward to seeing the Perl community. However, for work reasons I won't make it. This sucks.
Many people talk about TIOBE and how it's bad, or irrelevant, or broken, or many other vague descriptors of why it should be ignored.
All people talking about TIOBE miss one crucial point: It is software, it has an algorithm, and it is not "bad", it is buggy. That means it can be fixed.
So either fix it, or stop talking about it.
Here's why you can fix it
The TIOBE algorithm is to search for "[language] programming" on a number of search engines, then apply a weight to the resulting count, based on the search engine, and sum the results up to get a score.
Actually, there is even an RSS feed suitable for podcatchers. In case you'd like to listen to the earlier episodes while driving to work, check it out on the Perl Maven TV page.
Today TIOBE roll out his Programming Community Index for August 2013. Since it added many new searching engines perl slide rapidly down from 9 to 11 compared to last year.
I’m not surprised seeing this happened. it’s 2013, not 2003. except regex, I can’t see perl has any unique feature can dominate any common programming field. (yes, we have CPAN, but you can’t ask a newbie can adeptly choose parts in it to assemble in a canon. ;) ) With more knowing perl, I can more an more understand perl’s shortcomings.
It has been said that we need more Perl startups. I agree and have written CloseBargains.com - what better way to get a heapin helpin of local coupons than Perl, Mojolicious, Linux, and some 8coupons API goodness served up by hypnotoad. The frontend is done in jQuery Mobile; another buzzword that needs adding is that Backbone.js needs to be integrated for coolness factor.
While there are many who really appreciate the work of CPAN Testers, and value the feedback it gives, but it would seem there are still several people who are less than complimentary. One recently posted about what they see as wrong with the project, while continually making incorrect and misguided references. What follows is my attempt to explain and clarify many often mistaken facts about CPAN Testers.
(this is the email sent to the Dancer users mailing list, updating on recent releases)
Hey everyone,
I would like to get back into the habit of letting everyone know what's going on with Dancer. This means keeping you up to date on releases and our plans for the future.
1. Read documentation. Check changelog, check open bugs. Use only "good" modules.
3. Decide which API of module/perl function to use and how.
3. Write code, write tests. Write assertions in production code. Write proper error handling.
4. Test on several perl versions and several module versions.
5. If tests fail somewhere, investigate, change minimum version requirements or workaround problem.
6. Write down strict minimum dependencies in makefile etc.
Second way:
1. Briefly read documentation.
2. Write code
3. Test manually.
4. pin module version
5. always use one version of perl, use perlbrew, never upgrade.
So I think Second Way just introduces a technical debt. You save time during development, but the end
you have no idea how your code works and where.
I see lot's of advices to use perlbrew instead of system perl, because system perl can be broken (it can, indeed), articles about Gemfile-lock-like systems.
I spent much of last week on vacation with the family so very little actual coding got done on the p5-mop, but instead I did a lot of thinking. My next major goal for the p5-mop is to port a module written in Moose, in particular, one that uses many different Moose features. The module I have chosen to port is Bread::Board and I chose it for two reasons; first, it was the first real module that I wrote using Moose and second, it makes heavy use of a lot of Moose's features. I actually expect this port to be much more involved and require more actual design changes then the other ports have, simply because not all the Moose features used will be easily translated into MOP idioms. So in preparation for this I have been doing a lot of thinking about mapping the MOP to Moose and even started writing some documentation for it.
Jean-Damien Durand has just released
MarpaX::Languages::C::AST,
which parses C language into an abstract syntax tree (AST).
MarpaX::Languages::C::AST has been tested against
Perl's C source code, as well as Marpa's own C source.
UAV::Pilot, a Perl library for controlling the Parrot AR.Drone, has released version 0.5.
This was the big one. With the ffmpeg library installed, you can decode the h.264 video stream coming right off the drone, in real time. This is where UAV::Pilot starts to get really interesting, opening up applications like augmented reality games and object recognition.
I'm going to be taking a short break from working on UAV::Pilot for a while. After lazing about, I'll start work on the next release, which will mostly be cleaning up the API and bugs.
Also, I'll be giving a presentation on UAV::Pilot in September for the Madison Perlmongers Group, which I plan on recording.