Firebug and CSS Specificity

I was trying to get my Twitter widget (adapted from the Twitter Fan Wiki) to show a profile icon beside my own updates.

My original code was:

<style type="text/css">
.twitter_self {
background-image: url("http://www.blogblog.com/rounders3/icon_profile.gif");
}
</style>

I used it like so inside the widget code:

<ul id="twitter_list">
<li class="twitter_self">my update message</li>
</ul>

But what was this? The original arrow icons kept showing up!

After a little googling, I discovered Firebug, an amazing, free Firefox* plugin that, IMHO, all web developers should install. It allowed me to inspect Javascript-generated elements, among other things (like single-stepping through Javascript and live code/CSS editing), and I was able to confirm that my code was being overridden by the main skin style.

(* "Lite" version available for other browsers)



So I googled some more and found the wacky CSS: Specificity Wars page, which let me know that the spec says

ID selectors have a higher specificity than attribute selectors.

Aha! So I fixed the code like so:

<style type="text/css">
#twitter_list .twitter_self {
background-image: url("http://www.blogblog.com/rounders3/icon_profile.gif");
}
</style>

... and all was well. An easy problem to solve, but I learned something new.

more > | full >>

< less | full >>

Hai(na)ku

I still haven't slept after a night out with the bros and friends. So, I decided to write some haikus* (geek!!) inspired by certain events, conversations, and beer-induced imagery of last night (and today, pre-dawn). I wrote five, initially, but then I tried to do what I did before in high school: write 26 haikus, one for every letter of the alphabet.

I only managed 12. Maybe I'll add some more after I get some sleep.

Ah well, not too bad, considering. But then again, you'll probably get depressed reading these, heheh. Don't say I didn't warn you.


Ahead of the pack
Yet all is green as they preen
Mates that have their back.

-

Basking in the sun
Petals wilting with the wait;
Bees land on a bud.

-

Constricted no more
Spirit soaring, running free;
The future unfolds.

-

Dust-flecked empty chair
Between four others, still warm;
A friend, sorely missed.

-

Engulfed by duty
Carefree pleasures are no more;
No infinite road.

-

Freed from sleep's unease
Arms reach out and fingers seek
Naught is there but air.

-

Gone, and yet not gone
Fettered to another loosed,
Two linked birds in flight.

-

Haughtily black-clad
Scented flowers of the night;
Buzzing flies abound.

-

Icy flakes appear
On a yet-unfurrowed brow;
Freezing words still flow.

-

Laughter fills the night
But beneath the joy and warmth,
A cold dread uncoils.

-

Mountain winds arise
Shelter foremost in the mind;
Flowers go unseen.

-

Pollen in the wind
Swirling, questing to no end
Arid earth reclaimed.



* Haiku, senryu, zappai... whatever. ;-)

more > | full >>

< less | full >>

Dynamic DNS and transparent proxies

I prefer having my DynDNS account updated by my Linux-based DSL-500T ADSL modem/router (flashed with Russian firmware) since it means the host updates occur every time a PPP session is established. Otherwise, I would have needed an inefficient cron job at my main box.

I haven't needed to access my PC remotely in the past few months, so I just recently noticed that my DynDNS host wasn't getting updated. At first, I thought there was something wrong with the router, but after my previous blog, I noticed that my host's registered IP address was that of (you guessed it, good for you!) Globe's transparent proxy.

It turns out my router's ddns call (hardcoded in the router's firmware-flashed XML) was using automatic IP resolution, i.e. DynDNS used whatever IP address the update command came from.

So, I downloaded the current XML configuration, made it more editable with HTML Tidy (tidy -xml), fixed the command to use -i ppp0 instead of -r, mashed the XML back into a single line with another one of my quick-and-dirty scripts (clutter), and reflashed it into the router. After it rebooted, my DynDNS account was being updated properly again. Phew.

ddns -u myuser:mypass -h myhost.at.dyndns -w -r -q -i ppp0

If any of you are having similar problems, check if your ISP has a transparent proxy. If you're lucky enough to be able to customize the commands your router runs, the above might be of some help.

Of course, if you're really lucky, your router doesn't have this problem in the first place. :-P

more > | full >>

< less | full >>

Indiggnant at Globe DSL

I've been getting a blank page trying to login at Digg. It seems that a lot of people are having this problem, likely due to some bad transparent proxying by the ISP.

So I did a tcptraceroute to check if Globelines was using one:

# tcptraceroute digg.com
Selected device eth0, address 192.168.1.250, port 51873 for outgoing packets
Tracing the path to digg.com (64.191.203.30) on TCP port 80 (http), 30 hops max
1  192.168.1.5  3.372 ms  1.052 ms  0.651 ms
2  203.177.x.x  18.164 ms  18.177 ms  18.692 ms
3  222.127.x.x  18.108 ms  18.133 ms  18.378 ms
4  digg.com (64.191.203.30) [open]  18.395 ms  18.258 ms  20.177 ms

Aha! Time for a bypass.

Since I have SSH access to a number of servers, I just set up a SOCKS tunnel,

$ ssh -ND 8888 my-remote-server

then setup my browser to connect to localhost:8888 (SOCKS v5). I tried logging in to Digg... voilà!

Globeline's transparent proxy (apparently Blue Coat) does work for most sites, so I also installed the FoxyProxy Firefox add-on. It allows me to specify which proxy to use with what sites.

If you don't have access to an external SSH server, and are having similar problems, you could probably just use a public proxy server instead.

UPDATE 1: It seems Globelines has turned off its transparent proxy. A tcptraceroute to digg.com now shows 11 hops, following the same path as the normal traceroute. I wonder if this has anything to do with all those cut underwater cables, or it was just that too many people complained.

UPDATE 2: And... it's back again. Get your act together, Globelines!

more > | full >>

< less | full >>

Self-hosted Flash Video

Nowadays, the easiest way to upload videos to the web is via Google Video, YouTube, Metacafe, Vimeo, and the like.

If, for some reason, you want to host your videos on your own server, here are 4 steps to easily do this in Linux:

1. Convert your video using ffmpeg:
   ffmpeg -i your.avi -s 320x240 your.flv
   
   
2. Grab JW FLV Media Player and extract mediaplayer.swf
   
   
3. Upload your FLV file and mediaplayer.swf to your server.
   
   
4. Edit your HTML file to include something like this (one line):
   
   <embed src="mediaplayer.swf" allowfullscreen="false" allowscriptaccess="always" flashvars="&amp;file=your.flv&amp;autostart=false" height="240" width="320"></embed>
   
   or the more standards-compliant
   
   <object type="application/x-shockwave-flash" data="mediaplayer.swf" width="320" height="240">
<param name="allowfullscreen" value="false" />
<param name="allowscriptaccess" value="always" />
<param name="flashvars" value="&amp;file=your.flv&amp;autostart=false" />
</object>
   
   Note that the latter is not viewable in the Nokia Internet Tablets.
   
   

You should end up with something like this:

Hosting your own videos allows you to avoid any branding that a third-party host might impose -- perfect for intranet/corporate use. You should also check out the various features, such as playlists, that JW FLV Media Player offers.

Enjoy!

more > | full >>

< less | full >>

Thumb-thuking good

Eyan and I had dinner again at Thuk Thai. This time we were joined by Togz. We had spare ribs, pork omelette, kangkong, Tom Yum with coconut milk, and bagoong rice, washed down with a couple bottles of beer. Yum!

Do check out Thuk Thai one of these days, behind Rufo's on San Miguel Avenue, Ortigas. It's an unpretentious place serving great food at reasonable prices.

more > | full >>

< less | full >>