Comments on: Podcast 26: Technical considerations

By: Shammie Jayaransie

Shammie Jayaransie — Fri, 23 Jun 2006 10:47:34 +0000

thanks

By: eric marden

eric marden — Fri, 24 Mar 2006 16:03:15 +0000

You may be invested into Groove, but I want to suggest Basecamp – one of the best web applications I’ve used for project managment. It’s built by the same people that developed the Ruby on Rails framework and is an elegant example of usability, productivity and just the right about of AJAX to make the application reallly respond.
It’s very useful for collaborating with your clients, and I’ve found it very intuitive and easy for them to pick it up.

By: Dennis Lembree

Dennis Lembree — Sat, 11 Mar 2006 16:06:48 +0000

Great points, Phil. Also, I believe it's wise to somewhat regularly burn sites on a CD/DVD or external hard drive in order to archive it somewhere safely.

By: Ed

Ed — Thu, 09 Mar 2006 14:56:59 +0000

I know in my web standards aware mind that web standards is the way to go for an easily findable site, but then I do a search for "worst Christmas page" on Google, and what comes up first? My award winning bad site, that doesn't conform to any web standards at all! (though do a search for "worst Christmas site" and the podcast page for that episode comes up first, which would be made with web standards.)

By: Phil Palmieri

Phil Palmieri — Wed, 08 Mar 2006 17:42:35 +0000

In reference to your last podcast about backing up your website i just wanted to
jump in. ( i know it’s a short book ).
First, to your business people, always require a CD or other Soft copy of the
completed project on final payment – you shouldn’t have to figure out how to
download the site yourself, that what you are paying a web company for.
Second, to developers. You shouldn’t really (in practice) have to backup your
production server, your production server in essence is a snapshot of a stable
release. You should be backing up a version from the dev environment.
You can do this with a CVS like you mentioned, but in a 1 man shop I build a
version on my development server, then when i have a release i make a zip of
that stable version and archive it.
You should NEVER in a perfect world be touching your production files – if
something needs to be changed, change it on the DEV Server, then when it works
move it up. I know this is a hard concept to implement 100% because some
people want things, and they want them now – and its hard to justify a release
for a ridiculously simple update. I adopted the habit of if the client must
have the change now – i make them sign a document stating that they are aware
it hasn’t been tested etc, etc.. Usually this scares them off. – but if not, i
am 100% covered.
If you are looking at hiring a company to do web development, and they do not
offer an development view (not public) of your projects – run and hide — that
is usually a good sign of the professionalism of the company. It’s almost the
Hobby / Professional boundary – along with other things.
Did i mention not to ever, ever, ever work on the production server? Ok.

By: Gerben

Gerben — Tue, 07 Mar 2006 20:32:24 +0000

Again, good podcast. Loved the backgroundsound of keyboards and spinning cooler-fans ;-)

By: jedatu

jedatu — Tue, 07 Mar 2006 17:05:06 +0000

You should consider using http://www.shrinkster.com to shorten the links you read out over the podcast. As long as everyone knows you are using shrinkster, then all they need to remember is the 3 character code at the end. Here is a shrinkster link to this post: http://shrinkster.com/cqw Great podcast guys!