I've been working pretty much exclusively in Java for the last few years. However, we have a subproject to do some system/application automation work that's written in Perl. It's currently a CLI tool that allows us to install/upgrade our application remotely, restart the service(s) (the app runs on Solaris), and other fun stuff.
We're not only expanding its scope, but we're giving it a nice shiny GUI shell via a website. After working for years on Perl webapps I've been out of the loop for years. That can actually be a worse position than not knowing anything, because I have outdated ideas and biases as to how things 'should' work.
And now we get to my question. It looks like people are commonly using Catalyst, CGI:Application, Jifty. Are there others? And what's the "best" one to use?
Perl is supported at our company for a nifty internal testing/automation suite, some build automation, and probably under-the-radar stuff, but that's about it.
By comparison, this is a project we're not only hoping will be long-lived, but it will be deployed on servers not in our control (thus the Krang-like deployment above), and used by people (mostly IT staff) not in our control.
Will they freak out that this is a Perl app? Unknown -- what do you think? (This is IT in healthcare, FWIW.) Do we even need to tell them it's Perl (e.g., "it's a black box")? Unknown, but IMO we likely do.
Reading the recent 'perl is dying/dead' threads here [on use.perl] also makes me wonder about hiring. Hearing that quality organizations are having trouble finding competent Perl developers is disturbing, whatever the reason. For instance, take Grant Street. From what I've heard, they have a solid team that gets to work on pretty interesting stuff, not your typical CRUD tedium. You'd think with that combo they'd attract competent people like honey attracts bears. But they're always looking.
There's always an argument that you can hire someone smart and they can just "pick up" the language/platform. I think that's true if you have 6-12 months to burn. It's easy to learn a language, even Perl. It's harder and more time-consuming to learn its ecosystem -- which modules to use and not-use, idioms, approaches for common tasks, etc. It's not that these things are required to get things done, it's that the rest of the team will have to go over all of the new hire's work much more closely.
 Wasn't there a project to extract the Krang build logic into something self-contained? The projects occupying that area of my brain are 'Smolder' (which is aimed at code coverage and reports) and 'Matchstick' (which looks to have been abandoned). Is there something else?
There's a nice response from Bob on my thoughts on small vs large teams. He raises a bunch of good points, go read 'em.
Re-reading what I wrote, it sounds a bit like I'm a large team guy. People I work with know better: I'm quite the opposite. The largest development team I've ever worked on is what I'm on now -- seven developers, four on the server-side (including me) and three for the application on our wearable device (although we get to steal them sometimes). And one of the server-side folks came on four weeks ago.
And even at one point when we had the potential of bringing other folks temporarily on the team for our last three months before product intro, I resisted. Primarily because software isn't a generic thing you're building, it only makes sense in a context. And our containx (nursing homes) isn't something you can pickup overnight. So I saw that maybe we could get lots of code produced, but we'd be cleaning it up for the life of the product.
Anyway, what I wrote was primarily a response what I saw as some naive thinking. When someone says that a team of three people can do anything, I hear "I've never put a system into production." (Yes, it's hugely unfair.)
But reaction pieces aren't affirmative, they don't really tell you what a person thinks, just what he doesn't think. So here's what I think: small teams kick ass. Products designed and built initially by a small team tend to have a greater cohesion than those built by larger groups, and I think this is an overlooked benefit for maintenance programmers.
But small teams can by risky, too. Developers tend not to talk about risk because we think we can steamroll over it by heroics and cleverness. You have to be much more careful about hiring -- bad apples spoil any team, but they're immediately fatal to a small team. And it's even riskier if you need to move quickly -- it takes time to find the right people.
Of course, the alternative is risky as well. Hiring any warm body may seem productive at first ("we hit our hiring numbers!"), but it won't buy you success. And adding warm bodies to a project in trouble is a sure way to tank it.
A number of the strengths of small teams have a double-edge. For instance: on a small team it's easier to trust everyone, to know that they're going to do their job so you don't need to cover for them. But when something unexpected comes up there are fewer people to deal with it. So people tend to work longer hours. Which isn't so bad for a short time, but that has a bad habit of going longer than anticipated. Not so good for people with families.
Compared to this, choices among programming languages or even frameworks seem secondary. Or maybe teams choose these things to fit the folks working there? (If they're able.)
Reg Braithwaite has a typically interesting post, What if powerful languages and idioms only work for small teams?. As usual I think things are more complex than most of the posters.
First, most of them completely disregard timeframe. Sure, as Carmack said, "a team of 3 focused and creative people can accomplish almost anything" -- given sufficient time. But time is the knob that many (most?) projects have little control over. Everybody has competitors, and everything needs to get out yesterday.
Second, most of the comments regard developers only. Does "small team" include QA? People to gather requirements? People to write documentation for users, or even other developers? Or do the developers do those too? (And if they do, see the first item.)
Third, I think there's a huge distinction between creating something and maintaining/improving it. I agree with Bob that it's possible to create complex software. But what happens when it gets in front of customers? And then when you can no longer count the number of customers on your fingers and toes? And assuming only half of them have potential ideas as to bugs and improvements, who's going to do all that and develop new features to keep up with the Jonses, or those left out from the last version due to time constraints?
Fourth, the examples brought up during the comments are all tools -- Linux, Delphi, even Quattro Pro. They're generic tools built without regard for any specific business logic. But I'd venture a guess that most developers don't work on such systems. They have to deal with automating processes that have been accreted for years on paper and informally in the brains of the workers. And even then they have to communicate with systems and coordinate not only protocols (which is what tools do) but content, even in the face of stupid implementations.
And doing all that for non-trivial businesses, with a small team, no matter what language, is a tough job. (Not even mentioning figuring out what it is you're supposed to build.) In a short amount of time? Approaching impossible.
Even if you're not really a Perl person this is a fun time. My Perl status is grandfathered in from earlier jobs and projects so the talks aren't directly relevant to my job. But hanging out with a bunch of smart people together with ideas zipping by a mile a minute is never a bad idea. And throw in free food, you're golden.
See you there.
MJD has been working on his red flags book for a while, and he's had an open invitation to Perl Mongers groups: he'll speak at your group for free as long as you give him something to talk about. This could be work you'd like to see improved, whatever
I can testify that in the absence of volunteers he'll find other work. In our case, he happened on the Class::Observable module when he came to Pittsburgh last year. I remember walking in just as they were handing out copies of the source code, and seeing 'Observable.pm' at the top: my stomach plummeted.
Fortunately, he was extremely fair, and it was difficult to argue with any of his choices. The only one I could raise a tiny objection to was naming: I'd used 'update' to mirror the Java java.util.Observable interface, and on hearing that's why I chose it he said something like, "Oh, that makes sense." I'd also used a set of awkwardly-named methods like "_obs_foo_bar" but that's because I didn't want them overridden and Perl doesn't give you private methods. (At least, not by default.)
Unfortunately, I had to bail during MJD's presentation -- not because I couldn't take it anymore, but because it was early on in Barb's pregnancy and I had a strict time limit on how long I could be away from home. (Long story.) And because I came in late I couldn't explain this to MJD, but I figured that Casey, Tom or Rob would have told him I wasn't the shinking violet sort. (I did tell him later in an email.)
Anyway, I figured that was the end I'd hear of it until the book came out, and given the lead time of HOP I was comfortable with a few years for that. Until I got an email from Rob Blackwell: "You're an international red flag" along with a link to MJD's YAPC::EU presentation.
Ouch. Yeah, that me. But in my defense I think my overengineering tendencies have been greatly curbed in the last few years. And the few recent times at work I've strayed close to the overdesign line I've actually been rewarded when a changed or new requirement came up and it was a piece of cake to handle. We talk about "code smells" like they're so cut-and-dried, but they're not. In everyday work you often get to choose one way of doing things over another, and IMO it's experience with similar choices more than anything else that dictates which one will bear fruit, how successful your choices will be.
Wish I would have been there to see the whole presentation
Eight months ago today we met Ella, and we've been remarkably lucky since. She's growing and learning like crazy that her time with us is both compressed and expanded: it seems like such a short time ago we brought her home, scared and jubilant at this new life, it seems like such a long time ago that she last slept in her swing, or couldn't pick herself up off her back.
The only way we could be happier is if she picked the winning powerball numbers last weekend.
I've been thinking about this off and on over the weekend. And one thing I kept coming back to (even disregarding ideas about the technical future that my eight-month old keeps stealing from my mushy brain) is a discussion of community and open source. Has there ever been a development platform that died out having such a large and diverse open source community?
People who are firmly in the scripting camp and have never used Java may not realize the size and scope of the community. That may be because there's no central repository (like CPAN), or because there are so many large companies out there that might look to the naive to steal the oxygen from the ecosystem.
But right now I think of the Java community identically to how I think of Perl and CPAN: if there's some system I need to talk to, or some general task I need to accomplish, there will be an open source, business-usable library out there for it. I have bet my technical future on this with both platforms and haven't been disappointed yet.
Further, dismissing Java-the-language but grudgingly accepting Java-the-platform makes no sense. If I'm running JRuby, or Scala, or plain old Java, the community and the wealth of libraries is what supports my project and team.
Lastly and IMO, that the official JDK is open source makes it that much stronger. And that all editions of the platform , from mobile phones on up, are open source is underappreciated because of the carping that it took them too long (it sure did) and there are apparently some leftover licensing issues (IANAL). One of the wonderful things about open source is that people pretzel your project in areas and ways you never anticipated, and that all those pretzels produce benefits you can't even conceive. I think we'll see lots of these in the next few years, particularly as mobile devices get more powerful and people start playing with little dev kits that can run Java.
I have some other thoughts on this general topic (mostly related to the amount of risk projects/hiring are willing to assume with other platforms), but I'm going to have to wait a bit on those. Hopefully my eight-month old won't steal those, too.
Scheduling is a big part of our kickass product for nursing homes (coming soon!). Generally there are:
One of my fundamendal tenets of software development is that anything dealing with dates and times sucks hard. You have to deal with weird measurements (leap years, inconsistent month lengths), timezones, synchronization, agreement on units of measurement, and it's one of the relatively few areas of ubiquitous low level computing that can be influenced by human politics. Fortunately many other people much smarter than me have come to the same conclusion and have developed libraries and specifications to deal with the suck.
The infantry library for us is Joda Time, which is in my top five open source Java libraries ever. Partially because what it replaces -- the datetime handling in the JDK -- is so awful. But it's also because it's designed by people who have actually used dates and times in the real world, and because it encourages good practices by using immutable objects as the default and making everything threadsafe.
But that only deals with dates and times, not recurrences. The 800-pound gorilla in the recurrence space is RFC 2445, "Internet Calendaring and Scheduling Core Object Specification" or "iCalendar". iCalendar deals with every aspect of scheduling I can think of, and one of the trickiest is recurring schedules. The formal definition for the 'RRULE' (section 4.3.10) is a page and a half, and that doesn't even scratch the surface of what it actually means. The description of each field fills up another two pages: more useful, but still a little abstract for practical use.
For me, the best part comes later, in section 22.214.171.124. It includes six pages of explicit examples, like these three:
Every 10 days, 5 occurrences:
<p> ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
The first Saturday that follows the first Sunday of the month,
<p> ==> (1997 9:00 AM EDT)September 13;October 11
(1997 9:00 AM EST)November 8;December 13
(1998 9:00 AM EST)January 10;February 7;March 7
(1998 9:00 AM EDT)April 11;May 9;June 13...
Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
<p> ==> (September 2, 1997 EDT)09:00,12:00,15:00
When writing any type of documentation it's easy to assume your reader consumes what you've written as carefully as you've produced it -- from front to back, paying attention to your highlights and thinking deeply about your assumptions and goals. But IME few people have the inclination or luxury of reading that way -- it's, "How can I do job X?" Examples are the best way to do this; if your library is good enough, they'll get to the other (still important) parts later.
(BTW, the library we're using for recurrences is Google's RFC 2445 implementation. It's okay (it has Joda Time integration!), but IMO needs some usability improvements. When I get a few minutes to breathe this fall I hope to try and contribute...)
IDEA 7 has a nifty feature called 'Shelve changes'. Some SCM systems have this -- it's the ability to take a set of changes and have the SCM 'forget' about them so you can do other work independent of them. You can then reintegrate them back in one fell swoop. The typical use case is to move aside changes for a big feature to implement one or more small features at the same time so you don't accidentally bring the 'big feature' changes in with the small ones.
(From what I understand this is built-in to most distributed SCM systems -- branches aren't the heavyweight things they are in Perforce, so every feature becomes its own branch and has its own changesets associated with it. Cool.)
Anyway, somehow IDEA lost track of a shelf I'd made a week or two ago -- I hit Alt-9 to see the changes, then Alt-RightArrow twice to the see the 'Shelf' tab, only to see there was no 'Shelf' tab. Shit! I tried to remember everything I did, and while it wasn't a huge amount it was an hour of work plus testing.
Before I started on that path I went to the directory where IDEA
stores all of my stuff: ~/.IntelliJIdea70. Under
config/shelf was a single file with the extension of
It would have been really easy for the folks at Jetbrains to create their own format for shelved changes, and to tightly couple the 'reintegrate shelf' functionality with the file itself, disallowing its use anywhere else. That they didn't shows, again, how much they know how developers work. The fact that I also could have applied them with the command-line patch tool is also great, and another argument for sticking with standard formats where possible.
CAN HAS STDIO?
PLZ OPEN FILE "LOLCATS.TXT"?