Monday, February 7, 2011

I need this baby in a month - send me nine women!

Under what circumstances - if any - does adding programmers to a team actually speed development of an already late project?

  • See The Mythical Man-Month

    Christopher Mahan : @edg: noob trying his hand (successfully) at rep-whoring. This too shall pass.
    docgnome : @Christopher Mahan: No, I am not and frankly I find the accusation offensive. Why rehash a subject that Brooks handled so very well?
    docgnome : @Christopher Mahan: It's people like you that kill communities with your rude, unnecessary snarky attitude that everyone who doesn't expound for pages and pages is an idiot.
    Jon Limjap : docgnome, I suggest you come up with a good (even bulletpointed) synopsis of the cases pointed out in TMMM that answers the question. Page numbers or at least chapters would be nice too. :)
    MrBoJangles : We all lose when people leave brain-dead comments like the first one.
    Jonik : With a question like that, one would think the asker very likely *has already seen* the book, so simply mentioning its name does not add especially much.
    NetHawk : docgnome, I actually thought it was a snarky "RTFM" type of response, (and rated up your comment to C.M. where you say snarky attitudes are unnecessary and kill communities). The reason that I thought that was that you were being snarky was it seemed like the OP already knew of the book, and was asking a specific question about our experience with one nuance before he went off to actually read it. As little as accusations of 'rep-whoring' and name calling are needed, differing to an outside source, in a discussion-ending way, stifles interest on possibly interesting topics.
    From docgnome
  • If the existing programmers are totally incompetent, then adding competent programmers may help.

    I can imagine a situation where you had a very modular system, and the existing programmer(s) hadn't even started on a very isolated module. In that case, assigning just that portion of the project to a new programmer might help.

    Basically the Mythical Man Month references are correct, except in contrived cases like the one I made up. Mr. Brooks did solid research to demonstrate that the networking and communication costs of adding new programmers to a project will outweigh any benefits you gain from their productivity.

    Mike Stone : Not really... still there is a cost of learning the code base alone... and if they are totally incompetent, the project will probably fail anyways.
    Stu Thompson : I agree with Mike Stone here. The code base and architecture could be flawed, 2-4 months ramp up time per developer for a serious project, all sorts of issues regarding technical leadership, etc. Ught...I get the willies thinking about it.
  • The Mythical Man Month goes into great detail on this... adding people to a late project will not help... you have costs associated in bringing someone up to speed and them learning the code base that you just can't avoid. If the project is late, you will have to look to other ways to make it on time... such as cutting features that aren't really necessary.

    Airsource Ltd : And like all truisms, it's sometimes wrong. As Brooks himself said in the Mythical Man Month, the law is an "outrageous oversimplification".
    Windows programmer : The question asked "Under what circumstances - if any - does adding programmers to a team actually speed development of an already late project?", so an answer that answers the opposite is the accepted answer?
    Simucal : @Windows Programmer, Sure, if the answer helps illustrate that there aren't any.. why not?
    Marcel : +1 for mentioning "Mythical Man Month", as it is covered exactly there.
    From Mike Stone
  • Found this, thought it might be useful:

    http://agileworld.blogspot.com/2006/08/law-of-diminishing-marginal-returns.html

  • When your critical path of building the program isn't a single line, but rather a series or paths. Then you can assign a programmer to each critical path.

    Ed Guiness : textbook project management answer, one I've never witnessed
    Mike Stone : LOL, yeah... Sam... I think you need to read The Mythical Man-Month more than anyone :-) (it's a fun read anyways)
    Stu Thompson : agreed. another hopelessly romantic answer :P
    Sam : I like my rose colored glasses, thank you very much. :-)
    From Sam
  • Potentially as a co-pilot. Think extreme programming pair method, but with out the experience from having the coding from start. This is assuming your co-pilot is familiar with any frame works you are using.

    (just a guess though ^_~ )

    Ed Guiness : your guess is as good as most i reckon
    RQDQ : This is actually a pretty good idea.
    From gltovar
    • Self-contained modules that have yet to be started
    • Lacking development tools they can integrate (like an automated build manager)

    Primarily I'm thinking of things that let them stay out of the currently developing people's way. I do agree with Mythical Man-Month, but I also think there are exceptions to everything.

    From Tom Ritter
  • When the work can be split into independent units and there are more such units than programmers already on the project.

    From moonshadow
  • If the architecture of the system being built allows for the modular addition of the remaining functionality, then adding extra programmers could actually get to the end faster. You'd need a very solid foundation and infrastructure, with plenty of excellent examples and documentation, to make this feasible. As we all know, this is pretty unlikely (but not impossible).

  • Maybe if the following conditions apply:

    1. The new programmers already understand the project and don't need any ramp-up time.
    2. The new programmers already are proficient with the development environment.
    3. No adminstrative time is needed to add the developers to the team.
    4. Almost no communication is required between team members.

    I'll let you know the first time I see all of these at once.

    Mike Stone : basically adding someone back to a project they had left (recent enough so they haven't forgotten anything too)
    Stu Thompson : "I'll let you know the first time I see all of these at once." Holding my breath!!!
  • It only helps if you have a resource-driven project.

    For instance, consider this:

    You need to paint a large poster, say 4 by 6 meters. A poster that big, you can probably put two or three people in front of it, and have them paint in parallel. However, placing 20 people in front of it won't work. Additionally, you'll need skilled people, unless you want a crappy poster.

    However, if your project is to stuff envelopes with ready-printed letters (like You MIGHT have won!) then the more people you add, the faster it goes. There is some overhead in doling out stacks of work, so you can't get benefits up to the point where you have one person pr. envelope, but you can get benefits from much more than just 2 or 3 people.

    So if your project can easily be divided into small chunks, and if the team members can get up to speed quickly (like... instantaneously), then adding more people will make it go faster, up to a point.

    Sadly, not many projects are like that in our world, which is why docgnome's tip about the Mythical Man-Month book is a really good advice.

    Mike Stone : I think software is inherently not such a project, so unless you are adding people to do non-programmer work (like creating images and translating text), you can safely say it WON'T help, with TMMM as reference
    Marcel : +1, good example with the poster
  • Yeah, you should read the book. Wikipedia also has an article on Brook's Law which discusses the two main caveats. Basically, the only time when adding people to a project doesn't make it later is when no time is needed to bring the people up to speed. Essentially: at the beginning, or at least before it's late, and when the people being added are extremely skilled in the particular domain of the project.

    Ed Guiness : what makes you think I haven't read the book? thx anyway.
    From Jaykul
  • Never. Just that fact that it takes time for you to train them, and for them to learn system. This should only be considered if the project is just starting to get behind and there is room for it in the budget. But it should never be considered when the project is approaching its deadline.

    From MagicKat
    • If the new people focus on testing
    • If you can isolate independent features that don't create new dependencies
    • If you can orthogonalise some aspects of the project (especially non-coding tasks such as visual design/layout, database tuning/indexing, or server setup/network configuration) so that one person can work on that while the others carry on with application code
    • If the people know each other, and the technology, and the business requirements, and the design, well enough to be able to do things with a knowledge of when they'll step on each other's toes and how to avoid doing so (this, of course, is pretty hard to arrange if it isn't already the case)
  • I come from the context-based school of testing (and life, for that matter). Hence, my answer would be, "It depends." It depends on the skills of the programmers, and how quickly they can be brought up to speed on what needs to be done. I also come from the pair-programming school (dependent on context, of course). I believe pairing will give you near-instant gains, provided people are willing to pair up, don't hate each other, know how to pilot as well as navigate, etc. You'll still be late, just less late. And since you're already late, shoot for quality.

    To keep with your meme, You need this baby in a month, send another woman for moral support, and gestate faster, or something like that.

  • Only when you have at that late stage some independent (almost 0% interaction with other parts of the project) tasks not tackled yet by anybody and you can bring on the team somebody that is a specialist in that domain. The addition of a team member has to minimize the disruption for the rest of the team.

    From Daniel
  • I suppose the adding people toward the end of the work could speed things up if:

    1. The work can be done in parallel.

    2. The amount saved by added resources is more than the amount of time lost by having the people experienced with the project explain things to those that are inexperienced.

    EDIT: I forgot to mention, this kind of thing doesn't happen all too often. Usually it is fairly straight forward stuff, like admin screens that do simple CRUD to a table. These days these types of tools can be mostly autogenerated anyway.

    Be careful of managers that bank on this kind of work to hand off though. It sounds great, but it in reality there usually isn't enough of it trim any significant time off of the project.

    Stu Thompson : And how often is that actually the case?
    Mike Stone : virtually never ;-)
  • If software development is analogous to pregnancy, then could we say that a selection of modern v1 software products on a shelf are analogous to a hospital nursery, most of which are premature crack babies?

    Ed Guiness : and I thought I was pushing the analogy...
  • Never. There are no such circumstances.

    Ed Guiness : i like the confidence of your answer, even though its wrong. :-)
    Oskar : and all the other posts here, all wrong?
    From jfm3
  • An average programmer is rather unproductive about a month month after joining team, so that if the project is actually late (I'm speaking about 1 or 2 months to a first deadline) it's better to have some, unavoidable losses than increasing it by investing your programmers time into training a new team member.

    The other thing you have to reconsider is a quality and organisation of work in your team. There were many cases where team had enough workforce to complete the task in time, but delayed it due to bad communication, waiting for the dependencies, slacking or as an effect of false savings which forced developers to spend more time later, on the other parts of application.

    Also, I'm next man who recommends Fred Brooks book :]

    Stu Thompson : In addition to 'unproductive about a month after joining the team', that a programmer is not fully ramped up and a solid contributor for two to six months. (and some never)
    From rawicki
  • Depends entirely on the situation and code-base. If coded properly (i.e. following established design practices), it could make total sense. If you're looking at a bunch of code that follows no design practices, then you might be better off trudging through it.

    Ed Guiness : what is this "coded properly" of which you speak?
    From madcolor
  • The exact circumstances are obviously very specific to your project ( e.g. development team, management style, process maturity, difficulty of the subject matter, etc.). In order to scope this a bit better so we can speak about it in anything but sweeping oversimplifications, I'm going to restate your question:

    Under what circumstances, if any, can adding team members to a software development project that is running late result in a reduction in the actual ship date with a level of quality equal to that if the existing team were allow to work until completion?

    There are a number of things that I think are necessary, but not sufficient, for this to occur (in no particular order):

    • The proposed individuals to be added to the project must have:
      • At least a reasonable understanding of the problem domain of the project
      • Be proficient in the language of the project and the specific technologies that they would use for the tasks they would be given
      • Their proficiency must /not/ be much less or much greater than the weakest or strongest existing member respectively. Weak members will drain your existing staff with tertiary problems while a new person who is too strong will disrupt the team with how everything they have done and are doing is wrong.
      • Have good communication skills
      • Be highly motivated (e.g. be able to work independently without prodding)
    • The existing team members must have:
      • Excellent communication skills
      • Excellent time management skills
    • The project lead/management must have:
      • Good prioritization and resource allocation abilities
      • A high level of respect from the existing team members
      • Excellent communication skills
    • The project must have:
      • A good, completed, and documented software design specification
      • Good documentation of things already implemented
      • A modular design to allow clear chunks of responsibility to be carved out
      • Sufficient automated processes for quality assurance for the required defect level These might include such things as: unit tests, regression tests, automated build deployments, etc.)
      • A bug/feature tracking system that is currently in-place and in-use by the team (e.g. trac, SourceForge, FogBugz, etc).

    One of the first things that should be discussed is whether the ship date can be slipped, whether features can be cut, and if some combinations of the two will allow you to satisfy release with your existing staff. Many times its a couple features that are really hogging the resources of the team that won't deliver value equal to the investment. So give your project's priorities a serious review before anything else.

    If the outcome of the above paragraph isn't sufficient, then visit the list above. If you caught the schedule slip early, the addition of the right team members at the right time may save the release. Unfortunately, the closer you get to your expected ship date, the more things can go wrong with adding people. At one point, you'll cross the "point of no return" where no amount of change (other than shipping the current development branch) can save your release.

    I could go on and on but I think I hit the major points. Outside of the project and in terms of your career, the company's future success, etc. one of the things that you should definitely do is figure out why you were late, if anything could have been done alert you earlier, and what measures you need to take to prevent it in the future. A late project usually occurs because you were either:

    • Were late before you started (more stuff than time) and/or
    • slipped 1hr, 1day at time.

    Hope that helps!

    Ed Guiness : thanks for the thoughtful answer, i'll upvote when my vote supply is topped up
    Sheldon : you put effort into this. good quality posting! bump it up!
    sleske : Good list. However, I fear many projects are late precisely because they do not have everything you list...
    From Burly
  • Quite simply, none. If you're already late, adding people will only make you later due to ramp up time and an increase in communication channels.

  • With black box programming, it is easy enough to break out segments of a large project and pass them out to your programmers. The number of programmers that speed your progress is only limited by the number of simultaneously developed boxes your can design out of the system.

  • adding new people on will kill your baby

    From EvilEddie
  • In general, it is indeed a case of diminishing returns, however, if all other paths have been exhausted, other programmers may be able to be added at a cost factor of productivity, in small quantities.

    For theoretical/conceptual illustration, a team of 3 might have 1 person added and get an additional 50% worth of that person's actual hours (if they started at the beginning of the project it would've been all 100%). The same team may also be able to add 2 more people at a factor of 30% each, but then adding 3 may mean a factor of 15%, which is worse than if there were only 2.

    Tim Williscroft : As Fred Brooks points out, the fourth person has to communicate with the first three, *slowing them down*. The result of adding the fifth and sixth is even worse. In general, without good design, a SW team is an undirected, fully connected graph. Communications overhead goes up with (N*(N-1))/2.
    Troy DeMonbreun : My numbers were just for theoretical/conceptual illustration. I haven't read TMMM, but I'd imagine that along with communication overhead there would also be other types of logistical overhead, though I would guess that TMMM probably covers that.
  • It shouldn't, but here is a rule:

    If bringing on additional people speeds up a project, fire the first batch of people, and it'll speed it up even more.

  • Obviously every project is different but most development jobs can be assured to have a certain amount of collaboration among developers. Where this is the case my experience has been that fresh resources can actually unintentionally slow down the people they are relying on to bring them up to speed and in some cases this can be your key people (incidentally it's usually 'key' people that would take the time to educate a newb). When they are up to speed, there are no guarantees that their work will fit into established 'rules' or 'work culture' with the rest of the team. So again, it can do more harm than good. So that aside, these are the circumstances where it might be beneficial:

    1) The new resource has a tight task which requires a minimum of interaction with other developers and a skill set that's already been demonstrated. (ie. porting existing code to a new platform, externally refactoring a dead module that's currently locked down in the existing code base).

    2) The project is managed in such a way that other more senior team members time can be shared to assist bringing the newb up to speed and mentoring them along the way to ensure their work is compatible with what's already been done.

    3) The other team members are very patient.

    From Eyesno
  • According to the Mythical Man-Month, the main reason adding people to a late project makes it later is the O(n^2) communication overhead.

    I've experienced one primary exception to this: if there's only one person on a project, it's almost always doomed. Adding a second one speeds it up almost every time. That's because communication isn't overhead in that case - it's a helpful opportunity to clarify your thoughts and make fewer stupid mistakes.

    Also, as you obviously knew when you posted your question, the advice from the Mythical Man-Month only applies to late projects. If your project isn't already late, it is quite possible that adding people won't make it later. Assuming you do it properly, of course.

    From apenwarr
  • I think the {codesqueeze} post Adding People To A Late Project Makes It Later has some very good ideas about this problem

    From kmilo
  • I'm part of a project that has gone on more than twice as long as originally intended. Part of the problem is that neither of the contributors have enough time to work on the project around our other responsibilities. Adding a programmer or two who could spend a lot more time working on it would most certainly speed it up.

    From Benson
  • If the current team is made up of monkeys at typewriters and the new programmer is a smart human.

    You know, because he can just start from scratch.

    Windows programmer : "Always use a scratch monkey"
  • I think adding people to a team may speed up a project more than adding them to the project itself.

    I often run into the problem of having too many concurrent projects. Any one of those projects could be completed faster if I could focus on that project alone. By adding team members, I could transition off other projects.

    Of course, this assumes that you've hired capable, self-motivated developers, who are able to inherit large projects and learn independently. :-)

  • Simply put. It comes down to comparing the time left and productivity you will get from someone excluding the amount of time it takes the additional resources to come up to speed and be productive and subtracting the time invested in teaching them by existing resources. The key factors (in order of significance):

    1. How good the resource is at picking it up. The best developers can walk onto a new site and be productive fixing bugs almost instantly with little assistance. This skill is rare but can be learnt.
    2. The segregability of tasks. They need to be able to work on objects and functions without tripping over the existing developers and slowing them down.
    3. The complexity of the project and documentation available. If it's a vanilla best practice ASP.Net application and common well-documented business scenarios then a good developer can just get stuck in straight away. This factor more than any will determine how much time the existing resources will have to invest in teaching and therefore the initial negative impact of the new resources.
    4. The amount of time left. This is often mis-estimated too. Frequently the logic will be we only have x weeks left and it will take x+1 weeks to get someone up to speed. In reality the project IS going to slip and does in fact have 2x weeks of dev left to go and getting more resources on sooner rather than later will help.
    From JackCorn
  • If everyone in development and test

    • is co-located
    • communicates well
    • understands their role in the project

    you may stand a chance at pulling in the schedule by some small percent.

    Communication is the main barrier. Having everyone in one physical location is integral if you are throwing warm bodies on a project late IMHO.

    It is risky no matter what, though, as The Mythical Man Month outlines in depth.

    From unwieldy
  • Rather than adding programmers, one can think about adding administrative help. Anything that will remove distractions, improve focus, or improve motivation can be helpful. This includes both system and administration, as well as more prosaic things like getting lunches.

    Ed Guiness : Good suggestion, and one that I think is in keeping with the spirit of suggestions in Mythical Man Month. ++
    From JXG
  • Where a team is already used to pair programming, then adding another developer who is already skilled at pairing may not slow the project down, particularly if development is proceeding with a TDD style.

    The new developer will slowly become more productive as they understand the code base more, and any misunderstandings will be caught very early either by their pair, or by the test suite that is run before every check-in (and there should ideally be a check in at least every ten minutes).

    However, the effects of the extra communication overheads need to be taken into account. It is important not to dilute the existing knowledge of the project too much.

    Ed Guiness : So you're saying it might be helpful and it might not be helpful?
    Bill Michell : More or less. I'm saying that the accepted wisdom is that adding people to a late project will make it later, but under some limited circumstances, managed very carefully, you can get some useful extra work from an extra person.
  • If the extra resource complement your existing team it can be ideal. For example, if you are about to set up your production hardware and verify that the database is actually tuned as opposed to just returning good results (that your team knows as domain experts) borrowing time from a good dba who works on the the project next to yours can speed the team up without much training cost

    Windows programmer : This is actually a pretty good answer. More generally, if a project depends on knowledge of A B C and D, and programmers on the team know A and B, then adding programmers who understand C and D can speed up the completion. The people have to get along well and there are still size limits on the team
    From Oskar
  • Reading the question makes me want to answer perversely:

    When you add programmers to a team of zero people, then almost certainly the development would speed up.

    And I guess the team could be zero if they have quit in disgust, fired for extreme incompetance, passed away (naturally or otherwise), or any other multitude of options.

    From RickL
  • Haven't seen that happening ever. Only under those circumstances when one is "lucky", I believe.

  • Adding more people to a late project will only help if the sole problem with the project is not enough people to do the work. If there is one additional problem, adding people will most likely make that problem even worse.

Font rendering libraries for C# / dot-NET?

Are there any free, third-party libraries for rendering arbitrarily scaled and rotated text in dot-NET applications? Although native GDI+ allows for text scaling and rotation, its methods for determining the rendered text's dimensions are not sufficiently precise and the differences in kerning as text is added to a rendered string make it unsuitable for use in certain kinds of software (such as, for instance, graphics editing software).

Requirements:

  • Native .NET code.
  • Arbitrary scaling and rotation of text.
  • Precise text metrics.
  • Consistent kerning regardless of string length.
  • Windows Presentation Foundation provides sophisticated support for typography.

    rpetrich : actually, it is also available on XP SP2 if the .NET Framework 3.0 is installed
    aku : WPF is available on all platforms where .NET 3.0 installed
    From aku

Reading files in use and system files on Windows XP & Vista using .NET

I have this idea for a free backup application.

The largest problem I need to solve at the moment is how to access files which are being used or are system files. I would like the application to be able to perform a full backup of files (i.e. not on a disk sector by sector level).

I'll turn the server part of the application into a service. First of all this service will need to be run with administrative privileges I guess? And secondly, is it possible to access locked files and files used by the system? Maybe take those files after the next reboot? (I've seen some anti virus applications work that way.)

I will use C# and the .NET platform, as it seems to be the easiest way to develop Windows applications these days.

  • Do a Google on HoboCopy. It is an open source backup tool for windows that can backup files that are in use using Windows Volume Shadow Service.

    Aydsman : The HoboCopy SourceForge project is here: http://sourceforge.net/projects/wangdera/
  • What you're looking for regarding the files in use is the "Volume Shadow Copy Service" which is available on Windows XP, Server 2003 and above. This will allow you to copy files even when they are in use.

    I have found a CodeProject article "Volume Shadow Copies from .NET" which describes a simple Outlook PST backup application written against Volume Shadow Copy.

    From Aydsman
  • Nothing in .NET that could do that directly AFAIK.

    I think you are looking for Volume Shadow Copy on XP/Vista which is designed for this kind of task.

    DeletedAccount : Thank you for the tip! After some searching I found: http://www.codeproject.com/KB/dotnet/makeshadowcopy.aspx At least it seems doable to call these methods from .NET.
    From chakrit

Reasons why PHP would echo errors, even with error_reporting(0)?

What are some reasons why php would force errors to show, no matter what you tell it to disable?

I have tried error_reporting(0) and ini_set('display_errors',0) with no luck.

  • Note the caveat in the manual at http://uk.php.net/error_reporting:

    Most of E_STRICT errors are evaluated at the compile time thus such errors are not reported in the file where error_reporting is enhanced to include E_STRICT errors (and vice versa).

    If your underlying system is configured to report E_STRICT errors, these may be output before your code is even considered. Don't forget, error_reporting/ini_set are runtime evaluations, and anything performed in a "before-run" phase will not see their effects.


    Based on your comment that your error is...

    Parse error: syntax error, unexpected T_VARIABLE, expecting ',' or ';' in /usr/home/REDACTED/public_html/dev.php on line 11

    Then the same general concept applies. Your code is never run, as it is syntactically invalid (you forgot a ';'). Therefore, your change of error reporting is never encountered.

    Fixing this requires a change of the system level error reporting. For example, on Apache you may be able to place...

    php_value error_reporting 0

    in a .htaccess file to suppress them all, but this is system configuration dependent.

    Pragmatically, don't write files with syntax errors :)

  • Use log_errors for them to be logged instead of displayed

    Valdemarick : Still causes the same error, unfortunately. I'm looking for a way to do this without modifying php.ini. Is that possible?
  • To prevent errors from displaying you can

    • Write in a .htaccess: php_flag display_errors 0
    • Split your code in separate modules where the main (parent) php-file only sets the error_logging and then include() the other files.
    From Wimmer
  • If the setting is specified in Apache using php_admin_value it can't be changed in .htaccess or in runtime. See: http://docs.php.net/configuration.changes

    From troelskn

How can I capture the stdin and stdout of system command from a Perl script?

In the middle of a Perl script, there is a system command I want to execute. I have a string that contains the data that needs to be fed into stdin (the command only accepts input from stdin), and I need to capture the output written to stdout. I've looked at the various methods of executing system commands in Perl, and the open function seems to be what I need, except that it looks like I can only capture stdin or stdout, not both.

At the moment, it seems like my best solution is to use open, redirect stdout into a temporary file, and read from the file after the command finishes. Is there a better solution?

  • IPC::Open3 would probably do what you want. It can capture STDERR and STDOUT.

    http://search.cpan.org/~rgarcia/perl-5.10.0/lib/IPC/Open3.pm

    From mopoke
  • I think you want to take a look at IPC::Open2

  • There is a special perl command for it

    open2()
    

    More info can be found on: http://sunsite.ualberta.ca/Documentation/Misc/perl-5.6.1/lib/IPC/Open2.html

    Leon Timmermans : Dude, why do you post something that has already been posted?
    From X-Istence
  • Somewhere at the top of your script, include the line

    use IPC::Open2;
    

    That will include the necessary module, usually installed with most Perl distributions by default. (If you don't have it, you could install it using CPAN.) Then, instead of open, call:

    $pid = open2($cmd_out, $cmd_in, 'some cmd and args');
    

    You can send data to your command by sending it to $cmd_in and then read your command's output by reading from $cmd_out.

    If you also want to be able to read the command's stderr stream, you can use the IPC::Open3 module instead.

    Brian Phillips : To anyone reading this, you should make sure and not use bareword filehandles as this example does. See this doc: http://www.perlfoundation.org/perl5/index.cgi?bareword_uppercase_filehandles
    From benzado
  • I always do it this way if I'm only expecting a single line of output or want to split the result on something other than a newline:

    my $result = qx( command args 2>&1 );
    my $rc=$?;

    $rc >> 8 is the exit code of the called program.

    if ($rc != 0 ) {

    error();
    }

    If you want to deal with a multi-line response, get the result as an array:
    my @lines = qx( command args 2>&1 );

    foreach ( my $line ) (@lines) {

    if ( $line =~ /some pattern/ ) {

     do_something();
    

    }
    }

    From
  • The perlipc documentation covers many ways that you can do this, including IPC::Open2 and IPC::Open3.

  • IPC::Open2/3 are fine, but I've found that usually all I really need is IPC::Run3, which handles the simple cases really well with minimal complexity:

    use IPC::Run3;    # Exports run3() by default
    
    run3( \@cmd, \$in, \$out, \$err );
    

    The documentation compares IPC::Run3 to other alternatives. It's worth a read even if you don't decide to use it.

    From xdg
  • If you do not want to include extra packages, you can just do

    open(TMP,">tmpfile");
    print TMP  $tmpdata ;
    open(RES,"$yourcommand|");
    $res = "" ;
    while(<RES>){
    $res .= $_ ;
    }
    

    which is the contrary of what you suggested, but should work also.

    From stephanea
  • A very easy way to do this that I recently found is the IPC::Filter module. It lets you do the job extremely intuitively:

    $output = filter $input, 'somecmd', '--with', 'various=args', '--etc';
    

    Note how it invokes your command without going through the shell if you pass it a list. It also does a reasonable job of handling errors for common utilities. (On failure, it dies, using the text from STDERR as its error message; on success, STDERR is just discarded.)

    Of course, it’s not suitable for huge amounts of data since it provides no way of doing any streaming processing; also, the error handling might not be granular enough for your needs. But it makes the many simple cases really really simple.

  • window.location.href='/';

What emails clients are being used out there?

This is not "exactly" a programming question, but it's highly related. We are writing an app that sends out email invitations for a client (no, it's not spam). Their designer gave us an HTML and CSS template to use which is fine. The problem is that it looks like crap in Outlook 2007 because Microsoft decided to use Word (of all things!) as the rendering engine for HTML in Outlook 2007. I want the client to understand that they should design a "compatible" look and would love to be able to show some kind of statistics about what email clients are being used out there, namely that Outlook 2007 is growing in use.

Has anyone run across any white papers, web sites, studies that even come close to providing a view on this? I don't expect census level accuracy, but something fairly credible would be good. Thanks for any help.

  • you should look at ReturnPath - they somewhat specialize in that.

    Clients you likely need to consider (aside from Outlook): AOL GMail Yahoo Mail Hotmail Lotus Notes thunderbird

    From Rob Fuller
  • If you expect to hit many business customers, remember that a very large potion of them will be using MS Office and Exchange Server and therefore also Outlook. If you're more aiming for home users most of them will either be using some webmail or a mail client that uses a regular HTML engine, like Windows Mail, Thunderbird, Opera Mail, Mac OS X Mail.app.

    From jfs
  • I'm using gmail

    From Avner
  • My understanding of the generally perceived best-practise on this, is is to code for the lowest-common denominator. There are plenty of email clients with enough use in-the-wild that aren't great at rendering "modern" HTML.

    Firstly, aim to send your mails as a 2-part multipart mime message. An HTML part AND a plain-text part.

    Secondly, try to avoid using CSS or positioned divs where possible. Use table-based layouts and inlined-styles. Preferably specifying as much of the style in HTML where possible.

    Try to keep images as inline IMG tags, or as table/row/cell background attributes only.

    The email world just isn't anywhere near as up-to-date, and more importantly, far more diverse than the browser world. If you follow these simple rules, your life is going to be much easier than taking a more advanced approach and repeatedly tweaking it in order to get your content to render satisfactorally on enough of the common clients.

    From Cheekysoft
  • I use KMail, you should also look at Thunderbird, Outlook, Evolution, Lotus and Opera Mail.

    Also keep in mind many people use webmail such as GMail, Hotmail, Yahoo Mail etc. And some web mail (and mail-clients) work only in plain-text for security reasons.

    Personally I think that plain text emails are best, many people prefer not to allow HTML mails due to security reason and thus would just be viewing a badly formatted plain text mail anyway, regardless of what you send, so in my opinion it would be better to just use plain text.

  • Gmail - personal mail

    Lotus Notes - forced to use it for corporate mail :(

    Lotus Notes sucks at rendering any HTML message correctly (we're running 6.5), and has only partial support for CSS. The best HTML messages for it are simple table-based layouts.

    From X-Cubed
  • Raw market share figures will not help you much. When designing HTML email, the only thing that matters is what client your particular target population uses. This depends on geographical area, industry, B2B/B2C -- variations are huge in practice. In some industries (journalism...) you'll even have to reckon with a sizeable population using clients like Lotus Notes, which is notorious for supporting HTML barely more than nominally (shudder).

    Outlook 2007 can certainly not be neglected any more, in particular if you send to business addresses, but with Vista on new PCs it's also got a noticeable presence for private accounts.

    Return Path indeed have data according to industry.

    However, in practice, a good approach is to follow "save" guidelines, in a lowest common denominator style. Outlook 2007 is not the only problematic client -- Gmail is also quite notorious for lacking support for a number of design elements others display just fine. You'll find that a surprising number of web designers do run a sideline with HTML email design (there is demand and it helps pay the rent). If you just start out, Campaign Monitor (an email marketing provider) has a wealth of good resources. You could start with their 2008 Email Design Guidelines. They're also one of those behind the Email Standards Project.

    Oh, personally I use Thunderbird with IMAP, Gmail, and RoundCube.

    (Disclaimer/full disclosure: I actually work for a competitor, in the loose sense, of Campaing Monitor.)

    John Virgolino : The links are helpful, thanks!
    From chryss
  • At work we have 3 x KMail and 4 x mac OSX' mail.
    Further webmail as fail-over (squirrelmail on mail server) in Firefox, Camino, Safari. We put the words in the mail, the rest in attachments.

    Words (pure text messages) can simply be copy/pasted, forwarded etc without formatting problems.

    Separate attachments lets user choose to view, download, save etc.

    This is the most universal way to use mail.

  • I faced this issue some time back.. most of the clients (including web) block HTML! We just created a web version of the email and added this to the footer of the email "If you are not able to view the message click here (link to web version). It was simply because some people think that its not safe to display images ;-) so a better way to make them open and read beautiful html emails

    From Shoban
  • I have outlook and gmail, but also a blackberry Curve...

    The curve is HORRIBLE at dealing with anything other than plain/text emails. Please have a link near the top to view the email on a website, and consider sending a multipart email that also has a text only section for clients that don't support HTML and such.

    From Scott S.
  • I run M2 (Opera's built-in mail client) and always have it set to "prefer plain text" for mail bodies. I also have "Block external elements" turned on.

    From Shadow2531
  • In absence of general statistics, collect your own.

    Check out http://fingerprintapp.com/email-client-stats for a ready-made statistics collection tool, and see http://www.mattbrindley.com/fingerprint-email-client-usage-1/ for a write-up about it. Matt Brindley also offers this gem: "So far only Outlook has proved as popular as we expected, the iPhone was a notable surprise for our own list, with Lotus Notes making an unexpected appearance as well."

    Of course, provide both text/html and text/plain mime types so that readers can choose which version to view, and keep your html extremely basic until your statistics indicate that you can get fancier.

    If Fingerprint's fee is out of the question, you can collect your own statistics. Include hyperlinks in your HTML. When your CGI application receives requests from these hyperlinks, it can save the HTTP_USER_AGENT in a database for your statistical analysis. This method is not entirely reliable because some readers will stick to plain text, some will never click any of the hyperlinks, and some email clients will not include useful information in the user agent request header, but it may give you enough information to proceed.

    Sitepoint, a well-respected source for W3 information, has an article, http://www.sitepoint.com/article/code-html-email-newsletters/, in which Tom Slavin points out:

    1. Use HTML tables to control the design layout and some presentation. You may be used to using pure CSS layouts for your web pages, but that approach just won't hold up in an email environment.

    2. Use inline CSS to control other presentation elements within your email, such as background colors and fonts.

    Slavin also recommends templates from Campaign Monitor and MailChimp to get you started.

  • Also, I think if you send as both text/plain and text/html, Gmail users (of the webmail UI) have no choice but to view the text/html version.

    From Shadow2531
  • I ran across this report / data that clearly shows Outlook 2007 gaining in popularity and heading in an upward curve. Currently this site reports the following top 4 clients (percentage out of 100% of course) but also that Outlook 2007 is on the rise. Hope this helps.

    http://www.campaignmonitor.com/stats/email-clients/#most_popular

    27.77% Outlook 2000, 2003, Express / 16.23% Hotmail / 14.14% Yahoo! Mail / 8.94% Outlook 2007

    From mxb

What's the best approach to embed RegEx in Oracle or SQL Server 2005 SQL?

This is a 3 part question regarding embedded RegEx into SQL statements.

  1. How do you embed a RegEx expression into an Oracle PL/SQL select statement that will parse out the “DELINQUENT” string in the text string shown below?

  2. What is the performance impact if used within a mission critical business transaction?

  3. Since embedding regex into SQL was introduced in Oracle 10g and SQL Server 2005, is it considered a recommended practice?


Dear Larry :

Thank you for using ABC's alert service.

ABC has detected a change in the status of one of your products in the state of KS. Please review the information below to determine if this status change was intended.

ENTITY NAME: Oracle Systems, LLC

PREVIOUS STATUS: --

CURRENT STATUS: DELINQUENT

As a reminder, you may contact your the ABC Team for assistance in correcting any delinquencies or, if needed, reinstating the service. Alternatively, if the system does not intend to continue to engage this state, please notify ABC so that we can discontinue our services.

Kind regards,

Service Team 1 ABC

--PLEASE DO NOT REPLY TO THIS EMAIL. IT IS NOT A MONITORED EMAIL ACCOUNT.--

Notice: ABC Corporation cannot independently verify the timeliness, accuracy, or completeness of the public information maintained by the responsible government agency or other sources of data upon which these alerts are based.