Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jjn1056 (1241)

jjn1056
  (email not shown publicly)
http://www.beijingsolution.com/
+ -

  Comment: Yes, something like this (Score 1) on 2010.09.06 9:24

I personally have been annoyed when I go to work on a project and when I try to run the Makefile.PL for the purposed of getting dependencies installed (either via "make installdeps" or cpanm --installdeps .) I get a list of 'pre dependencies', mostly stuff to get Module::Install bootstrapped. I know there's 'config_requires' but this doesn't seem to help with the problem. Typically I solve it with a hack, when I create a new local::lib for a project I preload most of the common Module::Install plugins I use (via Task::BeLike::JJNAPIORK) and just tell contributors to preload that module before doing "perl Makefile.PL", but that feels too much like a hack, although its only a single extra step. It would be really nice if I could do something like "perl Makefile.PL --list_plugins | cpanm" or even "perl Makefile.PL --bootstrap_author_modules" or similar. On the other hand, perhaps moving toward using Fatpacker, where the Makefile.PL get generated via an authorside build script, similarly to the way App::cpanminus works, might be a more simply solution (athough that would probably get ugly with plugins like Module::Install::Catalyst, since that's part of the Catalyst::Devel package, which depends on Catalyst, and you'd end up Fatpacking a ton of stuff... Maybe Module::Install::Catalyst could be busted out of Catalyst::Devel?) I'm not sure which is the best option, but I do know it would be awesome if I could tell someone all they need to do to get started is clone my repo and do "cpanm --installdeps ." or similar and it just works without having to do some preparation.
Read More 6 comments
Comments: 6
+ -

  Comment: Wow (Score 1) on 2010.07.29 10:01

sounds like fun, will be checking it out
Read More 1 comments
Comments: 1
+ -

  Comment: Amazing (Score 1) on 2010.07.13 14:55

by jjn1056 on 2010.07.13 14:55 (#72163)
Attached to: Announcing CPAN Testers 2.0
Its truly awesome to see how a bunch of concerned Perl programmers are able to come together to pull off such a large and complicated project. The entire community owes this group a pile of kegs :)
Read More 2 comments
Comments: 2
+ -

  Journal: Google: Do No Evil (To Perl) on 2010.03.17 9:38

Journal by jjn1056 on 2010.03.17 9:38
News
Recently wrote about Google Adword API changes that will go live on 22 April 2010 and the negative effect on the Perl community over on my blog: http://jjnapiorkowski.vox.com/library/post/google-do-no-evil-to-perl.html
Read More 0 comments

+ -

  Comment: Wow! (Score 1) on 2009.11.23 22:57

by jjn1056 on 2009.11.23 22:57 (#71224)
Attached to: DBD::SQLite 1.27 now (finally) released
With FK support and online backup this finally makes SQLite something I can consider for more than personal or development needs. I know lots of people have been using in for various production but without FK support I just couldn't recommend it. Thanks to the entire team for this massive effort.
Read More 1 comments
Comments: 1
+ -

  Comment: Awesome! (Score 1) on 2009.11.13 9:09

by jjn1056 on 2009.11.13 9:09 (#71119)
Attached to: The new perl.org is up!
Looks Great! Now if we can just do something about perl.com, which appears to be mostly abandoned....
Read More 5 comments
Comments: 5
+ -

  Comment: Wow! (Score 1) on 2009.10.01 9:12

by jjn1056 on 2009.10.01 9:12 (#70741)
Attached to: Mac-Carbon 0.81 Released
This is really going to solve a lot of silly installation issues on the Mac. Thank you so much!
Read More 1 comments
Comments: 1
+ -

  Comment: Get the newest CPAN (Score 1) on 2009.09.30 8:26

by jjn1056 on 2009.09.30 8:26 (#70713)
Attached to: Why is Perl on Mac such a disaster
One of the issues (and is being discussed in other threads here) is the problem with File::HomeDir requiring the huge and mostly busted Mac::Carbon. CPAN tries to install this because it will use File::HomeDir to decide where to put ".cpan" on platforms where File::HomeDir is available. Unfortunately this ends up putting .cpan in a directory that contains spaces, which tends to break a lot of module tests and compiles, since most tests are written as though unix was the only filesystem, and I also see that many makefiles don't properely escape spaces int he path. So that is probably 99% of the trouble. The very newest cpan won't try to use File::HomeDir on the Mac, it just puts .cpan in $HOME, which is where most unix people expect to find it. So, as long as $HOME doesn't have spaces in the path, you should be find. I was able to compile the newest perl (5.10.1) setup local lib and install Catalyst, Moose, DBIC and a bunch of other things without trouble. So this is getting better.
Read More 44 comments
Comments: 44
+ -

  Comment: So what should be the order of precedence? (Score 1) on 2009.09.29 8:21

by jjn1056 on 2009.09.29 8:21 (#70686)
Attached to: Test::Database, for CPAN testers
For example, in my Test::DBIx::Class module, which is a tool to ease DBIC testing, you can specify a target database type and if you leave the connect info blank, I will try to automatically deploy a database (either mysql or postgresql) to a temporary area. If none of these are available, I fall back to SQLite. So, ideally if you are testing, I should first look for this system, and if it's not setup, fall back to sqlite? Seems like we have some overlapping concerns and might be valuable to collaborate a bit. My stuff is at http://search.cpan.org/dist/Test-DBIx-Class/ and I am currently working on supporting mysql replication. Let me know what you think. At the very least I think I want to use your framework to help with the 'default' mode. john
Read More 2 comments
Comments: 2
+ -

  Comment: Why use Moose... (Score 1) on 2009.09.04 9:39

Well, I use use for pretty much everything so my opinion is suspect. Most of the Pro 'Why Moose' bits have already be said so I will just add one. My gut feeling is that Moose based projects will have a much easier time growing and bringing new developers onboard. That's due to the fact Moose gives you most of what you need to develop well and after it's been in the wild for a few years we have developed a set of best practices. So Moose projects are easier to jump into. Non Moose projects have to incorporate a pile of bits just to be productive, such as something to speed up making accessors, validating parameters, dealing with inheritance ugliness, etc. Usually people end up rolling there own half baked, poorly written solutions, which a newcomer has to figure out before she can even start contributing. With Moose I look at the code and very quickly I know what is what. There are much fewer surprises to me. That's my opinion and I only have anecdotal proof of it. For example, Catalyst pre Moose was being used a lot but development and new releases seemed basically dead for like 18 months. Then, we are on Moose and it's been regular releases and updates. Sure, part of that has been fixing up some of the backcompat issues, but there has been a lot of new things added and there seems to be to be a lot more excitement about the platform. I expect similar things to happen when eventually DBIx::Class moves onto Moose. So, my feeling is that chooing Moose as a core tech makes it a lot easier to grow and manage a development community. That's why I would choose it.
Read More 11 comments
Comments: 11
+ -

  Comment: This is great news! (Score 1) on 2009.08.31 12:23

by jjn1056 on 2009.08.31 12:23 (#70376)
Attached to: Perl 5.10.1 released
This update contains a bunch of stuff that will make Catalyst and DBIx::Class users happy, as well as demonstrates that our ad hoc meritocracy is alive and well. Great work to everyone that donated personal time to get this done.
Read More 1 comments
Comments: 1
+ -

  Comment: Speeding DBIx::Class (Score 1) on 2009.08.19 14:33

by jjn1056 on 2009.08.19 14:33 (#70181)
Attached to: DBIx::Class, Catalyst and Moose Load Time
I find if I declare a base result class and load all my components into that, and then have each of my result classes inherit from that, we get much improved loading time.
Read More 3 comments
Comments: 3
+ -

  Comment: Re:Okay author of MooseX::Types::Structured listen (Score 1) on 2009.08.14 9:38

well, META.yml gets generated automatically, I guess you want me to editted manually? I guess I don't really get it, I just patterned my Makefile.PL against some other big distros, like DBIC, Moose, etc and just assumed they knew what that are doing.
Read More 15 comments
Comments: 15
+ -

  Comment: Re:Okay author of MooseX::Types::Structured listen (Score 1) on 2009.08.14 9:12

Well, That sucks. I changed it, tagged it and released it. "recommends" didn't give any errors when I ran perl Makefile.PL, and the rest. Now I have to go figure out what I need to change and change it again :(
Read More 15 comments
Comments: 15
+ -

  Comment: Re:Okay author of MooseX::Types::Structured listen (Score 1) on 2009.08.13 16:28

okay, I'll do this today or tomorrow then
Read More 15 comments
Comments: 15