Pete Corey Writing Work Contact

Frontend Workflow - T.U.S.T.A.C.R. Part 1

Written by Pete Corey on Sep 24, 2014.

I recently discovered Firebase, and I’m pumped about it. I wanted to make a small project to try it out, so I figured I’d make a URL shortener. Now, I’m pretty confident that this URL shortener is going to totally and completely rock, so I decided to name it So, with a new small project in the works, I figured that this would be a great time to document my usual front-end workflow. You can see an overdubbed timelapse of the process and read through some of my thoughts about it below.

Sketch In the Browser

I’m a big fan of “sketching” in the browser. My usual workflow involves laying out my base DOM elements and applying some rough styles to get them behaving how I want. After that’s done, I like to open the page in Chrome and start playing with the styles using the Chrome Dev Tools. The immediate feedback is invaluable. Once I land on styles that I like, I’ll clean them up and organize them into my CSS/LESS/SASS files.

CSS Generators

When I’m in a hurry, or want to mock something up quickly, I tend to use online CSS generators (css3factory, css3gen). The visual feedback they give me is pretty useful when I’m designing-as-I-go. I used a few during the couple hours I spent on this project.


On this project, I built the desktop version of the site first and added smaller viewport style changes at the end of the build. After the desktop layout was finished, I simply resized the browser until I found points where the content no longer worked. By “no longer worked”, I mean things like the header looked too large in proportion to the rest of the page, or where text was wrapping or overflowing, or where an element was pushed off of the screen, etc… When I found these places, I added media queries targeting that resolution to fix the issue.

Cross Browser Testing

I’m a huge fan of BrowserStack and I use it for all of my browser and device testing. Unless I am working on a potentially hairy feature, this is usually the last step in my process. I’ll run the site through each of the browsers I’m building for, look for issues, fix, rinse and repeat.

How to Improve

Looking back, there are lots of places where I can improve this workflow. First thing’s first, I should really ditch sketching in the browser in favor of some kind of LiveReload setup. This would eliminate the need to copy styles out of the browser and back into my codebase, and it would totally eliminate the mental context switching I have to do jumping from my browser to my editor.

I should also take more advantage of LESS mixin libraries. I tend to use online generators because of the visual interaction, but a LiveReload setup combined with a nice mixin library might make up for the lack of visual feedback. At the very least, I should transform the CSS I get from generators back into a LESS mixin for readability and maintainability.

Check out the final UI here. I’m planning on building out the Firebase/AngularJS/AngularFire “backend” next week. Stay tuned for another video and a blog post.

Namecheap + Amazon S3

Written by Pete Corey on Sep 23, 2014.

I recently wanted to point a domain I had registered on Namecheap ( to a static site I was hosting on Amazon S3. The whole process was fairly painless. Check it out:

  1. Create a new S3 bucket.
  2. Upload your content to the bucket.
  3. Add a bucket policy to allow anonymous read access to all objects in the bucket:
    "Version": "2012-10-17",
    "Statement": [
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "*"
  1. Enable website hosting on the bucket. Save the endpoint generated for you. You’ll need this to set up your Namecheap CNAME alias.
  2. Browse to the alias and make sure that your site is working as expected.
  3. Now on Namecheap, select the domain you want to link to your S3 bucket.
  4. Go into “All Host Records”.
  5. Add a CNAME alias to the endpoint of your bucket.
  6. Have a beer.

I hope that helps.

Git Bisect and Commit History

Written by Pete Corey on Sep 16, 2014.

Every time I use git bisect I find myself giddy with excitement. The tool is absolutely amazing at tracking down where a bug crept its way into your code. Being able to find the offending commit in minutes leaves me with an unhealthy sense of power over my code base. Sometimes git bisect can lead to an obvious fix if the bad commit is small, but sometimes a large commit can lead to hours of investigation.

When bisecting, I sometimes land on a commit like this:

f934e... is the first bad commit
commit f934e...
Author: ...
Date: ...
   Case #12345. Implemented feature X.

Feature X was huge. This commit touches hundreds of lines and dozens of files. I might have been doing frequency local commits while I was developing the feature, but I decided to be kind to my co-workers and my future self by rebasing everything into a tidy single commit in order to keep the repo history clean. Now, I’m faced with sleuthing through this behemoth to find my bug.

This always makes me question whether I should be rebasing my local commits before pushing them, or leaving them separate and pushing a large chain of commits to the trunk. By squashing and rebasing, you can cleanly revert large chunks of code (whole features) and quickly understand the project history at a glance. By not rebasing, you can quickly find where bugs were introduced and see the history through a more focused lens.

Personally, when working in teams, I try to keep my contributions to the trunk be fully self-contained. If I’m implementing a feature or fixing a bug, I want all of the changes related to that be in a single commit. This means that I squash and rebase my local commits before pushing. However, when I’m working independently, I find that I don’t rebase. I just push my chain of local commits.