Running WordPress? On shared hosting? Does the word caching make you nervous? Well worry no more. Here’s your beginner’s guide to caching in WordPress in just three easy steps:
And that’s it folks. I’ve installed Quick Cache on most of my sites in the past month or so and it does make a substantial difference to page load times. Enjoy!
I read Hacker News a lot. Its probably become one of my favourite websites in the past few years, and so went to read it over the weekend on my phone I was a bit shocked at what I saw:
Totally unreadable. And there’s really nothing you can do with this page to make it better. Double tapping to zoom in doesn’t help, nor does turning the phone sideways. Manually zooming in on a screen with no set bounds is a disaster too. See:
Here it is double tapped:
Here it is in landscape:
Double tapped landscape:
None of these make reading Hacker News fun, so, disappointed I gave up.
I’ve done a reasonable amount of responsive design work before—making pages respond to set window widths. While this is extremely nifty, its far from fluid. With responsive design, you can use media queries to set defined defaults based on common screen sizes or devices. The bottom of your stylesheet might look something like this:
/* Window widths between 768px and 991px */
@media only screen and (min-width: 768px) and (max-width: 991px) {
article {
width: 550px;
}
}
/* iPhone standard layout: 320px. */
@media only screen and (max-width: 767px) {
article {
width: 280px;
}
}
/* iPhone wide Layout: 480px. */
@media only screen and (min-width: 480px) and (max-width: 767px) {
article {
width: 400px;
}
}
If you’ve never used media queries before, this is still fairly readable. It simply changes the width of the article element when the window size changes. This works extremely well, but its hardly fluid.
After my sad experience with Hacker News, I was determined to finally figure out this fluid grid thing. A quick googling led me to all the main players (Blueprint, 960, etc) but 1140 struck me as being really simple and straightforward. And it is.
Setting up a layout with 1140px is (mostly) just as easy as this:
And of course things stay proportional when the browser gets resized:
This certainly doesn’t kill the need for media queries and targeting mobile browser sizes, but at the very least it should provide your users a better viewing experience—at all their browser widths.
If you haven’t yet made the leap from pixels to percents, have a look at 1140. I suspect you’ll be glad you did. I certainly wish/hope Hacker News would.
Development workflow is an extremely personal (read: contentious) thing. Everyone has an opinion and a way that they do things, and yet we get challenged every day with a swath of new tools designed to make our development faster, easier and more productive.
I’ll just start writing and see how many I come up with: LESS, SASS, Codekit, Compass, LiveReload, Jade, HAML, Coffeescript, Stylus, SLIM, Eco, etc, etc. That’s a lot already, and its barely the tip of the iceberg. In the past few years, I’ve tried almost all of these, and here’s a few notes on what I use:
It took me a long time to finally get around to LESS. I had it all bundled together in that huge pile of stuff that I wanted to learn one day. I’m extremely glad that day come a few months ago.
LESS gives you variables, nested rules, mixins, functions, and all sorts of other goodies that I don’t use yet. Here’s a quick example of how I use LESS on a daily basis, and how it makes CSS writing easier and more enjoyable:
@mainbg: #efefef;
@maintext: #444;
#main{
background: @mainbg;
color: @maintext;
float: left;
a {
color: lighten(@maintext, 5%)
background: darken(@mainbg, 25%)
}
article {
width: 450px;
float: left;
h2 {
font-size: 25px;
color: darken(@maintext, 20%)
}
}
}
So what have I actually used here? I’ve used LESS fairly minimally here as you can see. I declared two variables at the top: a background colour and a text colour, which I lighten and darken at various points. And I used nesting: see that H2 underneath article? of course those rules will only apply to an article’s H2. Pretty sweet. Likewise, all of those rules only apply when they’re contained in the #main div.
As you can see, none of this is a huge shift. It isn’t complicated, and after you’ve written it a few times, it actually makes more sense. It’s pretty easy to see that writing this:
article {
width: 450px;
float: left;
h2 {
font-size: 25px;
color: darken(@maintext, 20%)
}
}
Is a lot better than writing this:
article {
width: 450px;
float: left;
}
article h2 {
font-size: 25px;
color: #3f3f3f;
}
You can imagine that for even a small site, those style rules that nest underneath article will add up.
One last LESS benefit is the magical lesselements. I say magical because it is. Remember all those browser-specific prefixes you used to write?
#main{
-webkit-border-radius: 5px
-moz-border-radius: 5px
-opera-border-radius: 5px
border-radius: 5px
}
That truly is terrible to look at and onerous to write. With lesselements, all you need to do is write one rule:
#main{
.border-radius(5px);
}
And lesselements automagically prints out the browser prefixes for you. And you sleep better at night.
Good question. The best place to start is with LiveReload. Can you even come up with an estimate of how many thousand times you’ve hit Cmd+R in your development career? With LiveReload, you’re done with Cmd+R. Now, all you need to do is save the file, and your changes will magically appear in the browser window—without Cmd+R. Just reread that again if you need to. No more refreshing the browser window—just hit save and you’re done.
But that’s not all the magic that comes with LiveReload. Not by a long shot. Remember all that LESS stuff we mentioned a few minutes ago? LiveReload’s your uncle for that too.
So you’ve written some extremely cool LESS and you’re dying to get it up there on a site you’re working on. But! LESS isn’t quite as easy as CSS—LESS actually needs to be compiled before you can use it. Queue the sad panda parade.
But despair not!
All you need to do is tick off the compile button in LiveReload and it will convert (compile) your style.less file to style.css. Your website never needs to know about the LESS file, and technically never knows you’re even using LESS at all. The LESS file you write gets compiled into CSS when you hit save, and that’s all your website sees.
So that wraps up Part I. I really hope this was enough to convince you to give LESS a try. It really is better than plain-old CSS, and without all that headache and overhead you were expecting. And if you’re not yet using LiveReload, now really is the time. Since I started using it about 2 months ago, I use it all day, everyday and I can’t imagine doing without it. Cmd+R is ancient history.
In Part deux, I’ll run down how I deploy/launch sites. Spoiler: I haven’t used an FTP client in years.
I’m trying to make 2012 the year I finally learn to code. Not HTML/CSS/jQuery, but actual code—you know, if statements, and things like that.
So just a few days after Christmas, I chained myself to my desk and cracked open my worn copy of PHP/MySQL Development and a Lynda.com essential training course, and started in. I don’t think I lasted more than a few hours that first afternoon. Its not that I don’t get PHP, I think I just can’t stand it. I distinctly remember where it all went off the rails. See the screenshot below.
What a complete mess. Sure, I can read it, and for the most part I know what it says, but it does require some mental energy to just process and decode the structure of it. It just isn’t welcoming. My first instinct when I look at code like this is to sigh at the pain of having to mentally organize it before I can figure out what its doing. That’s aside from the fact that all you can really see are < and > signs, question marks, brackets and semicolons.
I’ve known this about PHP for a long time. I’ve struggled with getting beyond the beginner’s stage with it at least a half-dozen times in the past few years. I always get fatigued, normally stop at the same place, and then get too busy and move on to something else after a few days. I’ve just never been able to find any traction, never been able to really dig in.
I say again, because this certainly isn’t my first brush with Ruby either. I’d done a few tutorials and done the magical TryRuby thing, and thought it was really cool. But I’ve gotten hung up on the complexity of Rails more than once. And don’t let anyone tell you it isn’t complex. When you dive into Ruby and Rails you get it all thrown at you at the same time: object oriented programming, an MVC framework, Ruby gems and their dependencies, Rails ‘magic’, etc etc.
It’s quite a lot to get your head around—and until you have at least a tiny, tiny amount of knowledge about each, you’ll never get anywhere. Ruby is 100% object oriented (still figuring that out), Rails lives and breathes MVC (a paradigm I’d never used before), and figuring out gem bundle install errors and dependencies will make you old long before your time. In short: its tough.
But this time, Ruby’s simplicity, elegance and readability was always there, pulling me along the whole time. Just have a look at this excerpt from a program that fetches and downloads webpages from Wikipedia, from the fantastic Bastards Book of Ruby:
require "open-uri" remote_base_url = "http://en.wikipedia.org/wiki" remote_page_name = "Ada_Lovelace" remote_full_url = remote_base_url + "/" + remote_page_name puts "Downloading from: " + remote_full_url remote_data = open(remote_full_url).read my_local_filename = "my_copy_of-" + remote_page_name + ".html" puts "Writing to: " + my_local_filename my_local_file = open(my_local_filename, "w") my_local_file.write(remote_data) my_local_file.close
It is long, and probably doesn’t make sense to you, but just try reading it line by line. It basically sets a base url (the base Wikipedia url), adds the name of the page we want to fetch (the entry for Ada Lovelace), downloads the file and then pastes it into a file on our harddrive. Again, its a bit dense, but you can probably get the gist of what its trying to do, even if the syntax doesn’t make sense.
After running through a few more of the tutorials from the Bastards Book of Ruby, I was hooked. The code was readable, none of it seemed impenetrable, and I seemed to be able to write code myself (or at least predict how it was going to be written) fairly quickly—within a day or so. I was far from functional without a tutorial to follow, but I was able to get a basic understanding of what the code was doing, without getting frustrated by the syntax.
After a good, solid Saturday and Sunday running through tutorials and watching screencasts, I was really starting to get interested. That was the strange part for me: in numerous attempts to try and learn PHP, I never once felt that urge to go home and open up a new tutorial. I always had that nagging feeling like it was going to be an onerous, complicated chore. I always ploughed on with a no-pain-no-gain mentality, but I never, ever felt excited about learning—and within a week or so, I’d just give up. With Ruby, I already feel like I have some actual basics to work with now, and more importantly, I’m still excited about learning after four weeks. I actually feel like I have some momentum to keep going with—that mixture of excitement, interest and slow-and-steady accumulation of actual knowledge.
My goal for the first month was simple: just watch and read as much as I possibly could.
Instead of learning nuts and bolts, and trying to actually write and memorize a lot of code and syntax, my goal was to just see as much as I could. I hoped that if I kept looking at new material, I’d keep seeing similar things over and over.
This worked out quite well. In the 25+ tutorials and articles I read, for example, almost all of them used loops in some way. After all this reading, I was able to pick out which part was the loop, and really see how it worked and how to write the syntax for it. Same with if statements (known as part of ‘flow control’). Just reading and re-reading if statements really ingrained them in my head. After the first week or two, when I actually started to write some code of my own, I already felt a bit more comfortable.
If I were starting again, I would probably do them in that order. Learn a little bit of Ruby, get totally mind-boggled with the Ruby on Rails Essential Training, go back to Ruby again briefly (it should make much more sense now), then move on to Rails Tutorial. Rails Tutorial is really the gold standard tutorial out there. Its long, detailed and brings you right from start to finish. You do get lost at times, but its the best resource I’ve seen out there to date.
This month, I’m planning to finish the Rails Tutorial (building a Twitter clone), and I plan to actually try and build something simple from scratch. My plan here is to build something like a recipe catalog or an image gallery or something small like that to get the hang of things. My intention is to ‘scaffold’ (auto-generate) half of it and try actually writing the other half. Maybe I’ll scaffold a Users resource, while actually coding a Recipes resource…something like that.
All in all I think month 1 was reasonably successful. I still can’t really code things without guidance in Ruby, and I only really have a loose handle on just the V part of MVC (Views) in Rails, but things are moving along already.
For completeness, here’s a quick inventory of what I do have some idea about in Rails:
index, new, show, edit, deleteAnd that sounds and feels like progress to me! Stay tuned for next month’s update.
I find sites like Daring Fireball impossible to read. I’m not sure what it is, but the dark background makes my eyes go blurry. My issue is certainly not just limited to that one site either—dark background-ed sites are all over.
I’d been wishing there was some way to remedy this for a long time now, and while Readability got us half-way, it isn’t perfect for this purpose. It works extremely well on individual articles, but what if you wanted to invert the look of a homepage or a forum or anything else non-article?
Now you can. With Snowball.
It doesn’t work on every site, but I’m adding new rules all the time. If it doesn’t work for your favourite site just let me know and I’ll see if I can make it work.
Behind the scenes
On the technical site of things, Snowball is a simple Javascript plugin. The code is really divided into two parts: a fetcher and a set of jQuery CSS overrides. The fetcher (the actual bookmark) fetches jQuery and your magic external jQuery file containing the CSS fixes. The only hard part is Javascript required to fetch the two files—the rest is just basic jQuery. You can see it all over at Github.
My biggest goal was to get back to writing instead of applying updates (and thinking of more efficient ways to apply updates).
Long-time Drupal developer @wakah writes about moving his personal blog from Drupal to Jekyll.
This isn’t just about choosing the right tool for the job, its fundamentally about choosing (or not choosing) Drupal. The part about spending your time trying to think of more efficient ways to update Drupal resonated so loudly with me. The hours I spent in the Terminal making database backups and backups of backups, and saving the sites directory to somewhere else, and zipping it all up and downloading it and organizing it on my local machine, etc, are hours I’ll never get back.
I don’t know if anyone else is thinking this way, but I believe Drupal is at a crossroads. Its too complicated and ornery to be used to power simple blogs or small websites, and it has not been pitched to developers who are looking for a CMS/framework hybrid. If anything, Drupal has carefully chosen not to market it that way.
Just because @wakah chose to simplify his workflow and try a new hot tool like Jekyll doesn’t mean he’s abandoning or turned against Drupal, but it unavoidably says a lot about how he feels about it.
One of the 500 reasons why I switched to WordPress from Drupal lies below. If you’re reading this as a non-coder, please simply understand that this markup is absolutely heinous, overcomplicated and completely unnecessary.
<!-- main row: width = grid_width -->
<div id="main-wrapper" class="main-wrapper full-width">
<div id="main" class="main row grid16-16">
<div id="main-inner" class="main-inner inner clearfix">
<!-- main group: width = grid_width - sidebar_first_width -->
<div id="main-group" class="main-group row nested grid16-16">
<div id="main-group-inner" class="main-group-inner inner">
<div id="main-content" class="main-content row nested">
<div id="main-content-inner" class="main-content-inner inner">
<!-- content group: width = grid_width - (sidebar_first_width + sidebar_last_width) -->
<div id="content-group" class="content-group row nested grid16-11">
<div id="content-group-inner" class="content-group-inner inner">
<div id="content-region" class="content-region row nested">
<div id="content-region-inner" class="content-region-inner inner">
<a name="main-content-area" id="main-content-area"></a>
<div id="content-inner" class="content-inner block">
<div id="content-inner-inner" class="content-inner-inner inner">
<h1 class="title">Front Page</h1>
<div id="content-content" class="content-content">
For the sake of context, and humour, the same markup in WordPress could easily look like this:
<div id="main">
<div id="content">
<h1 class="title">Front Page</h1>
ht to @ncbeets for reminding me of exactly how happy I am with WordPress.
Back when I was desperately trying to learn PHP a few years ago, I would have killed for the resources that are all over the web today. If I had had those Stanford classes, Kahn Academy, Code Academy or Think Vitamin, maybe I would have actually learned to program. Instead, I struggled along with out-dated books, rambling, bug-filled tutorials, and complex theoretical discussions on the MySQL documentation forums. In the end, while I learned an incredible amount, I certainly never did learn to program.
I stumbled across yet another incredible resource yesterday: The Bastards Book of Ruby. Written in plain English, the online book takes you through practical programming projects, while teaching you about variables, loops, and objects as you go. In just a few minutes yesterday, I read about how to create a tweet aggregator and how to read from and parse text files. Both were interesting, engaging and useful examples. Somewhere down the road, I can picture myself going back to this book and putting some time into finally learning/playing with Ruby.
But (of course), there’s still a huge fly in the ointment: getting this stuff downloaded, installed, compiled and working. I’d venture to say that the target audience for this book is people like me—people who already build websites, people who already code, people who already make stuff using some combination of technology. Like many other people, I make my stuff with WordPress on my local installation of MAMP. The 10+ times in the past when I’ve tried to get Ruby and Rails working on my local machine, I’ve broken MAMP. Subsequent research and forum postings have even advised against using the MAMP copy of MySQL with Ruby. So how are you supposed to run the two? One forum poster told me to run a separate copy of Mac OS in a virtual machine! Sorry, but that’s just a bit too much for me.
In an interview with Fresh Air in 1996, Steve Jobs argued that computer science was something that we should all be exposed to:
In my perspective … science and computer science is a liberal art, it’s something everyone should know how to use, at least, and harness in their life. It’s not something that should be relegated to 5 percent of the population over in the corner. It’s something that everybody should be exposed to and everyone should have mastery of to some extent, and that’s how we viewed computation and these computation devices.
While I couldn’t agree more, I really don’t know how this can become a reality, given the state that technology is in these days. In order to execute a single line of code, you need to download Xcode to be able to download to Homebrew, to be able to download Ruby, Rails, MySQL, rpm, etc etc etc. This really makes the whole Ruby on Rails framework available only to a select few.
The reality is simple: increasingly few of us know how to actually program in an age where we need exponentially more programmers. Computer science enrollment has leveled-off or dropped in the last decade, and we don’t teach kids to program in school anymore. And finally, in my opinion the most crippling issue, when people actually get motivated enough to learn to program in something new and exciting like Ruby on Rails, they’re extremely likely to fail even getting the software installed.
While this abundance of new learning resources is obviously fantastic, I think considerably more attention needs to be payed making it so that we can actually use them. When writing a single line of code involves an hour of downloads, broken installs and late nights trolling through support forums trying to decode error messages, I really don’t think we’ll reach our end goal: teaching more programmers.
