I’m always fascinated by other people’s workspaces. I’m not the only one. Plenty of posts and entire sites, even, have been devoted to this subject. You don’t have to look far on Tumblr, Pinterest, or Dribbble either.
I thought I’d share my own.
On the Wall
Behind my computer, I have a bulletin board for inspiration and mood boards. It’s made out of Soft Tiles, you know, the mats you put on the floor for kids to play on. We just hung it up on the wall with nails. Perfect.
Also on the far left (you can see the edge of it), I have a Epson Perfection V100 Photo Scanner. It’s not the latest and greater scanner out there, but it’s more than perfect for what I use it for: scanning in textures, photos, and hand drawn illustrations — things that need to be scanned at a higher resolution.
For on the go, scanning, I’ve been really pleased with Evernote’s new app, Scannable.
I have an iPad Mini. I was an early adopted and started out with a 3G iPad 1. Eventually, it started having issues where apps would randomly crash. I upgraded to a wireless iPad mini for Christmas. I love the smaller size. I use it for reading (and testing websites), so the smaller size makes complete sense.
They’re connected to my laptop via a TripleHead2Go. (I wrote a post about the configuration.) I can keep the laptop open, and run in a T configuration, but lately, I’ve enjoyed keeping my laptop in clamshell mode. For whatever reason, I feel more productive instead of trying to manage more space.
I have a 15” MacBook Pro (Retina), 2.6 GHz Intel Core i7, 16GB of Memory, with a 1TB Solid State drive. It’s been a great machine. It’s the 3rd Mac Laptop I’ve owned in the last 11 years. I ran its predecessor into the ground.
Even though I know I need the real estate and power for print projects…and I can’t imagine trying to run Chrome Inspector tools on a smaller screen, I still eye the Air. I can’t get over how small and light it is!
I have a wireless keyboard and trackpad. I try to get away with as few wires as possible. The track pad and I have a love hate relationship, so I’ll still pull out my Magic Mouse (It’s not the track pad’s fault, it’s all me. I’m just old school like that.)
My desk is an Ikea desk top (hollow) with Vika Fagerlid legs (apparently, they don’t sell them anymore).
Lastly, you’ll see my moleskine. I do all design work, there, first. – ideas, wire frames, illustrations, everything. — And I’m kind of a pen snob, too. Pilot G2 0.7.
In the Comments
What are some of your favorite pieces of your workspace?
What is git anyway? Short answer: version control. Long answer: Think of it as having unlimited undos on your code. Or better yet, if you’re collaborating with another developer, it allows you to both work on the same project without overwriting each other’s code. Awesome!
This has saved my butt on more than one occasion. I’ve vowed to always use source control, regardless of how big or small the project is.
So, now that you’re interested in git, where do you begin? To get started, you’ll need to install git on your local machine (don’t worry, I’ll explain). Eventually, you’ll want to use an online service to store your code, like GitHub, BitBucket, or Beanstalk. (more on that below, too)
Installing git Locally
I use a Mac, so unfortunately, I can only speak to that. However, if you’re using another operating system try looking here.
The easiest way to to install Git on your Mac (if you’re on Mavericks or older) is to install the XCode Command Line Tools. This is as simple as trying to run git from the Terminal.
Remember, when you’re working in the Command Line, the dollar sign ($) is the prompt and signifies a new line. No need to copy it.
If you don’t have git installed already, it will prompt you to do so.
If you want a more up to date version, or would rather run the binary installer, you can grab that here.
The first thing you’ll want to do is configure your git settings.
Git is typically run from the Terminal. However, as a designer, I tend to be a little leary of the Termianal. Granted I’ve gotten more comfortable, but I still prefer a GUI (Graphical User Interface) when I can get one.
I think the easiest thing to do is learn the vocabulary. Then, it doesn’t matter whether it’s the Terminal or GUI, the same concepts apply no matter what.
Let’s walk through this as you would for a real project.
You’ll want to create a folder on your computer for your project. In my user folder, I have a folder called Code. Then, a subfolder called GIT. I keep all my project folders there.
If you’re trying to do everything from the command line, these commands create a new folder and then navigates inside:
$ mkdir new_project
$ cd new_project
Let’s initiatize our git repository. (All your git projects are called repositories.)
$ git init
So what does initializing really do? It creates an empty repository in a hidden folder, .git.
If you ever wanted to remove the repository, all you’d need to do is delete that .git subdirectory:
$ git rm -rf .git
Notice, I said empty. It did not add the current content within your folder. You have to tell it to do that yourself.
All the content within your project folder is considered the working copy. Once you get to a place where you want to save those files, you’ll stage your changes and then commit them to your local repository.
The advantage here is not all of the files you’ve modified since your last commit have to be staged and committed.
Let’s get an overview of everything that has changed since we last committed:
Git will put your changes into three main categories:
Changes not staged for commit
Changes to be committed
You can add all these changes by using:
git add .
If you don’t want to add the changes you’ve made, but cherry pick files, you can list them out:
If we removed a file, we’d need to confirm that too:
git rm something.html
Now, let’s commit our updates:
git commit -m "Initial commit"
The first commit, I usually title as “Initial commit” but as you continue to make changes and commit your code, you’ll want these messages to be meaningful. This will make it easier for you (or your teammates) to understand the changes you made later down the road.
Your message should include information like, “What was the motivation for the change? How does this differ from the previous version?”
If you need a longer commit message than 50 characters, you can leave out the “-m” parameter and Git will open an editor application for you to write a longer message.
Related Changes A commit should only contain changes from a single topic. Don’t mix up contents from different topics. This will make it harder to understand what happened.
Completed Work Never commit something that is half-done. If you need to save your current work temporarily in something like a clipboard, you can use Git’s “Stash” feature. But don’t eternalize it in a commit.
Tested Work You shouldn’t commit code that you think is working. Test it well — and before you commit it to the repository.
Short and Descriptive Messages A good commit also needs a good message.
If you want to review a history of all the commits that have been made to a project:
You’ll see a list in chronological order, beginning with the newest item.
If there are more items than what can be displayed on one page, you’ll see a : at the bottom of the screen. You can go to the next page by hitting the <SPACE> key and quit with “q”.
You’ll notice from the log, every commit has:
Commit Hash This is that crazy long string of letters and numbers (i.e. aa093b890c78e9d0869a3f267b2530cf2cbeb83f)
Author Name and Email Remember when we set our name and email address within the git configurations above? This is where it gets used.
Now that we’ve made a bunch of commits, let’s publish (or push) them online. First we need to tell Git where our remote repository is.
There’s several services you can use, three of the most popular ones are:
In this case, we named our remote repository “origin.” This is the default within Git. However, I could just as easily name it something else. I usually name mine based on where the remote repository is. This makes it easy within Tower (my GUI of choice) to tell where it’s being saved:
You’ll notice there are two URLs listed (fetch and push). One is for read access (fetch) and the other is for write (push). Uusally, the two URLs are the same, but you could use different URLs for security and performance issues.
Now, we need to push our code up to our remote:
$ git push origin master
Hopefully, some of these things are starting to look familiar. origin is the name of the remote repository and master is the name of our branch. (We haven’t talked about branching yet. It’s OK, just trust me for now, but it’s coming.)
Let’s pause for a moment. I just want to take a moment to point out: you’re more than halfway there! It wasn’t that hard, was it?! You know everything you need to know to save, commit, and publish your files online! There’s still more topics to cover, but you already know the basics. That’s worth celebrating!
OK. So far, we’ve just published our changes online. But, what if we’re collaborating with another developer? They’re publishing their changes too. How do we pull down there code?
First you may want to see what you’re pulling:
$ git fetch origin
$ git log origin/master
If you want to integrate these changes into your local working copy:
$ git pull
If you have multiple remotes and branches, you may need to specify:
$ git pull origin master
OK, so let’s (finally) talk about branching.
When you’re coding, there are usually several different contexts or “topics” you’re working with:
In the real world, these all happen simultaneously. You’re trying to fix a bug while a teammate is working on the new about page design.
If branching didn’t exist, how would you integrate some of these changes, but not all of them? You need to post the code for the bug fix, but your teammate isn’t ready to launch the new about page. You find out the new “members only” code you’ve been working on is going in a different direction, but you’ve already integrated that code in with everything else. How do you separate it out?
You can create a branch to handle each of these topics. It stays separate from all the other contexts. When you make changes, they only apply to the current active branch.
Your current branch can be referred to as the active branch, checked out branch, or HEAD branch. They all mean the same thing.
Whenever you run git status, it will tell you what branch you’re currently on.
You may have noticed from my screenshots, that my Terminal shows me what branch I’m in and changes color based on whether I’ve there are uncommitted files or not.
Think of the Stash as a clipboard on steroids: it takes all the changes in your working copy and saves them for you on a new clipboard. You’re left with a clean working copy, i.e. you have no more local changes.
To stash your local changes:
$ git stash
To see an overview of all your current stashes:
$ git stash list
The most recent Stashes will always be listed first.
When you want to apply a Stash, you can run:
$ git stash pop
This will pull the latest Stash and clear it from your clipboard. Or
$ git stash apply <StashName>
This pulls the specified Stash, but unlike pop, it remains saved. To delete it, you’ll need to run git stash drop <StashName>
These things are all great, but what if you’re not starting from scratch? What if you’re joining a project that already exists?
There will be times when you don’t want to put all your code within your repository. For example, if you’re using bower, you probably don’t want the bower_components folder. Or, if you’re running grunt or gulp, you don’t need node_modules. A teammate only needs to run bower init or npm install to get those files. Committing them would only bloat your repository.
You can create a file called .gitignore and list all the files or folders to exclude. For example, here’s my .gitignore file for a WordPress project:
There are several services that you can use to host your remote repositories.
GitHub is probably the most popular. If you make your repositories public, then you can create an unlimited number of repositories for free. You start paying when you create private repositories.
Even if you don’t plan on paying for a GitHub account, I would highly recommend signing up for an account anyway. GitHub has practically become a standard for developers. Meaning, if you’re applying for a programming job, your potential employer could ask to see examples on GitHub.
I actually store all my code on BitBucket. BitBucket does everything that GitHub does, but is missing the community that surrounds GitHub.
For me, the decision came down to $$. GitHub’s business model revolves around the number of private repositories you create. BitBucket’s bases its pricing tiers on the number of users. As long as you have under 5 users, it’s free.
As a one-woman web shop, I was easily in the top tier with GitHub. But, with BitBucket, I can have as many free private repositories as I want. That’s a no brainer.
BeanStalk is another great service. Like GitHub, you’re paying based on the number of repositories you use.
It’s missing a lot of the features that the other two services provide, but the biggest benefit it has is built in deployment. Meaning, you can push changes to your repository and it will automatically send those updates to your server via FTP (or however you specify). That’s almost enough to make me switch.
In the meantime, I’m using dploy.io instead. It’s made by the same company (WildBit) that makes Beanstalk. Dploy.io allows you to deploy commits from BitBucket or GitHub. Pricing is based on the number of repositories you’ve connected.
OK, now that you know the correct terminology, I want to introduce a few GUIs:
I use Tower. IMHO, it’s the best. Just from glancing at the screenshot, you can see the buttons along the top for most of the vocabulary terms covered in this post. If you want a little more information, check out this screencast (from the Tower app team):
Sync your devices. If you’re not paying for Creative Cloud, you can only have it running on one device at a time.
Click on the browser extension. Then, launch the app on your iPhone / iPad (your devices must be on the same wireless network). It will give you a passcode to enter.
Now, any page active in Chrome will automatically load on your device.
If you click the < > it will pull of Chrome’s developer window.
Click on the device you’re using in the Web Developer panel
It will load the Inspector panel. Any code you highlight will then be highlghted on your device. = SUPER COOL!
Couple this with LiveReload (Bonus)
I also found a program called LiveReload. In web development, there’s a lot of change the code, save, reload the browser. Make another adjustment, save, reload. Rinse and repeat. This program simplifies that process, so that when you save your file, the browser will automatically be refreshed.
A blog post on Adobe’s site had instructions for integrating this new workflow with LiveReload with Edge Inspect. (Before you get confused, Edge Inspect used to be called Shadow)
As I do more and more mobile web development, I know that these tools will prove invaluable. What are other tools you use when developing for your mobile devices?