I thought it would be nice to start a series of posts on neat tricks and plugins for Vim, called Vim Essentials. I don’t know how often I will do these kind of posts, but I’ve got a couple in mind already.
This first post I’ll start off with Powerline. A plugin for Vim that gives you a better status bar than the default status bar. Your current mode, filetype and used file format is more clear. See the picture below for an example.
After you download and install Powerline you also need to make sure that your
.gvimrc has the following lines:
set laststatus=2 " Always show the statusline
set encoding=utf-8 " Necessary to show Unicode glyphs
Adding these two lines makes sure the status bar is always being shown and the characters used in it can be displayed.
Looking at the screenshots provided by the author of Powerline it should also be possible to display the current Git branch, but I’ve yet to find out how to do so. The version I’ve linked here is deprecated in favor of the Python rewrite, which can be found at https://github.com/Lokaltog/powerline.
Since a week or 2 I’ve been using Varnish in front of my websites on my server. Varnish is marketed as a “web application accelerator”. To be honest, the homepage of the project doesn’t really give a good description of what it does. For that you’ve got to dive a little bit deeper into their website; the about-page actually advises you to read the Wikipeda article.
Basically it’s a HTTP reverse proxy that caches the made requests into virtual memory. It’s also capable of doing load balancing and supports health checking of your backends (e.g. the actual apps generating and serving your pages).
So why cache HTTP requests into memory? Several reasons actually:
- Your webapp will most likely take more time to generate a page than it takes to serve a static copy of it. Don’t believe me? Benchmark a WordPress site.
- Since your webapp will most likely generate the same page for the same route over and over it’s a waste of CPU to do so. With Varnish caching the request it only has to do this once. Without Varnish (or any other caching at your server stack) you can do some caching on the client side, but that still requires every visitor to request the page from your app at least once.
- Continuing from the last sentence of the previous point, imagine getting Slashdotted. Since Varnish will be serving a cached copy of the page you’re offloading your app and your server’s resources won’t get eaten up by all your new simultaneous visitors.
This all sounds very nice and it is, but there are some caveats. When Varnish caches a request it will not only look to the requested URL, but also the request headers. Since most websites can place a lot of Cookies on the visitor’s PC those are sent to your server as well, which are part of the request. When Varnish sees Cookies are being sent from the client it’ll directly forward the request to your app and never cache the page.
Pages with user specific content on your website such as greeting messages are also something you don’t want Varnish to cache. Since this usually requires a Cookie Varnish won’t cache the page anyway. In case you do use some other kind of identification check you don’t want Mike to see “Welcome back, John” when Mike visits your website after John. Dynamic content parts can be supported with Edge Side Includes (ESI). ESI is similar to Server Side Includes (SSI). With ESI Varnish still caches your page, but dynamic content is inserted where ESI statements are put when serving the page.
As I’m still new to Varnish as well I’d like to hear about your experience. If I’m telling something here that’s off, please let me know so I can correct it. If in the future I learn some neat Varnish tricks I’ll blog about it here. For now I’m very pleased with running Varnish in front of my HTTP server and I feel pretty confident in case I get Slashdotted (unlikely though).
A little while ago I claimed the domain name meldpuntdierenleed.nl (animal cruelty reporting). For months I didn’t do anything with it, mainly due to health reasons.
But, after reading the Dive Into HTML5 book, which I posted about earlier and feeling a little better I decided to get something up and running. It’s a simple HTML5 page with some CSS3 styling. I’ve only really tested it in Chromium and FireFox 3.6. It’s only a static page with some links to websites likes the WSPA where you can report animal cruelty. Along with it are some Google Ads and Analytics is measuring statistics for me.
I don’t have any other plans yet with meldpuntdierenleed.nl but figured having something on it is better than nothing.
After years of only talk about the HTML5 specification the last 2 years or so browser vendors are finally starting to implement most parts of the specification, even though the HTML5 specification isn’t completed yet. Because of this I haven’t been paying much (or any) attention to it at all so I’ve got no clue about all the new features that HTML5 brings.
Luckily for me the free online book Dive Into HTML5 by Mark Pilgrim gives a nice introduction to HTML5. It gives a nice explanation on how to use <article>, <header>, <footer> and <nav> but also some of the other elements as <video> and <canvas>. Geo-location, storage, offline availability, new types of form elements and microdata have chapters of their own as well. I think microdata is an interesting addition, although I’m not sure yet it would serve any other purpose than providing specific data to search engines.
Reading this book has brought me up-to-date quickly on the HTML5 topic and makes it a less scary beast for me. If you’re interested at all in web development then I suggest reading Mark Pilgrim’s excellent book.
Edit: I was told the site no longer exists, but https://digital.com/tools/html-cheatsheet/ has a nice overview as well.