This morning an article came across my feed that crystallized to me how wrong-headed the tech blogosphere is about the stylus. In this Read-write-web article, the author argues that the iPad isn't a proper drawing surface. I am in complete agreement with this point. A touchable interface is the cornerstone of the Tablet experience. Unfortunately, the Tablet fails when it comes to the production of artistic works. The author argues that the fault is the lack of physical feedback of the touchscreen. Instead, the software uses other kinds of feedback such as sound, graphics, or vibration. 

Which doesn't make any sense.

Most artists, particularly those that create 2D work such as drawings or illustrations, start with physical media. It's cheap, versatile, and yes, it's physical feedback is simply unmatched. Many webcomic artists start with physical media, and scan in their drawings to publish their stories. While this works, it has a number of drawbacks in the digitial world. Scans can be blurry or messy. Cleanup can take a large amount of time, and scanners can be fussy, broken, or unavailable. 

Enter the Wacom graphics tablet. I bought my Graphire 2 while I was in college early in the millennium. The $99 USB device still works and is still in service today. What's interesting about this bare-bones device is what it lacks. It has no display. No vibration. It doesn't even have buttons! Yet, I and many other artists can produce and continue to produce wonder pieces of art thanks to it and it's descendants. You'd think that the iPad and other tablets would be the ultimate "artist's digital sketchbook". 

But tablets suck at artwork. They are flatly unacceptable. The problem isn't haptics, or display resolution, or any of that nonsense. It all comes down to one simple thing:

Precision. 

Tablet touchscreens lack precision due to the nature of the technology. If you've ever held up a touchscreen and reflected light off of it at just the right angle, you'll notice a grid of "dots" cover the screen. Each dot is a tiny capacitor that can register a scale of contact. Clever (and highly patentable) mathematics are used to "guess" where you actually tapped on the screen. The problem is that capacitive touchscreens aren't manufactured to have the resolution required by artists. They are simply too expensive for the average consumer. 

Compare this with the technology behind a Wacom tablet. This device uses not capacitors, but a magnetic field using wires (circuit tracings) and a coil inside the stylus. The nature of this technology allows much greater densities of tap registration. With a little clever circuity in the stylus, pressure sensitivity can be measured with a minimum of additional components. This formula has worked well for Wacom, and digital artists for years and years. While it takes effort to get used to the lack of physical feedback provided by traditional media, a skilled artist can overcome that problem within hours. The result is clean digital lines without any scanning artifacts. 

But it has one critical problem. You need a stylus. 

The inductive system Wacom uses does not work with fingers. You can touch a Wacom tablet (with the exception of the Bamboo line) all day and not get a single click. Capacitive touchscreens take advantage of the conductive nature of fingers, and use that as a means to register taps. This is also why sausages work with touchscreens. In a mobile device world, this can be an advantage as only conductive objects register as taps, and it's unlikely you'll be carrying pieces of metal or meat in your book bag or pocket. Styli that work with touchscreens actually have a piece of rubber or plastic with a conductive coating. That's why they work. You can actually create a touchscreen stylus yourself with an old pen and some conductive foam commonly used to transport integrated circuits. 

The stylus has gained a bad reputation since the iPhone became the darling of the tech blogger world. This reputation is entirely undeserved, as the fault isn't the stylus, but the screens used at the time. In addition to Capacitive and Inductive, there's an older touchscreen tech -- resistive. The Palm series of PDAs heavily relied on resistive touchscreens. The physical configuration is similar to capacitive touchscreens, but relies on a different electronic property. When Palm was king, resistive screens were readily available and inexpensive. With a simple pointing device and again, clever mathematics, a tap could be registered and narrowed to a small region.

The problem is that resistive screens registered any and all physical taps. Furthermore, they had to be built using flexible material that deflected on contact. Capacitive touchscreens do not need physical deflection. As the size of the screens were often small in this age of mobile devices, a stylus was required to register taps accurately. Fingers were simply too mooshy. When Apple came along with the right combination of existing technologies, the stylus became the whipping child of an earlier era of technology.

The stylus is not the enemy. Bad touchscreen tech is. 

As of late, the Internet seems to be reconsidering the stylus. Thinkgeek popularized the idea of a capacitive touchscreen stylus to avoid the greasiness inherent to a finger controlled interface. Wacom has recently began producing a "premium" capacitive stylus under it's Bamboo brand. Yet, there hasn't been one article that doesn't repeat the words of Steve Jobs: "If you see a stylus, you blew it." The author of the article expands on this point:

Apple's second mobile operating system nearly eliminated the friction between the software and the physical human interacting with it. It felt like touching and manipulating the actual pixels. A stylus would just be an inert barrier in between.

And that is completely wrong when it comes to artwork.

For centuries, if not millennia, artists have used sticks of charcoal, quills, brushes, pens, and pencils in order to produce drawings and illustrations. These devices are long, usually cylindrical, and are often controlled by pinching them between the pointer finger and the thumb. Sound familiar? The stylus inherits this form factor. In addition to sheer familiarity, this form factor has been sucessful for one reason:

The stylus is not an inert element. It is an active, mechanical element that acts as a movement reduction device.

Leonardo da Vinci did not use finger paints, he used a brush. The stylus, pen, brush, and so on translates the relatively large mechanical movements of the hand into smaller more precise movements necessary for the production of detailed artwork. This was, coincidentally, why the stylus was necessary on Palm and Windows Mobile devices. The screens were smaller as they were more expensive to produce. The stylus allowed more precise input on the smaller surface.

Today, this remains a problem even on the relatively larger size of the tablet computer. Using a finger to produce artwork is akin to using finger paints. It's messy, clumsy, and the results tend to be prized the most by the parents of diminutive artists. A stylus is required to make artwork more detailed as fingers are too large to do it accurately. The problem is that current capacitive styli replicate not pens, but fingers. The tips are large and squishy, making it seems like finger painting with a cleaner, straighter finger. Pen-precise styli could easily be created, but the touch resolution of the average touchscreen is not yet up to the task. There are too few capacitiors, and they are too far apart.

The problem is not the stylus, dear tech bloggers. The problem is the screen. 

Earlier this evening a friend sent out a request on Twitter:

@[redacted] needs a new laptop. Any recommendations? She needs win7 and not too expensive.

I found something that met the criteria and quickly sent off a reply. There wasn't much too the request. Desktop Computers (including laptops) haven't changed much for the last few years. Even the specs have for the most part stabilized: 2 to 4 cores, 1.5-2.1 GHz, 4 - 8GB of memory, Hard Drives up to 750GB... Getting a new computer is simply no longer exciting. 

Contrast this with mobile devices. Smartphones and tablets have come to such an amazing prominence that they now consist of the majority of Internet traffic today. Most people in the US consume content on websites, blogs, and social media on these devices from the sofa while watching television. I too, have succumbed to this madness last summer and bought one myself. Yet, they are rarely considered machines on which you "can get work done". Just try to develop a web site on an iPad.

And that's the shameful part of it: you should be able to develop a website on a tablet. Hell, you should be able to write and compile software on it. My HP TouchPad has more CPU and memory power than the computer I used in college to write my assignments and compile my C++ code. Spec-wise, there should be no reason why a tablet of today could not supplant a desktop-class machine. The problem is the industrial complex including both the hardware manufacturers and the OS developers.

Apple championed the ideal of "owning the entire stack". They build the hardware, they code the software. This allowed Apple to integrate the two with spectacular refinement since the late Steve Job's return. There's also the opposing edge to that sword: You are at their mercy. If they decide to no longer support your model -- as Apple has with their recently announced Mountain Lion -- you're out of luck. Fork over another $1500 and you'll be reinstated into grace.

It's with distaste that other manufacturers have taken up the same methods, hoping to swell their coffers in the same manner as Cupertino. Since the original Droid, we've been fighting locked bootloaders on Android phones and tablets. The strategy hasn't worked. Samsung, Motorola, HTC; you're not Apple. You don't have the same fanatics or the legacy of a charismatic figure promising us a skeuomorphic Rapture of the Hipsters. What you can do sounds simple, but requires more thought and much more risk.

HTC is a prime example of Doing It Wrong. They seemingly put out a new smartphone model every month. None of them are distinct, and the modifications to stock Android, HTC Sense, provides only a minimal visual flare at the cost of increased pace of obsolescence. More than once, a firmware update has been held up because Sense couldn't be shoehorned into a popular device. At least once, a device that had an announced upgrade was canceled because Sense wouldn't fit. The subsequent outcry called for a a Sense-less upgrade, but HTC's response was lukewarm.

Apple did have it right with part of their formula: The number of models should not exceed the fingers on one hand. The times those models are replaced with a newer version should not exceed once a year. Customers like it simple. Do it right; don't rush anything out the door and make sure it's solid.

This is why I've watched developments in Windows 8 with great interest. Microsoft is trying to create a tablet experience in which you Can Get Work Done. While the hybrid Metro/Aero environment is abominable, their aim really does seem well thought out, if unsettlingly different. For the first time, ARM will be supported as a major Windows platform. Furthermore, the experience is "touch first". Microsoft hopes the touchscreen will be standard computer equipment going forward.

What is possibly more interesting to me is what open source developers will do. With Microsoft pushing touch interfaces, the tablet form factor will become the de facto standard. The two most popular desktop environments are already gearing up for this change. GNOME3 is taking a radical unified approach, casting off old mouse-centric WIMP interfaces and aiming for a blend not unlike Windows 8. KDE is remixing their astonishingly flexible DE into Plasma Active. For the moment, it is difficult to find a touch device on which either of these open source stacks will run. I hope that with the release of Windows 8, this will change.

That is, if Microsoft doesn't screw it up.

They already are, sadly. As part of the Windows 8 operating system, Microsoft is pushing "secure boot". If this sounds like the return of the Android locked bootloader controversy, you're right. This time it's bigger and meaner. While x86 based tablets will have no requirement to use secure boot, any ARM based tablets will. Furthermore, Microsoft will deny manufacturers the right to apply the Certified for Windows 8 sticker if an ARM tablet allows the user to disable the secure boot feature. One may think the solution would be to stick with x86, but the venerable CISC architecture was never designed for low power operation -- something critical for a mobile device. ARM, on the other hand, is specifically geared to function in an embedded context.

There are several technical discussions elsewhere on the 'net highlighting why "secure boot" is little more than DRM in disguise. Microsoft intends to create a technical vendor lock, preventing the upstart Linuxes from whittling away their overwhelming marketshare. It's petty. It'd devious. And they probably can get away with it. Universe knows Apple has for years.

Is there no hope for those of us that wish to run on an open source stack? If the open source community has shown anything, it's determination. Despite smartphone manufacturers best efforts, bootloaders have been cracked and hardware wrested from their control.

A famous hacker once put it thus: If a thing can be decrypted, it can be stolen reclaimed.

Yesterday I had a wonderful contact of firsts. It was:

• My first contact outside the US
• My first contact with Canada
• My first contact on 20 meters
• My first contact on PSK31

Until later that day, my only radio is my beloved Yaesu FT-817ND. It's a low power rig that is intended for backpacking purposes, featuring a maximum output of 5 watts and an internal battery. It's an adorable little rig, but the total output wattage is tiny compared to typical Ham Radio rigs. 

Let's compare my FT-817 to my newest rig that arrived only hours later -- an Icom 707. This older rig was originally released in 1993, 11 years before the 817ND! Nevertheless, the power output for the 707 is common to many rigs manufactured today, 100 watts.Even with a modest antenna, you can go across the country easily on 100 watts. With luck and the Ionosphere on your side, you can go around the world! With only 5 watts, however, things become much more tricky. You need to consider your mode carefully.

A mode is the method of encoding information in a radio signal. The most basic one you're probably familiar with through movies, Morse Code. This method turns the transmitter (or more specifically, the power amplifier connected to the antenna) on and off. Like binary, it has two "digits", a short "dit" and a long "dah". By encoding each letter of the alphabet as a series of dits and dahs, you can exchange information. Since the signal is either fully on, or fully off, and the frequency is constant, Hams like calling this mode CW, or Continuous Wave. CW is the mode proper, while Morse is merely a method of encoding the information. 

Other modes you're already familiar with, AM and FM. These are voice modes. Explaining these requires a bit more imagination. Think of your voice as a sine wave. Radio waves can also be thought of as a sine wave. For your voice, the length between the peaks of wave is much, much bigger than the radio wave. So much so, you can superimpose your voice wave by varying the power output of the transmitter. This is how AM, or Amplitude Modulation works. FM, or Frequency Modulation works by varying the frequency of the radio signal proportionally with your voice sine wave. FM was created to avoid noise generated by the atmosphere, most of which causes spikes in amplitude. 

While voice modes are easily approachable, they are rarely used in QRP work. Voice modes have a hidden cost, Sidebands. The original, unmodulated radio signal produced by the transmitter still makes it to the antenna even when you're talking! This bit of the signal, the Carrier Wave, doesn't contain any information. Instead, by a quirk of combining waveforms, the signal spreads out below and above the carrier wave proportional to the spoken frequency. These are Sidebands. FM has huge sidebands, since it's frequency changes slightly. While AM's are smaller, the two sidebands are mirrors, containing the same vocal information. A more efficient modification of AM is called Single Side Band. This mode cuts out one of the sidebands and the carrier wave. This means that what is transmitted has much more punch and travels further than it would otherwise. This makes SSB a good mode for low power work.

The ultimate mode for QRP work is still CW. Since there is no superimposed audio wave, the sidebands are tiny. All the punch is put into a very narrow range of frequencies, meaning each watt carries the signal that much further. The problem is that CW is a dying art. It's no longer a required skill to get an Amateur Radio license. While this was done to lower the barrier to entry for prospective Hams, the ubiquity of computers has popularized Morse Code Decoders -- software that can listen to a CW signal and print out the text. Likewise, Morse Encoders allow you to use a keyboard to type letters, making the computer translate them into dits and dahs for you. 

The problem is, that feels like cheating to me. If you're going to do CW, you should break out a straight key, or an iambic paddle and cut out the silicon middleman. And while that is my plan, after I practice thoroughly, I'm still facing the problem of a poor antenna and a low power rig. Enter PSK31.

PSK31 stands for Phased Shift Keying, 31 Baud. In many ways, it's like Morse Code. It encodes letters in an equivalent of dits and dahs, but by shifting the phase of the signal. Going back to our imagined sine wave, if you're at a peak, PSK31 will suddenly shift to a valley, with no transition in between. By doing this rapidly, we can encode letters in a series of timed phase reversals. The nifty thing is that this is not done with the radio signal! Instead, PSK31 is encoded as an audio tone! Why do this? PSK31 was designed to be simple, and bare bones. Requiring new transmitters to be build just to support it would hamper adoption. Instead, PSK31 is produced (and received) by a computer, and sent to a standard SSB transceiver. Unlike transmitting a full human voice on SSB, PSK31 only results in a very narrow range of audio, this means the sidebands are very narrow. As narrow or more narrow than CW! This means all the power is packed into a tiny bit of frequency, making each watt count. 

Now here comes the really nifty part: PSK31 conversations are often all sent and received with the transceiver tuned to the same frequency. Multiple people, having multiple conversations, at the same time, on the same frequency. How? Recall that PSK31 is encoded as audio first. By telling the PSK31 software to produce audio at one tone or another, multiple people can occupy the same frequency. It's like a room full of people each with a whistle. Only two people in the room have the same kind of whistle that produces the same tone. Since they're only listening for the same tone they themselves are producing, they can ignore everyone else. 

Want to try it yourself? Really! No radio required! Download and install Digipan on your computer. If you're on Linux, it runs just fine in Wine! Now, plug in a microphone and start up the software. Go to Configure -> Sound Card and set things appropriately. Then put on this Youtube video while having the mic pointed at your computer speakers. Nifty!

In a typical Ham setup, however, a special interface is required to interconnect the computer in the transceiver in a safe way. Too much audio power from the receiver can damage your computer's sound card. Too much from the computer, can damage the transmitter. I recently purchased a SignaLink USB. The nice thing about this unit is it's only a USB sound card to the computer. It works in Linux just fine.

While I made my 560 mile contact fairly easily, there's a lot more I can do. My antenna was not properly tuned, resulting in poor efficiency. Not all of my 5 watts ended up "in the air". I think with some additional work and tuning, I can make it much, much further. 

Click here to read Part 1.

Click here to read Part 2.

When looking at Drupal code, it can be hard to know where to start. Dive into any of the directories in a standard installation, and you'll find file after file of PHP code. In the root directory alone, you'll find five files! Where do we start? Determining this is quite simpler than it seems; all you have to do is look at the URL of any Drupal site. 

http://example.com/node/1234

The above is a typical URL for a Drupal site. Most Drupal sites use a feature called "Clean URLs". This removes a lot of the nuts and bolts of the address that helps us understand it. Without Clean URLs enabled, the above address looks like this:

http://example.com/?q=node/1234

Okay, that's a little helpful, but it doesn't tell us what we want to know. What file amongst all the files in Drupal do we look at? It turns out that many websites will look for a default file in the site's root directory if one isn't specified in the URL. In the Web 1.0 days, this was "index.html", for modern PHP websites this is "index.php". 

Four Lines to Rule Them

When we open of index.php, one might expect a lot of code. Instead (aside from comments) you'll find four lines:

define('DRUPAL_ROOT', getcwd());

require_once DRUPAL_ROOT . '/includes/bootstrap.inc';

drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

menu_execute_active_handler();

The first two lines are very straightforward. The first line defines a constant, DRUPAL_ROOT, containing the file path to the Drupal installation. This constant is then used in the second line, to load bootstrap.inc in the includes/ subdirectory. Despite the file extension, bootstrap.inc contains PHP code. Drupal uses the *.inc extension to prevent files from being executed directly. This way, someone cannot plug in http://example.com/includes/bootstrap.inc and get back a valid page.

That leaves two more lines, and that's where all the fun starts. At this point we've only defined the DRUPAL_ROOT constant and imported an include file. We have yet to execute any real code. Any Drupal page request can be thought of as a two step process (if you're a core dev, insert your groans here): Initialize the Drupal environment, and then handle a page request. The third line of code, drupal_bootstrap() does the initialization -- it forges a connection to the database, loads modules, loads needed data into memory, and prepares everything for the final line of code in index.php.

The menu_execute_active_handler() function handles the page request. This is the part that takes the ?q= half of the URL and produces a web page for the visitor to see. This is actually a new function in Drupal 7. Drupal 6 preferred to bury the request handling within drupal_bootstrap(). Separating the two makes things much, much cleaner.

Making Invocation Easier

In the last article in this series, I mentioned that invoking the debugger was somewhat tricky. Eclipse assumes that any code you're debugging is in a project and not external files. It turns out that the PHP Development Toolkit actuall anticipates this problem and solves it rather easily. 

1. Create a new PHP project by using the File menu:
   File -> New -> PHP Project
2. In the provided field, enter a Name of your choice that is unique within your workspace.
3. Under the Contents box, select the Create Project at existing location (from existing source) radio button. 
4. Click the Browse button adjacent to the radio button. Select the root of your Drupal install. 
5. Click Finish.

This creates a new project in Eclipse importing all of Drupal's files. This mode of project creation does not create a copy of the files within the Eclipse workspace, but rather creates references to the actual files on the web server. Thus, any changes you make to the files in the Eclipse UI affect Drupal's actual files. This is great for our purpose of exploration, but can problematic. Remember, don't hack core! 

Once the project is created, invoking the debugger is easy, easy, easy. Double-click index.php in the project explorer, then start the debugger with Run -> Debug As -> PHP Web Page.

Booting Up Drupal

Once you've started a new debugging session, we can dig into drupal_bootstrap(). The function looks a little circuitous at first: An array of phases is initialized, and then a while loop begins, iterating through a seven step process in which key subsystems and dependents of those subsystems are initialized in the correct order. Here's how it boils down:

• DRUPAL_BOOTSTRAP_CONFIGURATION -- Do some basic setup and load settings.php.
• DRUPAL_BOOTSTRAP_PAGE_CACHE -- If page caching is enabled, and the request is asking for a cached page, return the page.
• DRUPAL_BOOTSTRAP_DATABASE -- Connect to the database.
• DRUPAL_BOOTSTRAP_VARIABLES -- Load variables and enabled modules required for bootstrap.
• DRUPAL_BOOTSTRAP_SESSION -- Load the user's session from the DB. If the request isn't from a logged in user, return an anonymous user.
• DRUPAL_BOOTSTRAP_PAGE_HEADER -- Invoke hook_boot(), send default HTTP headers.
• DRUPAL_BOOTSTRAP_LANGUAGE -- Initialize the language system for translations. 
• DRUPAL_BOOTSTRAP_FULL -- The phase name is better thought as "Last", rather than "full". Load all enabled modules. Invoke hook_init().

Why the added complexity? Why not just use a static series of functions? The initialization process can be very complicated. For example, you may be in the middle of one phase, like DRUPAL_BOOTSTRAP_PAGE_CACHE, and you'll need to load something from the database. The code that's initializing the page cache will invoke drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE). Furthermore, each phase is dependent on each preceding phase -- you cannot do the DRUPAL_BOOTSTRAP_VARIABLES phase without doing DRUPAL_BOOTSTRAP_DATABASE, DRUPAL_BOOTSTRAP_PAGE_CACHE, DRUPAL_BOOTSTRAP_CONFIGURATION. This is used by index.php itself when it calls drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL). Since DRUPAL_BOOTSTRAP_FULL is the last phase in the list, it is dependent on all previous phases. 

Each phase of the bootstrap process has a lot of code behind it. While I could write an article for each, there's so much more Drupal to cover. We haven't even served a page yet! That's what we'll do next when we cover menu_execute_active_handler().

Click here to read part 4.