Over the past few weeks, I’ve been learning a lot of little tricks and tips from the instructors and mentors at HackerYou – most recently SASS (which I prefer) and LESS, which are CSS pre-processors. To abreviate: they make writing CSS much easier and more awesome. All this is to say that my workflow has increased exponentially since taking the full-time bootcamp course. So I thought I’d detail a few of the things that I’ve stepped up since taking the full-time course, something that every dev should be looking to do to streamline their workflow.
First and foremost, we need to start with what text editor you’re using. Personally, since I’ve started working in HTML and CSS I’ve used nothing but Sublime Text, and I have nothing but good things to say about it (heck, I even paid for it!). I used version 2 for a long while because I hadn’t upgraded my OS, but I eventually caved and upgraded both my OS and Sublime. I didn’t notice a huge difference, but one slightly annoying thing was that I had to re-install all the packages that I had on my Sublime previously. Speaking of which…
This, to me, is one of Sublime’s biggest draws – the ability to create, modify, and install packages created by other users or yourself. One of the most popular ones is a package called Emmet, which you absolutely must install if you’re using Sublime. Sublime will still work if you don’t install Emmet, but it’s a bit like buying a Ferrari and only driving it in the parking lot of the car dealership. People have blogged about all the crazy awesome shortcuts and tricks you can do with Emmet, and the folks at Emmet have actually prepared a handy-dandy cheat sheet for you to reference. Resident web ninja/tool junkie Wes Bos is currently writing a book about how awesome Sublime Text is, and has a few blog posts about how you can visually tweak Sublime Text to help you out (post numero uno, post dos).
Alright, this one may be a little far fetched, but hear me out: you should think about getting an external monitor. I know, I know, it seems a little excessive, but I swear it’ll improve your workflow. I thought having a second monitor was excessive, until I found myself having to constantly have to write code, save, tab over to my browser, refresh, look for the change etc. I know that all these things can be automated to keystrokes, but that’s still time (a LOT of cumulative time) that you could be coding and not tabbing between windows. So after a while, I started looking into getting another monitor. Turns out they aren’t as expensive as I thought they were (mind you, they’re not cheap, but they’re not the $500+ I thought they were for a decent one).
You might even be able to score a good one off Kijiji or Craigslist for cheap – but if you’re going this route make sure that you get a chance to see it actually on before any money exchanges hands, dead pixels are the worst. Even if you’re not going the preloved route, I definitely recommend seeing the monitor actually functioning, and I’d also recommend going to a site like Unsplash, so you can see how the colours and resolution are. Sometimes a monitor looks like it’ll be great, until you try and look at a high res picture with intense colouring and it looks like you’re staring at a crayon drawing of a potato. No bueno, my friends. No bueno at all.
This is my current setup:
In the top monitor I’ve got Sublime going, and I’ve split my window in two – one half has my HTML, the other has my CSS. The laptop below has my browser, onto which I’ve installed a plugin called Auto Refresh Plus which I set up to refresh every 5 seconds – just one more thing that I’ve set up to expedite my work. I’ve also got an external keyboard and mouse plugged in – without it the setup felt extremely uncomfortable and I was working with shoulders hunched up and ruining my back. The mouse is essential because using the trackpad is awful for your wrist, and I (for some crazy reason) don’t want to end up with carpal tunnel.
This is a tricky one, as it’s difficult to do because you’re building the site on your computer and testing it locally. I know that this may not be the most recommended method, but what I like to do is create a directory on an already existing site and test the site on my phone, or a friends iPad if available. As an example, proudfeet.io/wheresdrake takes you to the site that I was testing my Where’s Drake app on before I went and bought my own URL for it (full disclosure: this app is not responsive at all, and probably won’t work properly on your phone). I know that a lot of you might be thinking why I don’t just do this by resizing the browser or using some of the dev tools in the browser. While those are all great options, and generally what I do before I put the final touches on, nothing really compares to the feel of using the website on your phone. What looks great on your screen might not translate the way you thought it would on an actual phone – text sizes may be too large, something might be too far adjusted to the right etc. Mobile site are all about the feel and while resizing the browser will get you pretty close, it’s still no substitute for the real thing. Here’s me testing out my latest HackerYou project on my phone, it feels good to know that the designs don’t just work in theory, but I now have definite proof that they translate well to the device.
Until next time, stay SASSy (womp womp)… I’ll see myself out.