Tag: #front-end-web-development

Running BrowserSync with Jekyll

BrowserSync is a tool for injecting changes when working on your local site project and then refreshing your site on save. Perfect for designers/devs who need one tool for one job.

I couldn’t find any clear instructions on setting up BrowserSync with Jekyll alone (no Sass, no Grunt/Gulp) so here’s the command to get it working after you’ve gone through the install and you have changed directories to your projects folder root:

browser-sync start --proxy "localhost:4000" --files "_site/*.*"

This command will watch the entire <strong>_site</strong> directory rather then just your CSS folder. Note that you will still need to run the normal jekyll serve command in a separate Terminal tab or window, but your site will be view-able in the BrowserSync URL: localhost:3000.

Moved to Jekyll

I recently converted this blog to Jekyll from WordPress and am now using GitHub Pages for hosting. I didn’t move over specifically because of problems with WordPress, but because of the following:

  1. The dev-specifc way of publishing posts with Jekyll (edit in code editor, having everything in version control, review changes, push via Git, boom)
  2. Being able to use GitHub as a hosting platform for free
  3. Ease-of-use with pushing site style updates (which is nice for me with this sites style changing so much)
  4. Portability of the site due to no database. If for some reason hosting on GitHub doesn’t work out in the long-run, it won’t be a problem to simply move my local directory.
  5. I’m no longer looking for a WordPress-based development job, so learning more WordPress isn’t necessary. More on that in another post.
  6. Automatic, two-factor backups via Git and storing local folders in Copy.app (affiliate link).

It wasn’t that big of an ordeal and yes, you can do it to. There are however, a few caveats worth mentioning:

GitHub’s own guide to Jekyll will be invaluable and you will be using it a lot. Pay attention especially to The GitHub Way of structuring the files/folder layout of your Jekyll project. For me, looking at other Jekyll projects like Dan Eden’s personal site also helped with determining where files should go.

Jekyll is Ruby-based and as such, you should make sure your own Ruby environment is clean and that you’re using the most current version of Ruby that Jekyll support. Since I don’t work with Ruby, OS X’s version of Ruby that’s included with Mavericks was behind and I had to update it in order for Jekyll to run.

I ran into an issue with the RSS feed, but that was solved by finding a valid feed on GitHub (like this one from the Hyde repo) and then “burning” the feed with FeedBurner. I also needed to adjust the site.url YAML front matter in _config.yml to reflect my site’s url.

Jekyll repo’s worth checking out:

A New Site

The first domain I bought was my previous site: andrewcodes.com. It started life as a static, HTML-and-CSS-only, one page, fixed-width site. And at that time, that first launch was glorious. It ​was very gratifying being able to release something to the Internet that I created. That first site started the ball rolling of my love of web design and creating for the web.​​

This new site is a little different from my first. It’s built responsive from mobile on up, it has a few pages (with more on the way), and it’s built on WordPress.​ ​This is a scratch built theme using a simple WordPress reset.​ It also combines my landing/portfolio page and my blog (which were separated before as a domain and subdomain, respectively)​ into one site. I spent a lot of time on the performance and load time of this version as you can see below:

The end-goal with this version, is to release it properly on GitHub as an open-source theme. It’s not at all ready as I still have more to learn about Git. But this public theme will be a chance to hone my WordPress and GitHub skills and build something that would be useful to other people.

Podcasts for Front-End Developers and Designers

My daily commute to my job is forty-five minutes each way and on days that I don’t listen to music, I listen to podcasts. It’s nice to put that empty time to use by learning something new. Here are my favorite three podcasts that I listen to:

Shoptalk Show

The Shoptalk Show consists of Chris Coyier and Dave Rupert and usually they’ll have a guest on as well. Their focus is on Front-End development, nerdy jokes, “hot drama”, and sometimes Back-End development. Three episodes that are favorites of mine are:

Sometimes the audio quality is lacking but it’s not a deal-breaker by any means.

Draft

A design-specific podcast that focuses on designers telling stories of how they have tackled challenges and how to find inspiration. Besides design, they also talk about interacting with clients as well.

This Developer’s Life

This is a podcast that I just recently started listening to and has a much different feel/tone than the others. Created by Rob Conery, this podcast is more about developer’s telling stories about specific issues in their own careers and on projects they’ve worked on. It’s a show of how developers have overcome their own obstacles and risen above. The podcast is done in a very different format and is a welcome change. Also, the audio quality is absolutely excellent.

Leave a note in the comments if you have any to add to the list.

CSS Reset vs. Normalize

I was listening to the Shop Talk show to the other day and they had Paul Irish as a guest. If you don’t know who Paul is, he’s the one who created the HTML5 Boilerplate, CSS3Please, and various other tool-type sites that are awesome and super useful.

Paul mentioned that they’ve switched to normalize.css on the latest version of the HTML5 Boilerplate instead of using reset.css. normalize.css has some reset functions but also keeps some default styling intact as well.

I tried using normalize.css on a project the other day but realized I still like Eric Meyer’s reset.css a lot more. Using a reset gives you a clean slate to build your CSS which is my favorite part about it. However, creating your own “boilerplate” is even more valuable. If you find yourself re-writing code because your reset already cleared it, you should then modify your reset to fit your own needs. I like to take code, em, pre, and strong, out of the normal reset flow because I always use one or all of those tags in my projects.

Re-design Euphoria

A disclaimer: this post has been in my drafts since about version 3 of this site. I’ve added them up (including the designs that never made it) and I’ve created about 27 variations of this site. Yes, 27.

Creating a website design for someone like myself who is not particularly artistic, is a laborious, frustrating process. Yet at the end, I have something to show others for it. Code, at its core, is hidden. To view the code for this site, obviously you would right-click on a non-image part of the page, and click on “View page source”. Not too many non-developers are inclined to do that. So I’ve been spending more time on design then content, when it should be the opposite.

This more simplistic, minimal design took me about three total hours to make everything the way it is. My sister (an amazing print designer) could have designed this site in five minutes. And that’s giving her three minutes to sip on some coffee.

I’ve re-designed this site again to include just the basics. The goal is to stop trying to make this site look pretty and produce more content. Musings about development and finally adding items to my Projects/Portfolio page are on the way.

Faster

Everyone wants a faster loading website. One tip that I came across the other day is to move your scripts that you would normally include in the head tag down to just above the closing body tag. Since your website starts loading from the top of your code to the bottom, the extra scripts at the bottom will load last enabling your main, view-able content to be loaded faster.

Follow the link for more speed tips.