Programador Anónimo

Como não reagir a más exposições

noreply@blogger.com (libre) — Thu, 22 Jan 2009 14:09:00 +0000

Um caso mediático recente:
Durante a semana passada acompanhei um caso caricato passado num canal de TV do EUA, creio que um canal estatal, em que uma estudante comprou acidentalmente um computador Dell com o Ubuntu para frequentar as aulas à distância. Ela queixava-se que o CD do seu ISP não instalava nem conseguia instalar o msoffice, alegadamente requisitos para aceder ao sistema de e-learning da instituição o que a levou a desistir de um semestre.

As reportagens do canal:

Reportagem original (em texto, com possibilidade de vídeo)
Reportagem em resposta à reacção da comunidade (em texto e vídeo)

Em relação à reportagem tenho a salientar um ponto:
Tenho a certeza que não tinham qualquer intenção de atacar o Ubuntu. A sua intenção era a típica de um meio de informação baseado no sensacionalismo e populismo, atacar uma empresa, a Dell, por esta se recusar a resolver o problema, como se resolvesse o problema. Não vou estar aqui a contar a história toda, pois podem vê-la nos links acima.
Como é óbvio, e infelizmente, a reacção de muita gente foi negativa e mesmo destrutiva. Ataques ao canal e à estudante em questão, que neste caso chegaram mesmo a ser atitudes graves e reprováveis, como ofensas e ameaças pessoais. E como é óbvio o canal aproveitou a situação para vender mais da sua "peixeirada".

Pontos a ter em conta:

Relativamente à estudante:

Como conseguiu ela comprar aquele portátil? É mais fácil encontrar a página onde eles estão à venda a partir de um motor de busca que pela página principal do site da Dell. E pesquisar por "laptop Dell" não aparecem resultados relativos ao Ubuntu nas primeiras páginas;
Não tinha qualquer conhecimento sobre o Ubuntu ou OpenOffice.org;
Estava focada em instalar o software de ligação à Internet e o msoffice e acreditava que não era possível frequentar o curso sem isso;
Procurou trocar o computador por um com bloatware xp/vista ou obter uma licença deste através da Dell;
Tendo obtido resposta negativa, pois aparentemente o prazo para troca já tinha expirado, apresentou o seu caso ao canal de TV em causa;
Aparentemente não procurou qualquer tipo de ajuda após o contacto com a Dell;
Recebeu montes de ataques e acusações de ignorância, estupidez, etc...

Estamos perante um típico caso de pessoa que vive na total ignorância em relação ao mundo alternativo ao horrível mundo microsoft, mas será razão para atacá-la? Não me parece.

Relativamente ao programa de TV:

Típico programa do espectador acusa, nós fazemos a reportagem;
Apostou no ataque à Dell, tendo apanhado o Ubuntu no fogo cruzado;
Alegaram estar a fazer tudo para ajudar a estudante, mas não em relação ao que a estudante tinha em mãos, e temos que ter em conta que o poderiam fazer, mas isso venderia a notícia? Nunca;
Juntamente com a estudante receberam montes de ataques;
Lançaram um contra ataque, na minha opinião muito destrutivo.

Um formato de programas que todos conhecemos certamente, eu não sou totalmente contra este tipo de programas. Mas temos que ter em conta que o objectivo principal deles é "vender publicidade" ao maior número de espectadores possíveis. Alegam querer ajudar, e neste caso teriam conseguido de uma forma fácil, mas tal não beneficiaria os seus objectivos. Razões para a Comunidade de SL/OS estar chateada? Sem dúvida, mas lembrem-se que ao atacar um canal de TV poderá ter um efeito idêntico ao de tentar lutar de espada e escudo contra um tanque de guerra.

A atitude da comunidade Ubuntu/GNU/Linux

Podemos dividir as reacções em duas partes: as positivas e as negativas.

Às positivas foi dada pouca atenção na segunda reportagem, mas felizmente existiram referências. Muita gente se ofereceu apara ajudar a estudante e para lhe dizer que era possível usar o portátil como estava e até lhe mostrar os pontos favoráveis.

As negativas foram mais que muitas, e o canal não exitou em usar essa atitude negativa no seu programa. Se a situação estava má, aí é que piorou. Quem assistia ao programa e não conhecia o mundo alternativo ao império de Redmond ficou com uma impressão extremamente negativa em relação a todos nós. E aqui não podemos culpar exclusivamente o canal, podemos criticar o seu formato de programa, mas atacá-lo desta forma pode correr mal. E garantidamente causou estragos.

Atitudes a ter em conta neste tipo de casos

A principal atitude a ter em conta é a de nunca atacar utilizadores de informática que desconhecem o mundo do software livre, estarão simplesmente a afastá-los, ou pior ainda, a torná-los defensores do lado oposto. A melhor atitude será certamente a de oferecer ajuda, aconselhar e incentivar as pessoas a mudarem. Mas repito, ao atacá-las estarão simplesmente a perdê-las.

Outra atitude a ter em conta é a de como lidar com meios mediáticos, criticar defensores do software fechado ou comentar em blogues pró-ms é uma coisa, meter-se com meios mediáticos de comunicação é outra. Mas em ambos os casos é melhor nunca tomar uma atitude negativa, não quer dizer que não possam atacar com fundamentos válidos, mas sim nunca cair no desagradável. Com meios mediáticos o melhor a fazer é fundamentar bem o vosso ponto de vista sem nunca entrar no desagradável, lembrem-se que o seu poder mediático pode ser destrutivo. Usem os argumentos a favor, que já são mais que suficientes.

Lembrem-se que ser troll não é um exclusivo dos nossos adversários, e que no nosso meio também podem existir, muitas vezes dando uma má imagem de todos nós. Existem formas de jogar ao ataque contra os nossos adversários sem por em causa a nossa credibilidade, e nesses casos o meu conselho é: Aproveitem-nas, mas repito, sem ataques pessoais ou insultos gratuitos.

Emrelação a este caso as coisas não acabaram tão mal quanto isso. Aparentemente a estudante está a frequentar o curso e com o seu Ubuntu. Já sabe como utilizar o OpenOffice.org para criar documentos que podem ser lidos pelo pessoal do curso e obviamente já se liga à Internet do seu próprio portátil. Podem ver essa informação no blogue pessoal de um dos membros desse canal, aqui. Dá-nos essa informação positiva, apesar de manterem a posição da sua reportagem.

A grande mudança: Python 3000 lançado.

noreply@blogger.com (libre) — Thu, 04 Dec 2008 14:26:00 +0000

Foi anunciado hoje o lançamento oficial da versão 3.0 da popular linguagem de script Python, também conhecida por Python 3000.
A lista de novidades é bastante significativa e, com este lançamento, existe uma quebra de compatibilidade com as versões anteriores. Pelo que qualquer código escrito para Python 2.x ou mesmo 1.x poderá ter que ser re-escrito.

As principais novidades:

print passa a ser uma função: print()
As funções map(), filter(), range() e zip() assim como os métodos dict.keys(), dict.items() e dict.values() passa a retornar iteradores em vez de listas. No caso da função range() o comportamento é similar ao xrange() da versão 2.x que desaparece nesta versão. A função list(iterator) poderá ser usada para retornar uma lista através de um iterador, mas caso não seja necessário deve ser evitado de modo a salvaguardar o uso de memória.
As strings passam a ser todas Unicode.
Os inteiros são automáticamento de tipo Long.
O operador diferença <> for removido e substituido pelo operador !=
Desaparece a função reduce(function, iterable), devendo recorrer-se a implementações iterativas em sua substituição.
etc...

Na nota de lançamento oficial podem ser consultadas todas as modificações mais detalhadamente.

Esta linguagem é de extrema importância e este lançamento terá algum impacto pois entre utilizadores dela estão o Google, a NASA, é parte fulcral em muitas funcionalidades de distribuições GNU/Linux, como o Ubuntu Red Hat/Fedora, etc... Existem também muitas aplicações web desenvolvidas em Python e a linguagem é usada para criar scripts em muitos videojogos, pelo que o seu conhecimento poderá ser útil para o desenvolvimento de Mods. Há mesmo quem defenda que é uma alternetiva viável ao shell script para a criação de utilitários de administração de sistemas, pois esta é independente da shell que se usa.

Para quem não conhece é realmente uma linguagem a aprender.

"Porque detesto a Microsoft?"

noreply@blogger.com (libre) — Thu, 13 Nov 2008 05:00:00 +0000

Estas palavras não são propriamente minhas, mas sim de um cibernauta holandês, que publicou um site no ano passado e que recentemente descobri. E dado o teor, extensão e argumentação deste documento decidi que merece ser divulgado.

Ao ler fico com a sensação que podemos dividir a microsoft em duas categorias.
A primeira é a de uma empresa pouco inovadora, que pouco trás de novo. Basicamente pega na criação dos concorrentes e obtem sucesso com isso. E mesmo naquilo que fazem a qualidade é questionável. Mas no que diz respeito à inovação, pouca existe. Desde o primeiro sucesso em larga escala, o MS-DOS que foi comprado a uma empresa "amiga", até ao primeiro windows, tentativa de copiar o Xerox Alto e combater outra cópia do mesmo chamada MacOS, etc...
A outra categoria é a realmente assustadora. Como pode uma empresa com a descrição acima sobreviver num mundo tão competitivo? Primeiro tiveram a sorte do seu lado, saiu-lhes o euromilhões dos contractos de software, com o contracto da IBM para estes desenvolverem um sistema operativo, que basicamente foi comprado e sofreu umas modificações técnicas, para a sua linha de computadores pessoais. A partir daí conseguiram pôr-se numa posição de poder, e consequentemente segui-se uma série de politicas ferozes de aniquilação de concorrência. Passar acima de tudo e todos, custe o que custar. Numa atitude que faz muito lembrar os métodos que podemos ver retratados em filmes como O Padrinho ou em séries como Os Sopranos. Eliminar a concorrência a todo o custo.

Deixo aqui o site para quem quiser ler: (em inglês)
http://www.vanwensveen.nl/rants/microsoft/IhateMS.html

Acredito em grande parte do que está descrito nesse site. Basicamente é uma espécie de compilação de muitas notícias e factos Históricos que quem está atento à indústria TI já deve conhecer. Mas acho que também é uma prova de que uma abordagem livre e aberta ao desenvolvimento de software é a melhor forma de enfrentar este monopólio. Simplesmente o software livre tem um grau de imunidade a tácitas de aniquilação que o software proprietário não terá numa situação similar. Por esse facto também a ms aposta forte nas patentes de software, estas sim podem constituir uma arma poderosa contra toda a concorrência. Sob o pretexto de inovação registam patentes muitas vezes ridículas: duplo click, page up/page down, etc...

Não quero com isto apelar ao ódio, mas sim apelar a uma abertura de mentes.
Uma boa leitura, a todos os que a decidirem fazer.

Tutorial MVC - 4 Inserir dados, Formulários e Validação

noreply@blogger.com (libre) — Wed, 12 Nov 2008 23:09:00 +0000

Este tutorial é um seguimento directo do anterior. Utilizaremos os mesmos componentes e tabela de dados para criar um sistema de registo de utilizadores. Se não tem acompanhado esta série aconselho-lhe a dar uma olhadela ao tutorial anterior.
No que diz respeito à validação, será usado o novo sistema form_validation introduzido na versão 1.7.0. Dado que este tutorial é orientado para iniciantes não vi razão pela qual não o orientar para a nova versão.

Em qualquer página web com validação de dados existe o seguinte ciclo de validação:

Pedir os dados ao utilizador
Verificar os dados
Caso os dados não sejam válidos exibir erros e voltar ao ponto 1
Tratar os dados

Começando pela solicitação de dados, vamos criar uma view user/register.php com o seguinte conteúdo:

<?php echo validation_errors() ?>

<?php echo form_open('user/register') ?>
<fieldset>
<label for="username">Utilizador: </label>
<input type="text" id="username" value="" />
<label for="password">Palavra-Passe:</label>
<input type="password" id="password" value="" />
<label for="confirm">Confirmar:</label>
<input type="password" id="confirm" value="" />
<label for="email">E-mail</label>
<input type="text" id="email" value="" />
</fieldset>
<input type="submit" value="Enviar" />
</form>

A view acima é um formulário típico em PHP/HTML. Na primeira linha serão imprimidas as mensagens de erro caso a validação dos dados falhe. Recorre-se também à função form_tag para gerar uma tag form que chamará o controlador responsável por validar e armazenar os dados.

Agora para armazenar os dados resta-nos criar o controlador para o efeito. Mas antes disso vamos preparar a nossa classe modelo para guardar este tipo de dados. Lembre-se que estamos a criar um formulário para registo de utilizadores e dados sensíveis como a password não serão armazenados no formato em que são inseridos. A palavra passe será transformada antes de ser armazenada recorrendo à função de hashing sha1 utilizando uma chave salt para impedir a obtenção da palavra passe através de dicionários com hashs conhecidos. Ao modelo user_model.php serão acrescentados os seguintes métodos:

<?php
private function hashPassword($password)
{
//gera uma string salt aleatória
$data['salt'] = sha1(rand());
//gera o hashing da password
$data['password'] = sha1($data['salt'].$password);
return $data;

}

function register()
{
$data['username'] = $this->input->post('username');
$hash = $this->hashPassword($this->input->post('passwd'));
$data['passwd'] = $hash['password'];
$data['salt'] = $hash['salt'];
$data['email'] = $this->input->post('email');

$this->db->insert('users', $data);
}
?>

O método register guarda os dados, depois de codificar a password. Usando o método insert do Active Record a inserção de dados não poderia ser mais simples, basta um array associativo em que o indice corresponde ao nome do campo na tabela e depois passá-lo como argumento da função insert. Para obter os dados enviados pelo formulário podem usar o método $this->input->post('nome') ou aceder directamente ao respectivo elemento no array post: $_POST['nome'].

O método hashPassword é responsável apenas por gerar um hash e um salt para a password.

Por fim no controlador user vamos criar um método register que, neste exemplo, será responsável por criar as regras e executar o ciclo de validação.

<?php

function register()
{
//definição da lista de regras a aplicar
$config=array(
array(
  'field'   => 'username',
  'label'   => 'Nome de Utilizador',
  'rules'   => 'required|min_length[4]|max_length[20]'
),
array(
  'field' => 'passwd',
  'label' => 'Palavra Passe',
  'rules' => 'required|min_length[6]|matches[confirm]'
),
array(
  'field' => 'confirm',
  'label' => 'Confirmação de Palavra Passe',
  'rules' => 'required'
),
array(
  'field' => 'email',
  'label' => 'E-mail',
  'rules' => 'required|valid_email'
)
);

//atribui a lista de regras à próxima execução da validação
$this->form_validation->set_rules($config);
//Teste de validação de dados
if(($this->form_validation->run())==FALSE)
{
//caso a validação não tenha tido sucesso
//ou ainda não foi invocada
$this->load->view('user/register');
}
else
{
//se a validação teve sucesso
$this->user_model->register();
//redirecciona para uma página de sucesso
redirect('user/success');
}
}

?>

Neste exemplo recorremos ao método de criar um array com todas as regras de validação a aplicar. Nesse array cada elemento possui três campos:

field: possui o nome do campo a avaliar, deverá obrigatoriamente corresponder ao id do elemento do formulário que fornecerá esses dados.
label: contém uma identificação do campo, compreensível pelos utilizadores, a aparecer na mensagem de erro.
rules: aqui são declaradas as regras a ser aplicadas ao campo, as mais comuns são: required, campo obrigatório; min_length/max_length, definem os limites de tamanho em caracteres dos dados inseridos; valid_email, endereço de correio electrónico válido; etc...

A estrutura if no exemplo garante a execução do ciclo de validação. Na primeira chamada ao controlador, invocada pelo utilizador, a validação falha sempre sem qualquer erro, por isso é exibida a view com o formulário. O utilizador ao enviar os dados faz com que o controlador seja de novo invocado e a validação executada. Se falhar será re-exibido o formulário com as respectivas mensagens de erro. Caso os dados estejam correctamente inseridos, estes serão guardados na base de dados. Após o armazenamento o controlador redirecciona-nos para uma página de sucesso que não foi listada neste exemplo, dada a sua simplicidade deixo-a ao critério de cada um.

Código fonte do Android disponível

noreply@blogger.com (libre) — Tue, 21 Oct 2008 15:28:00 +0000

Foi hoje liberado o código fonte da plataforma móvel Android do Google.
Foi criado também o site http://source.android.com onde se pode obter o código fonte e acompanhar tarefas de desenvolvimento, correcções ou mesmo participar com colaborações próprias. A licença é a Apache2.0, mas certas partes do código podem ser fornecida noutras licenças, como a GPLv2 no kernel Linux.

É sem dúvida uma excelente noticia para o mundo do software livre e parece que sempre teremos um peso pesado para lutar contra a apple e a microsoft.

Para obter o código fonte, basta seguir as instruções disponibilizadas aqui.

Outro pormenor curioso é o facto de não estar disponível nenhuma forma de obter o código para a plataforma windows!!!

Tutorial MVC - 3 Acesso a dados

noreply@blogger.com (libre) — Thu, 16 Oct 2008 16:11:00 +0000

Depois de termos dado uma visão global ao padrão MVC e de dar os primeiros passos com a framework CodeIgniter vamos abordar uma parte também importante de uma aplicação web: o acesso a bases de dados.

Criação da base de dados e configurar o acesso

Ao contrário de algumas frameworks, p.e.: Symfony, Django, etc... o CodeIgniter não possui nenhum mecanismo próprio para criação de bases de dados, à semelhança do que acontece no Ruby on Rails e CakePHP, pelo que esta terá que ser criada com as ferramentas fornecidas pelo seu SGBD. O CodeIgniter segue um padrão de acesso a dados conhecido como Active Record que será demonstrado mais à frente. Para este capítulo apenas iremos utilizar a seguinte tabela utilizando o MySQL:

CREATE TABLE `users` (
`id` int(11) NOT NULL auto_increment,
`username` varchar(20) character set latin1 NOT NULL,
`passwd` varchar(40) character set latin1 NOT NULL,
`salt` varchar(40) character set latin1 NOT NULL,
`email` varchar(100) character set latin1 NOT NULL,
PRIMARY KEY  (`id`)
);

Agora vamos configurar o acesso à base de dados no CodeIgniter, dentro do directório application/config editem o ficheiro database.php:

$active_group = "default";
$active_record = TRUE;

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "o_meu_nick";
$db['default']['password'] = "a_minha_pass";
$db['default']['database'] = "nome_da_bd";
$db['default']['dbdriver'] = "mysql";
$db['default']['dbprefix'] = "";
$db['default']['pconnect'] = TRUE;
$db['default']['db_debug'] = TRUE;
$db['default']['cache_on'] = FALSE;
$db['default']['cachedir'] = "";
$db['default']['char_set'] = "utf8";
$db['default']['dbcollat'] = "utf8_general_ci";

O ficheiro em sí não tem muito que saber, basta alterar o valor de cada elemento com os dados respectivos. Para seguir este tutorial será necessário ter a variável $active_record a TRUE. O passo seguinte será configurar o acesso à classe de base de dados. Isto pode ser feito de dois modos: activar o carregamento automático da classe ou carregá-la no construtor de cada Controller ou Model:

//---Carregamento "Manual"---
//em cada controlador ou modelo invocar
//$this->load->database()
class User extends Controller
{
  //em PHP4: function Nome()
  function __construct()
  {
   parent::Controller();
    $this->load->database();
  }
}

//---Carregamento automático
//para carregamento automático editar config/autoload.php
//e adicionar 'database' ao array $autoload['libraries']
$autoload['libraries'] = array('database');

Para verificar se a conexão à base de dados está a funcionar basta correr o seu browser e abrir o url da sua aplicação. Se não foi informado de algum erro, então está tudo a funcionar.

Nota: A escolha de utilização de carregamento automático ou não classes está dependente do tipo de projecto. Se for uma classe utilizada por todos os controladores recomenda-se o carregamento automático de modo a poupar algum esforço. Se essa classe apenas for utilizada por algumas funcionalidades então recomendo que se faça o carregamento apenas quando necessárias para evitar sobrecarregar os controladores com material desnecessário.

Ler registos da base de dados

A exibição de dados é certamente a tarefa mais comum em aplicações web. Para demonstrar como realizar este tipo de tarefas vamos criar duas actividades num controlador User em controllers/user.php:

user/all
user/show/$id

Para testar este exemplo recomendo que introduzam alguns dados na tabela users.

<?php
class User extends Controller
{
  function __construct()
  {
   parent::Controller();
    $this->load->helper('url');
  }

  function all()
  {
    //selecciona todos os registos de users
    $data['list']=$this->db->get('users');
    //envia a lista de dados para a view
    $this->load->view('user/all',$data);
  }

  function show()
  {
    //vai buscar o id ao url, 3º elemento
    //se não for escrito retorna 0
    $username = $this->uri->segment(3,0);

    if($username == 0)
    {
     //se o id não foi fornecido redireciona
     redirect('user/all');
    }
    else
    {
     $result = $this->db->get_where(
       'users',
       array('username' => $username));
     //selecciona a única linha do resultado
     $data['user'] = $result->row();
     $this->load->view('user/show',$data);
    }
  }
}
?>

E agora as duas user/all e user/show:

user/all:

<h1>Lista de utilizadores</h1>

<table>
<tr>
<th>Username</th>
<th>Email</th>
<th></th>
</tr>

<?php foreach($list->result() as $user): ?>
<tr>
<td><?php echo $user->username ?></td>
<td><?php echo $user->email ?></td>
<td><?php echo anchor('user/show/'.$user->username);?></td>
</tr>
<?php endforeach ?>
</table>

user/show:

Username: <?php echo $user->username ?>
E-mail: <?php echo $user->email ?>

Os metodos mais importantes para este exempo são:

$this->db->get('tabela'): Devolve todos os dados da tabela (SELECT * FROM tabela)
$this->db->get_where('tabela', critérios): selecciona todos os registo que correspondam a um critério.

Os registos devolvidos são armazenados numa estrutura em memória da qual se pode extrair cada um deles como instância de um objecto Active Record, como neste exemplo, ou alternativamente num array associativo.
Neste exemplo foram usados dois métodos: result() e row(). O método result, usado na view user/all gera uma lista de objectos row, cada um deles representa um registo. O método row extrai directamente uma linha, o que é muito útil para casos como este em que a consulta à base de dados devolve uma única linha, caso devolva mais que uma linha o método row devolverá apenas a primeira linha.

Neste exemplo utilizamos o helper url, este fornece, entre outras, a função anchor que nos permite criar hyperlinks de forma dinâmica para outras funcionalidades da nossa aplicação. No exemlo acima podemos ver que esta é utilizada para criar ligações para a página show de cada registo.

Outra função a destacar que utilizamos é a função uri->segment que extrai elementos da nossa url, neste caso o username. O segundo parâmetro é opcional e indica o valor por omissão caso se invoque esa funcionalidade sem fornecer o username.

Modelos

Como foi explicado no primeiro tutorial, no padrão MVC o Model é responsável pela abstracção do acesso a dados. O que se passa no CodeIgniter é que o padrão Active Record já faz isso de uma forma mais geral. Pelo que é possível criar um projecto sem ter que implementar classes modelo, mas para casos mais especificos como consultas mais complexas é recomendado implementar essas funções numa classe Model.

Podemos reestruturar o exemplo anterior tendo em conta os seguintes aspectos:

Estamos a pedir à tabela todos os campos de um registo quando apenas utilizamos dois deles
Podemos criar métodos para obter os dados prontos a ser exibidos, encurtando o tamanho dos nossos controladores

Para isso vamos criar uma classe user_model.php no directório models:

<?php
class User_model extends Model
{
  function getDisplayableByUsername($username)
  {
    //indica os campos
    $this->db->select('username, email');
    $result = $this->db->get_where(
     'users',
     array('username' => $username));
    return $result->row();
  }

  function getAllDisplayable()
  {
    $this->db->select('username, email');
    $result = $this->db->get('users');
    return $result->result();
  }
}

Neste exemplo criamos duas funções que retornam os resultados apenas com os dados que desejamos exibir. O método select da classe db encarrega-se de definir os campos a retornar pela próxima consulta à base de dados.
Agora falta-nos alterar o controlador para utilizar o model.

<?php
class User extends Controller
{
  function __construct()
  {
    parent::Controller();
    $this->load->helper('url');
    $this->load->model('user_model');
  }

  function all()
  {
    //selecciona todos os registos de users
    //a ser exibidos
    $data['list'] =
    $this->user_model->getAllDisplayable();
    $this->load->view('user/all',$data);
  }

  function show()
  {
    //vai buscar o id ao url, 3º elemento
    //se não for escrito retorna 0
    $username = $this->uri->segment(3,0);

    if($username == 0)
    {
     redirect('user/all');
    }
    else
    {
     $data['user'] =
     $this->user_model->GetDisplayableByUsername($username);
     $this->load->view('user/show',$data);
    }
  }
}
?>

Para completar, como o método GetAllDisplayable já retorna uma lista result devemos ir ao código da view user/all e remover a chamada ao método result() no ciclo foreach para que tudo funcione devidamente.

Este capítulo fica por aqui, no próximo serão abordados os temas de adição e edição de registos, assim como a validação dos dados introduzidos pelos utilizadores.
Até à próxima.

Tutorial MVC - 2 CodeIgniter, Primeiros Passos

noreply@blogger.com (libre) — Mon, 13 Oct 2008 16:19:00 +0000

Primeiros passos
Para utilizar esta framework basta qualquer servidor HTTP com suporte a PHP. É extremamente provável que a aplicação que deseja desenvolver necessite de uma base de dados, estão disponíveis os motores livres PostgreSQL, MySQL e SQLite juntamente com outros proprietários.

O primeiro passo é a instalação da framework. Nada mais simples.

Fazer o download da framework aqui.
Descomprimir o ficheiro.
E copiar o conteúdo o conteúdo do directório CodeIgniter_x.x.xx para o seu directório web.

Nota: Evite desenvolver a partir do seu servidor de alojamento. Se desejar trabalhar num ambiente semelhante a um ambiente real, será boa ideia recorrer a máquinas virtuais.

Depois no web browser abrir: http://localhost/index.php, se tudo correu bem então está pronto a começar a trabalhar.

Como ambiente de desenvolvimento recomendo a IDE Eclipse com o plugin PHP Edit (ou mesmo o PDT). É uma ferramenta bastante robusta, mas de fácil utilização e a de completação automática de código funciona bem com esta framework.

Podem fazer download a partir do site oficial e instalar o plugin PHP posteriormente, ou fazer o download personalizado com as funcionalidades que desejar no site yoxos.

Estrutura de directórios

A framework é constituída por um conjunto de directórios por onde estão espalhados os diversos componentes que a compõem. Ao instalar verá que existe um directório de documentação na raiz, poderá mantê-lo ou apagá-lo, poderá mantê-lo durante o desenvolvimento da aplicação, mas deverá apagá-lo quando disponibilizar a aplicação online, a não ser que queira disponibilizar essa documentação online.
Existe também um ficheiro index.php, este tem obrigatoriamente que existir pois todos os pedidos à aplicação arrancam a partir dele.
Por fim temos o directório system onde existem os seguintes directórios:

application: este será o directório onde fará o desenvolvimento da sua aplicação. Em condições normais será o único a sofrer alterações durante o desenvolvimento.
cache: a cache do sistema, onde são criados ficheiros temporários que permitem o aumento da performance da aplicação.
codeigniter: o "motor" da framework.
database: controladores de base de dados.
fonts: tipos de letra.
helpers: colecções de funções de auxilio ao desenvolvimento que, por exemplo, poderão ajudar a criar elementos de uma página de uma forma mais simples.
language: ficheiros com termos usados pela framework numa determinada língua. Instalação do Português padrão.
library: biblioteca com as classes de referência que podem ser utilizadas no desenvolvimento da aplicação.
logs: logs de sistema
plugins: similar aos helpers, só que em vez de uma colecção de funções os plugins apenas disponibilizam uma função.
scaffolding: motor de scaffolding. Permite a gerar automaticamente páginas de visualização, criação, edição e eliminação de dados a partir de tabelas da base de dados. Esta ferramenta apenas deve ser utilizada durante o desenvolvimento pois não oferece qualquer garantia de segurança. Este modelo de scaffolding deixou de ser oficialmente suportado e será substituido, pelo que não deverá ser abordado para já nesta série de tutoriais.

Dentro da pasta application temos um conjunto de directórios orientado para o desenvolvimento da aplicação. Os directórios helpers, languages e libraries são equivalentes aos que encontramos na directoria system, mas neste caso destinam-se a componentes criados especificamente para o seu projecto. Os restantes directórios são os seguintes:

config: ficheiros de configuração.
controllers: local onde criará os seus controllers.
errors: páginas de erro personalizadas, como por exemplo o famoso 404-Not Found
hooks: extensões ao CodeIgniter, onde poderá criar funções ou classes que serão executadas em determinados momentos do fluxo de processamento da aplicação.
models: local onde criará os seus models.
views: local onde criará as suas views.

Olá mundo

Para variar vamos começar com a criação de um programa Olá Mundo.

A maneira mais simples de o fazer é a utilizar apenas um controlador, vá à pasta controllers e crie um ficheiro chamado primeiro.php e edite-o. Nele escreva o seguinte código:

<?php
class Primeiro extends Controller
{
  //em PHP4: function Primeiro()
  function __construct()
  {
     parent::Controller();
  }

  function index()
  {
     echo 'Olá Mundo'
  }
}
?>

Se digitar no seu web browser o endereço http://localhost/index.php/primeiro obterá uma página com o texto Olá Mundo.

O exemplo começa pela declaração de uma classe que herda as características de classe do CodeIgniter Controller, todos os controllers são subclasses de Controller, o nome da classe e do ficheiro são iguais, a única diferença é que o nome da classe deve começar sempre com maiúscula. Depois temos duas funções: a função Primeiro() é o construtor da classe, que neste caso apenas chama o construtor da sua superclasse, este pode ser usado para carregar qualquer tipo de componente do sistema; a segunda função é uma actividade do controlador, normalmente todos os controladores têm uma função index que é chamada sempre que esse controlador é invocado sem que seja invocada qualquer função.

Vamos acrescentar mais uma função ao nosso controlador:

<?php
class Primeiro extends Controller
{
  (...)

  function opiniao()
  {
    echo 'Estou a gostar muito desta ferramenta';
  }
}
?>

Esta função é similar à anterior, apenas serve para demonstrar o funcionamento dos endereços. Neste caso, para invocar esta actividade do controlador deverá digitar o endereço: http://localhost/index.php/primeiro/opiniao

A estrutura padrão dos endereços é:
...index.php/Nome do Controlador/Actividade/Informação Complementar
Caso não seja especificada nenhuma actividade será sempre executada a função index, como no primeiro exemplo, pelo que deverá existir sempre um index em cada controlador.

Views

As views são ficheiros PHP que contêm código HTML e chamadas PHP responsáveis pela apresentação dos dados. No exemplo anterior eram os controladores que apresentavam qualquer conteúdo na página, o que não é prático nem segue a norma MVC, pelo que vamos fazer algumas alterações.

Primeiro vamos acrescentar uma nova view, no directório views crie o ficheiro mensagem.php com o seguinte conteúdo:

<html>
<head>
<title><?php echo $title ?></title>
</head>

<body>
<h1><?php echo $message ?></h1>
</body>
</html>

Esta view será invocada por ambos os controladores e como podemos observar serão passadas duas variáveis: title que definirá o titulo a aparecer na janela do browser e message que terá a mensagem que aparecerá na página web.
Para utilizar a view vamos alterar ambas as acções do controlador.

<?php
class Primeiro extends Controller
{
  //em PHP4: function Primeiro()
  function __construct()
 {
    parent::Controller();
  }

  function index()
  {
    $data['title']='Primeiro Exemplo';
    $data['message']='Olá Mundo!';
    $this->load->view('mensagem',$data);
  }

  function opiniao()
  {
    $data['title']='A minha opinião';
    $data['message']='Estou a gostar muito desta ferramenta';
    $this->load->view('mensagem',$data);
  }
}
?>

Agora o funcionamento ficou ligeiramente alterado. Para passar dados a uma view é necessário criar um vector associativo em que o índice terá correspondência a uma variável com o mesmo nome na view. A última linha de cada actividade é uma chamada à view onde o primeiro parâmetro corresponde ao nome do ficheiro da view (a extensão PHP pode ser omitida), e o segundo corresponde à estrutura com os dados a ser passados. Não há qualquer obrigação de passar dados para uma view, pelo que nestes casos deverá apenas invocar a view apenas com o primeiro parâmetro.

Para uma view podem ser passados dados de qualquer tipo, sejam eles numéricos, texto, objectos ou outras estruturas de dados. O próximo exemplo demonstra como passar um vector para a view e como este normalmente é tratado.
Crie uma nova view chamada topics.php com o seguinte conteúdo:

<html>
<head>
<title>Uma lista de tópicos</title>
</head>

<body>
<ul>
<?php foreach($topics as $topic): ?>
<li><?php echo $topic ?></li>
<?php endforeach ?>
</ul>

</body>

</html>

Aqui a única diferença é que é usado um ciclo foreach para escrever cada um dos elementos na página.

Para pôr esta view a funcionar necessitamos de criar uma actividade no nosso controlador que o invoque, por isso vamos adicionar a função topics():

function topics()
{
  $data['topics'] = array('Model','View','Controller');
  $this->load->view('topics',$data);
}

Nada mais simples.

No directório views é possível criar subdirectórios para as organizar. Para invocar essas views deverá incluir o nome do directório na sua chamada:$this->load->view('directory/topics');E assim terminamos este capítulo, no próximo serão abordados o uso de bases de dados e os modelos.

Pacote de Portugês standard para CodeIgniter

noreply@blogger.com (libre) — Mon, 13 Oct 2008 12:46:00 +0000

Criei um pacote de língua portuguesa standard para o CodeIgniter 1.6.3, a partir do pacote pt-BR criado por Matheus Bombonato.

Os pacotes de línguas são constituidos por diversos termos e mensagens utilizados nas aplicações desenvolvidas com o CodeIgniter como por exemplo: mensagens de erro, nomes dos meses, dias da semana, etc...

Para o instalar faça o download e extraia-o para o directório wwwroot/system/application/languages.
Download pt-PT

Depois edite o ficheiro wwwroot/system/application/config/config.php e substitua a seguinte linha:

$config['language'] = "english";

Por esta:

$config['language'] = "pt-pt";

Tutorial MVC - 1 Introdução

noreply@blogger.com (libre) — Fri, 10 Oct 2008 00:49:00 +0000

Este tutorial tem como objectivo abordar o desenvolvimento de aplicações web seguindo uma arquitectura MVC. Será criada uma série de tutorias com uma sequência idêntica à do desenvolvimento de um projecto. Não será focada qualquer questão relativa ao webdesign a não ser que seja estritamente necessário. A ferramenta utilizada neste tutorial será a framework codeigniter por razões que serão descritas à frente.

O que é o MVC?

O MVC, Model View Controller, é um padrão de desenvolvimento de aplicações, normalmente, mas não forçosamente, web. A implementação de aplicações usando este padrão são feitas com recurso a frameworks, apesar de não ser obrigatória a utilização de uma para seguir o padrão.

Camadas e respectivas funções

Model: Nesta camada são definidas as regras de acesso e manipulação dos dados, que normalmente são armazenados em bases de dados ou ficheiros, mas nada indica que sirva só para alojamento persistente dos dados. Pode ser usado para dados em memória volátil, p.e.: memória RAM, apesar não se verificar tal utilização com muita frequência. Todas as regras relacionadas com tratamento, obtenção e validação dos dados devem ser implementados nesta camada.
View: Esta camada é responsável por gerar a forma como a resposta será apresentada, página web, formulário, relatório, etc...
Controller: É a camada responsável por responder aos pedidos por parte do utilizador. Sempre que um utilizador faz um pedido ao servidor esta camada é a primeira a ser executada.

Cadeia de Funcionamento

Esta é a cadeia normal de funcionamento deste padrão, em que todas as camadas são usadas, o que nem sempre acontece:

O utilizador efectua um pedido ao servidor
O controller processa o pedido do utilizador.
O controller efectua uma chamada ao model, para obter ou manipular dados.
O model devolve os dados pedidos que serão passados ao view.
A view gera a apresentação dos dados, p.e.: uma página HTML.

Existe a possibilidade, bastante frequente, de um pedido não precisar de invocar o model. Basta querer gerar conteúdo que não necessite de qualquer tipo de dados. Neste caso o controller chamará directamente ao view. Existe também a possibilidade de não ser gerada uma view, p.e.: o pedido ser uma actualização de dados. Apesar de não ser necessário é recomendado fazê-lo, as regras de interacção obrigam a que se notifique o utilizador do sucesso de uma operação, ou seja, a utilização de uma view.

Frameworks Existentes:

Existem diversas frameworks que cobrem inúmeras linguagens,algumas só para web e outras mais genéricas:

PHP: CodeIgniter, CakePHP, Symfony, Zend Framework,...
Ruby: Ruby on Rails, ...
Python: Django, Zope, TuboGears,...
Java: J2EE, Spring Framework, ...
Mono/.NET: Monorail, ...

Nota: Estas são as frameworks mais populares tendo em conta que são Software Livre, existem outras proprietárias, que obviamente não recomendo.

Porquê o CodeIgniter?

A resposta curta: porque simplesmente estou a utilizá-la de momento.
A resposta comprida: os critérios para o tutorial foram os mesmos que para o meu projecto. A questão da linguagem caiu obviamente para o php, quer pela sua popularidade em aplicações web, quer pelo facto de ser bastante fácil obter serviços de alojamento que o suportem. Quanto à framework já utilizei o Symfony e já brinquei com o CakePHP e estou agora a utilizar o CodeIgniter. A escolha desta frameowork recaiu sobre os seguintes critérios: é simples e com um desempenho bastante bom e a sua abordagem é bastante mais directa que o CakePHP e o Symfony. Esta última é mais complexa, apesar de não ser de todo uma desvantagem. Escolhi o CodeIgniter por ter a "melhor relação custo/qualidade".

No próximo tutorial metemos mão à obra. Até breve.

Mono 2.0 lançado

noreply@blogger.com (libre) — Tue, 07 Oct 2008 22:31:00 +0000

Foi lançada a versão 2.0 da polémica implementação do .net mono. Uma das criticas ao mono é estar sempre alguns passos atrás da implementação da microsoft, que neste caso foi bastante encurtada. As novidades são o compilador C# 3.0, compilador de VB.Net 8, Asp.net 2.0, Linq, etc... Fica também prometido que uma enorme quantidade de aplicações desenvolvidas com o ms.Net irão correr em qualquer sistema com o mono, e que a maior parte das que não correm, por usar API's especificas de sistemas windows, serão facilmente adaptáveis. Apenas uma pequena parte das aplicações é que necessitarão de modificações profundas para funcionar.
Esta lançamento deu-se na mesma semana em que a Free Software Foundation anunciou o fim do projecto dotGNU, outra implementação do .net, como projecto prioritário. Uma das razões foi a da existência do mono e de aproveitarem o facto para aplicar os recursos noutros projectos também essenciais.

O maior senão continua a ser a sombra que paira no ar na questão da possível ameaça de patentes. Apesar de baseado num standard ECMA muitas das API's podem estar "contaminadas" com "invenções" dos suspeitos do costume.

Nota de lançamento oficial

Python atinge a versão 2.6

noreply@blogger.com (libre) — Thu, 02 Oct 2008 12:27:00 +0000

Foi lançada mais uma versão de uma das mais populares linguagens de scripting existentes.
Esta versão é já uma preparação para a versão 3.0, também conhecida por 3000, mas mantendo a compatibilidade com as versões anteriores, facto que não se verificará na versão 3.0. A grande vantagem é a possibilidade de adaptação à versão 3.0, que deverá ser lançada ainda em 2008, e a de se poder escrever código que será reutilizável com a essa nova. Relembro que a versão 3.0 será uma reestruturação que será incompatível com a versão 2.x.

A destacar temos a integração de um módulo JSON na biblioteca padrão da linguagem. Isto poderá ser mais um trunfo para a sua utilização em aplicações web.
Outro grande destaque é o modulo multiporcessing. Um módulo muito semelhante ao modulo de threading que permite construir aplicações concorrentes utilizando processos em vez de threads.

Esta será certamente a última versão 2.x tendo em conta que a versão 3.0 será lançada ainda em 2008, muito provavelmente numa questão de semanas. Isto não significa a morte da versão 2.x, ainda demorará algum tempo até que o código escrito em Python 2.x seja totalmente substituido por Python 3.x.

Python 2.6

Para quem estiver interessado em exprimentar a versão 3.0 já está disponível o primeiro Release Candidate:
Python 3000

Dicas para projectos de Software Livre de sucesso

noreply@blogger.com (libre) — Mon, 29 Sep 2008 13:24:00 +0000

Criar uma aplicação de sucesso não é fácil por isso convém pensar bem antes de avançar. O objectivo deste artigo é dar umas dicas que podem garantir esse sucesso. Para quem queira entrar no mundo do Software Livre talvez seja melhor integrar-se primeiro num projecto já existente de modo a ganhar experiência. Mas se sente que tem aquela ideia que vai ter sucesso então certifique-se que ela realmente tem os requisitos para tal. A seguinte lista pretende ajudá-lo nessa tarefa:

Ser inovador: Isto é o ponto essencial em qualquer projecto de Software Livre. Criar algo que alguém queira mas não exista é o caminho para o sucesso, independentemente de se tratar de um tipo de aplicações novo ou de uma alternativa a uma ferramenta já existente. Por exemplo, apesar de existirem várias aplicações CMS e de grande qualidade não quer dizer que seja uma área fora de questão, se se oferecer algo novo é provável que se tenha sucesso.
Preencher lacunas: Este ponto é muito similar ao anterior, mas a inovação não é propriamente um requisito, pois criar uma alternativa a uma solução proprietária preenche este requisito se ser propriamente uma inovação. Ter em conta também as necessidades dos utilizadores, converter algo que ninguém quer poderá ser o caminho para o insucesso.
Partilhe o seu trabalho o mais cedo possível: Dar a conhecer o que se está a fazer no mundo do Software Livre é uma boa forma de adquirir colaboração e ajuda. Por isso é boa ideia promover o seu projecto logo que possa oferecer algumas funcionalidades básicas. Quanto mais cedo lhe der visibilidade mais depressa poderá atingir a popularidade desejada. E ao ser popular o seu projecto vai chamar de certeza colaboradores mais dotados contribuindo para um ciclo vicioso de qualidade.
Divulgue: Mesmo que não tenha possibilidades de pagar para ter anúncios não quer dizer que seja uma missão impossível publicitar a sua aplicação. Esteja atento a fóruns, blogs, salas de conversa, etc... pois podem surgir oportunidades para recomendar a sua aplicação. Se vir alguém que tenha interesse em alguma ferramenta que se enquadre com a sua aplicação não terá grandes dificuldades para o convencer. E se ele ficar satisfeito com a sua aplicação, será certamente o próximo a recomendá-la a alguém. Outra boa hipótese é a de sugerir a publicações especializadas e/ou bloggers/comunidades de referência a avaliarem a sua aplicação. Neste caso lembre-se de tirar proveito quer das criticas positivas, quer das negativas. Não deixe o seu projecto morrer por causa de uma avaliação menos boa, pois esta pode dar indicações valiosas acerca daquilo que é preciso melhorar.
Mantenha-se um passo à frente do todos: Sempre que a sua aplicação oferecer mais que as restantes terá a garantia de a sua ferramenta ser a/uma referência nessa área. É possível que alguém pegue no seu trabalho e inicie um novo ramo de desenvolvimento, fork, o que não é necessariamente mau, pois o que se aplica a si também se aplicará a ele pois só terá sucesso se criar algo de novo. Pode até ser ultrapassado, mas não que dizer que seja arrumado. Basta ver os exemplo dos CMS Mambo e Joomla, o segundo é um fork do primeiro e é talvez a maior referência actual nessa categoria de aplicações, mas apesar disso o Mambo continua de boa saúde e recomenda-se. Um fork não é uma coisa má desde que o seu projecto continue a dar frutos, antes pelo contrário, se alguém pegou nele para dar asas a um novo trabalho, é porque ele oferece garantias de qualidade.
Não reinvente, apenas invente: Tentar criar algo que já existe pode ser uma perda de tempo. Reutilize código já existente se possível, recorra a API's ou Frameworks para evitar perder tempo a repetir código ou a recriar funcionalidades já existentes. Outro conceito importantíssimo é recorrer a padrões de desenvolvimento. Ao seguir um modelo baseado em padrões fará com que potenciais colaboradores compreendam mais facilmente aquilo que está a fazer, o que facilitará a sua colaboração futura. O mesmo se passa no sentido inverso, se os seus colaboradores seguirem padrões pré-definidos e conhecidos será mais fácil para si gerir as novas colaborações ao seu projecto.
Os utilizadores são nossos amigos: Esteja sempre atento aos utilizadores da sua aplicação. Eles poderão ser uma pedra chave para a detecção de problemas e uma excelente fonte de novas ideias. Facilite ao máximo a sua participação e incentive-os a ser críticos em relação ao projecto. Lembre-se que fornecer o que eles querem é garantir que eles terão aquilo que desejam usar. Depois de obter e avaliar as ideias dos utilizadores implemente primeiro ideias de âmbito geral e pondere as ideias de carácter mais particular, pois podem pôr em causa uma utilização mais massiva da sua aplicação. Sempre que se justificar, e se tiver hipótese para tal, crie versões personalizadas, baseadas nessas ideias mais particulares. Se não puder alguém o poderá fazer, e como foi dito atrás, um fork não é nenhum pesadelo para si.
Incentive os seus colaboradores: Primeiro ponto, saber quem são os seus principais colaboradores e manter uma relação próxima com eles para garantir a fidelidade destes ao seu projecto. Se o seu projecto lhe der rendimentos monetários, não seja Tio Patinhas, partilhe parte desses rendimentos com eles, ou faculte a possibilidade de eles obterem algum rendimento também. Se tiver condições para tal, contrate-os.
Interoperar pode ser um ás de trunfo: Se a sua aplicação tiver como alvo o mundo empresarial, lembre-se que cada empresa tem o seu modo de trabalhar, por isso a sua aplicação deve ser o mais adaptável possível. Uma arquitectura orientada a serviços é sempre bem vinda. Mesmo com a vantagem de o Software Livre permitir a adaptação da aplicação às necessidades do utilizador, este processo poderá ser um bocado caro. Uma arquitectura orientada a serviços reduzirá os custos de integração da sua aplicação tornando-a mais atractiva.
Não ter medo das empresas: Existem várias empresas especializadas em soluções de Software Livre que podem ser benéficas para o seu projecto. Se estiverem interessadas em fornecer serviços recorrendo à sua aplicação então é quase garantido que estarão abertos a patrocinar o seu projecto ou mesmo a contratá-lo para desenvolver o seu projecto sob a sua alçada. Outros potenciais patrocinadores poderão ser empresas que usufruem da sua aplicação e querem garantir a continuidade do seu desenvolvimento. E se vir que compensa porque não criar uma empresa de suporte?

Nova Licença Livre para OpenGL e GLX

noreply@blogger.com (libre) — Fri, 19 Sep 2008 15:44:00 +0000

As licenças do OpenGL e do GLX, SGI Free License B e GPX Public License, foram reescritas e esses componentes essenciais para a utilização de gráficos avançados nos sistemas GNU/Linux passam a ser Software Livre. As versões anteriores dessas licenças tinham clausulas que não eram aceites pela Free Software Foundation nem pela Open Source Initiative. A nova versão é uma versão das já famosas licenças MIT e X11

Uma óptima noticia que acredito que vá impulsionar o desenvolvimento de software gráfico para sistemas operativos livres. Seria bom que para além deste passo a SGI se tornasse um aliado para ajudar a colmatar um grande problema dos sistemas GNU/Linux: a pouca quantidade de jogos disponiveis que impedem a adopção deste sistema por parte de muitos jogadores. Vamos esperar e ver.

Deixo aqui as declarações oficiais de ambas as partes envolvidas:
FSF
SGI

Código Fonte ou Binário

noreply@blogger.com (libre) — Thu, 18 Sep 2008 10:34:00 +0000

Uma das principais questões relacionadas com projectos de software livre é o seu modelo de distribuição. As possibilidades são a distribuição em código fonte, que é compilado no acto de instalação, e a distribuição em pacotes binários (deb, RMP, ...), já compilados e prontos a instalar.

Qual destes modelos é o melhor? Posso dizer que todos.

A distribuição binária é sem dúvida uma mais valia, torna rápido e acessível o processo de instalação. A instalação através de código fonte pode ser complicada ou assustadora para muitos utilizadores e o processo de instalação é mais demorado. Compilar leva o seu tempo. Outra vantagem são as dependências, a aplicação poderá necessitar de se ligar bibliotecas de funções ou utilizar outras ferramentas para funcionar, com um bom sistema de instalação binário estas são instaladas automaticamente, ou então são fáceis de identificar.

Então quais as vantagens de distribuir em código fonte?
A principal vantagem é a de ter um modelo de instalação que pode ser aplicado a qualquer distribuição do sistema operativo. Poderá ser necessário salvaguardar algumas diferenças durante o desenvolvimento, o que tem mais a ver com uma boa abordagem ao desenvolvimento que com a distribuição. Esse tipo de salvaguarda também é essencial para criar pacotes binários.

Outra vantagem do código fonte tem a ver com o tamanho da instalação, que poderá ser menor, e com a performance, que regra geral será melhorada. Mas não pensem que transformarão um camião num desportivo GT.

Por fim outra vantagem da instalação através de código fonte é a de permitir personalizar a instalação, podendo definir-se antes da compilação que funcionalidades poderão ou não ser incluídas.

Um exemplo de vantagens e desvantagens dos dois modelos de instalação é o famoso servidor web Apache. Pode-se proceder a uma instalação binária e adicionar funcionalidades, como por exemplo o PHP, através de ligação a módulos dinámicos, também eles binários, obtendo assim uma instalação fácil rápida e de fácil reconfiguração através da instalação ao remoção de módulos.
A outra opção é compilar o servidor junto com as funcionalidades pretendidas, botendo assim uma instalção monolítica e mais demorada, mas com vantagens significativas em termos de performance e segurança. Neste tipo de instalação a alteração de funcionalidades não é tão simples pois obriga a recompilar tudo de novo.

No que diz respeito a actualização de software os pacotes binários podem ser também vantajosos caso tenham sido obtidos através de repositórios online, pois ao lançar uma nova versão no repositório o sistema de actualização do sistema notificará o utilizador e permitirá uma instalação fácil e rápida dessa actualização. Mas tal já não acontece se o pacote binário for obtido por download e instalado manualmente.

No mundo de software livre a distribuição de pacotes de código fonte é "obrigatória", mesmo que se tenham criado pacotes binários para todas as distribuições possíveis. Não confundir com o acesso ao código fonte necessário para garantir as liberdades inerentes ao software livre, trata-se de fornecer o código já pronto para ser instalado com scripts de instalação, makefiles, ... preparados para o efeito. É necessário ter em conta que um utilizador pode querer personalizar a aplicação antes de a instalar, e tal só é possível com a distribuição do código. Lembre-se que essa personalização poderá ser uma mais valia futura para a sua aplicação.

Quanto às distribuições binárias, é recomendável fornecer pacotes para as principais distribuições. Existe um leque vasto de distribuições alvo, mas se o seu projecto ganhar notabilidade suficiente poderão ser os próprios criadores de uma distribuição a disponibilizar pacotes da sua aplicação para ela, ou então estes serem criados pela comunidade afecta a ela. Uma boa forma de ganahr notabilidade é a de facilitar o acesso à vossa aplicação, e ter um modelo de instalação fácil é uma excelente ajuda para o efeito. O Software Live no seu melhor.

Mono: Amigo ou Inimigo?

noreply@blogger.com (libre) — Wed, 17 Sep 2008 22:27:00 +0000

Antes de tudo o que é o mono?

O Mono é uma implementação em código aberto da plataforma .NET criada pela microsoft, daí a polémica em seu torno. Esta plataforma foi desenvolvida no final dos anos 90 como alternativa à plataforma Java da Sun Microsystems.

O mono é uma implementação de código aberto da plataforma .NET que pode ser executado em diversos sistemas: Linux, Unix, BSD, Solaris, windows e Mac OSX. O projecto foi desenvolvido pela Ximian que posteriormente foi adquirido pelo gigante Novell.

Quais as vantagens de o usar?

O Mono, essencialmente, não traz nada de muito novo, pois o que é possível fazer com ele já o era com outras ferramentas, nomeadamente o Java, mas isso não é a razão para o pôr já de parte.

A sua principal vantagem é a de oferecer a possibilidade de executar aplicações desenvolvidas em .NET para Windows noutros sistemas, ou pelo menos em teoria, visto que está dependente da implementação ou não das funcionalidades usadas por essa aplicação no Mono. A versão mais recente da plataforma .NET é a 3.5 enquanto que a versão mais recente do mono é uma implementação que se encontra entre a versão 2.0 e a 3.5 da implementação da microsoft.

Outra vantagem clara é o facto de programadores do universo windows poderem facilmente se adaptarem ao mundo *nix devido a terem uma ferramenta familiar. Outro facto a ter em conta é que esta plataforma pode facilitar o desenvolvimento de aplicações. As suas API's são bastante acessíveis e de fácil aprendizagem. E temos também a confortável vantagem de poder desenvolver aplicações com ferramentas web e desktop utilizando a mesma linguagem, de forma similar ao que acontece com o Java. Visto que o alvo do desenvolvimento de uma aplicação é uma framework e não um sistema operativo faz com que a portabilidade da aplicação para outro sistema seja extremamente simples.

Pontos Fracos

Um dos problemas principais do mono é o seu atraso em relação à implementação da microsoft o que põe a vantagem da portabilidade em causa. Outro entrave à portabilidade é o simples facto de certas APIs serem exclusivas do windows como por exemplo o directx o que anula qualquer vantagem em relação a uma aplicação nativa.

Outro ponto fraco é a falta de funcionalidades importantes na sua principal IDE, o monodevelop. Ainda lhe falta uma ferramenta de depuração integrada, coisa que pode dificultar bastante a vida aos programadores. Outra questão é a inexistência de um bom editor de HTML/ASPX, coisa que dificulta o desenvolvimento web. Ambos esses pontos estão em desenvolvimento para a próxima versão, mas a sua chegada já é um pouco tardia dada a maturidade do projecto mono.

O lado negro da força

Para quem está a ler este artigo a utilização desta ferramenta parece ser algo de bastante positivo, mas dado o título de amigo ou inimigo levanta-se a questão relacionada com os potenciais problemas desta plataforma. Uma das principais questões é a de se tratar de uma implementação de uma tecnologia da microsoft, que é tudo menos amiga do software livre/código aberto e este é um dos principais factos que leva à desconfiança por parte de muitos membros da comunidade livre.

O principal ponto contra é a possibilidade de aplicações desenvolvidas com o mono se puderem transformar em alvos das famosas ameaças de patentes já típicas da microsoft. Mesmo que não passem à acção, ficam com mais um argumento a favor num mundo que infelizmente continua a aceitar as patentes de software. Existem mesmo rumores que a microsoft anda a recolher fundos de empresas que utilizam software livre sob a ameaça de processos por violação de patentes, empresas estas que acabam por aceitar o pagamento de compensações pra evitar processos em tribunal caros e morosos. Os custos compensam, o que se torna obviamente em mais um argumento conta as patentes de software, pois as patentes foram criadas como forma de incentivar o desenvolvimento de novas tecnologias e não o seu entrave, como acontece com as patentes de software. Outras opiniões sugerem que a microsoft apoia o mono porque os projectos desenvolvidos para Linux com este podem facilmente ser adoptados pelo mundo windows.

Outros pontos relevantes são os de o projecto mono ser apadrinhado pela Novell, empresa que aceitou um "acordo de não agressão" a nível de patentes com a microsoft, o que irritou muita gente na comunidade do software livre pois é visto como uma aceitação das acusações de violações de patentes por parte da microsoft, acusações estas que nunca foram fundamentadas com provas concretas. E por fim o mentor do projecto, Miguel de Icaza. Programador que deu um grande contributo ao software livre com projectos como o Gnome, Gnumeric, ... e actualmente o mono. Muito criticado pela sua relação com a microsoft. Primeiro porque imigoru para os EUA para se candidatar a um cargo na microsoft, cargo rejeitado dada a falta de graduação académica que lhe impediu a obtenção de um visto de trabalho necessário para exercer aquele cargo. E por fim por constantes elogios a certas atitudes da microsoft, em especial o apoio dado ao polémico formato de documentos OOXML. Muitas pessoas viram esse apoio como um acto de traição. O contacto profissional que mantém com a microsoft também não ajudam nada na sua reputação.

Conclusão

O único senão na utilização do mono é a ameaça das patentes de software. Trata-se sem dúvida de uma boa ferramenta e em termos de licenciamento não há quase nada a apontar. GPLv2, LGPLv2 e MIT são licenças que não causam qualquer objecção em termos de software livre, apenas a salientar a possibilidade de licenciamento proprietário.

A possibilidade de processos de patentes existe mas acredito que seja pouco provável. As patentes de software têm um efeito dissuasor muito idêntico ao que as armas nucleares tiveram no desenrolar da guerra fria. Podem gerar um conflito em que todos poderão sair a perder. Apesar da comunidade de software livre/código aberto ser, regra geral, contra as patentes existem muitas empresas que apoiam este tipo de software que possuem vastos portefólios de patentes.
Por cá temos a vantagem de não serem permitidas patentes de software na União Europeia, mas não é uma garantia de segurança pois a ambiguidade no processo de registo de patentes e definição do que é ou não patente de software, para além de o organismo responsável pela aprovação de patentes é uma organização privada com fins lucrativos, leva a que muitas dessas patentes sejam aprovadas,
A questão resume-se em dar ou não mais um argumento à microsoft para levar a cabo as suas ameaças.

Do meu ponto de vista, a prudência é sempre boa conselheira.