Archive for the ‘Web Dev’ Category

Apr 10

Authentic Jobs is the brainchild of renown standardista designer Cameron Moll. It’s a job/personnel connection site, much in the ilk of the 37signals Job Board, but way prettier. Authentic Jobs are screened through the brain of Mr. Moll himself.

The testimonials page would bring grown developers to blush; Authentic Jobs proves insanely effective at filling niche jobs with qualified personnel.

And yes, microformats present.

Post a Job, Find One

Apr 08

RegexWidget, how I love thee. We all know (or should) that regular expressions save the day, but how frequently do we implement them in our string manipulation? RegexWidget will ease your transition, allowing you to test your regular expressions straight from your Dashboard.

No direct link, so scroll down a bit on the widgets page until you reach the download. Clicking download button transfers you to PayPal page, but this is only to encourage donations; RegexWidget is available through LGPL license and is free.

Aug 27

Notes to follow.
Monday session:

  • Eric Meyer: Secrets of the CSS Jedi
  • Jeffrey Zeldman: Writing the User Interface
  • Jason Santa Maria: Design Your Way Out of a Paper Bag
  • Lou Rosenfeld: Search Analytics for Fun and Profit
  • Liz Danzico: The Seven Lies of Information Architecture
  • Dan Cedarholm: Interface Design Juggling
Jul 16

Earlier this week NeatlySliced.com was transferred to a new host. Before the DNS switched, I wanted to test the new site. The new host uses virtual hosting, which means that I have to change the hidden /etc/hosts OS X file to assign the IP to blog.neatlysliced.com.

Okay, so going to Go > Go To Folder from the finder to access the hidden /etc folder can get pretty redundant. Fortunately, there is a widget that allows editing of your /etc/hosts file with quite a number fewer keystrokes. It does require usage of your admin password, but you can easily delete the password after performing your business.

Download HostsWidget. It is freeware.

Jun 22

I’m always eager for debug tools in different browsers so that I can troubleshoot browser-unique rendering CSS and JavaScript issues.

I am yet to uncover a decent Safari Web Dev toolbar. A simple option, however, is the Debug menu. The Debug menu features User Agent spoofing, JavaScript console (not quite as good as Firefox’s), and a view of the DOM tree, among other things.

To enable the Debug menu, first launch OS X’s Terminal. Then type the following:
defaults write com.apple.Safari IncludeDebugMenu 1

To disable the Debug menu, simply replace the 1 with a zero:
defaults write com.apple.Safari IncludeDebugMenu 0

Relaunch Safari and view your new Debug menu, next to the Help menu. Read a short bit of the JavaScript Console at Apple’s Safari Dev page.

Have you found useful Safari development tools? Leave a comment and let me know.

Jun 12

I installed Safari 3 Beta on my work Windows machine to test some sites. It was running fairly well, but one site that I hit crashed every time I hit a menu option. I did some googling, and the error code I received matched that of an application hitting a bad batch of memory. In other words, this is due to a memory corruption error; Aviv Raff lamented the same issue. In addition to the memory problem, MacRumors.com reports additional security breaches.

In any vein, I’m definitely holding off on installing Safari 3 Beta on my MacBook until a more stable release. Not only do I wish to avoid the problems, but the Beta overwrites Safari 2, much to an over-eager web developer’s chagrin.

Only install Safari 3 Beta if you are using Windows and if you need to quickly see how a page is rendered in Safari. Otherwise, hold your horses.

Jun 09

XML is the bread and butter of the so-called Web 2.0 development movement. While writing a web service to export some data to an XML file, through a few trials I learned some best practices with XML naming conventions.

Basic Naming Rules

These are nothing new for most programming languages, but sometimes slight variances apply (e.g., is punctuation allowed for the first character, as an underscore?). The rules according to the W3C schools guidelines:

  • Names can contain letters, numbers, and other characters
  • Names must not start with a number or punctuation character
  • Names must not start with the letters xml (or XML, or Xml, etc)
  • Names cannot contain spaces

Thus, "_" and "-" are acceptable characters.

Allowed Characters - Best Practices

The "-" character may be allowed, but it may lead to problems later with server-side code trying to subtract your XML element values. I used "-" in my CSS, since it is of no consequence in that language, and spread the habit to XML believing the same to be true. Use the underscore (_) and save yourself a headache.

In like manner, strive for all lower-case characters. XML is case-sensitive, just like CSS. Using camel-case will only lead to heartache when you typo that one character and your whole world explodes into hate.

Element Name Consistency

Ensure you have a solid schema. Often times to display your stored XML data, you will use an XSLT. XSLTs will often work by cycling through elements of a consistent naming convention and outputting your values depending on logic or required HTML.

Just last week I absentmindedly generated an XML file with a minor schema failing. The resulting XML, with that failing exaggerated, could have resembled the following:

XML:
  1. <catalog>
  2.    <rock>
  3.       <radiohead>
  4.          <album>O.K. Computer</album>
  5.       </radiohead>
  6.    </rock>
  7.    <folk>
  8.       <matt-costa>
  9.          <album>Songs We Sing</album>
  10.       </matt-costa>
  11.    </folk>
  12. </catalog>

This would be impossible to transform with an XSLT, as "rock" and "folk", in the structure of the XML, have no correlation. In a similar vein, the artist inside the genre could be anything - there is no way to know that "radiohead" and "matt-costa" are both artists.

Follow a schema with generic, semantic names, and either use elemental content or attributes to display your pertinent values. A refined XML file follows:

XML:
  1. <catalog>
  2.    <genre id="rock">
  3.       <artist>
  4.          <name>Radiohead</name>
  5.          <album>O.K. Computer</album>
  6.       </artist>
  7.    </genre>
  8.    <genre id="folk">
  9.       <artist>
  10.          <name>Matt Costa</name>
  11.          <album>Songs We Sing</album>
  12.       </artist>
  13.    </genre>
  14. </catalog>

Ah, how much easier this is to transform with an XSLT. Rather than analyzing element depth - which is vicious as it is inconsistent with larger XML files - one could process based on each genre, each artist, et cetera.

Get a naming convention down before you start processing your data; sometimes one of the tougher parts of programming is coming up with appropriate names. Be universal, be sustainable.