Disk Chocolate » programação

Meu ambiente de trabalho em 7 itens

Cindy Dalfovo — Wed, 02 Feb 2011 00:05:16 +0000

Eu estava lá, no meu cantinho, quando me convocam para um meme. Assim, do nada. Sem nem pedir antes. Essas pessoas, viu…?

Bom, o que eu podia esperar do Cobalto, né? u_u

Item 1 – Windows 7

Há, eu sei, aparentemente é de praxe começar pelo sistema operacional. Em todo caso, para mim faz diferença porque em casa uso o OS X, então… e o pior é que eu gosto. Sério, depois do detestável Windows Vista, é bom ver um Windows minimamente decente, que funciona bem.

Embora eu tenha toda sorte de bugs bizarros com ele – um só foi resolvido, er, criando uma conta nova no Windows. Não conseguimos descobrir qual era o problema da antiga, mas, enfim.

Item 2 – Eclipse

Ah, a IDE que eu amo odiar. Ele tem a manha de travar quando você está no meio da digitação, uma coisa linda. por outro lado, bom, as ferramentas e atalhos para encontrar classes, métodos e refatorar salvam minha vida <3

Item 3 – Piranha Plant de pelúcia

Junto com meu pequeno Wall-e, o Totoro na pokébola e a Marisa (Claymore), eles enfeitam meu ambiente de trabalho. As pessoas dizem que minha área é mais bonitinha.

Que foi, só contava o ambiente de trabalho do computador em si? Bom, não li nada sobre ser só programas, então adicionei algo que eu adoro “no meu canto”

Item 4 – TrueCrypt

Todos os dados estão em partições do TrueCrypt, esse lindo. Sério, adoro o programa, ele é eficiente e faz muito bem o que precisa fazer. É sempre o primeiro programa a ser aberto quando ligo o computador, por motivos óbvios. E um dos poucos programas que eu uso que nunca deu problema (mas se der, também, FODEU, imagina não poder mais abrir os dados do trabalho? D:)

Item 5 – Fones de ouvido

Que diabos de ambiente de trabalho de programador está completo sem fones de ouvido? Às vezes é praticamente impossível trabalhar sem estar ouvindo música. Interessante quando tá todo mundo nesse clima, com fones de ouvido, concentrados no trabalho. Parece reunião de autistas.

Item 6 – SVN/CVS

É, eu sei que a moda agora é Git, mas, sinceramente, comitando meus programas direitinho, não tem problema. Sério. E tendo históricos.

Item 7 – Plaquinha amarela escrito “Lost – the game”

Embalagem de um presente que eu dei para um colega, agora passeia pelo trabalho. Preciso mencionar isso aqui já que nossa empresa provavelmente tem um dos índices de “FUUUU, PERDI O JOGO” mais altos de… bem, é um índice bem alto.

A propósito, vocês também acabam de perder o jogo

E para continuar o meme eu indico VOCÊ, AÍ, SENTADO NESSA CADEIRA, QUE ACABOU DE PERDER O JOGO. Isso, você mesmo. Vai lá.

[Tutorial] Fazendo um jogo de memória em JavaScript (parte básica)

Cindy Dalfovo — Fri, 28 May 2010 18:03:10 +0000

Olá pessoas Eu queria ter postado esse tutorial já na semana passada, mas de lá para cá eu tive alguns problemas, e provas e, bom, acabei não programando nesses últimos dias. Em todo caso, esse tutorial vai explicar como fazer o joguinho básico que se encontra aqui, que eu havia mencionado no post anterior. Eu quero fazer algumas adições a ele, colocar mais algumas funcionalidades mas, em todo caso, eu achei que seria legal fazer o tutorial para o básico e depois fazer outros pequenos tutoriais sobre as outras funcionalidades.

Esse tutorial não requer que você saiba muito de JavaScript e/ou jQuery, mas ter alguma noção ajuda, e já ter programado também. Não é muita coisa para explicar, então eu vou tentar explicar tudo com detalhes para ajudar quem também está aprendendo JavaScript e/ou jQuery, OK?

De qualquer maneira, eu ainda estou aprendendo a escrever tutoriais, embora já tenha escrito alguns, então eu sempre posso esquecer de falar algo importante… se for o caso, pode perguntar nos comentários que eu respondo e, se possível, melhoro o tutorial, ok?

O Esqueleto da Aplicação: HTML e CSS

Como não é feito nada de muito avançado nem no HTML nem no CSS, vamos apenas dar uma olhada rápida na estrutura dos dois, ok?

Clique em 'mostrar' para ver o HTML
Jogo da Memória em JavaScript Jogo da Memória em JavaScript Tentativas:

Como vocês podem ver, a parte HTML desse joguinho é realmente BEM simples. Só quero ressaltar alguns detalhes:

São inseridos dois scripts: o script do jQuery, e o script do jogo. A ordem é importante, já que eles são carregados em ordem – se o jogo.js estivesse sendo carregado primeiro ele daria erro.
Estão vendo esses “div” no corpo da página? Sem entrar em aspectos técnicos, eu gosto de imaginá-los como marcações, um quadradinho colorido. Mais tarde eu vou mexer nesses “div” via CSS e via javascript e vou chamar o elemento cujo ID é mesa-de-jogo e o div certo vai ficar levantando os braços dizendo “me usa, me usa, sou eu, sou eu!” (imaginação fértil: eu tenho).
A parte de tentativas não está na página atual, apenas no arquivo do meu PC, mas é algo bem simples. Se você quiser implementar as tentativas, use esse div, senão, não use.

O CSS tem mais alguns detalhes, mas também é bastante simples:

Clique em 'mostrar' para ver o código CSS
body { background-color:#363636;} h1 { color:#84C1C3; text-align:center; font-family:sans-serif;} .carta img:hover { cursor:pointer;} .carta img { margin:5px;} .carta { display:inline;} #mesa-de-jogo { display: block; text-align:center;} #texto-tentativas { text-align:center; color:#84C1C3; font-family:sans-serif;} #tentativas { display:inline;}

Clique em 'mostrar' para ver o código CSS

body {	background-color:#363636;}
h1 {	color:#84C1C3;	text-align:center;	font-family:sans-serif;}
.carta img:hover {	cursor:pointer;}
.carta img {	margin:5px;}
.carta {	display:inline;}
#mesa-de-jogo {   display: block;   text-align:center;}
#texto-tentativas {	text-align:center;	color:#84C1C3;	font-family:sans-serif;}
#tentativas {	display:inline;}

Novamente, nada de muito impressionante, apenas alguns detalhes para deixar a página mais “bonitinha”. Olhando em cada elemento, nós podemos ver:

body é a página em si, foi definido só para colocar uma cor de fundo
h1 é o título, definido aqui apenas para definir cor, alinhamento e fonte (ou melhor, a família da fonte mas, enfim)
Esse ‘.carta img:hover’ dita o comportamento de quando o mouse está sobre (hover) uma imagem (elemento img) que esteja aninhado em um elemento da classe ‘carta’. Ou seja, isso será aplicado apenas a imagens desta categoria. Neste caso não faz muita diferença, já que as únicas imagens da página são aquelas do jogo, mas vale pela organização. Esse estilo serve para mudar o cursos do mouse para “pointer”, para indicar que é possível interagir com aquelas cartas.
Nesse caso, em “.carta img” estamos definindo um estilo para as cartas, nesse caso, uma margem de 5 pixels para elas não ficarem “grudadas” umas nas outras.
As duas linhas definindo o estilo de carta e mesa-de-jogo servem para que as cartas fiquem juntas… se você não definir nada, as cartas vão ficar uma em cada linha, o que não ficaria muito bonito :p Inicialmente eu havia usado tabelas para organizar isso, mas assim o código fica mais limpo (a parte de Javascript não tem de se preocupar com essa parte de layout, o que é importante). Ou seja, a mesa de jogo mostra seus elementos “filhos” em um bloco, e as cartas que estão dentro da mesa de jogo estão configuradas para serem mostradas “inline”, ou seja, serem colocadas na mesma linha e não em uma nova linha, como seria padrão em um div.
Bom, o text-tentativas e o tentativas não tem nada de diferente e, novamente, só são usados se você quiser fazer uma linha sob as cartas com o número de tentativas do jogo.

Uma nota sobre # e . : essas são dois marcados, usados tanto no CSS quando para manipular DOM. # serve para ID e . para classe. Não é difícil de imaginar que ID é um identificador único de um elemento na página, não é mesmo? E classe, por outro lado, pode ter vários elementos em uma página. É o caso de #mesa-de-jogo e .carta: só existe uma mesa de jogo, mas varias cartas, daí se usar mesa-de-jogo como ID e carta como classe.

A diferença pode não parecer relevante, mas existem diversas funções que encontram um elemento com um ID, por exemplo, como o document.getElementById(), que vai retornar um único elemento.

E isso encerra a parte de HTML e CSS. Agora, vamos para a parte divertida: Javascript e jQuery!

Javascript e jQuery: montando a lógica do jogo

Então, nós temos um esqueleto em HTML e CSS, mas do jogo nós ainda não temos absolutamente nada, não é mesmo? É aí que entra a parte de JavaScript e jQuery. O código é bastante simples e eu fiquei em dúvida de por onde começar a explicar… até ter a brilhante idéia de começar explicando… por onde eu comecei

(eu tenho umas sacadas geniais, eu sei)

Então, a primeira coisa que eu fiz foi mostrar as cartas na tela ao abrir a página:

$(function (){
	mesa_de_jogo.linhas = 2;
	mesa_de_jogo.colunas = 4;
	for (linha=1;linha<=mesa_de_jogo.linhas;linha++)
	{
		for (coluna=1;coluna<=mesa_de_jogo.colunas;coluna++)
		{
			$("").bind("click",function(){ mudarCarta(this);}).appendTo("#mesa-de-jogo");
		}
		$("#mesa-de-jogo").append("
");

	}
	novoJogo();

});

Por onde começar? Bom, essa função de jQuery, simplesmente $( function () { coisas } ) é carregado assim que o DOM é carregado. Ou seja, esse é, essencialmente, o nosso Main().

Serão colocadas 8 cartas, em duas linhas e quatro colunas, como pode ser visto em mesa_de_jogo.linhas e mesa_de_jogo.colunas. mesa_de_jogo é um objeto que eu criei, apenas para guardar esses dois valores de maneira significativa. Na primeira versão eu usei simplesmente as variáveis linhas e colunas e não faz diferença.

O primeiro for percorre as linhas, e o segundo for percorre as colunas, colocando cada carta na página. O código responsável por adicionar a carta à página é este:

$("
").bind("click",function(){ mudarCarta(this);}).appendTo("#mesa-de-jogo");

A cifra é o “seletor”, a grande ferramente de jQuery: permite que eu faça inúmeras coisas com os objetos do DOM de maneira muito mais prática que usando Javascript puro.

DOM?

Eu suponho que muitos aqui já saibam o que é DOM, mas vamos a uma explicação simples para aqueles que não sabem: trata-se de uma “árvore” de elementos. Uma página HTML é montada como se fosse uma árvore, cujo tronco principal é o “html”, os dois primeiros grandes galhos são “head” e “body” e daí vão se acrescentando mais galhos e folhas a esta árvore. Por exemplo, a árvore deste nosso jogo poderia ser representada assim (só coloquei os ramos referentes à parte de carta e mesa de jogo, para simplificar):

Eu até tentei desenhar como uma árvore, para ficar mais fácil de visualizar Mexer com HTML/CSS/JS basicamente envolve mexer bastante com essa árvore, mexendo nos ramos, adicionando folhas, etc. No caso, com

$("
")

Nós criamos um ramo, com o elemento carta, e que possui uma folha chamada img. Ao colocar isso dentro de $() nós podemos realizar operações sobre esse ramo mais facilmente.

Por exemplo, após a linha acima nós temos a seguinte função:

.bind("click",function(){ mudarCarta(this);})

O que isso faz? Basicamente faz uma conexão com o ramo. Bind funciona com .bind(evento, função). Neste caso, estamos dizendo que ao ocorrer o evento “click” sobre o ramo supracitado deve ser chamada a função mudarCarta(). “this” é passado como parâmetro da função, para que a função saiba qual carta foi clicada.

(Veremos essa função mudarCarta() mais tarde, calma, mas já é possível imaginar o que ela faz, não?).

Ou seja, já temos um ramo “carta”, que possui um evento de clique atrelado a ele. Porém, este ramo AINDA não está na árvore do documento. Ela ainda precisa ser anexada a algum elemento já existente da árvore do documento. No caso, nós queremos anexar esse ramo ao ramo “mesa-de-jogo. e a função .appendTo(elemento) faz isso. Agora, é possível entender totalmente o que faz a linha principal dessa parte do programa, não?

$("
").bind("click",function(){ mudarCarta(this);}).appendTo("#mesa-de-jogo");

Feito isso você irá perceber que por enquanto são apenas elementos… embora exista o elemento img, ele não tem o atributo “src”, ou seja, ele não está ligado a nenhuma imagem. Isso e outras inicializações são feitas na função novoJogo(), que é chamada depois que os dois laços for são executados e todas as cartas já estão na árvore do documento:

function novoJogo(){
	cartaLadoB.sort(function() {return 0.5 - Math.random()});
	$(".carta img").attr("src","images/carta.png");
	pares_restantes = pares;
	tentativas = 0;
	$("#tentativas").text(tentativas);
}

O que essa função faz? Basicamente, quatro coisas:

Embaralha as cartas
Define a imagem do fundo da carta
Diz quantos pares faltam para terminar o jogo
Reseta o número de tentativas

Embaralhando as Cartas

Essa parte de embaralhar as cartas é feita com uma única linha:

cartaLadoB.sort(function() {return 0.5 - Math.random()});

cartaLadoB é um array que eu define com o nome das imagens dos pares. No caso, no início do documento javascript eu a declaro da seguinte forma:

var cartaLadoB =
		["bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png",
		 "bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png"];

A função sort é a responsável por “embaralhar” esse array. Se eu simplesmente chamada cartaLadoB.sort() esse array seria ordenado em ordem alfabética, mas .sort() é uma função de JavaScript MUITO BACANINHA que te permite dizer COMO você quer organizar o array.

Basicamente, você passa uma função que pode retornar < 0, 0 ou > 0, e o sort organiza os elementos de acordo. Se você comparar os elementos a e b e retornar < 0, a função irá definir que a deve vir antes de b, se > 0, b deve vir antes de a, e se for 0 eles são considerados iguais e suas posições não mudam. Sabendo disso, é possível fazer uma infinidade de funções para fazer os mais diferentes tipos de ordenamento (como fazer uma função para ordenar pelo primeiro nome de um objeto Pessoa, por exemplo).

Para fazer um ordenamento aleatório, nós temos a seguinte função: function () { return 0.5 – Math.random() }.

Math.random() retorna um número aleatório entre 0.0 e quase 1 (não chegando a, exatamente, 1). Desta maneira, há uma chance de 50% deste número ser maior do que 0.5 e 50% de ser menor do que 0.5. Ao fazer o retorno de 0.5 – Math.random() há, portanto, uma chance de 50% do resultado ser maior do que 0, e 50% deste número ser menor do que 0. Ou seja, a ordenação de cada dois elementos é definida aleatoriamente, que é o que nós queríamos

Alterando um atributo da carta

Nós já vimos como criar uma “folha” da árvore, mas muito de Javascript não consiste em criar esta folha e colocá-la no documento, mas também modificá-la conforme necessário.

Por exemplo, ao criarmos o elemento “img” nós não definimos seu atributo src, e agora? Para isso, nós podemos alterar atributos de qualquer ramo a qualquer hora, selecionando-o conforme necessário. E melhor, podemos mexer um atributo para todos os elementos de um determinado tipo, se for necessário. Por exemplo:

$(".carta img").attr("src","images/carta.png");

Aqui o que nós estamos selecionando são os elementos img que estejam sob o ramo “carta”. TODOS os elementos, veja que não há nenhuma restrição como first, last ou qualquer outra coisa. Então, nós podemos mexer em todos os elementos de uma só vez. E então nós usamos a função .attr(atributo,valor_do_atributo) para modificar um atributo de todos esses elementos. No caso, nós estamos definindo que o atributo src deve receber o valor “images/carta.png” que é o endereço do fundo da carta.

Aqui cabe uma ressalva: eu recomendo NÃO fazer como eu fiz e colocar esse endereço hardcoded como eu fiz. Crie uma variável e coloque o valor dela conforme for necessário, e use esta variável aqui. É que mais tarde você vai fazer uma comparação com este endereço e eu perdi algum tempo até perceber que o erro que eu estava tendo se devia ao fato de ter colocado um espaço a mais em um dos endereços da imagem. Vivendo e aprendendo :p

Os outras linhas se referem a definir que o número de pares que devem ser encontrados para terminar o jogo é o número total de pares do jogo, e depois se atribui que o número de tentativas é zero, e se atribui esse valor ao ramo “tentativas” da árvore. Pronto, temos um novo jogo.

Exceto que, por enquanto, ele não faz nada além de mostrar algumas cartas bonitinhas na tela. E agora?

A função mudarCarta()

Esta é a função responsável por mudar a carta quando ela é clicada:

function mudarCarta(elemento){
	if ( ($(elemento).find("img").attr("src") == "images/carta.png" ) && (wait == 0))
	{
		$(elemento).find("img").attr("src", "images/" + cartaLadoB[$(".carta").index(elemento)]);
		if (!is_segunda_carta) {
			primeira_carta = elemento;
			is_segunda_carta = true;
		} else {
			segunda_carta = elemento;
			wait = 1;
			setTimeout(verificaPar,700);
		}
	}
}

E aí, deu para perceber o que ela faz?

Elemento é a carta que foi clicada, que é passada como parâmetro desta função. A primeira coisa que é verificada é se é o fundo que está aparecendo, para evitar que alguém fique clicando numa imagem que já foi virada, e também verifica se o jogo não está esperando (wait == 0). Esperando pelo que? Calma, já vamos ver.

Se o jogo não estiver esperando e o jogador tiver clicado numa carta que ainda não foi virada, então é verificado qual a ordem da carta que foi clicada, para alterar para a imagem de acordo com que foi definido no array cartaLadoB. Novamente, vamos analisar esta linha de código com calma:

$(elemento).find("img").attr("src", "images/" + cartaLadoB[$(".carta").index(elemento)]);

Primeiro, nós pegamos o elemento e obtemos sua folha “img”, para então alterar seu atributo src. Ou seja, até $(elemento).find(“img”).attr(“src”, … está tranquilo entender, de acordo com que nós já vimos. É importante notar que .find() também é um seletor, logo, ele irá retornar todos os elementos que estejam de acordo com os parâmetros. No caso, teremos um único elemento img sendo retornado pois cada carta possui um único ramo chamado img.

E a imagem é definida de acordo com o array cartaLado B, de acordo com “images/” + cartaLadoB[$(".carta").index(elemento)]. O índice desejado do array é o índice da carta na lista de cartas da página. Mas como saber isso? Para isso, novamente usaremos seletores: primeiro selecionamos todos os elementos de classe carta com $(“.carta”) e então verificamos, nesta seleção, qual é o índice desse elemento que foi clicado com index(element0). Pronto, temos o índice correto da imagem a ser exibida

Feito isso, temos que verificar se esta foi a primeira carta clicada, ou seja, apenas deixe a carta exposta ali, ou se já é a segunda carta, para verificarmos o par e desvirar as duas cartas se for necessário. Isso é feito com o if (!is_segunda_carta) (que também poderia ser um if (is_primeira_carta), se você preferir :p), sendo que is_segunda_carta é uma variável booleana definida no início do documento javascript como false.

Se for a primeira carta, nós armazenamos esta carta como primeira_carta, para depois fazermos a comparação e, se for o caso, desvirá-la, e então mudamos a variável is_segunda_carta para que a próxima carta verifique o par conforme necessário.

Se já for a segunda carta, nós armazenamos essa carta na variável segunda_carta, definimos que devemos entrar em modo de espera (falei que iria explicar, não falei? :]) e chamamos a função verificaPar depois de 700 milissegundos. A função setTimeout faz justamente isso: chama uma determinada função, depois de um tempo pré-determinado. Algumas observações importantes sobre a função setTimeout, essa função malandra:

você deve passar o NOME da função a ser chamada, e não invocá-la, por isso colocamos verificaPar e não verificaPar(). Se for necessário passar parâmetros, crie uma função anônima ali mesmo, com function() { funcaoQueVoceQuerChamar(parametros,que,voce,quiser);}.
setTimeout não PÁRA o funcionamento ali. Ele joga a função para ser executada depois e continua executando as instruções do código. No caso, eu não coloquei nada depois de setTimeout mas, se existisse algo, esse algo seria executado antes de verificaPar ser executado.

Por causa desse tempo de espera eu criei a tal variável wait – ela está ali só para o jogador não ficar clicando nas cartas nesse tempo de espera. E a função é chamada só depois de 700 milissegundos para dar tempo do jogador ver a carta antes que ela seja desvirada.

A função verificaPar()

Estamos quase acabando, amiguinhos Mas ainda falta o mais importante para o jogo funcionar: ele já vira as cartas, e tudo o mais, mas ainda não consegue verificar se você acertou o par ou não. E é aí que entra a última função desse joguinho, a verificaPar

function verificaPar(){
	is_segunda_carta = false;
	if ( $(segunda_carta).find("img").attr("src") == $(primeira_carta).find("img").attr("src"))
	{
		pares_restantes--;
	} else {
		$(segunda_carta).find("img").attr("src","images/carta.png");
		$(primeira_carta).find("img").attr("src","images/carta.png");
	}
	tentativas++;
	$("#tentativas").text(tentativas);
        wait = 0;
        if (pares_restantes == 0) {
		novoJogo();
	}
}

Eu acho que aqui, mesmo que no início você não soubesse nada de jQuery e Javascript, você já consegue entender o que esse código faz, não?

Mas, claro, como eu gosto de explicar as coisas (sério, eu ainda não sei se é uma coisa boa eu explicar tudo nos mínimos detalhes em todo tutorial… eu tento deixá-los claros e fáceis de ler, estou conseguindo amiguinhos? Ou só estou conseguindo fazer tutoriais enormes? :p), vamos olhar o que esse código está fazendo para não restar nenhuma dúvida.

Primeiro, nós definimos que a próxima carta não será uma segunda carta, isto é, is_segunda_carta volta a ser false. Depois, verificamos se a imagem mostrada na primeira e na segunda cartas são iguais.

Se forem iguais, é um a menos que o jogador deve encontrar.

Se fore diferentes, desvira as duas cartas, isto é, muda a imagem de volta para o fundo da carta.

No caso aumenta-se o número de tentativas e atualiza o número de tentativas mostrado na página no ramo “tentativas”.

Wait é definido como zero, isto é, o jogador pode voltar a clicar nas cartas.

Se não houverem mais pares a serem encontrados, isto é, pares_restantes for igual a zero, o jogo terminou e, portanto, deve-se iniciar um novo jogo.

E, é isso

Só para verificar, eu não cheguei a colocar explicitamente todas as variáveis que eu declarei no início de jogo.js, então aqui vão todas elas:

var pares = 4;
var cartaLadoB =
		["bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png",
		 "bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png"];
var pares_restantes;
var is_segunda_carta = false;
var primeira_carta;
var segunda_carta;
var wait = 0;
var tentativas;
var mesa_de_jogo = new Object;

Lembrando que elas devem ser declaradas no início do documento (…eu acho).

E, bom, é isso, agora vocês tem um super hiper mega incrível demais estupendo fenomenal joguinho de memória, feito por vocês mesmos UAU EIN

Aliás, sacanagem da semana foi eu estar toda empolgada com meu joguinho da memória e o Google me AVACALHAR com o joguinho do Pac-man feito em Javascript. Vou te contar, viu :p

Mas estou com o código salvo aqui (encontrei aqui) e vou estudá-lo com calma… não parece complexo, mas está bastante longo e foram usado algo para diminuir o tamanho do arquivo, acho, e várias variáveis estão com uma única letra como identificador, so, yeah.

Meu primeiro jogo em… JavaScript?

Cindy Dalfovo — Mon, 17 May 2010 14:54:39 +0000

Oi Quem me acompanha no meu twitter já deve ter percebido que eu estava fazendo um joguinho em JavaScript (algumas pessoas até me ajudaram com algumas dúvidas, meus amiguinhos do twitter são demais 8D). Agora eu terminei uma primeira versão e estou oferecendo aqui para vocês testarem.

Conheçam o meu hiper, mega, suuuuper… jogo de memória. Feito em JavaScript. Com gráficos feitos por mim no Inkscape.

A questão é que eu me diverti bastante fazendo esse joguinho, então talvez eu faça mais alguns em JavaScript O legal é que eu fiz ele em um único fim de semana… claro, se eu já conhecesse mais de JavaScript e JQuery eu provavelmente faria bem mais rápido, e se eu não fosse tão enrolada também… (gastei algumas horas escolhendo a IDE e deixando ela mais personalizada para o meu gosto… :p). Mas enfim. Para alguém com TDAH é muito revigorante conseguir terminar alguma coisa, então eu estou bem feliz

Eu vou tentar colocar mais alguns detalhes nele (como número de tentativas e talvez a opção de escolher quantos pares terá o jogo), mas o jogo em si está pronto e vocês podem testá-lo aqui ou clicando na imagem acima.

Eu vou fazer um post explicando como eu fiz o jogo, para aqueles que também tiverem algum interesse em jogos feitos em Javascript/jQuery, mas estou colocando o jogo para vocês jogarem e me avisarem se ainda tem algum bug e tal e se tiverem alguma dúvida, que aí eu já lembro de explicar no tutorial. De qualquer maneira, vocês já podem fuçar no jogo se quiserem, já que o código está disponível e você pode até mexer nele se tiver alguma ferramente de desenvolvimento web no seu browser.

(E sim, estou numa segunda-feira bem feliz por conta disso :] )

[Quick] Durante o tutorial de emacs…

Cindy Dalfovo — Wed, 28 Apr 2010 23:33:28 +0000

Li tanto que era interessante editar programas Lisp no emacs que eu resolvi tentar usá-lo.

Atualmente estou no tutorial de comandos, e tentando encontrar lógicas nos atalhos.

Mas estão tentando me enganar com o comando de colar.

Como assim, é Ctrl+y por que o nome do comando é… yank? Yank? YAAANK?

Imagino o diálogo.

- Ah, esqueci um comando importante!

- Qual?

- O Paste!

- Simples, use o Ctrl+p…

- Não dá, cara, não dá!

-Ctrl-i para Insert?

- Não cara, esse já foi!

- Ctrl-d, para down, colocar para baixo o que tá na pilha do copy…

- Não, não, esse também já foi!

- … ô merda. Coloca Ctrl-y então.

- Ctrl-y? Mas o que diabos começa com y?

-… * e depois de alguns segundos de reflexão * Yank?

- Isso, fechou! Valeu!

Because, really.

20 Anos Depois, Ainda Não Entendemos Reusabilidade

Cindy Dalfovo — Fri, 23 Apr 2010 21:50:56 +0000

Eu tenho uma relação de amor e ódio com programação, e não estou exagerando: são poucas as coisas que me fazem ficar tanto tempo lendo um único texto, e também são poucas as coisas que já me fizeram passar tanta raiva e dizer “não, porra, não vou mais fazer isso”.

O que eu demorei a perceber, e só estou realmente aprendendo agora, é que na verdade existe uma parte da área de programação que eu amo, sou apaixonada. É a parte com a qual eu sempre sonhei trabalhar. Francamente? Eu acho que é a parte com a qual todos da área sempre sonharam em trabalhar.

É aquela parte na qual você tem de pensar, planejar o que irá fazer para criar uma solução elegante, boa e compreensível. Escrever um belo algoritmo e testá-lo. Juntar as peças de maneira lógica.

Eu me lembro de quando estava aprendendo a programar, em Pascal, no ensino técnico – a felicidade que eu sentia em pensar em maneiras de calcular as simples coisas que eram pedidas. Aquele sentimento de triunfo ao fazer seu primeiro algoritmo com recurso – que deve ter sido algo como calcular fatorial, já que este é um exemplo clássico de recursão.

Pensei “poxa, isso é realmente legal, será legal trabalhar com isso”.

Desilusões

Aí eu comecei a trabalhar, numa grande empresa de softwares de ERP para empresas – gerir informações de empresas, gerar folhas de relatório, de pagamentos… essas coisas. Mas aquilo… aquilo não era a programação. Programação para mim era planejamento, lógica – algo como, se a matemática diz “o que é”, a programação diz “como fazer”.

Não, não era aquilo que eu estava fazendo. Eu havia me tornado uma “code monkey”. O ponto mais baixo foi o dia no qual me falaram para abrir um documento, procurar ocorrências de uma string e substitui-la por outra.

Sério, leia a frase anterior de novo e me diga se você não morreu um pouquinho por dentro. A argumentação foi que eu deveria me acostumar com o fluxo de trabalho, como ler chamadas, realizá-las e fechá-las. Burocracia, enfim.

Eu pensei que fosse um caso isolado. Afinal, eu era recém-contratada, tinham me transferido para lá. Pensei que o problema fosse comigo, que talvez eu não gostasse de trabalhar com programação.

Mas, no fundo, eu ainda gostava da parte lógica, e a maneira que eu encontrei de tentar seguir essa parte foi fazer Engenharia de Controle e Automação. Afinal, juntava Informática com coisas como Eletrônica e Mecânica, então com um pouco de sorte eu nunca mais teria de ver um ERP na minha frente.

Avance alguns anos. Eu descobri que, francamente, não curto interação com Hardware.

Mas, pensando agora, talvez o meu problema não fosse com o Hardware, mas com o estado dele – era frustrante construir um mero circuito digital e ter de adivinhar se ele não estava funcionando por problemas do projeto ou se porque algum dos componentes estava queimado.

Comecei a fazer um projeto em Java e, por um tempo, as coisas até que fluiram. Entrei em um outro projeto e as coisas começaram a decair. Não que o projeto fosse ruim, longe disso, mas é que eu me vi tendo de aprender estranhas e místicas bibliotecas para fazer meu trabalho, e eu acabava passando a maior parte do meu tempo não mais tentando encontrar um bom algoritmo para resolver o meu problema, mas tentando descobrir porque diabos aquela biblioteca não estava fazendo o que eu queria.

Eu achava que isso se devia à minha inexperiência – afinal, eu era uma programadora iniciante, e havia uma série de conceitos com as quais eu não estava perfeitamente familiarizada.

Esse ano algumas coisas aconteceram e me fizeram rever minha posição – talvez o problema não esteja APENAS comigo.

Reusabilidade Do Que?

Eu pensava OK, eu tenho apenas uns conceitos básicos sobre Spring/Struts, deve ser por isso que minha aplicação vive quebrando. Eu já fiz alguns programas com Hibernate, mas agora isso não está funcionando e…

Vocês já programaram com alguma dessas bibliotecas/frameworks? Elas foram criadas para facilitar o seu trabalho, para manter um código mais claro e fácil de manter.

Fácil de manter se você fizer todos os místicos procedimentos de geração, de manutenção, de modificação, escondidos em cerca de vinte arquivos e definidos nas páginas 700 a 735 do Pequeno Manual do Desenvolver daquela framework. Tudo funciona muito bem, até você dar um passo em falso – e por passo em falso eu digo, mudar um parâmetro em um dos vinte arquivos de configuração, um método ali, ou até mesmo a ordem que você resolveu compilar/gerar seu código. E, quando você dá esse passo em falso, você sabe o que acontece?

Meu amigo, A SUA APLICAÇÃO VAI PARA O INFERNO.

Já aconteceu de eu olhar ara uma aplicação que não está funcionando e ficar me perguntando qual parâmetro estava errado. Às vezes era uma linha, uma mísera linha escondida no fundo de um dos milhares de arquivos daquela aplicação. Eu acabei fazendo o escambau naquela aplicação porque eu não conseguia entender como fazer uma pequena modificação em um dos módulos. Era uma modificação pequena, que não deveria ter levado tanto tempo para ser feito. Boa parte do tempo eu gastei me estressando, lendo e relendo documentação, wiki e tentando entender o que eu estava fazendo de errado.

Só agora eu começo a pensar que talvez eles estivessem errados. Eu queria fazer uma coisa simples, porque estava sendo tão difícil?

Ao mesmo tempo, porque ERP ainda são tão complicados? Eu entendo que eles sejam complexos, mas há quantos anos eles são desenvolvidos? Não deveria ser algo mais simples de manter hoje em dia? Certamente depois de um tempo 90~95% das funcionalidades de um ERP deveriam ser bem conhecidas e triviais, não?

Digo o mesmo sobre base de dados: quantos milhares de programas não envolvem alguma variação de manipulação de dados? Veja os dados, insira novos dados, delete dados, eventualmente visualize um relatório. A complexidade deveria estar toda em definir um bom modelo dos dados, não? E realizar alguns eventuais ajustes. Ainda assim, por isso ainda é tão complicado de ser feito? Por que algo que se tornou tão trivial ainda possui implementações tão… não-triviais?

Você pode argumentar, poxa, até em Java isso é rápido, se você for no Netbeans, você cria visualizações simples a partir de uma base de dados em questão de cinco minutos… com gerados de códigos.

Sim, claro, ao invés de fazer você mesmo o trabalho sujo, você manda a IDE fazer a porquice por você. E adivinha quem vai ter de fazer as modificações e dar manutenção no código depois? Não será a IDE, eu garanto.

Ah, a IDE tem várias ferramentas de teste, eu é que sou burra de não ter aprendido a usar isso tão bem quanto deveria.

Claro, ao invés de você mesmo sair cutucando o programa em “tentativa e erro”, mande a IDE fazer isso por você.

Gente, isso não são soluções. São bandaids criados para esconder um problema maior: a maioria das bibliotecas é uma droga. Prova disso é a quantidade de geradores de código que acompanham as IDEs mais modernas: é claro que existem certas tarefas um tanto quanto repetitivas, mas certamente criar uma aplicação base não deveria ser algo tão enrolado?

Certamente o que nós queríamos com reusabilidade não era “ah, eu escrevi 100 linhas e o IDE escreveu 1000″, ou “aprenda essas trocentas bibliotecas para fazer um belo Hello World”?

O Inferno Está Cheio de…

É claro que a idéia por trás de uma solução como Hibernate é interessante. Eu já desenvolvi um pequeno projeto com Hibernate e, tendo trabalhado com SQL puro antes, é difícil não reconhecer as vantages que uma solução como essa trouxe. Até certo ponto, quando eu falo que a maioria das bibliotecas é uma droga, não estou me referindo a algo como Hibernate (até porque Hibernate é uma framework, mas, enfim).

OK, certamente muitas bibliotecas/frameworks resolvem muitos problemas, e muitas delas representaram em bons ganhos de produtividade. Sob esse ponto de vista, nossa, as bibliotecas/frameworks são excelentes.

O maior problema é… bom, um dos maiores problemas é a gestão de complexidade. E o pior: na maior parte das vezes, existem boas técnicas para ajudar na gestão de complexidade, algumas conhecidas há mais de 20 anos, mas que muitos desenvolvedores insistem em ignorar!

Digamos que você tenha uma linguagem bem simples, na qual você queira criar… um círculo. Então você cria uma simples lista, criada assim, por exemplo:

c = Círculo(x,y,raio)

E pronto, c é o nosso círculo, com coordenadas e um raio. Simples, não? Aí você pensa “sou um gênio, vou transformar isso numa biblioteca” (para fins de exposição, imaginem que foi criado algo um pouco mais complexo).

E, poxa, é tão simples, não é mesmo? Três simples parâmetros, e você tem um círculo, será um sucesso.

Aí o fulano vai usar sua biblioteca e pensa “poxa, legal, vou criar um círculo”:

c = Círculo(raio)

Afinal, ele só quer definir um círculo, sem se importar com a sua posição. Esse exemplo pode parecer ridículo, mas vocês não imaginam quantas bibliotecas são EXTREMAMENTE RIGÍDAS (ou, infelizmente, imaginam por já terem se deparado com bibliotecas assim…). Mesmo em um caso assim, no qual os parâmetros x e y poderiam ser considerados opcionais, restando apenas o parâmetro obrigatório raio. Ou ainda, poderia ser possível criar um Círculo sem parâmetro algum, para alterar seus parâmetros mais tarde. Parece tão simples, e pode ser uma solução perfeitamente lógica para o desenvolvedor da outra aplicação, mas ele terá de fazer algum malabarismo como

c = Círculo (0,0,10)

Ao invés de

c = Círculo (10)

Simplesmente porque a biblioteca o obrigava a usar todos os parâmetros, mesmo quando isso não fazia sentido. Claro, nós estamos falando de algo simples como um círculo, e qualquer um que olhe para Círculo(0,0,10) poderá imaginar que se trata de um círculo de raio 10 na origem, mas na maior parte dos casos práticos não é algo tão óbvio.

É basicamente pegar toda a liberdade que uma linguagem de programação te dá e resolver limitá-la para funcionar apenas da maneira que os desenvolvedores da biblioteca imaginaram. Olhando por esse lado, eu nem sei como tantos militantes do software livre, da liberdade, podem aceitar certas frameworks e bibliotecas com tanto orgulho.

E, até certo ponto, isso não é tão surpreendente. Existem cadeiras em Ciências da Computação sobre como escrever boas bibliotecas? Eu imagino que existam bons livros, mas eles não costumam ser citados. Eu costumo ler sobre programação das mais diversas fontes, e diversos dos meus amigos são programadores, mas eu não costumo ler um artigo sobre a mais recente técnica para desenvolver uma boa biblioteca, e nem meus amigos costumam falar sobre o excelente livro de Desenvolvimento Avançado de Biblioteca que eles leram.

Então eu tenho motivos para desconfiar que as pessoas que estão desenvolvendo essas ferramentas também não tem um conhecimento tão aprofundado sobre desenvolvimento de bibliotecas quanto deveriam ter.

Biblioteca = Reusabilidade, só?

Eu imagino que deve ter gente pensando “O que ela está falando? Que coisa idiota, é claro que se ensina a escrever bibliotecas, só que sem esse nome – se ensina reusabilidade, orientação a objetos com fraco acoplamento…”

Sou obrigada a discordar. Tudo isso é NECESSÁRIO para escrever uma biblioteca – afinal, uma biblioteca deve ser um bom software antes de mais nada, certo?

Mas não é SUFICIENTE.

Digamos que você tenha escrito a sua biblioteca círculo para uso interno na sua empresa, e tudo funciona muito bem porque ela se aplica exatamente ao que você deseja.

E você a libera, mesmo com aquelas limitações, chamando-as de boas práticas.

Sabe o que é uma boa prática? Consistência. E pode ser um pouco difícil ter consistência se você estiver usando diversas bibliotecas, e cada uma te obrigando a seguir o que ela considera “boas práticas”.

Além disso, muitas bibliotecas e frameworks são terríveis no quesito gestão de complexidade. Você acaba tendo a impressão de que quem usa a biblioteca deve seguir a mesma escola de pensamento que o desenvolvedor, e deve ter um conhecimento tão profundo quanto o desenvolvedor se quiser fazer algo que fuja um pouco do escopo pretendido.

Sabe porque as bibliotecas incluídas na maior parte das linguagens não costuma ter esse tipo de problema? Uma das razões é que elas são escritas por pessoas realmente experientes, e a outra é que elas possuem funções mínimas e bem delineadas. Uma função vai fazer uma coisa, e você irá utilizá-la para ela fazer exatamente o que você precisa. Ao contrário de muitas bibliotecas e frameworks megalomanícos que querem funções para fazer tudo de uma vez e AI de você se quiser algo diferente.

Existem técnicas que ajudam nesse processo? Existem, inúmeras! Fraco acoplamento, Lei de Demeter, Don’t Repeat Youself… só para citar algumas que eu vi nos últimos dias.

Mas, francamente, porque desenvolver software tem se tornado tão complicado? Existem centenas de razões para isso, algumas que mal cheguei a citar nesse artigo (como as fábricas de software e seus macacos, que simplesmente acham que desenvolver software é juntar um monte de coisas e tentar juntá-las até ter algo que pode ser apresentado ao cliente) mas que costumam ser citadas na maior parte dos artigos. Eu quis atacar um pouco o outro lado hoje, o fato de que poderiamos não apenas ter culpados do lado do usuário, mas também dos desenvolvedores – que práticas hoje tão bem aceitas talvez não sejam tão eficientes quanto deveriam.

Mas claro, esses são apenas os devaneios de uma jovem programadora, e eu deveria até me desculpar por ter escrito um devaneio tão longo, mas eu precisava dizer essas coisas. Quem sabe vocês também não se sintam assim, não é mesmo? Eu mesma acabei decidindo escrever esse post depois de ler o artigo “Whatever Happned to Programming?” com quase o mesmo sentimento, mas de alguém muito mais experiente do que eu.

Então eu talvez não seja a única, e é isso o que me dá esperança de voltar a trabalhar na área de programação.

Mas antes disso, muito estudo O Dive Into Python e o SICP não se lerão sozinhos…

Todo Software Tem Seu Preço

Cindy Dalfovo — Wed, 18 Mar 2009 02:56:32 +0000

Não existe algo como um software completamente "gratuito". Chama-se de gratuito aquele programa que não cobra de seu usuário final nenhum tipo de taxa, mas é óbvio que ele possui custos – para seus desenvolvedores, que gastaram tempo nele e, em alguns casos, para a empresa que financia o projeto. Algumas vezes temos – e mais comumente em projetos web – projetos "freemium", que não cobram nada por funcionalidades básicas e se sustentam pelos "add-ons", suporte especial, etc.

Até aqui, digo apenas o óbvio – mas o óbvio que é muitas vezes esquecido e distorcido nas mais diversas matérias sobre "software livre". Digo isso apenas para levá-los ao próximo passo: software livre não é o comunismo do mundo dos computadores. Não é o nivelamento através do "todos devem ter o que todos podem ter". HÁ uma ideologia, uma filosofia, muito forte na comunidade do software livre, e que é interpretada das mais diversas maneiras por diferentes grupos. Assim como existe uma ideologia muito forte no mundo do software fechado, mas que não chama tanto a atenção por não ser tão utópica.

Não é apenas o "software livre", mas todo o movimento que vem ganhando força no campo do software: é a democracia do software. Software livre implica em liberdade de escolha, de modificações. Os adeptos do software livre adoram falar em liberdade, mas muitas vezes se esquecem que essa liberdade pode implicar em uma escolha diferente da sua – uma pessoa que escolhe Windows pode ser tão livre quanto uma que escolhe Linux. A diferença está na consciência da escolha: enquanto as pessoas usarem Windows simplesmente porque é o que veio na máquina, a única liberdade que elas estarão usando é a de se acomodarem no mais simples.

O que as pessoas ignoram – ou escolhem ignorar – quando travam infindáveis argumentos de "software de código fechado é ruim!", "windows é melhor que linux!" e etc, é que nenhuma dessas questões é tão relevante quanto a democracia propiciada pelo software livre. E nem só pelo software livre, mas por softwares gratuitos, de baixo custo, pelo software "on the cloud".

Há cerca de 20 anos, software era algo caro, e com pouquissimas opções de escolha. Muitos necessidades não eram atendidas por mais do que meia dúzia – ou nem isso – de programas. Nenhum deles se adapta? São muito caros para o seu orçamento? Azar o seu, porque você simplesmente não tinha opções.

Por que eu uso Linux? Ah, é que o Tux é tão fofinho, poxa…

Recentemente o Meiobit postou sobre uma comparação de perfomance entre o Photoshop e o Gimp – na realidade, era mais uma comparação do Photoshop em diversas super-máquinas, e eles aproveitaram para testar o Gimp também – e na qual o Gimp perdeu. E digo não apenas perdeu no sentido de "nesse mês o Nintendo DS vendeu menos do que o PSP", mas no sentido de que "o WonderSwam vendeu menos em toda a sua vida do que o Game Boy Advance vendeu em um mês". E, sinceramente, alguém se surpreendeu com isso? Sim, o software livre vem avançando bastante, e em algumas áreas já possui competidores que estão no topo do podium, como no caso clássico do Firefox. Mas nós estamos falando do Adobe Photoshop, que custa cerca de 700 dólares sozinho ou 1700 dólares em um pacote com outros softwares da Adobe. Eles não cobram tudo isso apenas pelo nome bacana, mas por conta de toda uma equipe muito bem paga que trabalha para melhorar continuamente seus programas – e eles não podem parar, porque se eles não lançarem mais atualizações, bom, como eles irão arrecadar fundos, não é mesmo?

O que eu não entendo é que a partir disso se estenda uma guerra sagrada – de um lado, os defensores do Gimp, que se recusam a aceitar que o Gimp não, não está no mesmo nível do Photoshop, e do outro lado, os anti-software-livre, "meu deus, é grátis, deve ser ruim…".

Softwares livres como o Gimp, ou mesmo alternativas web de editores de imagens não tem a pretensão de desbancar o Photoshop. A questão é… não faz muitos anos que a ÚNICA opção existente era o Photoshop. Que outro programa de edição de imagens você conhecia? O Paint? E então existiam os profissionais da área, que possuem máquinas super-poderoas e múltiplos monitores de muitas polegadas e que pagavam os 700 dólares de um Photoshop… e existiam os seus priminhos, aquela tia que trabalha com imagens, aquele seu amigo que queria editar uma foto da formatura… que usavam cópias pirateadas do Photoshop. Ou que pagavam os olhos do cara para alguém abrir um arquivo no Photoshop e fazer meia dúzia de modificações simples.

Agora essas pessoas tem a opção de um programa leve, gratuito, e que pode fazer muitas das coisas que antes eram feitas apenas no Photoshop. Eu já usei Photoshop pirata e atualmente uso o Gimp. Não sinto falta de nada do Photoshop no Gimp – claro, sou uma usuária "banana" nessa área, sou completamente incapaz de entender metade das opções disponíveis nesses programas. Mas eu consigo redimensionar, balancear cores e contraste, e fazer algumas montagens simples usando camadas e efeitos de camadas. Para mim, e muitos dos usuários comuns, o Gimp é plenamente suficiente.

Outro exemplo? O BrOffice em relação ao Microsoft Office. Sempre tiveram muito mais opções do que eu jamais irei usar, ambos os programas. Uso o BrOffice e nunca, nunca pensei "ah, isso tem no MS Office e não tem aqui", mesmo tendo usado o MS Office por mais de 10 anos. A mesma comparação vale para o Inkscape x Illustrator, Thunderbird x Outlook.

É claro que você pode decidir pagar 700 dólares no Photoshop se irá usá-lo profissionalmente, ou comprar o pacote Office da Microsoft se ele tiver algo que os outros não possuam, ou pagar a licença do Windows se os programas da sua empresa rodarem apenas em Windows, por exemplo (se bem que, nesse caso, dava para tentar testar com o Wine, não é mesmo?), assim como pode escolher comprar o Maya ao invés de baixar o Blender, e comprar o Adobe Premire Pro ao invés de… ao invés de tentar descobrir alguma alternativa gratuita viável para edição de vídeo (ainda não conheço nenhuma, adoraria que o cinelerra fosse menos zoado, poderia ser uma opção interessante). Mas, aí está a diferença: é uma opção, e não uma imposição feita pela pura falta de escolha.

Você quer um sistema operacional? Você pode pagar pelo Windows, pode pagar por um servidor Red Hat ou Solaris, ou pode usar uma distribuição gratuita, como o Ubuntu, OpenSUSE, Slackware e OpenSolaris.

Você tem uma necessidade especifica X? Você pode procurar em sites como o Freshmeat e ver se existe algum que se adapte ao que você precise.

A democracia vem não apenas pelo código aberto, mas também pela gratuidade de muitos programas, que possibilitam o acesso a certas funções para pessoas que não teriam como pagar uma licença na casa das centenas de dólares, e também pelos programas que hoje em dia são encontrados nas "nuvens": você pode editar documentos com o Google, pode editar algumas imagens, pode até mesmo programar uma aplicação deixando toda a preocupação com processamento para o servidor. Isso possibilita que pessoas que não podem baixar arquivos ou que não possuem boas máquinas em termos de RAM, processamento ou HD, que usufruam de certas coisas.

Internet e democracia devem andar juntas: ontem a divulgação de informações era quase que totalmente restrita aos grandes meios, hoje muitas informações "quentes" podem ser encontradas nos mais diversos blogs. Isso não quer dizer que a grande mídia vá sumir, ou que ela seja maligna – embora em certos casos ela seja -, mas que hoje em dia é possível escolher da onde você quer suas informações. Quem você quer ouvir, quando, e como. Você pode encontrar um blog que transmita notícias de um jeito mais despojado e mais alinhado com o seu jeito de pensar, o que talvez fosse inconcebível na grande mídia, onde tudo ser pensando "na maioria", porque a minoria não dá dinheiro.

Mas democracia não é sinônimo de "grátis", ou "sem esforços". Muitos pseudo-adeptos-do-software-livre o são apenas por adorarem poder baixar programas gratuitos sem sentirem qualquer peso na consciência. Algumas pessoas tratam o software livre como tratam software pirateado – como algo legal para se baixar rápido, sem esforços, e sem preocupação. Alguns chegam a chiar se algum "software livre" é pago.

Se lançassem um "Gimp Pro", com muitas melhores e com uma interface muito melhor planejada, por 100 dólares, quantos comprariam? Por melhor que esse programa estivesse? Poucos parariam para pensar que esses 100 dólares estariam sendo usados para organizar uma equipe bem coordenada e fazer um desenvolvimento de software completo, com maiores investimentos nas partes de usabilidade e perfomance. Não. A maioria pensaria "porcos malditos, ficaram gananciosos, eu não pago pelo Firefox, porque iria pagar pelo Gimp"?

Mas alguém paga pelo Firefox. Alguém paga pelo Ubuntu. E são os softwares que mais possuem investimento por trás que costumam se destacar – claro, softwares não se fazem sozinhos, e nem sempre você vai conseguir que um programador vire noites atrás de uma solução ótima para um problema de perfomance no programa… de graça. Já não são tantas pessoas dispostas a fazer trabalho voluntário, e menos pessoas ainda estão dispostas a se sacrificarem por causa desse trabalho voluntário. E sem receber nada em troca, porque muitas vezes o reconhecimento dessas pessoas é ínfimo.

Então, lembrem-se: não existe software de graça. Não se concentre nessa palavrinha maldita na próxima vez em que você pensar nas razões pelas quais software livre é legal. OK, você pode baixar de graça, mas se lembre que alguém gastou algo para fazê-lo, em termos de dinheiro e de tempo. Se você achou um projeto underground que te quebrou um tremendo galho, porque não mandar um e-mail para o desenvolvedor? Fazer um tutorial? Ajudar na documentação? Divulgar para seus conhecidos?

Pensem nisso.

Um Novo Blog: Geek Cor de Rosa

Cindy Dalfovo — Tue, 17 Feb 2009 02:08:02 +0000

Uma coisa que muitos que lêem esse blog não sabem é que, recentemente, eu me terminei uma embaixadora de campus da Sun. O que quer dizer que eu sou paga para divulgar coisas que eu costumo divulgar de graça, como o uso do Netbeans e Java. Niiiice.

Aliás, uma das minhas funções é, justamente, escrever sobre tecnologias Sun (Java, Netbeans, MySql, servidores, Sun Spots…) no blog. Eu pensei em fazer isso aqui mesmo, afinal, eu já escrevi inúmeros artigos sobre desenvolvimento aqui, não é mesmo? Mas, depois de pensar bem, achei que fazer um blog em blogs.sun.com seria melhor para fazer algo mais "focado".

Então, de agora em diante, vocês tem um novo blog para acompanhar, caso curtam meus textos e gostem de desenvolvimento e de novas tecnologias: o Geek Cor de Rosa. Sim, eu sou SENSACIONAL para dar nomes às coisas.

De qualquer maneira, esperem ver meus diários como embaixadora por lá, participando dos treinamentos, dando palestras, escrevendo tutoriais e artigos sobre Java, JavaFX, Netbeans, Open Solaris, mySql, etc.

Enfim, é isso. Eu estou com três projetos e estou cheia de matérias nesse novo semestre, então, não estranhem se eu demorar para atualizar o blog. Ou parecer extremamente estressada.

[Tutorial] Aprendendo a Mexer com o Sun SPOTS

Cindy Dalfovo — Sun, 11 Jan 2009 16:28:54 +0000

Eu sempre preferi a parte de software do que a de hardware – eu me lembro de realmente FUGIR das aulas sobre hardware no meu curso técnico, e sempre que tenho algum problema com hardware eu costumo pedir socorro ao meu namorado. Além dele entender mais disso do que eu, ele tem o mesmo efeito do Gizmo nesta tirinha do Recruta Zero:

Além disso, eu sempre preferi a praticidade da programação: é muito mais fácil aprender a programar do que aprender a mexer com hardware, já que tudo o que você precisa está ao alcance dos seus dedos: existem milhões de tutoriais de programação na rede, e não é muito difícil baixar IDEs e testar seus recém-feitos programas.

Mexer com hardware, por outro lado, envolve coisas misteriosas como comprar placas, ter de aprender a mexer com Assembly (ou com C, na melhor das hipóteses), montar redes místicas e torcer para nada queimar… e eu nem mencionei em tentar colocar periféricos extras e mais interessantes do que… LEDs.

Atualmente, existem algumas alternativas para quem quer mexer com um hardware mais interessante e de maneira não tão complicada – uma que eu posso mencionar que eu já usei é o kit de Lego Mindstorms – você pode criar bonecos em legos, colocar sensores de luz, de pressão, colocar motores, e programar tudo isso a partir de uma programação em blocos simples (mas limitada) provida pela kit, ou programar em C e passar o programa através de infravermelho para o robô feito de Lego.

Bom, o resultado do meu grupo quando nós tivemos de fazer um projeto com isso na faculdade foi esse:

Lindo, né? Trata-se de um pequeno veículo para levar e trazer peças em um chão de fábrica. Nada funcionou como a gente esperava na hora que a gente precisava, mas tudo bem…

O problema desse tipo de solução é que eles ainda são muito caros – especialmente aqui no Brasil. Um kit do Mindstorms mais recentes (e mais bacana) custa cerca de 1000 reais aqui no Brasil. Não é exatamente algo que você pense "ah, ok, vou comprar um para ver como é…". Mas é o tipo de coisa que eu gostaria de dar para um filho, se ele se interessasse e eu tivesse condições. Ein, meu filho será filho de dois engenheiros nerds, vocês tem ALGUMA dúvida de que ele será criado como uma criança tr00 nerd?

Devaneios maternais de lado, outra solução é o Bug Labs, que oferece um kit básico e "apetrechos" extras para você fazer coisas mais interessantes, como uma câmera de 2MP, GPS, uma base para você conectar apetrechos via USB, sensor de movimento, acelerômetro… o problema, novamente, é o preço: 250 dólares pela base, e de 50 a 80 dólares pelos módulos extras. Mas ele traz uma SDK para ajudar no desenvolvimento, e é open-source.

A outra opção que eu conheço e sobre a qual eu vou falar é a solução da Sun, o Sun SPOTS. Basicamente, são pequenos hardwares que você pode programar em Java, já que ele roda uma máquina virtual. Conta com acelerômetros, sensores de luz, botões analógicos e digitais, etc.

Nota rápida: Ao procurar por Sun Spots no Google, encontrei uma notícia com essa headline: "Sun goes longer than normal without producing sunspots" e cliquei, já preocupada em estar interessada em uma tecnologia que poderia estar dando sinais de cansaço.

Bom, não era bem esse o caso, como você pode conferir olhando a matéria…

Nisso que dá uma empresa chamada Sun criar uma tecnologia chamada Sun SPOTS…

Como existem muitos gamers que lêem esse blog, eu acho que uma boa motivação seria mostrar esse vídeo do Sun Sposts sendo usado para criar um controle diferente para jogar Counter Strike:

Legal, ein? Novamente, os preços são um problema: 750 dólares pela base e seus apetrechos. Existe um desconto promocional para estudantes americanos, para 300 dólares. Há algum tempo, porém, eles estavam dando kits para estudantes que apresentassem propostas interessantes de uso – um amigo meu conseguiu um kit assim. Atualmente essa promoção não está mais valendo, mas mesmo assim eu tenho chances de conseguir um kit (o que é um assunto para outro post).

Para isso, claro, eu preciso fazer uma proposta interessante de uso do Sun SPOTS. E para poder fazer isso, eu preciso conhecê-lo melhor, para saber do que esse danado é capaz.

E eu posso fazer isso não apenas lendo o site, mas efetivamente programando e testando no Sun Spots! Não em um de verdade, claro, mas em um emulador fornecido pela Sun.

Como eu adoro criar tutoriais, eu vou tentar relatar o que eu estiver aprendendo por aqui. Se alguém tiver MUITO interesse, entre em contato com uma proposta de uso. Eu não posso fazer muita coisa para conseguir kits, mas eu posso mostrar sua proposta para alguém que possa. :p

Instalando o Emulador

Primeiramente, você deve ter o Sun Java JRE. Se você já programa em Java, você já tem o que é necessário, então não se preocupe. Instruções mais específicas podem ser encontradas aqui, de acordo com o sistema operacional que você usa.

Tendo os runtimes necessários, tudo o que você precisa fazer é ir na página do Sun Spot Manager e baixar o aplicativo.

Execute-o com o Sun Java WebStart (seu sistema provavelmente irá conhecer a extensão e mandar abrir com esse programa, de qualquer maneira), leia aquilo tudo (eu tenho certeza de que você vai fazer isso…), desça a barra de rolagem até o final, clique em próximo, próximo… se quiser, crie um atalho para o Sun Spot Manager no seu desktop, facilita quando você quiser acessá-lo depois.

Ele vai verificar se você tem o Netbeans. Se você ainda não tiver, instale-o quando sugerido, assim como o Ant. Isso facilita bastante na hora de desenvolver, acredite.

Além disso, não há muito segredo na hora de instalar – ele irá verificar os requisitos do seu sistema, sugerir instalar alguma coisa que não encontre… se você ler pelo menos o mínimo (sabe, aquelas mensagens que costumam aparecer com pontos de exclamação do lado), você não deve encontrar problemas aqui. Mas se encontrar algum, poste nos comentários que eu tento ajudar, claro.

Se você fez tudo certo, dê um duplo clique no atalho que está na sua área de trabalho e ele irá abrir o Sun SPOT Manager na aba de tutoriais. A parte que mais nos interessa é o Solarium:

É aqui que nós temos acesso ao emulador do Sun SPOT – clicar no pequeno botão escrito "Solarium" no canto inferior direito irá abrir o espaço do emulador (e também da onde você visualiza os Sun SPOTs reais que você tiver conectado ao seu PC).

Ao ir no menu "emulator" e selecionar a opção "new virtual spot", você irá ver a imagem de um pequeno spot na sua tela:

Pronto, esse é o emulador. Ao clicar com o botão direito sobre o Virtual SPOT você vai ver a opção "deploy MIDlet bundle", que é onde você irá selecionar o programa que você fez para testar no SPOT… o que nos leva, claro, ao passo seguinte: como fazer um programa para o SPOT?

Desenvolvendo para Sun SPOT no NetBeans

Se você instalou o Netbeans junto do Sun SPOT Manager, você já deve ter os plugins necessários. Mas como esse não é o caso de muitas pessoas, vamos ver como instalar os plugins necessários. Em primeiro lugar, você deve fazer o download do plugin que irá adicionar um novo Update Center ao NetBeans.

Para instalar esse plugin, abra o Netbeans e vá no menu "Ferramentas" -> Plug-ins.

Na aba "baixados", selecione "adicionar plug-ins" e escolha o plugin que você acabou de baixar. Depois de instalá-lo, vá em plug-ins disponíveis e recarregue o catálogo. Instale os plugins da categoria SunSPOT que irão surgir:

Depois disso, crie um novo projeto na categoria "Java", do tipo Sun SPOT Application:

Você vai ver que ele já cria uma classe padrão, a StartApplication.java, que tem todos os "imports" e inicializações necessárias para fazer seu Spot funcionar – na realidade, este já é um programa que você pode testar no seu emulador. Não que ele seja muito úteil – ele se resume a ficar piscando um led enquanto você não abertar um botão.

O código para isso se encontra no método startApp():

A primeira linha usa um método para recuperar o Switch 1, o primeiro led é colocado em um cor ligeiramente vermelha na segunda linha e então inicia-se um laço que é executado enquanto o Switch 1 estiver "aberto" (um switch fecha um circuito quando está pressionado, por isso a expressão "open", já que quando ele não está pressionado ele deixa um circuito aberto): Liga o led, espera um um quarto de segundo, desliga o led, espera um segundo e reinicia o processo.

Quando o switch é pressionado, o programa sai do laço e o notifyDestroyed serve para dizer que o programa foi encerrado (o que chama o destroyApp, que não faz nada além de se certificar de que todos os leds estão apagados neste caso).

Para construir o programa e testá-lo, você deve construi-lo, clicando com o botão direito sobre o projeto e selecionando "construir". Isso irá gerar um jar na pasta "suite" do seu projeto.

Agora, só falta a parte mais divertida: finalmente testar seu projeto "Hello, world!".

Testando o Projeto no Emulador

Lembram-se de que eu falei lá em cima que iríamos testar o aplicativo no Solarium? Volte para o Solarium, onde você criou o Virtual Spot, clique com o botão direito sobre ele, em "deploy MIDlet bundle" e então selecione o jar que você criou.

Para testar, clique com o botão direito sobre o SPOT, "Run MIDlet" -> "StartApplication". Pronto, você terá seu super-bacanérrimo… SPOT que pisca o LED!

Se você clicar novamente com o botão direito e então em "Display Sensor Output" -> Internal frame, você irá ver também os valores dos sensores (que você também pode alterar através dessa interface), como abaixo:

E aqui nós terminamos a primeira parte do tutorial. Espero que na próxima parte nós já estejamos fazendo coisas mais interessantes do que piscar LEDs, não?

De qualquer maneira, se você se interessou, não fique me esperando: existem muitos tutoriais que vem com o próprio Sun SPOT Manager, no site oficial…

E, gente, tutoriais assim dão um *** trabalho para fazer, então, se vocês gostaram, percam dois segundos da sua vida e comentem :p Eu sou uma pessoa carente. Ainda mais agora que meu namorado vai passar um mês fora. *sniff* * abraça todos os leitores do blog*

TDC2008 [Florianópolis]: Eu fui!, parte 2

Cindy Dalfovo — Mon, 08 Dec 2008 00:48:28 +0000

Continuando meus relatos sobre o TDC que ocorreu no sábado retrasado (com algum atraso, é verdade… mas eu tenho de admitir que devo ter feito umas 4 provas na última semana…), vamos dar uma olhada nas outras duas paletras que eu vi:

Palestra 5 – Java na ponta dos dedos: A caneta que roda Java

Palestrante: Dr. Spock [ blog ]

Sinceramente, uma das palestras que me fez babar no evento. Se você não souber o que me dar de natal e for podre de rico, eu aceito isso como presente:

Sério. Trata-se de uma pequena caneta que possui uma máquina virtual Java (e que por isso foi destaque no último JavaOne) e que, portanto, pode receber pequenos programas escritos em Java Me utilizando a API fornecida pelos desenvolvedores. É uma caneta esferográfica com um pequeno sensor de infravermelho na ponta e um gravador.

Funciona assim: ela vem junto com um caderno que a caneta reconhece, e cada ponto do caderno é diferente, assim, quando o infravermelho passa pelas páginas, a caneta sabe em que página está, e em que parte da página ela se encontra.

Desta maneira, você pode começar uma gravação e ir escrevendo no seu caderno. A caneta grava e associa com o que você está escrevendo e mais tarde, ao “clicar” com a caneta sobre partes das suas anotações, você pode ouvir o que estava sendo dito quando você escreveu aquilo. E isso é apenas a função com a qual ela vem – lembre-se que ela possui uma máquina virtual Java, o que permita que você escreva seus próprios programas para ela.

Dois programas “demo” inclusos são o “teclado virtual”: de acordo com as instruções da caneta, você desenha um teclado no caderno e, ao passar com a caneta sobre ele, a caneta emite um som, como se você estivesse tocando um teclado. O outro demo é um pequeno tradutor: você escreve a palavra em inglês e pede para que ela seja traduzida e a caneta “fala” a tradução.

Virou um sonho de consumo, mas infelizmente ela custa 150~200 dólares, e isso nos EUA…

Paletra 6: O mundo Java ME

Palestrante: Bruno Ghisi / GUJava [ blog ]

Essa é uma palestra que eu queria ver, especialmente por me sentir mais “em casa”, já que o Bruno também estuda na UFSC. Eu já o “conhecia” de tê-lo visto escrever artigos para a Mundo Java junto com o Lucas Torri. Confesso que senti uma certa “invejinha” dos dois, já que eles sabem muito mais de Java e já fizeram coisas relevantes para a comunidade, mas tudo bem, é uma invejinha saudável Mas estou divagando…

O foco da palestra do Bruno não foi apenas falar sobre Java Me, mas sim contrapor uma afirmativa feita há algum tempo, de que o Java Me estaria fadado a desaparecer porque, com o avanço dos celulares, eles estariam passando a rodar Java Se ao invés de Java Me.

Não apenas o número de celulares mais simples que rodam Java Me é absurdamente maior do que o número de celulares smartphones – algo como mais de 2 bilhões de celulares pelo mundo, mas não são apenas os celulares que utilizam Java Me.

Da mesma maneira que os celulares estão evoluindo, outros dispositivos também estão, e aparelhos que outrora só rodavam programas em Assembly ou, no máximo, em C, agora começam a utilizar máquinas virtuais Java.

Ou seja, Java Me não está desaparecendo. Muito pelo contrário: agora ela se encontra no topo, já que nunca se usou tanto Java Me como agora.

Um exemplo óbvio é a caneta logo ali em cima, da outra palestra, que roda Java Me.

Moral da história: sim, ainda vale à pena aprender e desenvolver para Java Me. Diga-se de passagem, vale muito à pena!

Ué, e não eram 8 palestras, Cindy?

Eram, mas eu acabei de chegar de viagem e estou cansada. Ou seja, daqui a alguns dias eu coloco um resuminho sobre as outras duas palestras.

Para quem quiser, já disponibilizaram no site do evento os downloads das apresentações (em pdf/pps).

TDC2008 [Florianópolis]: Eu fui!, parte 1

Cindy Dalfovo — Sun, 30 Nov 2008 16:06:06 +0000

Ontem ocorreu o TDC (The Developer’s Conference) em Florianópolis. E, como o título do post já diz, eu fui! Depois de ir em eventos de animes e de games, eu tenho de dizer que foi uma grata surpresa ver como esse evento foi organizado: houveram alguns atrasos, que não foram absurdos e foram tranquilamente contornados, os palestrantes eram excelentes (boa parte deles são professores na Globalcode daqui de Florianópolis), houve distribuição de brindes (e eu faturei dois, como você pode ver pela foto ao lado. Aliás, a camiseta é liiinda e eu estava mesmo precisando de um boné novo!) e o mais importante: os dois coffee-breaks tinham muita comida boa! Ei, se você não acha isso importante, tente encarar 8 palestras no mesmo dia sem comer lanchinhos gostosos!

Mas estou divagando…

Cheguei por volta das 08:30 na FIESC, peguei meu crachá e me pus a esperar. O começo desses eventos é sempre uma agonia para mim: como eu não conhecia absolutamente NINGUÉM, eu fiquei alguns bons minutos olhando de um lado para o outro sem saber o que fazer. Minha parte anti-social dizia “apenas fique sentada ali do lado olhando para o teto como você sempre faz” e a minha parte que estava ansiosa em fazer amigos que também entendessem de Java dizia “apenas se aproxime de algum desses grupinhos! Diabos, deve ter gente curiosa para saber como é uma menina que programa em Java, use isso a seu favor, sua tonta!”.

Felizmente eu não era a única mulher por lá, e logo puxei papo com uma que eu depois descobri se tratar de uma pessoa muito bacana, a Catia. Pouco depois das 09:00 o evento se iniciou, e eu fiquei na palestra sobre JSF 2.0 – que ainda não foi lançada, por isso a palestra discorria sobre o que esperar dessa nova especificação. Aliás, fazer isso de uma maneira mais organizada: abaixo vocês encontram resumos das 8 paletras (das 16 apresentadas) que eu vi, das 4 primeiras palestras, na ordem em que as vi. Espero que isso sirva para repassar um pouco do conhecimento que eu adquiri ontem. Mais tarde devo atualizar o post com links para os PDFs das apresentações e, no caso das palestras técnicas, links para os exemplos utilizados, que serão disponibilizados no site do evento.

Palestra 1: Aguardando o JSF 2.0

Palestrante: Vinícius Nunes ( e-mail )

O JSF (Java Server Faces) se mostrou uma tecnologia muito interessante, e uma das causas do seu sucesso se deve, justamente, ao fato de ouvir seus usuários na hora de desenvolver as especificações.

Trata-se de uma framework para desenvolvimento baseada em componentes e que busca simplificar o desenvolvimento web – aliás, há diversas frameworks que buscam o mesmo e o atingiram de maneiras diferentes. Se você já tentou desenvolver para web em Java você deve imaginar porque é tão importante ter ferramentas que auxiliem nesse processo… um simples projeto pode se tornar uma salada macarrônica (?!) se você não tiver uma boa ferramenta para lhe auxiliar.

O JSF já passou por algumas refomurlações, e a sua versão 2.0 (que deverá ser lançada no final do ano que vem) deverá se aproximar ainda mais do que os seus usuários esperam:

Trará suporte a AJAX
Trará também uma melhor compatibilidade entre bibliotecas de terceiros (já que você pode usar JSF com outras bibliotecas, como JBoss RichFaces, IceSoft ICEfaces e Sun Woodstock)
Auxiliará o desenvolvedor em diferentes etapadas do desenvolvimento, ajudando-o a descobrir falhas no código e até mesmo implementando pequenos detalhes que o programador pode ter se esquecido de colocar caso o projeto esteja em fase de “desenvolvimento”. Outros estágios possíveis são os estágios de produção e de testes, por exemplo.
Funcionará com um mínimo de configuração (fico feliz em ler isso. Quantas vezes você já empacaram ao aprenderem uma nova framework porque não estava configurando direito a linha 887 em algum config.xml da vida?)
Escopo view: uma alternativa para armazenar dados, ao invés de criar memory leaks jogando tudo no escopo session.

Além disso, há uma pequena lista de sites e blogs recomendados para quem quiser se aprofundar no assunto:

JSF Central
JSF Tutorials
(blog) Ed Burns – desenvolvedor na Sun e que atua como líder na especificação JSF
(blog) Jason Lee – outro desenvolvedor senior da Sun com ampla experiência em JSF e que atualmente trabalha no Mojarra Scales, uma biblioteca de componentes para JSF.
(blog) Ryan Lubke – mais um desenvolvedor trabalhando com o Mojarra Scales.
(blog) Roger Kitain - Outro líder na especificação JSF
(blog) Jacob Hookon – criador do projeto Facelets, que fez tanto sucesso que será integrado à especificação 2.0 da JSF.

Palestra 2: Quais padrões ainda sobrevivem com as novas tecnologias?

Palestra: Rodrigo Cândido

O que é uma design pattern? Trata-se de uma maneira de documentar soluções para que problemas comuns não tenham de ser extensamente analisados cada vez que aparecem – para quê reinventar a roda quando dezenas, centenas, milhares de desenvolvedores já passaram pelos mesmos problemas?

Qualquer um pode criar um “padrão de projeto”, basta que ele documento o problema encontrado (quando, em que condições, etc) e a sua respectiva solução (ou seja, como utilizar os recursos disponíveis para obter uma solução eficiente), além dos benefícios trazidos por aquela determinada solução, mas também consequências negativas e padrões de projeto relacionados com aquele.

Foram apresentados alguns dos padrões de projeto mais famosos, dos livros “Design Patterns: Elements of Reusable Object-Oriented Software”, lançado em 1995 com 23 padrões e que se aplica a qualquer linguagem de programação orientada a objeto (que ficou conhecido como o catálogo GoF – Gang of Four – pelo fato do livro possuir quatro autores) e do livro Core J2EE Patterns, lançado em 2001 e que conta com 25 padrões de projetos. Além disso, existem muitos outros catálogos de padrões por aí, como este, com boas explicações, no site da própria Sun, e o site na Sun sobre o livro Core J2EE Patterns, que possui o livro para visualização.

Não irei passar cada um dos padrões mostrados porque, bem, é um assunto que já amplamente discutido e que você pode encontrar referências com facilidade no Google (embora eu tenha colocado alguns links para facilitar a sua vida).

Palestra 3: JBoss Seam

Palestrantes: dr. Spock (blog) e Vinícius Senger / Globalcode

O Seam é uma plataforma de desenvolvimento open-source para construir aplicacações ricas para a internet – eu não falei que esse assunto estava em voga?

Trata-se de uma solução completa para simplificar todas as etapas do desenvolvimento web, utilizando muitas tecnologias fornecidas pela própria especificação da Sun: se existem Annotations, por que criar 1001 documentos xml? Você pode usar tanto Hibernate quanto JPA, pode testar seus módulos de maneira automatizada, além de se integrar facilmente com uma infinidade de tecnologias e conceitos como BPM.

Sinceramente, eu me interessei MUITO por essa solução, aguardem por novos posts a respeito do Seam, já que eu pretendo utilizar essa ferramenta no futuro.

O Seam permite que você faça muitas coisas, como contextos diferentes em abas diferentes (por exemplo, em um call center você pode estar atendendo pessoas diferentes em abas diferentes sem maiores problemas, ou ter dois carrinhos de compras diferentes em abas diferentes em um site de compras, embora eu não saiba ao certo porque raios alguém gostaria disso) e resolve problemas de persistências que podem irritar muitos desenvolvedores (nota: se desenvolvimento web já é um monstro de criar bugs, desenvolvimento web COM persistência deve ser coisa para querer arrancar os cabelos… não façam isso na mão, crianças), como o Lazy Init Error (ou seja, quando você quer mostrar um dado de persistência na tela mas a conexão com o banco de dados já foi fechada). Ele resolve esse problema permitindo que você escolha quando quer iniciar e quando quer fechar a sessão.

Uma sessão pode ser iniciada com um clique numa opção do menu, por exemplo, e encerrada quando outra opção é selecionada. Além disso, há uma necessidade de configuração muito menor, e as anotações fazem com que muita coisa não precise de 1000 linhas para ser “explicada” ao programa: se você tem um campo @DataModel, é óbvio que você precisa de gets e sets para ele, e você pode dizer ao programa que um elemento selecionado dentro de uma lista é uma variável dentro de uma classe que será tratada por ela com não mais do que duas ou três anotações.

Palestra 4: SuperCRUD

Palestrante: Vinícius Senger (e-mail)

Uma palestra rápida que buscou mostrar um projeto open-source (cujo “papai” é o próprio Vinícius) que pretende ajudar desenvolvedores a gerar código mais rapidamente com o uso de templates. Você seleciona um template (a seleção é bastante limitada atualmente, e conta com colaboradores para aumentar a lista), define o formato da sua base de dados (relações, campos, tabelas, etc) e o programa gera um projeto para você, que você pode importar para o Eclipse e continuar a desenvolver sem ter de se preocupar em gerar as entidades e relacionamentos mais básicos. Ele até mesmo cria um pequeno projeto utilizando JSF e hibernate que conta com algumas páginas web para visualização e edição simples de dados, deixando mais tempo para que o desenvolvedor possa se preocupar com o que realmente importa no programa, que são os negócios e processos.

Ele também busca gerar código para diferentes linguagens, não apenas para Java – tudo depende dos templates disponíveis. O projeto possui uma comunidade no ning, que conta com explicações do próprio Vinícius sobre como utilizar o projeto, e possui um repositório no java.net. O site supercrud.com está fora do ar neste momento, mas esperamos que ele volte logo.

O projeto conta com 70 colaboradores cadastrados na comunidade, e ele convidou os participantes a colocaborarem com o projeto e o utilizarem para aumentar sua produtividade. Na comunidade há um tópico explicando melhor o que é o projeto e como as pessoas podem utilizá-lo e colaborar com ele.

Na próxima parte, as outras 4 palestras que eu vi e considerações finais sobre o evento. Agora, se vocês me dão licença, eu vou almoçar que já são duas da tarde…