All posts by Tom Gutnick

Professional computer geek extraordinaire! I'm a technologist, educator, and musician. And teaching is a great opportunity for me to share what I've learned and to keep learning.

Tom Gutnick — Welcome

This is the public-facing web site for Tom Gutnick at Northern Virginia Community College. You can find information here about all the classes I teach at NOVA, along with blog posts on topics related to my classes. If you’re considering taking one of my classes, feel free to contact me (phone or email) with any questions — I’ll be happy to hear from you.

(Enrolled NOVA students: you’ll find the detailed notes you need for each class through Canvas.)

Spring is blooming and resources are abounding

Just a quick grab-bag of useful stuff that has appeared this week:

  • In class recently, we’ve talked about security vulnerabilities, and some of you wondered what you should do to write secure code. I said that that’s easily a topic for an entire semester. But here’s an article that can help you get started: Safeguard your code: 17 security tips for developers
  • There are many reasons HTML and CSS might make drive you nuts. A curated list of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas: WTF, HTML and CSS? (If you’re offended by slightly profane language, you might not want this.)
  • Oranges, Pickles And CSS Selectors! CSS Diner is a web-browser-based game, involving bento boxes, plates, and food on the plates. See how well you know the rules for CSS selectors.

Don’t Touch that Aspect Ratio!

In class, we were discussing the displaying of images with the <img> tag, and I talked about not changing the aspect ratio.  I want to make sure the concept is clear.

The aspect ratio is simply the ratio between the width and height of an image. Here is an image with a 1:1 aspect ratio — that means that the width and height are the same. Continue reading Don’t Touch that Aspect Ratio!

Who needs resolutions?

As we were discussing what can fit on the screen, a question came up about the meaning of screen resolution.  Let me attempt a quick overview here.

The basic graphic unit for computers is the pixel (short for picture element).  What we see displayed on a monitor is composed of a grid of pixels.  The screen resolution is the dimensions of this grid.  For early computer monitors, a typical resolution was 640 x 480 — in other words, the grid was 640 pixels wide by 480 pixels high.   Continue reading Who needs resolutions?

“The Art of Readable Code”

For about as long as computer programming has been going on, so has the quest for better-quality code. Among the early additions to my bookshelf were “Programming Proverbs for FORTRAN Programmers” (1975) and “COBOL with Style” (1976).  Both books’ covers promise “Principles of good programming with numerous examples to improve programming style and proficiency” — Continue reading “The Art of Readable Code”

Bloodhound Needed?

As you’ve been discovering all semester, it can be challenging to get your CSS code to do exactly what you want it to! Recently, I was looking over an interesting book, The CSS Detective Guide: Tricks for solving tough CSS mysteries by Denise R. Jacobs. A lot of good ideas here, much along the lines of what we’ve discussed in class, but with much greater detail.

And I learned something new. The book referred me to a page at W3C, validator.w3.org/docs/errors.html. This document explains, with a bit more verbosity than the default, the meaning of the various error messages put out by the HTML validator. Feeling stuck? Check it out!

In Search of eXtensibility

The standard for code in our class this semester will be XHTML 1.1, which is similar to the XHTML 1.0-Strict we used in ITD 110 — all the deprecated stuff is gone.  In case you’re new to XHTML, here are the main differences compared to HTML:

  •  The page must start with an appropriate prolog.  (Check the textbook, section 2.3, for details.)
  • All tags and attribute names must be in lower case.
  • All attribute values must be enclosed in quotation marks.
  • Every attribute must have a value.  (For example, <input type=”radio” selected=”selected”> instead of <input type=radio selected>.)
  • Every tag must be closed.  (For example, <p>Some text…</p>, or <hr />, or <img src=…  />.)
  • Tags may be nested, but should never overlap.  (For example:  <p><b><i>Some text</i></b></p> is correct;  putting the  close tags in any other order is incorrect.)

All code submitted, either for homework or projects, should be successfully validated.  Three ways to validate your code (listed from easiest to hardest):

  1. In Opera, right-click on the page (but not on an image or a link) and then click on Validate.   Or press Ctrl+Alt+V.
  2. In Firefox, install the Web Developer extension (which is a good idea for this class, for many reasons).  Then, while viewing the page, click on Tools | Validate HTML or press Ctrl+Shift+H (if you’re viewing a page on a web server) or Tools | Validate Local HTML or Ctrl+Shift+A (if you’re directly viewing a page on your own system).
  3. Visit the W3C Validator page and follow the instructions there.

Happy coding.

I Got the Winter Whites Instead of the Blues

In all the years I’ve been teaching at Nova, this is only the second time I’ve had a class cancelled due to weather — I guess it depends on your perspective whether that’s good or bad.  I am disappointed though, as I was looking forward to meeting new people and seeing old students again.  (I won’t normally phone everybody in case of a cancellation, but I made an exception for the first night.)

As noted in the e-mail I just sent everybody, the college has no provisions for make-up classes, so we’ll just have to do a bit of double-timing to compensate.  This week’s homework assignment will be due as originally planned. The good news is that the first two weeks are largely reviewing what you should already know (XHTML 
and CSS), so it shouldn’t be too much of a scramble. If you’re not sure of your LAN ID (that’s the one you use to log in to any of the computers on campus), there are workstations where you can look it up in the Loudoun library and the open computer lab. If you have problems getting your assignment published to your college web space, contact me and we’ll try to get it sorted out.

Have a great week, and be sure to contact me if any questions: e-mail or instant messaging (see Syllabus for details) works best, but you’re always welcome to try my cell phone.

In lieu of me trying to entertain you tonight, enjoy this extract from David Pogue’s New York Times “Circuits” column today:

Imagine (sung to the tune of John Lennon’s “Imagine”)

Imagine there’s no Apple,
No products that begin with “i,”
No monthly iPod models,
No Apple stores to get you high.
Imagine all the people
Finding other things to do!

Imagine there’s no bloggers…
It isn’t hard to do!
No viruses or spyware,
No weekly Windows patches, too
Imagine all the people
Learning to get a life…
(You-hoo-hoo!)

You may say it’d be a nightmare
Without Google, Mac or Dell
We might have real conversations–
But the world would be dull as hell!

Imagine no new cellphones;
Kiss console games goodbye.
No David Pogue or Mossberg
To tell us what to buy.
Imagine all the people
Getting some exercise!
(You-hoo-hoo!)

You may say that I’m a loony
But rest assured I’m almost done.
I’m pretty sure it’ll never happen
So we nerds can live as one!

More Textbook Blues

After 8-1/2 chapters of starting web pages with
  <?xml version=”1.0″ encoding=”UTF-8″?>,
the author suddenly springs a new version on us on page 359:
  <?xml version=”1.0″ encoding=”iso-8859-1″?>!

I don’t know why she did that — presumably it’s a mistake.  But the good news is that it doesn’t
matter:  you can expect to get similar results with either character set specified.

Over the Waterfall?

Hmmm, another language, different syntax, more attributes to remember.  The good news is that in the long run, Cascading Style Sheets make it easier to create and maintain attractive, consistent-looking web pages.  As I’ve mentioned in class, the W3C has a CSS Validator, which works similarly to the XHTML Validator.  (One warning:  your code must successfully pass XHTML validation before the CSS validator will run.)

There are likely to be times  when the styles are not being applied as you expected, and you’ll feel like banging your head against the wall.  In general, head-banging doesn’t solve coding problems, but there are some tools which might help you.  If you prefer working in Firefox, you’ll want to install the Web Developer and Firebug extensions;  for Opera, install the Web Developer Tools.  You find links to all three on the class Tools page.  The download pages include documentation for using the tools.  Questions?  Bring them to class and we’ll try to answer them together.

Happy coding!

More Validation Blues?

If I were a frog, I guess I’d be singing the greens, but either way, it’s sometimes a challenge to get code validated — partly because of our own mistakes, but partly because of tag attributes that are non-standard.  I know that some of you have run into issues trying to validate the chapter 5 case study.  As we’ve discussed in class, sometimes it’s easiest to just look at the standard to see what it says is allowed.

Sitting on a shelf right over my head is “HTML & XHTML: The Complete Reference”.
(See the  class Tools page for bibliographic details.)  I use it a lot to answer such questions, but sometimes I do bite the bullet and read the DTDs at w3.org.  The one for framesets is at www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Frameset. If you look there, you’ll find just which attributes are allowed for both frameset and frame tags. Today, I’ll save you the effort. For frameset, the only valid attributes are rows and cols — sorry, no frameborder. For frame, there are several valid attributes, including name, src, noresize, scrolling, marginheight, marginwidth, and YES, frameborder. Note that the valid values for frameborder are 0 and 1 (that’s not pixels, but rather signifying “no” or “yes”).

Happy coding.

I Got Them Code-Won’t-Validate Blues

It’s very frustrating when you try to validate an XHTML file and either the validator says it can’t make sense of your file and gives up or it gives you dozens upon dozens of error messages.  Fortunately, the problems are usually solved pretty easily.  Here are some of the most common reasons for problems:

  • Prolog problems.  The validator relies on the prolog to know exactly which flavor of (X)HTML to validate your code against.  If there’s a problem with the prolog, the validator can’t do its thing.  So make sure all three lines (the XML and Doctype declaratations and the html tag with xmlns) are exactly correct.  A single mistyped character is enough to throw the whole thing off!  In particular, be careful of case-sensitivity, and with the word xhtml1, make sure you’re clear about what’s an “L” and what’s the digit ONE.
  • Embedded spaces.  Space characters are never valid within a URL, so make sure that you don’t use spaces in the names of any of your HTML files or bookmark anchors.  I generally prefer to keep file names and anchor names short, but if you feel that you need a long one, name it like one of these:  FileWithALongFilename.htm or file_with_a_long_filename.htm or file-with-a-long-filename.htm.
  • Invalid characters.  If the validator sees a character that is not part of the encoding character set (probably specified in your xml declaration, otherwise maybe defaulting to “UTF-8”), it will reject the entire file — but it will give you the line and column number of the offending character.   If you need to use foreign accented characters, be sure to code them with the proper HTML character entities.  Also, be careful if you copy-and-paste from another source — programs such as MS Word will convert your typed apostrophes and quotation marks into “smart quotes”, which are invalid characters to the validator.
  • Use of the font tag.  Remember that the font tag is an inline element.  The validator doesn’t like to see an inline element wrapped around block-level elements (such as heading, p, ul tags).  So if you want to change the font for everything within an ordered list, for example, put a <font> ... </font> pair inside each <li> ... </li> pair.  Yeah, it’s a nuisance, which is why they developed Cascading Style Sheets as a better alternative.

Remember that we talked about the general process of validation at our third class session.  You might want to review my slides at www.nvcc.edu/home/tgutnick/itd110/slides/03c-Validation.pdf and your own notes.  You did take notes while I talked, didn’t you?

Happy validating.

Creating tables with colored borders

Yesterday, a student asked me about problems validating a web page that included the bordercolor attribute in a table tag. As the textbook notes (page 89), this attribute was never part of the official HTML standard, so it’s not even deprecated. If you want your code to validate, you’ll have to leave it out. But as an alternative, you can sneak in some formatting using Cascading Style Sheets (which we’ll be covering later in the semester). You can do this something like this:

<table style="border-width: 1px; border-color: #999999" ... >

Creating tables in XHTML

During the 13 September class, we looked at some of the capabilities of XHTML tables.  The basics are pretty simple:  a table contains rows (<tr>), and row contain cells (<td>).  The cells contain content — usually text (paragraphs, lists, etc.) or images.  Where things start getting complex is with tables that have cells that span multiple rows or columns, or with nested tables.

I’ve posted some code samples on the class web site at the slides page. A few samples are very simple demonstrations of row and column spanning; you might want to play with these to experiment with different combinations.  I’ve also posted a solution to the “Nova Gazette” problem we worked on.
Remember that this was a complex layout, designed to look like a newspaper. This file contains two possible extreme solutions: one done completely without nested tables, relying strictly on row and column spanning; and the other one done with multiple nested tables but no spanning. Which is best? Probably something in between.