For those of you using Macs, are you using Perl as it ships with OS X, the Perl MacPort, or are you compiling your own? If you could briefly explain why you use the one you do. I agonize over this every couple of months, and finally decided to sample a larger bit of the community this time around.
Like so many others before me, I have moved my CPAN modules over to github.
With that being said, I would avoid using CGI::Application::Plugin::CAPTCHA at this time, at least for anything too serious. It's a suitable speed bump, but has a glaring hole you can drive a truck through. I have a fix sitting here from Cees Hek that addresses that issue. Should see a new version sometime in the near future.
We're primarily a Windows shop. That doesn't have to relegate us to second-class citizens in the software development world, however. We have long used Perl for our web-based products, and development of our Windows client apps has gradually come to incorporate some of the practices and tools that we've grown accustomed to when developing in Perl.
In the not-so-distant future, we're taking a huge step off of Visual SourceSafe and moving to Subversion. We've long been using Subversion for our web apps, and upcoming developments in Powerbuilder will finally allow us to migrate away from VSS once and for all. We have a comfort level with Subversion, but before we totally take the plunge, we wanted to find ways to get more out of our version control software. Enter Growl.
Those of you who have used Growl on OS/X, you might not be aware that a Windows port is also available. It's kinda rough around the edges, but for the most part is pretty stable and handy. We wanted to use Growl to notify developers of recent commits to the source tree. Some of you might already do this, or something more robust, but it's something we recently implemented, and it's been tremendously useful. I find that developers are more informed as to what other people are up to, and gives people a gentle reminder to update their sandbox every now and again
To get started, make sure you have a Subversion server in place. If you are hosting repositories on a Windows server, I highly recommend VisualSVN Server. It has a nice MMC snap-in, and is easy for anyone with Windows experience to administrate. Install Growl for Windows on the same box - you're going to need it to communicate with your developers. When configuring Growl, make sure to enable "Allow Network Notifications" and "Allow Clients to Subscribe to Notifications". You will also have to add a password - network Growl (at least on Windows) will not work without one.
Create a sandbox on your Subversion server. The post-commit hooks will need one to operate on. You can use our post-commit hook scripts as a starting point.
post-commit.bat is what is actually run by Subversion. It executes post-commit-run.bat and logs the output (I can't take credit for this - I got the idea from Dan G. Switzer's blog). If something bad happens, this log is the only way you're going to see what it is.
post-commit-run.bat does a couple of things for us. It updates the copy of the sandbox on the Subversion server, then captures the log entry of the last commit. It then executes some Perl that broadcasts that log message over Growl. The first time you use this batch file, make sure you specify the user name and password of a Subversion user on the svn calls to give Subversion an opportunity to cache credentials. I haven't found another way of accomplishing this (and I am open to suggestions here!). Once the hook is run, you can remove them from the batch file.
To make Subversion cache credentials on Windows, add the following registry entries through regedit:
(taken from the online Subversion book)
As for the Perl program, it simply uses GNTP::Growl to broadcast the latest log message over Growl. I do not think that Growl on Mac currently supports GNTP, but think there is plans for such in the hopper.
Each developer that is receiving notifications will need Growl installed. On the Network tab, they should create a subscription to the Subversion server machine.
This isn't elegant, but it has worked pretty well for us.
Good luck! Hope you find this useful!
So I am trying to get a URL that looks like this:
Instead, I am getting URLs that look like:
In my template, I tried this:
[% c.uri_for( 'edit', [ item_type.type_id ]) %]
which gave me the latter URL. If I do this:
[% c.uri_for(c.controller('Admin::ItemType').action_for('edit'), [item_type.type_id] ) %]
I get what I want, but it seems too clunky to be doing in my view. Is there a simpler way to write that and have it still work? It seems like too common a thing to not have there be a simpler way, but I am just not finding it.
I've started a new project, and given that it's for my own enjoyment, I have the time to try out a few new things. At the suggestion of rjbs, I'm giving Catalyst, TT, and DBIx::Class a shot.
So far, I've been the happiest with TT. As a long-time HTML::Template user, I am totally drunk with the power that TT provides me with (yes, Uncle Ben, with great power comes great responsibility...). I've been a long-time purist in not wanting to intermingle code with presentation, but as I am finding with TT, there are some things (like how data is formatted) that should be left to the designer to decide. HTML::Template left designers with little ability to do some of those things (though Rhesa and Mark's work on HTML::Template::Plugin::Dot went a long way to bridge that gap).
DBIx::Class... I can't imagine how I lived without it either. While I haven't had some of the issues with Class::DBI that others have had, my company does have some ugly schema in spots that is just not practical to refactor in our current time crunch. Unfortunately, CDBI doesn't deal well with some of the problems in our schema, and because of it, we miss out on some of CDBI's features. DBIx::Class handles these without issue, and the syntactic sugar makes it a pleasure to work with.
Catalyst I am not sold on. Not that I think it's bad, but there's a lot I don't understand about it. CGI::Application has always been simple and straightforward... Catalyst does a lot more for me out of the box, but spotty documentation in spots has sure made it hard for me to figure out how to use some of it. That being said, I love how multiple views and models are handled in Catalyst. It's very sweet.
(and no, I'm not trying to bitch about Catalyst's docs. I might even submit some patches for the docs, time willing).
All in all, it's been a positive experience. I enjoy expanding my horizons, and learning new tools gives me new ideas and appreciation for the tools I have become accustomed to.
I've always harassed my wife about her black thumb. Every time she tries to deal with plant life, it dies. Well, I am experiencing the same thing with anything that plugs in lately. Yesterday's list of casualties:
It has not been a good week.
Make it stop, please!
I was setting up a network for a family friend's business last night, and stumbled across some of the worst Windows software I've seen in some time. The software has been around since the DOS days, and about two or three years ago, it was completely rewritten for Windows, but some of the DOS-isms remained. Mostly, it had to do with printing.
I didn't immediately notice this at first, but every printer that works with the software has to have a local printer port assigned to it (LPT1, LPT2, etc.) and be referenced by such within the software. It's.... archaic, but workable. My friend has two offices, and they wanted to remotely connect from one office to the other, access the other office's records, and print them locally. Remote Desktop will pass your printers through to the remote host, offering them up as local printers. It even assigns port numbers to them, beginning with TS. Problem is that the stupid ass software ONLY prints to printers who's port number begins with LPT.
Stupid stupid stupid. I want to slap those developers.
Some of these aren't necessarily Mac-specific.... but I thought I'd share some of my favorite Mac tools:
That's all I got for now. What are some of your favorite tools? Please avoid starting any editor wars!
I was fighting with Apache2 + mod_ssl on my OS X box for a while, and as it turned out, I was missing something pretty simple that wasn't documented that well anywhere. I'm posting this in hopes that I save others the same frustration.
I built Apache in the following manner:
./configure --prefix=/opt/apache20 --enable-ssl --with-ssl=/opt/local
And when I ran:
I got this in my error log:
[Thu Jan 25 09:04:49 2007] [emerg] (13)Permission denied: couldn't grab the accept mutex
[Thu Jan 25 09:04:50 2007] [alert] Child 29791 returned a Fatal error... Apache is exiting!
Makes it hard to develop a webapp when your webserver fails to start
Come to find out that on OS X, using an
default wasn't good enough. Apparently, OS X wants it set explicitly to
Hope some of you find this helpful.
If you need ODBC in your Perl programs on OS X, don't try to build DBD::ODBC against Apple's built-in driver manager - it's an exercise in futility. After struggling with it for some time, I built a vanilla iODBC driver manager in
Now if any of you have managed to make DBD::ODBC work with Apple's driver manager, I'd love to hear how. I searched for a while, but turned up nothing.