I love the Sage starter theme and I love WPEngine, but WPEngine doesn't seem to love Sage v9+. Once you've got your Sage theme running in WPE, chances are it will run pretty great, but it takes a little effort to pull off your first deploy.

Here's how I approach my Sage + WPE workflow:

• Build on a Gitlab runner. Sage needs to be installed in a complete, functioning WordPress install before the Blade templates can be compiled. Gitlab runners are an easy way to get access to a MySQL server so it's possible to spin up a functional WP install.
• Vendor files are required. You can't run a theme, even after it's compiled, without the vendor files generated by Composer. Make sure these files are included in your built push to WPE.
• Move the Blade template dir. WPE doesn't allow php files outside the theme or plugin dir. I place my compiled templates in a mu-plugin dir.
• Always Use Production "Sites". WPE offers multiple site installs (Dev, Stage, Prod) inside a top-level site container. Confusingly, they also allow you to have both a regular production environment and a "legacy staging" environment for all of those site sites... for a total of six environments. This is both overkill and misleading, because the legacy staging server config is not the same as a production config. Always use production sites to avoid disappointment when you deploy the live site.
• Test Your Pipeline Locally. Running the entire Gitlab script as you test your pipeline is tedious. I created a Docker config along with basic build deploy / scripts to make it possible to step through the deployment process interactively.
• Ask WPE support to set a caching exemption WPE has aggressive object-caching that can interfere with your Blade templates. Ask their support team to exempt your compiled templates from their internal caching.

Depending on the exact version of Sage that you're running, and the Composer packages that you're using, it might be necessary to tweak these files, but here's what I use in my live Gitlab runner:

.gitlab-ci.yml
bin/deploy

Good luck! If all goes well, here's what you'll see:

Lead photo: Clever Sparkle

While WPE is a fantastic host for managed WordPress sites, with helpful environment options... there will probably come a day when it's easier to work with a local instance of your site. Maybe you'd like to make some tweaks to a theme, or you need to run a CLI tool that WPE doesn't allow. There are a couple small quirks in the WPE environment to contend with, but process of configuring a local copy of a WPEngine is mostly painless.

Download a copy of your site's WP files

Under the 'Backup Points' section of your WPE dashboard, there should be a set of daily checkpoints, each of which contains all the non-database assets needed to run your site. Select the most recent backup and choose "Download Zip." It will take a few minutes to prepare the download if your site contains a large amount of images, but not as long as you might fear. I prefer to download the entire backup, with /uploads and /plugins to ensure you fully simulate the remote site locally. The backup point includes all the WP core files, too—it's a complete install.

Uncompress the backup package and point your local WP server (Valet, Trellis, VVV) at the new site directory.

Create a local copy of the remote site's MySQL database

Now that you have the WordPress files in a local dir, it's time to snag the database used by the live site, too. The WPE backup point does include a copy of the db under wp-content/mysql.sql but I find it's easier to use phpMyAdmin, to get a little more control over how the export is formatted. Inside the WPE admin panel, there's a link directly to the WPE phpMyAdmin. Under the 'Export' tab in phpMyAdmin, you'll see the option to download a direct copy of the live db. Choose the 'custom' option so you can pick just the main db. You want the one that starts with 'wp_', not 'snapshot_'... the snapshot one is a WPE system file.

Most likely the default custom export settings will be ok, but you should pick a Compression option, to speed the download and import process. On the local side, fire up your local phpMyAdmin and import the downloaded file. If it's a big db and you're running MAMP, there's a good chance the db will exceed MAMP's mystifyingly small upload limits. In the free edition of MAMP you can easily update your php ini files, and in the paid version of MAMP you will need to use the 'template' interface. Also worth noting it's simple to import a MySQL db through the command line.

Modify the local WP config to remove WPE system settings

Here's the tricky part: removing any remaining WPE artifacts that might interfere with viewing the local site. WPE adds a lot of their own variables inside wp-config.php that you can easily live without. It's critical that you delete two settings in particular: WP_SITEURL and WP_HOME. These variables will cause your browser to redirect to the live URL, not your local site. Change your 'Database Configuration' within wp-config, too. DB_NAME, DB_USER, DB_PASSWORD are hopefully self-explanitory, but the WPE config for DB_HOST and DB_HOST_SLAVE may be subtly different from your local setup. There are also seven WPE plugins that are no longer necessary on a local site:

wp-content/mu-plugins/mu-plugin.php
wp-content/mu-plugins/wpengine-common/
wp-content/mu-plugins/slt-force-strong-passwords.php
wp-content/mu-plugins/force-strong-passwords/
wp-content/mu-plugins/stop-long-comments.php
wp-content/advanced-cache.php
wp-content/object-cache.php

Finally, you will want to edit the db file directly in phpMyAdmin to update the two db values that tell WordPress how to build URLs to your site. siteurl and home both live under wp_options in the database. Once you've modified wp-config.php it should be possible to access your site locally and log into the WP admin area. From here, I like to use the simple and effective Search Regex plugin to update links inside posts use the wp cli's built-in find and replace. So much easier than a WP admin plugin! Remember that your live install was https and the local install might not be, so you will need to include the full url in your queries.

Once you have your local setup running, you might want to add a Git integration to your WPE install, or create a CI pipeline to deploy to WPE for you.

Photo: Ingo Shulz

I love the plugin The SEO Framework by Sybre Waaijer. It's a breath of fresh air compared to the bloated, distracting, and overly-promotional SEO plugins that have been so popular in WP for years. One advantage of using a plugin that's well-written and accessible is that it's easier to make little tweaks to fit the plugin to better suit your needs. In my case, I recently needed the option to display multiple page titles: one title for browsers, and a custom override title for Facebook, whose algorithm now censors content with rude words.

Sybre's source code is easy to follow, and the documentation is pretty good, but I thought I'd post my specific configuration in case anyone is looking to perform similar modifications.

This hook calls a custom function when The SEO Framework is preparing to output the title:

add_filter( 'the_seo_framework_ogtitle_output', 'og_title_override', 10, 2 );

This custom function checks to see if a particular meta value is set on the post in question. If the meta value exists, it returns that value as the title, otherwise it returns the title set by the SEO Framework.

/**
 * Injects a replacement Open Graph title when user fills out custom metabox.
 *
 * @param string $title The current title.
 * @param int $id The Post, Page or Term ID.
 * @return string Title. User input title is santized on metabox save
 */

function og_title_override( $title = '', $post_id = 0) {

    $user_title = get_post_meta( $post_id, '_fb_override_og_title', true );

    if  ( $user_title != '' ) {
      $title = $user_title;
    }

    return $title;
}

A very simple function, made easy to implement by a well-written plugin.

Photo credit: Adam Birkett

One of the best things about the Ghost blogging platform is the impressive flexibility in development and deployment options. Of course, with that flexibility comes a commitment to doing a lot of things yourself. I recently configured a Codeship Continuous Integration pipeline for deploying changes to a Ghost theme I maintain, and while it was fairly straightforward, I'm documenting the process for posterity. Feel free to skip over all the CI steps if you're only interested in using Git push to update a theme on a remote server.

Even though I'm the only developer working on this project—I know, I won't enjoy all the benefits of CI—I like using Codeship to run the build and test processes for my theme. This way, I get to keep a nice clean local working repo, and avoid any build scripts on my live server.

The full stack for my Ghost theme looks like this:

• Local development Ghost 1.20.3 server
• Ghost theme running Webpack and various JS / CSS processors
• Origin repo in Github
• Free tier Codeship account using node 6.9
• Digital Ocean Ubuntu 16.04 droplet also running Ghost 1.20.3

Broadly speaking, the CI process looks like this:

• Make local changes, commit, push to Github
• Github triggers Codeship build
• Codeship compiles the theme for production, swaps .gitignore files
• Codeship server pushes to repo on production server
• Production server receives updated theme files, restarts to display changes

Push your theme to a remote repo

You can't push a project directly to Codeship. When you create a Codeship project you'll have a choice to integrate to either Gitlab, Bitbucket or Github. I chose to use Github, but they're all roughly equivalent. So, from your local machine, prepare a repo from your working files. In the primary .gitignore file, you should ignore any production or build files. My .gitignore looks like this:

# ignore development / production files 

/node_modules
/assets

Next, create a .gitignore file to be used after Codeship builds your theme. This ignore list should specify working files, and allow production files to be committed. I call my build ignore file .codeshipignore and include these files:

# allow assets to be pushed from codeship

/node_modules
/src
build.gitignore

Once you have all the appropriate local files, go ahead and push to your remote repo, then create a Codeship project and give it access to your origin repo.

Configure Codeship to build your theme

Codeship will prompt you for some "Setup Commands." This is where you can specify the environment required for your theme's tests. If you don't have any test commands to run, don't worry about these fields. After you save this setup, you'll want to click the "project settings" button, and navigate over to the "Deploy" tab. This is where Codeship runs build processes.

Because I'm pushing to a theme that's on a production server, I used the master branch as my deployment trigger. If you push to multiple servers, i.e., a staging and a production server, you might want to configure multiple pipelines.

Once you've established a pipeline, it's time to add your build script (pick the 'custom script' option). These are commands you feed the Codeship server to be executed just like you're in a terminal session.

Here's what my build script looks like:

git config --global user.email "xxxxx"
git config --global user.name "xxxxxx"
git checkout master
mv .gitignore build.gitignore
mv .codeshipignore .gitignore
nvm install 6.9.0
nvm use 6.9.0
npm install
npm run build:prod
ls -la
git add .
git commit -m "deploy"
git remote add live ssh://git@xxx.xx.xx.xxx/home/git/xxxx-ghost/
git push live master -f

It's a fairly straightforward process: ensure you're on the right version of Node, install Node modules, build the theme from source, swap the .gitinore files, add your server's repo, and push. Codeship's environments reset after each build so it's necessary to add the remote every time.

Configuring your live server to receive Codeship pushes

Next, you need to be sure your live server can receive the Codeship repo. Log into your remote server through ssh, and create a bare repo for Codeship to push to, inside the home dir for the git user (this user should be created already, assuming you have git installed on this machine). You will also need to ensure the Ghost CLI is installed on your server.

cd /home/git
mkdir yourblog.git
cd yourblog.git
git --bare init

Jump into the 'hooks' directory and create a file called post-receive.

cd /home/git/yourblog.git/hooks
touch post-receive

Open the new file with the editor of your choice, and paste the following lines in, adjusting for the path to your ghost install / theme:

#!/bin/sh
git --work-tree=/var/www/yourblog/content/themes/xxxx-xxxx --git-dir=/home/git/yourblog.git/ checkout -f
cd /var/www/yourblog
sudo /usr/lib/node_modules/ghost-cli/bin/ghost restart

This script will direct git to place the repo files in your existing ghost theme directory, and to use the CLI to restart your blog instance.

Next, we need to ensure this script can actually execute. Change the permissions for post-receive:

chmod +x post-receive

...and it would be nice if Git owned the proper directories, too:

cd /home/git
chown -R git:git yourblog.git
cd /var/www/yourblog/content/themes
chown -R git:git yourtheme

At this point, we need to ensure Codeship can push to the remote server. Under the General Project Settings tab in Codeship, copy the "SSH public key" and paste it into the git .ssh dir:

cd /home/git/.ssh
touch authorized_keys
nano authorized_keys
[paste the key and close/save]

There's one last task to complete! We need to ensure the git user can run the Ghost CLI's restart command without being prompted for a password, since the Codeship server is unable to respond interactively. Open up the sudoers file with this command:

visudo

On newer flavors of Ubuntu this opens up a special session in nano, ensuring that the syntax of your sudoers is correct before saving, minimizing the chance that you blow up your system permissions. Go ahead and insert these lines at the end of the file, where ghost_instance is the name of the specific Ghost blog you have hooked the Git repo to:

# Allow git to restart ghost blogs
git ALL = NOPASSWD: /usr/lib/node_modules/ghost-cli/bin/ghost restart ghost_instance

The line added translates like this:
git ALL == allow connections from all hosts
NOPASSWD: == don't require the pw for sudo actions for...
/usr/lib/node_modules/ghost-cli/bin/ghost == the absolute path to the Ghost CLI

Source your bash profile to reload the sudoers list:

. ~/.bashrc

That ought to do it.

When I'm developing a new layout, I like to label components with background colors so I can see exactly where the position boundaries lay. Unfortunately, I can never seem to remember what CSS named colors are the most attractive, and it starts to strain my eyes coloring boxes all "yellow" and "red". So, here's a handy chart to the CSS colors that slightly less painful to paint with.

note: this is a pretty old post, and both Ghost and Acme.sh have changed quite a bit! This guide is now probably the best resource on configuring LE SSL with Ghost in the year of our lord 2020: https://ghost.org/docs/api/v3/ghost-cli/knowledgebase/#ssl-for-additional-domains

This tutorial assumes that you want to self-host your Ghost site under the root address of your domain, i.e. https://somedomain.com, and redirect all other domain permutations to this address. So, rather than resolve the non-SSL version of the root, the non-SSL wwww version or a https://www version—you want to 301 everything to a single canonical address. I wrote these instructions using Ghost 1.15.0, and Ghost CLI 1.2.1.

First, make sure that your domain is pointed to the correct nameservers, and that you have both an '@' and a 'www' record for your domain. It might be helpful to run the host shell command to verify that your domain is networked correctly to your server.

Next, set up your ghost site at the primary address you plan to use. If you want your site to live at https://lemontree.com, run the Ghost CLI installer and tell it the new install belongs at https://lemontree.com. The Ghost CLI will volunteer to set up a Let's Encrypt SSL cert for you at this address, and it will save you a lot of time to accept this offer. It's also easiest to allow Ghost to configure nginx.

The CLI will install a shell script called acme.sh in order to ping the Let's Encrypt service to issue certificates for the exact install domain.

Now, you should have a functional site, live on the internet. Go ahead and curl the URL you gave the Ghost installed.

curl http://lemontree.com no https will produce a Moved Permanently. Redirecting... message.
curl https://lemontree.com will return the full body of your Ghost homepage.

So far, so good. On to the next two domains, http://www.lemontree.com and https://www.lemontree.com. This step requires a little more legwork. curl http://www.lemontree.com should give you the default nginx install page, and curl https://www.lemontree.com with the https will result in an SSL error. This is because the SSL cert issued by Let's Encrypt covers only the non-www domain. You need to issue a second cert specifically for https://www.lemontree.com, even though we are planning to redirect this traffic. A browser pointed to a https address will confirm SSL certificate details immediately, before processing a redirect request.

In order to issue a certificate for our www domain, we need to configure nginx to respond to the LE verification request—this is what associates our certificate to our domain.

Navigate to the nginx config files Ghost setup for you. They live in /var/www/[lemontree]/system/files, where [lemontree] is the name of your install. Open up the non-ssl config file, lemontree.com. You should see an existing server block that redirects traffic from the non-https address to an SSL scheme. Add a new block below to accept requests from the LE verification request, and ensure this block redirects all other traffic to your primary SSL domain:

server {
   listen 80;
   listen [::]:80;

   server_name www.lemontree.com lemontree.com;
   root /var/www/lemontree;

    location ~ /.well-known {
        allow all;
    }
    
    location / {
        return 301 https://lemontree.com$request_uri;
    }

    client_max_body_size 50m;
}

By default, /var/www/lemontree.com will be the root dir of your Ghost install, though this may vary.

It's a nice idea to run a test on your nginx config files each time you edit them, before restarting nginx. sudo nginx -t will confirm a valid config. Assuming there are no syntax errors, sudo service nginx restart will gracefully reload your nginx config.

Remember that script acme.sh? Navigate to the directory where that script lives: /home/[user]/.acme.sh/, where [user] is the user account that ran the Ghost install commands.

Now, issue a certificate through acme.sh for your https://www address:

acme.sh --issue -d www.lemontree.com -w /var/www/lemontree.com

/var/www/lemontree.com needs to match the dir you specified in the nginx conf.

After acme.sh runs, you should see a message with the location of your new certificate files. Take note of these locations! They will look something like this:

Your cert is in  /home/serveruser/.acme.sh/www.lemontree/www.lemontree.cer
Your cert key is in  /home/serveruser/.acme.sh/www.lemontree/www.lemontree.key
The intermediate CA cert is in  /home/serveruser/.acme.sh/www.lemontree/ca.cer
And the full chain certs is there:  /home/serveruser/.acme.sh/www.lemontree/fullchain.cer

Next, we want to configure nginx to use these newly issued www cert files. I didn't have any luck using the acme.sh automated install command. Here's how I manually added the certificates. Head back over to the nginx config files Ghost created, in /var/www/[lemontree]/system/files. There will be an existing SSL config called lemontree.com-ssl.conf. Copy this to a new file, www.lemontree.com-ssl.conf. Edit the servername to match the www version of your domain. Comment out the line root /var/www/lemontree/system/nginx-root;—we're not going to serve any content from this address. Under the server_name line, add a 301 redirect: return 301 $scheme://lemontree.com$request_uri;. Finally, there will be two lines that begin ssl_certificate and ssl_certificate_key respectively. Edit the paths after these keywords to match the path acme.sh returned. (Should be as simple as adding www ahead of your domain.)

Now we need to add symlinks from the nginx dir to the new www conf file in your Ghost dir. Head over to the dir /etc/nginx/sites-available and add a symlink to Ghost:

sudo ln -s /var/www/lemontree/system/files/www.lemontree.com-ssl.conf www.lemontree.com-ssl.conf

Finally, link sites-enabled to sites-available: sudo ln -s ../sites-available/www.lemontree.com-ssl.conf www.lemontree.com-ssl.conf

Run one last sudo nginx -t test and restart nginx. Now, when you curl your www addresses, both the https and non-https variants should return a 301 redirect to the canonical, non-www https address. Congrats!

I wrote a brief essay about why ‘convenience’ apps like Uber are so successful: they shield us from interacting with behind-the-scenes workers, most often from very different economic, cultural and social strata than our elite consumers. Read the story over on Medium >>

There’s an acute lack of digital talent out in the wild. Every business — worm farmers to art dealers — knows it’s critical to be online. That means building a web site, creating a marketing presence and being active in social media. If you’re an employer, implementing this digital infrastructure can be confusing territory. Odds are, you don’t need a fulltime developer / web marketing expert / community manager on your team. But acquiring a freelancer means hiring and evaluating a skillset in which you may have little expertise. The internet landscape shifts so quickly, it’s hard to track exactly what is effective NOW unless you live and breathe web.

From a freelancer’s perspective, even one prepared with skills in strong demand, new clients are shrouded in uncertainty and frustration. Working productively means understanding a new brand and business goals in short order, while gently educating the client: what tools are necessary? what features are cruft? what content is useful?

For those freelancers fighting the good fight, Godspeed. For employers in need of freelance talent, a few suggestions:

1). Come prepared with a tight, concise concept of what you’d like to build.

At the onset of a web project, every client has an idea of what they want to end up with — even if it’s only in their head. There’s nothing worse than vague directions from a client that send freelancers back to the drawing board when deliverables don’t match poorly articulated expectations.

It’s ok if you’re not a designer or information architect. Sit down and map out exactly what you want as the final project. Sketch concepts on paper, make note of similar websites doing something you like, and make sure you consider what folks in your organization need from a backend. A minute spent on detailed specifications saves an hour of back and forth or wasted development effort.

2). Beware feature creep.

Closely tied to number one – make sure you nail down ALL the required functionality before work starts. There are many good reasons to avoid feature creep. New features add to the scope, which will result in additional cost to the employer. It’s generally harder to integrate new features once half the code is prepared. Most importantly: the new features are almost uniformly bad ideas.

There’s a certain pressure that clients feel to squeeze everything in once work is underway. This can lead to an insistence on building spur-of-the-moment ideas. Tread cautiously. Generally, clients and developers remember the truly important features before getting started. See a project to completion and live with it for a bit before deciding to add on extra bells and whistles.

It really messes up freelancers to extend a project, because missed deadlines cascade over into work that’s lined up in the future. Planning work schedules and accounting for uncertain income is hard enough when projects wrap up as expected

3). Limit parties allowed to provide feedback.

What’s the best strategy to avoid feature creep? Limit feedback on prototypes to only the most essential staff. Additional eyeballs reviewing freelancer work make it harder to reach consensus. Even if you are lucky enough to have all reviewing parties on the same page, getting everyone to take a peek wastes time and keeps your freelancer idle. Identify who needs to sign off on work at the onset, and don’t introduce commentary from the peanut gallery mid-process.

4). How to understand delays:

Delays are justifiably frustrating to clients. When a freelancer promises a product in 30 days, and fails to keep his or her word, the likeliest explanation seems to be that the developer is a liar, or a dolt. Unfortunately, even the best managed projects often (if not always!) turn more complex than anticipated.

Michael Wolfe offers a brilliant analogy in to explain how this happens. When you consider a project in broad strokes, say, as one might look at a length of distance down the California coast along a map, there’s a clear path from A to B. Once you’re actually on the ground, it’s likely there are many obstacles that weren’t clear from the map. There’s no method to accurately predict every complication in most digital initiatives, other than rolling up your sleeves and starting work.

Some freelancers like to take a guess at delays that may arise and quote high. I prefer an initial quote based on the best information at hand, and an employer who appreciates that there is always a possibility that information may change.

5). Draw up a contract.

When I first began freelancing, I didn’t mind winging a project without a contract. You are correct: was that ever a bad idea. At face value, contracts are useful in resolving legal disputes, but I’ve never been so unfortunate as to experience that first hand.

The real value in a contract is codifying everyone’s expectations and laying out a framework for the project. Insist on a detailed contract outlining scope, milestones, communication expectations, and a process for missed deadlines or additional work requests. Clarity in terms of engagement go a long way toward working effectively once you’re close to the finish line.

It’s tempting to manage a freelancer on the fly — but the most effective, and satisfying process is always building a tight, precise framework at the onset. When you and your freelancer share a clear vision, your project will turn out great.

*PS: I’m very grateful for Derek Sivers’ excellent guide to hiring freelancers. Four years old and every bit as useful today. *

Quartz news recently posted an analysis of the commission GrubHub and Seamless charge to restaurants that participate in their advertising network. Working backward from a claimed billion dollars in delivery orders, QZ calculated that GrubHub and Seamless collected $137 million in revenue through an average commission that approaches 14 percent.

This is completely coconuts, of course, and it got me thinking about how to fairly value technology. Technology can do wonderful things to improve our lives, but most often it seems improve the fortunes of those who are already well off. In this case, technological profit seems to come at the cost of those already marginalized.

Seamless and GrubHub frame their narrative as noble. They’ve struck upon an incredible breakthrough to fix a system and improve lives. In return, they deserve a lavish commission and untold IPO riches.

In my view, this is closer to reality: GrubHub and Seamless happen to control a small amount technological knowledge, which gives them leverage over business owners who are unsophisticated in their knowledge of internet. They’re unneeded middleman, and their compensation is out of line when compared against the value of their service.

The technical solution created by GrubHub and Seamless is hardly groundbreaking. It’s a shopping cart for restaurants, solidified by an anticompetitive merger. In a world where restaurateurs were web savvy, individual eateries could easily implement these systems. The real power in GrubHub and Seamless is that they ‘invented’ online restaurant ordering – introducing the concept to diners, and locking them into their ecosystem before restaurants had a chance to respond.

Let’s suppose that the core team of technologists here is no bigger than 50 – 100 employees. Their company hauls in $137MM in revenue. The entire operation is closer to 700 employees, according to GrubHub’s IPO prospectus, but it’s fair to assume the vast majority of these employees clock in at GrubHub for customer service positions, or are part of their mammoth sales force. I doubt many of those employees hold significant stock options. This slim collection of technologists are skimming a very significant percentage of the money that helps support tens of thousands of restaurant workers.

Based on a 2010 study by the National Restaurant Association (and Deloitte & Touche LLP), average pre-tax profit margins in the  trade range from 2-6 percent. It’s an extremely tight business, staffed with mostly low wage workers: according to the Bureau of Labor Statistics, average pay in the  industry is just $18,130.  It’s hardly a leap to suggest spiraling ‘web’ commissions will impact these wages. One might argue that GrubHub and Seamless are bringing in new business, but it’s more likely they’re supplanting what were once phone orders. The volume of take-out food orders is tied more closely to broader economic health than order-placing technology.

But wait —** it gets worse**! Once a restaurant is doing business with Seamless, they’re pressured to pay extra for better placement within the site. While consumers believe they’re shown restaurants based on ratings, or other objective criteria, placement is actually determined by fee. Their commission can in fact range as high as 18 percent. On top of that, there are monthly “partnership fees” to remain active, in addition to the commissions. Plus, when an order is placed on Seamless or GrubHub, they keep all the cash upfront, and send what’s left over after commissions at their leisure.

What happens when all restaurants are paying ~20 percent of their revenue to continue the business they had before GrubHub and Seamless arrived on the scene? It’s bad for consumers, much worse for restaurants, and another example of technology that benefits only a small cadre of insiders.

I can’t say for certain what compensation is reasonable for a shopping cart software company, but I do recognize what it looks like when one takes advantage of it’s clients. When I order takeout, I pick up the phone.

I’m fascinated by the diverse array of “No Parking” signs that sprout behind Brooklyn curb cuts. They’re little slices of folk art hidden in plain sight.

Despite the universal need for “NO PARKING” signage, there’s little consensus on their appearance. I see old-school Brooklyn, hipster Bushwick and graffiti kids in every driveway.

Signs can be threatening or matter of fact; professional or comically childish. A ubiquitous, yet hardly uniform feature of the urban landscape.

You can find the complete collection of 2013 Brooklyn No Parking photos over on my Tumblr.

Tunes, it seems, have finally become entrenched in the cloud. Why download and store your music locally when subscription services (either very inexpensive, or based on incessant, obnoxious social media posts) ? I’ll admit it: Pandora is awesome. Rhapsody has a huge library and catchy TV advertising. Spotify has the ability to annoy me. YouTube seems to have just about everything.

I know the inextricable march of technology pauses for no man. I understand streaming is a superior music delivery, but it mostly makes me sad.

I started collecting MP3s in middle school. I’m pretty sure my first was the classic Nickelback jam Leader of Men, but over time, my taste improved. Fourteen years later, I have a tad under 12,000 MP3s in my iTunes collection. I doubt it’s the world’s largest collection of MP3s, but I picked out each one myself. I think most of them are even legal, ripped from CDs, vinyl, or curated from sampler playlists.  I feel like High Fidelity’s Rob Fleming – obsessing over the perfect playlist, constantly re-arranging my file structure, fixing MP3 tags, tracking down album covers and finding the right balance between mainstream and esoteric artists. It’s an unconscious expression of my deepest, fullest self.

Is this the equivalent of my generation’s vinyl? Will the kids of someday start downloading files on the sly, saving them to a nostalgic external hard drive? Will physical storage become a status symbol? Street cred acknowledged among cool kids at exclusive parties? I can’t help but feel that’s an outside possibility at best. And that’s why, even knowing that streaming music is easier than editing my collection to fit a 32gb iPhone, I still want my MP3s, and my music.