30 de dez. de 2008

Britain From Above: Motorways off the Coast

A BBC tem agora uma nova experiência não só para os britânicos mas para todo o mundo. Videos e imagens de zonas modernas e históricas do Reino Unido estão agora disponíveis e deixo-vos aqui uma delas.

No Estreito de Dover, incluído no Canal da Mancha, passam diariamente mais de 400 embarcações entre cargueiros, petroleiros ou os simples ferrys que fazem a ligação entre França e Inglaterra.

14 de fev. de 2008

CakePHP Plugins

banner.png

Motivation


This paper is intended to try to improve the next version of Cake. I think one of the most important features of a framework is its capacity to be expanded. Plugins achieve that gracefully. But there is a problem; plugins, as read on tempdocs, are meant to be packages. I think they can be much more. This is mainly a software design problem.


Where they fail


Point #1


Cake creates conventions for everything turning controllers, models and views universal. Same happens to plugins, but because of namespace concerns it is recommended to developers to include plugins name in controllers, models and views names. So a blog plugin would have BlogPost and BlogComment as models, BlogPosts and BlogComments as controllers. That's fine to me (and recommended) but the Router should be smart so it won't be necessary URI's like /blog/blogPosts.


Point #2


Second is its usefulness. I think plugins can be more than just isolated modules. Imagine a plugin that is mutable, just by receiving some variables on runtime. I think every experienced developer has come to a day where he finds himself coding same thing twice. With MVC architecture that is a problem which is 90% of the time solved, but here are exceptions.


This kind of problem appears on relative big websites. Imagine you have Users profile page, which can receive Comments. You also have the Groups page which can also receive Comments. Code can be reused by creating an element and invoking it on the view, passing the right data. That's a simple example.


But, what if Users and Groups could have Images. The Images logic would be obviously be present in the Model, but what about all the actions? Could be achieved by /images/view/type:group/23. Still ok to me. But images now have Categories, Tags and Comments. That becomes kind of hard to maintain. Developer is responsible to persist the type and id, for the operations to succeed. A good solution to this problem would be packing all has a plugin, to get all things organized, but the persistent problem would still exist.


5 de jan. de 2008

Gráficos em jQuery

Apresento o Flotr, um novo plugin para jQuery, que vai facilitar a introdução de gráficos nas suas páginas.
Ao contrário do Google Chart API, este plugin cria e manipula gráficos no momento.

Este plugin surgiu da insatisfação do autor, Ole Laursen, pois outros plugins não eram inteligentes o sufeciente. A vantagem deste plugin sobre outros é que ajusta automaticamente os limites e ajusta a escala, de acordo com os valores de entrada. Outro plugin equivalente, mas para Prototype, é o Plotr.
Esta competição entre Prototype e jQuery só traz vantagens para os utilizadores.

Grafico Barras (Flot)