I work with a very talented designer, Kim Pimmel, who consistently knocks out killer work both on the job and in his free time—we share the same hunger for side projects. Earlier this year, he started a short film series titled, “Compressed.” Kim released his second of the series and it does not disappoint. Even after telling me exactly how he did it, I’m still dumbfounded. Below are a few stills along with the film.
Last month, Adobe’s XD department held a ‘hack day’ for developers. Since we only had one day to produce something, I planned ahead and aimed to turn a vintage Simon Says into a build server status indicator. Since patience isn’t my greatest quality, I finished the project weeks before the hack day. I’m glad I did since I had to order many additional parts I didn’t think I needed.
The indicator works by cycling through the colors if the server is building. When the build succeeds, the indicator flashes green. When the build fails, the indicator flashes red. I used an Arduino Uno with a battery and bluetooth modem to make it completely wireless, so it could just hang on the wall, waiting for a build to start. Unfortunately, bluetooth eats through batteries like I eat through burritos, so that foiled my plans. As a tethered device, it’s not exactly practical, so it will lie in a box until the next time I show it off.
If you’d like to take a closer look at the process, visit the lab page.
Since launching the new site and getting back into the blogging game, timing has been very important to me. Most importantly, what is the best time to tweet about a post in order to get the most exposure? This is where Crowdbooster comes in handy.
Crowdbooster is a web service that analyzes your tweets and your followers’ tweets, then generates a bubble chart, indicating the time of the day in which your followers are most active. From there, you can schedule a tweet and avoiding waiting for the right time. It also provides a slew of other data, like follower count over time and retweet impressions, but scheduling has been most useful for me.
At the moment, Crowdbooster is invite-only, but I have five invites to hand out to those interested in trying it out. Since the invites require me to type in email addresses rather than simply link you, I’m going to make it interesting. In the comments, link to your favorite animated GIF and I’ll pick my five favorite. And, by animated GIF, I don’t mean those under construction ones from ‘95. This gem is what I want to see.
Like many developers, I’m OCD about code quality—not only for performance, but appearance as well. When working with generated HTML, it’s difficult to make sure every mixin, include, or partial is correctly indented. Enter Tidy, an HTML-cleaning executable that oddly enough comes bundled OS X. Here’s an example of the syntax:
$ tidy -im index.html
In the above code, the -i flag tells Tidy to properly indent index.html and -m indicates that Tidy should directly modify the file.
This is all well and good for an individual file, but what if you’re working on a large website? Luckily, Bash makes it easy by using a glob, or wildcard. This snippet executes Tidy recursively over every HTML file in the working directory:
$ tidy -im ./**/*.html
Now, if you’re working in a language like Ruby, you probably don’t want to use the command line if you can help it. There are several Ruby Gems that can run Tidy on a string or file, but I’ve had the best luck with Tidy FFI.
For this site, I run Tidy FFI at the tail-end of my Rake script, automatically cleaning up the innards and giving my OCD side some peace of mind:
require 'tidy_ffi'
desc "Tidies HTML files"
task :tidy do
Dir.glob('site/**/*.html') do |path|
content = File.open(path).read
File.open(path, 'w') {|file|
file.write TidyFFI::Tidy.new(content,
:numeric_entities => 1,
:output_html => 1,
:merge_divs => 0,
:merge_spans => 0,
:join_styles => 0,
:clean => 1,
:indent => 1,
:wrap => 0,
:drop_empty_paras => 0,
:literal_attributes => 1).clean
}
end
end
My script sets a handful of parameters that actually prevent Tidy FFI from cleaning too much. If you’re not careful, it will merge elements, and royally screw your CSS if you use nested selectors. View the site’s source code and see first-hand how well Tidy cleans!
Continuing the Jekyll series, today, we build our first Jekyll website. So, where to start?—install the dependencies!
There’s a more extensive list of installation instructions on Jekyll’s wiki for those with a hipster OS, but I’ll get the majority of you started, assuming you already have RubyGems installed. Simply install the Jekyll gem via Terminal and it’ll grab all the other gems that Jekyll requires by default.
$ gem install jekyll
Create a new directory and cd to it. Create a file, index.html, and insert the following code:
<html>
<head>
<title>Hello world!</title>
</head>
<body>
<h1>Hello world!</h1>
<p>This is my first Jekyll website.</p>
</body>
</html>
If you run jekyll now, Terminal should spit out a warning about a missing _config.yml file—ignore this for now. Terminal should also indicate a successful build of the site, creating a _site directory with your index.html in it. And just like that, you compiled a Jekyll site in the simplest form.
As-is, you should be able to open the index file in your browser of choice and see the result. However, as you dive deeper, you’ll want view it as one would see it on the web. Jekyll gives you the option to run a server on localhost, providing a real-life testing environment. Simply add --server $port to the end of your jekyll command, replacing $port with the port of your choice. I use 1337 for the obvious reason—I’m a baller.
Note - Jekyll’s server disregards .htaccess files, so if you rely on one, I’d suggest using an app like MAMP. It’s free and doesn’t require you to keep a Terminal tab open.
Along with --server, you can add --auto to make Jekyll watch your source folder for changes. If it detects any movement, it’ll recompile. I don’t use auto-mode as much as I should because it only indicates when a file has changed, not when the recompile has completed. For larger sites, I prefer to know exactly when the new content is visible.
By default, Jekyll uses the source files from the top-level directory and outputs the generated files to that _site folder. I’m not a fan of this, so I use a different file tree that I specify in the configuration. I suggest you do the same by creating a _config.yml file in the top-level directory and adding the following code:
source: ./src
destination: ./site
Now your source files live in the src folder and your generated files live in the site folder. Move your index.html file to the source directory, run jekyll, and the file should now appear in site.
There are a ton of parameters you can set in the config file, but I’ll only touch on these for now. If you’re curious like me and want to jump ahead, check out the list of options on the wiki.
Note - Jekyll disregards any directory or file prefixed with an underscore, which is why it doesn’t copy the _config.yml file into _site. Keep this in mind going forward.
Layouts are one of Jekyll’s high points, especially when nested. Start by creating a _layouts directory inside of the source folder. Make a default.html file, which will (obviously) be the default layout used by your pages.
Copy the contents of your index page to this file, but replace the title and body, like so:
<html>
<head>
<title>{{ page.title }}</title>
</head>
<body>
{{ content }}
</body>
</html>
Jekyll utilizes Shopify’s Liquid framework for variables and processes within a page. I’ll be sure to write a post dedicated to Liquid, but for now, you might want to familiarize yourself with it.
Every layout must contain a content tag, telling Jekyll where to place a page’s content. As mentioned in the intro, you can nest layouts, where a layout’s code will replace its layout’s content tag. It might sound a bit confusing right now, but once you use it first hand, you might find yourself tap-dancing with joy.
The above code also inserts the page’s title inside the <title> tag. Jekyll provides a slew of variables, detailed on their template data wiki page. Pretty much any metadata you specify in a page’s metadata can be accessed with the page variable.
After adding your first layout, return to your index file and replace it with the following code:
---
layout: default
title: Hello World!
---
<h1>Hello world!</h1>
<p>This is my first Jekyll website.</p>
There are two parts to a page—the metadata and the content. Jekyll uses YAML to set variables for each page. It’s like XML, but without the opening/closing tags. Also, it’s very strict when it comes to whitespace, so take a moment to read up on it if you’re unfamiliar.
The metadata lives between two sets of three dashes, as seen above. Those dashes indicate that Jekyll should process this page. Before, when we had plain HTML files, Jekyll only copied the file without processing it because it lacked the dashes. In theory, you could have a page beginning with two lines of dashes, the content, and nothing else. Even so, you should, at the very least, specify a layout and title.
The content then lives below the metadata. For pages, the content must be HTML. It could be other formats, like HAML or Markdown, as long as you include the appropriate converter, which I’ll touch on in a future post.
Run jekyll one last time and it should generate the same content we had when using the plain HTML file.
I’m going to stop myself here before I go beyond a simple ‘hello world’ example. If you have any questions, be my guest and ask away in the comments. In the series’ next post, I’ll help you build your first Jekyll blog, utilizing ‘posts’ instead of ‘pages’ and Liquid loops. Until then, experiment!
Thumbnail photo by oskay
The best part of releasing a website or app is getting to the point where you can casually tweak things. I decided to have a little fun and set image backgrounds to the checkered canvas Photoshop uses to indicate transparency. It’s incredibly simple, requiring only a repeat background in CSS, but effective nonetheless. Below is the code and you can download the checker asset here. Feel free to use it on your own site.
img
{
background: url(/assets/checker.png);
}
Now that destroytoday.com runs on Jekyll, there are two sets of files—source and destination. Source, in my case, consists of HAML, SASS, CoffeeScript, and Maruku files. They are converted into HTML, CSS, and JS—the destination files. When checking into Git, I would commit both sets so Beanstalk could deploy the destination files. This means changing a single source file results in a commit of potentially dozens of files and a nightmare of a changelist.
I decided to improve the process a bit by investing in a Linode virtual private server—a setup without restrictions. This weekend, I was able to configure a system that builds the destination files in the background whenever I push to Git. There goes the need for Beanstalk, saving me another monthly bill to pay, and by installing Git and Gitosis, I get unlimited collaborators and repos free of charge.
With Linode, I also get root access, so I can pretty much do anything I want without waiting on anyone to set something up for me. I choose the OS and partition size, then, with a single click, I have a server. If I ever need to reboot the server, I can with the press of a button. Even if I’m on the go, I can use the Linode Manager iPhone app to check the server status and reboot if I need to. I’ve never had this level of freedom with a host before. If you’re in the market for a new host, take a look at Linode—they know what they’re doing.
Today, I received my most recent Fab.com order, a S’well water bottle. I’ve been anxiously awaiting its arrival because of two reasons: 1) I am the reigning king of stacked cups at Adobe, and 2) I needed a bottle to use with my Freaker.
The S’well bottle has a beautiful, slim, steel design and the company donates 10% of its proceeds to WaterAid. The Freaker is a cozy that fits any bottle size. It’s also a Kickstarter success story, made in America, and determined to rid the world of moist handshakes. Mine has a Maniac Mansion-esque robot on it, and there’s nothing greater than Maniac Mansion.
Why am I writing about these? Because I’m a sucker for great products that support a good cause. And, when you love something, share it with the world.
The most exciting aspect of the destroytoday.com reboot is the technology involved. I grew tired of the same old starting point of installing Wordpress, configuring, theming, and rushing the release. A half-designed website is twice as hard to maintain. With an unknown world to discover with Jekyll, the exploration and experimentation fueled my interest and kept me on track to release a well-groomed site when the time was right.
Now, what is Jekyll exactly? Its Github page describes Jekyll as “a simple, blog aware, static site generator.” Well said. It takes a source folder of templates and spews out HTML files using a number of helper languages—YAML, Liquid and Markdown by default.
+ src
- index.html
+ _layouts
- default.html
- blog-post.html
+ blog
- index.haml
+ _posts
- 2011-08-09-an-introduction-to-jekyll.maruku
+ site
- index.html
+ blog
- index.html
+ an-introduction-to-jekyll
- index.html
Upload the static pages to your FTP, pocket the source files locally, and now you have a site that is faster and more secure than any of the server-side blog engines out there. No CMS, no database—every page and blog post is a single file with a YAML config at the top and any content down below.
Because Jekyll uses YAML, configuration is clean, easy, and flexible. A page’s config could merely indicate which template to use:
---
layout: blog-post
---
Or, it could reflect the mood you were in when writing the post (if you’re still nostalgic about LiveJournal):
---
mood: nostalgic
---
Simply put, there are no required parameters. And, if a post has a mood parameter, that doesn’t mean every post needs it. As opposed to traditional databases, the world won’t end if a post strays from the common scheme.
Along with flexible configuration, Jekyll includes a versatile templating system—it’s dead simple too. The only requirement is a content tag, which tells Jekyll exactly where to put the page’s content. It supports nesting, so a template could have a template of its own, preventing the need for heavy, all-in-one templates. “Includes” are available as well to reduce boilerplate and de-clutter your code.
The last thing I’ll touch on is plugins. If you’re familiar with Shopify’s Liquid templating system, you’ll feel right at home. Jekyll promotes Liquid “filters” and “tags” as a way to add additional functionality without having to fork it and tamper with the innards. There are also “generators” and “converters”. Generators create additional pages, like tag or category index pages. Converters let you to run code on a page’s content if it matches a specific extension. These are extremely helpful for those looking to use preproceesors like HAML, SASS, and CoffeeScript.
That’s Jekyll in a nutshell, without getting our hands too dirty. In the coming weeks, I’ll dive into each section on a deeper level, sharing code examples and tips I found extremely useful in the process of developing destroytoday.com. If there are specific topics you’d like to know more about, let me know in the comments and I’ll be sure to touch on them.
Finally—one word that encompasses the past four months. I’ve been head-down redesigning and redeveloping, all the while relearning the web. A few years back, I took a break from all the HTML and CSS hoopla to focus on desktop and mobile development. It’s incredible how much the web has improved in such a short period of time. Everyone is telling IE to get bent and new shorthand preprocessors pop up every day. I love it.
The new site features a number of those preprocessors and then some. I took it as a chance to acquaint myself with the new tech and build a creative outlet for the many side projects that don’t see more than a single blog post. As an avid Github user, I stumbled across Jekyll, a static site generator with endless possibilities. Great beauty lies in a CMS-less, database-less website. If its loose-configuration and recursive templating doesn’t attract you, its generators, tags, and filters will.
Regarding the visible change of the site, it now houses dedicated pages for work and experiments—no more lazy-linking to Github. The lab has a handful of throwback projects from my outside-the-box years. The plan is to rejuvenate the other side of my brain and get back into the short-commitment, highly experimental routine that I so very miss.
As for blogging, Jekyll itself garners enough to write a book or two, but I don’t have a publisher, so a few posts will have to suffice. I’ll run through Jekyll, Haml, Sass, Liquid, and CoffeeScript over the next few weeks, detailing how best to introduce yourself and get them all working together. Until then, check out the rest of the site and let me know what you think!
