2007-08-08 04:57:36
tags: 

O 1º Encontro B.L.S

Iniciativa maravilhosa do Beto Largman, o primeiro encontro B.L.S juntou uma galera muito boa na última segunda feira. Presentes no evento vários amigos virtuais como Nick Ellis (Digital Drops), Fábio Seixas, Carlos Cardoso, Alexandre Inagaki, Alexandre Fugita, Bernardo Bauer, Veridiana Serpa, Guga Frullani, Romullo Pontes, Cris Dias e o meu grande amigo Paulo Mussoi, coordenador dos blogs do Globo Online. Até o mestre Jorge Aragão marcou presença no evento.

Veja a cobertura no Geekchic.

2007-07-07 07:47:03
tags: 

São Paulo precisa de doações de sangue

Minha amiga de Barcamp Lúcia Freitas manda um aviso muito importante:

"Desta vez o assunto é sério. A Secretaria de Saúde avisa: a reserva de sangue nos bancos só dá conta do recado até o dia 13, próxima sexta. A razão é simples: as doações caíram, já em junho, de 7 mil para 4.200 - mais de 50%.
Segundo o release da Secretaria é o normal - faz frio, o povo doa menos. Meu convite? Vamos usar os blogs para fazer uma corrente de doação. O assunto grave é aqui em São Paulo, mas tenho certeza de que os bancos de sangue dos outros estados também ficarão gratos com todas as doações que aparecerem."

Doe. Divulgue. Ajude.

2007-07-03 04:58:16
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 17)

Para ver os artigos anteriores desta série, clique aqui.

Olá pessoal. Obrigado por todos os comentários e emails! Estou tendo um prazer enorme escrevendo essa série, e fico ainda mais feliz quando vejo que realmente tem gente curtindo.

Mas vamos ao que realmente interessa. No nosso último encontro expliquei que existem diferentes formas, ou patterns, para lidar com buscas e coleções de objetos, mas que eu ainda não estava satisfeito com aquilo que conheço. Como já disse em outras oportunidades, aprendi o pouco que sei de PHP nos becos escuros da internet, entre latões de lixo e scripts procedurais escritos por sabe-se lá quem. Não tenho, portanto, nenhuma pretensão de conhecer todos os sutras da programação orientada a objetos. Mas, outro dia, eu tive uma idéia que achei interessante, nada original, mas um pouco diferente das duas implementações que mostrei pra vocês.

Um dos design patterns mais interessantes (e, para mim, mais difíceis de entender) que conheço chama-se Iterator. Devo ter lido as definições e exemplos umas 1000 vezes sem entender direito como usar essa coisa. Pra quem vem de um passado procedural, especialmente usando uma linguagem como o PHP que lida muito bem com arrays, é muito difícil entender o benefício de usar os tais iterators.

Os iterators, juntamente com um outro pattern chamado Collection, vão formar a base do nosso novo desenho. O que estou pensando é relativamente simples: assim como temos a classe base Model, para operações com modelos, quero criar uma classe ModelCollection, que vai cuidar das operações com coleções de modelos. Dessa forma, temos um paralelo interessante: assim como podemos carregar as informações do modelo fazendo $model->load e assim por diante, poderemos carregar as informações de coleções fazendo $modelcollection->load.

O que eu gosto nesse desenho é que tudo fica claramente definido: um $model é sempre um objeto, enquanto que os $modelcollections são sempre coleções de objetos. Uma função de um $model jamais vai retornar uma coleção de objetos; uma $modelcollection jamais vai retornar um objeto (caso uma busca retorne apenas um resultado, ainda assim será uma coleção com apenas um objeto).

Parêntesis: uma das coisas que me deixa maluco no PHP é o fato de você poder misturar absolutamente tudo - uma mesma função pode retornar uma string, um array, um objeto... É o que os estudiosos chamam de loosely typed language, uma linguagem que não exige a definição dos dados usados pelas variáveis. Claro que essa característica pode ser usada para o bem: muitas implementações interessantes usam essa característica para flexibilizar e agilizar o desenvolvimento. Mas com o tempo, depois de passar anos da minha vida tentando decifrar códigos de scripts PHP por aí, eu afirmo categoricamente: tentar entender um script ou classe de alguma outra pessoa escrita em uma linguagem loosely typed é muito mais difícil.

Mas por que esse parêntesis tão grande? Porque no desenho que estou propondo vamos sempre lidar com objetos; Porque as Collections nos oferecem possibilidades muito, mas muito interessantes mesmo pra trabalhar com objetos e coleções de classes diferentes de forma transparente.

Não entendeu? Bom, vamos aos nossos exemplos então. Imagine que temos dois modelos completamente diferentes. Tipo "Post" e "Carro". Logicamente, dentro do nosso desenho, vamos ter os modelos $post e $carro, além das collections $postcollection e $carrocollection. Onde queremos chegar? Bem, como tanto a classe PostCollection quanto a classe CarroCollection são "filhas" da classe ModelCollection temos a certeza que estas subclasses implementam as mesmas funções. E por que isso é lindo? Porque eu posso agora implementar, por exemplo, a classe HtmlHelper, cuja função buildTable aceita qualquer ModelCollection e imprime uma tabela html. Pra usar, basta fazer $htmlhelper>buildTable($postcollection) ou $htmlhelper->buildTable($carrocollection).

Sacaram a beleza? Esse é só um exemplo do que podemos fazer com as collections e os iterators, mas o importante é ver que esse design faz com que qualquer coleção se comporte de forma igual, pra que a gente possa implementar coisas genéricas que funcionam pra qualquer uma delas. A coisa que imediatamente vêm à mente é que essa classe ModelCollection vai ter um método genérico pra fazer paginação, um pra fazer ordenação dos dados, e assim por diante.

Quando nossas classes estiverem prontas, olha só o que vamos precisar fazer pra imprimir uma tabela html:

(controller)

/* A função ModelController::loadPage() carrega a página indicada no $_GET['page'] e no $_GET['pagesize']

já na ordem indicada por $_GET['orderby'] e $_GET['direction'] */

$this->postcollection->loadPage();

(view)

$htmlhelper->buildTable($postcollection); // imprime a tabela

$htmlhelper->createPreviousPageLink($postcollection); //cria o link para a próxima página

$htmlhelper->createNextPageLink($postcollection); //cria o link para a próxima página

E acabou. Não é legal isso?

Até a próxima!

2007-06-20 15:11:27

Dica: codeshow em agosto

O Diego, grande chapa lá da Visie, avisa que no dia 17 de agosto vai rolar Codeshow. Nesse evento super inovador os meus amigos e criadores do Tableless vão construir uma aplicação web de cabo a rabo, detalhando cada etapa, mostrando o que realmente interessa na prática. Vale a pena conferir!

Veja os detalhes em:

http://visie.com.br/codeshow

2007-06-05 04:32:35
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 16)

Para ver os artigos anteriores desta série, clique aqui.

Olá amigos, estamos de volta. Semana de muitas emoções pra quem gosta de Tênis: Roland Garros é sempre uma festa. Este seu humilde autor confessa que, em sua tenra juventude, chegou a disputar alguns torneios; Lembro-me claramente de ganhar uma cesta com catchup, mostarda, mini-pepinos, azeitonas e mais alguns outros enlatados da empresa patrocinadora de um dos torneios de que participei. Minha melhor colocação, 3o colocado. Pensando bem, acho que fiz bem em não seguir a carreira.

Mas, deixando Jankovics, Vaidisovas, Sharapovas e Ivanovics de lado por alguns momentos, quero voltar nossa atenção novamente para os modelos do MVC. Muito bem amigos, hoje vamos tentar definir o que todos os nossos modelos devem minimamente fazer. Nosso objetivo hoje é listar os métodos da nossa classe Model, a classe base para todos os modelos que criarmos. Não tenho a pretensão de fazer um estudo teórico detalhado; dentro de nossa filosofia PHP de Rua® o que estamos buscando é somente o básico, o essencial.

Então, caros amigos, quais seriam estas funções essenciais, compartilhadas por todos os modelos que vamos criar? Lembrando nossas conversas anteriores, o modelo é um ajudante, uma classe que só existe para ler e gravar informações em nosso banco de dados, e sua estrutura de dados será sempre mapeada à estrutura de uma tabela que existe no BD.

Por exemplo, se criarmos um modelo Tenista, que possua as variáveis $id$nome$ranking, é certo que teremos uma tabela que guardará esta informação, que pra facilitar (nomes têm poder, lembrem-se disso) chamaremos de Tenistas. Essa tabela terá, minimamente, os campos id, nome e ranking. Sacou?

Estamos, de fato, mapeando uma classe à uma tabela, e instâncias da classe a registros da tabela. Essa técnica é chamada de ORM, Object-Relational Mapping. A coisa é mais interessante ainda: como estamos falando de OOP, em algum de nossos métodos vamos bolar um jeito de fazer esse mapeamento da forma mais simples e genérica possível, pra que não tenhamos que criar queries sql específicas para cada novo modelo que criamos.

Vejam a beleza dessa solução, caros leitores! Quando terminarmos a classe Model, qualquer novo objeto de uma classe que a estenda poderá ser salvo ou lido direto do banco sem precisar que nós façamos uma query específica!

Sendo assim, creio que já ficou bastante claro que precisamos das funções save() e load() em nosso modelo-base. A gente não precisa gastar muitos neurônios pra perceber que também precisamos da função delete() além da função __construct() que todos as classes já nos oferecem para criar novos objetos.

Nesse ponto começa uma saudável polêmica: onde devem ficar as funções para buscar objetos? Se eu quiser pegar todas as tenistas que estão no banco, pra quem eu devo pedir? Em alguns frameworks MVC, como o CakePHP, estas funções ficam na classe Model mesmo. Então vocë encontra funções como findAll(), findById(), findByName() e coisas assim, dentro da classe Model.

Pra ser muito sincero, eu acho meio esquisito pedir pra uma tenista buscar as outras tenistas. É assim que fica no CakePHP:

$tenista = new Tenista();

$todasastenistas = $tenista->findAll();

Cara, eu acho isso muito esquisito. A semantica da coisa, sabe? Acho que é um pouco de preciosismo, eu sei. Adoro o Cake, estou realmente impressionado com sua facilidade de uso, mas acho o design da classe model um pouco confusa.

Outros frameworks e ORMs fazem diferente. Criam uma classe só pra fazer isso. Um gnomo, lembram-se? Então, o cara faz o seguinte:

$gnomo = new DbManager();

$todasastenistas = $gnomo->findAll('tenista');

 Nesse caso, a classe DbManager tem todos os tais métodos pra retornar arrays buscados no banco. Hm. Acho um pouco melhor, mas ainda acho estranho não termos uma classe mais esperta, que possamos estender para criar comportamentos diferentes caso a gente precise. A resposta está próxima, caros amigos. Mas não posso perder a chance de continuar no próximo capítulo, não é mesmo?

Até a próxima.

2007-05-02 05:25:23
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 15)

Para ver os artigos anteriores desta série, clique aqui.

Olá meus caros. De volta. "Que você viva em tempos interessantes". Esta antiga maldição chinesa (!?) explica muito bem a sensação que toma conta deste seu humilde autor. Muito a fazer, muito a compreender, pouco tempo. Desculpas à parte, retorno à esta série para falar mais um pouco sobre Exceptions, um conceito fundamental que talvez ajude alguns de vocês a poupar um tanto desse tão precioso tempo; afinal, como bem disse Benjamin Franklin, o tempo perdido nunca mais será encontrado.

Muito bem, senhores, o que faz nossas Exceptions tão especiais? Para entender, precisamos pensar na forma como gerenciamos erros em nossas aplicações. Ou melhor, precisamos pensar na forma como lidamos com erros em nossas vidas. Talvez isso complique as coisas, mas falar sobre a vida sempre é mais interessante, não?

Joãozinho trabalha numa fábrica de automóveis. (é um exemplo, ok? Não quero entrar em discussões morais sobre trabalho infantil, capitalismo, revolução industrial, etc e tal. Tudo bem, é um exemplo estúpido. Podemos ir em frente?) Joãozinho aperta parafusos na linha de montagem, e sua supervisora é a Mariazinha. O chefe da Mariazinha é o Aristides, que fica lá em cima no escritório.

Bom, você sabe que numa fábrica todo tipo de problema pode acontecer. Alguém pode esquecer de mandar o parafuso para o Joãozinho, o parafuso que foi mandado pode estar com defeito, o próprio Joãozinho pode vacilar e não apertar o parafuso... Sabe lá o que pode acontecer. Diante desse cenário, como você faz para gerenciar todos os erros que podem acontecer? Dá uma lista de IFs infinita para o Joãozinho para que ele mesmo resolva tudo? "Se o parafuso estiver com defeito, corra até a sala do Aristides e aperte o botão para parar as máquinas". "Se você dormir no ponto e não apertar o parafuso, corra até a sala do Aristides e aperte o botão para parar as máquinas", e assim por diante? Hmm... não sei se vocês estão entendendo, mas já está dando preguiça só de pensar em fazer essa lista. E a preguiça, amigos, é o nosso sentido-aranha, é nosso superpoder psiônico que avisa quando alguma coisa está esquisita no ar. Imagina se a Mariazinha tiver 50 funcionários sob sua supervisão, vai ter gente correndo pra tudo o que é lado, a sala do Aristides vai ficar totalmente destruída, e produção que é bom nada.

Apresento-lhes, então, as Exceptions, e seus companheiros inseparáveis Try, Catch e Throw. Vamos olhar para o problema acima de um outro ângulo. Imagine se a gente pudesse dizer o seguinte pro pessoal da fábrica:

Olha, Joãozinho, você vai tentar apertar o parafuso. Qualquer problema que você tiver, escreve num papel, amassa até virar uma bola e arremessa pra Mariazinha. A Mariazinha pega a bola, e se não for um problema que ela saiba resolver, amassa de novo e arremessa pro Aristides. Se ele também não souber resolver, a gente para a linha de produção na hora.

Tentar... Pegar... Arremessar... Vocês... sacaram? (se você viu Warriors, na versão legendada, está rolando no chão de rir nesse momento). [Agora relendo esse artigo me parece claro que o criador deste conceito gostava muito de baseball, ou cricket] Se vocês ainda não sacaram, vamos escrever um pouco de (pseudo)código:

/*
* Created on 02/05/2007
*
*/

class Apertador {

    function apertarParafuso(){

        echo "parafuso apertado!";

    }

    function oopa($descricao){

        echo "Apertador: oopa! Deu pau! Segura aí supervisor!";
        throw new Exception($descricao); // amassa e joga a bolinha pra cima!

    }

}



class Supervisor{

    function mandaApertar(){

        try {

            $joaozinho = new Apertador();

            $joaozinho->apertarParafuso();

            $joaozinho->oopa("Parafuso com defeito");

        }

        catch (Exception $e){
            echo "Supervisor: xi! Exception! Não sei o que fazer! Toma aí chefe!";
            throw $e; // peguei a bolinha, mas não sei o que fazer com ela... manda pra cima!

        }

    }

}



class Chefe{

    function vamosTrabalhar(){

        try {

        $mariazinha = new Supervisor();

        $mariazinha->mandaApertar();

        } catch (Exception $e) {
            
            echo "Chefe: Para tudo! Quero saber o que aconteceu aqui!"
		echo $e;
            die("Parando as máquinas!");

        }

    }

}


// Muito bem, agora a gente contrata o Aristides:


$aristides = new Chefe();

$aristides->vamosTrabalhar();

?>

 

Rode esse script e veja o resultado. Que interessante! Basta o Joãozinho mandar o erro pra cima que todos na cadeia (as classes que chamam a classe Apertador, neste caso) recebam aquela Exception, graças ao uso do comando Try. Tudo o que roda dentro de um bloco Try é monitorado, e caso uma Exception seja "jogada" ou "arremessada" pra cima o controle vai para o bloco Catch imediatamente abaixo.

Perceba também que ao gerarmos uma Exception, ela já é criada com um monte de informações importantes automaticamente: em qual arquivo e linha que o erro aconteceu, um Trace completo passando por todo o código até o Catch que "pegou" aquela Exception e muito mais. Para ver um bom resumo, basta mandar imprimir a variável que contém a Exception; mas você também pode acessar as propriedades do objeto separadamente usando métodos como $e->getMessage(), $e->getLine(), $e->getFile() entre outras. Não é bom isso?

Com as exceptions nosso trabalho passa a ser somente colocar os Throws nos locais onde erros acontecem, deixando o tratamento desses erros para classes mais acima na hierarquia. Mesmo que você não trate estas Exceptions com blocos Try/Catch a coisa funciona: você pode deixar a exception subir na hierarquia até chegar ao topo, pois toda exception que chega ao topo sem ser "pega" gera um erro fatal. Então, caros amigos, vocês podem trabalhar inicialmente só colocando throws no código, e, ao final, refinar o tratamento distribuindo blocos try/catch pelas classes da hierarquia. Muito bonito.

Mas tem uma coisa ainda mais bonita. Sim, amigos, a classe Exception pode ser estendida. É uma classe como outra qualquer. Isso quer dizer que no nosso caso você poderia criar a exception DefeitoParafusoException, que já conteria a mensagem de erro e mais outras informações que você necessita sem precisar nunca mais digitar. Exemplo:

 

class DefeitoParafusoException extends Exception {
     function __construct(){
        parent::__construct();
        $this->message = "Defeito no parafuso!";
    } 
} 

 

Sacaram? Agora toda vez que você criar uma nova Exception do tipo DefeitoParafusoException a mensagem já será colocada por default na variável $this->message da Exception em questão! Imagine o que você pode fazer com isso. Mas ainda tem mais. Imagine agora que você não quer parar a produção simplesmente por causa de um parafuso com defeito. Muito bem, então vamos fazer com que os Supervisores comecem a "Pegar" este tipo de Exception para não incomodar o chefe:

 

 class Supervisor{

    function mandaApertar(){

        try {

            $joaozinho = new Apertador();

            $joaozinho->apertarParafuso();

            $joaozinho->oopa("Parafuso com defeito");

        }

        catch (DefeitoParafusoException $e){
            echo "Supervisor: é só um maldito parafusinho, diabos! Continuem!";
        }
        
        catch (Exception $e){
            echo "Supervisor: xi! Exception! Não sei o que fazer! Toma aí chefe!";
            throw $e; // peguei a bolinha, mas não sei o que fazer com ela... manda pra cima!

        }

    }

}

 

pra ver isso funcionando, precisamos alterar a função Apertador::oopa() para mandar uma DefeitoParafusoException:

 

 function oopa(){

        echo "Apertador: oopa! Deu pau! Segura aí supervisor!";
        throw new DefeitoParafusoException(); // não precisa mais da descrição...
} 

 

E pronto. Vocês perceberam que podemos utilizar vários blocos de catch um embaixo do outro? Essa é a beleza desta solução. Podemos começar com um tratamento de erros bem genérico, e depois ir especializando com novas subclasses, sempre lembrando de colocar as subclasses mais específicas, neste caso a DefeitoParafusoException nos blocos anteriores, deixando o catch genérico (Exception $e) por último.

Por hoje é só, pessoal, dúvidas, reclamações, elogios e doações são bem-vindas. Grande abraço a todos.

 

2007-04-03 17:05:26

Mais sobre a EMI e DRM: Steve Jobs escolheu aumentar o preço

Sim, amigos: segundo o site Gizmodo e de acordo com a EMI, foi a mesma EMI quem procurou a Apple para oferecer músicas sem DRM, e não sugeriu preço nem formato. A Apple decidiu cobrar um premium e aumentar a qualidade. Acho que não fui muito justo com a EMI quando agradeci a Mr. Jobs... Obrigado, EMI. Steve, você precisa baixar esse preço e oferecer a versão mp3 normal sem DRM. Ou tudo o que você falou vai por água abaixo.
2007-04-02 09:05:54

Um pequeno passo para a EMI, um grande passo para a humanidade...

EMI anuncia a venda de músicas sem DRM, com mais qualidade, por um preço premium. Steve Jobs, mais uma vez, à frente do seu tempo.

 Via Meio Bit 

2007-03-27 08:17:10
tags: 

BarcampSP: valeu

Gostei muito do BarcampSP. A idéia é legal: sair daquele velho esquema tradicional das palestras e conferências, abrindo a participação para todos os presentes. Claro que esse modelo depende das pessoas que estão ali, o que às vezes pode decepcionar uns e outros; Mas eu gostei, e boto fé que a coisa vai continuar crescendo. 

Veja mais sobre o evento aqui e aqui.

2007-03-26 08:38:40
tags: 

32Bits™ contrata Estagiários

Olá pessoal. Minha empresa, a 32Bits™ Criações Digitais está crescendo mais um pouquinho, e estamos contratando dois estagiários com conhecimentos de (x)HTML e css. O salário é legal, damos vale-transporte e o horário é super flexível. Nossas exigências são simples: tem que ser esperto, e tem que gostar de aprender coisas novas. Html e Css são os conhecimentos básicos, e outros, especialmente Actionscript, são muito desejáveis. 

Currículos para contato[arroba]32bits.com.br aos meus cuidados, ok? Também é importante ter algum trabalho online pra gente dar uma olhadinha no código.

 

P.S. Nossa empresa fica no centro do Rio, ao lado do metrô Cinelândia e do cinema Odeon. 

2007-03-16 10:11:23
tags: 

Mais uma jóia da Web 2.0: Gliffy

Gliffy é uma ferramenta web para desenho de diagramas e gráficos de forma colaborativa. Muito interessante. Confira no endereço http://www.gliffy.com.
2007-03-15 03:25:34
tags: 

Encontro vocês no BarCamp Sampa

É isso aí pessoal, já vi que alguns de vocês também vão estar em Sampa no próximo fim-de-semana, então não vamos deixar de nos encontrar! Já fiz algumas sugestões de temas no grupo, tem muita gente boa e assunto pra falar. 

2007-03-04 03:21:08
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 14)

Para ver os artigos anteriores desta série, clique aqui.

Estamos de volta, caríssimos leitores. Mais uma vez agradeço pelos comentários e emails. No último artigo nós fechamos o conceito de controllers, e vimos alguns exemplos práticos de como usá-los. Nos artigos anteriores, definimos as outras partes do MVC, models e views (ou templates). Tudo isso sem escrever uma só linha de código.

Bem, depois de tanto tempo sem digitar um único if, alguns de vocês começam a manifestar uma patologia cientificamente conhecida como "fome de código", ou "Síndrome da abstinência de programação". Os sintomas são variados: suor nas mãos, digitação de códigos procedurais aleatórios, criação randômica de scripts, e, nos estágios mais avançados da doença, envio de emails e comentários para o site deste autor bradando palavras de ordem "Código! Queremos código!".

Para todos que estão desesperados para colocar a mão na massa, uma pequena história Zen talvez ajude a acalmar o espírito:

"Um monge perguntou a seu mestre:

– Mestre, quanto tempo vai demorar para que eu atinja a iluminação?

O mestre respondeu:

– Dez anos.

O discípulo respondeu, agitado:

– Mas e se eu trabalhar duro, estudar todos os sutras, praticar dez horas por dia, quanto tempo vai demorar?

– Nesse caso, respondeu o mestre, vai levar 20 anos."

Se existe uma coisa que é fundamental em OOP é paciência. É praticamente impossível fazer alguma coisa que funcione bem usando essa filosofia de trabalho simplesmente abrindo o seu editor e digitando código. Paciência, esse é o caminho.

Mas é necessário desenhar TODO o sistema, cada detalhe, cada vírgula? Certamente não. Mas como saber qual é o momento de parar de desenhar e começar a programar de fato? Ah, jovem monge, nós saberemos. Acredite, nós saberemos. Chegará a hora em que não teremos mais dúvidas, que vamos olhar nosso desenho do sistema e vamos dizer "é, acho que agora já dá pra começar". Ao longo dos anos muitas metodologias e processos foram criadas para tentar desvendar este mistério. Mas só o próprio desenvolvedor, em seu íntimo, sabe quando está pronto. Por mais documentação que um sistema já possua, por mais discussões que se tenha, por mais diagramas e casos de uso e o que for, sempre existe o momento da iluminação, quando tudo aquilo a que fomos submetidos simplesmente "clica" e começa a fazer sentido. Todas as nossas questões sobre como o sistema funciona começam a ser respondidas claramente, e não há mais nenhuma pulga atrás de nossas orelhas.

É, talvez essa seja uma boa definição: a hora de começar a programar é a hora em que não encontramos nenhuma pulga atrás de nossas orelhas. E nesse momento, ainda tenho algumas quando penso em nosso Digitalminds Blogging Engine. Por exemplo: Já sabemos quais são as classes principais que vamos usar, e como vamos usá-las. Mas ainda não sabemos quais métodos e variáveis elas vão apresentar. Qual a vantagem de termos as superclasses Model, View e Controller se não encontrarmos métodos e variáveis que efetivamente facilitem nosso trabalho de criar um sistema? Isso, caros leitores, é precisamente o que vamos fazer nos próximos artigos. Mas ainda nesse artigo quero tentar responder a uma outra questão que está na minha cabeça: Será que não precisamos de mais nenhuma classe nessa história toda?

Bom, eu sempre costumo dizer que a preguiça é uma das minhas grandes virtudes; ela já me ajudou a resolver inúmeros problemas e a ganhar muito tempo pra fazer o que realmente importa na vida, ou seja, nada. De qualquer modo, o que quero dizer com isso é que sim, acredito que teremos algumas outras classes nos ajudando a fazer coisas repetitivas ou chatas demais.

A primeira coisa que me vem à cabeça é "o que fazemos se um erro acontecer?". Sim, amigos, erros vão acontecer, e nós precisamos estar prontos para lidar com eles de uma forma civilizada. E quem já escreveu um sistema qualquer em linguagem procedural sabe como é chato fazer tratamento de erros. São tantas possibilidades, tantas combinações de erros, tantos ifs e tantos switches que só os mais corajosos acabam fazendo tratamento de erro de uma forma realmente completa.

Mas os criadores da programação orientada a objeto, em sua infinita sabedoria, olharam para nós mortais com piedade e com o som de mil trombetas bradaram "Que se criem as Exceptions!" E então, o mar turbulento do tratamento de erros se abriu, e o povo programador pôde passar em paz. Os criadores do PHP, em sua razoável e confusa sabedoria, olharam para nós, os loucos que usam essa linguagem idiossincrática, e também bradaram "Que se criem as Exceptions em PHP5!". E em um segundo, tudo o que já foi feito em PHP para tratamento de erros se tornou obsoleto e bizarro.

O conceito de Exception, senhores, é uma das coisas mais impressionantes que já foram criadas. E, como todo conceito mais complexo de OOP, é muito difícil de entender, justamente por ser uma coisa relativamente simples. Entendeu? Certamente não. Então fique ligado e não perca o próximo artigo.

Grande abraço pra todo mundo.

 

2007-02-26 07:06:40
tags: 

Produção Web: Subverta sua forma de trabalhar com arquivos

Vamos fazer um teste rápido: você montou uma página html muito legal, o css já está fechado, tudo está validando, acessível, etc. e tal. Nesse exato momento, o seu cliente liga e faz um pedido infame:    

— Olha, vamos precisar colocar esses 15 logos na página, mas precisamos que você coloque um em cada parágrafo, ok?

Bom profissional que você é, aceita resoluto a solicitação do cliente e insere uma a uma as imagens na página, transformando a sua linda criação em uma quase-árvore-de-natal feita de símbolos e logotipos que não têm absolutamente nada a ver uns com os outros. Pra que a coisa fique minimamente interessante, você perde mais 45 minutos ajustando o css, mexendo no tamanho das imagens, enfim, fazendo o rejunte e o acabamento.

Considerações estéticas à parte, a página eventualmente fica pronta e você pede a aprovação do cliente. Então, caro amigo, o inesperado acontece:

— Olha, ficou poluído demais. Pode voltar atrás.

O que?! Voltar atrás?

É aqui que entra nosso teste: nessa momento de tensão, caro leitor, o que você faria:

Opção 1: aceita, emburrado, e recomeça de imediato a corrigir o código, removendo uma a uma cada modificação feita. Depois, precisa revisar tudo novamente pra ver ser não ficou nenhum erro, se o layout está igual ao original (mas peraí, eu detonei o original!)

Tempo total: 30 minutos.

Opção 2: aceita, levemente aborrecido, e começa a procurar os arquivos de backup que você havia feito antes de alterar os arquivos. Depois, precisa revisar tudo novamente pra ver se realmente tudo está certo, se aquele “salvar como” foi feito com todas as últimas alterações, se aquela modificação de texto que a menina pediu por telefone estava incluída.

Tempo total: 7 minutos.

Opção 3: aceita, com um sorriso cativante no rosto, e clica com o botão direito do mouse no ítem “TortoiseSVN->Exibir histórico”, escolhe a revisão anterior, e clica com o botão direito novamente “Reverter para essa revisão”. Pronto.

Tempo total: 5 segundos.

Muito bem, meu amigo, minha amiga, o que este teste mostra para nós? Se você respondeu opção 1 ou opção 2 você precisa de um sistema de controle de versão. Fato.

Um sistema de controle de versão guarda diferentes versões de um mesmo documento em um repositório e é capaz de fazer operações com elas. Assim, é possível não só voltar a uma versão anterior de um arquivo instantaneamente, mas também comparar e ver exatamente as diferenças entre duas versões, linha a linha. Mais que isso, duas ou mais pessoas podem trabalhar ao mesmo tempo em um arquivo texto, combinando as partes alteradas quando terminarem. Não é feitiçaria, é tecnologia!

Existem várias soluções para controle de versão disponíveis no mercado. Uma das mais populares é a chamada Subversion, ou simplesmente svn.

O Subversion usa uma interface de linha de comando, mas graças à bondade da comunidade open-source já foi desenvolvida uma interface gráfica para Windows chamada TortoiseSVN que é bem mais fácil de usar. Faça o download da aplicação e da tradução para o português brasileiro no endereço

http://tortoisesvn.net/downloads

Observação: Para quem usa mac, existe o SvnX. É um pouco confuso, mas talvez ajude:

http://www.apple.com/downloads/macosx/development_tools/svnx.html

Depois de instalar o TortoiseSVN (será necessário reiniciar o Windows), você já pode criar seu primeiro repositório:

- crie uma pasta nova para conter seu repositório

- clique com o botão direito do mouse nessa pasta e escolha “TortoiseSVN->Criar repositório aqui”.

Pronto, já temos um repositório. Você não vai trabalhar nessa pasta: os repositórios svn guardam os arquivos num formato proprietário que não pode ser usado; Para trabalhar, é preciso fazer um “checkout” do repositório em outra pasta, ou, em português, “Obter” os arquivos do repositório:

- crie uma pasta para guardar seus arquivos de trabalho;

- clique com o botão direito e escolha “SVN Obter”

- Agora é necessário digitar no campo “URL do Repositório” a url do repositório que você criou. Como trata-se de um folder no sistema de arquivos, use o prefixo file:/// antes do caminho da pasta. Exemplo: file:///C:meurepositorio

- clique OK

Pronto. A partir de agora, os arquivos desta pasta poderão ser “Submetidos” clicando com o botão direito sobre ela e selecionando “TortoiseSVN->Submeter” . Uma janela se abrirá e você vai poder selecionar os arquivos que deseja submeter.

Dica importante: nunca apague ou renomeie um arquivo obtido de um repositório subversion pelo Windows; sempre use o menu do TortoiseSVN. Quando isso acontece, o banco de dados interno do subversion fica perdidinho e você pode ter algumas surpresas.

Para saber mais não deixe de ler o livro “Controle de Versão com Subversion”, que já está parcialmente traduzido para o português no endereço

http://svnbook.red-bean.com/

Nos próximos posts da série, vou mostrar como usar um repositório online do Dreamhost.

Divirtam-se!

2007-02-12 16:05:01
tags: 

A web 3.0 chegou

http://pipes.yahoo.com. A nova web está chegando.
2007-02-12 13:34:41
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 13)

Para ver os artigos anteriores desta série, clique aqui.

Olá caros amigos caçadores de gnomos. Estamos de volta. Ainda precisamos fechar bem fechado este conceito fundamental chamado controller. Pegando do ponto onde paramos, que tal darmos alguns exemplos práticos de como nossos controllers vão funcionar? Gostou da idéia? Então entra aí e vamos lá.

Onde queremos chegar com toda essa conceituação? Bem, alguma coisa simples que torne o desenvolvimento e o uso de novas funcionalidades bem fácil. Vamos a alguns exemplos.

Primeiro, quero ver uma lista de posts simplesmente acessando a URL

http://meublog/posts/listar

Simples assim. Para criar um novo post:

http://meublog/posts/criar

Ah, e para ver um determinado post, o chamado permalink, quero acessar

http://meublog/posts/ver/xxxx

onde xxxx é o id do post, seja ele um texto ou um número.

Da mesma forma, para editar um post, quero acessar

http://meublog/posts/editar/xxxx

Para apagar um post

http://meublog/posts/apagar/xxxx

e assim por diante. Gostou? Muito bem, meu amigo, você acaba de definir o nosso primeiro controller, e suas primeiras funções ou métodos. Sim, veja a beleza da solução MVC, você está presenciando um mapeamento direto entre classes e métodos diretamente na url que o usuário acessa! Nas urls acima temos um controller chamado posts que tem 5 métodos: listar, criar, ver, editar e apagar.

Repare que ajuda bastante manter a coerência de linguagem - controllers normalmente são substantivos no plural (já que normalmente eles "controlam" dados de um modelo, no caso o controller "posts" lida com as informações do modelo "post") e os métodos normalmente são verbos. Alguns até chamam os métodos de "actions" ou ações, já que realmente nada mais são do que ações de fato. Capisce?

Bom, a essa altura já deve estar claro pra vocês (caso não esteja prometo que devolvo o dinheiro de volta) que já que temos dois modelos (posts e comentarios) precisamos, no mínimo, de dois gnomos: um pra cuidar de posts, e outro pra cuidar de comentários. Nasce, então, o controller "comentarios". Já sabem as urls e métodos que vamos ter que criar?

Por hoje é só. Até a próxima!

2007-02-10 02:49:00
tags: 

Produção Web: Ambientes de trabalho

Ao longo dos anos aprendi que uma boa estratégia é ter 3 ambientes distintos de trabalho: Produção, Validação e, finalmente, um ambiente de testes internos. O primeiro, intocável, é o ambiente onde os clientes acessam a versão do site atual. O segundo ambiente é o ambiente de validação, onde o cliente aprova as alterações feitas no site. O terceiro é o ambiente onde você testa as modificações antes de apresentar ao cliente.

Acredito que a coisa realmente importante desse approach é ter um ambiente separado de validação para o cliente. Assim você não corre o risco de "quebrar" o site enquanto ele revisa alguma outra coisa que você já fez.

Mas como fazer isso na prática? Um dos motivos da minha simpatia pelo Dreamhost é a possibilidade de criar subdomínios ilimitados. Assim, crio dois subdomínios, um de validação para o cliente e um de teste para mim. Exemplo:

Para criar um subdomínio no Dreamhost é muito fácil: acesse o painel de controle, clique na opção "Domains", e em seguida no link "Add New Domain / Sub-Domain". O painel de controle vai configurar automaticamente o subdomínio pra você e já vai criar a pasta com o mesmo nome no seu diretório home. 

Trabalhe localmente e suba os arquivos para o ambiente de teste. Se tudo estiver bem lá, inicie o procedimento de atualização:

  1. Renomeie a pasta atual cliente.digitalminds.com.br para cliente.old (se alguma coisa inesperada acontecer é so voltar atrás)
  2. Duplique a pasta teste.cliente.digitalminds.com.br e renomeie para cliente.digitalminds.com.br

Tudo pronto, seu cliente já pode fazer a validação das mudanças. Assim você não interrompe o site de validação durante o upload e tem certeza de que tudo está funcionando no servidor.

Existem formas ainda mais bonitas de fazer este tipo de atualização, especialmente se você tem Subversion disponível. Mas aí é outra dica. Pra coisas simples isso funciona muito bem, e você ainda pode fazer um pequeno script bash pra automatizar tudo.

É isso, gente. Até a próxima. Para ver todos os artigos desta série, acesse http://www.digitalminds.com.br/tags/pw

2007-02-10 02:32:20
tags: 

Produção Web: nova série

Olá pessoal. Começo hoje uma nova série na qual vou tentar passar dicas rapidinhas de produção web. São coisas simples e rápidas que aprendi ao longo desses 16 anos trabalhando nessa industria vital, que de repente ajudam vocês a resolver alguns problemas e ganhar tempo. A série vai se chamar Produção Web, e você vai poder encontrar os artigos no link http://www.digitalminds.com.br/tags/pw . Espero que gostem.
2007-02-07 08:26:38

Steve Jobs: Thoughts on Music

Vale muito a pena ler o que Mr. Jobs tem a dizer.

Via Alfarrábio, do Bicarato

2007-02-04 06:11:55
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 12)

Para ver os artigos anteriores desta série, clique aqui.

E estamos de volta, amigos, em dia de Superbowl (você nem precisa gostar do esporte, mas assistir à final é quase uma obrigação. Os comerciais mais esperados do ano são exibidos durante o evento, o show do intervalo vai ser de Prince, e quem ainda não ouviu o comentarista da ESPN de futebol americano não sabe o que está perdendo - é a coisa mais engraçada da televisão brasileira). Mas nós não estamos aqui para falar de futebol americano, não é? Nosso assunto de hoje, isso sim, são gnomos!

Os gnomos, como todos sabemos, são criaturas lendárias que geralmente usam chapéus ponteagudos e barbas enormes. Presentes na mitologia européia e nos jardins de muitas pessoas de gosto duvidoso, nossos pequenos amigos têm a fama de ter poderes mágicos e de viajar pelo mundo.

Muito bem, caros leitores, chegou finalmente a hora de revelar a todos o porquê da presença desses furtivos seres em nossa história. O que têm em comum, afinal, os gnomos e a programação orientada a objeto?

(rufar de tambores) (trilha de "psicose") (silêncio absoluto)

A resposta é muito simples. Absolutamente nada.

Mas peraí! Peraí! Antes de pegar os ancinhos, enxadas e outras ferramentas agrícolas e se dirigirem até minha casa bradando "IMPOSTOR! IMPOSTOR! MORTE AO IMPOSTOR" preciso de algumas linhas para me explicar.

Dentro da minha filosofia "PHP de Rua®" procuro sempre usar metáforas para explicar alguns conceitos que considero mais complexos. Ok, algumas dessas metáforas não são tão interessantes assim, mas acho que algumas já ajudaram alguns de vocês a compreender um pouco mais do assunto em pauta. Os gnomos, meus caros, são mais uma dessas metáforas, como vocês já devem ter percebido.

A idéia de usar os gnomos me veio à cabeça quando comecei a entender melhor o conceito de "manager" em orientação a objeto. Muito bem, vamos recapitular um pouco pra lembrar alguns conceitos importantes. Todos se lembram que definimos classes para Automóveis, Seres Humanos, e outros objetos? Agora quero pedir que vocês procurem ver uma característica que todas essas classes têm em comum, do ponto de vista conceitual: todas elas são criadas a partir de objetos que, de um modo ou de outro, são coisas de verdade no mundo real. Um automóvel existe como "coisa" tanto abstratamente quanto concretamente. Não sei se vocês estão entendendo, mas talvez ajude dar um exemplo de alguma coisa que não exista na realidade para que fique mais claro.

Na nossa série temos focado em um tipo de modelagem chamada "Real World Modeling", ou modelagem do mundo real. Ou seja, sempre que falamos de classes e objetos, falamos de alguma coisa que efetivamente existe no "mundo real". Automóveis e Seres Humanos são exemplos disso. Poderíamos falar também de Registros (de um banco de dados) ou Fichas de Cadastro; mas sempre partimos de uma "coisa" que já existe na realidade, um conceito pré-existente. Sempre tive mais facilidade de entender este tipo de modelagem; é o que me parece mais lógico. Mas, como vamos ver, muitas vezes em programação orientada a objeto um sistema é modelado usando conceitos que não são reais, ou melhor dizendo, usando conceitos que são criados somente para o sistema que se está desenhando.

Os Controllers, peça fundamental do design pattern MVC, são justamente um exemplo deste problema. Explico: é fácil imaginar que um sistema de gerenciamento de blogs tenha as classes Post e Comment, pois no mundo real estes ítens são componentes de um blog. O conceito de Controller, no entanto, jamais apareceria se nós tentássemos encontrá-lo simplesmente olhando um blog. Trata-se de uma classe criada a partir de uma metáfora de uso criada especificamente para resolver um problema de programação. Na prática, estas classes são normalmente muito importantes em um sistema, e ao mesmo tempo são as mais difíceis de criar, já que não têm uma contrapartida no mundo real.

Mas muito bem, ok, já entendemos que os tais Controllers são diferentes dos outros objetos, mas o que eles são exatamente? Aha, aí é que está. Eles são gnomos, amigos. Criaturas imaginárias que fazem coisas pra nós. Eles recebem ordens e as executam, não recebem salário e não reclamam (bom, se a gente programa tudo certo eles não reclamam).

Os Controllers são fundamentais no modelo MVC, pois são os responsáveis por receber as ordens, ou requests, dos usuários do sistema, interpretá-las e mandar novas ordens para que outras classes executem seus métodos. Eles mandam no pedaço. São os reis da cocada preta. Os maiorais.

Muitos de vocês talvez já saibam que existem dois métodos muito importantes para se requisitar (request, sacou?) coisas quando no protocolo http. Eles são os superpoderosos GET e POST. O método GET pode ser visto na maioria dos sites, é só procurar uma url que tenha uma interrogação. Nesse tipo de request o pedido é feito na própria url, passando muitas vezes pares de variáveis separados por um & (e comercial). Um request GET típico seria:

http://www.google.com.br/search?q=oop

Este request, como vocês podem imaginar, está passando a variável "q" com o valor de "oop" para o sistema. Tudo bem simples e trivial.

Um request post é muito parecido. Na teoria, estes requests teriam funções diferentes, o primeiro para "pegar" informações do servidor e o segundo para "colocar" ou "postar" informações lá. Mas, na prática, essa regra não se aplica muito, a coisa é bem misturada. Para nós, essa distinção não é importante, e para um Controller de verdade ela também não deveria ser, já que queremos que esse gnomo entenda qualquer tipo de ordem que o usuário passe para ele.

Esse é exatamente o ponto. Um controller "recebe" ordens, ou requests e executa métodos de acordo. Ou seja, qualquer request que chege em nosso site irá ser tratado por um gnomo, ou Controller, que irá dizer para modelos e outras classes "ei, você, post número 25, apareça aqui que o usuário quer editá-lo!" ou "Ei template Lista de Posts, tome aqui esta lista de posts e desenhe-se na tela". Em um sistema que implementa autenticação de usuários, por exemplo, os Controllers perguntariam "Ei, autenticador, este cara aqui pode editar este post?" e coisas assim. Deu pra entender?

Até a próxima. Alguém aí já está se coçando pra escrever algum código? Calma, gafanhoto... Ainda temos que decidir que gnomos precisamos. Vejo vocês por aí. Grande abraço.

2007-01-31 03:38:21

Google Earth disponibiliza ruas e estradas brasileiras

Um post rapidinho só pra dar uma notícia importante: a Google está lançando o novo Google Earth 4, que além de inúmeros updates está disponibilizando uma camada de ruas e estradas brasileiras. Vale a pena conferir!

 

http://earth.google.com/earth4.html

 

Volto já com a continuação da "Arte". Grande abraço a todos!
 

 

2007-01-08 02:09:46
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 11)

Olá todo mundo. Estamos de volta depois de um final de ano chuvoso, marcado pelos excessos gastronômicos e pela total e absoluta imobilidade. Àqueles que conseguiram viajar, meus cumprimentos. A minha viagem vai ficar para o carnaval, não pude viajar desta vez. Acho que a melhor definição dessas "férias" de fim-de-ano foi "uma grande seqüência de sábados, seguida pelo maior domingo de todos os tempos". Mas, quem sou eu para reclamar! Deu pra descansar bastante, curtir um pouco e ganhar a Master League na dificuldade Professional duas vezes. 

No nosso último episódio falamos um pouco sobre Views,  a letra V do MVC. Pra quem está chegando agora, vale a pena dar uma olhadinha nos artigos anteriores. Hoje vamos falar de modelos. Um assunto muito mais interessante, não? Mas, calmaí. Antes que você se decepcione, não vamos falar de modelos, mas sim de modelos, ok?  

Bom, de forma bem simples, o M do MVC é o cara responsável pelo gerenciamento dos dados da aplicação. Toda vez que você precisar ler alguma coisa do banco de dados, ou atualizar alguma informação, você vai utilizar um modelo. A chave para entender os benefícios do MVC é perceber que cada uma das três partes faz um trabalho específico, o que torna tudo no final das contas mais simples e seguro.  Na implementação, normalmente se cria uma clase base (normalmente chamada model ou appmodel) que contém quase todas as variáveis e métodos que você precisa para acessar dados no banco. A partir dessa classe, outras classes são criadas, estendendo os métodos para cumprir funcões mais específicas para cada um dos tipos de informação.

A palavra "modelo" talvez seja um pouco difícil de entender. Acho que a tradução foi feita ao pé-da-letra pra manter o acrônimo MVC; mas eu sempre tive dificuldade de entender esse conceito, muito mais do que tive pra entender "View" e "Controller". Pra deixar o conceito mais claro na minha cabeça inventei uma metáfora, talvez ela ajude alguns de vocês. Penso em modelo como um modelo 3d, tipo um robozinho de computação gráfica, responsável por "buscar e levar" os dados até o banco. Assim quando a gente fala que vai criar um modelo para um Post, estamos na verdade construindo um robozinho chamado Post que irá realizar todas as operações com o banco, e guardar informações importantes para nos passar depois. Esse robozinho é criado a partir de um robô genérico, chamado Model, que contém todos os métodos genéricos de todos os robôs. Lembrem que como estamos no mundo da orientação a objeto, podemos criar, na verdade, vários robozinhos Post a partir da classe Post. Esses robôs são instâncias ou objetos da classe Post.

Aliás, pra coisas simples, vocês vão perceber que quase todas as funções ou métodos são muito similares para quase todas as informações. Essa é a beleza dos frameworks MVC como o Rails: só de instalar você já "ganha" uma série de métodos prontos pra usar. Mas essa é uma outra história, que vamos falar um pouco mais tarde.

Muito bem. Quais seriam os modelos que teremos que construir para nossa aplicação funcione? Alguém se arrisca? Vou pelo caminho mais simples, como bom preguiçoso que sou. O primeiro modelo, e mais óbvio, é o modelo de "Post". Sim, amigos, sem posts, não temos um blog. Concordam? Então vamos em frente. Que informações um post deve guardar? Essa é fácil: no mínimo temos que guardar o título do post, seu conteúdo e seu permalink. Pra poder identificar este post de uma forma simples, vamos guardar também uma identificação única, que pode ser um número, por exemplo.

Outro modelo importante pra nosso DBE é o modelo "Comment", que representa um comentário feito em um post. Os comentários vão  guardar o conteúdo do comentário e a identificação do post ao qual ele se refere.

Pra nossa primeira versão, que vai ser muito simples, acho que estes dois modelos serão suficientes. O que vocês acham? Ficou faltando alguma coisa?  Mandem seus comentários!

Grande abraço e até a próxima.

 

2006-12-28 17:29:08
tags: 

Feliz Natal e um ano novo maravilhoso para todos!

$ano = 2007;

while ($ano >= 2007){

    $felicidade = true;

    $paz = true;

    $ano = $ano + 1;

}

2006-12-18 11:47:21
tags: 

Algumas Perguntas

O leitor Silfar Goulart me fez algumas perguntas por email que prometi responder por aqui. Então vamos lá:

Por que vc escolheu PHP ?

Na verdade, acho que foi PHP que me escolheu. Era uma das poucas opções disponíveis em servidores compartilhados linux. A outra era Perl. Quem conhece Perl gosta bastante, mas sabe que não é uma linguagem muito amigável. Então comecei com PHP.

Por que escrevo esta série em PHP? Bom, porque, como já disse antes, sou preguiçoso e estou muito mais interessado em me aprofundar na parte de design do que em conhecer outras linguagens. Eu realmente acredito que uma aplicação bem desenhada pode ser feita em qualquer linguagem. Dizem que Python é ótima, e eu já andei olhando Ruby e me pareceu muito interessante. Mas como meu tempo é limitado preferi me aprofundar em outras questões que estou achando mais legais no momento.

Agora, por que você vai usar PHP? Bom, primeiro porque ela está disponível em quase todos os servidores compartilhados do mundo. Claro que estas opções estão melhorando a cada dia, cada vez mais provedores estão disponibilizando Ruby e Java, por exemplo. Mas por enquanto, PHP ainda é quase sinônimo de sites dinâmicos no mundo linux.

Segundo, porque é uma linguagem muito gostosa de usar, especialmente simpática para quem está aprendendo. As funções para lidar com arrays são simplesmente maravilhosas, e a versão 5 é bastante esperta, não só em relação a Orientação a Objetos, mas também tem muitas coisas interessantes disponíveis na instalação. Não menos importante é a comunidade de desenvolvedores, muito ativa e prestativa.

Você trabalha mesmo com PHP ?

Sim, trabalho. Não sou um programador full-time, mas eu cuido do desenvolvimento de nossas aplicações server-side aqui na 32Bits™. Não tem nada muito complexo, mas nossas coisas são limpinhas :-)

No Wasabi, quem manda é meu sócio e guru Bruno Goyanna, e aí a coisa é muito mais séria. O Wasabi é todo escrito em Java, com Struts, Velocity, etc e tal. Performance é a palavra chave, e o Bruno é simplesmente "o" cara.


O que acha de python e ruby ?

Conheço muito pouco, mas as duas me parecem muito interessantes, especialmente Ruby. Só fico meio com medo de usar uma linguagem tão nova, sou meio conservador nisso. Quando Ruby estiver há uns 10 anos no mercado aí sim vamos saber se ela é toda essa Coca-cola que andam dizendo.

(UPDATE) O Cris Dias, que além de ser o dono do Vilago é programador Ruby, puxa minha orelha e diz que Ruby nasceu em 1995 também, assim como o PHP. E eu achando que o japa tinha inventado Ruby ano passado. Ignorância minha. É que a linguagem realmente só começou a aparecer por aqui nessa época, mesmo sendo bem forte no Japão. Acho que meu sentimento tem mais a ver com a abundância de recursos na internet disponíveis para PHP. O Cris, faz um artigo aí dando o caminho das pedras pro pessoal!

E sobre os frameworks feitos em python Django e TG ? e em ruby Ruby on Rails ?

Não conheço Django nem TG, mas o Rails é demais. Quem não conhece tem que conhecer, mas acho que é quase impossivel conhecer Ruby sem conhecer Rails, não? Pra quem programa em PHP, o CakePHP é um port muito bom do Rails pra PHP, embora ainda jovem. O que mais me impressiona no Rails é o cuidado com a documentação.

 

2006-12-17 07:20:18
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 10)

Para ver os artigos anteriores desta série, clique aqui.

Olá todo mundo, escrever nesse calor que está aqui no Rio é quase uma insanidade, mas enquanto houverem leitores a série deve continuar! Hoje vamos começar a detalhar melhor nosso plano falando de uma das partes importantes que compõem o pattern MVC. Mais precisamente, o "V", ou View.

Decidi começar por aí (sei que parece estranho para quem já conhece o funcionamento do MVC) por uma razão bem simples: eu sou preguiçoso, e gosto sempre de começar pelo mais fácil. Na minha modestíssima opinião, o conceito de View é o mais simples dos três, e certamente o mais simples de implementar também.

Quem já trabalhou com algum template engine (como o Smarty, por exemplo), já conhece o conceito de View com outro nome: Template. Basicamente, uma View é um gabarito que permite a visualização de dados dinâmicos dentro de uma determinada formatação. Bom, na verdade é um pouco mais que isso, é também um conjunto de classes que suportam o uso destes templates, afinal se você simplesmente gravar um arquivo com html ele não vai se tornar dinâmico sozinho, não é mesmo?

Uma definição mais careta de View é a seguinte: "uma representação de um estado do modelo". Cuma? Bom, pensei numa metáfora razoavelmente idiota para explicar esse conceito, me perdoem se parecer meio ridículo, mas juro que estou fazendo o melhor que posso :-)

Primeiro, você vai precisar de um caderno, um lápis e um estilete. (?!) É isso mesmo. Vá lá no quarto e pegue um caderno, um lápis e um estilete. Se não tiver um estilete, nosso pseudo template não vai funcionar. Depois você vai entender por quê.

Arranque uma folha do caderno e escreva no topo "Template para criação de Posts". Esse será o nosso template 1. Logo abaixo, escreva "Título do Post:", e embaixo disso, "Texto do Post:". Tudo bem? Bom, você já tem um pseudo template html, mas ainda falta o fundamental, a conexão com o nosso pseudo banco de dados, também conhecido como caderno. O estilete, essa tão importante ferramenta, vai funcionar para fazer a conexão.

Pegue o estilete, e, ao lado do texto "Título do Post", faça um buraco (ou, em nosso pseudo html, um ítem de formulário Input Text) que permita mais ou menos 255 caracteres. Do lado de "Texto do Post:" abra um buraco ainda maior, simulando um TextArea. Eu falei que era uma metáfora meio idiota, não falei?

Muito bem, senhores, vocês têm em suas mãos um Template. Ou uma View, como queiram. Agora podemos usá-la tanto para escrever em nosso "banco de dados" quanto para visualizar seu conteúdo de forma bonita, formatada. Se quiser, você pode editar esse template pintando com hidrocor, sabe como é, dá pra fazer bastante coisa com Hidrocor Style Sheets. OK, deixa pra lá.

Para adicionar um "registro" no "banco de dados" basta "carregar" o seu template, colocando-o sobre uma página vazia do caderno, e escrevendo os dados dentro dos buracos no template. Para adicionar outro registro, vire a página e repita o procedimento. Nesse exemplo, o estado do modelo é a página que você está vendo. Mudar o estado do modelo, portanto, é como mudar de página nesse exemplo tosco. Vocês entenderam?

Claro que um modelo que não é feito de papel pode mudar de estado de outras formas, mudando quais informações estão disponíveis e a forma como elas estão sendo visualizadas. (Ainda preciso ver como fazer sort nesse banco de dados, mas ele possui a grande vantagem de ser portátil, de fácil utilização e ser facilmente expansível "conectando" outros "bancos de dados" quando o espaço acabar. Muito interessante, não? O chato é fazer backup.)

Bom, resumindo, uma View é uma espécie de gabarito que contém partes estáticas (escritas em html, no nosso caso) e outras dinâmicas (escritas em php simplificado, para garantir que não vamos colocar lógica dentro de nossos templates). Claro que os templates que vamos construir são mais poderosos e flexíveis que os feitos em PHTML ou Pseudo Html ou Papel html, sei lá.

Vou dar um exemplo: nosso blog, claro, vai disponibilizar um feed RSS para seus leitores. Usando templates, isso é muito simples: pegamos as mesmas informações que mostramos no blog usando um template bonitinho em html e as mostramos usando um template escrito em XML, no formato Atom, por exemplo. Pra isso funcionar, é só fazer um novo template trocando, por exemplo, a tag "h1" usada no html por uma tag "title", usada no formato Atom. Muito mais fácil do que ficar copiando queries, scripts inteiros, e coisas do gênero.

Em termos práticos, pra nós uma View vai ser um arquivo php que praticamente só contém html. As únicas coisas que estarão escritas em PHP serão os dados que vêm do banco de dados ou algumas funções bem simples para realizar loops, imprimir constantes na tela e pouca coisa mais. Vamos manter nosso DBE bem simples, se depois alguém precisar de mais funcionalidades vamos permitir que se use o Smarty ou qualquer outro template engine pra renderizar nossas Views.

Até a próxima.

2006-12-04 13:22:49
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 9)

Olá a todos. Mais uma vez estamos aqui (excepcionalmente escrevo numa segunda-feira, já que meu fim-de-semana foi totalmente dominado pelo PES6, também conhecido como Winning Eleven 10) pra falar de OOP, ou object-oriented programming. No último post, deixei bastante suspense no ar. O que é o design pattern MVC? Por que usar MVC neste projeto?

Como muitos que nos acompanham já sabem, muitas vezes este esquizofrênico autor acaba fazendo novas perguntas e dando respostas totalmente desvairadas às perguntas feitas anteriormente. Desvairadas no bom sentido, claro - para chegar à essência de qualquer coisa, primeiro temos que entender muito bem suas particularidades; portanto minha resposta à pergunta "O que é o design pattern MVC" vai ter duas etapas (consegui colocar 3 acentos graves em um só parágrafo. Uau.)

Etapa 1: O que é "Design Pattern"?

Design Pattern é o termo utilizado para definir uma prática bem estabelecida em arquitetura de software, uma solução clássica para um problema recorrente. Ou seja: meu amigo, esse problema que você está tendo muito provavelmente alguém muito mais inteligente e com mais disponibilidade de tempo já teve e já resolveu com uma classe, uma beleza que muito provavelmente você não conseguiria. É isso mesmo, o primeiro passo para se tornar um grande desenvolvedor (ou um chutador barato como eu) é aceitar a humildade em seu coração e perceber que as soluções mais bonitas já estão por aí. É só achar. E os design pattern clássicos são pura poesia em forma de código.

"Mas tudo bem, Danilo, eu sou humilde, mas ainda não entendi". Bom, aí, só mostrando na prática, não é mesmo? Então vamos lá, chegou a hora de não explicar o que é MVC.

Etapa 2: O que é "MVC"?

Model, View, Controller. É isso. Entendeu? Olha, se você ainda não entendeu, pode desistir. Não vai adiantar. Invente alguma outra coisa pra fazer, vá mexer no Photoshop, sei lá.

Brincadeirinha. O difícil dessa história de design pattern é compreender a beleza da solução. Só com o uso você pode entender. Eu poderia copiar e colar várias definições sobre o que é MVC, falar sobre toda a teoria, mas, como vocês já sabem, esta não é uma série convencional, e eu estou me propondo a mostrar essas coisas de um ponto de vista mais tosco. Algo como um PHP de rua, se é que vocês me entendem.

Então, pra mostrar ná prática o que é MVC, vou começar listando as coisas que mais me irritavam quando desenvolvia scripts PHP. Aí, se você não entender, realmente vai ser melhor ir fazer gifs animados lá no Photoshop, saca? :-)


- Lógica no meio do desenho da tela

Não existe nada mais desesperador do que lógica no meio do desenho da tela. Digo isso com conhecimento de causa, já que este é um dos piores problemas deste blog que vocês leêm nesse exato momento. É um inferno. Quero trocar o conteúdo de um link, mas ele está no meio de infindáveis ifs (perdoem o trocadilho) e depende de uma outra infinidade de variáveis que não sei mais de onde vieram e pra onde vão. Para criar o RSS feed do blog? Tive que começar do zero, o trabalho de editar o código que já existia nem valia a pena. Um outro exemplo clássico é a versão 2 do OsCommerce, o software open-source de comércio eletrônico. Tentem mudar qualquer coisa ali pra ver. Tem um milhão de condicionais e funções que rodam nas páginas de apresentação de conteúdo, entre um div e um p por exemplo. É coisa pra deixar qualquer um maluco. Um trabalho que poderia levar alguns dias me tomou 3 meses. Eu odeio isso com todas as minhas forças.

- Segurança $_GET e $_POST

Se você usa scripts php diversos para cada uma das páginas do seu site sabe muito bem que cada input do usuário, em cada página, precisa ser validado. Aí, digamos que você tenha 12 páginas php em seu site, e você copia e cola código em todas elas. Ok, agora, imaginemos ainda que 3 variáveis mudaram. Você tem que ir lá e copiar tudo de novo, doze vezes. Os mais espertinhos vão dizer "ah, mas é só fazer um include!", ao que eu respondo "mas, hey, amigo, cada página tem diferenças sutis em relação às outras, os dados comuns têm uma validação diferente de acordo com a situação do usuário e - deus que me livre - de acordo com seus níveis de permissão". Aí, cara, você cai duro, imaginando que aquele orçamento que você deu foi totalmente por água abaixo e que você vai ficar copiando e colando código para toda a eternidade, até que um dia não exista mais PHP no mundo e finalmente você possa descansar em paz.

OBSERVAÇÃO: Claro que dá pra fazer um site ou uma aplicação assim. O que nós estamos falando é de produtividade e capacidade de evolução com o tempo. Todo bom desenvolvedor que conheci é preguiçoso; afinal o computador foi criado pra que nós não tivessemos tanto trabalho, não é mesmo?


- Includes em múltiplos arquivos

Ah, includes. Os includes são uma bênção. Mas quando se tem 30 arquivos php para trabalhar, gerenciar includes se torna uma tarefa muito chata. Uma das soluções que a comunidade desenvolveu ao longo do tempo é o pattern "top.php", um arquivo que é incluído em todas as páginas do site, no topo, que por sua vez inclui outros 30 arquivos necessários ao funcionamento do site. Preciso dizer que tem desperdício de recursos aí? Aquela página que só precisa dos arquivos 1.php e 2.php acaba carregando o 3.php até o 30.php sem precisar. Bons desenvolvedores são higiênicos também; não gostam que tenha sujeira embaixo do tapete.

- SQL misturado com scripts php

Ah, essa é de doer. Já cansei de fazer código que tem SQL misturado, no meio dos scripts PHP. Sim eu era um "lousy coder", um desenvolvedor mixuruca, mas se você olhar tem muito código open source por aí assim. Meu Deus, como eu não via a gravidade desta heresia? Como eu não pude perceber que lugar de SQL não é no script que desenha minha tela? Que sql é coisa muito séria, que deve estar protegido, separado em classes que deixe tudo bem seguro pra que nenhum engraçadinho detone meus dados? Bem, acho que eu realmente não ligava. Mas quando a coisa começou a tirar a minha produtividade, e eu perdia horas procurando "cadê aquela query, acho que deve ser essa aqui" etc e tal a coisa ficou mais clara pra mim. Tinha que haver uma solução melhor pra isso.


Bom, o que posso dizer para vocês é que o pattern MVC resolve estes e muitos outros problemas, e uma vez tendo usado MVC você não vai querer mais voltar para o inferno. Mas tem uma questão: a coisa toda é mais complicada. Fato. Precisa pensar um pouco antes de sair escrevendo código. Precisa planejar. E esse planejamento é precisamente o que vamos começar a fazer no próximo artigo. Até lá.

p.s. o gnomo é o c...

2006-11-25 04:23:17
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 8)

Olá todo mundo. Tudo pronto? Cintos de segurança afivelados? Mesinhas fechadas e travadas? Hoje começamos nossa longa jornada com um primeiro passo importante: definir algumas premissas do novo e nada revolucionário Digitalminds Blogging Engine 2.0, o primeiro software open-source para gerenciamento de blogs desenvolvido pela comunidade Digitalminds (o DBE 1.0, como vocês já sabem, é um script todo remendado, feito nas horas vagas, que não tinha código livre por que o autor tem vergonha de mostrar o ninho de rato que a coisa é).

Muito bem, então vamos às premissas:

do Lat. praemissa
cada uma das duas proposições, maior e menor, de um silogismo;
facto ou princípio que serve de base a um raciocínio ou a um estudo

Nossa primeira premissa é que nossas premissas serão as bases do nosso projeto, e que premissas só são alteradas para novas versões. Essa frase ficou um pouco redundante, eu sei, mas vocês vão ver que redundância é uma coisa muito importante quando se trabalha em grupo. Tudo precisa ser muito, muito, mas muito bem explicado para que não haja nenhum problema.

Que fique claro para todos, então, que depois da definição de nossas premissas para a primeira versão do projeto, só poderemos ter novas premissas para uma nova versão. Um dos maiores erros que podemos cometer é mudar de premissas durante o projeto. E, amigos, acreditem, vai ser muito tentador. Muitas vezes em projetos complexos dá muita vontade de mudar o que foi acordado antes, simplesmente por que todos aprendem ao longo do processo e percebem que algumas definições não fazem muito sentido. Mas como diz aquele deputado que não lembro mais o nome, "Versão boa é versão finalizada". É melhor ter um software na mão do que dois voando. Como estamos tentando aprender com o processo, vamos tentar manter a ordem e fechar a primeira versão conforme as premissas originais, ok?

Muito bem, senhores, então quais seriam as outras premissas para o projeto? Tenho algumas idéias que gostaria de sugerir:

- O DBE 2.0 vai rodar necessariamente em ambientes LAMP (Linux, Apache, MySql, PHP). Claro que não será difícil portar o sistema para outras configurações, mas não será nosso objetivo.

- O código será disponibilizado em um repositório Subversion(SVN), e todos poderão atualizá-lo sem restrições. A responsabilidade é sempre deixar a versão do trunk funcionando. Se você não entendeu nada dessa premissa, não se desespere. Vamos explicar diretinho o que é SVN, e dar todas as dicas para usar esse sistema de controle de versão fantástico.

- A versão 2.0 do DBE vai ter apenas o estritamente necessário, do ponto de vista das funcionalidades. Ponto final. Vamos tentar fazer para essa versão apenas o essencial. Se tivermos qualquer dúvida sobre uma funcionalidade, ela fica pra próxima.

- Como simplicidade é a palavra de ordem, não vamos construir nesse momento um sistema de autenticação. Vamos usar a autenticação Digest do Apache, ou mesmo a Basic, caso alguém não seja tão paranóico quanto eu. Trata-se de uma configuração bem simples que pode ser feita em um arquivo .htaccess no seu servidor. A vantagem da Digest é que ela usa criptografia para proteger a sua senha durante o envio. Pra quem não conhece os termos técnicos, autenticação do apache é aquela janelinha que abre em alguns sites pedindo pra você digitar a senha. Nada muito bonito, mas é bem seguro e fácil de implementar.

- A versão 2.0 do DBE vai ser escrita em PHP 5.1.4, usando orientação a objeto. Por quê esta versão? Bom, acho que esta é a primeira versão na qual a programação OOP realmente funciona 100%. Enfim, acho que não vai ser problema pra ninguém, praticamente todos os provedores bons já estão com esta versão, que por sinal tem outros updates importantes na área de segurança.

- Nosso DBE vai ser desenvovido usando modelo simplificado do design pattern mvc. por que usar o pattern mvc? O que é o pattern mvc?

Não perca o próximo capítulo! Só posso dizer que os gnomos estão chegando, amigos, e mais premissas também!


2006-11-18 03:25:25
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 7)

Olá pessoal, depois de mais um longo e tenebroso outono(?!) de muito, muito trabalho estamos de volta. Muito obrigado por todos os comentários e emails, mesmo estando totalmente atolado de trabalho na 32Bits™ eu tento ler todos e respondê-los o mais rapidamente possível. Pra quem tá chegando agora no blog, meu email é danilo[arroba]digitalminds.com.br e você pode ver todos os artigos dessa série clicando no título deste post, ok?

Bom, muitos escreveram perguntando sobre os gnomos. Quando eles vão aparecer nessa tão complexa trama? Qual é sua verdadeira identidade? O máximo que posso dizer é que eles tem contrato para 7 temporadas, e que talvez as respostas ainda demorem um pouco a vir... (funciona pro Lost, não? ;-)

Mas voltando ao que realmente interessa, OOP, ou object-oriented programming, hoje quero preparar o terreno para os próximos episódios. Agora que os conceitos principais já foram apresentados a vocês (se você ainda não sabe o que são classes, subclasses, interfaces, etc, talvez seja bom dar uma olhadinha nos artigos anteriores) gostaria de começar a parte Zen de nossa série. Como nossa marca registrada é gastar metade do artigo falando sobre coisas que são apenas marginalmente relacionadas ao assunto principal, vou tentar explicar o que é Zen em apenas uma palavra, sem nenhum compromisso de conseguir. Vamos lá:

Prática.

Talvez seja mais simples enumerar tudo o que o Zen não é. Zen não significa calma. A frase "Fulaninho é Zen, não se irrita com nada" basicamente não significa nada. Zen não é um conceito esotérico. Zen não é magia, tampouco feitiçaria.

Prática. Contar diariamente de um até dez. Koan. Tornar-se um com o arco. Concentração. Mente de principiante. Buda. E por aí vai.

E o que tudo isso tem a ver com OOP? Bem, caros leitores, a experiência de programação em oop só pode ser totalmente vivida na prática diária. Ler sobre oop é ótimo, mas é como olhar para o dedo que aponta para a Lua, e não olhar a Lua propriamente dita. Como verdadeiramente aprender estes conceitos? Vivendo-os. Como quebrar os Koans das classes, interfaces e patterns?

Recebi alguns emails pedindo que desse exemplos do uso da OOP em situações do dia-a-dia. Muito bem, então vamos começar uma nova etapa dessa série: Digitalminds 2.0.

Já faz tempo que quero refazer o Digitalminds Blogging Engine, que mesmo tendo esse nome bastante pomposo é um script muito furreca, todo remendado, escrito na correria entre trabalhos. Então, vamos nessa? Vamos refazer juntos o DBE, usando os conceitos que falamos, e, ao final do projeto, lançamos o DBE como um produto open source para livre download?

Acho que é uma idéia legal. Tudo bem que já existe o WordPress, etc e tal, mas... se a gente for por aí, TUDO já existe. A idéia é aprender e curtir o processo. Quem se habilita?

Até a próxima. Não percam o próximo artigo, vamos listar nossas premissas para o projeto e quero as opiniões de vocês. Abraço.

2006-09-17 05:34:55
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 6)

(Para ver todas as partes desta série clique aqui)

Olá, pessoal, já estamos aqui de volta para falar mais um pouquinho sobre OOP, PHP, e outras siglas igualmente ininteligíveis. Hoje quero falar sobre um tema que sempre gera muita confusão: interfaces. E, é claro, não podemos falar de interface sem olhar a etimologia dessa palavra.

O prefixo inter- vem da preposição latina inter, que significa "entre, no meio de". A palavra face, também de origem latina (fascia), significa "camada externa". Juntando as duas coisas, temos um termo genérico que significa praticamente qualquer coisa em tecnologia. Temos interfaces gráficas, interfaces com o usuário, interfaces RS232, interfaces usb, e por aí vai.

O conceito denominado de interface em OOP é bastante diferente disso tudo. No nosso mundo imaginário de carros, superpoderes, gnomos e outras criaturas fantásticas orientadas a objeto, interfaces são simplesmente definições padronizadas de acesso a funções que estão dentro das classes que as implementam. Falando assim parece bem complicado, mas não é não. Na verdade, na verdade, se a gente olhar com muito cuidado, nós de fato já usamos o conceito de interface aqui mesmo nos artigos anteriores.

Explico: quando nós criamos uma classe, estamos criando também uma interface. Lembra que nós construímos dois carros, um FiatUno e uma FerrariF1, e ambos podiam ->acelerar() ? Justamente! Ajoelhe-se diante do poder das interfaces!

Ao estender a classe Automovel para criar a classe FiatUno e a classe FerrariF1 nós estamos automaticamente implementando a interface usada na classe automóvel nas duas. Assim, temos absoluta certeza que todas as classes-filhas da classe Automovel vão poder ->acelerar(). Esse é exatamente o conceito de interface: a padronização do acesso aos dados e funções de uma classe ou objeto.

Mas o que é realmente interessante é que algum desses gênios malucos que inventaram os conceitos de OOP acordou um belo dia e teve uma idéia brilhante: "Perai, mas eu não preciso ter que criar classes-filhas toda hora pra usar uma interface!". Nasciam as palavras-chave interface e implements, que permitem a criação de interfaces que podem ser usadas entre classes que não tem nenhum parentesco entre si.

E eu estou aqui para provar tudo isso implementando Superpoderes em Automóveis! Você há de concordar que um Automovel não tem nada a ver com um SerHumano, já que eles não têm nenhum parentesco. Como ter certeza que essas classes e todos os seus filhos possam usar objetos da classe SuperPoder de forma padronizada? É fácil:

Primeiro, criamos a interface SuperHeroi:

 interface SuperHeroi {
    public function ativar(SuperPoder $superpoder);
} 

Bom, como você pode notar, a função ativar só vai funcionar se você mandar pra ela o SuperPoder desejado durante a chamada da função. Se mandar texto, número ou qualquer outra coisa vai ganhar um erro de presente.

Agora vamos alterar nossas classes Automovel e SerHumano para implementar a interface SuperHeroi:

Class SerHumano implements SuperHeroi { 	
    public $nome;
    public $vivo; 	
    public function __construct($nome) {
        $this->nome = $nome;
        $this->vivo = true;  	
    }
    public function taVivo() { 
        if($this->vivo == true) {             		
            print "Sim, eu estou vivo, e meu nome é $this->nome!"; 	
        } else {             	
            print "..."; 	
        }  	
    }
    public function ativar(SuperPoder $superpoder){
        $superpoder->ativar()
    }
} 

e agora a classe Automovel:

 abstract class Automovel implements SuperHeroi {
     public $aceleracao;
     public $velocidade_atual;
     public $cor;

     public function acelerar() {
        $this->velocidade_atual = $this->velocidade_atual + $this->aceleracao;
        print "Acelerando! Agora a velocidade é de " . $this->velocidade_atual . "Km/h!";
     }    
    public function ativar(SuperPoder $superpoder){
        $superpoder->ativar();
    }
 }

 

Agora, tanto os objetos SerHumano quanto objetos da classe Automovel (incluindo aqueles das classes FiatUno e FerrariF1, já que pela herança um FiatUno ou uma FerrariF1 sempre têm todas as propriedades e funções da classe Automovel) já podem ->ativar() um SuperPoder. Como a classe SuperPoder é abstrata e ninguém consegue ativar um SuperPoder abstrato, vou ativar a SuperForca:

$meucarro = new FerrariF1('vermelha'); 
$meucarro->ativar(new SuperForca);
// Meu deus, posso levantar um caminhão! 

E os gnomos, você deve estar se perguntando. Eles virão... Eles virão...

2006-09-05 03:15:33
tags: 

Assine o Dreamhost sem pagar taxa de adesão

Pra quem ainda está procurando por um bom provedor recomendo enfaticamente o Dreamhost. Como já comentei anteriormente, tinha bastante gente que tinha gostado do Dreamhost mas que achava a taxa de setup muito alta. Aí lembrei que eu posso dar um desconto pra quem assinar usando o Digitalminds como referência. Então, como não estou aqui pra viver disso, resolvi descontar toda a taxa de setup da grana que eu receberia por cada referral. Ainda vou ganhar o suficiente pra pagar minha conta lá, então tá tudo certo.

Pra quem não conhece o Dreamhost, essas são algumas das características:

Com a promoção, você paga US$ 10,95 no cartão de crédito por mês, sem taxa de adesão. Se pagar um ano de uma vez, eles não cobram a taxa, você paga US$9.95 e você ainda ganha o desconto, ficando com 5 meses grátis. Se quiser pagar 2 anos de uma vez o preço cai pra US$8.95 e você ainda ganha o desconto, ficando com 6 meses grátis. Vale a pena!

Mas cuidado: não tem suporte nem documentação em português. Se você está procurando um bom provedor com suporte diferenciado aqui no Brasil, recomendo o Vilago, do Cris Dias.

ATENÇÃO: Algumas pessoas tiveram dúvidas sobre como pegar o desconto, pois ele não aparece até a verificação final.

  1. Escolha o plano de hospedagem;
  2. Preencha os seus dados;
  3. na página entitulada Verify Total, coloque DIGITALMINDS no campo Promo Code;
  4. aperte o botão UPDATE para receber o desconto.

Clique aqui para escolher seu plano e aproveite.