Idiotprogrammer Blog

Category: Python/Zope/Plone

  • Docbook, Pandoc, Rants and Some Decent Free Fonts

    I’m working on a user manual and am in the process of discovering several tools to do the job.

    Here’s RSTA,  an online restructured text editor which lets you output into HTML and PDF. This is mainly of interest to people in the plone and python world.

    Python programmer extraordinaire Mark Pilgrim explains why he codes in HTML and not Docbook. From the comment section, I learn about Pandoc, a great program for converting different forms (LaTex, RST, markdown, HTML, Docbook, gosh – just about everything!).

    Here’s the Pandoc user guide and an online converter. The key, I’m guessing is how it handles unicode and document fragments, but I look forward to finding this out.

    Pilgrim also does a rant about the restrictive fonts:

    I know what you’re going to say. I can hear it in my head already. It sounds like the voice of the comic book guy from The Simpsons. You’re going to say, “Typography is by professionals, for professionals. Free fonts are worth less than you pay for them. They don’t have good hinting. They don’t come in different weights. They don’t have anything near complete Unicode coverage. They don’t, they don’t, they don’t…”

    And you’re right. You’re absolutely, completely, totally, 100% right. “Your Fonts” are professionally designed, traditionally licensed, aggressively marketed, and bought by professional designers who know a professional typeface when they see it. “Our Fonts” are nothing more than toys, and I’m the guy showing up at the Philadelphia Orchestra auditions with a tin drum and a kazoo. “Ha ha, look at the freetard with his little toy fonts, that he wants to put on his little toy web page, where they can be seen by 2 billion people ha h… wait, what?”

    Let me put it another way. Your Fonts are superior to Our Fonts in every conceivable way, except one:

    WE CAN’T FUCKING USE THEM!

    Soon — and I mean really fucking soon, like “this year” soon — there will be enough different browsers in the hands of enough different people that can use any possible font on any possible web page. And then a whole lotta people will start noticing fonts again — not just Your People, just also Our People. People who couldn’t tell a serif from a hole in their head, but they’re gonna be looking for new fonts. People who are just savvy enough to be tired of Comic Sans will be looking for a new font to “spruce up” their elementary school newsletter, which, in an effort to Love Our Mother (Earth), they now publish exclusively online.

    A typeface designer responds:

    As a type designer I feel like I have to step in and say something here. First off the majority of typefaces designed in the past twenty years haven’t been made by big foundries but by individuals working on type in their spare time. Second, typefaces receive no copyright protection in the United States so copying font files and renaming them for sale is pretty much legal. Third, fonts have been available on peer-to-peer networks since before the days of Napster and in 2000 it was estimated that only one out of fifty instances of a typeface file (postscript or TrueType files) was paid for, and it has only gotten worse.

    I have over forty commercial typefaces available for sale through various type re-sellers around the world and my average yearly income off the typefaces is $115, even though I regularly see my typefaces in use on the web, on TV in print and in video games. I used to think that one day I’d have a nice supplemental income from my typefaces but the reality of the situation is that people like you don’t value the effort that goes into making a typeface. I haven’t designed a new typeface in eight years now and I have no desire to do so. Why should I when you’re going to be a big bitching twat you greedy self-centered tantrum throwing teenager?

    Actually, the whole thread has a lot of expletives and rants, but lots of issues come up.  Actually, the most valuable information I gleaned from the threads were the names of some decent free fonts: Gentium, Day Roman, Yanone Kaffeesatz, Yanone Tagesschrift, Delicious, Aller, Charis SIL, Doulos SIL, Junicode,  Linux Libertine, the Liberation and Droid families, and Computer Modern (or, more likely, its Type 1 version, Latin Modern).

    See also the Open Font library (here’s the beta version, which seems buggy—the search results only gives 1 result). Here’s a general list of the most famous free fonts, separated by license type.

    Here’s a good (and indispensable) article about how to use the font-face css rule to use any of these awesome free fonts. Here’s another how-to. Here’s a nice demo.

    Update: This browser support table shows that Chrome 3 (the current version) does not support embedded fonts, and that Chrome 4 will be released in 2010. Also, Internet Explorer only supports EOT fonts. (I’m not 100% sure what that means; according to the link in the previous paragraph, EOT is a Microsoft implementation of fonts. Certainly there has to be a conversion tool? Update 2: this font wiki has this information and more).

    The free font issue is important for distributing ebooks. (Here’s a mobileread discussion). The .epub standard supports embedded fonts (I think), and having a unique font makes reading a more enjoyable experience when reading on a  Kindle or Nook.  I am growing weary of the same font on my Sony PRS 505 reader.

    I guess I haven’t mentioned it yet, but I’m working on two creative commons ebooks and am working on a user guide to publish on Booksurge and possibly as an ebook as well. For that reason, I’ve been learning a LOT about docbook. Overall, I’m happy with its flexibility even though the learning curve was steep –and also I’m depending a little too much on a on a noncommercial license of Oxygen XML editor. If I wanted to do something commercial, I’d have to pay $349 for a full version and $199 for an Author version (which lacks some  XML/XSLT tools but has an easier interface). Frankly, Oxygen is incredible, but I’m close to making commercial use of it.

    Serna XML editor (the free version) is good for authoring, but I haven’t figured out how to validate it using various  schemas and DTDs. Apparently, Serna uses python plugins to enable validation of various XML languages like docbook and DITA. It looks like Serna only supports 4x versions of Docbook; I could be wrong.

    By the way, after I finish one or two ebook projects, I plan to write an article about using docbook for ebook creation.

  • Book Review: Practical Plone 3

    With the proliferation of content management system (CMS) software, a need has arisen for good manuals. When a CMS starts out, user forums are usually the main place for help;  then someone will start a wiki, and a few people will write tutorials on their blogs. But if the user base for a CMS grows rapidly, docs quickly go out of date, and it becomes hard to figure out which parts of the docs still apply for the latest release.  That poses a risk for someone wishing to buy  a technical book (or  write  one).  Technical publishers use several methods to future-proof their books. This includes: focusing on core features unlikely to change between releases, anticipating future development, publishing smaller books that require less time to produce and group writing. Group writing (assigning different people to contribute chapters) has been a popular method because it reduces the burden on one person. As long as the assigned topics don’t overlap and are well organized, group-written technical books can be extraordinarily helpful and can be released quickly, as in the case of  Packt Publishing’s latest Plone book (Practical Plone 3).

    First, a little background. Plone is a python-based CMS that has a large user base and many enterprise  features. It is deployed on many nonprofits and governmental sites and historically has been easier to secure than LAMP CMS’s like Drupal. Data is stored in an object database (ZODB)  as opposed to relational databases (although adapters have been written to connect to mysql, postgresql, etc).   Plone is based on a platform called Zope, and in fact Plone’s version 3  release in 2007 implemented many architectural changes.
    Packt has published several Plone books already (including Martin Aspelli’s well-regarded 2007 book Professional Plone Development), and the latest book is bigger, covers more topics and should interest a wider audience.  

    About half of the pages (and a third of the chapters) in this 565 page book contain screenshots to demonstrate functionality which can be controlled with the web interface. However, the book’s audience is not really for novice users or content creators (despite the book’s subtitle that is a "beginner’s guide"). If you wish for something like that, try  the excellent Users Guide to Plone —downloadable for free). Practical Plone 3 covers basic topics in Chapters 4-6, but it focuses on several  topics which are not easy to find the answers for. This book would be useful for the website administrator or the developer or designer trying to customize Plone for an organization or company.

    First, Plone includes lots of features not enabled by default which are hidden in the administration menu (called "Plone Site Setup"). Unlike Drupal (which seems to have a massively complex control panel), Plone Site Setup looks deceptively simple, but lots of things are hidden under the hood. So you need to know where to look.   Practical Plone 3 explains how to use a lot of these features:  versioning, managing groups and roles, creating custom workflows and using the portlet manager to control what sidebars appear on the left or right of the web page.

    Plone differs in many ways from LAMP CMSs both in architecture and concepts. Usually, these differences remain hidden from users. But  understanding these  differences can help you  understand why things work differently in Plone. For example, Plone uses the folder-file metaphor for content objects. They can have states and properties; they can be copied/cut/pasted into other Plone folders even though they don’t really exist as files or folders on the file system itself. Another easily overlooked feature is the extensive metadata fields that exist for content types. (it exists in a secondary horizontal tab  like this one ).

    The book chooses (wisely) not to talk too much about third party Plone  products (i.e., plugins). But it does go into great detail about using PloneFormGen (an auto-generator of web forms) and cache-fu (an indispensable product for caching performance). These two sections were very well done.

    The last half of the book describes  how Plone development proceeds, beginning with creating  new content types. In Chapter 16, the book covers how to use a graphical UML tool called ArchGenXML to create a new content type based on the builtin content types. Here you use Archetypes, a Plone-specific way of building content types. (Archetypes have been around since Plone 2). After you use the graphical tool to create UML, the ArchGenXML script will generate the product code for you to upload to the server’s file system.  Later, in Chapter 17, there is a good walkthrough of using Generic Setup to export configuration changes you make in the Zope Management Interface (ZMI) into an XML file on the file system.  That allows you  to replicate site configuration more easily and  keep configuration information outside of the database.   Chapter 17 also  covers the Zope 3 architecture underlying Plone and how to set up browser views in ZCML configuration files and viewlets and portlets.

    Chapter 18 covers the creation of themes and css for a Plone site. This process is slightly complicated because you make your changes to a themed product which is later installed/enabled from Plone Site Setup. The book walks you through the steps of using a python script called paster to generate a series of files which make up the theme product. Editing the css for the theme is possible only if you understand how viewlets work and which files you are supposed to edit (it is not simply a styles.css file).

    The last two chapters cover caching and performance tuning. Overall, well done.

    In general, this is an excellent guide and it covers a lot of ground thoroughly. Unlike the Drupal series of books by Packt (which struck me as flimsy–they have 12 separate books!), this book  combines  all the important aspects of Plone 3 into  a single book.  Everything in the book struck me as important–none of the material seemed like padding. The usage information in the first section was very well done (although it probably needed better coverage of Kupu, the rich text editor).  The section on workflows was great, and the explanation about Zope 3 views seemed well done, but the look-and-feel chapter looked imposing. If editing a CSS class means having to edit a theme product and re-add it, that might discourage doing too many tweaks (especially on a live site!). It would have been nice to have an appendix summarizing the configuration files, location of important objects in the ZMI and CSS classes.   I did not see any chapter  about uploading images or multimedia files on the file system; that seemed to be outside of the book’s scope.   I am not a developer (I just play one on TV), but there seemed enough meat in the advanced sections to address many contexts.

    Finally, it’s worth pointing out that the plone.org site has a well-organized documentation section. The book may lack a good section on kupu, but plone.org has  several help topics about Kupu.  (In fact, many of the book’s contributors also produce documentation for the Plone.org site). One doesn’t read this kind of book for narrative; nonetheless,  most of it was easy to read and easy on the eyes.  Except for chapters 17 and 18 (which were a little deep), the rest of the book got straight to the point quickly.

    In summary: this book is a substantial guide which covers a lot of intermediate and advanced topics. Very well written and organized (with lots of illustrations), but the section on themes was hairy and even a little confusing

    *******

    Robert Nagle is a technical writer and fiction writer who lives in Houston.  He blogs about culture and technology on his idiotprogrammer weblog.

  • Ploneability Higher Education Workshop: November 7

    I’ll probably be attending the Ploneability Higher Education workshop at University of Houston on November 7.  Registration is free.

    I don’t work at a university per se, but my plone/ebook implementation should be relevant to people at the university.  Plus, I used to teach at a university in another life.

  • Plone 3 is released!

    Plone 3 is released. Lots of new features here. I’ll be spending the next two weeks working rather building out a plone 3 site for a new project. All I’ll say is, About Fu**ing Time! (Honestly, these are tears of joy)…

  • Houston Zope Python User Group (Houzpug)

    Here. It looks like Houston Zope Python User Group has a website (actually just a redirect). Let’s see how much google juice getting blogged about here gives the site.

  • Announcement: Python Unconference for Texas

    Here’s information about the Python Unconference in September

    The schedule is evolving, but it looks like the focus will be zope/plone and SciPy .
    . It’s hosted by the Houston Python Users’- group

  • Plone’s New look

    Alexander Limi provides an update about development on Plone 3.0. (here’s a screenshot). My ebook site will be backed by plone 3.0. I’ll probably be jumping the gun a bit, deploying on a release candidate or beta 2 version. (Or maybe, I’ll just test all my 2.5 work against 3.0 and magically change over in May when everything is ready).

    It’s always a debateable question about how closely you should match your deployment schedule with the latest release of a piece of software. If I were in the corporate world, I’d play it safer, but now that I’m on my own, I don’t mind the risks involved.

  • Plone Rants

    Torrent Freak, a website devoted to coverage of p2p/torrent technology news. Also includes a podcast.

    Martin Aspeli on the love-hate relationship people have towards plone:

    So following on from that is process. Outsiders always have a tendency to want to add more formalism to Plone’s process, but that kind of misses the point. Some formalism is needed, if it enables people to work on Plone more effectively, for example by avoiding duplication of effort. When it starts restricting them, however, it’s bad. Most people have a day job that gives them plenty of management overheads, and when they go home and want to hack on Plone, they just want to be productive. Surprisingly, this doesn’t actually mean we all pull in different directions. The transparency, friendship and mutual respect that exists in the community means there are incredibly few real disputes, and if they arise, they are normally resolved to mutual satisfaction. We tend to debate until we mostly agree and let pragmatism do the rest. This depends greatly on Plone development being decentralised, which in turn stimulates innovation.

    Martin wrote a great guide on creating 3.0 friendly content types. Here’s a video of the same guide.

    Interestingly, at the end of his rant, Martin lamented that “Now, if only I’d spent half as much time fixing Plone 3 bugs as writing this, that may have deflected some future criticism from Plone 3. Back to work!” Sometimes getting a rant out of one’s system can be the perfect way to rejuvenate one’s creative energies.

    (Martin wrote his dissertation on the plone open source developer’s community PDF ).

  • XSLT/Zope 3 Geekend

    It’s official. This weekend, I’m going to do some playing around with Zope 3/Five application development.

    I bought Web Application Development with Zope 3, a recently published book about the subject.

    Here are some appetizers to follow on the worldcookery site.

    I’ll be going through Martin Aspeli’s tutorial on 2.5/zope 3 development.

    I’ll be watching Rocky Burt’s video of the talk he gave at Plone conference in Seattle on zope 3. It was way over my head at the time, but I think I’m ready for it. Well, not intellectually ready, but psychologically ready. I’m rarin’ to go.

    I have my zope hosting to try it out on a live server (well, zope 2.10 with Five). Also, I have my laptop to try things on.

    Making a zope 3 application will be an academic exercise, but very instructive for figuring out the interfaces (also, good for familiarizing myself with python. And getting myself ready for deploying my plone 3 site.

    My goal for the weekend is not to get a plone site out (although I think I might end up doing so).

    I’m preparing for the upcoming release of Plone 3.0 alpha 2 this weekend. Beta 1 should be out at the end of February (yes, there’s been significant schedule slip, but I can wait).

    Although I won’t get around to it, I’d like to get my head around the KSS tutorial (which is plone’s version of Ajax).

    I am not a fulltime programmer, but I enjoy getting it into it again. Also, I wanted to try writing some XSLT this weekend. That might be wildly optimistic, but it would be very nice.

  • Things I have Learned

    Today I figured out why it’s so difficult to find lowcost plone CMS hosting: it uses buttloads more RAM than PHP CMS’s

    I also learned why it’s possible for digital cameras to become so cheap: they offer 90 day warranties instead of 1 year warranties! (Btw, warranty information is often missing on the product spec information on the major sites).

    I realize that from a marketing point of view it makes sense for a camera company to put photos of teenage girls on their promotional information. But why would they choose to have this photo on their home page?

  • Email vs. Content Management

    Seth Gottlieb has a nice weblog about content management, open source and ploney things. (Another good one is Content Wrangler).
    Here’s his post about Smart Folders and plone (don’t know how I missed this one). Smart Folders (previously called Topics) are something worth getting familiar with. Places to start: Using Topics in plone 2.1

    Here’s Gottlieb’s wrapup of the March plone conference. Most interesting were his reports of Alan Runyan’s explanation of why he doesn’t use a plone product for bulletin boards:

    Alan wants to get make Zope less of an island. The example that he uses is that CMFBoard (an add on bulletin board that can be added onto a Plone instance) is a dead project but there is no good reason to write another one in its place. The Zope platform is not optimized for the kind of thing that a bulletin board is designed to do. Bulletin boards are write-intensive whereas the ZODB is more efficient with reads. Instead, Alan recommends integrating with an external BB software built in something like PHP. He did this using Simple Machines Forums (SMF: http://www.simplemachines.org/) for the OXFAM site. All that they needed to do was make some modes to SMF to enable single sign-on.
    Alan wants to create a repository in the Plone collective (which is used to store add-on products) for integrations with external systesm. These integrations could be patches that can be applied to external systems or adapters. Zope could be a very good platform to support this integration based architecture because of its strong support of XML-RPC. I really like this idea and I hope the dialog continues.

    Since my CMS needs are relatively modest and I don’t have a lot of experience making customizations/ integrations, I dread the prospect of involving external products. Still, I can’t reject anything out of hand.

    Here’s Seth’s take on the email vs. content management issue.

    The key issue that I have against email is that it compounds the problem of exploding volumes of unmanaged content by creating unnecessary duplicates. If you email a document to 2 people, you now have 3 copies to manage and merge and diff. No one knows which one is the master copy. No one knows which one is the newest copy regardless if someone stupidly added “new” to the file name. Plus, everyone is personally responsible for their piece of the archive. That is too much responsibility. If I accidentally delete the best version (it may or not be the latest version) of a document, there is no way to get it back.

    (This was a response to the Central Desktop blog on the popularity of email for office work:

    Virtually everyone who has ever touched a computer understands email. Maybe it was daunting at first, but in the end, email is easy to understand. “It’s like sending a letter through the postal service, except its electronic.” People get it. The fact that so many grandparents and young children use email to stay in contact with their families and friends around the world is a testament to its ease-of-use. Likewise, after you “learn email” for the first time, all other ‘variations’ of it are essentially the same. The learning curve for switching email interfaces is virtually non-existent.

    By comparison, most collaboration software solutions are difficult to understand. Many provide such a different user experience (wikis for example) that the learning curve becomes another hurdle of adoption.

  • Plone, Noted, Admired (+ ArchGenXML)

    I’m determined to do my website in a weekend and started downloading/installing, only to be distracted by two things.

    Great programming video by Sean Kelley on deploying a plone site and specifically creating a simple archetype using ArchGenXML and ArgoUML. Basically you use a modelling tool to create a .xmi file which ArchGenXML converts to an archetype product. This is not something I need to worry about in my weekend of plone, but it definitely is worth looking into when I do my customizations. (I found it awkward to create archetypes in a text editor or python IDE when I tried it before, but time will only tell what’s the best way to do this.

    Here’s written documentation about doing precisely that. Here’s the free ArgoUML modeling tool for creating .xmi files.
    In the meantime, here’s where I’m starting out for my laptop deployment.

    Why the sudden switch to doing plone stuff?

    1. I accepted a short term assignment where I was helping a technical writer document an Oracle-based product, and was already in the follow-the-directions/be-one-with-linux mindset.
    2. Because of said assignment, I was too tired at night to focus on my creative writing. (Translation: I’ve hit writer’s block, and this is kind of a distraction until my creative side recuperates).
    3. My pump for my exercise ball has still not arrived (and it is driving me crazy!)

  • Wiki Resources

    Ultimate Wiki comparison guide. Highly technical.

    Andrew Stellman on how managers at corporations can learn from open source project management.

    Andy Oram: Rethinking Community Documentation .

    On the post before this one, I’ve been gathering lots of useful ebook links.

    Uche Ogbuji develops in python and xml. Here’s his copia weblog which is far too esoteric for my terrestrial sensibilities. He’s written several articles about python and xml for the Oreilly website and I just now made the connecting between his consulting company and the 4-suite package for python.  Here’s a fascinating article Uche wrote about microformats. He talks about the limitations of microformats which he concluded were by design:

    One problem that the microformats technique doesn’t address at all is auto-discovery of semantics. You learn the meaning of the conventions in a microformat by reading the format specification. There are no shortcuts. If you come across a pattern in a host format that looks suspiciously like a microformat, you have no way of knowing what the microformat is for, and what its rules are unless you do some sleuthing with the help of your favorite search engine and find the spec. Even once you find the spec you almost always get an informal description of the convention. You don’t often get a schema, and you almost never get a schema structured enough to help automate processing of the format.

    This is one limitation that I think is the right choice for microformats. Discovery and semantics are very hard problems, and microformats would never have got off the ground trying to solve them any more than XML would have trying to solve the problem of semantic transparency as well as syntactic transparency. Microformats are rooted strictly to the syntactic realm, and those who do need more formality and structure can build these on the basics. In this article, I am sticking as much as possible to syntactic considerations with respect to microformats, but some of these considerations are related to semantics and are informed by how semantics might be mixed into microformats.

    He later talks about a initiative called GRDDL  (undertaken mostly by W3C staffers) to bind microformats to RDF models.

  • Pycon 3: Gadget Overkill

    I thought that bringing both my PDA and laptop to the Python conference was overkill until I ran into a man who brought 2 laptops and 1 PDA/Phone.

    “Having another laptop is convenient,” he said.  “That way, I can bring one laptop to a session while the other laptop is charging in my hotel room. And when my first one runs low on batteries, all I have to do is switch.”

  • Pycon Day 3: The Zen Nudge

    Last night, I was sitting around the conference lobby and overheard some people talking. One person was saying the conference was ok, though he’d heard nothing remarkable so far.

    Going to a techie conference can be a hit-or-miss thing. You never know what’s going to strike you, what’s going to be relevant. I’m reminded of a story of a Buddhist monk at a monastery who holds up a single finger during a talk, which mystified all the monks listening to him except for one, who immediately attained enlightenment. (Yes, Zen Buddhism is replete with these loony kinds of parables, something you don’t find so much in Christian scripture).

    I sat on several different sessions, none of which seemed to lift a finger for me. Actually during one of the plone tutorial sessions, the instructor  answered a question of mine with an explanation that only somewhat satisfied me, and then he mentioned a key phrase, “XML-RPC” which totally made me understand. Rather, I didn’t totally understand, but I understood what I needed to do to learn to craft a solution to the problem I was dealing with.

    Sometimes when working on a technical problem, sometimes all you need is a  nudge to  a solution. When asking a question in a forum or newsgroup, you don’t need a complete explanation, just something to look up. Often the problem is one of terminology. You want to do X. What is the technical term for this functionality so I know how to look it up in the documentation?  Sometimes you have an idea about how to do something, but then an experienced pro may have a different view of what the problem actually is. Also, in the open source world, chances are someone already has done a similar kind of project, so all you really need to know is that it exists somewhere, so you can search for it.

    Yesterday, I talked to one of the coauthors of Python Cookbook, a great book of recipes submitted by the python community that illustrate how to write in python. Programming books, typically are too abstract or deal with one example application that is discussed and extended throughout every chapter. (By the last chapter, you are sure to be sick of this movie database, online bookstore that was invented by the author. Recipes are smaller and more task-specific; plus you can see how problems can be solved in different domains (not only the ones of interest to you). When using a mature language like python, chances are you’re relying on standard libraries which provide domain-specific functions, so maybe you may never need to use the networking modules if you don’t touch this for example. But algorithms, tricks, shortcuts, organizational methods, all these things can be gleaned whatever type of problem you are trying to solve.

    I type this as I listen to Guido Van Rossum give his keynote address. Guido is the elder preist/benevolent dictator/code pope  of the Python language (now he works at google apparently).  Disciples listen and nod approvingly, but few understand the ultimate truth of it.

  • Python/Linux/Nokia

    For the record, my last day working at Texas Instruments was Tuesday. (more on that later).

    But I’m now at a session about python programming for Nokia cellphones. (Nokia was Texas Instruments biggest customer). Curiously, in this room, I bumped into about 5 different owners of Nokia 770 PDAs, a device which  I own also.  This device has lots of mindshare in the geek community, presumably more than the subject of the talk I’m attending. The neighbor next to me writes medical records applications for portable devices; the company he works for sees the advantage of writing something in an opensource environment.
    I’m agnostic about the companies I used to work for; I don’t make it a point to say great things or bad things about Dell or TI, but it’s great that Nokia has embraced the open source community so wholeheartedly.  A few years ago people were predicting that linux would become the OS of choice of portable/embedded devices, and lo and behind, a European country was the one to figure that out.

    Conference note: although Wifi provided by the conference hotel is adequate, the big limiting factor is power strips. About a third of the rows don’t have any access to power as we know it. In today’s keynote, I noticed about 200 developers all in one room, everybody with their own laptop (and  presumably checking email or their feedreaders during slow moments).  If I had a gun, and demanded that everybody hand over their laptop to me, I could become a wealthy man.