Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #8611

Re: Why PHP?

Show key headers only | View raw

On 09/03/13 06:46, clayjar@gmail.com wrote:
> It may be more helpful to me if you could state the number of years of experience in which development environment.

PHP: ~9 years
C#/dotnet: ~3 years

> I'd like to use your opinions if you don't object to that.

Surely dotnet has much built in when it comes to input verification, but 
at the same time it makes it inflexible and sometimes feeling that you 
have no say on how to do things. PHP is more flexible and using a 
framework still allows you easy access the values and adding your own 
features, but at the same time if you haven't tough of all the dangers, 
then you may end up with a less secure product (of course if you have 
made a MVC2 dotnet application, it will be insecure as microsoft will 
not release a patch to older version of dotnet which would prevent code 
injection with crafted input values, at least php has the advantage you 
can patch a fault yourself in the version you use if upstream don't 
provide a backport to the version you are using).

Surely the Visual Studio and MonoDevelop are excellent tools to develop 
dotnet applications with and giving you a lot of help, which you lack in 
most IDE when it comes to php, specially break point in the code, 
allowing you to step through the code and even allow you to modify 
variable values.

When it comes to online documentation, php.net is difficult to beat and 
microsoft has a long long path to walk before they are anywhere near and 
you will also find a lot of bad solution examples for dotnet out there 
as it's been quite popular in India (too many not so good coders over 
there who made HOWTOs, but there are a handful exceptions).

At my current work, we have a mixed environment, where we have 
dotnet/iis based web servers, but the main logic is run on linux servers 
on c++ based daemons. It works, but I feel that IIS ain't at all as good 
as Apache (I may be colored by the almost 20 years I have been using 
Apache) and I prefer Apache over IIS and of course Apache running on 
Linux/BSD over Apache on ms-windows.


> I've formed the analysis document into categories of "Proprietary vs. Open Source", "Windows vs. Linux", "IIS vs. Apache", "SQL Server vs. MySQL", "C# vs. PHP".

SQL Server is okey at some times, don't rule it out even if you choose 
to use PHP, it has it's benefits over MySQL, but also it has it's 
drawbacks. I wouldn't pick MySQL as it's not that transaction safe, even 
using innodb, but maybe you should look at PostgreSQL which has a major 
benefit over MySQL as PostgreSQL can handle data encryption (some of the 
patient data may be good to store as encrypted data).

When it comes to my experience of OS, Linux and BSD are far faster to 
get security updates and i maybe would favor the BSD over Linux if you 
are storing critical patient data (or at least have a BSD based 
loadbalancer/firewall in front of the Linux machines), for you I don't 
think switching over to BSD would be a big thing, most of the things 
would be pretty similar. Don't forget that many microsoft updates 
require you to reboot the system, the only time you need to reboot a 
Linux/BSD system is when you needed to upgrade the kernel (there is 
money costing option for Linux which can even make it possible to patch 
the kernel without reboot).


> Basically, it comes down to a philosophical issue, and yes, I have my development tent pitched on a free software philosophy.
> I'm also hesitant about taking this route to form a persuasive presentation, because as many of you already mentioned, the
> competency of the team along with the factor of learning curves are major determinants than other things.

I think the curve will be approximately the same, no matter which way 
you go, as long you have done a good documentation of your framework, if 
not, go through your code, make proper comments where it's needed and 
use a tool like phpdoc to generate a documentation.

It's in the end the side with the most convincing arguments (in the 
bosses ear) that will be the winner, and it has nothing to do with which 
is the best solution. So money, stability, security are those things you 
may have to focus on.


> We are trying to take a long view approach to deal with the sustainability of our own development team,

Then moving to the open source is a far better then being closed in, as 
I mentioned the MVC2 issue, we are still suffering of the potential risk 
(even if we have been adding our own validation, but you never know when 
someone forgets to add that extra validation to a variable)  and you 
can't just switch to MVC3/4 without rewriting the whole thing.

Just keep on pointing out the long waiting time for critical bugs and 
near EOL and after there is no way to get those issues fixed in a 
microsoft environment, you need to upgrade to the new version, getting a 
new license for everything and then rewrite more or less everything again.


> and it's unquestionably clear that open source approach is the way to go for us given the budget and many
> restraints that are in place, however, there have been years of mismanagement, thus producing an untenable
> environment at status quo simply to avoid hurting people's feelings.

To get rid of the bad, it's better that those who has been indoctrinated 
in the bad ways to switch to something new, as they have to learn 
something new and at the same time it's easier to teach them to do 
things the right way, if they stay with what they are familiar with, the 
risk is higher they will keep on doing the same bad mistakes as they did 
before as they think they know everything already.

Something you could do is to setup an automatized deployment of a test 
environment using git (or svn) and teamcity (or jenkins). We have setup 
so that when a new feature branch is pushed to stash (we use the 
atlassian stash as our git daemon), teamcity deploys it so it can be 
tested by our test team. When a feature branch is merged into develop 
branch we get teamcity to deploy it to the proper test environment. The 
main branch is always deployed to the stage environment, but teamcity 
only builds an install package as we can't have an automatic deployment 
to the live environment and our tehcops needs to have a chance to 
practice the installation before doing it live.. Having things automatic 
and feature rich, you will make a wow factor and show how well your 
setup works, if you then even attach some automatic test suites to it 
like Selenium (we are just in the evaluation phase of which test suite 
we ill use, so can't advice which one to use), but having at least some 
basic automatic tests done on each deployment will ensure you that 
things still work without the need of spending time, if you then attache 
the overall result of the test (success/failed) in stash(jira (another 
atlassian product), then you know if the feature branch should not be 
merged to the develop branch (of course you need to maintain the test 
cases if features changes, and it should be the developer who made the 
big change who fixes the test case).
Of course the automatic testing shouldn't be a replacement for unitests, 
but a complimentary, also it's not a replacement for real testers.

A boss who would see something like this (and never seen it before in 
the company), would most likely choose the automatic testing, easy 
merging of code, for this is how an enterprise development environment 
should work.


> Our software products are becoming more
> important in the overall strategy as we are growing rapidly.

I think it can bee good on think of the whole process from planing a 
feature, develop the feature, test the feature and deploy the feature 
and show how much time will in general be spent on each step, and of 
course you choose the worst options for the system you don't like.

Keep in mind to tell of the positive things with your setup to people 
around, even those who don't have anything to do with the decision, like 
if you have something like techops, then you could tell them how little 
time and preparation they would need for deploying the php project, 
while using dotnet they would need to learn loads of new tools and it 
would still be difficult (of course don't like, but bend the truth a 
bit, the microsoft way).

Don't forget to push that your development system is already up and 
running, while switching to C#/dotnet and rewrite most of the things 
would delay the product at least 3 months or even 12 months (we made a 
replacement system completely in C# it took us 13 months to rewrite 
everything from scratch and it had less features (~1/3) than the old 
system and we had 6 developers working on it), we know which frameworks 
we would be using, but still 3 months was used to fine tune things and 
set a coding standard and rewrite parts which didn't match the new standard.
As you have the framework, you would directly starting with porting the 
features to the new platform and those you have saved at least 3 months 
in developing time, the bigger team the more money you save.

I hope there is something you will have use of.

-- 
  //Aho

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Why PHP? clayjar@gmail.com - 2013-03-07 23:14 -0800
  Re: Why PHP? Michael Vilain <vilain@NOspamcop.net> - 2013-03-08 01:03 -0800
  Re: Why PHP? Jerry Stuckle <jstucklex@attglobal.net> - 2013-03-08 08:45 -0500
  Re: Why PHP? Martin Leese <please@see.Web.for.e-mail.INVALID> - 2013-03-08 10:11 -0700
    Re: Why PHP? The Natural Philosopher <tnp@invalid.invalid> - 2013-03-08 18:53 +0000
      Re: Why PHP? Robert Heller <heller@deepsoft.com> - 2013-03-08 13:53 -0600
        Re: Why PHP? Richard Yates <richard@yatesguitar.com> - 2013-03-09 15:41 -0800
          Re: Why PHP? The Natural Philosopher <tnp@invalid.invalid> - 2013-03-10 00:06 +0000
        Re: Why PHP? Arno Welzel <usenet@arnowelzel.de> - 2013-03-10 16:45 +0100
          Re: Why PHP? The Natural Philosopher <tnp@invalid.invalid> - 2013-03-10 16:54 +0000
            Re: Why PHP? Arno Welzel <usenet@arnowelzel.de> - 2013-03-10 19:43 +0100
            Re: Why PHP? Jerry Stuckle <jstucklex@attglobal.net> - 2013-03-10 16:51 -0400
          Re: Why PHP? Christoph Becker <cmbecker69@gmx.de> - 2013-03-10 21:59 +0100
            Re: Why PHP? Arno Welzel <usenet@arnowelzel.de> - 2013-03-14 20:15 +0100
              Re: Why PHP? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-14 23:50 +0100
  Re: Why PHP? "J.O. Aho" <user@example.net> - 2013-03-08 18:37 +0100
  Re: Why PHP? clayjar@gmail.com - 2013-03-08 21:38 -0800
    Re: Why PHP? Michael Vilain <vilain@NOspamcop.net> - 2013-03-08 22:06 -0800
  Re: Why PHP? clayjar@gmail.com - 2013-03-08 21:46 -0800
    Re: Why PHP? "J.O. Aho" <user@example.net> - 2013-03-09 12:22 +0100
  Re: Why PHP? David Heller <daveh@allheller.net> - 2013-03-09 06:13 -0800
  Re: Why PHP? Arno Welzel <usenet@arnowelzel.de> - 2013-03-09 16:22 +0100

csiph-web