Peter Seibel recently blogged to challenge the idea of reading code for reading’s sake. “Code is not literature and we are not readers,” he concluded. “Rather, interesting pieces of code are specimens and we are naturalists.”
That’s partially true. Interesting pieces of code are specimens. Yanked from their context in programs or frameworks, lines of code become like dead bugs on pins in boxes.
It might be nice to sit around with a snifter of brandy and discuss a dozen lines of code as though they were some exotic insect or even poetry, but few developers can afford that luxury. Developers have jobs to do and problems to solve that are embedded in thousands of lines of supporting code. Often, these lines are built by numerous developers attempting to address a set of problems that evolve unpredictably over time.
But that’s not to say that developers don’t read source code. Reading is actually the first thing that goes into solving most problems. Sometimes it might be necessary to, first, pick apart a stack trace or grep through any log files that might be on hand. But then it’s on to reading the suspect portions of the source code, and the detective work begins.
Continue reading %Reading Ruby for Professional Development%
Phil Karlton once said, "There are only two hard things in Computer Science: cache invalidation and naming things." This article is about the harder of these two: cache invalidation. It’s directed at readers who already work with Varnish Cache. To learn more about it, you’ll find background information in “Speed Up Your Mobile Website With Varnish.”
10 microseconds (or 250 milliseconds): That’s the difference between delivering a cache hit and delivering a cache miss. How often you get the latter will depend on the efficiency of the cache — this is known as the “hit rate.” A cache miss depends on two factors: the volume of traffic and the average time to live (TTL), which is a number indicating how long the cache is allowed to keep an object. As system administrators and developers, we can’t do much about the traffic, but we can influence the TTL.
Sass was introduced about 7 years ago as a workaround for CSS flaws and has come a long way since then. It has played a major role in popularizing CSS preprocessing, to the point where the question is no longer if you should use a preprocessor, but which one you should use. It turns out, the answer to that question is very often Sass — because the syntax is better (and closer to CSS), because it’s permissive, and because it can do a lot of stuff and works well.
Since being introduced, Sass has become arguably the most important CSS preprocessor available today. It has a whole ecosystem growing around it (starting with Compass) — Playgrounds, applications, grid systems, libraries, and so on… But it’s not always that easy to dig up interesting stuff about Sass. The more there is, the more you have to look in order to find the thing you want.
Hence this blog post. What if I tried to enlighten the path by showing you what I think are the most valuable Sass tools? Sounds cool right? Let’s go.Playgrounds
Fortunately, you can try Sass online. There are playgrounds, or online tools, that allow you to write Sass and see the compiled CSS and (sometimes) the way the code will render. As of writing this, there are two major playgrounds to play with Sass:CodePen
CodePen, by Chris Coyier, Alex Vasquez, and Tim Sabat, is by far the best playground you can use. It offers everything you need and beyond for front-end testing. Regarding Sass, it supports the stable version (version 3.3.4 as of writing) and you can use either the old indented syntax or the SCSS one.
SassMeister, by Jed Foster, is a playground that specializes only in Sass-related stuff. Obviously then, it does the job better than CodePen. You can use either stable, or Sass 3.2.14, or even LibSass, the C port of Sass (still running on Sass 3.1.x as of this writing).
Of course, SassMeister lets you choose the syntax you feel more comfortable with and you even can choose the output style (expanded, compressed, and so on). Most importantly, because SassMeister is specific to Sass, it allows you to import Sass libraries (Compass extensions actually). You can even propose your own extensions if you think they should be added.
Continue reading %My Favorite Sass Tools%
This is important because:Picturefill was a great solution already, and this brings it into the future encouraging the use of the future proper syntax. You not only can use
<img srcset>too, which is a close cousin and useful when swapping sources with media queries alone would suck.