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!

Evolutionary Oddity: The Anglerfish

You may be familiar with anglerfish, those fish that have weird antenna-like things growing out of their head which they use to lure prey close to their mouth.

I just heard the disturbing details of their "mating" habits. There are details on Wikipedia, but I liked the gory detail in a response I found on Yahoo Answers:

Once the male has sniffed out a female he swims up and, in a shocking bit of sadism, clamps down on her with an unshakable bite. The fish has evolved tooth-like plates in his upper and lower jaw for this purpose, and once he sinks them into a chosen female, he stays put. [...] the male anglerfish doesn’t let go. Ever again. FOR THE REST OF HIS LIFE.

[...]

Not so fast. [...] As soon as the male attaches himself to his mate, she begins to slowly absorb him (men, this part may sound familiar). Eventually, his lips grow into the skin of her side, his mouth and eyes disappear, his circulatory system ties itself to hers and he becomes a permanent appendage, dependent on her for food, protection, and a ride. He becomes little more than a reproductive organ, the sex act his only purpose.

Yikes.

A View from the Office

Mostly, I'm testing Blogger photo publishing, but it's a neat view, no?