WEBSTANDARDS Archives

January 2010

WEBSTANDARDS@LISTS.UMN.EDU

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding:
7bit
Sender:
UofMN CSS Web Development <[log in to unmask]>
Subject:
From:
Gabe Ormsby <[log in to unmask]>
Date:
Mon, 25 Jan 2010 16:34:55 -0600
Content-Type:
text/plain; charset=UTF-8; format=flowed
MIME-Version:
1.0
Reply-To:
UofMN CSS Web Development <[log in to unmask]>
Parts/Attachments:
text/plain (53 lines)
Several people have already hit several of my thoughts, so on most of 
the following, my input is basically "Me too." The one thought I'd add 
is that it would be great if scripting/database-enabled hosting packages 
came automatically with a development installation running on the same 
host as the production site (or a clone). It would be great if, when I 
ordered up newsite.umn.edu, I automatically got dev.newsite.umn.edu and 
www.newsite.umn.edu.

The "Me too"s:

- Clearer documentation about what's available (and in this, I mean both 
as a "product" and as a negotiated capability. When learning about 
hosting available at the U when I first started working here, I ran into 
a few "Oh, that's available, it's just not on the menu" moments.)

- For hosting accounts that include a database as well as scripting 
support, some means of accessing the database is essential - Shell 
access, even PHPMyAdmin or analogous tools.

- Andre's point about anticipating future changes and continuing 
decentralization of skills is a great one - I think OIT should focus on 
crafting offerings that allow choices for clients (VPS vs. shared 
hosting, php|perl|ruby|python/*SQL) rather than trying to forecast which 
one or two higher-level platforms (e.g. Drupal) will be most popular.

- In a similar vein, offerings should be tiered somehow to recognize the 
diverse needs of U staff - some are comfortable with the whole stack, 
others with parts, others with app front-ends. Services should offer 
some accomodation to these different levels of need, as much as this is 
possible when crafting manageble slate of offerings.

- +1 on Zach's note about highly-privileged sudo or root access where 
possible, esp. in a virtual server situation, where package upgrades, 
apache configuration, and direct database access needs are nigh inevitable.

- +1 for a Debian or Ubuntu server option.

- I second Tony's suggestion about bringing internal services closer in 
line with commercial offings (pricewise and functionally). I'm agnostic 
on the "common good" vs. fee-for-service question - I would expect that 
much of what we're suggesting can be priced competitively if the 
fee-for-service route is taken - let the accountants figure that one out :-)

-Gabe
-- 
Gabe Ormsby
Web & Database Developer
612-625-6221

Office of the Senior Vice President for System Academic Administration
University of Minnesota Twin Cities
http://www.academic.umn.edu/system/

ATOM RSS1 RSS2