« November 2009 | Main | February 2010 »

January 31, 2010

Creativity, hackers, and other stuff

Below you'll find an article that I wrote to my local Mac users group. I haven't had the time to translate it into english, so unless you are willing to learn portuguese, you'll have to wait a bit.

But for those that share my mother tongue, here it is.


(para quem leu a versão na mailing-list, tem apenas pequenas alterações de estilo, e um "Resumindo:" lá pelo meio)

A discussão que está a acontecer sobre o iPad, o efeito do modelo fechado e controlado pela Apple, e o que ele trás à criatividade e ao espirito hacker (no sentido cosquinhas, curioso, e não no sentido cracker) está mesmo muito interessante.

Acho que a questão da criatividade, que pelo que percebi começa com o post do Tim Bray que termina com a frase "For creative people, this device is nothing" é uma falsa questão.

Sinceramente, o bias natural do Tim Bray para a plataforma Android baralhou-lhe as ideias temporariamente. Basta apontar o trabalho do nosso Jorge Colombo com as capas da New Yorker como contra exemplo do seu argumento.

Mas mesmo que ele estivesse a dizer criativo como programador/developer, seria falso. Ninguém programa para o Android no próprio device. Estes devices não são computadores que possam existir no vácuo, são apêndices aos computadores que vamos ter em casa, ou no emprego.

O único contexto em que se pode ver o iPhone/iPad como limitadores de criatividade é nas politicas de aprovação da AppStore. Tudo o resto está disponível.


A parte de discussão sobre hackers é muito mais perto do meu coração. Tanto quanto pude ver começa com esta frase do Alex Payne:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today.

Apenas é possível concordar com isso se se pensar que o iPad será o nosso único computador, e claramente que não foi desenhado para isso. Mark Pilgrim parece concordar com esta visão negra do futuro dos hackers:

Once upon a time, Apple made the machines that made me who I am. I became who I am by tinkering. Now it seems they’re doing everything in their power to stop my kids from finding that sense of wonder. Apple has declared war on the tinkerers of the world.

O meu percurso (assim como de outros nesta lista, estou seguro) é semelhante ao do Mark: primeiro computador aos 11, começar a programar aos 12, 13 em BASIC e depois Assembler; começar a montar os seus próprios PCs; usar Pascal, C; usar minix, linux porque nos dava o controlo da nossa máquina; o querer saber como funciona, desmanchar, abrir, mudar. No meu caso sempre fugi um pouco da parte electrónica da coisa, não me dou com electrónica, e mais focado na parte de software low-level.

Mas respondendo à pergunta: será que o iPad vai limitar a próxima geração de hackers? Eu podia dizer que não e explicar as minhas razões, mas acho que a Gina Trapani tem uma resposta bem melhor que qq coisa que eu poderia escrever:

Because while we're all ranting about how closed the iPad will be, the jailbreak community is planning competitions to see who can crack it first. The sun isn't setting on tinkerers; their desire to crack things open intensifies when faced with something that's closed by design. The challenge is part of the appeal.

...

I'm of the mind that if someone wants to tinker, they will tinker, period. Because it's in their DNA, not because it's easy, and because by nature, tinkerers don't play by the rules.

A parte que eu posso acrescentar à discussão é esta: em 1991, na Universidade do Minho, a vasta maioria dos alunos não tinha acesso à internet. Não tinham mail, ainda não havia Web nem browsers, começava a aparecer usenet. Nesse tempo, quem andava pelos centros de informática, ou estava lá o menor tempo possível para fazer os seus trabalhos e ir embora, ou então pertencia ao grupo de pessoas que queria perceber tudo, como é que aquilo funcionava, como usar (e abusar) do sistema. Era uma "guerra" contra os administradores de sistema, porque era divertido. O que se fazia era programar, aprender e trocar conhecimento. Não havia outro sitio onde o fazer.

Durante os anos em que o acesso começou a aparecer, 92 e 93, apenas esse grupo lhe prestou atenção. Era uma fonte de conhecimento inesgotável e finalmente disponível. Despertava o nosso sentido de saber mais. Se tivesse de dar um nome a este período, seria a nossa explosão cambriana.

Esse aceso não nos transformou em colectores passivos de informação. Apenas nos deu mais energia para as próximas experiências.

Mas a partir de 94, altura em que os browsers Web começaram a ficar acessíveis às massas, começaram a aparecer uma nova tribo. Passavam horas e horas nos centro de informática a consumir informação, mas sem produzir informação. Lembro-me de discutir isto com a minha tribo e alguém (sinceramente não me lembro do nome dele) dizer "mas isto é o que se espera de pessoas normais". Sem dúvida que o nosso "hubris" tecnológico já estava presente e separava-nos das "pessoas normais" :).

Resumindo: não é possível julgar um device ou um comportamento que esse device facilita da mesma forma pela tribo dos hackers e pelo resto das pessoas normais.

A verdade é que para muitas pessoas, o que é importante não é se o sistema é aberto, às cores, hack-able, ou não. O que interessa é que com ele consigam fazer as tarefas simples do dia-a-dia sem as preocupações que apenas devem (ou deviam) existir na cabeça dos profissionais de IT.

Relembrando o artigo da Gina: ...someone wants to tinker, they will tinker, period. Because it's in their DNA, not because it's easy...

Penso em pessoas como a minha mãe, ou a minha tia, que por mais brilhantes e cultas que sejam (e claramente o são mais do que eu) não se sentem à vontade em usar um desktop clássico (Windows XP, Vista, 7, e Mac OS X) sem se baralharem.

Uma parte do artigo do Fraser Spiers:

Secretly, I suspect, we technologists quite liked the idea that Normals would be dependent on us for our technological shamanism. Those incantations that only we can perform to heal their computers, those oracular proclamations that we make over the future and the blessings we bestow on purchasing choices.

...

Those of us who patiently, day after day, explain to a child or colleague that the reason there's no Print item in the File menu is because, although the Pages document is filling the screen, Finder is actually the frontmost application and it doesn't have any windows open, understand what's happening here.

Ao olhar para os defeitos que a minha tribo atribui a esta nova plataforma, e seguindo um pouco a classificação dos mesmos que o artigo do Luke Wroblewski usa, podemos tentar vê-los do ponto de vista de uma "pessoa normal".

Quando se fala de multitasking, temos de clarificar exactamente o que queremos dizer com isso: correr várias aplicações ou partes delas ao mesmo tempo. De base, tanto o iPhone como o iPad, são um sistema multi-task, e apenas a limitação artificial da Apple em correr apenas uma aplicação ao mesmo tempo nos impede de o fazer.

Acho que é fácil de provar que a maioria das pessoas se baralha com multi-task. Basta pensar em todas as pessoas que já vimos a usar o Windows com todas as apps maximizadas, uma de cada vez. Ou de ver os problemas com o menu File > Print que o Fraser nos fala acima.

É claro que mudar rapidamente entre aplicações é importante, e essas mesmas pessoas o fazem, mas para tal não é necessário que a aplicação destino esteja a correr, desde que a ilusão criada pelo sistema operativo esteja bem feita.

Sem dúvida que várias features que a nossa tribo pensa em colocar nas suas aplicações passam por ter um processo em background a fazer qualquer coisa. Mas até as limitações actuais nas baterias estarem resolvidas, é possível argumentar que esses serviços devem ser feitos no nosso Mac/PC principal, e deixar a esse a tarefa de notificar o device que temos informação importante para ele, com a opção de enviar um link para a mesma informação que o device, transparentemente e sem a intervenção da app, obtem da rede para passar à app na próxima oportunidade.

Existem certas coisas que não são possíveis neste cenario, que normalmente envolvem informação que só o device pode ter (como o Bordalo nos diz, o Android dele adapta-se ao sitio onde está), mas até essas podem aparecer no futuro como um serviço do OS, disponível a todas as aplicações.

Quanto a não ter o plugin de Flash no Mobile Safari, já escrevi hoje sobre isso; resumindo a minha visão da coisa, era importante ter a opção de correr Flash no iPad, mas dispenso claramente de o ter dentro do browser, até porque as utilizações mais práticas que tenho para ele, estão (ou estarão) disponíveis via HTML5.

Todo o processo de aprovação da AppStore, e as barreiras à distribuição de aplicações são aspectos claramente negativos, apesar de dar origem a alguns episódios cómicos dignos de Kafka. Neste aspecto, acho que um compromisso pode surgir em que todas as apps tem de ser assinadas pela Apple (existem vantagens claras nisso), mas a distribuição pode ser via Web.

Uma coisa pouco discutida, é o facto de os i{Pad,Phone}'s não mostrarem o filesystem aos utilizadores. Segundo parece, no iPad, os ficheiros da aplicação ficam guardados numa pasta dentro da aplicação (que pode ser exportada para o Mac/PC via file sharing), de forma a que quando se remove uma App, tudo o que está associado a essa App desapareça (é giro cruzar esta funcionalidade com a alteração do Mac OS X relativamente a deixar cair o suporte a creator codes).

Cada app fica com a responsabilidade de mostrar os seus documentos, e se acham que isso é anormal, é porque não tem prestado atenção ao que o iTunes e iPhoto andam a fazer à anos: a esconder o file system com uma visão do mesmo ajustada à tarefa, ou tipo de documentos, que estão a ser manipulados.

Será que isso escala para muitos documentos? Olhando para o iTunes e iPhoto parece que sim, mas é possível argumentar que só funciona nesses casos porque apenas consumimos os documentos, não os alteramos profundamente, como numa aplicação do iWork.

É sem dúvida uma questão de volume de documentos, e faz mais uma vez lembrar que o iPad não pode ser um computador autónomo, sem o Mac/Pc para o acompanhar.

Mas olhando para as limitações como decisões conscientes de design, é importante ter uma coisa em conta: a nível de hardware, o iPad não nos limita em termos de user-inteface porque todo o seu UI é gerado por software (excepção única à ausência de camara que para mim é ainda hoje um grande mistério). Logo tudo o que nós hoje vemos como limitação, pode ser alterado, ou removido no futuro. Veja-se o que aconteceu com copy-paste nos iPhone's.


Como conclusão: para todos os efeitos, eu coloco-me claramente na tribo dos hackers. Ainda hoje continuo a abrir e fechar computadores como forma de hardware porn, principalmente máquinas antigas; ainda hoje continuo a continuar a ler e comprar livros para perceber como funcionam estes devices que nos intrigam; ainda hoje perco^Winvisto uma data de tempo todos os dias a estudar e a aprender com outros.

Por isso a minha posição sobre a politica da Apple não podia ser diferente daquela que a Gina Trapani tem:

First, know that I fundamentally agree with Alex and Mark: the closed nature of the iPad turns me off, and I wouldn't give one to my kid if I were encouraging her to learn about how computers work.

...

Even though I am critical of the iPad's closed nature and agree with Mark and Alex, I won't go as far as Alex did and say that it represents a dystopian future. I have more faith in our future tinkerers than that.

Mas a verdade é que eu não quero ser apenas hacker, e existem ocasiões em que é muito agradável desligar essa parte da minha vida para me concentrar no que está à minha volta, e nessas alturas, ter um device que me trate abaixo das minhas capacidades para o dominar, é uma trégua simpática.

Acho que a tribo está ao rubro porque este gadjet não é para eles, e isso é algo a que não estamos habituados.

Apple vs Flash

Update: Firefox also has multiple file upload since 3.6, fixed.

As expected , the iPad will not support Flash, and this brought back all the discussion that went on when the iPhone appeared. I find it interesting that Gina Trapattani is seeing a reduction on Flash-enabled browsers (and thats not counting iPhones, just regular browsers) on her sites. Also Gruber (but he is counting iPhone's) and Alex Bayo.

As a end-user I would not mind see Flash burn in hell. On a regular day, I used to have regular Safari crashes. Since I installed ClickToFlash, I don't see them anymore. Maybe it is related, maybe not, but my suspicion is that the culprit is the Flash plugin.

But there are at least two features that I use several times per day that right now require Flash: multiple file upload, and clipboard access.

The first, multiple file upload, is solved by HTML5. Its in the spec, and implemented in Safari4 and Firefox 3.6+. I think that Chrome 2 already supports this too.

Regarding copy-to-clipboard, the situation is less clear. There is a section in the HTML5 spec about copy-and-paste, but it is inside the drag and drop chapter, and I don't know how it can be used today, if at all.

So the two last remaining useful (as in work-related useful) uses of Flash will soon have HTML5-based replacements, and that means that I will not miss Flash at all.

But that is not to say that Apple is right about this. As the person who bought (or will buy) one of this Apple devices that lack Flash support, it should be my decision to enable or not a technology that for better or for worst is still widely used. I do not want a Flash plugin, but I would not mind a Flash runner app. A dedicated browser, totally written and supported by Adobe, and available for free on the App store. With that, I would have a choice to click the blue legos and see the the Web as Adobe think it should be. (shudders)

January 29, 2010

Clarifications about AnyEvent::Mojo

It seems that I need to clarify some stuff, based on Sebastian comments in my last post and via Twitter. I really hope this is the last time I have to talk about it. I rather spend my time coding.

First, you can look at the code of AnyEvent::Mojo::Server::Connection: no private Mojo APIs are being used.

They might have been with early releases, but as Sebastian says, I did work with him to improve Mojo so that I didn't have to depend on private APIs. That would be wrong.

In fact, given that I was able to write a AnyEvent-based Mojo server proves that the code was properly structured.

Second, I have no problems with changing state machines. I like state machines and expect them to change. I was eager to see Sebastian add a "pause" state, that would greatly simplify my own work regarding long-pooling. And the first break included changes in the state machine that I fixed on my side.

But the second break was caused not by the introduction of new states, but the abstraction of some code into the new Mojo::IOLoop. After the notification of no changes until 1.0.

Now, I totally accept that Sebastian needs to evolve his code base to support the new stuff he wants to support, like WebSockets. But it was nonetheless new code, and a re-factoring of all the Server interface.

I was pissed at having my code broken in that way after the "no changes" declaration, but only for a couple of days, but, and significantly more importantly, that has nothing to do with my deprecation of AnyEvent::Mojo.

I'm deprecating my module because there is a better way to do it now. I no longer need to keep this module up-to-date, I just have to work with the larger community of the PSGI/Plack, the Perl Web Server. It just makes sense to drop one-off module and switch to a system that is being reused by so many projects.

In a nutshell, I'm deprecating AnyEvent::Mojo because you have better solutions now. Solutions that I will move to and recommend to others. Solutions based on the PSGI/Plack stack, the Perl Web Server.

I am glad to see a clarification about the deprecation policy in the Changes and the http://github.com/kraih/mojo/commit/89fc6baf390d0065ad319abc540dc6a47e0bc812 for the Mojo project, I think it is a big step in the right direction; it can only give assurance to potential users of Mojolicious, and help the project.

I did learn a lot about HTTP that I hadn't pay attention before, the tiny details in the protocol. I do like Mojolicious MVC stuff, I just think that the Plack HTTP stack is better than the Mojo HTTP stack.

And I might get the cake and eat it too. I'll wait for Mojo 1.0 but it should be possible to use Mojolicious, the best part of the project, with Plack.

Anyevent::Mojo update

The current version of AnyEvent::Mojo is failing some tests. The Mojo API that I was using changed yet again and I don't have the tuits to fix it right now. I'll explain how we got here, what are the next steps, and finally I'll comment on lessons learned.

A long, long time ago...

When I wrote AE::M, I was looking for a way to do long-polling in Perl, with decent performance and cool stuff like epoll/kqueue support. At the time, the only solution might have been POE, but I have other problems with that module, so I decided I wanted a AnyEvent-based solution.

I went looking for a HTTP-stack that I could extend and found Mojo. The code was working and ready in a afternoon, and I was happy.

But then we had the famous 0.991250 release. A lot of backwards incompatible changes, and AE::M broke. I was caught at a bad time and could not update my own module for some weeks. In the Changes file, Sebastian explained why he broke backwards compatibility and that it would be the last time before 1.0; so I finally found the time and updated my code.

CPAN Testers was giving me green lights once more, and I was happy.

Until 2 months later that is, when we got the new Mojo::IOLoop code. AE::M broke again, and its broken since then. The place where I was using AE::M needed some fixes, and the work to adjust my code to the new Mojo is not as simple as it was the first time around.

So I took the dirty way out: included the last pre-Mojo::IOLoop code with my project, implemented the new features, and shipped. Not pretty. At all.

Meanwhile, in a distant planet, miyagawa was busy changing the Perl landscape with regards to HTTP integration. He wrote the PSGI spec, and the Plack toolkit. It is a wonderful piece of work, and the Perl Web Server of choice.

And after some API work, with the help of nothingmuch, it included a very decent support for asynchronous HTTP servers, including all the bits to make long-pooling work right.

Then in December, we got Mojo::Server::PSGI, native support for PSGI inside Mojo.

Next steps

Right now, I'm waiting for the next release of Mojo, and then I'll immediately release a new version of AnyEvent::Mojo, deprecating it.

With the native support for PSGI, there is no reason to maintain the AE::M interface, just use the Plack::Server::AnyEvent (or AnyEvent::HTTPD::PSGI when miyagawa finishes the cleanup he talked about).

But I will update the AE::M one last time to make it compatible with Mojo::IOLoop, as soon as I have the time. I don't want to leave it broken.

In the meantime, if you are using AE::M, I suggest that you bundle an earlier version of Mojo. I'll run a git-bisect to figure out which version is best and update this post.

Lessons learned

Not sure. On one hand, it is a version below 1.0 so we can expect some breakage.

On the other hand, the Changes file mentions that no more backwards incompatible changes would be made to Mojo before 1.0.

I still like the Mojolicious MVC framework and the dispatcher behind it, but I fear the Mojo stack and deprecation policy of the project now.

For now, all my async work is moving to Plack. I still need a asynchronous MVC framework, but I can wait a bit, or even write a very simple one if need be. Maybe steal code that I like from the others.

But I'm back to Catalyst (and I plan to talk about my feelings about the attribute-based dispatcher soon) because I feel safer. A lot safer. I know that there are other people out there that depend on Catalyst every day and in with big sites, much bigger than mine. And I trust the Cat developers not to break my code.

I do hope to see Mojo 1.0 soon, and I hope it goes well for all the gang at #mojo, but I will also look for some form of backwards compatibility policy before I even mention Mojo ever again in my presentations about Perl.

iPad

My take: what Rui said.

My analysis: I like the price, the battery life and the screen size. I would like to have a webcam for Skype, but that wasn't meant to be. Maybe next time.

I'll buy one, probably the 32G WiFi-only. It will replace my 17" Macbook for the non-work-related tasks that it does now.

I keep my iTunes, iPhoto, and other media stuff on my desktop Mac at work, and I travel around with the Macbook. Its a pain to keep these media libraries synchronized with the laptop, but its painless to do it with the iPad.

For most of my travel, I should be able to just leave the Macbook at home now.

For work related tasks, if I can get a Remote Desktop client on it, I should be able to connect back to the desktop at the office, via my IPSec VPN, and solve small problems.

Real-time web

There is a lot of stuff being written these days about real-time web. Some think that it is the next step, the next big thing.

I find the concept interesting only from a technical point-of-view. All the details about a good real-time web is what passes for tech-porn around here.

But from a human point-of-view, the concept is flawed. Or at least, my own brain finds the concept flawed.

I can't keep up with a constant barage of updates. For quite sometime, I don't have a Twitter client (I only get status updates that contain a link via RSS), I stopped using FriendFeed, and I've disabled or pushed to 8+ hours all of my checks for new mail or new articles on my feed reader. The only exception to the no-real-time updates I have is my instant messenger, and a lonely IRC client on the last virtual desktop of my system.

Not that it isn't helpful sometimes, its just not a good way to consume knowledge and information.

There are two very different concepts here: up-to-date information and real-time awareness.

I want the real-time web to succeed because it creates the necessary infrastructure to have up-to-date information in real-time, but I don't want to have the awareness of those updates shoved at me.

In an ideal future, you would have an application that sits on your mobile device, your smartphone or your tablet, that helps me manage the real-time stream. Some of my friends, Nuno and Pedro, call this application Exocortex.

Your Exocortex would subscribe to all your news feeds, your email, your Twitter/Facebook/Whatever stream. With the real-time web infrastructure in place, it would be constantly being updated with the latest information. He does not interrupt your concentration, he doesn't require your awarness; he just collects, organizes (preferably by learning what you like, and what is important to you), and indexes all. It fetches pages mentioned in the articles that you get and caches them (I find that I often click on the links but rarely follow to the second level).

Most of this happens locally on the device. It is a ecological crime not to use your local CPU. The cloud should not be CPU and storage outsourcer, but a meeting point and backup destination. Not the main point of consumption, but the backup destination. And yes, some business models would stop working.

Then, when you take your device, you get an interface into the latest trends, articles, web pages mentioned, all from the inside of your little information world, powered by your personal social network.

You can be offline and still see the latest information up to the moment you disconnected. Everything is cached locally, and if something is missing, you can pin it for later retrieval. I like to call this "close the laptop and go"-scenario. No need to sync the latest version.

So I welcome the real-time web, not because I want to be bothered every time someone farts on Twitter, but because I just want to take my iPad and go.

Contacts

melo@simplicidade.org (XMPP/email)
+351 302 029 050 (voice)
melopt (Skype)

IronMan challenge

Iron Man badge Are you ready to be an Iron Man? Join the challenge and find out! (what is the meaning of this little man?)

Moosaico

Junta-te!

Recent Comments

Powered by Disqus
Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.2