Storing Art Safely
Earlier today I had a brief Twitter conversation with John Resig about storing art, specifically prints. I thought I'd share a few additional thoughts that didn't quite fit into the space of 140 characters.
Disclaimer: I'm no conservation expert and my art isn't particularly valuable. If in doubt, consult a pro.
The best method, I think, is to have your prints archivally framed and hanging on the wall. You can enjoy them and they're relatively safe from damage. Unfortunately, framing is expensive and we only have so much wall space.
Although it's common practice to ship prints in tubes, you should store them flat if at all possible. It's almost always possible to flatten out a print, but in my experience the paper tends to develop a memory. The longer it's rolled, the harder it is to flatten out without developing waves or ripples.
The obvious storage solution is a flat file cabinet. They make it very easy to simply lay the prints in the cabinet and be done with it. However, flat files are big, bulky furniture. The biggest commonly available size is 36" x 48", which is a lot of real estate in your room. And remember, that's the outside dimension — the largest print you can accommodate will be more than an inch smaller.
Flat files are also fairly expensive, though careful shopping on Craigslist or the like may turn up something useful.
All that said, if you can swing a flat file, it's the way to go for safe, bulk print storage. I love mine.
Within the cabinet, some folks like to store prints in mylar sleeves. I tried this route and found the hassle and cost outweighed the utility: the sleeves don't always lie entirely flat and I couldn't stack prints without inducing some waviness in prints on lighter-weight paper.
I ended up taking the prints out of the sleeves and instead simply place prints on top of each other, alternating with sheets of acid-free blank paper.
For prints up to 24" x 36", art portfolios with slip-in sleeves work great for storage. The stiff covers provide good protection for your prints, but make it easy to page through and admire your collection. They also can slip under a bed or, if you're careful, lean against the back of a closet. Watch out for pests and spills, though.
I like the Itoya 18" x 24" Profolio and Profolio Evolution. This is a common size for gigposters, so the vast majority of my collection fits in these easily.
There are bigger portfolio cases. I have a 24" x 36" Stein deSign Picturesque Presentation Case. Pricey, and only comes with 5 sleeves, though you can expand up to 20 sleeves with "refills". On the other hand, it's a very sturdy alternative to a flat file for storing larger prints.
You may also be able to find fold-over artist portfolios in even bigger sizes. They don't typically have sleeves to help organize your prints or hold them in place, so you need to be careful about handling. Look for acid-free materials.
I have a few really long prints that don't fit in any of the commercially available, affordable solutions. So I made my own folders — basically a variation on the fold-over portfolio.
Get some 40" x 60" acid-free foam core boards and some acid-free hinging tape used for framing.
Put two boards on top of each other and tape one edge together, creating a hinge.
Carefully place the prints between the two boards. For added peace of mind, you might want to temporarily mount the prints on heavy acid-free backing paper using framer photo corners or clear mounting strips.
Hold the entire thing closed with big-ass rubber bands or similar. Handle the whole thing carefully — contents are likely to shift.
Get Your Own Art
Hand-made prints — screen prints, woodblock prints and lithographs, usually — are a great introduction to the world of art collecting. There's something everyone. I really like Andy Warhol's Cow Wallpaper, but that's not going on my wall any time soon.
Instead, I accidentally fell into the rock art gig poster scene. You can learn more about it at gigposters.com and Expresso Beans, two of the more active communities for artists and collectors.
John, by the way, has his own fascinating site cataloging Japanese "Ukiyo-e" woodblock prints.
Full disclosure: some of the links on this page are Amazon affiliate links and I could receive a payment from them for any purchases you make during a shopping session initiated via these links.
Return of the Jedi Remembered
30 years ago today, two friends and I ditched school to see the very first screening of Return of the Jedi on its opening day on the biggest movie screen in the county. It turned out to be a significant day in ways I didn't suspect at the time.
I was a freshman in high school. My friends and I had been, of course, huge fans of the Star Wars franchise since the original movie, 7 years before. In many ways it had become the core of a SciFi and Fantasy obsession dating back even further, fueled by books, magazines like Analog, Starlog and Heavy Metal and the old movies featured by Bob Wilkins on his Saturday evening Creature Features show.
Significant anticipation had built up over the resolution of various plot lines left hanging in The Empire Strikes Back. Is Darth Vader really Luke's father? Will they rescue Han from Jabba the Hut? And who's this Boba Fett character?
We couldn't wait to find out, and dared not run the risk of someone spoiling the surprise. And besides, we were old enough now to see the movies alone. No need to wait for our parents this time.
In those days I didn't yet have that coveted driver's license, but we did have the wonderful freedom of our bikes. I frequently rode the 4 miles between home to school. So on that Wednesday afternoon 30 years ago, my friends and I ducked out at lunch, grabbed our bikes and pedaled over to the big "dome" theater in Pleasant Hill to catch the very first showing of Jedi in our town.
It seemed like such a caper at the time. I'd never really been one for breaking the rules, and recall looking over my shoulder several times, half expecting an army of Assistant Principals and Truant Officers to be chasing after us like in The Great Escape.
In reality, I don't think anyone noticed we'd gone. I certainly don't recall any disciplinary fallout from that afternoon.
We arrived at the theater and found a small group of people waiting. Not a huge crowd, but we weren't the only ones hoping for another grand installment in the story of Luke, Leia and the rebellion. We bought tickets, soda and popcorn, debated the best place to sit — we had most of the huge theater to choose from — and settled in for the coming attractions to roll.
The movie itself was great and fulfilled many of our hopes, until... the Ewoks. I remember thinking "Teddy bears? WTF?"
The rest of the movie wasn't a total disappointment. I mean, the showdown between Luke, Vader and the Emperor was pretty badass. But that's followed up by the uncomfortable makeup scene between Luke and Fat Vader, the Ewok hoedown, C3PO telling stories (badly I might add) and the bemused Jedi ghosts. (Let's not even get started on the whole Hayden Christensen thing... that was a disappointment yet to come.)
By the way, here's 30 things you probably didn't know about Return of The Jedi.
At the time I probably felt somewhat betrayed by the trite ending and the indignity of a fat bushbaby tribe saving the rebellion. But I soon came to realize something else: George Lucas wanted to keep Star Wars accessible to children. And I was growing up. In some sense I'd moved on and realized these movies weren't necessarily for me anymore. They were maybe for George Lucas or a new generation of kids or, anyway, people who were less snooty and cynical than this teen-aged cineaste was becoming.
(Ironically, I unintentionally ended up seeing The Phantom Menace on opening day 16 years later, but that's a story for another day.)
The Star Wars saga no longer holds the position in my life it once did, but it still maintains a place of respect in my pantheon of great stories. I've seen all the films so far, if only out of curiosity, and look forward to JJ Abrams' interpretation of Episode 7, lens flare and all.
I read and highly recommend Michael Heilemann's Kitbashed blog, dissecting the creative work of George Lucas and the influences remixed into the Star Wars universe. It's a very grown-up look at myth, film-making, creativity and what it means within our cultural heritage. From Kitbashed I learned of this excellent Michael Kaminski article In Tribute to Marcia Lucas from The Secret History of Star Wars, which outlines her significant contributions to George's work through Empire (and perhaps why Jedi missed the mark).
As if to underscore the fact that Star Wars remains part of my childhood, that theater where we first watched Jedi shut down in late April and was demolished two weeks ago. Like many other landmarks of my youth, it's gone forever. But I have fond memories.
And the original theatrical releases on DVD.
Cross-platform Text Editing in 2013
Update 2/22: Revised to address bug fixes in TextDrop. See my notes below.
In 2011, I wrote a post about Crossplatform Note Sync with Dropbox. For the most part, the workflow and apps I wrote about still work well. However, times change I thought it would be a good idea to go back and check on some new developments, both platforms and tools, that may give you some new note-syncing options.
In a few cases, new features make this workflow even more flexible. For example, Elements now allows you to select which folder it uses for syncing files.
Dropbox has much more flexible options for sharing files and folders. There's also a revamped iOS client and a client for Windows 8, but not for Windows Phone 8.
One new development the deserves a look is TextDrop, an online text editor for Dropbox.
TextDrop is a web app that lets you access your Dropbox folder and edit, in the browser, any text-based document there.
I learned about TextDrop from Gabe Weatherhead of Macdrifter, who's written some great introductory posts about it, most notably here and here (plus an interview with TextDrop developer Sam Nguyen that's worth a read).
There's not much to the app: one pane shows the contents of the current Dropbox folder, the other lets you view and edit the selected file. It provides minimalist text-editing features, plus MultiMarkdown preview.
There are options for enabling hard tabs, non-text file previews and full-text search. That's pretty much it.
The good news is that TextDrop works fine in some popular desktop browsers, specifically Chrome, Firefox and Safari. TextDrop also works in Mobile Safari on the iPhone and iPad, though the site is a bit too cramped for regular use on the smaller phone screen.
The not-so-good news is browser compatibility. IE 6 and 7 are not supported by design,
and I couldn't get the site to load in IE 9. Google Chrome Frame might help. Windows 8 is not supported. No joy in Opera, either. The site does load on Mobile Safari, but it's marginally useful at such small screen sizes.
Update: After a recent update to TextDrop 3.8.3, the site loads and works correctly in IE9. I haven't tried IE10 yet.
TextDrop is priced on a sliding scale, the actual subscription price rising a small amount with each new user. This is similar to the pricing scale used by Pinboard.in. You lock in a yearly subscription fee based on current price when you sign up.
I purchased a subscription (at around $10) because TextDrop does add some helpful flexibility to my writing work and I want to support Sam's continuing development of the app. The price recently jumped to almost $30.
Is TextDrop valuable at the current price?
If you work mostly within the toolset currently supported — namely, Chrome, Firefox and Safari — TextDrop can be quite useful. Once authorized, your documents are just a browser bookmark away, wherever you may be working.
Although TextDrop has some missing spots in its compatibility checklist, it does cover the most popular platforms. Expanding compatibility to Windows 8 and Windows Phone 8 could win TextDrop some vocal supporters. On the other hand, improving mobile compatibility and expanding the editing capabilities probably addresses the needs of a larger user base. I'll be watching with interest.
Update: It's worth noting that Sam is making regular updates to the service and making changes in response to user feedback. Not only did he fix the IE9 loading issue within a week of my pointing it out, but he also fixed a minor tab-spacing bug as well, among other things. This is the kind of service where your subscription dollars are really going to support the work of an independent developer, who in turn is working hard to address the needs of his paying customers. I like it.
The State of Things
TextDrop aside, how has the cross-platform document editing scene changed since I wrote about it in 2011?
Dropbox seems to have become the most reliable and flexible service for syncing your data, reinforcing the reasons I settled on it in the first place.
Apple's iCloud service still isn't ready for prime time and is, anyway, currently restricted to Mac and iOS.
Microsoft's SkyDrive service offers cross-platform syncing, including Android, iOS, Mac and Windows/Windows Phone clients.
There are two reasons I'm wary of this service. First, given the history of support for now-defunct sync services like FolderShare/LiveSync and Live Mesh, I wonder how long SkyDrive will stick around.
Second, you have to wonder about support for competing platforms with Apple reportedly rejecting updates to Microsoft’s SkyDrive iOS app.
Text editing apps have proliferated. I run Sublime Text 2 on all my desktop systems — Linux, Mac and Windows. For iOS devices, Brett Terpstra has compiled an extensive list of iTextEditors - iPhone and iPad text/code editors and writing tools compared. I'm still happy with the latest updates to Elements.
I'm less familiar with the Android text-editing scene, but LinuxLinks has a roundup of the 8 Best Free Android Editors. Here's another Minimalistic Text Editor for Android, though I've seen a few forum posts recommending vi. Seriously.
Code-focused editors are another, more specialized category. I'll be looking into that soon...
Terms of Service
Updated below on 1/3 and 1/16
Online services are going to steal all of our content and use it to enrich themselves. Or maybe they're not. It makes for great paranoid headlines whenever a popular site updates their terms of services, but what's really happening here?
IANAL and have no particular expertise in the areas of IP law, so you'd be wise to rely on your own judgement and the advice of an attorney rather than my insight. However, I think there's a lot we can learn from a close reading of actual terms of service and a little common sense.
I was inspired to write about this by a tweet from Hal Berenson, linking to a post by Bruce Schneier, suggesting that, if you "Store something in the cloud... the cloud service owns it."
Schneier mentions the recent dust-up about Instagram's terms of service, and if you've been paying attention, you also know that Twitter, Facebook and other services have faced similar controversy over their TOS language.
The general uproar is something along the lines of:
"OMG ALL YOUR CONTENT ARE BELONG TO [service du jour] AND THEY CAN DO ANYTHING THEY WANT WITH IT!"
What's this all about? Why is [service du jour] suddenly stealing everyone's photos, wry observations, presentations or whatever? And what are they going to do with all this booty?
All Rights Reserved
The problem rests in some fundamental misunderstandings about how we use copyrighted works.
When you create something — write a tweet or a blog post, take a photo, sing a song and so on — the copyright for it is granted automatically (and in most cases, to you... though there are exceptions). If someone else wants to use it, they need your permission: you can grant a license for them to use that writing or photo or song under certain conditions.
And that's exactly what's happening here. You take a photo. You have a copyright on that photo. You upload it to Instagram. For them to do anything with that photo, you need to give Instagram permission — a license — to reproduce your copyrighted content and save a copy on their server.
Say you want Instagram to let your friends see the photo. You're smart and know how computers work; think about the further consequences: Instagram has to make and distribute copies of your photo for each person who wants to see it. Maybe they distribute files around to servers for load balancing or CDN-style distribution. More copies. Hopefully they back up your data. More copies.
They need your explicit permission to copy and distribute your copyrighted work.
Of course, lawyers being lawyers, and corporations being corporations, they use very-broad-and-yet-very-specific language to cover their asses in all the ways they can possibly think of, plus a few ways both you and they haven't imagined yet.
So you end up with terms of service language that sounds like OMG ALL MY FILES BELONG TO...
Take a deep breath. Maybe it's not that bad after all.
In a previous life, part of my job involved proofreading EULA text for software installers. Yes, it was dull. But, the benefits! If you'd ever read through all of a EULA, a rental or mortgage contract or any similar legal document, you'd know that most of the language looks remarkably similar from one contract to another... it's boilerplate. Why reinvent the wheel? If it works in one situation (and holds up in court), use it again and again and....
In order to provide you with the Service, it is necessary for you to grant Prezi certain licenses to your User Content.
With respect to Public User Content, you hereby do and shall grant to Prezi (and its successors, assigns, and third party service providers) a worldwide, non-exclusive, perpetual, irrevocable, royalty-free, fully paid, sublicensable, and transferable license to use, reproduce, modify, create derivative works from, distribute, publicly display, publicly perform, and otherwise exploit the content...
(My emphasis here and throughout, by the way, unless otherwise stated.)
That sounds pretty sinister. Promising to "exploit" is rarely a great way to make friends. In addition, Prezi requires you to grant a similar license to anyone who views your public content:
When you upload User Content on or through the Service, you also hereby do and shall grant to each user of the Service with whom you share your presentation a personal non-commercial non-exclusive license to access and view your User Content.
Yikes! What are they doing with my presentation?
But hang on. Think back to what I metioned earlier. They need your explicit permission to make any copies of your content that live on their servers or move around their service, any copies displayed to other users of the service and any copies needed for features of their service they haven't implemented or even thought up yet. That is what your "worldwide, non-exclusive, perpetual, irrevocable, royalty-free, fully paid, sublicensable, and transferable license" enables Prezi to do without fear of being sued for copyright infringement.
I mentioned my interpretation of the license terms to Hal, who replied that "Microsoft has no rights other than those necessary to operate [the] service", offering Microsoft's terms of service as a counterexample to Prezi's.
It's a fair point to the extent that Microsoft Services Agreement section 3.1 does explicitly state "[W]e do not claim ownership of the content you provide on the services. Your content remains your content...."
I believe that to be entirely true and put in fairly straightforward terms. Further, they make the entirely valid point that other people may see, save and reproduce copies:
If you share content in public areas of the services or in shared areas available to others you’ve chosen, you agree that anyone you have shared content with may, for free, use, save, reproduce, distribute, display, and transmit that content in connection with their use of the services and other Microsoft, or its licensees’, products and services. If you don't want others to have that ability, don't use the services to share your content.
However, if we read a bit further, we'll see something a bit more like that Prezi license language start to show up:
When you upload your content to the services, you agree that it may be used, modified, adapted, saved, reproduced, distributed, and displayed to the extent necessary to protect you and to provide, protect and improve Microsoft products and services.
...you are granting Microsoft, its affiliated companies and necessary sublicensees permission to use your Submission... including, without limitation, the license rights to: copy, distribute, transmit, publicly display, publicly perform, reproduce, edit, translate and reformat your Submission... and the right to sublicense such rights to any supplier of the Services.
For better or worse, you're going to see language like this being used by pretty much any significant player in online or cloud services.
Here's Twitter's version, under the section helpfully titled "Your Rights":
You retain your rights to any Content you submit, post or display on or through the Services. By submitting, posting or displaying Content on or through the Services, you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute such Content in any and all media or distribution methods (now known or later developed).
As the tip on the page notes, "This license is you authorizing us to make your Tweets available to the rest of the world and to let others do the same."
Let's take a look at Facebook's Statement of Rights and Responsibilities, under "Sharing Your Content and Information":
You own all of the content and information you post on Facebook, and you can control how it is shared through your privacy and application settings. In addition... you grant us a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content that you post on or in connection with Facebook (IP License).
Or maybe you should check out the "Your Content in our Services" section of Google's Terms of Service:
Some of our Services allow you to submit content. You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours.
When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works...communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones.
It's a little harder to find (conspiracy theory anyone?), but Apple's iCloud Terms And Conditions aren't much different:
Apple does not claim ownership of the materials and/or Content you submit or make available on the Service. However, by submitting or posting such Content on areas of the Service... you grant Apple a worldwide, royalty-free, non-exclusive license to use, distribute, reproduce, modify, adapt, publish, translate, publicly perform and publicly display such Content on the Service...
Birds do it, bees do it. Everybody on the web seems to do it. Let's do it. Let's accept that these license terms are basically industry boilerplate and move on.
Fox In The Hen House
Just to be clear, I'm not trying to belittle the comments made by Hal or Bruce... or anyone else who has concerns about this widely used, easily misunderstood — and perhaps easily abused? — licensing language.
I believe it is essentially boilerplate and meant to cover legitimate business use of our photos, videos, jokes and memories. Thus far, I can't think of any businesses that have, in fact, appropriated user content for reasons not intended by the user. And given the backlash resulting just from the suggestion that it might happen, I can't see why any sanely run business would try to do so.
But the ideas that are unacceptable today may become more acceptable tomorrow. Perhaps a future startup tries explicitly employing user content as part of its service, creating a wedge that makes the practice tempting where it was previously taboo. Of course, people tend to do stupid things, so maybe it's just a matter of time for someone to exploit this broad licensing language, consequences be damned.
In the meantime, the bold headlines seem more click-bait than Cassandra.
Update: Well, well, well... Ryan Singel points out that BuzzFeed is already raising significant investment funding on a "biz model of willful copyright infringement." Sure, they're taking liberties with photos folks have posted to other services — you haven't licensed them anything — but is this the "wedge that makes the practice tempting where it was previously taboo," or an outlaw site, doomed to failure?
My point stands, however: these terms of service aren't the problem (yet). Bad actors are.
Update 2: Today Reuters reports that News outlets improperly used photos posted to Twitter. According to the story, a reporte at Agence France-Presse took photos that photographer Daniel Morel had posted on Twitter, used them in an AFP story without permission, then passed them on to Getty Images, from whom the Washington Post procured the images.
AFP had argued that Twitter's terms of service granted it the right to use Morel's images.
The judge, though, said that while the service terms do allow the reposting and rebroadcasting of users' images in certain circumstances, such as "retweeting" them, it does not grant a license for commercial use....
Twitter was not a party in the case. "As has always been our policy, Twitter users own their photos," a Twitter spokesman said.
As before, I think this is a case of misappropriation — and a journalist at an organization of this stature should really know better.
Apps of 2012
2012 was the second full year back using a Mac as my full-time work machine since the mid-90s. The transition from Lion to Mountain Lion hasn't been smooth as I would have liked, but it's still a nice place to get some work done.
In theory, I don't need many tools to get my daily work accomplished: a browser and a text editor handles 90 percent of my needs. Nonetheless, it was interesting to look back and think about the tools that did end up being used on a daily basis.
On Mac OS
My most-used machine is still the 2010-vintage Mac Mini I purchased used two year ago. I'm using it with a Filco Majestouch-2, Tenkeyless keyboard and Apple Magic Mouse. The displays are an old 23" Sony IPS monitor and an even older 20" Samsung.
Chrome is my current go-to browser. Fast and flexible makes up a great deal for horrible memory hog.
Template is a Chrome extension written by Alasdair Mercer that I use extensively for quickly grabbing information about a web page that I can then paste as formatted text into other documents.
Instapaper and Pinboard are my preferred bookmarking/read later services.
TableTools2 is a handy Firefox add-on for grabbing data from HTML tables and pasting it in CSV format. It does other tricks, too.
Sublime Text 2 is my text editor these days. It works enough like TextMate that moving over was a breeze, and now I have a consistent text editing experience across my Linux, Mac and Windows machines.
Reeder is my RSS client of choice, providing a much better window for keeping track of the feeds in my Google Reader account.
TextExpander holds boilerplate bits and pieces of text that I use frequently, and also has the ability to run scripts that grab and insert data on demand. Priceless! Pro tip: start your snippet abbreviations with a semicolon and you'll never have to worry about premature expansion.
Alfred App mostly gets used as an app launcher, but I've slowly been adding extensions (including a few of my own) to automate CLI-like file creation, tweeting, data conversion and other operations. Another can't live without app now.
Witch is Commmand-Tab task-switcher that's a huge improvement over the default Mac OS feature. I have it set up to work much more like the traditional Windows Alt-Tab functionality of switching between open windows.
Marked is a great app for creating previews and HTML markup of Markdown documents. Created by Brett Terpstra, who's also behind nvAlt, which I use for Crossplatform note syncing.
1Password keeps track of my passwords across iOS, Mac and Windows, and also provides great tools for creating new, strong passwords.
Twitterrific is my preferred Twitter client on both iOS and Mac OS thanks to the unified timeline and being just generally easier to read than other clients I've tried.
Dropbox is my primary tool for sharing important data across devices as well as providing a first line of backup, along with Time Machine. I also use SuperDuper! as a secondary on-site backup and CrashPlan for off-site backup. Yes, I'm paranoid about backups.
µTorrent is my (very) tiny BitTorrent client, for sharing large files and live show trading.
GeekTool is a flexible utility for displaying data on the desktop.
I've already mentioned 1Password, Dropbox, Instapaper, Reeder and Twitterrific, all of which see active duty on my iOS devices as well as the Mac.
Camera+ serves as a feature-rich alternative to the native Camera app.
Check the Weather, by David Smith, is my current weather app, and a pretty good one — pretty, not overly information-dense and easy to read. I highly recommend listening to David's Developing Perspective podcast if you're a mobile app developer.
Dark Sky is a different kind of weather app, more focused on current and near future precipitation. Extremely useful if you don't want to get wet.
Downcast keeps track of my podcasts.
Due reminds me to take out the garbage. I'm not a huge fan of the interface of this app — I find setting the time for reminders unintuitive — but it's better than others I've tried for recurring reminders.
I don't use the old Windows 7 box much anymore, but I do keep it around for browser testing, working on documents in Office and a bit of PC gaming (which, unfortunately, I haven't had much time for lately).
iRacing.com is still my racing sim of choice. I use a Logitech G27 Racing Wheel.
Baldur's Gate — the classic Windows version — has been kicking my ass for much of the year. I'm really not very good at it, but keep coming back for more punishment.
Black Mesa is my more recent obsession. I was introduced to this universe through Half-Life 2, so playing through a Source engine-powered re-boot of the original Half-Life feels like a long-overdue pilgrimage.
Valve's Steam service and GOG.com are great ways to get games for both Mac and Windows, and getting better all the time.
Linux is my preferred server OS for personal projects. Nothing much exciting happens here. I run various flavors of Ubuntu for no other reason than it was at hand when I got started and the documentation is quite good.
Nginx is my web server. I prefer its concise, additive configuration to the Apache alternative.
staticDimension, with a few customizations, is my static blog engine.
AWStats handles my minimal web stats requirements.
Full disclosure: some of the links on this page are Amazon or Apple affiliate links and I could receive a payment from them for any purchases you make during a shopping session initiated via these links.
Coding in Public
I recently wrote a bit about customizing archive creation in the staticDimension blog engine I use. In the process, I also created my first Github repo for my fork of the staticDimension codebase.
Bonus: Mike Wats merged my pull request, and now the new archive code is part of the core staticDimension code on Github.
Not bad for a first attempt at coding in public.
But it never really clicked for me. Until this year, when I started to put some real effort into not just learning about coding, but actually putting fingers to the keyboard and making something — anything! — execute and do something — anything!
I'll write a bit more about the experience of putting years of theory into action another time. Right now I'm going to share my experience of doing one of my first real coding projects, however small it may be, right out in public for everyone to see.
As I mentioned in the previous post, my primary goal for this project was to create a simpler, easier to navigate archive of my blog posts that no longer appeared on the home page. Simple solution: create a single page with a listing of past posts. In the unlikely event that someone wanted to find one of my old posts, it would be easy to simply go to the archive page and either scroll the list or Command-F find the desired post title — responsibilty on me to write relevant post titles.
The quick-and-easy plan for adjusting the code was to comment out the archive code that I didn't want to use and replace it with a modified version of the code used to create the home page. It just needed to grab the titles and bylines (including publishing dates) and make the title a link.
There were a few other details, such as including a link at the end of the home page to archive, so the intrepid reader who scrolled all the way down could fine more posts. And that was about it for version 1.
Making it Work for Anyone
Those tweaks would have sufficed for my site, but I felt a need to take the next step in my development as a developer: write code good enough for other people to use, not just me.
To my mind, that meant three things:
Make my changes a new, additional feature to the existing project, not just a tweaked version.
Write my feature in a way that defaults back to the standard functionality if anything goes wrong.
Try not to add much additional overhead to site updates.
As a bonus, I thought it would be interesting to submit a pull request and see if Mike would add my feature to his codebase.
I'm not all that self-conscious of the triviality of my changes. It adds a feature I want, it works, it doesn't remove any functionality other users might use. The first part was pretty easy. The second part added a bit of a challenge.
After thinking about the problem, it seemed like the most straightforward approach would be to add a setting. If it's set to true, my new feature gets used. A setting of false or any other value reverts to the default behavior.
This setting enables a single-page archive instead of
the default day-month-year folder archives...
A value of 'true' enables single-page archives.
Any other value currently uses the default archive
$this->settings['singlePageArchive'] = true;
I left this as false by default as well, so anyone who pulled the code to an existing site would not be surprised by new, unexpected archive page creation. This was an important point for me: it should not break anyone's existing site!
From there it was a fairly straightforward task to put in my new archive creation code (adapted from Mike's original home page cration code) along with a test for the singlePageArchive setting.
That took care of my first two goals, adding new features on top of the existing ones, and not breaking the old, default features.
This is probably old hat to many programmers, but it was a pretty big step for a guy who's worked with programmers for many years, yet never written anything comprising more than 20 or 30 lines of rudimentary Python.
For starters, I'd never spent much time wading around in PHP before, and what I had done was mostly cut-and-paste coding to quickly solve a problem. The contact page on this site is a great example: someone elses's code example with a few tweaks to suit my needs.
The good news is that, over the course of many years, enough programming logic permeated my thick skull that I could follow the code, understand what it was doing, and find the interaction of functions I needed to modify — even though it was in a foreign language.
The moral of this story is that you can achieve quite a bit with a little knowledge, reference material on the web, some careful reading and persistent effort.
What I'd Like to Do Better
There's definitely room for improvement. I have few illusions about that. So there are a few goals for the future:
Testing is something I've read much about, but haven't done properly yet. This is a high-priority area to learn and incorporate into my future projects.
My third goal was to avoid adding overhead to site operation, and that may be one area where I've failed. As implemented, any action that adds, changes or removes articles updates the entire site to make sure the archive page gets updated. A better way to handle this would be to test whether the changes actually affect the archive and only update the affected pages instead of rebuilding the site.
For a small site, this probably isn't an issue, but it would be more "right" in my mind.
Finally, I've been wanting the ability to update menus and sidebars without having to edit each page template individually — a source of several errors. So expanded templating would be nice and is on the to do list.
Polished Is Not a Requirement
Now, while I saw putting some spit and polish on my code as a prerequisite to sharing, it's certainly not a requirement. In my case, I felt it set a reasonably high bar for my own work as well as making sure my contribution played well with someone else's existing project.
This seems to be the quality bar many others set for contributing to existing projects. Play nice. Make your changes clear. Provide passing tests. It's just good manners.
But there are plenty of cases where putting code up in public for other people to see, play with and discuss can help move an idea forward. The sentiment is pretty well summed up in this exchange between Kelly and Brandon:
That led to Kelly posting her initial swag at writing her own home-brew column-oriented database, Dazzle, an attempt at understanding the inner workings of Cassandra by implementing her own version of it.
Success or failure, the kinds of fast, constructive feedback loops enabled by Github and similar tools are great for learning. So there's very little reason to not share your code.
I never doubted that public code repositories were a great idea, and the proliferation of choices — Bitbucket, Github, Google Code, SourceForge and others — indicates it's a pretty popular and successful model for collaboration. And though I'd downloaded code and applications many times from these services, I never thought I'd write any code worth pushing back.
But my tiny triumph underscores how important it to just dig in and try something new. You can keep it to yourself if you want, but striving to make something you're willing to share sets the bar high, and sharing opens the door to feedback, learning and improving. Whether it's coding or writing or drawing... whatever floats your boat. Create. Share. Grow. Repeat.
Search Can't Find Itself
Once upon a time, the Internet was a much smaller place, but still full of incredible things that suddenly made our pre-Internet world seem small and plain by comparison. But you couldn't find it all very easily. It was like wandering around in the dark and occasionally stumbling upon something interesting.
And then there was search, and it was good.
Making search better and better taught me that the information was out there, and I could find it.
It also gradually led me to expect that, as search improved, it would begin to understand my question better and return more accurate, relevant results.
Eventually, however, search engine developers seem to have stopped trying to understand my search expression in more sophisticated, relevant ways. They know a lot about me: where I am, what I search for, what I look at, what I buy... and they make a business off that. But I'm not the customer anymore. And their attention turned toward making the service better for the actual customer...
Making search better and better for marketers is teaching me that the information may be out there, but whatever I enter as a search term, it fails to understand the nuance of my question no matter how I phrase it and returns only marginally related results, mostly for products or services I can buy.
Page after page of inaccurate results, and all for the wrong thing to buy.
It gradually leads me to expect that our industry will pursue progress and innovation just far enough to capture an audience. And from that point on it's all scaling up, monetizing and, mostly, showmanship. But not giving me a better product.
Eventually more folks realize that they're contributing to the business, but not getting anything back out of it. So the audience goes away and the search folk are left wondering where they went wrong. Should have written the service in a different language? Didn't scale right? Outmaneuvered by competitors?
No, just forgot why what they started was important in the first place. And that was not so good.
So, to live happily ever after, the good folks wandered off elsewhere to find and share things and maybe, over time, search becomes a bit less relevant. Because they forgot who their real customers were, and why they started doing what they were doing, and we never really made any progress at all.
I bet you can apply this same parable to a few other online services, too.
Updates to the Archives
My latest adventure in proto-coding has been to fork the staticDimension blog code written by Mike Watts and add a new option for the archive pages: a single-page listing of articles.
More about the git/Github aspect of this adventure in another post. I'm still making sure things work as expected and the story won't be over until I submit a pull request to Mike. Stay tuned.
As for the Archive page... Mike wrote the staticDimension engine to create archives organized by year, month and day. I'm sure that works for him, but it's very difficult to find anything unless I know exactly where to look. Otherwise I might as well googlebing it, which sort of defeats the purpose of having the archive in the first place.
Instead, for any overflow off the home page, I just wanted a static list of every post on the site in reverse order of posting, showing only title and byline. This solves the search problem by enabling a simple Command-F search on the page in most browsers. The onus is on me to write useful post titles.
I suppose this could become unwieldy for a busy blog, but I haven't written often enough thus far for it to be a problem
One interesting aspect of this project has been figuring out someone else's codebase and making these changes in as non-kludgey a manner as possible. I'm not a particularly experienced programmer. I know very little PHP. And yet, I pulled it off.
It's also worth noting that, once I committed to sharing my code publicly on Github, it really focused my mind on making the changes an addition to Mike's work, not just a variation. More on that later.
Enjoy the new archives.
The Presidents Project
One of my projects — long on the back burner, but now moving forward again — is to survey American history by reading the biographies of the U.S. presidents (or as many as practical). Why biographies? Because people make history, and I find it more interesting to understand their experience, motivations and reactions to events than simply a chronicle of what happened and when it went down.
To get this project going again I spent some time trying to find one or two well-reviewed biographies for each president. You'll find the results on my The Presidents Project page and I'll continue to update the list based on recommendations and further research.
I also included the biographies of a few other notable non-presidents, and that list may also change over time.
Hopefully you'll find this useful. Enjoy!
Playhouse Product Testing
We had some friends and their children over for Christmas/Hanukkah dinner, and the playhouses I wrote about last week got some serious product testing.
There were seven adults in the house trying to have some grown-up conversation, and six kids — 1, 3, 4, 5 and two at 8 years old — simultaneously climbing into, out of and around the playhouses.
Eventually the red door came off the cottage, and some wrestling between three of the boys tore part of the lower-front corner of the cottage. Fixed it with some packing tape this morning.
I think some of the parents were appalled by what their kids were doing and I had to repeatedly tell them it was all in good fun. I wanted the kids to do their worst so I could see where the playhouses failed. We were all amazed that they provided as much fun and held together as well as they did.
Best playtesting ever.