Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
In order for it to work smoothly, an exact development copy of the production server is required. This is pretty resource intensive in both servers and admins. Second, the deployment of new applications needs to be communicated to the administrators. This took some time depending on the difficulty of the change. Finally, any issues that popped up in the production server that wasn't seen in the development server required "emergency admin access". It usually meant that a server admin and developer sitting at the same terminal working out an issue.
This method, while not being efficient, forced a couple of best practices. First, because development had to be done a replica of the server, the code was already tested on a server that was identical(as possible) to the original server. Second, because the deployment had to be done by server admins, the developer had to document all the steps required to deploy their application. It let the admins know the changes being made, allowed auditors to see the change, and forced the developer to make an application that was reasonably easy to deploy.
Overall, I think it lead to a pretty clean production environment with much fewer "surprises". However, any code you want to put into production takes twice as long and cost twice as much (approximately). To truly evaluate if it monetarily makes sense, the cost of a failure/fraud in a production environment needs to be calculated. I don't think it is always better one way or another. Although, as a developer it sure was a pain in the ass.
As for clause viii, I believe my actions are in the spirit or intent of the agreement. This is again a completely overly broad statement that protects them in all situations. See above why this is a bad argument.
I have looked at clause ii already and it doesn't apply at all to my site. I am storing photos from my wedding, which are not available on any anyone else's site. This is the first argument that is specific, but doesn't involve me.
If indeed the first two clauses incriminate me, then they incriminate every other GoDaddy user. The third clause doesn't pertain to me. Case closed. Thanks for clearing that up.....
Your style of development is certainly one way to go about it, but the issues you imply occur with other peoples development methods are rooted in your ignorance of their methods. I can infer this, because if you did understand it you wouldn't be making such statements. Bottom line is that it doesn't effect you, due to the awesome and perfect way that you "make web pages". However, some of us have more complex development issues that require us to put files on servers before explicitly sharing them in a way that is not "stupid and unprofessional".
I wanted to post this so that others could avoid their hosting service if they don't want to be harassed for doing, in my opinion, normal web development.
Another thing I think should be pointed out, most web albums consist of server side code that process photos on the server's folders. So, "making an album on my hard drive" doesn't make a whole lot of sense in most contexts.
While a technical solution to the problem would be listing all of my directories for download, I find this intrusion, harassment, and complete lack of regard for a reasonable argument frustrating. They sell me an "unlimited" account of which I am using (1gb) of storage total and they are trying to delete content already? This policy truly surprises me and I wanted others to be forewarned. Is this policy normal for hosting companies?"