web notes - a blog

Key elements of RPM spec files when used with web applications:

• Source: - source should be the distribution tar file. If it isn’t yours (meaning it is an open source application), it is best to use the original or distribution URL. That way, you are sure it is unaltered
• Build: - this is really just a copy into a directory
• Files: - since there really isn’t a build process, you are just identifying the files and where they will go. The command suggestion below can be used to generate the filelist.
• Provides and requires must be set carefully to make this work well for complex systems

tar -tzf eztagcloud.tgz | grep -v ".*/$" | awk '{ print "\"""%{targetdir}"$0"\""; }'

Web applications are traditionally distributed with tar files, but they can be packaged as RPMs.

A web application in an RPM should have a tar file with the source. The tar file should have the files from the top of the application file tree, to make it easier if the target directory needs to change. The only parts of the .spec file that really need to be defined are the install, which will copy the files from the build root into a target directory, and clean, to delete the files after the RPM is built. Use tar tf to list the files from that tar (don’t list the directories or warnings will be issued for duplicate files). Be sure to encase the filenames in double quotes, write them to a file and then include them into the files section with the -f option. Using the -f option allows all the files for the tar to be specified, automatically, and ensures additional packages can be defined for the same directory with minimal conflicts.

The group for most web applications is Applications/Internet

RPMs can be created to allow the files to be relocated, another excellent approach would be to use symlinks into a single installation on a server, with account level configuration/access and databases.

During development, a script which creates tar files from the modules can be used to support both the RPM packaging, and create quick distribution packages for updates from a version control system.

Many web companies use a common, core set of javascript libraries and applications which use hierarchical CSS architectures.

If the live server is used for development (which is a very cost-effective approach), thousands of requests are made for the same files.

To reduce this, common components can be sourced from a single point, which the HTTP headers set to cache them with far-future expire dates.

In addition to reducing bandwidth consumption during the development phase, it also reduces it for live sites.

If there are related sites on the same server - the benefit is extended.

This is a small CDN (content delivery network), which allows distribution of customized files for a company, or custom code. It also simplifies management of the common code core, since updates only have to be made to one file.

This saves disk space as well, and speeds page loads.

If there is an issue with having content from a different URL, rewrite rules can be used to hide the true source of the files, while retaining the advantages of a single source.

With additional creative configuration, an application can be used to support multiple accounts. This is riskier, and I don’t recommend it - unless you can be sure you will never change the application. I would try it with this blog software (b2evolution), because from what I’ve seen - it would be very successful.

Web sites have become exponentially more complex and the expectations of site visitors have soared as well.

The only way to build powerful pages is to use sophisticated tools, quickly and effectively.

:!: Choose tools that have decent documentation and a good community. You will need help. Be ready to reciprocate.

B) Use sample code. Everytime you have to learn something new, start with someone else’s posted code. It might not work exactly as you want it to, but you can tweak it, one piece at a time, until it does.

:>> Be very aware of the code architecture. Use an MVC approach, since it is likely you will have at least two views - through a template or HTML and AJAX/JSON.

:crazy: Abandon ideas that are too difficult. This isn’t lazy, it is smart. You’re smart, if you can’t get something working quickly, find another one. Many smart people posted great ideas - use them (and share yours). Abandon tools or libraries that don’t work quickly, too. There is one caveat - if you can see a tool’s potential and are humble enough to admit the problem is a learning curve, it may be worth persisting a little longer. eZ publish is a great example of this - it was well worth learning.

:idea: Be creative.

|-| Use abstract data structures and concepts. Multi-dimensional arrays are incredibly powerful.

:lalala: Be persistent, if it is almost working, keep trying. Try things that don’t make sense, because sometimes, they work - and well.

:oops: Don’t be afraid to be wrong.

:!: Use every available resource, carefully. LAMP is a stack of technology and some parts are better suited for tasks than others. Don’t use bash for page design, don’t use javascript to write large amounts of HTML.

:?: Explore, learn, try. Very little of what I have learned has been useless. Even mistakes and bad ideas are valuable, to avoid.

:yes: Be independent. Don’t ask for help right away. Try to solve your own problems, then ask.

• Should give the user the information necessary to make decisions on the page displayed, as well as links to access additional resources
• Should be consistent, throughout the application
• Should be configurable
• Should be attractive, polished, and easy to work with
• Must include the requisite security
• Should help the user enter valid data, and protect the server from malicious submissions
• Should include AJAX
• Should include a template system
• Usually require access control management
• Should have password recovery
• Should not offer actions the user cannot perform, buttons should be suppressed or disabled visibly
• Should make use of common navigation methods through lists and data sets