LeeZilla.net

The Arduino Pro Mini in all of it’s glory. I have used...

Fri, 17 Feb 2012 17:42:00 -0800

The Arduino Pro Mini in all of it’s glory.

I have used various Arduino’s for projects and recommend them. The smallness of the Pro Mini is just shocking though.

A more succinct definition I have never heard

Mon, 13 Feb 2012 22:25:55 -0800

With RISC, though, every instruction is 4 bytes: the chip knows that every 4 bytes, it can expect to see a new instruction. It doesn’t have to work as hard figuring out the grammar.John Brownlee

John’s entire piece is an excellent read and worthy of your time. The above paragraph just blew me away. Over the years I’ve worked down deep in the CPU on both x86 CPU’s (286 FOREVER!) and both MIPS and Dec Alpha CPU’s. In that time I have never really thought threw the non-techno jargon for the difference between CISC and RISC.

Until the iPad came out. Now I have my de facto answer, as well as a fabulous article to refer anyone that asks back to.

On the experience of Apple and Safeway

Sun, 05 Feb 2012 18:35:17 -0800

Apple is rarely on record discussing company strategy, direction or goals. They tend to let the products demonstrate what they are about. There have been a number of times that Steve Jobs (and now Tim Cook) has slipped little bits out though, and they always paraphrase down to something like:

Put the end user first.

Like so much about Apple, it is amazingly simple and impossibly complex all at the same time. It can be complex to develop around, but at retail it usually means a couple of things. Training and empowerment.

Today I was at my local Safeway, getting some items from the deli. I found a company that is going the opposite way with things. The couple in front of me in line had to leave the deli and stand in a standard cashier line because they had a case of soda and bag of chips to go with their fried chicken. They asked why they couldn’t check out here, as it was only them and me in line and the deli. I was even being helped by another employee at the time.

It’s a new corporate policy, if you have non-deli items I cannot ring you up at the deliPatient Safeway Employee

After hearing this conversation, I asked the employee helping me with my own order about it. He confirmed that this was a new policy handed down from high above. Service at the deli had experienced some number of issues with customers bringing large sets of non-deli groceries to the deli cashier. Rather than training and empower staff to handle this situation in a manner appropriate to conditions, management decided to castrate their employees and put a policy in place that will not be applicable 99% of the time.

By pushing this policy down, management has told staff “You are not capable of handling basic customer service, we do not respect you.” I can’t help but feel like this is the kind of decision made by someone that has never met their customer and does not care about developing a long standing relationship with them.

I find it very weird that I found myself thinking about Apple retails stores after this experience. I’ve seen Apple employees make horrible short term business decisions (honoring long expired warranties for example) in order to foster long term relationships. They do this because Apple trains the hell out of them and gives them the power to make those types of decisions.

"That is Schrödinger’s Joke. You can know either the setup or the punchline, but not both."

Sat, 04 Feb 2012 18:43:05 -0800

“That is Schrödinger’s Joke. You can know either the setup or the punchline, but not both.”

- LeeZilla

How to Lose a Guy [Market Lead] in 10 Days [4 Years]

Sun, 22 Jan 2012 22:30:00 -0800

We’ve made a lot of changes in the past 18 months. Not changes, but also evolution. I changed a lot of my management team, in hardware, software … I’ve trained a lot of other people in the last four years. What do you think I did?Thorsten Heins

Wow. Just, wow. RIM spent 4+ years falling from market leader to market punchline, and these two gentlemen finally decide to jump ship.

Did I say falling from market leader? I should have said stagnating from market leader.

Stagnation within RIM started in the earlier part of last decade. The last (and first) great idea after push-mail was BBM, and that was somewhere around 2006. BBM is really the only end-user feature that has been fully backed and worthy of usage. Every other consumer-oriented feature in the RIM line is lazy and sloppy.

To me, RIM’s troubles go right to the root of product design. When you design a product for a specific market you have massively limited your appeal. BlackBerry wasn’t a success because people liked the product, they liked the experiences that BlackBerry enabled. Beyond that their design was based around the needs of a market (enterprise) rather than the end user (human).

In the phone / portable market it seems that when you have devices geared towards humans in a broad sense, you can always add specific market appeal via software (obviously there are some exceptions). That being the case, products that humans enjoy using will be the most successful over any period of time.

caugh iphone caugh

‘Is the iPad a PC?’

Sat, 14 Jan 2012 08:46:16 -0800

Ben Brooks turned me on to an article by Horace Dediu today. I present the quotable:

“One wonders if these “media tablets” are not PCs and yet they negatively affect the purchase of PCs whether they are indeed competing with PCs.”

I often find myself talking to great ends about the nature of Apple’s success. It seems that there are a vast number of reasons they succeed, and one of them is understanding their market.

PC manufacturers (and I lump Microsoft in here) have it in their heads that people want to buy PC’s. It turns out that people don’t want to buy PC’s, and they never did. No customer wanted an IBM XT or an Apple II, they wanted VisiCalc or Oregon Trail. They want the applications, the media and the experiences that the PC enables.

Take a moment and consider the ramifications of that vantage point. People don’t want PC’s, they want the experiences they enable.

This is where Apple has long succeeded. It is why Steve Jobs pursued the Macintosh, with it’s GUI and mouse. Reduce the barrier to using a computer, advance the world out of the terminal prompt. The iPad is an evolution of that, and it took Steve Jobs many years to clarify his thinking. To quote the man himself:

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

If adding a GUI and a mouse to the Macintosh all those years ago enabled customers that much of a revolution to the experience, what did the iPad represent? It almost directly connects us to the experience. We have directly added another dimension to how we interact with these things. In the pre-iPad times we experienced our applications and media with our eyes and our ears. We now physically touch our media and applications.

We use our hands to experience the world. Touch is the very first of our senses, from almost the moment of zygote (slight exaggeration of course) we can sense through our skin. When we enter the world, we might see something first but we grab it in our hands and explore it with touch in order to fully know the new object. Touch is a powerful way to relate to an object, and most users anthropomorphize their iPads and iPhones because of this relationship.

iPads are impacting PC sales because nobody ever wanted a PC. Now that there is something genuinely BEYOND what a PC is and can do, why would anyone go back?

Apple Mini-Stores

Fri, 13 Jan 2012 11:29:58 -0800

Paul Thurrott offered up this gem today:

Oh good, I was just thinking that what this country needs is more Apple Stores. I have an idea: Rather than build all this crap, why doesn’t Apple just unilaterally make each of its products available for 25 percent less than the current selling price? It would save money, raise market share, and benefit the millions of people who can’t actually afford all this stuff to begin with.

I love this kind of link-bait punditry. It reads good, it’s sensationalistic and it’s batshit wrong. A massive portion of Apple’s success has been creating a retail environment completely foreign to consumers. The pre and post purchase experience of owning an Apple product is part of the product itself. A big part of Apple’s strategy is not to sell a product, it is to create a customer.

What Paul is really suggesting is going the route Dell did. Dell products suck. Dell products suck. I hated supporting them in the datacenters I worked in and on the desktops as a user. Apple has a vision that is proving to be what the public wants, and the have the management team to continue to refine and improve an already world-class ecosystem.

EE, MSM and Datagrab

Mon, 07 Nov 2011 11:04:44 -0800

Over the weekend, twitter user @audiopleb ran into issues importing data to Expression Engine MSM sites via Datagrab. This is something we have a huge amount of experience in back at the office. That is to say, migrating data between sites (Non-EE -> EE and EE -> EE) is something of a specialty of mine.

One of the issues I’ve noticed with Datagrab (indeed, other add-ons as well) is how they deal with MSM sites. Datagrab for example uses this parameter to do a lot of it’s internal MSM handling:

    $this->EE->config->item('site_id')

This seems to mean that if you are accessing the control panel via http://site_1/system, then site_id will always be 1. For some reason, possible depending not the version of EE/MSM/Datagrab, changing the site via the CP drop down does NOT update the site_id value (at least according to Datagrab). My workaround has been to access the CP via the secondary sites URL. For example, use http://site_2/system. This seems to get things where they want to be.

All you really need to do to make this happen is put a copy of /admin.php somewhere under site_2. I use this structure for my sites:

/ee_system/ - site_1 system
/html/ - site_1 web root
- /html/sites/
  - /html/sites/site_2/
    - /html/sites/site_2/dashboard/index.php - site_2 version of admin.php

Edit the site_2 version of admin.php to point all the way back to your main EE System folder via the $system_path variable. Mine looks like this:

    $system_path = '../../../../ee_system';

This keeps things nice and relative for easy migrations. I’m sure there is a solid explanation for this occasional behavior, but every the I’ve hit it I have been deep into a time-sensitive work. Some day I would love to understand why this happens, and why my work-around (aka, dirty hack) seems to work so consistently.

Google and the patent double talk

Sun, 06 Nov 2011 20:35:00 -0800

Care of SFGate.com.

It’s fair to say that one of the most effective ways to respond to a threatened patent assertion is to be able to assert patents of your own.

- Tim Porter, Google Patent Council

So then the plan is to:

Like what the iPhone is doing
Do a half-ass implementation of that thing you liked
Shit-talk the patent system when the thing you stole gets noticed by who you stole it from
Get your hardware partners sued from now to the end of time

At least they don’t have a corner on anything important, like information storage, indexing, searching and presentation.

Shit.

AB Seeing your sites performance

Sat, 05 Nov 2011 10:47:00 -0700

The subject of Expression Engine Snippets versus EE Embeds was recently brought back to my mind by Jean St-Amand on Twitter yesterday. It has been some time since I’ve thought about the matter, so this got me thinking a bit more about EE performance. First, some background on how we got sideways and how we solved it. Then some zen learnings at the end.

At the office, we are now on the 3rd major version of our core web product. The second version of that product was our first EE project as a team, and my first EE project ever. I am fortunate to have come in with EE 2.1.0, and I was hooked right away. It was one of the more complex systems my partner in crime has built on EE, containing over 7,000 entries at the time we did the initial build (now well over 10,000 entries). We used every trick in the book to build this thing out, and by every trick I mean every WRONG way. Related entries for every entry, categories by NAME as part of our URL structure, and my LORD did we have some embeds. Our home page must have embedded 4 levels deep at a minimum. Some of those embeds went out and performed relationship lookups to then perform a 5th level of embeds.

Looking back at the pingdom records, page response time had pass the 5.7 second mark. 5.7 seconds. There are cars that could go 0-60 mph in that time. TWICE. AB testing from a good solid cable broadband connection showed a number closer to 11 seconds. ELEVEN. Once we factored in a normal user internet connection our response time almost doubled. I was embarrassed. The smallest site (by unique visitors) I had worked on in quite some time and it was performing this poorly? We started upgrading hosting. Then migrating. Then out came Varnish. I’m not saying that Varnish is a bad tool, but by this point I knew I was just hiding the root cause. By this point I had learned enough about EE to understand the error of my ways. Vint Cerf gave me the look of a disappointed grandparent.

I bring up Varnish for a reason. It’s good. Use it. Or Memcached. Or both. I don’t care how clean your architecture is, how fast your server. Even small amounts of traffic will clog things up on smaller VPS hosting or low-end dedicated stuff. Varnish keeps traffic from even getting into your AMP stack. Memcached can help keep things out of PHP and MySQL. Learn them. Use them. IronCache makes playing with Memcached simple, I highly recommend it. The Grist Labs team is awesome.

In the recent past we had enough time to both redesign and refactor this core site. Combining over a year of EE learnings along with a better understanding of our product and customer combined powers to generate a much better product. Everything was turned into snippets. As a rule we avoided any embeds. Ditto for any type of relationship field. We found some exceptions to the embed rule, but held firm to the relationships issue. Embeds became a tool ONLY for exposing integral data and not just for making our code “look clean”. We worked hard to understand when and where an embed was needed and when other strategies solved the problem.

The numbers tell the story. The problem version had 56 embeds in our global includes template group. The new version has 14. These 14 are also infrequently used in our code. We plan on replacing a lot of these 14 with jQuery tricks in order to take the direct embed out of EE. That will make an interesting write-up of it’s own when finished.

AB testing from a normal user connection followed this line of performance:

Version 2 - Bare System: 11 seconds
Version 2 - Varnish: 0.8 seconds wow, Varnish is cool!
Version 3 - Bare System: 1.2 seconds wow, Snippets are cooler than Varnish!
Version 3 - Memcached: 0.6 seconds

Those are some telling numbers. As I said before, use either Varnish or Memcached. Use both if you need, they are NOT mutually exclusive. After refactoring into Version 3, our site performance almost caught up to Version 2 with Varnish. Note that our data structure changed in just one way: Removal of all relationships. We used two relationships on the site, but they were used on almost every single page. Worse, each relationship was usually used to feed an embed. Terrible combination there.

The Zen Learnings

Test early and test often. In the traditional software world (think C++ or Java) testing is done at nearly every stage. My best developers always turned out code that was performance tuned. You do this by testing performance on each component as well as testing performance on the integrated whole. This can be done and SHOULD be done with web development as well. I feel ignorant for not doing this the first go around. How to test? AB is the standard tool for simulating load. Combine this with server utilization numbers (I use sar 4 5) and you have a winning combination.

How do you run the test? AB makes it easy, and it should be a standard install on Linux systems as well as Mac OS X. You run it like this:

ab -n 500 -c 20 http://www.mydomain.com/

Pretty straight forward so long as you know that:

-n 500 means to snag the requested URL 500 times (-n, number, get it?)
-c 20 means to run 20 gets at a time (-c is concurrency)
http://www.mydomain.com/ is the target URL to get. I seem to need the trailing / on this to make AB happy.

When do you test? All the time. Continuously. Test each Snippet, embed and template individually then after integrating them. Create a template that just contains a single snippet with just enough supporting EE code to test what is inside of that snippet. Use preload:replace to test embeds. Test every time you think you are “done” with a feature. Test against your local dev machine. Test against production. Test, test test test and test some more.

There isn’t a magic bullet for knowing when your code is fast enough or clean enough. Indeed it is easy to assume it IS fast enough. Always challenge that assumption. It will make you think cleaner and clearer about what you are trying to do. It will force you to learn things you didn’t know existed. It will cause you to see the world from your end-users perspective. One last bit of zen advice I learned in my performance seeking adventures:

Not all fast websites are good, but all good websites are fast.
- Me, right now

MSM and the mysterious Logout issue

Wed, 02 Nov 2011 21:22:56 -0700

On the #EECMS zone of the Twitterz today, Matt Everson of Astuteo was having a problem with MSM and mysterious logout issues. His reasoning was that this cropped up with EE 2.3.x, but I have seen it as far back as 2.1.0. The solution is simple enough. Via the control panel visit Admin -> Security and Privacy -> Cookie Settings. You need to set the Cookie Domain as appropriate. For me I wildcard it out a bit, like this:

.mydomain.com

Repeat this once for each MSM site under the install. Problem solved? Good. Now, why is this the solution? When a cookie is issued to the client browser, it is tied to that Cookie Domain value. That is really the root of identity for each cookie. After the domain, you then have the Cookie Path and the Cookie Name.

The next bit of knowledge that helps build on the understanding here is that EE manages your login based on a Session ID number. That Session ID number is stored in a cookie named exp_sessionid. This is a simplified way to think of the cookie that results from a control panel login:

[cookie domain].[cookie path].[cookie name] = [cookie value]

If we login to Site_1 of an MSM install, we might get something like this:

[.mydomain.com].[/].[exp_sessionid] = 123456789

It is important to note that EE will use the domain for the FIRST of the MSM sites if no configured value is set for Cookie Domain across all sites. That means if you then logged in to Site_2, you get a new cookie with the new Session ID. That cookie would have the EXACT SAME identity tree, and would then overwrite the cookie set by Site_1. Now there is no longer a way for Site_1 and your browser to track the session you are with on the server and you are logged out.

Setting that unique Cookie Domain will allow you to have multiple cookies with differing domains but the same name (exp_sessionid). Since nothing gets overwritten once this is setup you are able to keep your login working.

Looping through the Matrix

Wed, 02 Nov 2011 20:32:26 -0700

Anyone out there use ExpressionEngine? Okay, settle down. Anyone use Pixel & Tonic’s Matrix field type? Likely that the same number of people just raised their hands. Now, how many of you custom-dashboard-matrix-using-expression-engine developers also use jQuery?

That should have been everyone as well.

One of the challenges we run into at the office is looking at the values of a Matrix field to compute, compare or validate on. For example, one might have a matrix with this format column format:

Item Description | Price

Very simple data entry example. Item and Price. At any time you might want to get an updated Total Price number to the end user. Looping over the entire Matrix is the pain point we found a nice solution to. Take this jQuery snippet as our reference bit:

    $('div#field_id_106 textarea.matrix-textarea[name^="field_id_106[row_"]').filter('[name*="[col_id_38]"]').each(function() {
        // Do some cool stuff here with the data. Access the local cell with
        // $(this).val()
    });

The jQuery warriors among us are saying “Well, yeah, duh!”. The rest of us are looking at Sanskrit. The magic are the name^= and the name*= selectors. First, we select down to the Matrix we care about. In my example, it is contained inside of div#field_id_106. Next I select down to the textarea stuff, since the fields I care about here happen to be textarea fields. Now for some magic.

[name^="field_id_106[row_"]

The operator ^ after the name attribute tells us that the selector we are isolating down to must START with the string field_id_106[row_ in order to be included. Stopping at the row_ is a trick that really made this useful for us. Both NEW matrix rows as well as UPDATE matrix rows (existing values in place) will contain this. You won’t need to know anything about the matrix you are looking at in order for this selector to work.

Last I add the .filter() to our object. This filters further to look at a specific column in the Matrix. I take advantage of the * operator here (can contain ANYWHERE), and I look for the [col_id_38] string in the name attribute. We wrap it up with the .each() call, and now we have a nicely set loop. Within the loop we can get to our cell values with:

$(this).val()

There are going to be a lot of ways to slice this turkey, and I would love to hear from anyone else that has faced this issue. Are there even cleaner ways to get into the Matrix cells via jQuery?

The myth of the overnight success: App Store Edition

Wed, 02 Nov 2011 18:56:35 -0700

Today Chris Steven posted an essay (or rather, a marketing piece for his book) on the randomization of success rates in the App Store. As a current and former App developer, as well as a long time commercial software developer, I do not like his Casino analogy. As a long time gambler, I also don’t like being reminded that there isn’t a way to “beat the casino”.

Chris has been involved in successful consumer software, and his post can be taken as being “from the horses mouth” in that regard. Successfully making a living via mobile software is a very challenging niche. But to equate success to anything inside of a Casino is just silly, as mobile games don’t provide free drinks. It doesn’t matter if you are selling nails, books, art or video games. Perhaps luck can help you shortcut a path to success. But hard work, intense research and development of your product are fundamental to success.

Rovio. Overnight they became one of the biggest franchises in the world of mobile. Overnight. Of course you must ignore the previous 6 years of experience the company built on. The principals started a path in 2003 together that led to 51 dismal failures. Poor character design, ungainly gameplay and hardware platforms that nobody used all conspired to create repeated failures. Read that again. 51 games that failed to be “huge”. The fortitude to push forward again and try number 52 is what separated them for the other slot machine players in the casino. By the time Angry Birds hit big Rovio already had Platinum Players Club status.

Rovio had to develop an understanding of their market. Indeed they had to develop this understanding while the market was being ripped apart and redesigned by Apple. They honed their personal identity, game concepts and business processes over these repeated failures. They sought and achieved angel funding to keep the lights on while driving forward. Hard work. Long days. Short weekends. Iterate, iterate and iterate some more.

Did this hard work and iteration guarantee success? Hell no it didn’t. Not even close. Did it guarantee that when a little bit of luck did happen that they would be in the right position to turn that into maximum success? Hell yes they did.

This is where the analogy to a casino is flawed. In a casino, you can walk in and hit a jackpot on the very first spin of a slot machine. Drop in your $5 bill and win big. You cannot do that with software. Winning big means you have iterated on a product over and over and over again. You have honed the details, worked with your customers and developed a core following.

When the first time a developer enters the casino (publishes a product), they might get a little win. If they are lucky. That same first-time developer will have a buggy product that is very likely incomplete or short on content. It will be ill marketed and ill supported. It will be bargain-basement priced. They have stacked the deck against themselves by trying to sell a poor product in a poor manner.

The next time a developer enters the market, he will carry the weight of that failure. He will know to have a better tested product. His product will be complete and flushed out. There will be a nice website and support system in place. It will be priced off of the floor level. They have begun to stack the deck in their own favor. A great product requires more than just itself to succeed. It needs all that support surrounding it to stand upright and live.

Even though I don’t like the Casino analogy, I’m still going to read his book. Chris has been on a side of the market (massive success) that I have not been on. Some day I would like to see what he has seen.

Interested? Amazon has it for both kindle and tree.

The Great Texture Debate

Tue, 01 Nov 2011 22:15:00 -0700

Not long back John Gruber posted a bit of thinking surrounding the Skeuomorphic UI Textures that Apple has started using and expanding on. This piece was a response to James Higgs criticism of the same. Both Gruber and Higgs are some of the most thoughtful and insightful journalists around, but both can prone to “inside the machine” thinking. By this I mean that some folk (myself included) see design decisions like this as obscure and unneeded. We are entirely right. leather trimmed textures are stoopid. Yes, stoopid. Two O’s and zero You’s.

We don’t have leather trimmed desk blotters. We don’t carry paper and leather day planners or contact lists (didn’t they used to be phone books?). Why should our software have something our “real world” doesn’t?

I am not the target of this design. Higgs and Gruber are not either. For the target audience I must look to my Father-In-Law. 64 years young. Handle bar mustache. 30+ year veteran of the Washington State Department of Corrections, prison guard to the non-con and outsider. Also a well educated man, smart by smarts standard. He reads more in a week than I do in a month.

He won’t touch a computer.

He is afraid of them. Not evil per say, just something he feels is beyond his abilities. He does own a desk blotter and a phone book. Both leather and paper products. He owns an iPad (1st gen) too. He just “gets” the iPad. Ask him and he will tell you “anyone with half a bean in their noodle would make a computer as simple as an iPad”.

This Skeuomorphic trend (beautiful word, skeuomorphic) is about your Father-In-Law. It is about pushing further distinction between computers and Apple’s. Computers are hard, cruel and beyond the average man. Apple’s are something else entirely. Hell, the iPad is a physical object. You interact directly with it. Zero abstraction between intent and input. A book is much the same, as is a desk blotter.

The “wrapped in leather” look represents the reality that most of the world is still afraid of computing devices. Apple solved this problem without patronizing my Father-In-Law, and without alienating the tech-forward among us.

"Has anyone seen my triceratops? He’s fanTASTIC!"

Sun, 30 Oct 2011 21:10:48 -0700

“Has anyone seen my triceratops? He’s fanTASTIC!”

- Zombie Christopher Walken

Two Weeks with an iPhone

Sat, 29 Oct 2011 18:44:36 -0700

Shhhhh… Don’t tell my F.O.S.S. friends, but I have switched to the “dark side”. After spending a tick over two weeks with my iOS partner I have some odd thoughts on the matter. Odd because they are not the things I had anticipated, but probably should have.

First, iOS lacks a lot of features that are on some Android devices. For example, I haven’t had to reboot my iPhone once. It stays functional, and it stays working.

I’ve never had the dock go MIA on me. I turn the screen on, and go to work. Icons are where they should be. Moving between screens happens without massive redraw showing it’s face. I liked watching the screen refresh. I felt like I understood the nature of my machine. iOS? I have no clue what it going on in there. It is just magic, and that scares me a little.

No lag. None. My old Android had TONNES of lag. I kind of miss it. Without all the wait time I am forced to get things done. Did I just intend on making a call? BOOM. Call happens and I am now required actually conversate with the other party.

Yeah, that was a bit of sarcasm. I apologize for that. It started out with good intentions but quickly went sideways. My very initial thought did concern a lack of features. Android just packs features in everywhere possible. Lots and lots of features.

If Android was Windows, all you Stallman fanatics would call that BLOAT. Since this is Linux based though, we will forgive you your hypocrisy. Much like Ubuntu, Android is just an over-bloated whale. Loved by all, useful to nobody.

After two solid weeks though I realized that my iPhone friend packs in a lot of features. It limits itself to the features that are actually useful though. Do I want the ability to install additional browsers? Hell Yes. Did I EVER use those browsers on any of my old phones? Nope. The long story short is this:

What is popular isn’t right. What is right is INCREDIBLY popular.

I also need to highlight the GET IT DONE attitude my Cupertino companion has. Everything just moves fast and smooth. It is so responsive to touch that I feel like it actually reacts to my touch BEFORE I have physically come in contact with the glass. I never really felt like my last Android device was slow or laggy. But that was ignorances bliss and not reality.

I guess to summarize, two features jump out and stick with me. Every single feature on the phone is polished to a beautiful shine. They work exactly the right way. And they work FAST.

The jQuery, The Link and The Target

Sat, 29 Oct 2011 10:56:00 -0700

I received an e-mail yesterday evening from someone using some old ExpressionEngine plugin of mine. Specifically it was Rewrite Links, and I have long since orphaned this. The story behind this plugin was that my content people did not consistently use target=”_blank” for outbound links. At the time, ExpressionEngine was new to me and I was trying to use it as the hammer for every nail I found.

That was a dumb way to go. About a month later I found several bugs with the methodology and realized the code path was fundamentally flawed. As I am still in denial about making such a poor engineering choice so I will avoid discussing what I messed up and move on to my solution. Long story short, the above e-mailer had run into these bugs as well and was curious if I had seen and solved them.

I am getting rather good with jQuery. Good enough to be dangerous anyways. My solution for some time has been a little jQuery snippet in my footer. The absolute minimal approach is to stick this at the end of the page (or in a $(document).ready() call):

  $("a[@href^='http']").attr('target', '_blank');

This bit looks at all the A tags in the page, then filters down to tags with the characters http in the href attribute. All results get target=”_blank” added to them. Very simple, fast and effective. We can even expand the concept a bit in a number of ways. Most useful to me has been to use the .each() iterator with it.

  $("a[href^='http']").each(function() {
    if( $(this).attr('href').indexOf('localdomain.com') < 0 ) {
      $(this).attr('target', '_blank');
    }
  });

This is getting to be a pretty powerful bit of code. Going back to my content people, they all seem to use different types of links for on-site stuff. Some of them use a relative path. Some of them use absolute paths. Some of them use absolute paths without the WWW. in front of our domain. We force that in our .htaccess file. The above snippet applies this logic:

All link tags
That contain http
That do NOT contain localdomain.com
Add the attribute target=”_blank”

This has proven to be pretty effective for us. It is important to leave out the WWW. from your localdomain.com in the IF conditional. Some users will use it, some will not. Your site might force WWW, it might force NON-WWW, or it might not care. By using the 2nd level naming only and dropping the 3rd, you will get what you intend with less fuss and failures.

If you really REALLY wanted to, you could even replace the hard-coded ‘localdomain.com’ string with document.domain. To keep things sane, just check for and truncate any WWW. from the return and you have code you never need to touch.

Maybe something kewl like this, tossing some :not() selectors into the mix:

  $("a[href^='http']:not(a[href^='http://" + window.location.host.toLowerCase() + "']):not(a[href^='http://www." + window.location.host.toLowerCase() + "'])").attr("target", "_blank");