This year the London Perl Workshop has taken the bold step of having tickets for the event. They are priced in four stages and are entirely voluntary as to which stage you purchase:
Workshop Attendee (zero pounds)
The London Perl Workshop is a free to attend event which means we place no fiscal barrier to being there. All persons are eligible for a ticket.
Workshop Friend (twenty-five pounds)
A friend of the Workshop is helping to support the event they respect, and we admire your brio in doing so.
Workshop Lover (fifty pounds)
Wow, you really like us, and this stunning contribution will be used at this event and next year.
Workshop Sponsor (one hundred pounds)
You realise this makes you a SPONSOR! It also makes you a star, contributions at this level are making a great impact and we thank you for making that special choice.
I have recently started a new job and it has forced me to learn more Python than I have ever had need to learn. I decided that I should take this as an opportunity to learn, and as Miyagawa-san has often done, steal when possible.
One thing that fascinated me is Python’s yield or generator pattern. In this pattern, you can make a function (or my case an object) which implements a lazy iterator returning a value (or possibly values (see below)) without leaving the while loop that generates them.
Following up to szabgab's blogpost: a couple of years ago, I called out for people interested in getting together to make a new Perl group here in my country, the Philippines. I saw that there were already some registered Perl mongers groups in pm.org for Makati, Manila, and elsewhere, but all of their websites, and even the contact persons listed form, were simply inactive or unreachable. There were a few people responding to my call, but I made the mistake of not following through to that call myself, due to other circumstances happening at that time.
A while back I said "just build something”. That was a bit of a lie. You need to build something people want. Don’t be the one who builds something s/he thinks people want. Make sure. Do you want it? Are you building it for someone who will use it immediately? Do you work somewhere that could use it if it existed? Do some basic market research. If you build something people want, then you’re already on your way to success.
If you try to install Term::ReadLine::Gnu on Mac OS X, you will ordinarily run into this unpleasantry from the Makefile.PL (which will likely end up in such as ~/.cpanm/build.log):
The libreadline you are using is the libedit library. Use the GNU Readline Library.
Here I will assume that you are using Homebrew and have installed GNU Readline:
brew install readline
Even so, you will get this error. This is because of how Homebrew installs Readline. Since OS X ships libedit as libreadline, Homebrew tries to avoid conflicts with system software by installing Readline as “keg-only” software – that is, it’ll install it within its package-managed filesystem hierarchy beneath /usr/local/Cellar, but it won’t link the libraries into /usr/local/lib, so that they won’t be visible to software that isn’t explicitly linked against it.
Today I checked the 1,000 most recently uploaded modules again:
Date
Has license
Has repository link
December 2012
82.6%
49.6%
February 2013
83.4%
49.7%
July 2013
87%
60.1%
It's a nice improvement, but remember these are the 1,000 most recent uploads. The percantages would be a lot lower if we looked at all the packages currently on CPAN.
I think both of these numbers should be around 99.7%.
If you'd like to check your module, you can use the metacpan_meta.pl 1000 PAUSEID command with you PAUSEID after installing MetaCPAN::Clients. That will show the 1000 most recent upload for the given PAUSEID. Even if some of them were 5 years ago. It will also show the list of offending distributions.
If you'd like to update them, here are two articles I wrote showing how to make that happen: link to repository and add license field to META files.
Possible you've read the grep test, particularly if you read Hacker News. The premise of "the grep test" is that if you write code that is not greppable, you fail "the grep test". Whether or not this is a good thing is a matter of debate, but here's my experience.
If you are a software developer and have created or are creating a start-up, then please do not forget about building a web services API. Not only will it be an excellent way to build out a web site and connect mobile clients, but a web services API can be an excellent marketing tool.
The API allows other people to build their own stuff on top of your API. Sometimes these will just be hobbyists playing around, but those hobbyists can be an excellent marketing tool as they’ll likely write blog posts and release their source code out on GitHub, or elsewhere. In addition, businesses may tie into your service, which is not only an additional source of revenue, but they’ll likely tout their integration with you on their web site.
I received a massive amount of feedback: here, on the mailing list and in private email. I humbly thank all of you for the many words of encouragement. I am planning to summarize in more detail what I took away from this in a separate post soon (once I am back from an internetless trip this weekend).
Original Text
TL;DR - There is this thing called
DBIx::Class
. It has a number of users, and a number of staunch non-users, which is all fine. Bottom line - it seems to be
relatively important
. For good AND for bad, I happen to be an
integral part
of this project for nearly 5 years. A number of my friends (who badgered me into writing this) believe that I am in a relatively unique position to "to boldly take this project where no ORM has gone before". Furthermore I am at a life-junction where I
indeed
OP: because i was getting errors and warnings because not all variables are defined as "my" or "our". it is for testing purposes only. I will uncomment that line later when the script works.
Pinto is great and helps create custom repositories of cpan packages, tune dependencies and get vital information about your distributions. One thing I lack is to propagate changes in source control as new distributions in pinto stacks and also new distributions for production servers. So this why I have created tool named "jam". Now it's in prototype stage, but it give a sense the way of automation.
One have list of code sources with changes get pulled from scm triggering new distributions holding changes and new distribution of application, dependent on those new ones. This processes get automated by jam. All you need - install pinto and jam, checkout sources and set configuration file:
I have never been a fan of Perl's operator overloading support, not only is the API kind of awkward, but the functionality is limited and fairly inflexible (at least compared to other languages like OCaml and Scala). But that said, I felt it was important to have some support for it in the new p5-mop.
As many of you know, the Moose module has a metaobject protocol, but it's not something that many casual hackers use. Truth be told, I don't use it a lot either, but when I do, it saves me a lot of hassle. I've been writing an extremely complicated data importer and at the end, I didn't so much need a summary of the data, but a summary of what the importer did. That's when Moose metadata made my life so much easier and my code more maintainable.
This is github clone. you can install portable github system into unix/linux.
We konw gitweb.cgi, but this is a little difficult to use, and GitHub become defact standard.
User is happy to use GitHub interface when he create private repository on the server in company.
Perl and Mojolicious is great. GitPrep can work in both CGI and prefork built-in server and PSGI. You can use GitPrep uploading shared rental server as CGI script.
GitLab is difficult to install. but GitPrep is easy to install. requirement is only Perl 5.8.7.
Mojolicious need perl 5.10.1 but mojo-legacy project need Perl 5.8.7.
mojo-legacy author is jamadam. he is Japanese programer.
GitPrep is useful to see git repository on your server. Enjoy!
One of the pain points of MetaCPAN is that URLs don't always point where you would expect them to. For example, should a script be found under metacpan.org/module/*? Does that make sense? What happens when someone releases a module with the name of the script? Please note that we're talking about the URLs on the search front end, not the API.
We've struggled for a long while with questions like this. How do we structure URLs on metacpan.org which have a sensible hierarchy? URLs (like version numbers) should be boring -- we don't want them to offer any surprises.
The bulk of the discussion on this topic can be found in this issue. However, if you want to weigh in on this without wading through the entire discussion, hop down to this comment and start from there.
Or should I say lack thereof. This period witnessed some rather major change in my personal life. I got married and moved to an apartment. So between the preparation for the wedding, the honeymoon, and the moving, there was little time and attention for long sessions of hacking.
What I managed to do is release minor updates for some of my CPAN modules: