ASP, PHP, dotNET 5

[Hondy]

Hello

Are there any glaring reasons that I shouldn't consider ASP, PHP or dot NET for a commercial web app?

If I speak to .NET'ers they indicate ASP and PHP are old hat and not suitable for proper web apps. I don't believe this, but I need some kind of Pros Cons?

 

[traingamer]

If I speak to .NET'ers they indicate ASP and PHP are old hat and not suitable for proper web apps.

Well, duh. Consider the source.

It depends on what experience you or your developers (if not you) have.

It further depends on what services already exist on the server side (if any). If you have a .net server and expertise in-house, by all means take advantage of the platform. If not, or if you have php experience, use that.

By extension, this applies to coldfusion or any other development platform as well.

(The short answer is nonsense; there are no glaring reasons). But individual circumstances may clearly tilt that answer.

Greg
"Personally, I am always ready to learn, although I do not always like being taught." - Winston Churchill

 

[Hondy]

yeh i know that, thats why I need to be able to argue the difference. I think that because .NET is related to ASP and that PHP is "free" leads to language snobbery.

So then, given that .NET is compiled, does it have any security or other advantages over PHP?

 

[audiopro]

I would second what Greg says about use what is available. If you have a choice of all of them, use the most appropriate tool for the job. I personally prefer Perl for most of my server side work but PHP's image handling is much better than Perl's so I tend to use a mixture.
As for being old hat, I would always try to use a language which I know will do the job in hand.
Having said that .NET may be a much better way of working than my current method, I have never used it but as I prefer to write the code myself rather than have an interface create it for me, the old hat applications suit me just fine.

Keith

http://www.studiosoft.co.uk

 

[ca8msm]

There are no technical reasons to discount any of the languages. Choose whatever language is right for you and your project.


-------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions
[URL unfurl="true"]http://weblogs.asp.net/marksmith[/url]

 

[Hondy]

thanks, i wish i knew more about the technicalities of the languages to be able to put up a decent argument.

I have a project to do and my preferred developer is a PHP guy but I'm going to have to argue the point with the in house developers (who won't be dealing with the project)- but they will be saying that I chose the wrong language :s

Arghhh

 

[audiopro]

Why are the in-house people not doing it?

If it is a stand alone project, it doesn't really matter what language it is written in, as long as it does the job in a reliable way. The only issues the in-house devs would have, would be if they needed to interface to it or maintain it. If they need to interface with it, get the specs of the I/P & O/P vars down in writing before any dev is done and get the author to provide full docs.

Keith

http://www.studiosoft.co.uk

 

[Hondy]

in-house people aren't involved, its complicated

Out of interest, when you code something and spend hours documenting it for your clients do you then charge for this service?

I have worked with a few programmers and it rarely comes with documentation unless you specifically pay them to sit down and write it, I don't like this and they would argue "ok you can have docs but I will charge more per hour to have this included" - in other words full documentation is either part of the price or an extra, either way you pay for it. I can see the logic in this but if you pay for an hours work then have to pay an hour to get them to write it down its a bit harsh.

OK so PHP = good

 

[Foamcow]

Well there's an argument from both sides on the documentation issue.

1. A coder should document anything that they are producing for a client. It sort of goes without saying really. But they should include this in their initial costs.

2. You can't really expect someone to work for nothing. If they haven't included or charged for documentation then you can't really expect them to then write all the documentation for free. As a 'buyer' you should ensure it's included in the price you are paying.


As for "PHP = good". Yes, I love PHP and would use it as my language of choice. But that's just because it's what I do. There is no reason an application cannot be written in .NET as oppose to PHP.

There are alot of great apps written in PHP, there are great apps in .NET. Equally there are alot of badly written apps too.

Personally, I tend to find that .NET apps seem to fail more often. But I think this is indicative of the many .NET "developers" (note the quotes) that just point and click with no real understanding of the mechanics of what goes on under the hood - nor of software development best practice.

The only limiting factors in the choice of language are those already pointed out. Namely:

1. Who is going to support the app? Are they able to work in that language?

2. Will the app integrate easily with other apps already in place?

For instance, if the support team know nothing of PHP then it's a bit daft to commission a PHP application in the first place. You should at the very least consider the cost for training, support into the lifetime costs of the project.





--
Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.

 

[audiopro]

Documneting an app shouldn't take too long but the additional time has to be paid for in some way. I am not industry trained so their procedures are very different from mine. The industry people I know seem to spend a great deal of time in meetings without actually coding anything, that is paid for by someone. I am not knocking this way of working because there is little point in writing anything until the team know what the app has to do and which team member is responsible for which bit. My projects are all small, stand alone apps which are developed with the client. At the start of the project, I usually have a very vague brief which I develop into a full app. My docs are usually brief notes throughout the script which describe what each section does.

During the time of writing the app, I will live and breath the script and know it inside out. A few months after completion I don't know it at all and if the client wants something adding, the notes within the script are essential for me to return to it.

Working out what other peoples scripts actually do can take a lot of time and cost so docs are essential in the long run.

Keith

http://www.studiosoft.co.uk

 

[Hondy]

Thanks guys, I do agree entirely with what you say that someone must pay. Programatical documentation worked into the price is like an insurance policy in case you need additional programmers I guess! Of course the documentation will be good enough for this... won't it?

Most of our stuff is M$ - but I would love to go the opensource route to reduce costs.

Cheers!

 

[BabyJeffy]

I'd go so far as to be quite specific about what you expect to be documented. If you expect unit tests (which can then be used to understand the code - from a developers perspective) then make sure you state this clearly (what coverage do you expect etc). If you expect "business analyst" style documentation at a high level - make that clear. If it has a significant user-facing component, is there a design (or style) guide that is expected (or updated)? Do you require the developer to maintain (any) existing documentation (such as the design guide or specific use cases)? I'd write it down as part of the initial contract to ensure there is no confusion down the line.

Cheers,
Jeff

[tt]Jeff's Blog [!]@[/!] CodeRambler

http://www.coderambler.com/

http://www.coedit.co.uk/

[/tt]

Make sure your web page and css validates properly against the doctype you have chosen - before you attempt to debug a problem!

FAQ216-6094

 

[Hondy]

Yeh thanks Jeff.

I would like to know what percentage of a project is actually code writing time when you have:

Meeting after meeting
Code writing
Testing
Bug Fixing
Documentation
Roll Out
More bug fixing!

 

[ChrisHunt]

When you code something and spend hours documenting it for your clients do you then charge for this service?

Anything I spend hours doing for clients is charged for.


-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[traingamer]

Code writing should be less than 20-25% of a typical project. Analysis, design and testing should take the bulk of your time. (Your mileage may vary).

Hey, you guys start coding; I'll go see what they want...

Greg
"Personally, I am always ready to learn, although I do not always like being taught." - Winston Churchill

 

[GUJUm0deL]

Why can't Coldfusion be part of the solution? CF8 can do pretty much anything you want, and learning CF is incredibly simple as it follows HTML-style coding.

_____________________________
Just Imagine.

http://www.imajinarts.com

 

[BabyJeffy]

Hondy, for me it's about time management. We all have to deal with external activities (meetings, presentations, documentation, bug fixing etc) and I tend to manage them in such a way that I ensure I get the chance to do some coding...

A typical day might be:
9.00 standup meeting to discuss progress and identify what tasks will be done in the following day
9.30-10.30 available for meetings (or doing bug fixes if no meetings)
10.30-12.30 coding new functionality - not available for meetings
1.30 - 2.30 bug fix exploration and delegation
2.30-4.30 coding new functionality - not available for meetings
4.30-5.00 document the work completed today
5.00-6.00 available for meetings (or doing bug fixes if no meetings)

If you do a little bit every day, it's not such a burden - and you don't forget what it was you worked on. The documentation medium for us is a wiki - so it's 100% visible to everyone all the time (which makes it harder to ignore doing).

Hope that gives you some mileage!

Cheers,
Jeff

[tt]Jeff's Blog [!]@[/!] CodeRambler

http://www.coderambler.com/

http://www.coedit.co.uk/

[/tt]

Make sure your web page and css validates properly against the doctype you have chosen - before you attempt to debug a problem!

FAQ216-6094

 

[GUJUm0deL]

Jeff, I have to admit I don't really use wiki (or even visit that site much), but if you're using wiki as a documentation medium for your company, doesn't it mean that anyone on the web has access to it? Usually documentations have processes that is meant for internal folks. How does that work for your company?

_____________________________
Just Imagine.

http://www.imajinarts.com

 

[johnwm]

I think Jeff may be suggesting A wiki rather than Wikipedia

Have a look at the Wikipedia definition of wiki to get a better understanding of what he is suggesting

___________________________________________________________
If you want the best response to a question, please check out FAQ222-2244 first.
'If we're supposed to work in Hex, why have we only got A fingers?'
Drive a Steam Roller
Steam Engine Prints

 

[BabyJeffy]

You are indeed correct, I mean A wiki

We use the Trac wiki:

http://trac.edgewall.org/

It's been configured on the corporate intranet to remain available only within the intranet. Personally I get frustrated by the markup you have to use - but you get used to it.

Cheers,
Jeff

[tt]Jeff's Blog [!]@[/!] CodeRambler

http://www.coderambler.com/

http://www.coedit.co.uk/

[/tt]

Make sure your web page and css validates properly against the doctype you have chosen - before you attempt to debug a problem!

FAQ216-6094