| Re: Why PHP? [message #180675 is a reply to message #180671] |
Sat, 09 March 2013 11:22   |
J.O. Aho
Messages: 194
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 09/03/13 06:46, clayjar(at)gmail(dot)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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]