I used to have two Twitter accounts. I used one under my name once for the last MacHeist, and the other for this site as part of the "land grab" and never used. I write "used to" because now I can't seem to login into either of them. To me, Twitter is nothing more than instant messaging remixed to be public-first rather than private first. I never use IM, and Twitter gets the same lack of attention from me as well, particularly because it is public. I had forgotten about them until yesterday.

Yesterday, I got a couple notifications that "Jessica (Jessica63311)" and "Elise Rebbeck (Elise18556)" are both following my tweets, such as they are, and their tweets look like the loads of crap that gets filtered out of my email.

In short, I got spammed. Via Twitter. Already. And I don't even use it. Welcome to "Web 2.0".

"Meet the new boss, same as the old boss." —Pete Townsend

I'm amongst those legions of 30- to 40-something programmers whose first computer was the Commodore 64.

When I had it, I wasn't doing so much programming as I was collecting as many games as I possibly could for it. I had an Intellivision at the time, but the Commodore 64 was way ahead in terms of graphics and sound. I futzed around with BASIC, aced all of my computer classes in high school, and generally just had a good time with it. I remember distinctly getting the GEOS operating system for it, and I never looked back to that two-tone blue, command-line interface again. I still remember that OS with fondness and awe over what they were able to accomplish with only 64K of RAM.

I could go on about the awesomeness of the Commodore 64, but it's suffice to say that my entire foundation of knowledge about how computers work was based on the Commodore 64, my interests in software, computer audio, computer graphics, were all born on the Commodore 64. The GEOS operating system made my jump to the Mac a cinch, and for that I feel a sense of gratitude to those developers. There are few things in my life that have had as much influence on me as the Commodore 64.

What has me on this nostalgia kick is that Daring Fireball recently had a link to a story about a company that created what looks to be an awesome Commodore 64 emulator for the iPhone. Apple, rightly yet wrongly so, rejected the application pointing out the specific terms of the SDK agreement. Yes, the application clearly violates the SDK agreement, but Apple is yet again inconsistent with their approval process according to the article as there are other applications out there that do the same thing with different systems (I'm looking at you, Sega).

I very much hope Apple will come to their senses and let it through. If not only to be able to futz with old-school BASIC again, but then just to be able to play Bruce Lee again. I loved that game, but the batch of emulators that are out there really aren't all that great. Like Mr. Gruber, had it been approved, I would have purchased in a nanosecond (despite my wife's complaint that I already have too many games. Whatever).

I had my Commodore 64 all through high school, college, all the way up until about six years ago. I viewed it, at the time, as so much dead weight because storage space was limited where I was living at the time, and I had not physically touched it in years. I sold it at the MIT Flea Market. All original Commodore kit complete with CPU, disk drive, monitor, printer, and the entirety of my software collection traded for a measly $50. As soon as it was gone, carried away by the stranger that I sold it to, I got a lump in my throat.

I still regret that decision to this very day.

The core of one of my more robust applications is now built in Xcode*, a port from REALbasic to hopefully take advantage of some Cocoa technologies. It went pretty smooth, I have to say. A lot of the math was already sorted out from before, but still, it wasn't as bad as I thought it was going to be once I wrapped my head around the Xcode paradigm.

But that was the real trick: the head-wrapping around Xcode. I wouldn't say that, in terms of development applications, comparing REALbasic to Xcode is like comparing oranges to apples (that switch was intentional. See what I did there?). I would say that it's like comparing oranges to enormous blue elephants.

Cocoa is vast, and I easily spent more time reading about what to do next as I did actually doing it. The ratio between reading and doing in Xcode compared to REALbasic is huge. As I noted in another forum, Cocoa has a class for everything, including array enumerators (logically named NSEnumerator). It was overwhelming and frustrating at times ("Why the @#$% can't I just do what I want?"). But once I finally read all of the prerequisite material (more on that in a little bit), and began to see the common patterns, Cocoa became richly rewarding because a lot the math I was dealing with was already taken care of for me.

In particular, I'm amazed at the simple elegance of the NSRect used in drawing coupled with the NSPointInRect, and all of their coding cousins. Stunningly simple to use and all of it makes so much user interaction a cinch. For REALbasic, I had to write all of that code myself, and while it works, it isn't nearly as logical as how Cocoa handles it. As soon as I got it all working together, it became one of those "If I only I had known" kind of a thing. I will say, however, that I feel that I am a better programmer for having gone through that exercise, but still. I hear the complaint that Xcode is much more verbose, but at the same time, the line count in Xcode for doing the same thing in REALbasic in my project is a fraction, even the number of functions went down.

In terms of interface design, I'm currently having to deal with Scroll Bars in Xcode, and it's safe to say that Apple really doesn't like you mucking about with them. The few instances of Scroll Bars in Xcode are tied to specfic controls, and I can't just lay down a Scroll Bar next to a custom view and hook up things the way that I did in REALbasic (you know, in a straightfoward manner), or at least it's not obvious to me in any way. In REALbasic, I just drop in the Scroll Bars that I need, hook up the code, and away I go.

As a side note speaking to the vastness of Cocoa, almost all of the class documentation has recommended reading. So, to read about Scroll Bars, the Introduction to Scroll View Programming recommends the Cocoa Event-Handling Guide and the View Programming Guide for Cocoa. The Cocoa View Programming Guide recommends the Cocoa Fundamentals Guide, which in turn leads to The Objective-C 2.0 Programming Language and the Model Object Implementation Guide. That's over 500 pages of reading right there, folks, and that's only a portion of what is needed. Believe it when I say that you will end up reading all of them; they may say "recommended", but they mean it more than that. (If only I could carry this stuff around as eBooks on my iPhone.)

The single biggest downfall for me with Xcode is Objective-C 2.0, because it's just a thin, yet insanely useful, object layer over the hell that is C. Yes, hell. REALbasic is just so much easier to read and write, with its notable lack of brackets and semicolons (ooh, you semicolons, I shake my fist at you). Refactoring code is much easier in REALbasic than it is in Xcode, because there aren't separate header and implementation files to muck about with. I would think that going from Xcode to REALbasic, not having separate header and implementation files would take a little getting used to, but going the other way, remembering there are two files for evety class requires outright practice. If a property or method needs to be moved over from one class to another in REALBasic, it can be, and usually is, as simple as a single copy and paste. Try that with any of the C-variants.

Another major trade-off that I can see between the two is that with Xcode the developer is programming "close to the computer". It's a quick step into memory addresses and more direct control over what happens on the machine itself. REALbasic doesn't have that same close-proximity "feel" to it, at least not up front, which in a way is easier because memory management just simply isn't a task for the developer. That makes for much cleaner code, and more time is focused on core functionality rather than low-level machine management. Declares in REALbasic help with getting the more low-level or platform-specific functions, but like Xcode, you need a real reason to be doing it, and I've only come across a need for something low-level a few times.

In terms of an interface, I would have to say that there are a lot of trade-offs here. For one, I really like having the Groups and Files ever-present in the right of the window in XCode. REALbasic's layout doesn't allow for that, and having to go back to the Project tab can sometime be a hassle (albeit a minor one, but even small things repeated countless times become big things). But, I have to say that I prefer working with REALbasic's icons and straghtforward objects in the left column because that aids in refactoring rather than so many text files.

People sometimes complain about the limited scope of REALbasic when compared to Xcode. It's a fair assessment, but a lot of what Xcode accomplishes doesn't fall within REALbasic's mission. With Xcode, all of OS X is laid at your feet. While REALbasic does have its declares, I don't think REALbasic is designed to be an outright replacement for Xcode, otherwise they would have sorted out a way to integrate a lot of Mac OS X frameworks directly into the REALbasic frameworks. It's tough to beat the original, and here I think it would be a suicide mission. REALbasic has found their place with the IDE, and I think they should stick to their guns.

Xcode is not for the feint of heart, and it certainly isn't designed for tinkering around, whereas REALbasic has appeal to the hobbyist and the full-time professional. Xcode, on a certain level, almost demands that you have a reason to be there, and makes a lot of assumptions about your skill level as a developer. Xcode represents a major commitment on a number of levels. My time spent in Xcode matches that of REALbasic, but I spend more time reading, researching, and looking up functions in Xcode, where in REALbasic, I started coding truly useful applications much sooner. They are both rewarding to work with, but the characteristics of those rewards are different.

REALbasic has a genuine advantage over Xcode in that a developer can write a useful application in straightforward code of almost any scope fairly quickly. In that regard, REALbasic has as much a place in the developer's toolbox as Xcode. As far as I'm concerned, anyone who disrespects REALbasic is just jealous they didn't find out about it sooner like we did.

Scroll Bars in Xcode are on the docket for this weekend, but I have some reading to do first. Wish me luck and happy coding!

---

* By "Xcode", I mean Xcode and Interface Buider using the Cocoa and Carbon frameworks and Objective-C 2.0.

I think this is becoming an annual tradition, me musing on my biggest of all projects. But like a salmon going back to the spawning grounds because of some primitive urge, I feel the need to muse again. Unless you can sympathize with me as any other tormented programmer, or have a vested interest in my sanity and can handle plunging into its depths, I suggest you move onto something else.

For those of you that are continuing reading and are new to the show, I have been working on a music composition application, strictly MIDI-based, off and on for the past few years. Okay, few really means several, but with an equal balance of both off and on, and I only write about it when I'm "off".

The application, for the most part, adds nothing new to MIDI apps that hasn't already been done. The standard features are there for note creation, editing, multiple tracks, undo/redo, etc. It's just that my take on the MIDI application has tools that I have yet to see in any other MIDI editor, and I'm still surprised any of this stuff hasn't been done yet. It actually originally started as much as an exercise to see if I could do it. I'm also keen on making it easy-to-use, by not being bogged down with too many tools, and therefore affordable. The feature set that I have in mind makes it not necessarily competition against GarageBand (I can't compete against "free") or Logic (I wouldn't dare try), but instead to complement them.

The project is large for a solo developer, from what I understand to be considered large based on what I've read. It weighs in at over 10,000 lines of code, and that increases by another half if I take into account the amount of documentation I have about the current iteration, comments and otherwise. Although, most days it seems like so much more.

It has a couple of names, but for the most part, I just simply (affectionately) call it "The Widget". I've talked about this project so much, bouncing ideas off of people and ranting, that The Widget has become a part of the family's lexicon. I rarely get through a conversation without hearing "So, how is the Widget coming along?" That has been both a good and bad thing because it forces me to be brutally honest with myself about The Widget and yet I still keep thinking about it and what to do next.

I don't feel I'm any different from most other developers in wanting to create an application, any application, that people see as a "must have" or that raises the bar for all of the other applications of its type. The Widget could be one of those apps, or it could not but I think it has that potential. Either way, the more I develop it, the more I play with it, and that is what is most important to me ultimately. However, personal satisfaction only takes one so far, and there comes a point when there needs to be external validation.

No, this is not an announcement that The Widget is soon to be released. Far from it, in fact, though that would be totally awesome. I'm merely using this forum as a therapist of sorts, and to blow off a little steam. See, The Widget is stalled. Again.

The Widget, I feel, has a well-designed architecture. It's document-based, I use a lot of objects, modules, and methods to reuse code as much as possible, it's easy to use, and code (for the most part, I'll get to that bit later), and it has relatively scaled well over the long term. I've poured through Code Complete, Design Patterns, and a couple other classics enough times that I think their authors would give me a tacit approval of my work. As expected with anything this size, I've refactored it once, rebuilt it from scratch another time, and a gazillion little iterations in between. But I still found one fatal flaw in the current iteration: I totally didn't handle commands correctly and I've gummed up the works.

My original strategy was that I would put in all the functionality first, and then put in the undo and redo code. However, some of the initial features ended up having further-reaching implications than originally planned. I had to stop adding functionality and get to work on the undo engine so I could be sure that everything was being handled properly. It was after doing the commands for Add, Resize, Delete, Group, and a couple other basics that I realized that commands really need to be developed in tandem with new functionality.

The other problem with commands is that if not done right, a Command class can become a more than a little unwieldily when trying to record the state of affected widely-varied object types (Windows, Classes, and Files. Oh my!). They need to be refactored because handling the most basic of the higher editing functions ended up taking an entire day and it still isn't complete (Undo but the not Redo, and I think even that statement can be viewed as a symptom). I have a day job and chores to do so my time needs to be spent well.

There are some other refactors, though not as large, that could be done to make the code more manageable. I have various custom classes to handle editing that could easily be broken out into smaller chunks to give more focus, and I've already written up the documentation and cooked up the framework in REALbasic to do just that.

I could continue with The Widget as it is now, but I feel that it would just take far more effort than necessary and that just isn't reasonably sustainable through that magical, mystical version 1.

Do I see The Widget as a failure? Hell no. If anything, I see it as a victory, and a deeply personal one at that. The Widget has driven me to learn programming, and there are times I wish I had started down this path a long time ago. I don't think I have ever found a task so dynamic and rewarding. The Widget, because of its size and scope, steered me in directions that have helped me in almost everything else I do even in other languages. The journey has truly been the reward.

I have recently come to terms with the fact that I might not ever release The Widget; that The Widget is forever destined to be a personal pet project. In fact, I'm currently rolling around the idea of open-sourcing The Widget under the GPL and let it loose upon the world in source code form for some other newbie to pick up and hopefully learn a few things like I did with other code examples. How I got to that point is a bit random, and speaks to my oft-denied desire to just noodle around and yet complain about my noodling.

For the past couple of days, I've been researching more about the Command pattern, trying to pick up on something in an implementation that might help me in the situation I'm currently in. In doing so, I stumbled across an example Xcode project that closely resembled the example REALbasic projects that were the initial kernels that got The Widget going. Reading turned into noodling, noodling turned into more research into Widget-specific features, and a feasible framework was devised. Essentially, I began work on moving The Widget to Xcode and I think it's the direction I'm going to move in.

I have several goals I hope to achieve in moving The Widget over to Xcode. For one, it would give me a framework in which to learn different aspects of Cocoa. The Widget has it all: it's document-based, graphics, audio, etc. Cocoa has in place functions that I could really use that I had to write my own functions for that I'm not entirely happy with. So, in Cocoa's own way, I'm hoping to reduce the amount of "tool" code, for lack of a better word, I need to maintain and take advantage of its efficiencies. I originally wanted to reduce the line count, but that was quickly cast aside. The code will require however many lines of code it needs. 10,000+ lines of code is a milestone, but it can't be the primary metric by which the project is judged.

Of course, moving The Widget to Xcode is also going to mean a lot more hair-pulling, I'm sure. There's also no guarentee that I won't come across the same problems in Xcode that I have in REALbasic, and I know I will come across new ones. But much like The Widget and learning to code in the first place, I think the pleasure of Cocoa is going to be worth the pain, and I'm a much more experienced developer than I was when I picked up my first Objective-C book so many years ago.

There has also been the issues related with REALbasic itself. No proper Grid control (making a track list in a music application is all but impossible without one, container controls aside), and the flip-flop status of the NotePlayer class to name a couple. There are trade-offs to be sure, the track listing features were a cinch to solve in Interface Builder. CoreAudio is a rough, complex road but REALbasic's NotePlayer class can't be any easier. Besides, other than a couple projects for The Day Job, I only program for Macs, so the cross-platform aspect is lost on me, and I sometimes bump my head on the limited range of native controls that comes as a result of REALbasic's cross-platform paradigm.

So, then, what to do with all that REALbasic code? There's tons of good stuff in there, and while I don't consider it a waste of time, I think it could do more good than just sitting in my code library as a handy reference for various design patterns and techniques. So, that's why I'm thinking of open sourcing it under the GPL after stripping my unique functions. Someone is bound to find it useful. But, then what if I want to go back to the RB version? How does the GPL affect me then? Thus, the debate about open source.

Not too long ago, I wrote an article here about my future with REALbasic, and what I need to do to keep it as a viable tool in the toolkit. I concluded, and I still think this, that the onus is on me to keep up with REALbasic Studio, not for Real Software to pander to my individual needs. I have always seen The Widget as a large part of what direction I will go in, but I'm thinking now that doing so places too much pressure on myself and the project, and it's taking away from the the fun of it all. By direct result, I don't see The Widget as being bound to REALbasic anymore.

Does this mean that I will stop using REALbasic altogether? Hell no. REALbasic, for all of its foibles, is far too useful to just walk away from it. Cocoa is über-powerful, but with REALbasic, I get to just focus on the core of an application right from the very beginning in a clear syntax. MVC is nice, but there is something to be said about throwing the code into the interface and getting work out the door rather than futzing with hidden bindings and deep-featured Inspectors. There have been more times than I can to count where I have used REALbasic to whip up a solution that has earned me the reputation as a quick, comprehensive problem-solver (though the flavor of that reputation would be a matter of debate amongst my peers). Those who are quick to dismiss REALbasic are missing out, I think, and maybe a little jealous.

The question of whether I stick with REAL Studio or move back down to REALbasic Professional is the true question for that. Downgrading will depend on the state of projects when my license expires and how flush I feel with cash at the time (and with The Kid on the way, I don't have high hopes for REAL Studio). But there is no question that the licenses will get renewed one way or another. The only difference now is that I'm just going to stop worrying about what is going to happen in little over a year and focus on The Now.

As for The Widget, I'm just feeling as though my biggest, most favorite project needs a fresh start. I'm looking for a new journey, which is easy when I'm no longer so concerned about the destination.

To the woman that Renée and I saw yesterday in rush hour traffic driving her car while holding her fast food packaging in one hand, eating a burger in the other, and with the cell phone tucked in her ear because she didn't have a hands-free kit: I would never, ever wish anyone to get into an accident, and I'm no saint with my cell phone, but you deserve everything you get based on how you drive your car. Just sayin'.

---

The best comment from the Boston Globe article about the recent Boston MBTA trolley accident where the trolley driver admitted to texting:

"The Boston Red Sox should provide free, replacement tickets to game-goers who were already late for first pitch?"

Nah. If they were such fans, why were they late?

---

It's only a crisis if you intend to do something about it. If you intend to do nothing about something that could be considered a crisis, and just leave it be, then how is it a crisis? If you decide to not do something about the problem facing you, then you can't say "crisis averted". Stating "crisis averted" implies that you acknowledged the crisis for what it was and did something about it.

---

I don't claim to be perfect, I only claim to be diligent. Someone claiming to be perfect means that they won't own up to their own mistakes, and might even go so far as to justify the mistake as something they meant to do. I mean, really, how can there be mistakes if they are perfect? If someone is diligent, then not only do they acknowledge mistakes, but they also take ownership of them and resolve them as best as possible. I would much rather be diligent than perfect any day, and that's why to this day I only write with pencils. I make mistakes all the time.

---

After having purchased and used several iPhone eBook readers, I have to say that all the good ones (Kindle, Eucalyptus, and Classics) are all just subtle variations of the same concept, and none of them really vary much in good or bad relative to each other in the grand scheme of software. Collectively, they have set the baseline from which all new readers will be compared against. Good on them.

At the same time, they would all benefit from the same features that they don't have, namely the ability to highlight text, add comments, and the ability to search. I'm a bit surprised about a lack of discussion in the mainstream about that last feature because none of these books include a functional index. I think it be very empowering to search a book for something, like how I can with a PDF, but then also search all titles at the same time for the same thing.

I'm also not thrilled with the prospect of not being able to read my Kindle titles just on my Mac's screen, like I could with anything from the Gutenberg Project, but that's a discussion for another entry.

---

Reading Daring Fireball's great diary excerpt of someone who approves iPhone applications reminded me of this long-standing theory that the bulk of the iPhone application approval process isn't done by "reasonably smart late-20s/early-30s guy with a B.S. in comp sci". I think it is instead handled by reasonably smart comp sci *interns* that are managed by full-time employees who, collectively, have a clearly-defined set of rules, no legal latitude (e.g. when in doubt, reject it), and that, as an unspoken rule, don't talk to each other and have little or no real-world application development experience. In short, the approval process is like cell phone or cable customer service: the resulting action, in this case application approval, a developer gets largely depends on the individual and their manager that sees the application.

So, one app being accepted while another, similar app is rejected is because the first app was seen by one group and the second by another, probably clear across the floor of the building and both are unaware of the others' existence beyond a face in the hallway on the way to and from the bathroom and cafeteria.

The reason why I think the approval process is done by interns is because we had a woman here at the office whose husband was getting his music composition degree at Berklee here in Boston. He had an internship requirement to fulfill and scored a position over at the iTunes division ripping music and entering metadata. It turns out that the bulk of the iTunes work is done by interns, and I don't see any reason why iPhone applications would be handled any different. Interns are cheap, plentiful pretty much year-round, and are already trained employees should they make the cut to permanent status. But, they also have almost no real-life experience, so they can easily reject applications based upon the (probably contradictory) guidelines given to them by the iPhone and Legal divisions.

Little less than three years ago, I used the Schoolhouse Rock classic to announce my sister- and brother-in-law's pregnancy. I'm happy—nay, ecstatic—to say that it's now Renée's and my turn.



Because we don't know if it's a boy or a girl, nor do we want to, we reference it as either "The Kid" or "Elvis' Love Child". The next time you hear Elvis on the radio, play him loud.

All hell is supposed to break loose in late October, but without getting into any details, I think it can be argued that it already has around here, and that's part of the reason why it's been a little quiet around here lately.

Buying the Daughtry album was supposed to be an impulse buy. I saw the band play on Amercan Idol, liked the song, and wanted to buy the first album. I'm clearly not a devoted fan seeing as how I'm only just now buying the album, but Daughtry is something that I wouldn't mind in the iTunes rotation while doing stuff around the house.

But I can't just buy the album. No, I have two choices and neither of them fit my desires as a consumer. The choices are as follows:

Daughtry (Deluxe Edition) , [Buy Album], $16.99: The original 13 tracks, three live and acoustic tracks and eight videos.

Daughtry , [Partial Album], No Price Listed: All of the original thirteen tracks. Prices are either $1.29 for the hit singles, $.99 for the rest.

One of my favorite aspects of iTunes has always been the ability to—get this—just buy the entire album with one click. I have purchased single tracks before, but sometimes I realize I want the whole thing because sometimes a track is part of a much larger whole. Almost all of my iTunes purchases have been the entire album. With Daughtry, I can buy the album, but it takes over thirteen mouse clicks or one click with an added $3 expense and MBs of content I don't care about.

So sorry, while Daughtry is cool and all, I just don't see enough material to make 11 extraneuous items to be compelling enough to pay the price of a physical CD. There are very few bands where I will have the patience to sit through all of that. At the same time, do I *really* have to click all thirteen tracks to get the album? I really still pay physical CD prices ($14.09 to be exact) for a collection of files, you know, something that clearly isn't a CD (thus the point of iTunes)? Where is the super-convenient, easy-to-use-and-understand $9.99 Buy Album button? It's not really a big deal getting the extra stuff, I just don't want it hanging out on my hard drive because it serves no purpose than mixing in with the chaos and taking up space that I could use for more compelling data.

Last night while out getting some dinner and doing some shopping, I did pass by an FYE (with three very earnest, and bored, salespeople), and thought about maybe picking up the Daughtry album there. I almost went in but decided against it because I didn't want to be accosted by earnest, bored salespeople (yes, I, too, know how to use the alphabet. Go away.) and I viewed buying a physical CD, if it were cheaper, as somehow taking a giant step backwards. The last physical CD I purchased was in London three years ago because iTunes didn't have the album (and they still don't) because the last thing I need is more "stuff".

I realize that typing this is decidely more work than purchasing each song or the deluxe album, but there are some real usability metrics being touched upon here. My choice, as a user, is either click thirteen times to make a simple purchase or spend time downloading a bunch of content I don't want. From a purely usability standpoint, both choices suck. As a user I was put off by the whole thing and as a consumer I ended up not buying anything of it because of my user experience. I'm fickle and not enough of a Daughtry fan to put up with such nonsense. I don't blame Daughtry or Apple as I get the overall impression that none of this is really their choice; the blame sits squarely on the record companies here. It's almost as if they are intentionally looking for ways to make music commerce as difficult as possible, and they deserve everything they get.

The humble web page for the Pocket Pal really belies its importance in the graphics arts industry. The Pocket Pal is one of those books that I have seen everywhere in my career and is something that I still pull out to this day. I could gush, but the summary says it all:

Pocket Pal®, the authoritative introduction to the graphic arts, is now in its 20th edition. Acclaimed by industry experts as the best book of its type, Pocket Pal® is the ideal choice for students, artists, designers, printers, publishers, advertisers, buyers of printing and virtually anyone associated with visual communications.

But, again, "20th edition" doesn't tell the whole story because the book was first published in 1934. I have seen more Pocket Pals everywhere I have worked than I have bibles in hotel rooms. But just like an old bible, you don't just throw an old copy away. Old Pocket Pals just get shuffled into dark corners of bookshelves as newer copies and other books take over the prominent places above and beside the desk.

The other day, we found an old copy of Pocket Pal on a bookshelf at The Day Job, specifically the 50th anniversary edition with a copyright of 1988. A question came up of what exactly trapping and overprint were and their difference form each other. The questions were answered by the book correctly (some things just haven't changed) but we also stumbled onto some text that was worth a chuckle.

For a frame of reference of when this book was published in 1988, I was a junior/senior in high school and just starting to do basic drafting and illustration on some of the first Macintoshes. Adobe Illustrator was version 1.x, QuarkXpress was still in its infancy (though some would argue it still is to this day), and the only online information source I knew about was Quantum Link for my Commodore 64. Almost all page layout was still done by traditional paste up.

Page 59:

The future of page makeup Advances in digitization and scanning now permit us to reduce any visual item (pictures, illustrations, etc.) to a series of digital signals. High resolution video workstations can display these elements to handle type and other elements routinely. Already, digitized typesetters are setting type and outputting halftones.

Newly introduced copier/duplicators use digitized methods to produce pages for high-speed reproduction. For the last few years we have been using digitized methods for platemaking, scanning a page pasteup and then using lasers to produce the plate.

The implications of of electronic page makeup leads us to the plate and reproduction steps of the printing process. Once a page is in electronic form, it can be stored, transmitted, and output to a typesetter, platemaker, or electronic reproduction system. In some cases it may be transmitted by earth-orbiting satellites to remote printing locations.

It all sounds so Shiny And New™. It was that last line that got us started. I couldn't imagine sending the data for even a small 1/c book via satellite anywhere. FTP sucks enough as it is and the reputations of satellite ISPs aren't known for speed as much as "no other option is available out here in the boonies".

Page 60:

Personal Computers
Usually consisting of keyboard, video screen, floppy disk (and internal microprocessor computer), personal computers have become the Model Ts of the electronics world. Easy-to-change software allows each unit to perform word processing, accounting, and other function for business or personal use. Data prepared on personal computers is often interfaced with typesetting.

It took us a minute to decide whether comparing computers to Model Ts was a good or bad thing, especially when looking at the eight-core Mac sitting on the desk at the time we read this, arguably one of the BMW M-series of the computer world right now. I love how "internal microprocessor computer" only gets a parenthetical mention.

FUTURE
Computers and software have been responsible for many improvements in costs and productivity in graphic arts and they will continue to expand its horizons by extending these imptobvements to the pressroom and bindery. Now that printers realize they are part of the vast information industry that dominates the US labor force and economy, computers and software will gradually usher printers into the use of information media other than paper and ink. These new media are electronic like Videotex, cable TV, electronic newspapers, paperless books, electronic shopping, electronic telephone directories, and even electronic publishing and ink jet printing. To prepare themselves for these media, a number of newspaper and magazine publishers already own cable TV stations.

It's interesting to see how much of that is so right and yet so wrong at the same time (electronic telephone directories in particular), and how long it has taken for us to get where we are now. I had to look up Videotex because I had no idea what that was.

Losing an iPod isn't the same as losing a cell phone. I can't call my iPod and follow the ring.

---

Coffee may start my day and the oatmeal keeps me healthy, but it's the tea that keeps me sane.

---

Total anonymity on the web is really only for the pranksters. If you aren't going to visibly stand behind what you say, then you are perpetuating the kinds of actions that have lead to the t-shirt that says "Never underestimate the power of stupid people in large crowds." It's one thing to be allowed a voice in forums and comments sections, but your character is derived by how you use the privilege given to you.

For example, I mixed it up a little bit on Boston.com about their recent reporting about the current flu problem. My avatar is my photograph that can also be seen on LinkedIn, FaceBook, etc. Going to my profile on their site brings anyone back to here, and anyone is welcome to contact me. I stand behind what I write, and I think it would be great if others did the same.

So, either my browser had problems the other day or Google pays attention to this site, because it looks as though I didn't lose all of that information in Google Analytics. All of it is back, including the empty profile for this site that I know for a fact I deleted. I guess I won't be trying that again any time soon.