I’ve been wanting to return to active blogging and more frequent posting of photo galleries for quite some time now. The sysadmin/geek in me also wanted to completely overhaul the halfpress.com blog including finding a new approach to how my galleries are created. I also needed to refresh my approach to online photo sales, not just for the regular events I shoot, but to begin dabbling with the sale of some of my photos on an artistic basis.

The blog was originally hosted on my own server(s) using MovableType and a few layers of self-written Python code to support a database-driven, slideshow-capable gallery workflow. This approach became cumbersome after a while, namely once Lightroom came into my life and my editing workflow changed significantly (for the better).

the new halfpress

I’ve had cause in the last year to build other blogs related to my work and have taken a real liking to the modern WordPress. As a result, I’ve moved everything to one of my beefier, more modern Linux servers and ported all of my MovableType halfpress content to the latest release of WordPress. Once again, the sysadmin and geek genes in me have plans for some custom components, so I’m continuing to host on servers that I maintain from the physical hardware level on up.

Frederick Van Johnson turned me on to Graph Paper Press a year or so ago and I’ve been eyeballing their slick, media-centric WordPress themes for a while. I went ahead and subscribed to their service this past week and have started out with their ultra-flexible Modularity theme. There is a lot the theme can do that I haven’t implemented, and I might still dabble with some of their other theme lines or Modularity-parented variants. For now, this gets me going.

The last major element was the hosting of my photo galleries. This is one area where I have decided to move from my own servers to outside hosting. After some inquiries to my always helpful Twitter followers, I quickly landed at Zenfolio. Their system has great backend management, nice presentation and kills two birds with one stone for me: it serves as both an elegant portfolio site and a very capable photo sales site.

I do a good bit of event photography, some of which is annual (namely for my employer, Sweet Briar College). Since 2006, I’ve been selling those photos online with good success. My photo sales galleries were always a world all their own, disjointed from my workflow and galleries on the blog. I also periodically tossed random stuff on Flickr, but I’ve never been a fan of their user interface despite the massive community they represent.

Zenfolio provides me with an opportunity to put everything in one place using an interface that I really like, including a nice Lightroom plug-in by Jeffrey Friedl that massively streamlines my gallery creation. By placing all of my photos here and linking those galleries to my blog entries, I have a fairly transparent bonding of the two sites. I also have less individual sites to manage and an opportunity now to offer virtually anything – events or non-event artistic photos – for sale online.

I’m just now completing the initial blog move and Zenfolio configuration. There are still rough edges and lots of unexplored territory, so things will likely continue to change in the coming days. Since I ported all of my previous blog content, but haven’t been blogging much in the last two years, my front page will still have quite a few old entries. This gives me more incentive, however, to get some momentum and push those things off the main page by adding new content. One can hope.

the old halfpress

The old incarnation of halfpress is by no means dead (yet). While the content has been migrated to the new site, the old server is still in operation in all of its antiquated glory: http://archive.halfpress.com.

I’m open to feedback, which you can place in the comments on this post or tweet to me (@halfpress). I’m especially interested in comments on the site navigation, overall aesthetics and my choices of imagery for the slideshow, etc. Also try the small images you see in my posts (like the ones to the left and right of this text) – they should be clickable for enlargement and I’d like to know if they pop up cleanly for everyone. I’ve implement reCaptcha, too, in my comment system and would like to see it in action with users (I had this implemented on the old site, too).

Mobile users (iPhone, Nexus, etc): please let me know if the streamlined mobile version looks good. There is a toggle switch at the bottom of the mobile version allowing you to switch to the full site if your device is up to it.

It’s almost 4 AM and I’m going to be insanely tired tomorrow, so I’ll wrap this up, send out a tweet and hit the sack!

- Aaron

Here’s a nice article I spotted today in my RSS feeds that gives some insight into reCAPTCHA, the system I implemented here on the blog last week.
Enjoy!
- Aaron

P.S. Screw you, spammers.

NOTE: Needless to say, this post is entirely outdated now as of 3/6/2010 with my rebuild in WordPress. It’s here for historical reasons, though.

This is just a quick note to let everyone know that I’ve upgraded MovableType today to the latest version. The version I was running before was quite old and it’s been on my “to do” list for ages now.

There are new features I’ll try to utilize once I have time to explore them, but my goal for now was to not destroy the current site while gaining the ability to implement captchas on the comment system. Comment spammers have been hammering me to death for years and I finally hit my frustration limit. I’d call spammers the sub-human scum of the earth, but that would be an insult to scum. Scum serves more of a purpose and, as little as I appreciate scum, I respect it infinitely more than I respect spammers.

But I digress…

Anyway, I’ve implemented reCaptcha on the comment forms, so if you take a moment to leave comments on here, you’ll also be helping digitize books! As a Kindle owner, I appreciate your efforts.

More to come…
- Aaron

I’ve spent time over the last few nights focusing on the migration of my old MAME website to a new MAME blog appropriately called… well… mameblog.com.

I’m going to be doing a lot of photos of my arcades (inside and out) soon to update the documenation on those projects. In the process, I’m hoping to create content for both of these sites along the way: documenting the photographic techniques and experiences here, utilizing the fruits of the labor over there.

Fellow children of the 80′s: click on over to my other blog for a bit of nostalgia…

- Aaron

NOTE: All of this has been massively superseded (here in 2010) with WordPress and Zenfolio together with Lightroom. Again, I leave this here for “historical” purposes…

I’ve been working off and on for a week or more on a major workflow automation project for the blog. Let me start off by quickly pointing out what this means for the readers in terms of new features:

• Every photo gallery can now be viewed in either of two forms: HTML gallery or flash-based slideshow
• Links to both are embedded in the articles now as dropdown lists (“View photos as…”)
• The number of photos and pages (for the HTML gallery) are listed below the dropdown list
• An index of the galleries exists both in HTML and slideshow form
• The dropdown list below the random image in the top right of every page will take you to the indexes as well as the gallery categories
• The random image box in the top right by the banner now runs the slideshow or, if you don’t have flash installed, my original random image script requiring no plug-ins

So what’s the “workflow automation” all about? Well, generating galleries and linking them to a blog article is already a multi-step, albeit relatively easy, process. The addition of the slideshows, though, added a significant extra layer of work in the form of carefully structured XML configuration files. Since I want to be consistent and I don’t want a ton of extra work to stymie the urge to post new galleries, I figured it was time to streamline the process as much as possible. Past experience has told me that once the posting process becomes too complex, spur of the moment and casual posting grinds to a halt. I want the process to be trivial enough that I won’t have any excuses not to post more frequently.

The behind-the-scenes story of how this process works is, of course, disturbingly geeky. Fortunately, there are plenty of other fellow geeks out there that might be interested. The rest of this piece (and I predict it will be rather long) will cover the gist of what went into this project thus far. If the binding together of iView MediaPro, AppleScript, linux, OS X, ssh, scp, a big chunk of python code, MySQL databases and various bits of HTML and XML technology interest you… read on.
Here’s a linked list to the various tools and technologies use:

• iView MediaPro 3.02
• Mac OS X
• Fedora Core Linux
• AppleScript
• Python programming language
• MySQL Database
• OpenSSH
• SlideShowPro

Detailed description below the fold…

Background
In a nutshell, making a photo gallery for this site is a pretty straight forward process. I currently do all of my photo management with iView MediaPro on the Mac.

click to enlarge

It’s a fantastic piece of software, all in all, and I manage literally tens of thousands of images with it across multiple drives and servers. I use its templatable HTML gallery feature to generate the halfpress galleries. By doing this I have a consistent means of pushing any catalog I create in iView out with just a few clicks of the mouse. I generally just write them out to a specific directory within the structure of the blog and then code a link into the article.

The random image box at the top right of the halfpress pages was one of my earlier developments. Using iView’s Text Table feature, I could write out a text file in CSV format that contains the filenames, captions, etc., of the images in the current catalog. I would then feed that CSV file through a CGI interface I wrote in python on the halfpress server. This script would parse the data into a MySQL database that had all the information needed to build HTML links to the thumbnails and images in any gallery. The database doesn’t need to contain the photos… just the paths and filenames as they appear on the server. The little CGI script that selects images for the page simply makes a random selection of a photo from the database on each page load, builds the relevant HTML to display the existing thumbnail and embeds the image-specific link into the gallery. Voila… lightweight random images that are clickable taking you right into gallery it came from, and without duplicating any of the assets.
So, in a nutshell, the pre-automated workflow process was:

• Bring new photos into iVIew
• Sort photos and make selections
• Open photos from iView into Photoshop for editing
• Final cataloging of edited images in iView
• Generate HTML gallery with iView and write it via AppleTalk to the server
• Create a CSV dump of relevant catalog information from iView
• Feed the CSV file through a private CGI interface on the server
• Write the new blog entry and link to the gallery

Once I became attracted to using the flash-based SlideShowPro, though, the complexity went up a bit. Rather than go all flash, I want every gallery to be available in both forms so the user can choose what they like best. This means I do everything listed above plus create an XML configuration file for SlideShowPro that includes the somewhat complex, server-specific paths, captions, etc. I’d then be creating two links in the text to the two viewing options.

My first attempts at automating the XML creation became possible with the new iView MediaPro 3.0 release. It has the ability to not only write out XML dumps of catalog data, but also the option to template the XML via XSLT which is, basically, the CSS of the XML world. I wrote an XSL template that did much of the work of making a SlideShowPro configuration file, but it was still going to require per-gallery hand editing of the XML.

The Automated Workflow
Basically, what I’ve ended up with is a combination of AppleScript on the desktop and Python on the server with MySQL in the middle to hold the data.

Here’s how the process goes:

• A final catalog is created as per normal (import, sort, edit, caption, etc).
• I mark any photos from the catalog that I want included in the random image box pool with a ’1′ (red label) within iView
• I choose one photo to be the thumbnail representation for the slideshow index by marking it with a ’2′ (green label) iVIew
  

  click to enlarge

• I launch my AppleScript using iView’s scripting menu
• The script asks me for the directory name that should be used for the new gallery on the server (i.e. “st-thomas” for the Saint Thomas, USVI gallery.
  

  click to enlarge

• I’ve broken the logic of the workflow into stages. When making changes to existing galleries it might be more efficient or desirable to conduct certain parts of the process and skip others. The actions I wish to skip can be de-selected from the list before continuing. Correcting a typo in a caption, for instance, would only require the HTML Gallery, XML and parsing stages while skipping the redundant creation of slideshow thumbnails.
  

  click to enlarge

• The script now runs through the selected stages and ends with a dialog box notifying me of successful completion.
• The final step is to write the blog article. The photos are linked in by adding a single HTML server-side include (SSI) that injects the dropdown box with the image and page count automatically computed (the code is created by the server’s Python script described below). To continue the example from the St. Thomas photos, the include would yield this (with both javascript and non-javascript methods):

  <!--#include virtual="/galleries/st-thomas/include.html" -->

• Done.

Behind The Scenes: Desktop
What’s happening behind this script is fairly complex and, despite initial appearances, more stable than you might think.

The AppleScript does a series of things:

• Prompts for the ultimate gallery directory name on the server
• Prompts for the stages of the workflow you wish to conduct
• Builds a tree of folders on the desktop to hold the data on its way to the server
• Tells iView to build an HTML Gallery using a pre-defined option set for halfpress (template, etc)
• Tells iView to build appropriately sized thumbnails for the flash slideshow interface to match the catalog
• Tells iView to do a proper XML dump of the catalog data
• Because the line endings on the Mac don’t match the Linux standard, I call an awk script to rewrite the XML dump with proper CR/LF settings (irritating, but handy)
• SCP is called to transfer the XML file, thumbnails and HTML gallery to the server
• SSH does a remote shell call to the server to execute the python “parse” script

click to enlarge

This is my first hands-on experience with AppleScript and, frankly, I’m not especially fond of it. I spent a lot of time fighting with the syntax and screaming about the lack of coherent documentation. I think this is one of those cases where the “english” syntax is frustrating since I’ve already spent my life thinking in the more abbreviated, algol-ish, logic-driven syntax of various programming languages.

The use of SSH and SCP was a matter of convenience and relative security. I didn’t want to store passwords in any of the scripts, so I used the public-key, “passwordless” login capabilities of ssh to pull this off smoothly. I have it highly restricted, so I think it’s a sane tradeoff… not to mention everything is encrypted with 2048 bit keys. This is also testimony to the power of the UNIX underpinnings of OS X that I can call these tools without a second thought and interact with the Linux server transparently.

Behind The Scenes: Server
When I first started thinking this project through, I considered doing the MySQL work on the desktop side. I quickly decided, though, that I’d separate it out so only those actions most directly related to the desktop’s real role (photo management) would reside here and the rest would be done on the server. This also makes it more likely that everything will continue to work nicely when I’m traveling and behind bizarre proxies and firewalls that might crap out the MySQL connectivity. As it stands nows, if the SSH and SCP stages were somehow blocked when traveling, I can hand-execute the server side with a single statement once I get the files transferred by other means (FTP, for instance).

The server side of this process is all encapsulated in a fairly efficient Python application I wrote that manages all the file creation, filesystem manipulation and MySQL interaction.

The system is bound together with a core MySQL database consisting of two simple tables. One table contains a basic index of the galleries including the filesystem path, the formal gallery title and the comment that should appear in the slideshow index. The other table has an entry for every image in every gallery on the system including the filenames, paths, captions, EXIF data, display order within the gallery and a flag indicating whether a given image should be included in the random pool or not. Note that there are no images in the database itself… just references to the existing thumbnails and full sized images as they appear in the gallery. This makes it far more efficient on several levels.

Basically, every incoming gallery carries with it an XML dump of the catalog that contains everything I want to share: captions, EXIF metadata, etc. My python application, when called from the AppleScript system via SSH or on the command line, does the following:

• instantly drops any existing copy of a gallery by the same name from the database to avoid needing to do comparative updates
• Using python’s xml.dom.minidom library, it parses the XML output from iView and extracts a pre-defined series of fields that I wish to store in the database:

click to enlarge

• EXIF-formatted dates are parsed into more traditional, readable date formats for use in the captions
• ID numbers are cleared and re-assigned across the entire contents of the database to assure there are no gaps for the older random number script’s selection logic
• Any images with the random flag are selected from the database and an XML file is generated to drive the new random instance of SlideShowPro that appears in the top right of every page
• Attention then turns to the new incoming gallery that triggered the python application call. This includes writing out a gallery-specific XML file for SlideShowPro complete with with links, captions, thumbnail references, etc.
• Case is changed on the filenames where required on thumbnails generated by iView and symbolic links are created within the filesystem to common HTML files shared across the galleries
• The number of images in the gallery is counted from the database and divided by the standard number of images per page that I use in my template. The floating point comparisons are done to determine the page count
• A small, gallery-specific bit of HTML is written out containing the javascript and non-javascript links to call the gallery from the articles. Also included is the text with the image and page count. It is this little HTML file that is pulled into the written articles with a server-side include to provide the dropdown box for selecting the gallery style
• Finally, a master XML file encompassing all of the galleries is written out. This file is the one that drives the all-encompassing instance of SlideShowPro with its own internal, thumbnailed index. This allows the user to peruse all the galleries via SlideShowPro and complements the blog’s native HTML gallery index
  
  

Notes and Comments

As with any system like this, the design is predicated on a consistent layout to the filesystem. Everything is stored in a standardized format within the core database and, because the filesystem is laid out in pre-defined manner, HTML links and other references can be built on the fly by the python script for use in the XML and the server-side includes.

Since all the galleries exist within a certain directory, all that is needed to be known is the name of the enclosing directory and the individual names of the images within. The thumbnails and full-sized images use the same filenames and are stored in parallel directories and scaled to their required sizes. Since iView puts out its HTML Gallery using a set layout, a single filename reference in the database can yield either the thumbnail or the full-sized image just by pre-pending the enclosing directory names.

In the St. Thomas gallery, for instance, image “_mg_1346.jpg” is stored in the database with a gallery name of “st-thomas”, its relevant caption, EXIF data, etc. A reference to this file in any of its incarnations is easily built as follows:

click to enlarge

• Thumbnail: /galleries/st-thomas/preview/_mg_1346.jpg
• Full Image: /galleries/st-thomas/source/image/_mg_1346.jpg
• HTML Gallery Entry: /galleries/st-thomas/source/_mg_1346.html
• HTML Gallery Index: /galleries/st-thomas/
• Gallery Slideshow: /galleries/st-thomas/slideshow.html
• XML Catalog Source: /galleries/st-thomas/catalog.xml
  (view source in Safari)
• XML Slideshow Source: /galleries/st-thomas/images.xml
  (view source in Safari)
• SSI Code-Snippet: /galleries/st-thomas/include.html

SlideShowPro, as stated before, is a flash application that gets it marching orders from an XML configuration file. I’ve described aboved how the XML files are generated based on the consistent design of the filesystem layout and HTML gallery assets.

I’ll mention that I have at least three copies of the SlideShowPro app “published” from Flash Studio 8.0 to fit each need: the random slideshow, the master slideshow gallery with index, and the individual gallery slideshows. The individual galleries share a single instance of the swf file and read the XML file based on a path-relative call.

Closing Thoughts

To summarize, my workflow is now:

• Make the catalog
• Run the script
• Write the article
• Embed the single line server-side include to link to the gallery options

That’s pretty much it. All of the galleries, random images, slideshows, slideshow indexes, etc., take care of themselves as a result of the script(s). I can focus on shooting, editing and far less on gluing the blog together.

Over time I’ll continue to test, tweak and likely make changes to the overall design. This is just the first functional incarnation of the concept and it will probably improve over time. I don’t claim that the code is the most efficient thing on the planet nor do I assume the overall design is nearly as ideal as it could be. That’s half the fun, though, since there are a zillion ways to approach any one problem with these kinds of tools.

If anynone has any questions or comments, don’t hesitate to email me or use the comment fields below.

No, I haven’t passed away and halfpress.com isn’t dead either. Life has been Busy with a capital ‘B” lately. I’ve got a lot to write about, actually, and want to do the various topics justice in the coming days. Among the various things going on has been the completion of my second MAME arcade (details on the first one here), the installation of the DS3 circuit upgrade I ordered last November (long, sordid story), and a handful of other things I’d like to share, vent about or otherwise blognosticate upon for a while. I’m just trying to catch my breath right now.

Regarding the MAME machine: I’m in the process right now of getting another blog set up to house the information (I’ll RSS-crossfeed it with this blog, too). My plan is to migrate all the content from my previous MAME arcade site to the new MovableType installation I just completed a few minutes ago. Once I get the new look for it in place and the content migrated, I’ll link it to the world and begin the process of documenting the building of the new machine. It’ll take a few days, so bear with me… I’ll also be co-authoring the site with my good friend and other local MAME afficianado, John Coleman. I’m getting ready to do the Linux work for him on his partially-finished CPU and we’ll document his project on here as well. We’ve got big plans.

As for the DS3… information on all the facets of that project are for another post that I’ll get around to writing soon. The dust is still settling, but the impact of it has been tremendous in many (positive) ways. You should undoubtedly be seeing a vast improvement in how fast this site comes up compared to just over a week ago. More on that later…

For now, I’m off to finish tinkering with the guts of the new MAME blog and catch up on last night’s episode of Rome which I missed since I was… well, tinkering with MAME again.

Oh, and the new MAME blog is running on MovableType 3.2, so I felt compelled to do the update on here as well. So far as I can tell, it didn’t eat halfpress. If you hit any pages, though, that seem borked, don’t hesitate to let me know so I can fix them. I still have some new features to explore and possibly implement in the coming days.

NOTE: This is the original “about” from halfpress.com. I’m replacing it with the blog update, but leaving this for “historical” purposes…

Half-Press, halfpress, 1/2press?

Eh… doesn’t much matter how you write it, I guess. I tend to find halfpress to be the easiest one to type out of the bunch. (halfpress.com, halfpress.net, half-press.com and half-press.net will all get you here, by the way.)

What is it, though? It’s my personal, relatively photo-centric blog.

Why should you care? No reason, really… unless you’re a friend, a family member or just happen to be interested in any of the things I might write about, rant about, photograph or otherwise toss out for the world to see. It’s all about thinking out loud, sharing information and, from time to time, accidentally creating something that might prove useful (or serve as a warning) to others.

I guess it’s about time I finally made a personal site on the web considering I’ve been ass-deep in Internet-centric resources (bandwidth and Unix servers galore) for much of my life due to my profession. While I’ve put quite a few topic-specific sites on the net for one reason or another over the years (my MAME’d Millipede project and political blog, for instance), I just never got around to creating a personal site that I felt I’d be inclined to maintain in the long run.

A little background…

For the last twelve years I’ve worked for Sweet Briar College as the Director of Network Services. Despite the somewhat specific, administrative sound of my title, my actual role is pretty broad and quite to my liking: network and infrastructure geek.
I’m kind of the hands-on “guy behind the scenes” dealing with most of the servers, the physical network, security, and anything related that beeps, blinks or relies on the flow of electrons to do its job. I’m one member of a pretty decent sized team (considering our relatively small size as far as colleges go) that handles everything related to computing on the campus.

My job keeps me knee-deep in Linux (my workhorse OS of choice), the usual Cisco routers, switches, DS1 and DS3 circuits, copper, fiber, wireless devices, a fair amount of programming (it’s all about the Python, baby!), and a great deal of freedom to explore new technologies that might help chart our digital course as an institution.

In the last year or so, I’ve also starting doing a tremendous amount of contract photography for the college as well as outside groups, have become editor and animator of a growing Art History podcast (iPod / HD feeds), and am dabbling far more seriously now in the 3D world that has fascinated me since I was a kid (check out Modo if you haven’t already).

Small colleges tend to be fascinating, diverse little worlds unto themselves with a strong sense of community. This is especially true when they are fairly rural, as is the case with Sweet Briar here in central Virginia. Fairly conservative Lynchburg is ten minutes to the south, comparatively (and refreshingly) liberal Charlottesville (home of UVA) is 45 minutes to the north and the rest of the world mere milliseconds away via the Internet. Throw in beautiful, mountainous geography, a lot of historical significance (heavy on all things Jefferson) and you’ve got a general sense of where I live.

Why?

The urge to create this blog stems from recognizing that the overlap of my professional skills, work environment, social scene and various hobbies generate a lot of thoughts, anecdotes and experiences that I’m increasingly keen to share. Oh… and photos. Lots and lots of photos.

A few years ago, a person in my line of work might be able to say that one of their non-computing related hobbies was photography. No more. Today, photography is so heavily dominated by ever-improving digital technology that photographers are rapidly becoming computer geeks and computer geeks are finding it less of a stretch to become accomplished photographers.
I’m speaking purely from a technical perspective in that last statement, of course. The real joy (and success) in photography lies in the creative outlet it provides, not to mention the challenges involving timing, precision, resourcefulness and myriad other skills. Luck is a big factor, too.

Of course, having a passion for photography is made all the more fun by sharing your creations with others. Being both a computer geek with resources and a photography addict leads to the inevitable: using your blog to share your photos and using your photos (and photography-related experiences) as a topic upon which to blog.

So, getting back to the point of this relatively pointless ramble…

What is a “half-press” and why use it as a domain name for a blog? There are a few answers to that question.

Since photography is something I enjoy immensely and it was going to be a key focus of the blog, I decided to seek a name that was, at the very least, suggestive of photography and could have some possible double meanings in other contexts.

A sidenote regarding domain names:

If you ever want to experience the equivalent of slamming your head in the car door repeatedly but wish to forego the cranial hemorrhaging, try to register a clever (or simply descriptive) domain name. Be sure to look for something related to a specific, popular topic (like, say, photography). Start with the obvious words and then make it increasingly obscure with your repeated failures. Yep, even the obscure ones are taken. So are the VERY obscure ones.

Rest assured, pretty much anything you really like is already registered. Be sure to also look to see how many of them are legitimately in use versus the number of names being held by opportunistic squatters. They paid the $7.95 you should be paying in hopes that the name is important enough to you to cough up what amounts to ransom ranging from hundreds to, literally, hundreds of thousands of dollars.

The website at the name you want, if owned by a squatter, won’t have any useful content. It’ll most likely just be a self-promoting advertisement letting you know that somebody beat you to the punch… but not to be creative, helpful, or informative. No, they just got “firsties”. “Beat ya to it! Want it? It’s gonna cost ya!”

Go ahead and bang your head randomly on the keyboard and submit the resulting gibberish. Yeah, it’s probably already registered, too.

Bottom feeding bastards. Ask me sometime how I feel about spammers, by the way.

Halfpress came to me after, literally, days of playing this game. I don’t know whether it wasn’t taken already due to some cosmic accident or because it’s just freakin’ stupid enough that nobody else wanted it. The more I pondered it, though, the more I liked it.

The name rolls off the tongue in the same manner as other sites I admire, like Slashdot.

It has relevance to photography. A “half-press” is what you do with the shutter button on most cameras to lock the exposure, focus, or both while composing a shot. The half-press is a significant step in the composition process (psychologically and physically) that usually comes in the final moments before you turn a living, possibly fast-moving scene into a frozen, timeless photograph. There is something about that moment in time that I find intriguing.

On a slightly more obscure note, “half press” is something of a play on words related to the blogging world in general. I take this view particularly from my involvement (however limited) with blogging politics. The constant debate over the role and “legitimacy” of bloggers in the journalistic and media world is pretty intense. Some of it relates to a collision of communities (one established, one emerging) as well as real issues concerning ethics and bias.

Assuming (which I do) blogging is at least halfway legitimate in a journalstic sense, “half press” is a tongue-in-cheek reference to its stature in comparison to the established “real” press.

Maybe that bit of “cleverness” is exceedingly corny or obscure, but I personally find it amusing nonetheless. Your mileage may vary.

Whatever the case, I’ll be working to make this blog my home on the Internet and I hope others find it useful, entertaining, or at least worth the bandwidth it takes to give it a casual poke with a virtual stick from time to time.

Enjoy!

- Aaron Mahler