Nikola Tesla, named by The Oatmeal the “greatest geek who ever lived,” was born on this day in 1856. And on the occasion of his 157th birthday, we’d like to share this great talk about the inventor who held more than 700 patents, including ones for alternating current, the radio, the remote control, the electric motors and neon lighting. The talk, given by illusionist Marco Tempest at TED2012, celebrates Tesla’s inventive mind, but is not purely a celebration. The talk also tells the story of the project that was Tesla’s undoing — a wireless telegraphy center in upstate New York that he envisioned being used to contact other planets. He became a recluse.

All in all, on Tesla’s birthday, it’s a meditation on the innovative spirit — and the importance of giving great thinkers the opportunity to dream, try and occasionally fail.

Not really, sort of. If premature optimization is the root of all evil, oversemplification is the coder way to hell. Let me share an almost perfect example of the latter, found in a well known premium ( = paid) theme out there:

.ar{ text-align: right; }
.fr{ float: right; }

It may sound beautiful: “a CSS class I’d actually use when I write code in the editor!”.

Yes, maybe. Let’s say you’re going to build a multilanguage website: you’re probably add language_attributes() to the <html> tag and you’ll be fine – unless you’re going to add support for a language with Right-to-Left direction, like Arabic or Hebrew.

Your stylesheets will need proper RTL support, and a language-dependent CSS class in the <html> or <body> tag will help a lot. You may find yourself coding a quick snippet like this one:

Now, what can be wrong? It’s a clean snippet with a proper filter on body_class and nothing more, except the wrong CSS class. What kind of LANGUAGE_CODE will have – for example – Arabic? AR. French? FR. And how this will render in the snippet above?

<body class="ar">
<body class="fr">

Two lessons here:

if you really need to name your CSS classes after a two-character shortcode, at least namespace it.

if you need to add semantic CSS classes to some tag, check your theme’s CSS files before (well, check ’em before anyway) and namespace your CSS classes as well:

I spent a lot of time tweaking my own Textmate setup in the last years, than I switched back to linux and I was stuck: Textmate is the *best* code editor I’ve ever seen, even if it’s OSX only I hope that many other code editors will borrow some of its powerful text-mangling features (because it has been open sourced).

Sublime Text is my new editor of choice, it’s really powerful even if it’s not on pair on everything with Textmate (but I’m sure it will catch up: it’s actually the best editor on linux), it’s not actually open source (nothing wrong with that, just a personal preference) and it’s a little too Python-focused for me (but this could be a plus for some other devs).

One feature I really loved is its Textmate bundle support, as I’m finally able to have the very same color scheme in both linux and OSX: I can write code anywhere with every tool but one thing really annoy me: color schemes (or lacking-of). Here’s mine:

My color scheme on Sublime Text 2 (linux)

You can find this color scheme on BitBucket, feel free to grab it and contribute your enhancements if you like. Enjoy!

One of the biggest problems in the WordPress community are abandoned plugins. This is a real issue for WordPress users as well as administrators, sometimes even for authors and developers as well.

(Disclaimer: I feel guilty on my own: my first two open source plugins were so badly coded that I couldn’t fix them; users switched, I though I learned a lot from this mistake. Wrong. Years later I forked another abandoned plugin, then I become mantainer of the original one, then I was stuck again, couldn’t find help any way and had to abandon the plugin after its creator, leaving it unmantained. I think I know the problem inside out.)

In the past there was some private effort to deal with this, like the WP Recycle program from PluginChief, but it didn’t gain a lot of feedback from both end users and developers and it quietly shut down. (I’m sure to have read an interview with a PluginChief guy about the project’s EOL but I can’t find it anywhere).

As a developer myself I feel plugins and themes are sometimes difficult to mantain and support: authors and developers may lack the knowledge required to fix (or even identify) some bugs, while cooperation and reciprocal support between projects is a rare thing.

Lack of satisfaction and motivation is also another common cause: authors may feel “slave” of their open source plugins because they are supposed to provide free lifetime support while – at the same time – they may have their own issues in their personal life, or they are having hard times making a living out their freelance work (something I experienced on my own. both. twice.)

I feel that the WordPress community is lacking a couple of tools that would make plugin and theme authors’ life really easier.

First one is a dedicated online place (being it a forum, a list or whatever) to share coding best practices as well as to ask for help, exchange coding for graphics work or look for a new mantainer. This should be an official community effort (aka: in the wordpress.org realm) and should complement the tools already deployed – like the wp-hackers list – in a clear web interface. I would really love something like that.

The last tool I think we’re lacking is a sort of “open source marketplace”, based on a simple and proven concept like Flattr. Let’s call it “WP Karma” 🙂 I’d like to think an easy process to support open source developer: let users define their monthly contribution, divide it by *installed* plugins and themes, count each plugin/theme days of activation and give each plugin/theme author it’s own.

I feel those tools would really empower and strengthen the community as a whole. I’d love to help build it but not on my own, so I’ll try to spread these concepts in the WP community, let’s see what happen.

(aside: I’m trying to get used again to english writing after a long time, fix and suggestions are welcome! )

I walked into a friend’s home and found the fridge covered with refrigerator art from her seven year old. The traditional home often features such childhood artwork but this was extremely precious as the child has learning disabilities and drawing.

The artwork was beautiful. I stood there transfixed at the crude scribbles, trying to find distinguishable shapes and forms. Then I realized it didn’t matter. They were her attempts to connect visually to her world and translate it.

A few days later I watched a presentation by Aarron Walter, author and UX director at MailChimp. He explained how we need to design “small kindness” into our site designs, personal touches that connect with us personally through personality, story, and voice.

It’s not about the products. It’s about the effect of those products on the people and their lives.

Since WordPress 3.6 is in beta, I thought I’d use this nearly-abandoned blog (hey, been busy working on WordPress!) to talk about some of the cool stuff for developers. For the first installment, check out the new shortcode_atts_{$shortcode} filter. The shortcode_atts() function now accepts a third parameter — the name of the shortcode — which enables the running of this filter. All of the core shortcodes now pass this parameter.

This filter passes three things:

$out — the output array of shortcode attributes

$pairs — the array of accepted parameters and their defaults.

$atts — the input array of shortcode attributes

Let’s look at what we can do with this. One thing is that you can dynamically set or override shortcode values. You an also define new ones, and transpose them into accepted ones. Let’s look at the “gallery” shortcode for example. What if there was a gallery of images…