destroytodaydt

2012 - A Year In Review

It’s late on the first of January, almost the second, but I’m determined to get this post up before it’s too late. Today might even be too late, but I think it’s important to have something written for this past year, especially for this past year. Let’s get started.

I moved to New York

After a year and a half in San Francisco, both Jen and I heard the calling of the east coast loud and clear. Even with the beautiful weather, close proximity to the mountains and beaches, and unbelievably accessible fresh food, overall, it wasn’t for us. In February, we moved to New York where we feel at home more than ever. This is where I’m meant to be.

I joined Studiomates

Shortly after moving, I started renting a desk at Studiomates, which I would easily call our second home. The people in this co-working space are incredible. Working aside some of the makers I’ve looked up to for years still feels like a dream. The sense of community is so strong, I wouldn’t give up my spot for anything.

I taught my first class

Maryland Institute College of Art invited me to teach a 2 day workshop on anything I’d like. I had the students take an existing app and redesign it. The experience was fantastic and I would love to teach more. I’ll be back at MICA later this year to teach another class.

I quit my job

Two and a half years at Adobe sure taught me a lot, but most of all, my time there made it clear what I really wanted to do with my life. The urge to be on my own grew with every day and even though I enjoyed most of the projects I worked on, I constantly felt myself racing home to work on my side projects.

I started my own company

Rather than looking for a new job, I decided it was time to finally go out on my own and start a company, giving Destroy Today the focus it truly deserves. I couldn’t be happier with the decision. I’m consistently working with incredible designers, developers, and companies. And it’s easy to find passion for these projects because I believe in each one I take on. I also feel real ownership and responsibility. The drive to succeed is one of survival. I still have those moments of panic several times a week where I fear I’ll go broke, not have a next project, or burn out. I’ve come to realize this stress is just part of being on your own. It never fades.

I got married

After five and a half years of dating Jen, we tied the knot in our home state of Pennsylvania. Everything went as planned—she showed up and agreed to marry me. The day was perfect and married life couldn’t be better. She keeps me going and keeps me sane.

What’s next?

Very soon, I plan teux ship the product that’s been my life these past six months. I recently ditched Instgram with the hope of returning to real photography. I need to write more. I want to work on at least one off-the-computer project. I’d love to teach and speak more.

Let’s do this.

The tech behind our wedding

On the 15th, I became a married man. An inordinate amount of work went into this wedding to ensure that it matched us as a couple in every way, and luckily, everything went without a hitch. I’m a dev at heart, so in the planning, I took it upon myself to be creative where I could. I utilized several services and even experimented with some of the newer web tech out there. In this post, I’ll run through the ‘backend’ of our wedding and provide detail on exactly what went into it.

Planning

In planning the wedding, we used a variety of web services for organizing everything from guest lists to vendor options. Since this data needed to be seen by several people and incurred much overlap in editing, we relied heavily on Google Docs. Maintaining our guest list as a spreadsheet allowed us to keep everyone’s contact info in one place and in an easily exportable format.

For outlining website content and keeping a general list of ideas, we used my go-to list app, Workflowy. Its interface is so quick and easy, there’s absolutely no friction in jotting down thoughts. Sharing is a breeze, too.

To keep track of everything that had to be done, we used TeuxDeux. With its calendar interface, todos rollover to the current day if you don’t do them. This allows more flexibility while keeping the task in view, in case something unexpected comes up. Protip: when planning a wedding, something unexpected always comes up.

Save the Date

This year has been pretty active for us. In February, we moved across the country, back to the east coast, and a month later, both of us quit our jobs. Because of this, we weren’t as quick to send our ‘Save the Date’ as we had originally hoped. With only a few months before the big day, we opted for a less traditional approach.

I set up a single page website using vintage postcards Jen bought on eBay—each displaying a location where we lived. The website determined the viewer’s location from their IP address and displayed the corresponding postcard. With CSS3, the postcard flips when rolled over to show the wedding info. The postcard images are retina-supported and look especially nice on the latest iPad.

To get the word out, we used Mailchimp. Since we had a Google Docs spreadsheet of our guests, importing them into Mailchimp required only a click. Again, we used a scan of a vintage postcard as the email graphic with hand-drawn type by Jen.

RSVPs

After sending the ‘Save the Date’ as an email and website, we wanted to provide guests with something more tangible for the actual invite. Jen designed and illustrated our very own postcard that we screenprinted together. It provided guests with details about the big day and pointed them to our wedding website to RSVP.

We opted for an online approach for the RSVP because it requires the least amount of effort from the guest—they simply need to fill out a form. Personally, the thought of mailing anything these days feels like a hastle. We again used Mailchimp, but this time for their subscription form. By having them ‘subscribe’ to our wedding, we now had a new mailing list specifically for those who are able to make it. By cross-referencing this with our original list, we were easily able to see who didn’t RSVP and send them a follow up email.

Website

The website was built on Jekyll with HAML and SASS compiling to HTML and CSS, respectively. It provided guests with everything they needed to know about the wedding, including the pertinent information, like time and location, but also our backstory, hotel accommodations, and Philadelphia attractions. Jen even created a Pinterest board for suggested attire that I coded to fit within the site.

Photo Blog

For the day of the wedding, like any couple getting married, we wanted to capture every moment and every angle. We hired amazing photographers, but still wanted more. We knew that a fair amount of guests would take take their own photos and some would even use Instagram to post them. Originally, we planned to use a hashtag to auto-post to a Tumblr feed, but within days of the wedding, we discovered another couple had the same idea!

I looked for other methods that could give us more control and rediscovered IFTTT. With it, we could set up a trigger to watch for ‘likes’ from a specified account and post the corresponding photos to Tumblr. I created an Instagram account for the wedding, followed each guest with an account, and ‘liked’ the photos we wanted on the blog. At first, I thought this approach would be tedious, but it ended up being a great way of re-experiencing each day including and surrounding the wedding.

Wrapping Up

I hope this post was helpful to those either currently or eventually planning their wedding. With so many advancements in everyday technology, we should always look for ways to take advantage of them. Be creative and have fun. And let me know if you have any stories of your own.

Using Alfred to setup your dev environment

This started as a post about all the ways you could use Alfred outside of just launching apps, but the post quickly became a book in size, so I decided to split it into a series. To prevent the series from becoming the only content on my blog, I’ll focus on the use-cases that are specific to my everyday workflow.

I constantly think about ways to improve my workflow. The main goal is to automate any menial tasks, so I can focus on the more important ones. One of the biggest lesson I’ve learned since starting my own business is that the value of time cannot be measured, and anything that saves time is well-worth the initial time invested.

I started analyzing my typical day-to-day. Are there any repetitive tasks soaking up my time? The first that came to mind was setting up my dev environment. With TeuxDeux, I need several Terminal tabs for the following processes:

• rake server runs the web server, which serves the app and javascript tests.

• rake guard cleans all public folders and auto-compiles all HAML, SASS, and Coffeescript files.

• bundle exec autotest watches Ruby source folders and runs Ruby unit tests with RSpec.

• bundle exec racksh enters the app’s console.

Sure, each process requires only a single-line command, but tally how long it takes each and every morning and you can see the effect. Aside from lost time, it’s a daily hurdle that must be done before I’m able to do any work, and it’s a task that requires no skills, unless you type it one-handed—that takes skills. Wouldn’t it be nice if this could all be done with a single command? Yes, that would be quite nice.

Luckily, Alfred gives its users the ability to write extensions—all sorts of extensions! For my case, I need to write an Applescript extension, so I click the ’+’ button in the bottom left of the Extensions tab in Preferences and select ‘Applescript.’

I set the title AND the icon because this is an extension I’ll see everyday and anything with an icon is legit.

From there, I describe the extension, set its keyword (something easy), and write the Applescript.

Applescript isn’t your everyday programming language, so I had to dig to find the correct syntax. The code starts by launching Terminal if it’s not already open or bringing it to the front if it is. I specify the commands I want for each tab and the script loops through them, opening a new tab for each one.

tell application "Terminal"
  activate
  set command_list to {"rake server", "rake guard", "bundle exec autotest", "bundle exec racksh", "subl ."}

  repeat with the_command in command_list
    tell application "System Events" to tell process "Terminal" to keystroke "t" using command down
    do script with command "cd ~/projects/teuxdeux;" & the_command in selected tab of the front window
  end repeat
end tell

That’s all. By setting aside 10 minutes one morning, I can now start writing code sooner and get to what really matters. That makes think—what else could I do in a short period of time to greatly improve my workflow? The posts to follow will continue this discussion. If you have tricks of your own, feel free to share them in the comments.

Working on TeuxDeux

Today, I start as lead developer on TeuxDeux, a todo app by swissmiss and Fictive Kin. Since its release, I’ve been an avid user, relying heavily on TeuxDeux for more than just todos, so I’m ecstatic for the opportunity to help shape its future. First on the agenda is to rewrite it for the modern web. From there, we’re going to take TeuxDeux to the next level. Sign up now to be the first to hear about updates.

10 reasons why I switched to Spine.js

In the past year, I shifted interests from the desktop to the web. I’m really drawn to apps that can be accessed from any device with a browser. I have a history with HTML, CSS, Flash and PHP, so I’m familiar with the space, but only in a presentation sense—I’ve made websites, but not web apps. I dove head-first into Rails and instantly fell in love, but the immediate response I knew with Flash was replaced with page loads. Because of this, I turned to Javascript.

Like the new kid at school, I didn’t know who was who in regard to frameworks. I looked around and saw mentions of Backbone.js everywhere, so I assumed it was the standard. After several months, however, I realized it’s not for me—Backbone.js lacks a clear direction of use. Every tutorial I read used a different structure, and it almost seemed too easy to disregard proven design patterns.

Enter Spine.js. I spent a night just reading through its guides and examining its demo apps. Everything I saw just looked right. That night, I wore a big smile and even had trouble sleeping because I couldn’t wait to start using it. What made me so excited?—these 10 things:

1. A Clear Architecture

   Spine.js follows MVC (model-view-controller, for those who should take a moment to learn MVC). All the apps I’ve written follow the MVC architecture, so I immediately know how to structure my app using Spine.js. I also feel a sense of familiarity off the bat. There’s no question of which class does what or where each class lives.

2. Models are Models

   Backbone.js has models, but it’s awkward because there are also collections—essentially an array of models that can also query an API and populate itself with the results. Spine.js models are very similar to Rails models. A model can be instantiated to represent a record, but it also has class-level methods for retrieving records from the API. These methods return the results instead of populating an array, so we don’t have to contemplate where the class lives, as one would with collections. And because collections are instances, many of the examples I’ve seen treat them as singletons. As a result, those learning Backbone.js and following these examples are also learning how to write untestable code.

3. Spine.app

   While using Backbone.js, I found myself copy/pasting code every time I created a new class. I missed the generators I grew accustomed to in Rails. With a single command, I could generate the new class along with its spec, based on a template—this adds years to a dev’s life. “Write Backbone.js generators” was on my todo list for weeks, but I never got around to it.

   Spine.app generates files. With a single line, I can create a class and its spec, just like in Rails. Hell, I can even generate a new app with one command.

4. Dynamic Records

   This one is just crazy black magic, but it solves a problem I faced with Backbone.js. Let’s say you fetched a record in one view of the app. Then you fetch and update that same record in a different view. In Spine.js, both records will update. You don’t have to worry about keeping them in sync. The moment I read about this, a single tear rolled down my cheek.

5. Elements Hash

   With Backbone.js, I constantly found myself manually assigning variables to nested elements in every view’s render method, repeating the same code for each element—that’s a lot of boilerplate. In Spine.js, there’s an ‘elements’ hash. The keys are selectors and the values are variable names. Just like the ‘events’ hash in Backbone.js, all your elements are mapped—clearly and easily.

6. The Release Method

   In my Flash days, optimization was a key to survival. If ever I forgot to remove a single event listener, my app would leak memory like… a poorly maintained app. Because of this, every class I wrote included a method to nullify all references and remove all event listeners. Spine.js has this built in. Sold.

7. Routing Lives in the Controller

   There is no Router class in Spine.js. This functionality is part of the Controller class where it belongs. In any controller, I can navigate to a new location and react to this new location. Other controllers can react to this new location as well. Now there’s no temptation to create a router singleton.

8. Model Adapters

   By default, Spine.js saves models in memory, but there are two adapters that can be applied to any model class—Ajax and Local. By simply extending either of these adapters, your data can live in a remote database or even locally using HTML5’s local storage API. All this functionality is a matter of one line of code.

9. Get a Model from its HTML Element

   This is another issue I faced with Backbone.js. I could instantiate a view and tie a model to it, but if I would ever need to reference that data without access to the view instance, I’d be out of luck. Spine.js provides access to an element’s model through a jQuery plugin. Just call the ‘data’ method on the element and you have your model.

10. Logging

    Spine.js comes equipped with a nice little convenience module for logging. In any controller, you can call the log method and it will write to the console with a set prefix. You can then toggle whether or not to trace the logs without removing them.

In Conclusion

Now, this list is why I switched to Spine.js. Some apps might be better suited for Backbone.js, or any other JS framework. If you’re researching different frameworks, definitely take a look at all of them. Do your due dilligence. Make sure whichever framework you choose has a clear example and is free from gotchas. You don’t want to find yourself halfway through development and questioning the framework.

Resources

By default, Spine.app generates an app with Jasmine as its testing framework. I much prefer Mocha.js, so I forked Spine.app to add Mocha.js support. It also includes a HAML compiler and I have plans to include SASS as well as other helpers.

Here are all my javascript bookmarks from my recent high-dive into the language. They consist of links to articles, libraries, and answered StackOverflow questions. Hopefully, they will get a few of you out of a pickle.

I plan to write more about my Spine.js discoveries over the coming months, so keep an eye out if you’re interested.

thumbnail from OrthoIndy

Turn your MacBook eject key into a rimshot button

When I left Adobe, I returned my company laptop. Since then, I’ve been test-driving a borrowed Macbook Air from fellow Studiomate Skylar Challand (Canadians are so nice!). While using the laptop, I realized something strange—even though it lacks a disc drive, it still has an eject key. This is understandable because of the optional USB superdrive, but the last time I actually used a disc drive was to burn the MP3s I downloaded from Limewire.

Half-joking, I tweeted this:

The eject key on the Macbook Air is completely worthless and should be re-mapped to play a rimshot sound.

— Jonnie Hallman (@destroytoday) April 17, 2012

Before the tweet could load, I knew I had to follow through. And within 15 minutes, I had a solution.

Disclaimer: There are probably dozens of easier ways to do this, but this is the first way that came to mind.

1. Download KeyRemap4MacBook

   KeyRemap4MacBook is a free preference pane app. I would describe it, but it’s one of those apps that skips all the cutesy names and tells you exactly what it does.

2. Map the eject key to F13

   Go to the KeyRemap4MacBook preference pane, search for ‘eject f13’ and check its box. I use F13 because, on my computer at least, it isn’t mapped to anything.

3. Download rimshot MP3 from instantrimshot.com

   If you haven’t been to instantrimshot.com, you aren’t telling enough jokes in the workplace. I ended up scrubbing the HTML to find the MP3 file, but you can just download it here.

4. Create Alfred extension to play MP3 using afplay

   I skipped writing a step for downloading Alfred and purchasing the Powerpack because I assume you already have them. If not, 5 points taken from Gryffindor! Open the preferences and under ‘Extensions’, create a shell script as seen below. Ever since Leopard, OSX comes bundled with a binary called ‘afplay’ that lets you play audio files from the command line. Incredibly useful in this case.

5. Create global hotkey for extension

   Lastly, go to the ‘Hotkeys’ tab and create a global hotkey for your shell script and map it to F13.

Try it out and let me know how it goes!

On building and partnering

Early this year, my brother Ben interviewed me as part of a series he’s working on. I talk about design, why I build, and my thoughts on collaboration. Ben recently started his own company as well, Hallman Productions, providing services for video recording and editing.

In case you were wondering about the birdhouse and plant, Ben interviewed me at our parents’ house in PA while I was home for a visit. And no, a tiny bird does not live in that birdhouse. I wish.

Today is my first day at Destroy Today LLC

As mentioned in my previous post, I recently left Adobe. I won’t go into detail about why I left—I just knew it was time. Leading up to my last day, I met with several companies. I figured my next steps would be to join a new company and see where it leads me.

All of them seemed like great opportunities. It was enlightening to talk to people about their future while I was trying to figure out mine. When asked for input on what they should do next, I surprisingly had no problem sharing my thoughts. This on-the-spot kind of thinking allowed me to come up with ideas I never considered, looking years into the future instead of just months.

I showed them my work, speaking thoroughly about the process and sharing the many stories tied to each app. When asked about specific UX innovations in my apps, I turned to DestroyFlickr. I recalled it having a handful of unique features I was really proud of.

Revisiting the app left me a bit nostalgic. I could remember everything about the time I wrote it. I remembered being so excited to work on it I couldn’t sleep. I remembered knowing nothing about designing an app besides what felt right. I remembered celebrating each time I got a new user—reaching 30 was a huge deal.

At that moment, I fell in love with my side projects all over again. I realized I would still work on them no matter where I ended up—they are a part of me. Without a doubt, these side projects are my best work. They are what I’m best known for. They are my passion in life.

Then why are they just side projects?

The decision has never been more clear. It’s time to destroy today, every day. I will work for myself, spending every waking moment just building. I will collaborate with other builders, creating partnerships out of the want to make our ideas real. I will share everything I learn—writing articles and teaching workshops. Whether I’m designing, developing, or both, I will ship quality products. This is what I need to do. I’m ready.

Today is my last day at Adobe

After almost three years with Adobe, it’s time for me to move on. I was first a developer, then a designer, and now I need to be both. I wish the best for my fellow Adobe-ans and look forward to their future work. As for me, that’s for another post. Stay tuned.

I have 15 Art.sy invites