So, what’s this do?

The Twitter Search Widget allows you to track any topic, live, in real-time. You can even use our advanced search operators which dogfoods straight into our own search API.

So what are these other features?

Well, for the advanced JavaScripters; or actually, I should say, ANYONE who can read JavaScript should be able to try some of these things out on your own. Which brings us to the hidden undocumented features

But first…

Let’s look at the base widget code to start off with.

base twitter widget code

<div id="twtr-search-widget"></div>
<script src="http://widgets.twimg.com/j/1/widget.js"></script>
<link href="http://widgets.twimg.com/j/1/widget.css" type="text/css" rel="stylesheet">
<script>
new TWTR.Widget({
  search: 'my search query',
  id: 'twtr-search-widget',
  loop: true,
  title: 'what people say about...',
  subject: 'stuff and things',
  width: 250,
  height: 300,
  theme: {
    shell: {
      background: '#111',
      color: '#000000'
    },
    tweets: {
      background: '#000000',
      color: '#ffffff',
      links: '#f59f00'
    }
  }
}).render().start();
</script>

What this does is load our base functionality and stylesheet. It then instantiates a new Widget object, and points to an id representing an HTML element. What this tells you already is that you could technically have multiple widgets on a page by simply instantiating new objects, populating existing <div> elements. Hey, you could create your own web version of tweet deck this way by stacking a few of them into columns :)

The features object

So there is a features object that you can pass into your constructor. There are currently four of these features.

the features object

new TWTR.Widget({
  id: 'my-element-id',
  .
  .
  .
  features: {
    hashtags: true,
    timestamp: true,
    avatars: true,
    fullscreen: false
  }
}).render().start();

Albeit mostly self explanatory, they each do this:

• hashtags: defaults to true. setting to false will hide them.
• timestamp: defaults to true. setting to false will hide them.
• avatars: defaults to true for search. and false for profile widget. setting to false will hide them.
• fullscreen: (I love this feature!) defaults to false. setting to true will give you a full viewport sized widget, perfect for displaying on large screens at events, conferences, etc.

Overall, these features are pretty great. I especially love the hashtag and fullscreen features since they are perfect for pairing.

Let’s say for instance you’re running a conference like SxSW — you could search for “#sxsw OR #sxsw09″ — and in the results, hide the hashtags so it doesn’t distract the readability of all the searches. Neat, eh?

Some examples

I went ahead and installed the widget on my own site — And here’s a few examples:

• fullscreen, hidden hashtag search for #iranelection
• fullscreen iphone to:apple (hey, we all do it)
• Or sometimes you just want to know what Evan Weaver is doing

That’s it for now

This will all undoubtedly be on our FAQ website soon enough, but it’s enough to have a play.

Happy Twidget Searching!

If any of you use our Twitter API to embed your latest statuses on your website, here is a simple little script that will do a few niceties for you. This includes linkafying, hashtagifying, and of course the most important, atify (aka: “at replies”). check out the source, and use it as such:

tweet code

ify.clean('your tweet text');

Thus making transforming a tweet such as the following:

Before and After

Bfore
Hey @ded. You should #stfu! and use http://canon.com #rant.
kthxbye @erin http://www.google.com/search?q=canon+rules

After
Hey @<a href="http://twitter.com/ded">ded</a>.
You should #<a href="http://search.twitter.com/search?q=%23stfu">stfu</a>!
and use <a href="http://canon.com">http://canon.com</a>
#<a href="http://search.twitter.com/search?q=%23rant">rant</a>.
kthxbye @<a href="http://twitter.com/erin">erin</a>
<a href="http://www.google.com/search?q=canon rules">
http://www.google.com/se...</a>

Download: source | minified

With that said, if you like one and not the other, this should still at least be entertaining and educational. If you like both, then you’re in for a treat of nerdy euphemisms and theories.

Hold on a sec… Photography? Really?

Yes, really. If you haven’t noticed, I’ve started my very own 365 Project where I take at least one photo a day, and post it there. There’s even a handy RSS feed you can drop into your favorite Reader. Anyway…

Photography and JavaScript are similar because…

• They are expressive: This is almost a no-brainer. Since the beginning of having the ability to take a picture of something, the expression “a picture says a thousand words” has held true to this day. This also great for people who aren’t fantastic with words. This spills into JavaScript because it is one of the smallest object oriented languages on the planet and allows you to express behavior and action in a variety of ways. The mere fact that we have such a plethora of JavaScript libraries these days is testament to how expressive it really is, especially since most of them pretty much do the asme thing! Just differently.
• They can be as simple or as complicated as you make them: I’ve always said that JavaScript is the closest thing we have to a ninja, but in written lexical structure. As previously mentioned, it’s a small language. But it can be very, very complicated at times, especially when you dive into JavaScript Design Patterns and begin to learn about subclassing, information hiding, prototypal inheritance, and all that other fun good stuff. Same holds true for photography in that the scientific break-thru of capturing light (onto film or a digital sensor), and modifying it by means of shutter speed and aperture, is so simple that anyone can get started taking pictures on a manual camera. On the flip side, you can turn it into a really complicated and complex hobby (or profession) by introducing flash, wireless remote systems, then umbrellas, soft boxes, snoots, grid spots, gobos… there’s also a giant pile of lenses you could buy; macros, telephotos, wide-angles, primes, zooms… the list can go on. There’s a reason why there are dedicated camera stores like B&H Photo, Calumet Photo, unfortunately there aren’t exactly stores like this for JavaScript ;) — I guess that’s what Apress and O’Reilly are for (which sells both photography and JavaScript books :)
• they are both object oriented and subject driven: Clearly, JavaScript is object oriented, there’s no argument on that (seriously, don’t get us started), but often the subject of what we’re programming for drives how we use the language. When you’re building a library, you’ll most likely use the languages object oriented features. When you’re implementing interfaces and dealing with simple tasks, you’ll use more functional JavaScript. Same goes for photography where the subjects should drive the type of photos you’ll take. When I’m going to shoot a small plant, I’m not going to pull out my wide angle, I’ll pull out a macro or telephoto. When I’m doing portraits, I’ll grab my prime 85mm. For more serious work, I can begin to create my own light with strobes. Maybe even two or three of them. And of course the real reason photography is object oriented, is because it evolves around taking pictures of objects. Of course don’t call people objects (which is slightly inappropriate), they are more or less subjects.

And so the list goes on

I could probably continue on, but I’m pretty sure most of the point has been proven. This stuff is fun for a reason, and I’ve always known that in one way or another, the two have been connected. Something about my brain latches on to simplicity with the ability to evolve. Kind of like Gmail (but this is not the forum for that). Cheers everyone, and happy Friday!

Now I’d like to invite you to yet another brain teaser, except this time your answer must require a regular expression. If you solve it, I would urge you to buy yourself a t-shirt ;)

The Problem

Write a function that takes a text input (first argument), and an integer specifying the amount of duplicates (second argument) to begin the grouping. View the following code as our skeleton:

empty function

function bookend(text, start) {
  // return modified text
}
var example = 'a a a a a a a a a bb bb c c c c d a dd dd dd dd dd dd';

var result = bookend(example, 3);
// result is 'a a a (a a a a a a) bb bb c c c (c) d a dd dd dd (dd dd dd)'

var result2 = bookend(example, 4);
// result2 is 'a a a a (a a a a a) bb bb c c c c d a dd dd dd dd (dd dd)'

In English

Bookend all duplicates that begin after the specific amount of minimum duplicates. Therefore if you specify the offset of ‘4′ as your argument, and there are six duplicates in a row, then bookend the final two. Also take special note of the spaces in the examples.

Assumptions

You can assume your text input will only be a mix of letters (eg: “\w+”), and that nothing is separated by more than a single space.

Sharing

If you come up with a solution, post them offsite. I’d recommend Pastie.org.
Happy RegExing!
Cheers!

So anyway, I ran into this problem lately with back references within the body of regular expression matches. Trust me, I’ve scoured the penultimate of documentation websites for regular expressions, and still found no clear answer, so I thought I’d share my findings through trial and error.

First, what am I talking about?

Within the body of a regular expression, you can callback a previous match by using “\1″ or “\2″ (up to “\9″ (in JavaScript, of course)). These will reference the “appropriate grouping to the left of the back reference” (so says websites that document this feature). This is true, however, what does that mean?

A quick example before we complicate things

What this basically means, using the most common example on nearly every website that explains this feature is this. Let’s say we want to replace all duplicated words in a paragraph. We would do so as follows:

replacing duplicate words

var str = "welcome to the the jungle baby baby";
str = str.replace(/(\w+) \1/g, "$1");
// str === "welcome to the jungle baby"

Notice that \1 recalls what it found in the (parenthesis) match. Ok great, most already know this, good onya.

Now, let’s put it to a confusing test. We’ll start with the following string:

hello world

var str = 'hello hello hello world hello world world';

Take a good look at the string, then compare it against the following matches:

various back reference matches

/(((hello) (world)) \1)/
/(((hello) (world)) \2)/
/(((hello) (world)) \3)/
/(((hello) (world)) \4)/

Stop effing with me

In the above four scenarios, what in the world does “appropriate grouping to the left of the back reference” mean? Clearly we have parenthesis madness everywhere (four in total), but through trial and error, they simply match the following:

back reference matches

/(((hello) (world)) \x)/
when "x" matches
1 = "hello world " (note the space at the end)
2 = "hello world hello world"
3 = "hello world hello"
4 = "hello world world"

If that bit of text doesn’t help, here’s a graphic I made to help understand it a little better:

Therefore, what this tell us is that it works from left-to-right (as mentioned) starting from outside to the inside. Take special note that if we tried to reference a match before the set of parenthesis exists yet, it is a null value. So if we tried to reference “\4″ below:

null reference to non-existing match

/(((hello) \4 (world)))/

It doesn’t work. But “\3″ would :)

null reference to non-existing match

/(((hello) \3 (world)))/

The above “\3″ would look for “hello” - thus making the entire match “hello hello world”, which is in fact, a found match. And that, my friends, concludes todays oddities in back matching for regular expressions. Happy Thanksgiving! Cheers.

Update: For the record, this is the standard forward compatible HTML 5 doctype. This should always work.

Doctypes have long been in standardista discussions circles. Why to use them. Which one to use. Which one is best. These are all <sarcasm>really fun details</sarcasm> to get into, but the most important aspect of any doctype is simply having one, since without one, you’re stuck in the lovely world of “quirks mode”. If you’re interested in understanding the anatomy of a doctype, then by all means, dive in.

At Google, we have this obsession with byte size. And by byte size, any “lack-therof” the better. Therefore the doctype you will find on most Google webpages while still triggering the browser into “standards mode” is as simple as you see below:

The skinny doctype

<!doctype html>

There is really, absolutely no reason you need the rest of the doctype in your declaration unless you’re validating code. Furthermore, it does not mean that your page is even invalid. In the end, it puts your webpages into standards mode, which is what really matters. (Plus it’s easy to memorize ;)

Try it out. It will fix your box model in IE6 and clobber all those other funny gotchas when you’re in quirks mode. Cheers.

Nevertheless, just the other day I found my problem with Regular Expressions. My process is wrong. Similar to eating vegetables, I try and skip the chewing, and simply eat them whole. With vegetables, this is a little bit easier. But with regular expressions, it prolongs the pain. Let’s take for example some of my most favorite foods I enjoy like dessert wine, and Filet Mignon. Each having tastes to savor and slowly enjoy, putting a cheery happy smile on my face. Talk to anyone who is good at regular expressions, and you’ll notice they often enjoy them just a little more than your average person.

Carefully note the differences between enjoying your food slowly versus trying to swallow it whole. The same goes for regular expressions. Cut them up into pieces, and take small bites. Match smaller portions, the rest isn’t going to leave your plate any time soon.

Why do I say all this?

I mean, aren’t all Google employees required to how to crack a CIA database? Kidding aside, even to this day I have continued to avoid using regular expressions when I know how useful they could be. So therefore I am now saying all this today to announce my early 2009 programmers resolution to eat more regular expressions. Upon this declaration I will be reading the highly recommended Mastering Regular Expressions by Jeffrey Friedl.

Also, where have I been?

Good question. I’ve been working on Gmail since last February building high fidelity prototypes to test new ideas. I’ve also been taking several photos and getting much heavier into photography than ever before. There is still rarely a day that goes by where my camera isn’t by my side. Feel free to have a gander at my featured photos. Other than that, Happy Upcoming Turkey Day. Cheers!

JS native querySelector

var $$ = function(q, b) {
  if (b) {
    return document.querySelector(q);
  } else {
    return document.querySelectorAll(q);
  }
};

This allows you to pass in a second optional boolean parameter that denotes the function to only return the first matched result as a single node. Otherwise a standard nodeList is returned. Nevertheless a problem still remains is that you still get returned something that is “array-like” but not a real array. So we’re still stuck with classic array conversion hacks:

Converting to an array

[].slice.call($$('ul > li:not(".selected"):hover'), 0).forEach(function(el) {
  el.style.color = 'red';
});

Border images

Border images can be fun if you need them. Although, the rounded corner craze seems to be dying down a bit. This would have been useful five years ago.

A better URL bar

Yes! A better, smarter URL bar, that enables you to make it behave like the old one. Check out these preferences in about:config.

Notice how you can finally turn off title matching (albeit others think this is cool to leave it as the default setting).

Tabs!?!

I’m not sure whether tabs got better, or worse. First of all the introduced a tab switching overlay pane that behaves similar to app switching in OS’s. Now when you hit ctrl + tab you get this overlay. I personally find it annoying when just trying to switch tabs… others… might like it. The only problem is, it breaks the tab switching model. ctrl + tab moves right; ctrl + shft + tab moves left. NOT SO in this case. Now when you move one over with ctrl + tab, then hit it again, it takes you back to the last one you were on rather than continuing to move to the right. (I took a small screencast to illustrate what I’m saying) This is bad. But, whatever. As long as there is a way to eventually turn this off.

And of course, Better support for “Web Standards”

I’m not really sure what this means. I didn’t scour the release notes to see if this meant anything actually useful. Since they rewrote a large core of their layout engine, they are going through regressions, so this could just mean they fixed things that were already working, but broke with the latest public release of Firefox 3.

Overall

Things are looking good and I’m glad Mozilla has overcame leaps and bounds throughout the years from a once dominated by IE6 world. My current site statistics show Firefox at 63% over a 28% IE. Indeed, times are good.

The problem is simple

First, you have an array. It looks like this:

The array

var arr = ['a', 'b', 'c', 'c', 'd','e', 'e',
'e', 'e', 'e', 'f', 'e', 'f', 'e',
'f', 'a', 'a', 'a', 'f', 'f', 'f'];

Be sure to use the array above in your example. You can iterate through an array easily with a batch function like forEach.

using forEach

arr.forEach(funciton(item, index, ar) {
  // do stuff here
});

In the end, we’d like to have an output that looks like the following:

The final output

a b c c d e e <span>e e e</span> f e f e f a a <span>a</span> f f <span>f</span>

You can use basic string concatenation while looping through the items to build your final output. Be sure to test and compare your output results with the actual results. And last but not least, the rule.

So the rule is this

In English: Group together all duplicate items that occur anytime beyond twice by wrapping them with a tag, naturally “bookending” them.
Simple, right? No, really. Tease your brain for a few minutes, you can fix that bug after lunch.