Adventures in IPv6 Land

I've been reading about IPv6 for years now, and finally decided to take the plunge last weekend.

The goal was to

1. sign up with a tunnel broker
   
2. get an IPv6 subnet
   
3. set up my home Linux server as the endpoint
   
4. configure said server to advertise itself as an IPv6 router to the home LAN.
   

SixXs had been recommended to me as a tunnel broker, so I headed over to their site and signed up. Then I waited. And waited. I never got a response from them, so my IP6 efforts were thwarted for the weekend.

This weekend I did a Google search and found Go6 on Wikipedia's List of IPv6 Tunnel Brokers. Within about 10 minutes I had done all of the steps above. Four computers on my network (the Linux server, 2 Mac laptops and 1 Eee PC running Ubuntu) got world-routable IPv6 addresses without any configuration changes or even a reboot.

"Great," I thought, "now I can access my home computers directly without having to set up tunneling each time to get through our NAT/router." But, IPv6 addresses are a pain to remember. So I headed over to No-ip.com, my preferred dynamic DNS provider, to add a few hosts to my account. Only to find that it doesn't support IPv6 AAAA records.

Ok, a bit of googling for "IPv6 dynamic dns", and I find www.dns6.org, which has a promising name. Except that its page never loads. I'm about to blow it off when a thought strikes me.... "Surely they wouldn't..."

I check Firefox's "about:config" panel and search for ipv6. Aha, it's got an option: "network.dns.disableIPv6". I double-click to toggle its value to "true", disabling IPv6 name resolution, and reload the page. And it works.

That's right -- dns6.org's server has an IPv6 record, which web browsers will try to honor, but its web server doesn't actually RESPOND on that address.

I double check by re-enabling IPv6 in Firefox and visiting http://ipv6.google.com/. Sure enough, there's the Google home page with the animated logo letting you know you've got the ipv6 version.

But it gets better -- later in the evening I'm searching for neat IPv6 sites to test. Google links me to a page on sixxs.net only it doesn't load. It's got the same problem -- its HTTP server doesn't seem to want to serve pages over IPv6. I can ping the address. I can even connect to port 80. But requesting a page just hangs.

This reminds me of something I read about Google's IPv6 services:

We continuously conduct detailed measurements on the quality of IPv6 connectivity, and our latest results show that making Google services generally available over IPv6 at this time would lead to connection problems and increased latency for a small number of users. User experience is very important to us, and we do not want to impact users on networks that do not yet fully support IPv6. We will continue to re-evaluate the situation as the IPv6 Internet evolves.

Which sounds a bit like a chicken-and-the-egg problem. If people don't start using IPv6, how will we know that there are issues with IPv6 providers? And with crummy IPv6 service, who wants to be the first to use it? But it's good for us, right? It's the future, right?

I ended up going with FreeDNS for my dynamic AAAA record. I've still got ipv6 enabled, but if it ends up poorly impacting my web experience I may end up disabling it.

Out and About this Weekend

Was invited to go see the Brooklyn Botanical Gardens and the museum nearby. Photos/video shot with my G1. :)

Flickr "Secret" API Key?

One of the personal projects I've been thinking of working on is writing a Flickr uploader for Android. I purchased a G1 running Android so that I could develop for it, and a Flickr uploader seems easy enough to start with. Plus, I've been wanting to do just that as I take photos with my phone, so it would be handy to have.

So I head over to read up on the Flickr API and find out that I've got to register for an API key. Once registered, I find that I've got both a public and "secret" API key.

It looks like several "secure" API calls have to be signed by your secret key in order to work with Flickr.

But, what if I want to distribute this application? Does that mean I have to distribute my secret key along with it? It's not very "secret" at that point, then, is it?

It looks like the only thing you need to sign is a list of the names of arguments that you're passing to a particular API call. As a compromise, I could pre-sign all method calls that my application needs to make, and distribute only that. That's better than distributing my secret key itself, but anyone who inspects my application can still find those method signatures and use them to impersonate calls from my API key.

Is this (pre-signing all method calls) how people actually use this API?

What sort of security is this supposed to offer? It seems like an awful lot of effort for seemingly little gain.

Object Oriented Antipattern

This is an antipattern I've seen at a couple places I've worked.

Considering that I keep seeing it, I feel the need to point it out and make a note: This is not OOP. This is a convoluted function call. The names have been changed to protect the guilty.


$newObject = MyObject::createObject(array(
"someStuff" => $datas,
"morestuff" => $moreDatas,
"typo" => $lolTypes,
"theKitchenSink" => KitchenSinkFactory::getInstance()
));

$newObject->doStuff();

$results = $newObject->getResults();


If that is the entirety of the API that one is expected to use from MyObject, then, really, it's just a function call pretending to be an object.

La Malĝentila Usona Programisto

Tio kio sekvas estas traduko de "The Ugly American Programmer". Kiel usona progarmisto, mi kelfoje havas similajn pensojn. Mi tradukas ĝin esperanten nun por disdoni ĝin al aliaj esperantistoj kaj aŭdi viajn pensojn. (Kaj, verdiri, por ekzerci mian esperanton.)

La Malĝentila Usona Programisto

En la Interreto, oni povas pensi kvazaŭ la mondo estas plata. En kiu ajn lando vi loĝas, kiun ajn lingvon vi parola, vi havas la saman povon atingi la scion de la mondo kiel ĉiu alia civitano de la planedo Tero. Kaj kreskanta procento da tiu scio povas kaj devas esti atingebla en via denaska lingvo.

Sed mi kredas ke la reguloj malsamas por programistoj. Mi tiom pensas tion, ke mi demandos la nepensebla: ĉu ĉiu programisto devus kompreni la anglan?

[Vidu la originalan por vidi foto #1]

Vaste pligranda proporcio da informoj pri programado atingeblas en la angla. La plimulto da programlingvoj uzas anglajn ŝlosilvortojn. Per ajna metodo per kiu vi povas mezuri, la angla estas la "lingua franca" de programado.

Nu, rilate al kultrua lerteco kaj vojaĝado, supozi ke ĉiu devus paroli la anglan estas tute neakceptebla konduto - ekzemplo de malĝentila usonano.

[Vidu la originalan por vidi foto #2]

Sed tiuj reguloj ne aplikas al ni.

Ni ne priparolas nomralaj, ĉiutagaj homoj. Ni parolas pri programistoj. Civitanoj te la interreto. Homoi kiuj promesas aliĝon ne al lando, sed al tradukilo. "Hakeroj" havas siajn propran kulturon, sian propran kutimaĵojn kaj normojn pri lerteco. Eric RAYMOND notis ke funkcianta angla estas neceso por veraj hakeroj:

Kiel Usonano kaj denaska angla-parolanto mem, mi antaŭe hezitis sugesti ĉi tion, krom se ĝi estu konsiderata kiel ia kultura imperiismo. Sed kelkaj denaskaj parolantoj de aliaj lingvoj jam urĝis min sciigi ke la angla la angla estas la funkcianta lingvo de hakera kultruo kaj la interreto, kaj ke oni bezonos scii ĝin por funkcii en la haker-komunumo.

Antaŭe, ĉirkaŭ 1991 mi lernis ke multaj hakeroj por kiuj la angla estas dua lingvo uzas ĝin en teknikaj diskutoj eĉ kiam ili parolas la saman denaskan lingvon. Estis raportita al mi tiam, ke la angla havas pli riĉa teknika vortaro ol iu ajn alia lingvo kaj estas tial simple pli bona ilo por la tasko. Por similaj kialoj, tradukoj de teknikaj libroj skribitaj en la angla estas ofte nekontentigaj (kiam ili eĉ estas faritaj).

Linus TORVALDS, finlandano, prikomentas sian kodon per la angla (ŝajne neniam okazis al li fari alimaniere). Lia flueco kun la angla estas grava faktoro en sia povo allogi tutmondan komunumon de programistoj por Linukso. Ĝi estas ekzemplo sekvinda.

Esti denaska angla-parolanto ne garantias ke vi havas lingvo-kapablojn sufiĉe bonajn por funkcii kiel hakero. Se via skribado estas semi-lerta, negramitika, kaj plenplena je misliterumoj, multaj hakeroj (inklzive min) emos ignori vin. Dum fuŝa skribado ne ĉiam indikas fuŝa pensado, ni generale trovis la korelativecon forta -- kaj ni havas neniun uzon por fuŝaj pensantoj. Se vi ne povas skribi lerte, lernu.

Estas malfacie komuniki ĉi tiun ideon sen senti sin kiel malĝentila usonano programisto. Sed ĝi ne venas de nacieco, nek deziro domini la mondon. Ĝi estas nenion pli ol ke komunuma rimarko de bonegaj hakeroj ke resti kun la angla por teknikaj diskutoj faciligas efektivigi aferojn. Ĝi estas meritokratio de kodo, ne lingvo, kaj neniu (almenaŭ neniu kiu malfrenezas) lokaligas programlingvojn.

Mi ricevis ĉi tiun retpoŝton de Slawomir, pola programisto, antaŭ kelkaj monatoj. Li konfirmis tion kion mi ĉiam suspektikaj sekrete kredis -- sed hezitis diri:

Mi ĵus aŭskultis al epizodo #29 de la Stack Overflow podkasto, kie vi diskutas lokaligadon de programistaj iloj.

Miaopinie, ekzistas neniu kialo traduki programistajn ilojn kaj dokumentojn.

Mi konas multajn programistojn en Pollando kiu prefaras (kiel Joel menciis) ricevi anglajn dokumentojn ol la polan tradukon kaj la kialo estas ke tradukoj ne ĉiam estis fidelaj. Eĉ Microsoft programaj dokumentoj estis tradukitaj nur parte, aŭ kun eraro, do legi la originalan anglan dokumenton estis pli facila ol la angla-polan.

Se ĉiu blogas kaj programas per la angla - nia tutmonda biblioteko de volvoj kaj blogafiŝoj estas multe pli granda kaj oni havas pli bonan ŝancon trovi solvon por sia problemo.

Konscie elekti ŝanĝi de la pola al la angla rememorigias min kial mi forlasis Visual Basic por C#, tiel doloriga kiel tio estis. Ĉi tiuj lingvoj faras precize la samajn aferojn -- kaj la froto de elekti la malplimultan lingvon estis drasta. Mi trovis multan kodon kaj respondojn en C# kiam mi serĉis, kaj preskaŭ nenion en VB.NET. Mi elspezis multan tempon tradukinte kodon al en VB.NET kaj aldoninte cimojn kaj erarojn dume, kune kun nenumereblajn linvgan forkojn. Ĉi tio finfine ĉesis havi sencon al mi -- kiel ĝi farus al iu ajn bona programisto.

Advokati la adoption de la angla kiel la "de fakto" norma lingvo de programado estas simpla pragmatismo, la plej virta de ĉiuj hakerjaj trajtoj. Se tio faras min malĝentila usona programisto, tiel ĝi estu.

Bazaar

One of my favorite pieces of software is Bazaar. It's a distributed source control system in the same family as Git and Mercurial. I've had this IRC conversation a couple times in #bzr, so I thought I'd paste it for the great Google Overmind to index:

21:44 -!- dfrbn [n=adam@93.54.124.24.cm.sunflower.com] has joined #bzr
21:45 <dfrbn> are there any options for integrating netbeans with bazaar currently?
21:45 <dfrbn> (aside from writing a plugin ;)
21:51 <NfNitLoop> Last I checked (which, admittely, was a while ago), no.
21:51 <NfNitLoop> There *is* an Eclipse plugin.
21:51 <NfNitLoop> and the eclipse plugin is modularized in a way that should be mostly reusable if someone wanted to make a Netbeans plugin.
21:52 <NfNitLoop> (ie: POJOs and communicating w/ bzr via XML output)
21:52 <NfNitLoop> again, all this is a bit dated. I just use the commandline. :p
21:53 <NfNitLoop> dfrbn: are you developing on *nix by any chance?
21:53 <dfrbn> NfNitLoop, yeap, entirely
21:53 <NfNitLoop> I recently have become fond of a program called 'meld'.
21:53 <NfNitLoop> it's a visual diff analizer, but it works with svn and bzr to show you local changes in your working copy.
21:53 <NfNitLoop> and resolve conflicts.
21:54 <NfNitLoop> I find meld + command-line bzr better than any IDE plugins I've used.
21:54 <dfrbn> nice, tks for that, I'll check it out.
21:54 <NfNitLoop> hint w/ meld though, for bzr it always wants you to run it pointing at the root dir of your repo.
21:54 <NfNitLoop> which you can handly do with: meld `bzr root`
21:54 <dfrbn> right on. I do like using svn in netbeans, I find the ui very comfortable to use
21:54 <NfNitLoop> :)
21:56 <dfrbn> I'm debating on where to host a project and am leaning to mercurial just cuz of the netbeans integration. But I don't have any experience with either.
21:56 <NfNitLoop> I've been keeping an eye on mercurial...
21:57 <NfNitLoop> as an openly biased bzr groupie, here are the reasons I stick with bzr:
21:57 <NfNitLoop> 1) bzr keeps things simpler. (without actually lacking features)
21:57 <NfNitLoop> 2) bzr-svn is the best svn integration I've seen.
21:58 <NfNitLoop> 3) the bzr team has been really responsive to my questions/bug-reports/etc.
21:59 <NfNitLoop> Oh, and launchpad.net is pretty spiffy. :)
21:59 <dfrbn> So I could have my own master repo in subversion for the project (which I already do), and merge my changes into bzr and use both?
21:59 <NfNitLoop> dfrbn: Yep!
21:59 <dfrbn> agreed on launchpad :)
21:59 <NfNitLoop> you can do 'bzr branch' from a svn repo and it is a fully fledged bzr repo.
22:00 <NfNitLoop> which just happens to have enough metadata to merge back into a svn repo.
22:00 <dfrbn> interesting
22:01 <dfrbn> I like the idea of keeping my own master repo
22:01 <dfrbn> as long as it's easy to merge back and forth
22:02 <NfNitLoop> There are a couple caveats...
22:03 <NfNitLoop> SVN can't represent nonlinear history.
22:03 <NfNitLoop> so it's best to keep a bzr branch that mirrors svn, then merge (or rebase) onto that, then push that up to SVN to keep things linear.
22:03 <NfNitLoop> you wouldn't lose any data doing it another way...
22:03 <NfNitLoop> but your svn history would be...
22:04 <NfNitLoop> not what svn users expect. :)
22:04 <dfrbn> gotcha
22:04 -!- AfC is now known as AfC|cafe
22:04 <NfNitLoop> (This applies to any DSCM that interfaces with SVN)
22:05 <dfrbn> I see. the only kinda distributed one I've ever worked with was a windows email based on called code coop by relisoft. it was actually pretty cool, but that was a long time ago
22:06 <NfNitLoop> hopefully you'll find that things have improved quite a bit since then. :)
22:06 <dfrbn> :)
22:06 <NfNitLoop> the bzr wiki has a great int[r]o to different distributed workflows.
22:06 <NfNitLoop> let me find it...
22:07 <NfNitLoop> http://bazaar-vcs.org/Workflows
22:07 <NfNitLoop> heh, easy enough.

Expedia Inexpedient

Last weekend I spent a couple hours trying to book a flight and car reservation for two adults from NYC to Austin via Expedia. Their web site provided some vague error about being unable to process my request and asked that I call a customer service representative.  

I called and went through the tedious process of spelling out all of my personal information, which I had already (and much more quickly) typed into the system.   Only to be told by the CSR that she received the exact same error I had.  Gee, thanks.  

Then my friend Mike told me that JetBlue's web site will do car reservations too.   Ten minutes later I was done.  

Bon voyage, Expedia!