After a marathon hacking session yesterday I’ve got a working server up for The Captain Is Dead (TCID). Many video games can be developed by basically creating a state machine, which is essentially what I’ve done for TCID. All you’re doing is tracking the set up of the game map, and what state all of the components attached to the map (including the players) are in.
I’m writing TCID video game in Perl using a toolkit we developed in-house called Wing. Wing is effectively a set of preferences for developing web-service enabled web apps. It glues together all our favorite components such as DBIx::Class, Dancer, Moose, Config::JSON, jQuery, pNotify, Bootstrap, beanstalkd, and a whole lot more. Without it there’s no way I would have been able to build out a working video game server in a day.
Lot’s yet to do, but I’m glad to finally get started on this project.
Or how to execute arbitrary Perl code using Gearman and B::Deparse.
Perl offers us the flexibility that empowers us to clearly separate code that deals with different concerns.
As developers, we should take advantage of it and build reactive, flexible and generic enough business components.
As an infrastructure developer, I don't really know what people are going to do with gearman, nor should I care too much. I'll introduce an approach that lets me concentrate on what is important: the stability, scalability and the security of my gearman workers.
As an application developer, I don't care that I have to encode my functions parameters in a certain way. And I don't want to bother changing code in some obscure gearman module when I make changes to my business code.
What I want is to use gearman as a facility that helps me design the best possible application without getting on my way too much.
Building a complex web app almost never goes without the need to write a handful of command line tools. Whether it's to alter the database schema, convert image files, or move records from one format to another, you know you'll have to create a bin directory and fill it up with CLTs.
The Perl Kelp web framework makes this task easy with its robust and flexible configuration module. The default config file lives in conf/config.pl and contains a Perl hash of configuration options. For example:
Wing has long been able to generate internal object relationships thanks to the goodness that is DBIx::Class, but now it can automatically write the web services for those relationships as well, thanks to two new subs in Wing::Rest:
generate_relationship(object_type, relationship_name) - This writes out a simple web service that will expose a list of “relationship_name” objects that are attached to “object_type”.
generate_all_relationships(object_type) - This interrogates DBIx::Class to find all the relationship objects and then calls generate_relationship() on each of them.
I love open source programming. I’m continually humbled to see even the small impacts that my contributions to the Perl community have made for fellow programmers around the world. Mostly my use of Perl has been to write a complex simulation and the tools that it uses to simulate the dynamics of electron bunches in an Ultrafast Electron Microscope column, which is the subject of my recent Ph.D. thesis. So while I have enjoyed sharing my work both here and at the 2012 YAPC::NA I never would have expected that my name would mean too much in the greater Perl world.
The event takes place every Sunday at Alley NYC. The midtown venue is a shared office space open between 12-4pm with room for 100+ hackers, power, wifi and kitchen facilities. A youngish crowd and a relaxed, friendly vibe, there are no presentations or planned activities - just turn up and hack solo or chat with people and code together. Most people I met were budding Ruby programmers from a local college. I really enjoyed it and will be heading back there frequently (including tomorrow). If you're heading down to Alley NYC drop me an email if you'd like to chat / hack Perl.
N.B. Hacker Hours are another meetup group that uses the Alley NYC space on Sunday at the same time. I didn't notice any distinction between the two groups.
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.