alias unused='perlcritic --single-policy ProhibitUnusedVariables'
However, I found a few cases where it didn't work. That's when mithaldu told me about warnings::unused. I installed it locally and ran it on some code which had a case that ProhibitUnusedVariables didn't find:
Whoa! The one area were Perl::Critic modules repeatedly break for me is when I'm dealing with scope issues. It appears to miss where a variable is legitimately declared and used in one sub, but declared and unused in another. It also missed something like the following:
There are definitely more and more people involved with Dancer which makes me proud.
Alberto Manuel Brandão Simões (ambs) has been putting a lot of development work into Dancer recently, improving it in ways we haven't even thought about. Flavio Poletti has been also offering some commits, and more importantly, takes the time to help newbies within the Dancer community (successfully, might I add!) and we can see more and more new-comers giving us good feedback and pull requests.
However, as much as all the aforementioned people deserve their own posts for their work (which isn't just the code, but the motivation they give others), this post is about someone else. A person by the name of Puneet Kishor.
Puneet has been a member of the Dancer community for a long while now. He has been writing quite a bit on the mailing list, and raises a lot of inquiries, possible bugs, feature suggestions and general issues such as recommended writing methodologies.
Khan Academy If you have or know any children who are in school, this is an awesome resource, Sal is an excellent and talented teacher . The video's are ten minutes in length and of very good quality.
This Javascript exercise by John Resig ( Jquery creator) is a good way to learn some advance javascript
This Clojure article is a pretty good way to get your feet wet in getting started with Clojure programming.
If you want to get started with HTML5 this is a pretty good book , You can also order a print version here
My employer kindly (and prudently) gave me the go ahead to open source our interface to Yahoo's awesome search API. First release version is crude, but it works. Patches welcome. I just pushed 0.03 to PAUSE, so it should be available at a CPAN mirror near you shortly.
For a long time now, I've been thinking how to organize my information about people, their addresses, phone numbers and birthdays, their websites and code they've contributed to, codename "Hoover". But there are some problems that always keep me from writing more than the bland user interface I've come up with so far.
The main problem is, that I'm no good with user interfaces. So I'd like to reuse somebody elses user interface and just import the data into it. Perl is good at that. But I'm not aware of a sufficiently good data store with sufficiently nice user interface. There are some proprietary solutions that have good to horrible integration with other programs:
The Windows Address Book is a pain to import and export, and it doesn't support custom properties of contacts.
Thunderbird is fair to automate (through Mozrepl). Adding custom fields is possible, and there are already some premade importers, for example for Gravatar images.
Building my own LDAP schema would be the enterprisey solution, but getting applications to talk to it seems hard. Having only Thunderbird available to read from the LDAP also makes this a solution less desireable.
Ideally, I want a storage format that (I) can synchronize with my mobile phone and automate from Perl, to keep the information synchronized with the interwebs.
Both articles are a mouthful, and try to be very thorough in the advices and ideas they present. Sadly, both miss the point completely by assuming that "contributing" means "committing code". And this is not only wrong, its part of the reason people hesitate to contribute
For starters, "Open Source" projects tend to be seen as a hard-core programmers-only club, where you have to know how to program (mainly in C/C++), or you have no reason to be there. Seeing that the high profile projects are such complex systems, I can understand how did this image.
There has been a bit of discussion recently on the #distzilla IRC channel about how people are integrating their CPAN distribution development with Git, and in particular some of the Dist::ZillaGit plugin(s). I thought it might contribute to a useful discussion if I show how I have things set up.
Like many, I want to host my code on GitHub and then periodically publish to CPAN. Dist::Zilla helps in both these by providing plugins to automatically push releases to GitHub, and then also upload to CPAN.
What bothers some is the stage at which these things happen, and also how the branches and tags are represented on GitHub. In particular, folks might want:
a "clean" git branch which tracks CPAN releases
another branch which is the "trunk" of development
a user browsing the GitHub website to see the CPAN branch (with the README, etc)
I've just released Dancer::Plugin::Database 1.00 to CPAN. This includes Alan Haggai's patch to supply runtime configuration info to the database keyword as a hashref (thanks, Alan!) which was already released as a developer release, 0.91_01.
I've bumped the version to 1.00 to indicate that I consider it stable and ready for use in production, for those users who mistrust any module with a 0.xx version number.
Over the years it has become abundantly clear to me that people who object to OO fall into two categories:
A handful of people who really understand object-oriented programming.
Wankers with blogs.
Though I don't object to OO, it's still unclear which of the above categories I fall into. I suspect it's not the first.
This brings me to a lovely quote from H. L Mencken, "for every complex problem, there is a solution that is simple, neat, and wrong" (annoyingly, there are tons of subtle variations on that quote. I need to find the original). A "solution" I had in Role::Basic was was simple, neat, and wrong. I'm kicking myself, but my problem was my failure to apply what I thought I had "learned" from the original traits papers.
All:
The group I manage is severely understaffed and one of my most competent employees has just tendered their resignation.
This blog entry is not an official job announcement. The official announcement will be made available online once it is finalized. I would just like to touch base with anyone who might be interested.
I want to be clear that, though we use perl every day, this is not a "software developer" position. My group works in a technical support capacity doing everything from providing recommendations on architecture and design reviews to writing utilities to extract data from logs. The primary skills that I need are scripting (perl/shell), SQL/stored procedures, trouble shooting/problem solving/critical thinking, Unix (AIX/Solaris) and security concepts/best practices.
The position is in the Baltimore/Washington D.C. area and relocation expenses are not included.
Please contact me if you are interested so that we might touch base.
Ok, I must admit that we havn't posted something for quite some time. We actually held our meetings and everything, but there was nothing of interest so far. But recently at Christmas time we had our special christmas meeting.
Lots of Perl mongers become busy at christmas time. Buying gifts and stuff, you know, the usual pre-Christmas stress. Other mongers are allready traveling throughout the country visiting relatives for christmas. Though not everyone is able to attend to the last meeting of the year. Our last meeting dates were late in December and therefore very close to Christmas eve.
Thats why it has become a habbit to give relatives and friends of our the ability to check what we "weird" guys are doing when we are out for the "Programmers-Meeting".
So we had some attendies at our meeting who are not into programming. Of course talking about Perl and stuff need to set back a bit that evening, we didn't want to scare non-programmers away with techno-babble. But on the other hand someone brought tiny chocolade Santa Clauses to the meeting. And it is quite interessenting getting to know the social surroundings of our fellow members. You know, we are not just programmers trying to help each other, we are also some kind of friends here.
Perl test output (the so-called "Test Anything Protocol" or "TAP") is simple: "1..N" declaring that N tests are planned, then either comments starting with "#", or lines starting with "ok X" or "not ok X" saying whether or not test number X succeeded. Generating it should be simple. Parsing it should be almost as simple.
However, the code to generate and parse test output is a byzantine nightmare: Test::Simple and its dependencies are at least 1345 SLOC, and the various TAP-parsing modules are at least 3918 SLOC (including an IteratorFactory!).
Both generating and parsing the subset of "TAP" used by most programs can take around 50 SLOC. This seems like a perfect opportunity for a ::Tiny module.
Every now and then, I can't remember the exact semantic of a function or module, and every now and then the documentation is not quite clearstraight about it. Then I gotta see the code running to make sure. Eventually my own personal memory stack will overflow and I will need to revisit some of this information. Here it's where:
Perl has so many useful builtins that most people who use the language probably only use a fraction of what's available. Every year or so I like to peruse perlfunc and perlsyn as a refresher. Yet in years and years of hacking Perl code, there are a few in there that I will never use. I surprised myself the other day by reaching for the loop control command redo. It occurred to me that while I use other loop controlling things like next and last constantly, I couldn't remember a single time before when I have ever had to redo an iteration. For the curious, here's the astonishingly simple scenario where it came up.
It's frustrating to me that I have limited bandwidth right now. A new job, a new country, a (soon to be) new baby, and a new blogging venture have all conspired to ensure that I don't have as much time for writing software outside of work. However, I've been working hard on Role::Basic and following a suggestion from Stevan Little, I've started [a branch with Moose::Role tests](
https://github.com/Ovid/Role-Basic/tree/moose_tests) and have started working through them. Some are clearly inapplicable (for example, Role::Basic has no notion of attributes), but a few have given me pause. I wasn't sure if they were supporting original traits behavior or if they were extensions for Moose. Since I've already ready the original traits paper (pdf) several times, I decided to move on to Traits: The Formal Model (pdf) to make sure I hadn't missed anything. There are some interesting bits there.
After half a day of yak-shaving that started with having to port yet another Makefile.PL to the dist.ini format, I am now finally able to post this small snippet of elisp code to blogs.perl.org from within emacs (more on that later):
I don't think this is documented anywhere, so let me blog about it before I forget it. Install the module CPANDB. See if it works by running one sample program, maybe:
use CPANDB;
use YAML::Syck;
print Dump [CPANDB::Distribution->select
("order by volatility desc limit 1")];
It may take a while but you will get something like this:
SslAuth uses the recently added TLS certificate authentication support in Mojolicious 1.01.
The first argument passed to the callback sub is the IO handle, giving you access to whatever IO::Socket::SSL provides. (get_cipher, for example).
ParamsAuth is very basic, its purpose being to keep your params-based authentication uniform with other auth-types.
The arguments passed to the callback are the values from the named form or query parameters.
BasicAuth has been around for a while, and uses a similar interface:
If you're looking to be hip with the latest oauth goodness, Marcus Ramberg recently released Mojolicious::Plugin::OAuth2.
...
On a side note, Вячеслав Тихановский (vti) updated MojoX::Validator only days ago. It is, to date, the only form validation helper that doesn't make me think Amway would have been a better career choice. It can be integrated into Mojolicious or used separately. And, like Mojolicious, the code is easy to understand and contribute to. Join up!
