3 ms·

That shitty deployment experience has nothing to do with PHP. There are plenty of valid reasons to move to Python or Ruby, but better deployment stories aren't

by sauravc 14y ago

That shitty deployment experience has nothing to do with PHP. There are plenty of valid reasons to move to Python or Ruby, but better deployment stories aren't one of them. Objectivity seems to be in short supply here on HN.

heretohelp 14y ago
It has to do with community standards. The community standards for deployments and dependency management for Python & Ruby are much higher than PHP. virtualenv/rvm are the standard, using git is the standard, fabric/capistrano for pushing/provisioning is standard. This is not the case for PHP, the vast majority are using graphical FTP clients to manually overwrite files.
AnswerAndForget 14y ago
Isn't the ecosystem always trotted out while defending PHP, as well as its 'accessibility' to amateurs? Well, those amateurs are part of the PHP ecosystem, and you'll have to put up with that... or not.
damncabbage 14y ago
heretohelp made the point better than I did, but I explained my thoughts on that with this sentence: I got tired of checking for a baseline of automated deployment, automated testing, version control, and individual dev systems at every single job I applied for; Ruby people don't look at you funny when you mention these things. It's about expectations. I tried really hard to find a place that had all these in the PHP world. In the Ruby world (for example), it's a given. (I have only ever encountered one PHP shop during my rounds interviews that did automated testing... But they used CVS for version control. The very first Ruby shop I interviewed had all of the above, and treated it like they were no big issue.)
- bandy 14y ago
  >But they used CVS for version control. Oh the horror! A proven source-code control system. M-x My-lawn-remark$
  - damncabbage 14y ago
    That's nice. Unless you, say, you want to: * Track renames of files. * Track changes to the repository as a whole, instead of per file. I care most about stepping through revisions of a project; inspection of the history of a particular file is a secondary concern for me, but is all that CVS can do. A "project" for me is usually a set of files that are interdependent to greater and lesser degrees. The best you get with CVS for tracking the versions of all the files in a repository is manually creating tags all the time. With Git, Subversion, Mercurial, Bazaar, etc you get this for free; it's how these tools work. (As an aside, DOS is also a proven operating system. For varying values of "proven".)

by sauravc 14y ago

heretohelp 14y ago

It has to do with community standards. The community standards for deployments and dependency management for Python & Ruby are much higher than PHP. virtualenv/rvm are the standard, using git is the standard, fabric/capistrano for pushing/provisioning is standard. This is not the case for PHP, the vast majority are using graphical FTP clients to manually overwrite files.

AnswerAndForget 14y ago

Isn't the ecosystem always trotted out while defending PHP, as well as its 'accessibility' to amateurs? Well, those amateurs are part of the PHP ecosystem, and you'll have to put up with that... or not.

damncabbage 14y ago

heretohelp made the point better than I did, but I explained my thoughts on that with this sentence: I got tired of checking for a baseline of automated deployment, automated testing, version control, and individual dev systems at every single job I applied for; Ruby people don't look at you funny when you mention these things. It's about expectations. I tried really hard to find a place that had all these in the PHP world. In the Ruby world (for example), it's a given. (I have only ever encountered one PHP shop during my rounds interviews that did automated testing... But they used CVS for version control. The very first Ruby shop I interviewed had all of the above, and treated it like they were no big issue.)

bandy 14y ago
>But they used CVS for version control. Oh the horror! A proven source-code control system. M-x My-lawn-remark$
- damncabbage 14y ago
  That's nice. Unless you, say, you want to: * Track renames of files. * Track changes to the repository as a whole, instead of per file. I care most about stepping through revisions of a project; inspection of the history of a particular file is a secondary concern for me, but is all that CVS can do. A "project" for me is usually a set of files that are interdependent to greater and lesser degrees. The best you get with CVS for tracking the versions of all the files in a repository is manually creating tags all the time. With Git, Subversion, Mercurial, Bazaar, etc you get this for free; it's how these tools work. (As an aside, DOS is also a proven operating system. For varying values of "proven".)