Productivity « Standing on the Brink

Cory von Wallenstein 5:07 pm on August 14, 2011 Permalink | Reply
Best Wireless Scanning Experience to Date: Epson WorkForce 840

I hate paper. Yet I have piles of it.

Many of my Dyn Inc. documents do get digitized thanks to a kick-ass HP scanner at the office that emails you a PDF of whatever you insert. At home, however, it’s been a pain.

Until now.

Finally fed up with tons and tons of paper lying around, I made an (impulsive) purchase of an Epson WorkForce 840.

I could not be happier with this thing. Here’s my workflow:
1. Toss in a pile of papers.
2. Press Scan, then Scan to Memory Card.
3. Get a full color duplex scan as a PDF over the network via the scanner’s file sharing. No fuss.
All for $180. Plus it prints and all that jazz (but who cares… wasn’t it printing that got us into this mess to begin with?).

In detail, here it is. Start off with a bunch of two-sided pages (tray holds up to 30):

Make sure I have a USB flash drive installed. This stays here all the time and is mounted over the wireless, just a spare 1GB USB flash drive. Nothing fancy.

On the touchscreen, select Scan, then Scan to Memory Card.

When it’s done, the PDF is accessible from the Samba share that has the USB flash drive mounted. Just make sure you turn on network file sharing in the Epson’s setup menu.

Go buy an Epson WorkForce 840 and clean out your home office.
Reply Cancel reply

Required fields are marked *

Name *

Email *

Website
Cory von Wallenstein 11:16 am on January 8, 2008 Permalink | Reply
Tags: developer guide, example code, technical books, technical web sites, user guide
Ever Use Example Code From a Book That Did Not Work?

The challenge of keeping example code updated and working when it is destined for printed form was addressed during my update over the weekend with a quick glimpse into how we’ve overcome the problem. In a nutshell, we keep our example code in source control, and use brief tags in Microsoft Word along with a Word macro that pulls the code directly out of source control and places it inline with our descriptive content. See my previous article for the technical nitty-gritty.

Now I want to highlight a couple areas where I think this approach will be applicable, as well as a demonstration movie showing how we use it.
1. Technical Books. Big, big problem. I can’t remember the last time I picked up a programming book and didn’t find a flaw somewhere in the example code. Just like we have a spell-checker to catch a good portion of typos, we can now have a compilability-and-testability-checker, since our code would be coming straight from source control, where the automated build system and suite of unit tests made certain everything was working.
  
  And really, knowing that the printed code works is only a small benefit of this approach. I see a much bigger benefit being when edition 2 of a book comes out, and now making all of the code in the book up to date is as simple as… making the actual code in source control up to date. Then just run the macro to pull the new code into the book. Much, much simpler than having to go through the book and manually update all of the code examples.
2. Web Sites. This might be even more of a problem than with the technical books, since there often isn’t quite the same review process for web sites as there is for mass-produced technical books.
  
  Probably about 90% of the work I had to do to make this happen in Word was spent overcoming my own lack of knowledge in macro development and VB/VBA. This would have been significantly easier for me to have implemented with server-side software that I am more accustomed to; but alas, that was not where I needed it the most. I needed to address our printed documentation. I leave it to someone else to benefit in the online world of code examples.
3. User Guides and Developer Guides. I think I beat this one to death already. Let’s move on to the video.
Here I walk through the API manual for our WebReboot Enterprise, and show how a technical writer would add code examples into their documentation, and have those code examples come right out of source control.
Jeanine Mccay, Dave, and Cory von Wallenstein are discussing. Toggle Comments
- Dave 11:44 am on January 8, 2008 Permalink | Reply
  
  I’ve been doing the same thing with OpenOffice.org for a few years and we’ve been doing it with DocBook (and other various XML formats) for some time now. Several Wikis support pulling in code snippets via various mechanisms.
  
  Is there something particularly new about your approach?
- Cory von Wallenstein 12:33 pm on January 8, 2008 Permalink | Reply
  
  Certainly. The biggest differences to previous approaches and this approach are focused around ease of use both for the programmer and the technical writer, and for level of control of code selection.
  
  DocBook, for example, makes it pretty easy to pull in entire outside files, but that is only useful when you’re showing a complete example program. What if you’re describing a method name inline in the content? What if you wanted to say:
  
  “The doPowerOff method is used for doing A, B, and C.”
  
  With other approaches, you really don’t have a way to say “insert this method name here” in the document such that when the underlying code is inevitably refactored (perhaps to doServerPowerOff), the references to those method names get updated inline too.
  
  Even if you had an external file that just had that method name in it… for this example, with Java, that would not be valid and compilable, so its usefulness diminishes.
  
  Even specifying by line numbers is far, far too brittle. By having the code identified with context-relevant tags, life is easier for the programmer moving code around, and the technical writer trying to figure out what-does-what.
  
  Really, we needed a way to get down to an atomic level of control for what code gets pulled into the documentation, and we needed a way to keep the code itself valid and testable by our build environment, and most importantly, we needed to support code refactoring so the changes would automatically cascade throughout our documentation.
- Dave 3:30 pm on January 8, 2008 Permalink | Reply
  
  I built my DocBook files by embedding elements that would retrieve a file and look for commented “snippets” in any of a couple source control systems; the same thing in OOo (but via OOo scripting). It’s the same way the Wikis I use pull in external snippets and seemed the easiest way for my documentation and books.
- Jeanine Mccay 10:41 pm on April 30, 2011 Permalink | Reply
  
  One thing I want to say is always that before purchasing more laptop memory, look into the machine in which it will be installed. If the machine is running Windows XP, for instance, the memory limit is 3.25GB. Using in excess of this would purely constitute some sort of waste. Be sure that one’s mother board can handle the actual upgrade quantity, as well. Interesting blog post.
Cory von Wallenstein 9:50 pm on December 18, 2007 Permalink | Reply
Tags: Productivity, winter

Why So Productive in Massachusetts?

I think I get more accomplished in the winter months in New England than throughout the rest of the year. And it’s no wonder…

We managed to time our return from Washington DC right between two monster storms. When it came time to decide what the weekend’s activities should be, a simple look outside on our porch pretty much summed it up:

Internet? Check.

Power? Check.

Caffeine? Check. Check. Check.

Let’s get to work.