Let me preface this by saying: While I have some education in the field, and I create user experiences in software on a daily basis, I am not a User Experience professional. So take this with a grain of salt, and feel free to comment on this and point out where I err.
New Year's Python Meme 2012
The fabulous Tarek Ziadé started a "New Year's Python meme" a few years ago. This is the first time I am joining the fun. Here you go:
UpShot 1.0 with Custom Domain Support
I am proud to announce release 1.0 of UpShot, my automatic screenshot uploader for OS X! Lots of news to share, buckle up!
2 Ways to Use a Custom Domain with Dropbox
Since version 1.0, UpShot supports using your own custom domain name to share your screenshots via Dropbox.
Quick bugfix release: UpShot 0.9.1
Since I released my first version of UpShot, the Python-based automatic screenshot uploader, last week, I have received plenty of good feedback (for example on Hacker News), encouraging comments (like here on my blog), and even quite a few Issues were filed on Github.
Meet UpShot, Screenshot Sharing via Dropbox on OS X
Ways to share screenshots on the Internet are a dime a dozen.
HTML5-Compatible Blink Tag
We all know that the <blink> tag was always a bad idea. It's not part of any HTML standard, it's not semantic, and it is so horrible for accessibility and user experience that Jakob Nielsen called it "plain evil".
Fail Pets Research in UX Magazine
I totally forgot blogging about this!
Remember how I curate a collection of fail pets across the Interwebs? Sean Rintel is a researcher at the University of Queensland in Australia and has put some thought into the UX implications of whimsical error messages, published in his article: The Evolution of Fail Pets: Strategic Whimsy and Brand Awareness in Error Messages in UX Magazine.
In his article, Rintel attributes me with coining the term "fail pet".
Attentive readers may also notice that Mozilla's strategy of (rightly) attributing Adobe Flash's crashes with Flash itself by putting a "sad brick" in place worked formidably: Rintel (just like most users, I am sure) assumes this message comes from Adobe, not Mozilla:
Thanks, Sean, for the mention, and I hope you all enjoy his article.
Fun with ebtables: Routing IPTV packets on a home network
In my home network, I use IPv4 addresses out of the 10.x.y.z/8 private IP block. After AT&T U-Verse contacted me multiple times to make me reconfigure my network so they can establish a large-scale NAT and give me a private IP address rather than a public one (this might be material for a whole separate post), I reluctantly switched ISPs and now have Comcast. I did, however, keep AT&T for television. Now, U-Verse is an IPTV provider, so I had to put the two services (Internet and IPTV) onto the same wire, which as it turned out was not as easy as it sounds. <!--more-->
tl;dr: This is a "war story" more than a crisp tutorial. If you really just want to see the ebtables rules I ended up using, scroll all the way to the end.
IPTV uses IP Multicast, a technology that allows a single data stream to be sent to a number of devices at the same time. If your AT&T-provided router is the centerpiece of your network, this works well: The router is intelligent enough to determine which one or more receivers (and on what LAN port) want to receive the data stream, and it only sends data to that device (and on that wire).
Turns out, my dd-wrt-powered Cisco E2000 router is--out of the box--not that intelligent and, like most consumer devices, will turn such multicast packets simply into broadcast packets. That means, it takes the incoming data stream and delivers it to all attached ports and devices. On a wired network, that's sad, but not too big a deal: Other computers and devices will see these packets, determine they are not addressed to them, and drop the packets automatically.
Once your wifi becomes involved, this is a much bigger problem: The IPTV stream's unwanted packets easily satisfy the wifi capacity and keep any wifi device from doing its job, while it is busy discarding packets. This goes so far as to making it entirely impossible to even connect to the wireless network anymore. Besides: Massive, bogus wireless traffic empties device batteries and fills up the (limited and shared) frequency spectrum for no useful reason.
One solution for this is only to install manageable switches that support IGMP Snooping and thus limit multicast traffic to the relevant ports. I wasn't too keen on replacing a bunch of really expensive new hardware though.
In comes ebtables, part of netfilter (the Linux kernel-level firewall package). First I wrote a simple rule intended to keep all multicast packets (no matter their source) from exiting on the wireless device (eth1, in this case).
ebtables -A FORWARD -o eth1 -d Multicast -j DROPThis works in principle, but has some ugly drawbacks:
-d Multicasttranslates into a destination address pattern that also covers (intentional) broadcast packets (i.e., every broadcast packet is a multicast packet, but not vice versa). These things are important and power DHCP, SMB networking, Bonjour, ... . With a rule like this, none of these services will work anymore on the wifi you were trying to protect.-o eth1keeps us from flooding the wifi, but will do nothing to keep the needless packets sent to wired devices in check. While we're in the business of filtering packets, might as well do that too.
So let's create a new VLAN in the dd-wrt settings that only contains the incoming port (here: W) and the IPTV receiver's port (here: 1). We bridge it to the same network, because the incoming port is not only the source of IPTV, but also our connection to the Internet, so the remaining ports need to be able to connect to it still.
Then we tweak our filters:
ebtables -A FORWARD -d Broadcast -j ACCEPT
ebtables -A FORWARD -p ipv4 --ip-src ! 10.0.0.0/24 -o ! vlan1 -d Multicast -j DROPThis first accepts all broadcast packets (which it would do by default anyway, if it wasn't for our multicast rule), then any other multicast packets are dropped if their output device is not vlan1, and their source IP address is not local.
With this modified rule, we make sure that any internal applications can still function properly, while we tightly restrict where external multicast packets flow.
That was easy, wasn't it!
Some illustrations courtesy of Wikipedia.
Lightning Talk: Premature Optimization
During the work week of Mozilla's Rapid Web Development in the Bay Area a few weeks ago, we gave a bunch of lightning talks.
In my talk, I am looking at two math problems from Project Euler. For each of them, I am contrasting an intuitive solution with one that is, arguably, faster/better/uses less memory. But is it actually a better solution and an optimization worth spending time and effort on?
Check it out and let me know what you think!