Category: Uncategorized

Why anybody doing computer work should use gaming equipment

The many benefits of hotkeys

I’ve always been keen on hotkeys as they help you get stuff done faster as well reduce the amount of friction you get from having to do repetitive operations. It’s a huge time saver. These wins you get with hotkeys also compound over time to make those few seconds saved per operation grow into hours. And last but not least, when you are in the zone with your writing or your designing, your drawing or your programming, you want to stay in the flow! Hotkeys help you stay in the flow by reducing the amount of time navigating the screen, typing, searching for what you need and contorting your fingers.

Keyboards and mice with programmable keys

So I’ve always paid attention to input devices that provide extra keys, but for some strange reason regular keyboards aimed at those doing computer work rarely come outfitted with a meaningful amount of programmable keys. But hardware companies do cater to gamers and they happen to love hotkeys. For this reason, if you want to maximize the utility you can get from hotkeys, you are best looking at some gaming equipment. These devices may look designed for a younger audience but they are more than equipped to deal with a professional workload. They are designed for precision, endurance, responsiveness and programmability on an order of magnitude more than regular consumer products. In other words, if you do serious computer work, use gaming equipment.

Most people when they think of programmable keys, they think of keyboards and maybe a mouse with a few extra keys. But my Perdition mouse has 18 programmable keys and has made the most gains for me.

Example use cases & a magical mouse button recipe

Hotkeys can do a variety of things. You can program to output any length of text or key presses. You can of course configure complex keyboard shortcuts into a single button so you don’t have to do finger gymnastics. You can record and play macros and automate complex sequences of commands.

I have fallen in love with my mouse configuration, let me show you the ways:

  • separate buttons for Copy, Paste and Cut. It’s amazing how much work quicker using these buttons is than with regular keyboard presses.
  • a button to bring up clipboard history and paste any item from that history
  • manage virtual desktops by toggling between desktops with separate keys
  • instantly scroll to the top or bottom of a page, something that is very useful in today’s web when pages have gotten more scroll heavy
  • Forward and Back buttons work in almost every program
  • Screen dimming keys (using f.lux) at a finger’s touch
  • zoom in or zoom out by pressing a button and moving the mouse wheel

Recommended Keyboards

Logitech G510s Gaming Keyboard with Game Panel LCD Screen

Logitech G11 Gaming Keyboard (Black/Silver)

SteelSeries Merc Stealth Gaming Keyboard

Due to the SteelSeries Merc Stealth Gaming Keyboard’ many programmable hotkeys, it can boost productivity for writers, designers and programmers
A picture of the Logitech G11, it’s the keyboard I use because it features 18 programmable hotkeys on the side and 3 modes to use those 18 keys for 54 hotkeys.
Logitech’s G510s features 18 programmable hotkeys on the left side and you make 3 configurations with those 18 keys for 54 hotkeys that will boost your productivity with your professional tools

Recommended Mice

Razer Naga Ergonomic MMO Gaming Mouse

This Razer Naga Ergonomic Gaming Mouse boasts 12 thumb buttons, originally geared toward MMO games, it’s perfect for adding a variety of work related hotkeys

SHARKK® Gaming Mouse for the Pro Gamer 16400 DPI High Precision Programmable Laser Gaming Mouse for PC and MMO with Omron Micro Switches 18 Programmable Buttons Weight Tuning Cartridge Gaming Mouse with 12 Side Buttons 5 programmable user profiles

Sharkk’s pro gaming mouse has 18 programmable keys, which is amazing. It blows a normal mouse out of the water as far as productivity goes.

Redragon M901 PERDITION 16400 DPI High-Precision Programmable Laser Gaming Mouse (Black)

Redragon’s Perdition series is the mouse I own and hit has 18 programmable hotkeys and flashy programmable lights to go with it. It’s the best mouse I’ve used for my work flow.

Why hiding the publishing date from your posts is bad

If you’re doing research into a topic, one of the most important guides is understanding when resources were published and last updated. I’ve been coming across a lot of theme designs where the author has chosen to hide the post date. It makes efficient research extremely hard.

Knowing when a post was first published and when it was edited gives a reader the ability to figure out the chronology. Even if an older source of information is more informative than a newly published one, it’s important to understand the order in which things were written. This is especially true for problem solving. Figuring out what the most current solution to a problem is vital.

When blog posts are being written in an optimal way, they build upon what has already been written and try to evolve an understanding about a topic. A big part of doing that is respecting the order in which things were written.

On most problem solving quests on google, I will look for the most exhaustive and authoritative resource as well as the most recent ones. Recency is important, because it often will lead to a post where the author has used older resources to build up a better picture or add some new perspective.

Freshness is also a good indicator that a topic is active and being actively thought about. It shouldn’t be made harder to figure out if a certain topic has become stale.

Older posts that have not been updated do not have the benefit of having gleaned from new developments, new solutions and new problems. That doesn’t make a post less valuable, but it has to be abundantly clear that it’s a dated post and may no longer be current.

There really is very little reader benefit to hiding a publishing date in the first place. If you have written evergreen content, that is to say, content that will stand the test of time, it doesn’t mean the post date becomes any less valuable. In fact, it can provide proof that you were the original author, or the first person to make certain statements.

It really baffles me that savvy authors who write on web development topics hide the publish date. This provides a terrible user experience. You are making understanding a topic more of a pain. Don’t make things a bigger puzzle than they need to be.

CSS3 PIE 2 and WordPress integration

A new release of CSS3 Pie has been announced, PIE 2.0 Beta 1. It comes with lots of goodies such as a bit of background size support and rgba support in simple linear gradients and box-shadow rendering. For a more precise break down check out the release post, as not all of the newly supported features work in all contexts.

I had written a method for integrating version 1 of PIE into WordPress for plugin and theme authors but as the new version of PIE uses a different load method, I found it useful to post an updated method. The main difference with PIE 2.0 is that the htc file is very small now (<2kB) and it will conditionally load javascript files based on the version of IE. The advantages are that you can load these js files from any server (such as a CDN) and now that unnecessary code is left out, the download will be a lot smaller. Caching works a lot better out of the box as well.

The method I’ve suggested for PIE remains mostly the same except we now have to add in a custom load path so will load the javascript files from the right location. By default, PIE will look for the javascript files in the same folder is located. Because the implementation I’m detailing here doesn’t point straight to the file, the script won’t be able to find the javascript by itself. A custom path to the javascript files can be specified with a pie specific css rule called ‘-pie-load-path’. You could hardcode this rule in your stylesheet and be done with it, but it’s more flexible to do this dynamically with an inline style element.

note: It’s important to note that the implementation I’m detailing here is geared toward plugin and theme authors looking to package PIE with their distribution. If you’re just trying to get PIE working on your own sites it’s easier to move the PIE files to the root folder of the domain, in a folder right off the root or in the wp-content folder. You can just follow the normal instructions and forgo with having to set a custom load path and simply point directly to

The benefits to the method I’m using are the same as before:

  • avoid having to hardcode the path to in your css
  • avoid having to mess with php in your stylesheets to insert the path to dynamically
  • avoid having to move to the domain root or elsewhere
  • avoid having to mess with relative urls when pointing to PIE, just use an easy to remember absolute url
  • a short url and easy to remember url for referring to the PIE file in your css

The Implementation

Normally, when inserting scripts and styles, you would want to hook into wp_enqueue_scripts and use a WordPress function such a wp_add_inline_style for inline style elements. In this case, we only want to have the browser read the style element if it’s Internet Explorer, so we want to wrap our style element in the familiar conditional code to target IE only. For that reason, I opted to go for a more straight forward approach and attach the function that prints this code straight in the head section through the wp_head hook. Another benefit to this is that we can place this code before other stylesheets are loaded. (I haven’t tested to see if this makes an actual difference in terms of how fast PIE applies its styling, but it makes sense on paper)

if( ! function_exists( 'css_pie' ) ) {
	function css_pie ( $vars ) {
		$vars[] = 'pie';
		return $vars;
	add_filter( 'query_vars' , 'css_pie');

if( ! function_exists( 'load_pie' ) ) {
	function load_pie() {
		if ( get_query_var( 'pie' ) == "true" ) {
			header( 'Content-type: text/x-component' );
			header( 'Cache-Control: max-age=2592000' );
			readfile( get_stylesheet_directory() . '/inc/PIE/' );    
			// Stop WordPress from loading further
	add_action( 'template_redirect', 'load_pie' );

if( ! function_exists( 'set_pie_path' ) ) {
	function set_pie_path(){
		$piepath = get_stylesheet_directory_uri() . '/inc/PIE/';
		<!--[if IE]>
		<style type="text/css">
		html { -pie-load-path:"<?php echo $piepath;?>";}                
	add_action( 'wp_head', 'set_pie_path', 7 ); // just before stylesheets are printed

To adjust this code to your project, keep in mind where your PIE files can be found. In this example I created a folder called PIE in the includes folder of my theme directory. You’ll need a different url path if you’re including PIE from within a plugin. If you are loading PIE within your theme – which is probably going to be the case most of the time – you may want to set the paths to look for the parent theme instead of checking the child theme. In that case you can replace get_stylesheet_directory() and get_stylesheet_directory_uri() with get_template_directory() and get_template_directory_uri() respectively.

Applying PIE in your css is as easy as cake, just use:

behavior: url(?pie=true);


Here’s How To Improve (Social) Psychology’s Academic Reputation

The social sciences such as psychology and sociology have been getting hammered as questions arise over the validity of findings coming out of various studies. The most heinous of causes are incidences of fraud, which is a terrible blow to the field any time it happens, but it goes beyond even that. Research methods are being questioned and classic findings that had been assumed to be reliable are put in doubt when replications of studies fail to reproduce and support said findings

Rumblings in the social sciences are not new, an article about the subject by Jonah Lehrer back in 2010 created a lot of attention. Most recently Daniel Kahneman has attempted to get the attention of his colleagues in the social priming field, sounding the alarm as replication failures for classic priming studies have proven to be disappointing. His call to action involves greater collaboration between laboratories in order to check results in more transparent and trustworthy ways.

A snippet from conversations between Kahneman and Ed Yong, author of an article about this subject on Discover magazine caught my attention. To quote from the article:

Kahneman said that priming effects are very subtle, and could be undermined by small changes to experimental protocols at the hands of unskilled experimenters.

And this immediately reminded me of another controversy in the social sciences when Daryl Bem published a paper detailing a series of classical experiments that had been slightly modified to test for paranormal phenomena (with significantly positive results). Many skeptics in the field responded critically and it prompted to call into question some of the most basic research practices in psychology. You see, Daryl Bem mostly followed text book practices and so when results turn up that many skeptics will find incredulous, there must also be something wrong with the basic research protocols we have been teaching students for decades.

The scientific method was in full motion in response to Bem’s studies, as many labs were motivated to replicate the studies. As some (but not all) research groups were unable to reproduce his results, many thus concluded that Bem’s results could now be discarded. On paper it seemed like a win for the scientific method, especially if you are a critic. You have to understand that for many scientists, this fringe area is seen as detracting from the integrity and credibility of the entire field. It’s a sore in the eyes of hordes of many traditional scientists.

But those that are especially familiar with the parapsychology field know that ESP type studies are typically done with greater scrutiny and attention to detail than the average study. An obvious reason for this is that if you want to arrive at convincing results in such a controversial arena, you have to be extremely diligent about ruling out effects that  would otherwise explain results. Another reason has something in common with the priming field: when experimentally studied ESP effects can be notoriously subtle. The debate continues to whether the small, but positive effects obtained in studies are pointing to something real, or just noise.

In the wake of Bem’s paper, failed replications added weight to the notion that the original study must have been flawed in some way, or at the very least, that the results are meaningless with so much evidence to the contrary. You see, if you can’t replicate a study, it’s usefulness disintegrates. Kahneman implies that some replications regarding classic priming effects were done inaccurately. The same argument regarding replications of Bem’s studies would be regarded by many as wishful thinking on the part of people who want to believe in ESP. Since priming effects rely on less exotic grounds, it’s a different story.

Whichever way you cut it, there’s a serious problem when you have a field that has generated a lot of data and you can’t tell how reliable that data is. My solution to this problem would improve research methods as well as the reliability of important and influential findings. My proposal would be to make replicating classical studies part of the curriculum across universities around the world. By repeating replications of classical studies on a periodic basis and prioritizing the findings from papers that are being cited the most, the entire field will get a boost. Data will become more reliable and students will learn stricter research methods than those of previous generations.

Organizing Your WordPress Theme’s CSS

Stylesheet files can get ridiculously long. The Twenty Eleven theme has over 2500 lines  of css (unminified). That can be a pain if you’re trying to make significant adjustments to a theme. Quite a few theme frameworks take a more modular approach to css and separate their CSS into different files. That is a big improvement, but it does come at a cost. The more files you import, the more requests you’re making to the server. Secondly, persons who have to work with the CSS now need to figure out what files contain what style specifications. Thirdly, the built-in editor in the administration screen is not that user-friendly when you have to hunt down specific files instead of editing the basic style.css file.

I use the LESS language these days which makes CSS management heaps easier. You can have multiple less files and you can generate a single css file from those files. The question now becomes: what’s a good way to organize the less files?

There are quite a few different ways to organize your CSS logically and the problem here is that you can easily run into overlap situations. Do you put your CSS targeted for small screens in a separate file, or do put them in the file that targets those specific elements? If we have a file dedicated to structure as well as for different content elements, from widgets, to post-formats, how do we make the separations? If you have CSS for your images, do you include them with the file that handles galleries, or do you put them in the file that addresses media elements. These are just a few examples.

So far, I haven’t come up with a system that has perfect clarity. I don’t think it’s possible. The conclusion I’ve come to is that you have to do what’s most in alignment with your workflow. If you have to figure out what file to make an adjustment, there should be no more than 2 obvious candidates to choose from, and they should be obvious. If I want to make an alignment adjustment to a widget area for tablet screens, I don’t want to have to check a widgets file, a structure file, an alignments file and a responsive file.

I’ve been taking advantage of the LESSphp library to get around some of these file organization dilemmas. You can drop in your media queries like you would do a mixin. That way you can keep all the CSS relating to a group of elements organized in one logical area. There is one downside at the moment: the output isn’t perfect yet since it can cause your CSS to contain a lot of redundant data (similar media query statements aren’t grouped automatically into a single media query). I’m working on a css post-processor (the Flawless Styles Compiler plugin) to fix this and make the output cleaner and lighter in general.

Here’s my current file organization setup for those that are interested:

  • variables.less
  • mixins.less
  • reset.less
  • structure.less
  • typography.less
  • general.less
  • navigation.less
  • header-area.less
  • footer-area.less
  • page-templates.less
  • post-formats.less
  • media-elements.less (images, video, audio etc)
  • form-elements.less (input elements, search box, contact forms etc)
  • ui-elements.less (button’s etc)
  • sliders.less
  • gallery.less
  • comments.less
  • states.less
  • print.less
  • widgets.less
  • misc.less

Potential tweaks to this organization? I’m thinking further separation of individual page templates and post formats. Post types can fall into either page template or post format category but it might make sense to have a dedicated file for post types as well.

LESS and convenient file organization make things a lot easier. But I want managing a site’s design to be even easier and this is why I’m building a plugin called ‘Flawless Styles Compiler’ which will take CSS development for WordPress to a whole new level.

Troubleshooting Auto-Formatting Issues In WordPress

Got a bunch of white lines in your post that you are sure you didn’t put there yourself? Is your content getting wrapped in paragraphs in all the wrong places? Are shortcodes messing up your text or coming all out of whack?

Welcome to auto-formatting hell. Let’s troubleshoot this.

WordPress allows your content to have filters applied to it. In fact, it has some default filters that are automatically applied. The most notorious of these is the wpautop filter. It’s a function that semi-intelligently cleans up your content by wrapping text in paragraphs and placing linebreaks and such. The concept is great because it means that the end-user doesn’t have to worry about applying the right HTML.

Content filters are also heavily used by plugins to modify the rendering of content. You can do all kinds of neat stuff with content filters, like appending or prepending snippets of text to your content, modifying words or stripping links.

The downside is that content filters can also get in the way, especially when you have content that the content filters don’t deal with properly. These issues are really common when you are working with shortcodes, or certain HTML code (for example, HTML5 brought several new elements that aren’t taken into account by most filter functions).

When you bump into issues with unwanted paragraph wrapping or unexpected amounts of line breaks, it is most likely the wpautop filter that is doing the evil work. For those that are technical at heart, checking out the source code to see what wpautop is actually doing is really helpful. For most people, they will look on the googles to find a solution to their formatting ailments. You will likely find advice to disable this filter. You can do that by placing this code in your plugin file or functions.php file of your theme:

remove_filter( "the_content", "wpautop" );

This line removes the default filter that is applied to the content. Since the wpautop filter is applied in other types of content as well, you would have to apply ‘remove_filter’ to those other contexts as well. To remove the filter from the excerpt output for example, you can copy the above line and replace ‘the_content’ with ‘the_excerpt’.

If you don’t like to code, there are a bunch of plugins that do this as well. But there a problems with this approach. The first problem is that we typically don’t want to have the filter removed site wide. Many users quickly find out that the rest the content on the site now looks condensed and ugly. Argh!

One solution some people use is to apply their own modified filter that does much of what wpautop accomplishes but also takes care of the undesirable behaviour. If all you want is to prevent linebreaks from being added you could call wpautop with an additional parameter that prevents this.

remove_filter( "the_content", "wpautop" );
add_filter( "the_content", "your_custom_wpautop", 10 );
function your_custom_wpautop ( $content ){
	$content = wpautop( $content, false ); // false parameter disables br insertion
	return $content;

If you’re dealing with shortcode issues specifically, you could try reordering the timing of the filter so that your shortcode content is processed before the wpautop filter is applied.

remove_filter( "the_content", "wpautop" );
/* shortcodes are processed with priority 11, the default for wpautop is 10, but we change that here to 30 so that it runs after the shortcode has finished processing */
add_filter( "the_content", "wpautop", 30 );

(You can also process your shortcode before wpautop)

These solutions however will do nothing if another plugin or theme function is running wpautop manually and applying its own filter. Removing the ‘wpautop’ filter won’t work in that case. To get around this you have to figure out what the best thing to do actually is. First of all, if you have tried above solutions and you still have extra paragraphs and/or linebreaks, determine whether it’s a theme or plugin adding their own filter. If you think it might be the theme, switch themes, if you think it might be a plugin, deactivate the most likely culprits one by one and check your results.

If you have determined that it is a plugin or theme function there might be an elegant way to disable their filter. You can run through the code to find out what the filter is called and then use the remove_filter function with that filter name (it’s important you match the same priority level that the filter was added with). You could flat out disable the conflicting plugin in question and use another plugin. You could adjust the theme or plugin code manually, but you’ll lose those fixes when you upgrade.

There are two alternative solutions you could apply if you don’t want to remove any existing functionality sitewide. First, you could disable the offending filter on a post by post basis. Or you could roll your own filter that corrects the formatting (which you could also run on a post by post basis).

Corrective Filter Example:

// filter to remove excess linebreaks from the content
 function kill_linebreaks( $content ){
	$content = str_replace( "<br>", "", $content);
 	$content = str_replace( "<br />", "", $content);
 	return $content;
function no_linebreaks(){
 	add_filter("the_content", "kill_linebreaks", 100000); // removes linebreaks after every other filter has finished processing
add_shortcode( "no_linebreaks", "no_linebreaks"); // insert this shortcode if you want linebreaks removed from the post in question

To use this solution, just add the shortcode [no_linebreaks] in the posts that need it. You can also run a shortcode that removes the offending filter.

Advanced Debugging Tips

Here are some tips for troubleshooting tricky situations. The filters that are run are stored in a global that you can access. The add_filter function can be found in wp-includes/plugin.php.

global $wp_filter;
var_dump( $wp_filter );

If you are trying to determine if it’s wpautop being run or some modified version with a different function name, a quick and dirty way to check is to edit wpautop (you can find it in /wp-includes/formatting.php) and insert a debugging statement or function. You can also use debug_backtrace() to pinpoint what files are calling wpautop. Just remember the remove your code or restore a saved backup of the file when you are done.

Loading Javascript and CSS mid-page, HTML5, WordPress & Passing Validation Part 1

Since WordPress version 3.3 it has been made a lot easier to load javascript and stylesheets mid-page.

Why would you want to do this in the first place?

Well a lot of plugins load their own CSS and Javascript files on the page and some of them do so at times when it’s not really necessary. As a plugin or theme developer if you are loading styles that only need to be loaded in certain cases (not on every single page), you want to avoid loading them when they are not needed.

If you’re not sure on which pages your scripts and styles will be needed, it presents a bit of a conundrum. This is a common problem for plugins that let a user add its functionality via a shortcode. Common examples are sliders, media players, galleries and forms.

The best way to load your scripts is to enqueue it with native functions WordPress provides. There are a number of advantages to this. For one, you can avoid scripts from being injected more than once, you can control where the script loads (in the head or in the footer) and it offers ways to deregister scripts and styles from loading altogether without resorting to hacks.

The problem with enqueueing used to be its inflexibility in relation to the load sequence of WordPress. Prior to WP 3.3 you had to enqueue your scripts and styles before the page content is constructed. While there were good methods for calling javascript mid-page and having it load in the footer, there were no palatable equivalents for loading CSS stylesheets. What you could do was:

1) Include the CSS on all pages
2) Rely on inline styles
3) Parse the page content for shortcodes before styles are enqueued and include your CSS with conditionals.
4) Use javascript to dynamically add your stylesheet to the head section
5) Set a postmeta field that is checked when a shortcode is added to a post and include a condition that loads your css if the postmeta field is present

Now it’s possible to enqueue scripts and styles mid-page through wp_enqueue_script() and wp_enqueue_style(), it will load your scripts and styles in the footer as a result.

By now you might be wondering, wait, can you have stylesheet links at the bottom of a page? Yes and no. Browsers are okay with this but validators are not. So while, in the wild it will work ok, your page isn’t going to validate.

But you’re theme is HTML5 you say? Good news, HTML5 is supposed to be fine with styles inside the body of the HTML…or is it? After some experimentation I found that my stylesheet reference in the footer was still bringing up validation errors for HTML5. The LINK element can’t be used for stylesheets in the BODY it seems…but you can use STYLE, in fact there is a new attribute on the horizon called “scoped” which will allow style declarations for certain sections of a page. It has virtually no browser support at present…but the code does validate according to HTML5 specs and the browser will recognize the style declarations itself. The trick then is to use the import statement to load your css file instead of using the LINK element, like so

But how do we do this?

We could still use wp_enqueue_style and modify our output with a custom function. WordPress will output a LINK element by default but you can adjust the output by hooking into the ‘style_loader_tag’ filter.

function print_html5_style( $output ) {
// some regex to find the url to the stylesheet
$url = preg_match(“/(href=’)(.+)(‘ type)/”, $output, $styleurl);
// the new output based on a HTML5 valid

return $output;
Because we only want to modify those CSS styles that are placed in the footer, we make our filter run conditionally.
function html5_style_filter (){
add_filter( ‘style_loader_tag’, ‘print_html5_style’, 10, 2 );
add_action( ‘wp_head’, ‘html5_style_filter’); // the wp_head hook runs after the header scripts are printed

And voilá now we can load our CSS mid-page by calling wp_enqueue_style and get validating markup for our HTML5 page.

There’s just one disadvantage…

Because the CSS is loaded later in the page, the HTML you are wanting to style may not show proper styling straightaway, it has to wait for the CSS to load. But since we’re allowed to in HTML5 we might as well load our CSS right before we render the rest of our shortcode output. So let’s say you have a slider somewhere on your page, the STYLE element can be placed just before your slider is printed. That resolves a lot of the styling issues a visitor might see during pageload, because your CSS is loading much earlier.

How do we do this? We can’t rely solely on wp_enqueue_style because it just prints styles in the header or footer. We’ll need another custom function and we also want to make sure we retain all the benefits of enqueuing a style with wp_enqueue_style. This is covered in part 2.