StrivingLife presents ...

JavaScript appears to be disabled. We recommend you enable JavaScript while visiting this site.

Logical coding

by James Skemp, May 28, 2006 07:49

(All original content on this site is licensed under the Creative Commons License Attribution-Noncommercial-No Derivative Works 3.0.)

When it comes to proper coding, you should know the most important rule of all; LIFO. However, not even LIFO nor the W3C can really tell you which order to put certain elements. In the nature of Web 2.0, I'll discuss some of the standards I've been bouncing around for HTML text markup when the same text is given multiple attributes.

LIFO

LIFO - or last in, first out - states that that which is last stated is dismissed first. So, to take some empty ColdFusion code;

<cfif x = y>
  <cfif y LTE z>
  </cfif>
  <cfif y GT z>
  </cfif>
</cfif>

Here, we have opened an if-statement. We then opened another if-statement within our first, closed the second, opened a third, closed the third, and closed the first.

We also do LIFO in simple code. For example, to create text like this,

<strong><em>this</em></strong>

To be proper, we must close the emphasis before we close the strong tag. If we did the following, we'd be wrong.

<strong><em>this</strong></em>

Applying multiple attributes to the same block of stuff

In our previous example, where we place both emphasis and bold on the same group of text, we run into a bit of a question; which comes first? Do we place emphasis on the fact that the text is bold, or bold the emphasis on the text? I argue that we do the latter.

Before we tackle this one, let's tackle an easier one; a bold link.

In such a case we would have an <a> and a <strong>. Does one preempt the other when they apply to the same thing?

If we have a paragraph that has bolded, with a link within it, then the ordering is natural.

The question is, is there any case where a word would be bold, but the entire paragraph would be a link?

Since we can apply a style on a link, namely font-weight:bold, it's possible that bold text within a link could not be seen. By doing so, we risk the chance that the link would be lost. Logically, we can also ask whether we are linking the bold text, or just the text. In some cases, we may want to bold a particular word. For example;

Download the PDF version of the document.
Download the Word version of the document.

Yet, that is not within the scope of what we've asked.

Download the PDF.

In such a case, we are calling attention to the fact that there is a link where you can download the PDF. Therefore, when we code this, we do it as follows.

<p><strong><a href="#">Download the PDF.</a></strong></p>

We're not giving emphasis to some text within the link, we're giving emphasis to the fact that there is a link. So, if we were to look at <a> and <em>, we would thereby put the <em> surrounding the <a>.

Going back to our emphasis / strong question, on which do we apply which? For both, we can use styles to remove the usage of <strong> and <em> altogether. However, if we do use both, in which order? As I stated above, I argue that we bold the emphasis.

Deadline ends August 2006.

Deadline ends August 2006.

Deadline ends August 2006.

Really, though, it depends upon which of the first two we would do if we could only do one or the other. Do we give it emphasis, or do we bold it? In both cases, we're giving the text emphasis. As I see it, by using <em> we're using emphasis within the text, while using a <strong> gives a style emphasis. That is, in most paperbacks, <em> is used. It's rare to see bolded text. However, bold text is used for layout emphasis; to call attention to something outside of where one would look in the natural course of affairs (so to speak).

Given that view, we <strong> the <em>, or bold the emphasis.

<strong><em>Deadline ends August 2006.</em></strong>

Obviously, if we're only bolding a portion of the emphasis, or giving emphasis to a portion of bold text, then we would follow LIFO.

Conclusion

Given the above, I've now argued that when it comes to <strong>, <em>, and <a> surrounding exactly the same text, the order of placement should be as follows;

<strong> <em> <a>

Otherwise, LIFO always gets priority.

Comments on this conclusion are indeed welcome.

Tags:
Categories: article | general programming

Upgrading (our local install of) ActivePerl

by James Skemp, May 26, 2006 17:36

(All original content on this site is licensed under the Creative Commons License Attribution-Noncommercial-No Derivative Works 3.0.)

In a previous guide, we walked through installing ActivePerl on a local machine. This time, we'll be upgrading ActivePerl. For this guide, we'll be upgrading from ActivePerl 5.8.7.815 to 5.8.8.817. However, since the installation requires the uninstallation of previous versions of ActivePerl, we'll simply be installing a new version of ActivePerl. If you have not installed Perl before, you can skip ahead to "Installing Perl" below. Please note that this guide will work equally well for the installation of, or upgrade to, ActivePerl 5.8.8.819.

Uninstalling Perl

To upgrade Perl, we'll first need to uninstall Perl. Head over to the Windows Control Panel and Add or Remove Programs. Select ActivePerl 5.8.7 Build 815 and Remove the program.

Once the uninstall has finished, you'll need to manually remove every directory in your installation folder with the exception of the site\lib folder. So, if you followed by advice, leave C:\usr\html\site\lib\, but remove everything else. Note that if you haven't done much with ActivePerl, you may want to simply rename the usr folder to usr2, or delete it completely.

Installing Perl

Now that we've uninstalled our previous version of Perl, we can install Perl. To install Perl, we're going to download ActivePerl from ActiveState. Navigate to http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl, and download the MSI file for Windows. When writing this, the current version is 5.8.8.817, and the download size is very large 12.8 MB.

Once we've downloaded this file, we'll open it. Read and accept the license, and on the next screen, leave the installed settings alone, but change the Location from C:\Perl\ to C:\usr\. We'll be doing that in order to keep with Linux (just like we installed our content to C:\home\).

On the next screen, keep the first two boxes checked, and leave everything else unchecked. Finally, hit the Install button to begin the installation.

Once the rather long installation has finished, we may need to modify the Apache httpd.conf file so it can recognize Perl. Note that if you've already installed Perl, you may skip this step safely. However, you may still want to restart Apache.

Setting up Apache

To setup Apache to recognize ActivePerl, open up the httpd.conf file as before, using the Start menu or the shortcut in your main Web folder. Now, search for "ExecCGI". Scroll down to the first uncommented line, and add the following information, displayed as bold text.

Options Indexes FollowSymLinks MultiViews ExecCGI Includes

Now do a search for "AddHandler". Scroll down a couple of lines until you reach the commented lines below.

# To use CGI scripts:
#
#AddHandler cgi-script .cgi

#
# To use server-parsed HTML files
#
#AddType text/html .shtml
#AddHandler server-parsed .shtml

Remove the comments from the three lines so that the above becomes the following. Note that lines changed are bold. We'll also add the .pl extension to the end of the first uncommented line, to allow another file type to be run.

# To use CGI scripts:

#
AddHandler cgi-script .cgi .pl

#
# To use server-parsed HTML files
#
AddType text/html .shtml
AddHandler server-parsed .shtml

The last two lines will allow us to add simple server-side pages to our site. These files are created on the server, and then displayed to the user. Using server-parsed HTML files, we can create a standard header and footer that is displayed on every page (so long as we tell the page to include it).

Finally, do a search for "ScriptAlias /cgi-bin/" and comment this line. So, when you're done, it should read as follows.

#ScriptAlias /cgi-bin/ "C:/Program Files/Apache Group/Apache/cgi-bin/"

This change will allow us to place, and run, CGI scripts in any folder, not just the above folder.

Once these changes have been made, save the httpd.conf file, and restart Apache. Now that Apache has been restarted, we'll test our installation of Perl. To do this, open Notepad and copy or type the following text into it.

#!/usr/bin/perl
print "Content-type:text/html\n\n";
print "Hello world!";

Save this file into C:\home\, and call it TestCGI.cgi. Now, go to http://localhost/TestCGI.cgi. The page should load with the text of "Hello world!".

View all of the steps to creating a local Web server, for development.

Tags:
Categories: software | tutorials/guides

1,000 spam caught by Akismet!

by James Skemp, May 26, 2006 06:26

(All original content on this site is licensed under the Creative Commons License Attribution-Noncommercial-No Derivative Works 3.0.)

As of this morning, exactly 1,000 spam have been caught by Akismet for this site. Not too shabby. Unfortunately, I don't know when this started, but it was before I got really hit.

On that note, Akismet 1.15 has also been released. Included in this is the big addition of a delete button at the bottom of the page (for those of us that look over comments).

Update: June 10, 2006 @ 6:39 pm

1400 as of a couple minutes ago. Yikes.

November 24, 2006 @ 11:26 am

10,000+ as of a few moments ago.