Notes

Caros Srs. Deputados, os meus melhores bons dias,

Para contexto do que vos quero perguntar, sugiro a leitura deste artigo: Matem o monstro.

São dois projectos de lei que andam na alma de todos os que dependem da tecnologia para viver cá em Portugal.

Se souberem de uma maneira eficaz pela qual eu possa lutar contra este absurdo, digam-me. Já estou com um desafio novo este ano, em que umas entidades públicas mudaram as regras de certificação à qual estou sujeito (para melhor acredito sinceramente, assim que os sistemas estiverem estáveis) mas a que já estamos obrigados sem que o regulamento oficial tenha sido distribuído publicamente. Dizem-nos no final do mês... Se tudo correr bem... Uma parte interessante desse regulamento novo (porque sim, o preçário já está on-line no site deles) é que podem fazer quantas fiscalizações quiserem por ano mas eu tenho de pagar algumas centenas de Euros por cada uma delas, independentemente de ser detectada qualquer infracção.

Eu queria focar-me nisso, afinal é o meu negócio, mas parece que tenho de perder tempo com esta pérola que é a PL118 (ainda não li o PL119 mas dizem-me que é do mesmo calibre), uma vez que discos é algo que preciso regularmente para manter o meu serviço no ar, serviço esse que usa apenas conteúdos produzidos pelos meus clientes, mas pronto, pagam todos o dizimo à santa SPA.

Sinceramente, digam-me o que fazer para lutar contra isto. Este ano parece que também podemos vir a ser responsáveis pela segurança social dos nossos colaboradores (são colaborações esporádicas, pontuais) se 80% do rendimento deles for feito via a minha empresa. Eu compreendo a necessidade de apanhar fugas a esses pagamentos, mas imaginem que uma das suas empresas se preocupa em obrigar todos os seus colaboradores e parceiros a passaram facturas e recibos, e se preocupa em declarar tudo o que ganha e paga. Entre essa empresa e outra que não o faz, quem é que vai apanhar com a factura da segurança social?

2012 vai ser um ano giro para nós, os nossos clientes vão ter ainda menos dinheiro para gastar, novos regulamentos oficiais mas não públicos aos quais temos de obedecer, a potencial continha da segurança social, e outros desafios que nós próprios nos atribuímos para crescer o nosso negócio. Sem dúvida muitos desafios. Mas acreditamos que ainda vai ser possível, e até temos um terceiro filho como prova de que acreditamos que pode melhorar.

O que eu não preciso é de uma lei, criada à medida da SPA, cujo modelo de negócio está a desaparecer porque as pessoas compreenderam finalmente que é idiota comprar pequenos discos brilhantes quando é mais prático obter legalmente as coisas on-line, e que decide que todos devem pagar a uma entidade privada só para o caso de alguns andarem a piratear conteúdos. Não preciso, nem tenho tempo ou dinheiro para o que querem implementar cá, mais um regime de IVA.

Por isso, digam-me: como é que se luta contra uma injustiça destas? Ou devo desistir já de investir em Portugal, e ir procurar trabalho lá fora, onde apesar de já ter 40 anos, consigo obter emprego com bom salário amanhã, com base no investimento que Portugal já fez em mim?

Posted by Pedro Melo at 12:26 PM | Permalink | Comments (view)

This morning I migrated from my old personal ejabberd XMPP server to the Hosted.IM service by Process One.

tl.dr; The migration went smoothly and I'm very happy with the service. I still have two things I need to do (SSL certificate and migrate my XEP-0114 external components), but for personal reasons I won't have the time to finish the migration until next month. So expect a small update when I finish those two.

For now, I'll just describe the service and my migration process, the good parts, the could-be-improved parts and other tidbits.

The Hosted.IM service provides a hosted XMPP service powered by a carrier-grade ejabberd XMPP server. The service was created and is maintained by Process One, the main driving force behind ejabberd development over the past years. I had the pleasure of working with Process One and Mickael in particular when we migrated the SAPO XMPP server.

The basic service is free (5 user accounts, a single domain).

The main roadblock preventing my migration was the couple of custom-made external components I wrote to interact with some web and TCP-based services that I currently host, so I needed proper XEP-0114 support. I asked Mickael for it and less than two weeks later, they delivered. The XEP-0114 support was officially announced yesterday on all non-free plans.

With this final roadblock lifted, I was ready to migrate my domain.

I've registered a new account, and added my domain, simplicidade.org. The first thing they ask you to do is to add a DNS TXT record to validate that you own the domain. I don't understand why they need this TXT records. The XMPP service requires you to add or update a couple of SRV records to point to the Hosted.IM XMPP servers. If you aren't the owner of the domain, you won't be able to update those records, so why ask for an extra DNS record? I hope they clear this process and remove this particular requirement. Or, if this is really something that they really need, add a FAQ explaining why its needed.

I also immediately updated my SRV records to point to them, using the provided examples. This turned out to be a mistake that you should avoid.

If you are migrating an existing domain, I strongly recommend that you don't update the DNS SRV records at first. You should first create the accounts on the new service, migrate the current users rosters and vcards, and only then switch the DNS records. This should be pretty obvious stuff, but I was eager to move and failed here.

The Process One support personal will accept a SQL dump of your rosters and vcards and load them up on the service at Hosted.IM. I was lucky because I was already using ejabberd with the SQL backend, so I only had to cleanup old accounts, dump the SQL database and send them the file.

This data migration process is unfortunately not documented yet. New users don't even know the possibility exists. I had to ask for it on Twitter to discover the possibility. I also don't know what other formats or other servers export files they support. So check with support before you decide to switch to figure out how you'll migrate the roster information.

As I said, I didn't prepare that part, so I had to scramble to dump the rosters and send them the SQL, so that my users didn't end up with a empty roster. Fortunately the support staff was awesome and I quickly had my SQL dump loaded onto the service.

After this was done, I closed the firewall for my old server C2S ports, and started up my XMPP client. I connected without any problems to the new service.

From start to finish, and even with all the discovery and learning the layout of the administration interface, it took me less than 2 hours to have my service migrated. Pretty good.

I then selected the cheapest plan, at €8/month. The payment system is not clearly explained at the site. It works as a prepaid system: you load your account with €nnn and they remove the amount you owe every month. You also get some bonuses if you load your account with large amounts. After spending 10 minutes wondering where the payment interface was (after you change plans, the interface appears in the account section; while on the free plan, it's not visible - this is suboptimal, a link in the Plans & Pricing tab, or near the costs values in the domain administration tab would be more helpful), I loaded my account with €100 and I got a €8 bonus.

Some services cost extra. For example, using your own SSL certificate is a €2/month, and connectivity to other IM networks costs €4/month. Unfortunately, these extra costs are not described in the service homepage. You have to register for the trial account, and then check the Plans and pricing tab inside your domain management admin page.

Aside: on the service homepage, if you select Plans & Pricing in the navigation toolbar at the top, the javascript scrolls down to the #pricing section but fails to update the page location, which makes sharing the direct link harder.

And this is were we stand right now: accounts, rosters and vcards were migrated successfully, and I was able to load my account with enough money to last me for a bit less than a year (I was not counting on the extra €2/month for the certificate).

The next step is creating my own certificate. This part of the process could be improved a lot. For technical reasons, you have to upload the certificate private key. But if that is a requirement (and it is, I understand that part pretty well), then they could save a lot of work to their clients if they just took care of all that: add the option to generate the key on their servers, and send me the Certificate Request file so that I can request a certificate from a CA that supports XMPP certificates (which are slightly different from HTTPS certificates, they require an extra extension). It would be helpful if they recommended a couple of CAs providing the service, but they do not.

In the past, the XMPP Software Foundation provided a free service of XMPP Certificates, but it was shutdown sometime ago. According to their page above, you can buy a XMPP certificate from StartSSL CA, but I'm still figuring out how to do this. It should be straightforward, the same process as a HTTPS server, and I'll update this article after I've successfully done it, but the StartSSL site lacks XMPP-specific information.

After I have that part done, I'll move my external components. Some of them are sub-domains of my main simplicidade.org domain and those should be straightforward.

Others use a completely different domain name. This is an unusual setup. I basically used my own ejabberd server as a XMPP router for some domains. I connected those domains as external components, and pointed the S2S DNS records to the ejabberd server.

The Hosted.IM does not yet support this mode of operation, but I again asked Mickael about it, and this unorthodox configuration should be supported very soon. Awesome.

All in all, a pretty smooth ride.

Posted by Pedro Melo at 12:30 AM | Permalink | Comments (view)

Designing a good API is an art form, unfortunately. I've seen some efforts to graduate this process to science or engineering level, but nothing even close to accepted by a majority or programmers so far.

One particular problem I face from time to time is related to helpful APIs. Those tend to help the programmer complete its task by adding common fallback processing paths. It usually goes something like this: the API designer convinces himself that X this is the most common operation, so when user doesn't do it, we do it for them. The programmers have less to write because the API will do the right thing™.

My problem with those APIs is that they tend to fail silently. The program keeps on going, using the default processing path, and eventually the programmer lack of decision will bite him with an exception or a core dump (pick your poison).

I tend to prefer non-helpful APIs: if the programmer should make a decision, force him to do so and die as soon as possible if he doesn't, compile time if you have that concept and if you can make it happen then.

The decision the programmer needs to make could even be to do the default processing path, but he must make one.

It is a little bit more code to write, but it pays of enormously in long-term readability by eliminating the hidden default behavior. Every action is explicit, so a new programmer looking at the code (eg. you, the same one who wrote it the first time, only 6 months later) will need less background information to understand it.

So help you API users. Die often, die early, be explicit and stop helping lazy programmers.

Posted by Pedro Melo at 12:00 PM | Permalink | Comments (view)

Since the Isaacson's Steve Jobs biography was released, a lot of articles were written about this one single passage on the topic of TVs: "I finally cracked it."

From that, an explosive number of articles sprang up about Apple doing a integrated TV set, a smart(er) TV. The term disruption has been in almost all of those articles. I'm sure everybody would love to see what Steve Jobs and his team would come up on that space. I have to wonder though, if this was not the last grand-master chess player move against his competitors.

Wouldn't it be very Jobsian to send all of Apple competitors in one last great wild goose chase?

To explain my rationale (and tackle that overused "disruption" term), let me start with a question: please point me to a recent (lets say since 2000) disruption that took hold of a market (and not just a figure of imagination of pageview-whoring tech pundit), that was not accompanied by, or based on, an explosive growth of that market? I'll wait.

You see, I could not remember of any. I'm sure there are some, and I'm hoping that someone will point them out to me, but I though about this for a day and I could not remember a single one.

The last two great disruptions, smart phones and tablets, are still seeing close to 100% growth rates. Maybe Square is sitting on one, with their gorgeous simple payment interface, but they are US-only for now, and they still use VISA and MasterCard, so I don't think they even qualify as disruptive, given that they are not defying the incumbent.

But back to the disruption thing. I don't think it is possible to be disruptive on the TV space.

First, you don't have explosive growth on TV set sales. And without explosive growth, the incumbent has time to adjust to the changes introduced by the contender.

Second, the TV space is filled with big players, with huge financial interests at stake. They form a interlinked web, that is much stronger than any of them standing alone. Apple may have (had?) an influence on Disney, but those are just one single player.

Another example: look back to this 18-week periond in the spring in the USA, with the NFL labour dispute. The entire sport is supported with over one billion dollars TV revenues. I don't know about you but I would be weary of telling 32 times 50 players, each one showing about 2 square meters of hardened muscle, that their business got disrupted (apologies to all NFL players that might be reading this and take it the wrong way, I'm a big fan, and watch your games regularly; I'm sure most of you are cuddly, and friendly to kids and animals).

Third, the fact that the current TV sets are passive. It allows TV programmers to play with the ratings and follow a hit TV show with a less popular one in the hope that the audience is too lazy to change channels (Nielsen tells us, yes, they are...). And this helps them push more ads. The entire business and operation is hoping that the user turns the box on and leaves the remote alone, dozing over average (at best) quality content while you wait for your hit show.

So no, I think disruptive is asking too much. I believe subversive is the best the internet technocracy can expect in the near future.

They will slowly take over functions that current contenders in the same space are doing. For example, the AppleTV with AirPlay, could take over casual gaming from the Wii. Both Google's and Apple's offers, specially teaming up with Netflix, will slowly kill the DVD/BluRay player and the cable operator pay-per-view services, not because they are better at providing movies and TV shows on the TV set (at best they slightly better, and only because the cable operators have been slow to or bad at reacting to the threat; technically the operators are better placed to provide that service), but because they can integrate better and faster with other methods of consumption, from tablets to smart phones to the Web.

And that is what the current TV add-ons boxes (like Google's and Apple's current offerings) are already doing, starting with the basics, moving into games, and soon small apps controlled via smart phones or tablets (and solving the user interface problem in the process).

Given all this, we can allow a different interpretation on Steve Jobs quote: maybe he hasn't cracked the problem, maybe he just finally understood the size of it, and that it would take a long time and effort to slowly chip away at the wall.

And maybe, just maybe, with that final hurrah, he could just send his competitors into a all out race against that same big strong wall.

Posted by Pedro Melo at 09:29 AM | Permalink | Comments (view)

Microsoft and Intel need to stop ruining good looking hardware...

Posted by Pedro Melo at 10:22 AM | Permalink | Comments (view)

Recently Google announced they will redirect their logged in users to the HTTPS version of their search engine.

(skip the rambling, take me to the summary: tl;dr)

I think nobody can dispute that this is a good thing. HTTPS will provide an almost (if only Certification Authorities (CA) weren't so prone to hacks...) perfect assurance that you were indeed talking to the correct server. HTTPS with CAs is a solution to man-in-the-middle attacks.

We can only hope that this redirect will eventually become the default behavior, because regular and non-authenticated users will still be using the plain HTTP search, and need to specifically ask for the https://www.google.com/ secure site to be safer. But given Google's goal of securing personalized search results I think is acceptable to limit this to logged in users only for now, given that they are the ones with access to the personalized search results. Mind you that this might also be a way for Google to load test their HTTPS setup.

But starting on the third paragraph things take a turn into a new reality: Google will no longer provide the query information to the site you click on the organic search results page. There is no direct explanation on that article why they will start (or stop) doing this.

Before going on further, lets make one thing clear: there is no technical limitation that prevents Google to forward the individual query. In fact this is working right now. When you use the HTTPS version of Google Search, the URLs are rewritten in a way that they go through a Google jump, and from that they are redirected to the final page. But this Google jump page is hosted on a plain HTTP site so the final redirect to your page includes this as the Referrer, with the full query information. Google could just keep using this scheme to provide sites with the information they want.

What they do tell you is that if you click on a ad from the results page, the query information does get sent to the destination site.

This might seem as a double standard of behavior, but sites that appear on organic search results and sites that appear because they payed Google are clearly two different populations and so they can have different treatments from Google if Google chooses to do so. After all, when I pay to get my site on the search result page, I have a right to get all the information about why my ad was shown there. I payed for that right.

It seems we sometimes forget that Google is a company, and as all companies, the goal is to make a profit selling goods. The goods Google sells are your searches. The fact that Google has become so large and useful as to be considered indispensable, and that some small changes in its behavior can make or destroy entire business models, is something that we should be aware, and if possible try to fight against. Its never good to have so much power in the hands of a private company, be it Google, Apple, Microsoft or Facebook. If Microsoft was investigated in the 90's, I will not be surprised to see the same happen to Google in the next decade.

The point is: Google is deliberately choosing, as is their right to do so, to stop sending valuable information to outsiders for free. And I think this will move them closer to a investigation by some governments.

One of the business models that is threatened by this change is the land of search engine optimization. As we can expect, they are livid, and react accordingly. There is this particular article that caught my attention: Google Puts A Price On Privacy.

The premise of the article is that with this change, Google will only share is search data if you pay them.

Well, duh...

Google is a company, a for-profit company, of course it wants to get payed.

The second paragraph is even better:

Google’s a big company that goes after revenue in a variety of ways some critics feel put users second.

(emphasis mine). Now this is laughable. There are two different types of people that classify as users:

• users of the search engine that use it to find stuff: we get a free (and great) service, and in exchange we get to see some ads - I think these are the real users of the service;
• users of the ad system: they pay to show ads of their products on the search result pages - I call these customers of the service.

But no matter which group of users you pick, the change Google announced is good for them.

As users of the service, we get a little bit of extra privacy from third parties: strangers on WiFi networks, governments with intent to control their citizens civil rights, you name it, it gets better.

For customers of the service, they get more value from their payments because now they will have exclusive access to valuable information.

So who are those users who loose? I think they are two other groups, and only one of them really looses a lot. The first is all of us who have a site and were used to receive the search query information. Some of us used it for actual useful features on our site, others would only see them via the analytics system they were using. So we loose a little. We can still get to part of the analytics information via Google Webmaster Tool if we want for some reason optimize our search ranking, but not adjust in real-time to our users queries.

People who make money re-selling the search queries that leaked from Google Search are the really big losers, though. They would use the search queries to target ads on their own sites. And it was a good business.

And I believe the article was written by someone in the second group, or someone who writes for the second group.

The claims are all interesting:

• "[Google is ] perfectly happy to sell out privacy": not news, the moment ads started showing up on Google Search results, we knew they were selling our privacy - we are the product. Besides, explain why someone who makes a living on the search keywords that leak via the referrer is not violating our privacy also?
• "...blocking is a pesky side effect to a real privacy enhancement Google made": no, blocking is not a side effect. Today you can search on HTTPS Google search site and still get the information on your non-HTTPS site. Blocking is a deliberate decision by Google, don't blame technology about this one;
• "Google could have pushed many sites across the web to become more secure themselves": this is based on the logic that if all sites were HTTPS then the referrer information would still flow to the sites. Google is actively trying to change people over to SSL-based communications, to the point that they designed a protocol that requires it (SPDY) and bundled that protocol into their own browser. I don't see how you can accuse Google of not doing plenty for the improvement of the security on the web. Even this change is a clear prod in that direction - as the author notes, if you want to keep receiving the data, switch to HTTPS;
• "Google could have [...] its default search [redirected] to be secure. [...] using Google’s own figures, [logged in users filter will ] protect less than 10% of Google.com searchers": true, but I believe that this is an engineering decision - lets try with 10%, and if all goes well, switch everybody over.

I guess that if my business was based on referrer information I would be pissed today, and even I don't depend on them, I really do hope that Google keeps sending those lovely q's query parameters in the referrers.

But most of this article facts and complaints are at best self-serving, if not just plain wrong.

My biggest doubt is the SPDY angle. If you use a recent version of Chrome, your access to Google is done using SPDY, which includes TLS security by default. So even if you just type www.google.com you are using a secured version of the search engine, but still the following click will be plain old HTTP with the full referrer information. Will they change this too? What are the rules for a SPDY to HTTP transition? Should they be the same as a HTTPS to HTTP transition?

Bottom line: I appreciate the default redirect to HTTPS, and I agree that Google has a right to provide a better service to paying customers. But I don't believe they will be able to sustain this policy of not forwarding search keywords. Not only its petty, it might also trigger a government investigation on the subject, something that I think they would not want.

Posted by Pedro Melo at 12:02 PM | Permalink | Comments (view)

Godspeed Steve.

(image from Ars Technica article about the life of Steve Jobs)

I leave you with my all-time favorite ad. When I learned of this and whenever I think of his impact on our lives, I think of this ad.

Posted by Pedro Melo at 08:09 AM | Permalink | Comments (view)

In a recent blog post, Dion Almaer talks about AirPlay and how he can see it as a big part of almost every application you use today. I like AirPlay. In fact, I'm might end up buying a Apple TV just to have an AirPlay- enabled big TV.

I've read about games on the iPad/iPhone using AirPlay to use the HDTV as a display device, and it is a wonderful idea: you sit down with one of your favorite games in front of the big screen, flip a switch on your phone and now you can use the entire screen as a controller. Kind of like a Wii U, I guess.

But there is another scenario I like even better. Let me tell you the story of the "iPad for the kids" here at home.

A couple of months back, when the iPad2 was first announced, we decided not to buy any portable game consoles anymore. The games on those might be better, but the economics are wrong: you pay less for the console, but after the 4th or 5th game, you are already into iPad2 price points.

On the other hand, if you get an iPad2, you can have games between €0.79 and €5 a pop, even without counting the enormous amount of free games. So we bought an iPad2 for the kids and created an account with an allowance on the App Store. Entertainment problem solved. And as a bonus feature, we can load great education apps like Mathboard or Algebra Touch too.

So we have the iPad, mainly for games, and AirPlay (as soon as the Apple TV arrives) to make use of the HDTV. But I'm skeptical about real-time games via AirPlay. I very much doubt that the delay will go unnoticed.

Fortunately there is a better option, one that also might promote the Apple TV from a hobby to another billion dollar business for Apple.

You see, the new Apple TV is powered by an ARM processor and iOS, exactly the same combo the other iOS devices use.

If you could download the games over the air from your iPad/iPhone, they would run on the Apple TV, using the HDTV as display, and use your iOS portable device as a remote control, then your Apple TV becomes a games console too, with no display delay at all.

It would not be powerful as a XBox, PS3, or a Wii, but it would not matter: it would have a killer price point, and you could start a game on the iPad, arrive at home, keep playing on the HDTV, and switch back to the iPad later.

Now that would be awesome.

Posted by Pedro Melo at 07:32 AM | Permalink | Comments (view)

A couple weeks back I noticed someone on Twitter having problems cloning git repos from GitHub using HTTPS. I didn't pay attention to it because I usually use git: protocol - nothing against HTTP, just habit.

But today, on a Mac OS X 10.5.8 system, I noticed something similar:

$ curl -LO http://xrl.us/cpanm
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   185  100   185    0     0    301      0 --:--:-- --:--:-- --:--:--   301
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). The default
 bundle is named curl-ca-bundle.crt; you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Now, you can work around it quickly if you add --insecure to that command line, but that feels dirty.

I checked on my other Mac, running 10.6.6, and I had no problems. The curl version in Leopard is just too old, and lacks some of the new certification authorities:

### 10.5.8
$ curl --version 
curl 7.16.4 (i386-apple-darwin9.0) libcurl/7.16.4 OpenSSL/0.9.7l zlib/1.2.3

### 10.6.6
$ curl --version 
curl 7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3

If you check curl SSL certs documentation you'll see that, yes 7.16 is very old and until 7.18.0, the bundled CA file is "severely outdated".

The solution is to update the bundled CA file. First we need to find it and curl-config --ca is your friend:

$ curl-config --ca
/usr/share/curl/curl-ca-bundle.crt

I though "I'll just copy the file from 10.6.6..." and be done with it, but no such file is present on my Snow Leopard. I assume that curl uses the system keychain in 10.6, but I don't know for sure.

So we do it the hard way. I'm just interested on accessing GitHub without problems so I checked the CA GitHub uses and downloaded the CA chain from them: you'll need both the "DigiCert High Assurance EV Root CA" and the "DigiCert High Assurance EV CA-1".

Put those file in a directory, open a terminal to it and type:

cat /usr/share/curl/curl-ca-bundle.crt \
    DigiCertHighAssuranceEVRootCA.crt \
    DigiCertHighAssunceEVCA-1.crt \
    >> curl-ca-bundle-new.crt

To test this new CA bundle you can use:

curl --cacert curl-ca-bundle-new.crt -LO http://xrl.us/cpanm

and the download should work perfectly.

To make this change more permanent you can replace the original curl-ca-bundle-new.crt with this commands:

sudo cp /usr/share/curl/curl-ca-bundle.crt /usr/share/curl/curl-ca-bundle.crt-backup
sudo cp curl-ca-bundle-new.crt /usr/share/curl/curl-ca-bundle.crt
sudo chmod 644 /usr/share/curl/curl-ca-bundle.crt
sudo chown root:wheel /usr/share/curl/curl-ca-bundle.crt

And that's it! All your HTTPS downloads from GitHub should now be CA errors free, including clones using https:// URLs.

Although I had this problem on a Mac, the solution should work as well with other operating systems, as soon as you find the location of the curl-ca-bundle.crt file.

Posted by Pedro Melo at 11:25 PM | Permalink | Comments (view)

When I was younger, at college, I decided that I was to enjoy and do all the wrong but good things in life, without great care about stuff like me weight. Everybody healthy has a lot of time ahead of him, so you can postpone all the "eat right", and "exercise regularly" advise people throughs at you.

My answer was always "I'll do that when I turn 40".

Well, I turned 40 today.

I suppose now I should do all that, but last December I noticed that I had put a lot of extra weight. I was always a 72/75kg person, but since my surgery I had gained an extra 10kg, and was dancing around the 82kg mark.

Lets just say I was not happy... So, given that my deadline was coming up, I decided to start early. January 1st I had 82 and I wanted to reach 40 at 70kg.

I started eating better (no fast food, no soft drinks, less bread, more soup and fruit) and more often (4 snacks, two in the morning, two in the afternoon). I made my membership at the gym something more than a cost, and started going 3 times a week for a mix of cardio and weight training. And, and this is probably the best thing I ever did, I started running.

I used one of those 5K programs, that promise you to be running 5km in 9 weeks. At first I did that at the gym. If I had problems at least I was not alone in the street. Then on March 7, I did my first 5km run outside and became addicted to RunKeeper. You can follow my improvements on my profile page, but right now I'm running 10k in 1:10:00/1:15:00 3 to 4 times a week.

And I feel great.

The result of all this can be seen here, courtesy of my Withings body scale:

I didn't hit 70kg, I'm exactly at 71kg today. I blame a couple of weeks in late April where I was stuck in the 72kg mark because I tripped and hurt a knee, and couldn't run, but I'm on the right path and I'm sure before the month is over I'll be clearly in the 70's.

So, after loosing 11kg (going on 12) how do I feel? Great. I have more energy and stamina and that shows where its most important: with my two kids (third on the way by the way, expect delivery late December).

Hitting 40 is sort of a mark on everybody's life. I can honestly say that I don't feel different than yesterday, but I'm also certain that I'm much better physically than I've been for a long long time.

So, have a great day. I know I will.

Posted by Pedro Melo at 06:26 AM | Permalink | Comments (view)

The message announcing the kibosh on all third-party collaboration with the Twitter platform triggered several bop-ed's. You can find a nice summary over at Michael Tsai's place.

Twitter will live on as a mainstream platform, used by countless millions of regular every-day non-technical users for which these new rules are meaningless. They will suffer and question why their previous favorite client no longer works, while downloaded the latest official Twitter abortion of an interface. They will complain about it (their $Deity given Internet right), but will move on, and keep on using it.

But those of us more technically-able will probably look for a new partner, while we lick the stab wounds inflicted but our former mistress.

As always, when something wrong happens to a centralized system, the geek-gene arouses and looks for the greener pastures of decentralization. "Would it be good to have a Twitter without the central service?"

Apart of the love/hate relationship with centralized systems, of which the current cloud-fad is one mighty engine, I have to say that the only word who comes to mind about all this is dejavú

Almost-optimal solutions for this problem exist for decades. The first one I remember is good old multicast. Assuming unlimited address space, assign each person his own multicast group and let the routers take care of it. Its unpractical of course, but the architecture of any solution that emerges will have a lot of common points with this old codger.

But more recently some systems tried to tackle the problem. My pet favorite, XMPP, is one of them. We have per-user publish/subscribe that can be used to implement such a system. And we have a large network of XMPP servers already.

But XMPP has two drawbacks. The first is that the explosion of a message to all his subscribers is done at the source server. This means that when the Bieber opens his mouth and bleats, his own server would have to send his pantomime individually to all members of his flock. So even if a thousand of them were on the Google Talk network, instead of a single message, the Google servers would receive a thousand messages. I would be remiss if I didn't mention that there is a deferred extension to tackle this problem, but few in the community showed interest on it.

The second drawback is more perception than technical: over the years I felt that people don't see XMPP as Webby enough. Its a strange, dark technology, that few understand, and the passion for it by those who do, makes those who don't stagger.

But the pretty solution of a multicast network to deliver information, even in the XMPP approximation of a network of centralized servers, where each one acts as a aggregator for a part of the community, providing distinct local services for local people, has one glaring drawback: there is no privacy.

If I delegate one instance of my message to a Google aggregator that serves their clients, I can only hope that they will do the right thing and deliver said message to the right people.

If this requirement is soft for public messages, it becomes very strong for protected streams. If you want some assurances that your protected tweets don't end up in the wrong place (and I set aside the discussion about what kind of guarantees we have about that from Twitter itself in its quest to monetize your content) then you can't use this remote-server-side explosion but have to go back to exploding your messages individually to each of your approved subscribers.

There is an extra cost on resources for this kind of privacy.

So if you want to try and tackle the distributed Twitter problem, please remember that it is one of the most discussed architectures in our Internet history. It has been done before (or at least tried) several times, some with success, others less so. It doesn't matter if the next real-time micro-blogging tool will be based on Usenet, SMTP, RSS, XMPP, or the latest fad-du-jour. The basic problems are the same ones our fore- fathers tried to solve with multi-cast.

As I said, dejavú.

post scriptum rant, or why I need to support <aside> on my CSS: But is a decentralized system with some central aggregation nodes based on trusts workable? History has something to reminds us again: the usenet was the elite messaging tool amongst geeks in the early 90's (oh how I miss thee, trn). Then the AOL horde invaded and it became mainstream. The geek clan left, and later the usenet collapsed with spam, and now is a strange BitTorrent look-a-like.

The clan moved over to blogs and RSS. And those too were colonized, although not as thoroughly because that RSS thing is still a bit on the complicated side.

So the social networks were born, to hide all those pesky RSS feeds, add a dash of real-time, and place a pretty face on top of all of it.

So: do all decentralized systems evolve into spammer havens or centralized silos by sheer force of capitalism? A topic for another day.

Posted by Pedro Melo at 09:47 AM | Permalink | Comments (view)

The keys 'hjkl' have a special meaning for a lot of UNIX users. They are used to move around inside the vi text editor, and have been used by loads of websites as keyboard shortcuts to move around inside a page. One of sites I visit often that I uses them is The Big Picture of the Boston Globe. Inside each article, you can navigate between photos using 'j' and 'k'. Try it.

The source of this convention started with Bill Joy, the creator of vi. The reason for this particular set of keys is because Bill Joy used a ADM-3A terminal, and the keyboard has cursor arrows printed on those keys.

You can see a big picture of the ADM-3A on Wikipedia. Zoom in on the keyboard to see the arrows.

Nothing like a bit of geek archeology...

Posted by Pedro Melo at 12:31 PM | Permalink | Comments (view)

Good answer from Google, given the limitations they have on software version updates and older hardware.

This topic of Android fragmentation always triggers a StarWars-based scene: Ogly Wan Genoobly sitting calmly inside his speeder, waves a hand at an iTropper: "These are not the the fragmented droids you are looking for".

Posted by Pedro Melo at 10:33 AM | Permalink | Comments (view)

For the past 2 or 3 years, my favorite web server is nginx. It replaced lighttpd on most of my production sites, and soon it will take over them all.

One of the roles nginx is performing is to act as a frontend server for Perl-based Web apps. This apps run under Starman or one of the other PSGI-compatible servers.

The simplest configuration block you need to use is this:

server {
    server_name my.site.com;

    location / {
        proxy_pass http://127.0.0.1:9999/;
    }
}

This will proxy the request to your Web app running at 127.0.0.1, port 9999.

The problem is that the Host HTTP header is rewritten to 127.0.0.1. In fact, the header is rewritten to whatever value you use as the host in the URL given to the proxy_pass directive.

With a bit of /etc/hosts manipulation you can use stuff like:

proxy_pass http://my_web_app.production:9999/;

But this makes the deployment process more complex because you need to keep /etc/hosts in sync with all your apps.

A cleaner alternative is to force the original Host header to be sent to the backend server, like this:

server {
    server_name my.site.com;

    location / {
        proxy_pass http://127.0.0.1:9999/;
        proxy_set_header Host $http_host;
    }
}

With this configuration, the backend server will receive whatever Host HTTP header your browser sent that matched this server block, which is particularly useful if you use a regular expression to match host names.

Or if you have multiple server_name's but want your backend to receive a fixed host name, use:

proxy_set_header Host "my.forced.hostname";

Either way, its much simpler to keep frontend and backend servers in sync, with regard to virtual host names.

Posted by Pedro Melo at 05:27 PM | Permalink | Comments (view)

In the casual games category, I have to pick the harbor simulation games, like Harbor Master or Harbor 3D, as my favorite genre.

They are the ones I always get back too, and their place on the iPhone is clearly assured.

Here are some tips to help you play them:

• use the speed multiplier from the start. Always play at the top speed: you can grow your score quickly, and when you eventually get into trouble, you can slow down the pace a bit to solve the problem;
• try to use the same path for ships of the same speed, like a train;
• Harbor 3D lets you can anchor a ship by tapping it. Harbor Master doesn't. In the latter you can create a circle in front of the terminal and keep a bunch of ships there, doing laps. This is the same as the planes do while they wait to land on busy airports, they keep descending in circles.
• Harbor 3D ports are very wide, so aim each ship to a different part of the port: you can get 2 or even 3 ships to dock at the same time;
• unless a new ship is very near another when he shows up, wait until you see the indication of the next ship before moving it. When you direct a ship to his destination, your hand covers most of the screen, and you'll miss the notification. You would then need to quickly determine where he is. If you wait to see that before directing the new ship, you know were you must move too immediately after. You might even decide on a different port based on the side of the screen the next ship will arrive.

Any tips for me?

Posted by Pedro Melo at 11:44 AM | Permalink | Comments (view)