I've been casting about online for some kind of portable training device, something that can keep track of my time on the road while I train for a particular race later this year. There are quite a few options for watches, each with options of their own.

One of the more fascinating watch brands out there is Suunto. There are a couple of other makes that have similar capabilities, but Suunto looks to have expanded on an interesting idea of connecting wirelessly to peripherals like a chest-worn heart-rate monitor, a bike cadence monitor, and even a GPS. The watch acts as a central processor for the peripherals, receiving, recording, and presenting a subset of the information, and then relaying it (via USB tether) to a computer for more intense processing and output.

While all of that is interesting, I think there is a surprising lack of movement in a particular direction that would make watch computing much more interesting.

Ok, so here's the idea I've been tossing around in my head. Imagine that there's some wireless protocol that allows a device to broadcast the control that it offers, and can receive control instructions. Let's call it, say, bluetooth. Suppose that your TV, your DVD player, you MP3 player, your phone... Suppose that all of these devices are broadcasting short-range signals that allow them to be controlled by some controlling device.

And try this: Suppose that there are some other sensors in the environment. Just as an example, suppose that there is a digital thermometer outside your kitchen window, and it too broadcasts data. Instead of broadcasting control data, it simply broadcasts informational data about temperature, humidity, wind speed, etc.

Ok, so maybe you're not happy with just the current weather info outside your window. Your computer can broadcast weather information - possibly any information it wants - from the internet. You could configure your PC to grab any information you like and broadcast it... But to where?

Your watch.

So here were some fun parts I've been thinking about. Your watch receives the signals, and provides UI for any of the controls that the device makes available. Because of the nature of the protocol, the watch maker can provide whatever interface controls it wants. You'll be able to consume those controls not just with your watch, but with whatever device can understand the protocol. So there could even be a variety of watches that provide different interfaces to the same sensor information.

When consuming data, the watch could also vary in the amount of computing power that it provides. For example, a low-power, low-cost device could simply display the temperature data it receives. A higher-power device could store historical data and plot it over time, correlating it with regional historical data retrieved from the computer. Keep in mind that even a low-powered device could be in command of higher-power processors via a wireless command and control link.

Storage is an interesting thought, too. Obviously, you don't want to have to rely on a persistent connection to the internet. So when you're within range of your PC, it transmits a packet of information that the watch can store and use when it is not in range. When you move out of range, it makes use of what data it has in storage.

Moreover, and perhaps more cool, is that as you move through the landscape of free and open sensors, you can choose to consume them as you see fit. So if you're on the beach, and the transmitters on the boardwalk are broadcasting tide info, you'll know when to go surfing or build your sandcastles. Other watches might also provide a broadcast signal to other watches that could use this proximity information for presence or even a loose grid network.

There are a few issues. One is the size of the interface. I think that a touchscreen is probably pretty efficient, but not with the finite control to select specific points in the UI. If you look at the Tissot T-Touch, they've got an interface where you can touch the screen around the edge of the bezel in about 6 places to indicate the function you want. I think that's a little draconian in comparison to our modern multi-touch controls on MP3 players and phones, but consider a control interface that typically isolates "click" control to a finite number of discrete areas and also allows you to "swipe" across the face of the watch to flip through interface pages or confirm menu options. Applying an interface like the Zune's "twist" interface could provide a reasonably intuitive way to select options and browse through any available data.

Another issue is battery power. I'm reluctant to have to plug the watch in to recharge every night. Plugging in some necessarily tiny and usually sealed connector seems like a pain, especially considering that my current watch is solar-powered and doesn't ever need a battery change. Some kind of inductive charging/docking station would be neat. Set the watch in the station to both charge and dock it to the PC for data exchange. Pretty slick, I think.

Ultimately, I'd like ubiquity of my data. I want to use my watch - my same, every day watch - to keep track of training data, then check out the TV schedule while sitting on my couch, then set my house alarm when I go to bed, then review my flight itinerary while on vacation, then see the caller ID info from my ringing cell phone and maybe even answer it... Etc.

I think there's a mental roadblock with how processing power should be distributed. People seem to think that their phones are capable of all of this. Phones are great. I rarely leave the house without my phone. Nonetheless, my phone is just a small part of the overall picture, and I'd still like to have some device that is a window - even if it's a small one - into my processing power and data strapped to my body, always available.

Even if the eventual window has to be my cell phone, which I think is a very myopic view, it should still have the same abilities that I've described for this watch. Also, it shouldn't be limited to just the phone. You should be able to do this with any device, and all devices that are capable should also be able to commandeer processing power from any device that offers it. If you've got 4 PCs in your home enabled for it, your watch should be able to pool their processing power to perform any task asked.

I think it's a good idea, and the technology should exist to produce it.

Photo by: http://www.flickr.com/photos/jmrosenfeld/ / CC BY 2.0

We had a discussion at work the other day, and again on IRC recently, about what to name our computers. At first this might sound like a silly thing, especially to people who use a single home computer, but for people with more than one at home or who use computers every day at work, it's something that you probably end up thinking about at some point.

All of my computers at home are named after "characters" in books. This computer is Defiant, named after a spaceship in Bill Baldwin's Galactic Convoy novel. My file server is Naruto after the manga character, and my notebook is named Runcible, after a much higher-tech device that is the center of the Neal Stephenson novel The Diamond Age.

I tend to be pragmatic about my server naming because there are just too darn many of them to remember, but many people and organizations give them more fanciful names. For example, A Small Orange uses characters from the show Lost to name their servers, as I noticed when editing some of my content on Hurley.

I've heard of some (extremely geeky) people using Star Trek ship classes and Star Wars planet names as computer names. One of the criteria, I suppose, for choosing a set of names is that you have enough for your entire network, because you don't want Moe, Larry, Curly, and Fred. The Seven Dwarfs might work well if you only have seven machines, but certainly doesn't work for twelve.

I wonder if anyone has any more imaginative name sets for their computers. Even if it's just one, you know you have to name it.

Every so often, you want to see how some code will look on your server before you actually deploy it there. Without setting up an identical server at identical cost elsewhere, you might consider testing locally on your desktop computer.

This setup describes what I've found to be useful, which is a system that allows you to host multiple sites on your local system, all resolving to different domain names, and configurable by adding a simple single line to a file and creating the directory to host the site. You don't even need to restart Apache to configure a whole new virtual host with this method.

The steps to do this are pretty simple, and all of the software is freely available. I recommend PSPad as a free text editor, which has a cool feature to let me mark these files as "favorites" to open them quickly without having to browse for them. You could also use Notepad, if you enjoy your own pain.

Download and install xampp
Xampp is a package that installs Apache, MySQL, and PHP on your Windows system. I usually install the Lite version, because it has exactly what I want, and is very easily cleaned up (no registry entries added). Follow the instructions in the distribution to get it working correctly. You should be able to connect in your browser to http://localhost when you're done and actually see the xampp installation. If you've gotten that far (and getting you there is the content of the xampp install instructions, not this tutorial), then you can proceed.

Create a vhost directory
You don't need to do this step to have a working testing server. Technically, after you install xampp, you're done. I like setting up local vhosts because it lets me host multiple projects very easily all on my local system, and when the configuration is done, it's stupid-easy to use and really handy.

If you want to, you can use the existing htdocs directory inside the xampp install to be the vhost directory. What we're going to do is create a separate directory inside that directory for each site/project that we want to host locally.

As long as you know the directory you want to use to hold all of the subdirectories, we'll move on...

Add mod_vhost_alias to the Apache config
mod_vhost_alias lets us dynamically host virtual hosts without having to change the httpd.conf every time. We'll configure Apache to look in the directory above for a directory that matches the name of the requested host. So if you try to load "www.mysite.com", then Apache will look in htdocs/www.mysite.com for the files to serve for that site.

To configure this, first load up your http.conf in a text editor. You can find this file in xampp at {xamppdir}/apache/conf/httpd.conf

Make sure that the mod_vhost_alias module is loaded. Look for this line:
LoadModule vhost_alias_module modules/mod_vhost_alias.so

It should not have a hash (#) in front of it. Save the change if necessary.

Also, look for this line in your httpd.conf:
Include conf/extra/httpd-vhosts.conf

This should also be enabled, as we will be editing and using that file.

Load your httpd-vhost.conf file. You can find this file in xampp at {xamppdir}/apache/conf/extra/httpd-vhost.conf

You can leave commented out every line in this file, which is the default. Somewhere in that file, add these lines:
NameVirtualHost *:80 UseCanonicalName Off VirtualDocumentRoot "path_here/%0"

Replace path_here with the path that you've chosen in the prior step. Be sure that there is a slash between the path and the %0 so that Apache doesn't get confused.

If you're not going to use the htdocs directory that is the default location, then you'll need to make sure that you have a <Directory> directive that allows Apache to access the files at that location, since xampp wisely denies access to everywhere by default. Such a directive looks like this:

<Directory "path_here"> Options Indexes FollowSymLinks Includes ExecCGI AllowOverride All Order allow,deny Allow from all </Directory>

Save your changes to that file, and restart Apache.

Create your vhost directory and HOSTS info

This is the cool part. First, imagine what you want your project name to be. Say it's "foo". In the htdocs directory (or wherever you have configured Apache to point), create a directory named "foo".

Now, open your HOSTS file in a text editor. Your HOSTS file is usually located at C:\windows\system32\drivers\etc\hosts

If you haven't edited that file or used some crazy anti-adware software that edits this file, it should be pretty plain. What you want to do is add a new line to the end of the file, like this:

127.0.0.1 foo

This tells windows that when you request the domain "foo", it should return the IP address 127.0.0.1. 127.0.0.1 is your computer. So when you request the URL "http://foo" Windows should send your request to your locally installed Apache server. And since Apache is now configured to serve requests for virtual hosts out of directories that have the same name as those virtual hosts, you should be all set to create as many new virtual hosts as you want on your own Windows PC and access them indiscriminately.

Whenever you want to add a new "site" to your system, add a directory to the htdocs directory using the name of the domain you want to use, then add that domain to your HOSTS file with the 127.0.0.1 IP address. You should not even need to restart Apache, it should just start resolving the domain to your local Apache instance, and Apache will find the appropriate directory to serve files from.

If you change the HOSTS file often within a single coding session, your PC might get a little hung up by caching this value. You can usually free up the DNS cache by running this on the command line:

ipconfig /flushdns

If you temporarily want to use your own desktop server as a staging site for your remote server, you can temporarily add the domain of your remote server to your HOSTS file with the 127.0.0.1 address.

With the HOSTS file, you could even point some domain at a different IP address than what it normally resolves to, which is really helpful when you're moving your site to a different host. I currently have this setting set for Asymptomatic, since I'm in the midst of transferring the site to a new server. Note how easily I can switch between them and still use the same domain on both, even though one IP is not yet public.

Every system I know of (windows, linux, mac) all have a HOSTS file, it's just a matter of finding it and tweaking it to make it do what you need.

And that's the process. Enjoy!

Where is it?

One of our clients for work has been on the hunt for an issue tracker to keep track of issues for our web development project and for their internal systems. We looked through a few options and eventually settled on FogBugz. I do not like FogBugz because it's another one of those programs subscribing to that crazy Creating Passionate Users philosophy that says it's great to have people that hate your product. Particularly because I am one of them.

The idea is that they've created the software to have a specific process flow. You either subscribe to their process wholly, or you fit your round process into their square hole. We're in the process of rounding the corners off of our peg just so that the licenses we've paid for aren't a waste. Am I wrong to think that there should be a solution that allows you to apply your standard operating procedure without having to codify it specifically in the software?

What I mean is, if we had a process, we should be able to get the software to conform to it. We shouldn't have to make the software perform every step of the process and enforce it for us. Personally, I would have been happy with a place to list issues and have their histories. Perhaps a way to "tag" and classify them and mark them as open, fixed, or resolved would be enough for me. Maybe I'd want more, but I wouldn't have to fight with some crazy assignment process like within FogBugz, I could just implement a new operating procedure and the software wouldn't need to change.

So I've been looking for an open source solution. We're going to need to recommend some kind of issue management system to other clients, and we may want to switch out this client eventually for something that works better (although by the time we get there, we'll have "figured out" FogBugz and our project will be complete).

What really bothers me about the issue tracking arena is that there are really no good open-source contenders that I can find.

The best of the pack, I think, is Bug Genie. Bug Genie has a nice and friendly interface, and has a ton of features. Maybe an overkill of features. The process is nice, but in this Web 2.0 era, not having Ajax processing (and FogBugz fails here, too) leaves you wanting. Bug Genie also seems more focused on desktop application development, with specific pages to detail your system capabilities. I would really prefer something more web project-oriented.

The disturbing part is that there seem to be a bunch of packages out there to do the job, but they're all commercial, hosted products. Take 16bugs for example. I didn't sign up for their trial, because I'm not interested at all in a paid/hosted solution, but the software looks like the simple kind of thing that we'd want. It tracks issues. I keeps a history. It lets you mark things as completed. What other features are really neccesary? But it's commercial and hosted, so it's automatically off the list. Oh, well.

Basecamp seems like a good fit, if looking for a commercial product. Looking for project management software is something that I had been doing a lot of in the past. Actually, on that front, Basecamp can be almost entirely replaced by ActiveCollab.

ActiveCollab isn't exactly complete, but it provides simple task lists and project management that might get you through. As it develops, I'm sure it'll provide more of the features of Basecamp. Still, these project management packages aren't issue trackers. They don't function well as issue trackers. So they don't work, either.

Mantis may be effective, but I've got to have non-coders using this thing. The interface has to be dirt simple.

What would be truly awesome is a cradle-to-grave project management system. It would let you specify requirements (I would love a subset of the function of Borland Caliber in a web product.), track project development milestones and revisions (integrating into subversion), track issues from clients and QA, automate deployment, and manage maintenance requests. The system should integrate fully with email (allowing/forcing all email traffic for a project to funnel through the system and be tracked), and provide RSS feeds for updates so that email doesn't get clogged with automated notices. (Damn you, FogBugz!) It would also be nice if there was a desktop component, one of the features I do like about FogBugz, that allows you to take screenshots and submit them directly as new cases. The tool should also be able to consume the tracker's RSS feeds and give you notices. Rather than function as a standard feed reader, it could consume Atom (for example) with extra data specific to issue tracking, and let you filter it a bit on the client side, or respond directly to the system. Yeah, that would be nice.

For now, though, I would settle for a really simple system like 16bugs that was not hosted or encrypted (like Olate's Arctic, which isn't bad but still not quite the solution).

Know of anything good?

Over the years I've had many occasions to work with different graphic designers in producing various types of output related to the computer. Of course, I've helped produce web pages, but also printed documentation and marketing materials all related to software releases.

Some designers have been better to work with than others, as you would expect in any field. There are many common threads that I've noticed between these designers of, shall we say, "things they could do that would make things go much more smoothly than doing what they're used to" in regard to getting software projects done.

Allow me to list a few ways that a graphic designer could improve relations with his coders.

Understand Graphic File Formats

This seems like a stupid thing to say - that a graphic designer wouldn't understand graphic file formats. Experience has nonetheless shown me that a large percentage of graphic designers couldn't explain the relative merits of graphic formats.

There are reasons why web developers (and in this case I'm using "developer" for "coder") use GIFs in some places and JPEGs in others. There is a reason to use a PNG file, and there are flaws in its rendering that you need to understand.

For example, GIF files can have transparent areas, but they are binary - either it is completely transparent, or it is completely opaque. GIF files have a color limitation of 256 colors, so they are not as good for photographs as JPEGs. Unlike GIF, JPEG is a lossy format, meaning that the computer will fudge the look of the graphic trying to get the file size smaller. As a result, JPEGs are not good when precise, clear lines are needed. PNG files are nice because they can be lossless (the opposite of lossy) and can support alpha transparency (different levels of transparency), but their browser support is spotty, and IE requires special hacks to make their transparency features work.

If you are a graphic designer working with a coder to bring about a web site, for example, not knowing these things makes you look like a loser.

Photoshop is not a valid file format

Maybe it's personal preference, but the more I think about it, the more I'm becoming firm on this issue.

Given all of the cool toys your coder could have in his arsenal, why on earth would he waste $800 or more on graphic software? No, your coder probably does not have a copy of Photoshop "laying around" like you do. If he does, it's probably because he's had to deal with graphic designers in the past who insisted on providing PSD files as their preferred output format.

There are many reasons PSD isn't the end-all of graphics formats. For one, there are many different versions of PSD files. If you save in CS2, will it open in a prior version? Another thing, they're huge. There's no reason to send a 2GB PSD file when a 30k PNG does the job better.

"Oh, but it has layers," you say. Layers are the devil. Layers don't save your coder time, they save you time and let you get sloppy in your page construction. Slicing images out of a layered document is complicated. If you have created some design that has two separate web pages on separate layers (why???) then the slice areas need to be configured very oddly to get the specific slices out of the document as needed for the layout. If you were the one who had to do it, you'd understand. So just trust me - it's a pain.

Plus, we coders don't spend our whole day using Photoshop. It's weird to me that we'd gain the level of proficiency that we have just because designers keep delivering their designs in that format. It takes us much longer in relative terms to do anything than you do - why don't you just give us the graphics we need in the sizes and formats we're going to use?

And no, you open-source Inkscape users aren't any better for delivering SVG files. There's still no clean way to get the images out of that format. It's almost worse since it's yet another tool that your coder will have to learn, one that's not even as stable as the Adobe format.

Your canvas is bigger than that

This one always makes me laugh before I break down in tears.

A designer creates a new web page design in his program of choice. Ok, call it Photoshop. (Which, while I'm rallying against it, isn't actually a page layout program at all - it's photo retouch software that you're repurposing for something else, see: Photoshop) You have to tell Photoshop the size of your file, so you give it a pretty standard 800×600 or 1024×768. Photoshop draws a nice little box for you to doodle in - and there lies your downfall.

The web may have certain soft, practical limits for width, but it does not have those limits on height. You may be thinking of keeping things "above the fold" (ah, amusing newspaper sayings), and while that applies to your design, it shouldn't restrict you from putting certain things below the fold. Yes, it'll be ok. Those things will still be on the page, just not, you know, at the top.

The worst offense here is cramming a full-page design into 600 vertical pixels just because you've set that arbitrary limit. Site visitors will not die if they have to scroll a little.

Use bigger fonts

While you've got that 800×600 layout open, let me hit you with another nice little factoid: Your fonts are too small. Maybe you're trying to fit too much into the space allotted to you by Photoshop, but for some reason you've chosen fonts that are maybe 6 pixels tall.

I've spent significant brain power trying to deduce what causes this phenomenon. Why do designers think that their pretty 6-pixel-high fonts will ever translate to the web? They don't! Actually, Firefox and Internet Explorer do different things when you try to make your fonts that small. Firefox refuses. IE displays them as small as you like. It's not a good thing.

Still, while your fonts might look great at that size in Photoshop, that's because they're antialiased. That's a complicated term meaning that the fonts are not just black pixels where the text is and white pixels where the text is not, but shades of blended gray (and even other colors!) that help the font look smooth at those small sizes. That's great in Photoshop where you can control the graphic integrity of the image, but not when your coder is going to turn all of your text (why did you type it all into the mockup?) into, uh, text.

Causing particular dismay is when the design insists that text lines up with graphic elements on the page, since it is very difficult to have a consistent font size on different browsers on different operating systems. Insisting that the text is in pixel-perfect alignment with your graphics is outright insanity.

Use smaller fonts

It's in direct opposition to the prior entry, I know, but designers are a varied bunch. With the last entry, you're probably dealing with a designer who designs on the side, without much practical experience (the brother of the guy whose web site you're building) working on an office or home computer. With this entry, you've got a "seasoned" designer who just doesn't get it. Why do I say this? Because they've invested in a 30-inch Cinema Display, they have the resolution cranked all the way up, and they don't have the slightest idea what the word "resolution" means.

If you've got a monitor that displays 300 pixels in an inch, fonts that look average-sized to everyone else are going to look really small on your screen. Don't compensate by making the font five times bigger than it needs to be. Yikes.

You would be surprised at how many self-labeled "designers" will drop $3k on a screen to get some designer cred but don't have the slightest idea of what they've gotten themselves into.

Use common fonts

Yes, there are more fonts on the web these days than just the three bland ones that everyone uses. But there is a reason why everyone uses those bland fonts - they work.

When you submit your graphic to your coder and he slices up your image and creates a nice layout, and the client asks, "Can you have this text over here (in HTML, not graphic) look like that text over there (in a weird graphic font)?" what do you think that does to the coder? Yes, it takes years off. Or at least, greys the hair a little.

Worse yet, you provide the Photoshop file with the strange font in it, but then don't provide the font for when a change needs to be made. I know, I know, they should come back to you for design changes. But here is our (coder and client) experience with that:

Designers, perhaps due to their artistic nature, are often flaky. And so getting one of them to respond after the design is "complete" is often a difficult task.

Coders have to work with the client directly in a give and take relationship to get the functionality working. And while it's possible for designers to do the same, the conversations are much different. For example, if the client sees a design he doesn't like, the question is, "Can this be more blue?" or at worst, "Make this more blue." And then the designer is free to interpret what "more blue" means.

For a coder, the questions are never questions. It's always "this is wrong". As a result, the client feels he has more sway over the coder than the designer, because he can concretely say, "This is wrong and it's clear that it should be fixed in this way." It's just the way the universe is constructed, and that's fine. But what happens as a result is the client will often insist that a design change be done, and the only one they can "boss around" is the coder, because the designer is aloof or the coder is actually responsive to that kind of feedback. So we're left holding the bag after the designer has long gone off and spent their 3× fee for 1/4 the time on that trip to Tahiti.

No, I'm not bitter. Ok, I am, but that's the subject of a separate post.

Coordinate your drop box

There are a few project management packages out there these days that'll get the job done, perhaps not as well as they could, but done nonetheless. Use one. Coordinate with your coder to see what they use.

Insisting on FTP'ing your files to some server is a pain. Emailing several multi-megabyte files is worse. Personally, I don't keep a real FTP client installed on my desktop system. I try to be SFTP-only here so that all access to client sites is done securely. If I've got to hand out FTP access to designers because they can't switch to SFTP or use the project tracking software, that's a pain.

Those are the big items, I think. I could probably go on about this topic for hours. It makes me crazy. Hopefully there is some enlightenment here.