Archive for July, 2009

Quick and Dirty Guide to Deploying Rails with Capistrano

Wednesday, July 29th, 2009

Capistrano is one of those problem solving apps that can be tricky to setup at first, but is a no-brainer once you’ve deployed with it.

I added a few notes about hosting on Dreamhost because they only support rails 2.2.2 at the time of this writing. My current app is actually developed under 2.3.2.

With Dreamhost, you only get a RAILS_ENV=’production’ setup on Passenger hosting…but that is good enough. I prefer to run test.the-app.com locally anyway.

If an app of mine gets popular, I would move it off of dreamhost regardless ( security, reliability, etc ). Try slicehost or linode if you’re looking for a more professional web hosting solution.


#create the_rails_app_production database
#setup db.the-rails-app.com db server
#setup domain the-rails-app.com to look in ./current

#!/bin/bash
cd ~/the_rails_app
mkdir config/deploy
for e in 'staging production testing'; do touch config/deploy/$e.rb; done;

echo '#!/bin/bash' > script/spin
echo 'touch tmp/restart' >> script/spin && chmod 755 script/spin

# dreamhost only:
# change config/environment.rb to require rails 2.2.2
# change config/database.yaml (production:) and delete the socket ref for mysql
# add symlink to older application.rb controller

svn ci -m 'initial capify'

capify .
cap deploy:setup
cap deploy:check
cap deploy:update #fix all errors until this succeeds
cap deploy:migrate #initial migration of db
#if using 2.2.2 be sure to symlink application_controller.rb to application.rb

cap deploy:start

# if you modify anything, be sure to checkin and deploy:update again

VN:F [1.8.4_1055]
Rating: 10.0/10 (1 vote cast)
VN:F [1.8.4_1055]
Rating: 0 (from 0 votes)

Browser Testing: How to learn the best coding practices

Monday, July 20th, 2009

Its easy to install a virtual machine on your laptop or desktop computer that will allow you to run other operating systems within your main os (ie: linux, windows running inside MacOS).

Virtual Machines:

Parallels
VMWare

The uncommon browsers may not be the largest part of your UserAgent slice in web stats, but don’t belittle the gain you will get in building accessible web sites and testing with them.

Common Browsers:

Internet Explorer 6, 7, and 8
Mozilla Firefox 2.x (recently released 3.0)
Opera
Safari 3.x
Shiira (new comer to Mac OS that strives for complete W3C compliance)

Unlikely Browsers:
Lynks (command line browser for the shell: linux, bsd, *nix)
Links2 ( some support for basic javascript and css, command line browser)
Gnopernicus ( open source screen reader available for Linux)

Its important that your clients have the ability to access your web site in a plain-text html fashion (no CSS or JavaScript) should their own personal needs require it.

You will learn a bit more about the importance of using semantic markup after looking at your site in Lynx for example. Using Gnopernicus is another great test to see how your web site holds up to text readers (otherwise known as “screen readers”). It is freely available on Linux.

There are a few handy tools for Firefox as well that will let you disable javascript, images, and css at the click of a button. You can also resize your window to see if it scales well down to minuscule screen sizes such as a mobile phone.

VN:F [1.8.4_1055]
Rating: 0.0/10 (0 votes cast)
VN:F [1.8.4_1055]
Rating: +1 (from 1 vote)

Docbook Customization Layer

Monday, July 13th, 2009

I decided to use Docbook as the place to store user interface documentation for my employer’s web applications.

The UI documentation has the “customization layer” implemented as described in the Docbook XSL book available online.

The customization layer, generally speaking, is a way to override the default docbook xsl stylesheet rules and templates in favor of our own.

For example a docbook paragraph may be defined as:

sample.xml fragment:

<book>
	<section>
		<title>User Interface Help</title>
		<para>Content goes here...</para>
	</section>
</book>

The default docbook xsl template for “section” might produce something unwieldy like this:

<div class="section">
	<div class="title">
    		<font size="4">User Interface Help</font>
	</div>
	<div class="para">
		<p>Content goes here...</p>
	</div>
</div>

A customization layer for a docbook xsl template enables us to write our own templates producing cleaner markup after the xml -> html transformation:

<div class="help">
	<h2>User Interface Help</h2>
	<p>Content goes here...</p>
</div>

The UI docbook customization layer can be found here in trunk:

	/myproject/ui/source/xslt/docbook

Only customized docbook xslt files belong in the above directory.

The “default handling” for docbook XML tags are pulled from the file system’s location of docbook as installed on the operating system (and should *never* be modified because changes will not be distributed):

	/usr/share/xml/docbook/stylesheet/nwalsh

This location may be different based on your local environment, and is defined in a configuration file somewhere under /etc and picked up by the xml processor from the DOCUMENT type declaration in a given docbook file (ie: the user interface’s glossary.xml file).

VN:F [1.8.4_1055]
Rating: 0.0/10 (0 votes cast)
VN:F [1.8.4_1055]
Rating: 0 (from 0 votes)