Free web pages ... know your ISP ...

Many people would like to put up simple web pages but are not quite sure where to start.

Start with your ISP. Many ISP’s include web space as part of their service agreement. It is usually supported with tools that make it easy to post materials on the ‘net.

This is a great way to learn about the Internet.

It can be used by individuals or very small businesses. If you want to point a domain at it, you can. You can use PayPal to accept payments, and, in very little time, for little to no cash, you will have a site up.

Got questions? Go to the ISP’s web site, or call them.

Reduce your 'net print

Bandwidth reduction will soon be a priority. The proliferation of RIAs exponentially increases the bandwidth requirements of initial page loads, while potentially reducing that of subsequent requests.

  • Use public CDNs - both to access and distribute libraries. Public CDNs are built for this purpose and often compres content. If you have your own CDN, use it.
  • Use and allow the use of logo images from their original sources. For example, the logo for your product could be displayed, from your server, on many sites. This allows headers to be set for browser caching, such that subsequent requests for the images will be served from the client, not the server.
  • Use compression where appropriate. Optimize images and ensure text is text, not images.
  • Examine your file and page architecture. Strive to deliver only that content required for each page.
  • Check the stats to find where the bandwidth is being used and focus on improving page performance for those pages. Use
  • Use AJAX.
  • Develop locally, use XAMPP or VMWare.

Software etiquette

Many web development projects are done outside conventional version control environments. The overhead of version control simply can’t be justified for a small application or the customization of a site. However, it the development is performed by a team, particularly a distributed team, common etiquette should be observed.

  • Don’t change other people’s code. Either request they change it to your specifications, or ask if it is okay for you to make the change. If you receive such a request, reply promptly and act promptly, otherwise, you should assume the requestor will make the change.
  • Keep your own backup. This is a good practice anyway. This includes the database.
  • Use a site architecture that makes it easy to separate design and logic, and communicate it to the team. For example - all CSS/HTML/templates are the domain of the design team, all PHP/applications/installations are engineering.
  • Identify an authority to resolve any conflicts, and clearly document any likely exceptions to the file architecture above.

Management of an extremely low cost site

  • Let the client see exactly what they will be purchasing. Have an online demo, where they can upload a logo or image (must have enough colors for good results) and see an example.
  • Offer logo design services for clients without a logo. Set a time limit for the designer and make it clear to all parties. Low cost means exactly that.
  • Provide clear pricing for services beyond the initial installation.
  • Grant the client access to cPanel like functionality and allow them to manage their email acocunts by themselves. Again, provide a demo (perhaps a link to the hosting company demo).
  • Be upfront about the service being provided - which is a low cost design integration. Credit the sources of the software and explain why you use it. Suggest the client attempt to do the work on their own if they would prefer. You may lose an independent client, but you may also avoid a dissatisfied customer who challenges the cost of a system based on free software.
  • Make support limits clear. Support can be extremely expensive. Ensure the client understands that once the site launches, support will cost them.
  • Provide a ticket system (existing companies should have one already) and request that all support requests go through it. Phone calls can be extremely expensive.

Caveat - without careful management, these projects will be very prone to cost overruns.

Know what it costs before you offer it! Allow the technical team to define the process and determine EXACTLY how much time it takes after the NRE (non-recurring engineering) has been done to put up a site and grant access. If it won’t be profitable, don’t do it.

RPM vs. tar for distribution for open source web applications

RPM advantages

  • Installation always puts it in the same location
  • Single copy of the source on the server, saves disk space
  • Potentially more secure, since permissions can be set to read-only
  • RPM can serve as an installation wizard, rather than writing one
  • RPM can also uninstall
  • Dependencies managed by RPM
  • Upgrades can be managed by RPM
  • Fits nicely into larger architecture
  • Can cross directories to handle configuration at different levels, for example, add an Apache .conf file.
  • Allows custom default configuration to be installed easily

RPM disadvantages

  • Single copy means application shouldn’t be customized once installed, all accounts will have to run the same
  • Single copy also means there may be additional filesystem architecture adaptations, for example a compiled template directory normally placed under the application would have to be accommodated. Application may have to be modified
  • May require root access
  • Filesystem architecture should be known
  • Requires installer to have some knowledge of RPM, usually more complex than tar
  • Requires installer to understand more filesystem commands (how to link into installed application, rather than install it
  • If application is normally distributed as a tar/gz file, RPM will be outside the documentation
  • Creating RPMs is far more complex than creating tars. Learning curve.
  • Development team and environment. If everyone is working on a single server, it may be difficult for them to share a single copy of an application. Consider VMWare.

Deciding Factors

  • Installation type - single application on the server, or multiple. Single is best with RPM, multiple is probably better with tar
  • Application source - custom applications may be better with RPM, outside/open source applications are probably better with tar
  • Dependencies and type - RPM really does a nice job with dependencies
  • Upgrades - RPM allows yum/up2date management of upgrades, with dependency observation
  • Skill/experience/education level of team
  • Servers in use - tar may be slightly more portable
  • Flexibility of target system
  • Updates during development are very easy to apply with RPMs