Um teste de unidade nunca deve interferir em outro, e isso significa que se um teste falha, você deve ter um problema e se dois testes falham, você deve ter dois problemas. Isolar os testes de unidade garantem manutenibilidade pois impede que algum erro no código quebre vários testes.

Um problema que podemos enfrentar ao escrever testes de forma isolada é que algumas vezes temos que utilizar objetos semelhantes em vários testes, usando o JUnit como exemplo podemos contornar isso com a utilização das Annotations que o framework nos fornece como o @Before, ou até mesmo somente isolando em um método privado para criar os objetos. Vamos ver uma classe de Test de Exemplo:

 Veja como há algumas linhas que se repetem algumas vezes:

List<Integer> esperado = Arrays.asList([alguns valores aqui]);
List<Integer> recebido = new ArrayList<Integer>();
FibonacciIteratorFinal finonacci = new FibonacciIteratorFinal();

A primeira coisa que poderíamos fazer é transformar esses objetos (esperado, recebido e fibonacci) em propriedades da classe, pois a manutenção vai ficar bem complicada se essa classe crescer e continuarmos copiando e colando esse mesmo trecho de código. Aliais, um bom sina de que temos que há algo errado em nossa classe é a repetição de trechos de código. Para transformar essas variáveis locais repetidas em propriedades podemos utilizar a própria IDE, no caso do Eclipse podemos colocar o cursor do mouse na variável local e pressionar Ctrl+1 e selecionar Convert Local Variable to Field.

Feito isso podemos utilizar um método que configure (instancie) os nossos objetos esperado, recebido e fibonacci. Podemos fazer um método privado que faça isso, mas mesmo assim teríamos que chamar esse método a cada teste que for executado, é menos pior do que o código repetido, mas da pra ficar ainda melhor.

private void setUp() {
	recebido = new ArrayList<Integer>();
	finonacci = new FibonacciIteratorFinal();
}

@Test
public void deveRetonarZeroUmeUmComoPrimeirosElementos() {
	//chamamos setUp() antes de cada método de teste
	setUp();
	esperado = Arrays.asList(0, 1, 1);
	recebido = retornaQuantidadeDeElementos(3);

	assertEquals(esperado, recebido);
	assertTrue(finonacci.hasNext());
}

A opção ninja pra melhorar a nossa classe é não chamar método privado algum, simplesmente passamos o método para público novamente e usamos a Annotation @Before que faz com que o JUnit execute esse método antes de cada método de teste (que está com o @Test):

@Before
public void setUp() {
	recebido = new ArrayList<Integer>();
	finonacci = new FibonacciIteratorFinal();
}

@Test
public void deveRetonarZeroUmeUmComoPrimeirosElementos() {
	List<Integer> esperado = Arrays.asList(0,1,1);
	List<Integer> recebido = new ArrayList<Integer>();
	FibonacciIteratorFinal finonacci = new FibonacciIteratorFinal();

	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());

	assertEquals(esperado, recebido);
	assertTrue(finonacci.hasNext());
}

@Test
public void deveRetonarOsOitoPrimeirosElementos() {
	List<Integer> esperado = Arrays.asList(0,1,1,2,3,5,8,13);
	List<Integer> recebido = new ArrayList<Integer>();
	FibonacciIteratorFinal finonacci = new FibonacciIteratorFinal();

	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());
	finonacci = finonacci.next();
	recebido.add(finonacci.value());

	assertEquals(esperado, recebido);
	assertTrue(finonacci.hasNext());
}

Outro trecho de código que se repete bastante é a chamada ao next() e value(), e isso pode piorar dependendo da quantidade que queremos retornar para o nosso teste. Nesse caso pode ser uma boa alternativa criar um método privado para eliminar esse código repetido que torna a leitura do métodos de teste um pouco mais complicado. E a refatoração fica assim:

@Test
public void deveRetonarZeroUmeUmComoPrimeirosElementos() {
	esperado = Arrays.asList(0, 1, 1);
	recebido = retornaQuantidadeDeElementos(3);

	assertEquals(esperado, recebido);
	assertTrue(finonacci.hasNext());
}

@Test
public void deveRetonarOsOitoPrimeirosElementos() {
	esperado = Arrays.asList(0, 1, 1, 2, 3, 5, 8, 13);
	recebido = retornaQuantidadeDeElementos(8);

	assertEquals(esperado, recebido);
	assertTrue(finonacci.hasNext());
}

private List<Integer> retornaQuantidadeDeElementos(int qtd) {
	qtd--;
	recebido.add(finonacci.value());
	for (int i = 0; i < qtd; i++) {
		finonacci = finonacci.next();
		recebido.add(finonacci.value());
	}
	return recebido;
}

Assim deixamos a nossos testes desacoplados, é claro que existem mais situações e técnicas que não foram abordados nesse post, mas esses são os alguns dos problemas mais recorrente que podem ocorrer. Observe que utilizamos o @Before no setup() fazendo com que o JUnit execute esse método antes de cada teste, e de modo semelhante temos também o método @After que é executado depois de cada método de teste, que é bastante útil quando temos que liberar recursos, como por exemplo quando abrimos um arquivo ou conexão com o banco de dados.

Postagens Relacionadas:

1. Teste Unitário com JUnit – Rapidinho
2. Enums – Rapidinho
3. Método, Variável e Classe Final

Algumas vezes temos o “problema” da equipe começar a crescer, e isso torna a Reuniões Diárias, e a primeira solução pra isso é dividir em equipes menores, com até 9 membros. Mas nem sempre a ambiente permite isso, há diversos problemas que posso sitar, mas esse não é o foco.
O fato é, algumas pessoas tem mais dificuldades em manter a atenção em reuniões (mesmo quando há menos de 9 membros), algumas ficam conversando até chegar na vez dela de falar… E assim vai!
Uma possível solução é tentar aplicar alguma dinâmica de grupo para energizar a Reunião Diária, e a premissa básica é que a dinâmica tem que ser fácil o suficiente para não tornar a Reunião demorada e tem que prender a atenção para que os envolvidos não percam o foco.

As equipes iniciantes normalmente seguem o modelo que é proposto no Guia Scrum para manter um padrão de fala, mas as mais maduras acabam deixando de lado esse modo “mecânico” de falar. Para a dinâmica dar certo é necessário estabelecer duas pequenas restrições.

1. Uma pessoa inicia a Reunião falando qual o valor entregou desde a Reunião anterior (só manter o mesmo modo de falar usado pela equipe).
2. A pessoa que acabou de falar indica quem é a próxima pessoa que deve falar e não pode ser a pessoa que está do lado dela.

Esse é um bom modo de fazer com que todos os envolvidos na Reunião tenham que manter a atenção, por ter que ficar de olho se é o próximo a falar, diferente de quando a Reunião vai seguindo em circulo. Além disso cada membro deve ter atenção para saber que a próxima pessoa que ele vai indicar não pode ter falado ainda.

Desse jeito as pessoas saiam um pouco da rotina.

Abraço

Postagens Relacionadas:

1. Todos de pé!
2. Scrum em Ação “Scrum in Action” você deveria ler

- Junta essas classes em uma só, muda isso e apaga aquilo.
– Assim fica mais fácil de entender, e as responsabilidades são diferentes. Você enxerga algum problema? Qual o motivo de juntar tudo?
– Porque eu quero que junte!

– Estamos gravando os logs SGDBR.
– Poderia gravar em um NoSQL pra ser mais rápido e não gastar recursos da aplicação. E com o MongoDB podemos configurar pra um escrita mais rápida já que esse tipo de log aqui não há problema em perder alguma linha o mais importante é a velocidade.
– Poderia sim, mas eu não quero fazer assim!

Esses diálogos hipotéticos já falam por si, mas vamos continuar…

Imagine a situação:
Uma empresa tem um problema, esse problema afeta o trabalhos de todos da equipe. A solução pode ser uma nova tecnologia que será adotada ou um novo modo de usar a engenharia.
E pra completar a situação anterior…
Nessa empresa há ilhas de conhecimento (ou silos), onde uma pessoa (ou grupo) detém o conhecimento total de determinada parte do processo (talvez essa pessoa impeça que outras melhorem esse processo pra não ter que sair da zona de conforto), e só para ela é delegada a tarefa de fazer pesquisas novas, pode ser que essa pessoa nem tenham tando conhecimento assim e é bem provável que não tenha mesmo.
Pra piorar ainda mais tudo isso, a parte superior da hierarquia só delega as mudanças para essa pessoa, deixando de fora qualquer outro membro da equipe que tenha mais conhecimento. Sendo assim há alguém que é o dono da verdade e levanta ou abaixa o polegar pra todas as situações.

Nessa situação relatada podemos observar uma série de problemas, não precisamos nem pensar muito, mas vou listar alguns:
Um só pessoa tem um conhecimento limitado, e quando delegamos as tarefas pra essa única pessoa deixamos de aproveitar o conhecimento coletivo da equipe, e é sabido que duas cabeças pensam melhor que uma só.
Outro problema é que ninguém gosta de ser pego de surpresa, imagine você de uma hora para outra saber que não pode mais usar a IDE Eclipse e de agora em diante todos tem que usar JBoss IDE ou até mesmo o NetBeans, é claro que esse exemplo é bem simples, e pode até ser que essa mudança vá resultar em ganhos de alguma natureza, mas o problema entra quando a mudança é imposta, quando não há avisos nem consultas, quando você deixa de perguntar pra outras pessoas da equipe se mais alguém tem alguma ideia melhor ou possui experiência pra saber de implicações que podem ocorrer.
As pessoas cuidam das mudanças quando elas sentem que fazem parte dela, quando sentem que de alguma forma a sua opinião foi levada em consideração e mesmo que o resultado final seja uma decisão contrária ao que ela achou, pelo menos deve haver alguma justificativa, não um simples “eu não quero que seja assim”.
E uma das consequências de tudo isso é que a equipe para de zelar pelo bom andamento do trabalho, claro que ninguém vai deixar de fazer o seu trabalho por “birra”, pois aí seria um problema ainda maior (qualquer profissional vai fazer o seu trabalho direito), mas você deixa de aproveitar o conhecimento de outras pessoas da equipe que pode ter experiência ou estudado assuntos semelhantes.
Por exemplo: Você quer implementar os testes de unidade em sua equipe. Pra uma pessoa que nunca nem fez um teste de unidade, há a possibilidade de a primeira coisa que ele vá fazer é procurar uma ferramenta pra isso, e essa pessoa pode ter uma única fonte de pesquisa. Mas para implementar os testes é necessário ter pelo menos conhecimento teórico, saber sobre boas práticas, como organizar o código, quando usar Mocks, quando ir no banco, quando paralelizar os testes e etc… Caso contrário passaremos a ser reféns dessa ferramenta escolhida por achismo e mania de ir sempre na mesma fonte, e indo além, assim que os testes passarem a ser caros de mais pra serem implementados eles serão jogados fora, sendo que o problema pode ser da ferramenta.

Esse simples exemplo ilustra como podemos com pequenas atitude acabar com todo o ânimo de boa parte de uma equipe, e como consequência ir minando as aptidões que cada um tem… As vezes ter um comportamento padronizado pode fazer com que erros sejam evitados, mas isso elimina completamente o trabalho criativo, e sem criatividade não há inovação e provavelmente ainda estaríamos usando o ANIAC.
Ao invés de colocar cabrestos em todos da equipe e podar a criatividade centrando todas as decisões em uma única pessoa devemos ter o costume de dar feedbacks para as pessoas, assim fazemos o mais importante: Elevar o nível da equipe!

Postagens Relacionadas:

1. RUP(Rica Utopia Pobre) ou A vida como ela é.
2. 5 dicas para ser mais efetivo em suas apresentações
3. Como Configurar Variáveis de Ambiente para Usar o Java?

Olá a todos…
Sem dúvida esse foi um dos anos que mais aprendi, foi um ano incrível. Apesar de ter estudado muito menos do que eu planejava por não ter me organizado muito bem no primeiro semestre (acho que não li nada no primeiro semestre), não por falta de tempo como foi a desculpa de muitos, mas por não ter conciliado muito bem todas as coisas. Mas como disse, mesmo assim foi um ano em que aprendi muito, me foquei bastante em Engenharia de Software, mais precisamente em Scrum, XP e Kanban, não só nos livros como nas leituras de artigos, mas é claro que li muito sobre programação e também aprendi muitas coisas novas nisso, realmente posso dizer que me tornei um programador melhor.
Mas vamos a lista de livros de 2013:

Guia da Startup: Como startups e empresas estabelecidas podem criar produtos web rentáveis (comprar)

Scrum in Action: Agile Software Project Management and Development

Scrum Guide (baixar)

Scrum Gestão ágil para projetos de sucesso (comprar)

Test-Driven Development: Teste e Design no Mundo Real (comprar)

VRaptor: Desenvolvimento ágil para web com Java (comprar)

Scrum – Guia Prático para Projetos Ágeis

Introdução à Arquitetura e Design de Software (comprar)

Agile: Desenvolvimento de software com entregas frequentes e foco no valor de negócio (comprar)

Test Driven Development: By Example

The Clean Coder: A Code of Conduct for Professional Programmers

JPA Eficaz: As melhores práticas de persistência de dados em Java (comprar)

Code Simplicity: The Fundamentals of Software

Clique aqui para ver essa lista no Goodreads.com.

Eu queria ter feito um resumo de cada um desses livros, por sorte achei que todos foram legais e mesmo os que eu não gostei tanto houveram coisas que deram pra aproveitar.
Eu sei que foi poucos livros que li comparados a outros Devs que conheço, mas foi alguma coisa, espero melhorar pro próximo ano.

Uma dica pra quem fala que está sem tempo: Todo mundo tem a mesma quantidade de horas no dia, é só parar e analisar quais momentos você pode aproveitar, acho que não da pra ficar o tempo todo lendo e estudando pois também há um mundo fora da programação e dos livros, com eu disse é só achar os tempos que sobram entre família, namorada e amigos, eu por exemplo sempre leio no tempo que pego ônibus e tento ler 1 hora por dia em casa. Como? Eu não sou fã de novelas, então leio enquanto a minha namorada/mão estão vendo, as vezes minha namorada vai estudar depois da novela, então aproveito esse tempo também, outra coisa foi diminuir o acesso ao Facebook, claro que lá eu posso encontrar várias pessoas que não vejo com frequência, mas por outro lado não da pra ficar o tempo todo olhando pra “nada” lá. O segredo e maximizar a qualidade e não a quantidade de tempo estudando.
E que venha 2014! Com a nova meta de leitura de 36 livros.

Postagens Relacionadas:

1. Livro Scrum: Gestão ágil para projetos de sucesso
2. Quebrando em Tarefas!
3. Grupo Haw no Agile Brazil 2013!

Lembro de ter lido esse um post com o título “Por onde começar no desenvolvimento de um software” no dia em que foi publicado no GUJ 01/02/2011, e esses dias eu estava procurando um post que eu tinha marcado como favoritos no GUJ e me deparei com esse. O Tiago Peczenyj (http://pacman.blog.br/) escreveu uma resposta de forma totalmente descontraída mas ele não tem ideia influência teve sobre o modo como eu vejo e desenvolvimento, lembro que naquele tempo eu já lia muito sobre Agile, XP, Scrum, TDD e etc, já havia até lido livros, mas como eu não trabalhava com isso ficava uma lacuna, faltava alguma coisa/alguém que me explicasse qual o fluxo de trabalho de tudo isso, o pulo do gato pra juntar aquele monte de informações que eu estava lendo e vendo em palestras. E foi aí que por acaso eu li esses post e vi a seguinte resposta:

inicie usando um software parecido.

vc quer fazer um webmail? use o gmail, hotmail, mailinator (não lembro de outro minimalista apesar deste ter uma proposta bem DIFERENTE).

ja usou? faça uma prova de conceito. Uns htmls estaticos por exemplo, para vc clicar e brincar. Adicione um javascriptzinho se desejar.

entendeu como alguem usaria? então pense na coisa mais simples possivel de ser feita. Por exemplo, mandar um email para vc mesmo com subject de teste e mensagem teste 123. Não serve pra nada mas vc ENVIOU um email, vc fez um software que chama uma biblioteca ou componente que manda email provavelmente e configurou as coisas certas. Agora disso para algo que recebe os dados de um POST HTTP é um pulo, assim como um login para dar acesso ao mesmo.

é claro que existe banco, design grafico,SEO, segurança, etc. Mas se vc extrai o VALOR do software e proriza o mesmo, fazendo algo que funciona desde a versão 0.0.1 é maneiro para caramba.

Agora imagine que vc faz com TDD ou ATDD ?

Vc tem que fazer um webmail. Vc cria um teste onde vc recebe um email e executa o software e o teste falha pq vc não implementou. Vc implementa e roda o teste. Mas como testar isto?

Ai entra a safadeza. Digamos que vc usa o PQPMail, um framework BOLADÃO de envio de email. E é simples

IPQPMail pqpmail = new PQPMail(configuration);
pqpmail.to("vc@mail.com");
pqpmail.from("papainoel@mail.com");
pqpmail.subject("teste");
pqpmail.message("teste 123");
pqpmail.send();

OPA! o seu codigo não é nada mais do que chamar um codigo de terceiros com os parametros certos e “enviar”.

Eu posso substituir o objeto pqpmail por um Mock – um objeto falso, de testes – e verifico se os metodos foram chamados com os argumentos certos. Existem varias bibliotecas para criar Mocks em java.

Mas isto manda email? Bom vc pode conferir na sua caixa postal. Vc pode automatizar isto? Pode, assim que descobrir como.

Mas vc precisa de muitas firulas no sistema, muitas funcionalidades! E agora?

Bom, se vc quebra em funcionalidades e pensa em uma trilha para implementar as paradas, o resto vc cria com o tempo. Pense bem, um webmail pode ser algo tão simples quanto o formulario de post do GUJ removendo os botoes para negrito, italico, etc!

E como vc evolui? Deixe as pessoas mandar email ue. Elas vão comentar o que pode ser e o que não pode. De repente vc não precisa ter as funcionalidades X e Y e sim A e B. De repente vc não precisa de banco de dados.

Mas como o software escala? Isto é uma boa pergunta. Se é um sistema web, vc tem certas tecnicas para escalar um sistema assim. Para isso vc vai querer saber quanta carga um servidor aguenta. Se vc deixa rodando toda a noite um teste de carga e analisa CPU, IO, Memoria, etc vc sabe como a adição de codigo afeta a performance. Se cair 1000x de um dia para o outro tem algo errado. Se vc sabe como escala e quanto um servidor aguenta vc consegue prever coisas como

– quanto precisa para suportar 1000 usuarios simultaneos? e 1 milhão?

É claro que vc parar uma hora para produzir um CSS maneiro. Fazer uma documentação DUCA ou tunar o banco de dados socando indices e outras coisas, ou vendo opções de cache para os servidores. Mas faça isso sob demanda ou quando estiver de saco cheio.

Tenho amigos que adicionaram track via analitics de TODAS as funcionalidades de um dado site. Eis que descobriram coisas como 90% das pessoas usavam um dado link ao inves de um botão. Dai removiam o botão e colocavam mais links. Navegação dobrou.

Nessas horas tem que ser malandro. Para isso:

quer fazer um software? use software. use bastante!
quer programar? conheça quem programa coisas e aprenda.
coloque logo em produção e deixe as pessoas usarem. sei la, seu pai, sua irmã, seus colegas de AD&D.

“fiz um software que calcula o Indice de Massa Corporal. os gordinhos vão usar?”
“fiz um programa que calcula a expectativa de vida a partir da quantidade de cigarros fumados. fumantes vão usar?”
“fiz um site de compras coletivas focado no publico marciano. os ets vão dar dinheiro pra essa parada?”

perceba que é menos tecnico e mais jeito de fazer as coisas.

Essa descrição descontraída pode não ser o melhor lugar para aprender sobre Agile, mas lembro bem de ter lido esse post várias vezes e ter a sensação de finalmente estar entendendo como as coisas funcionam (é menos técnico e mais jeito de fazer as coisas).

Link do post: http://www.guj.com.br/java/231734-por-onde-comecar-no-desenvolvimento-de-um-software#1192186

Postagens Relacionadas:

1. Desenvolvimento de Software não é especulação!
2. Manifesto para Desenvolvimento Ágil de Software
3. O Efeito Stroop no desenvolvimento de software

Todo mundo nesse país deveria prender a programar um computador… Porque isso nos ensina a pensar.

Para saber mais sobre esse projeto vá em Code.org.

Postagens Relacionadas:

1. O Programador Pragmático – Capítulo 2 – segunda parte
2. O Programador Pragmático – Capítulo 1
3. O Programador Pragmático – Capítulo 2 – primeira parte

Não tenho palavras pra acrescentar… Apenas aprenda como tornar as suas páginas mais leves.

E se juntássemos os feras que trabalham em grandes portais para criar o guia definitivo de performance para front-end?

Mas nada daqueles guias chatos feitos para robôs, que tal fazer algo divertido? Que tal juntar Briza Bueno(Americanas.com), Davidson Fellipe(Globo.com), Giovanni Keppelen(ex-Peixe Urbano), Jaydson Gomes(Terra), Marcel Duran(Twitter), Mike Taylor(Opera), Renato Mangini(Google) e Sérgio Lopes(Caelum) para criar a melhor referência possível?

Foi isso mesmo que fizemos! E iremos te ajudar nessa batalha de criar sites cada vez mais rápidos.

— Zeno Rocha, líder do projeto.

http://browserdiet.com/pt/

Se você preferir pode dar uma olhada na apresentação antes de ler o site. Além de ser bem legal você já vai poder ter uma ideia do excelente conteúdo que terá a disposição.

Obs.: O site deveria ter uma parte para doações, um trabalho bem feito desses custa no mínimo muito tempo e dedicação. Parabéns!

Postagens Relacionadas:

1. Livro Scrum – Guia Prático para Projetos Ágeis

Olá…
Esses dias estava dando uma olhada no sumários de um livro no site da editora Novatec e acabei me deparando com o lançamento do livro Scrum – Guia Prático para Projetos Ágeis do autor Cesar Brod.

Preço e escopo fixo não combinam com dinamismo.

O livro foi uma surpresa bem legal, o Cesar Brod soube expressar as suas idéias e experiências de uma forma bem fluente, e isso tornou a leitura do livro bem agradável, além disso cada capítulo é bem direto ao ponto e isso faz com que o livro seja fácil de consultar, coisa que já fiz algumas vezes.

Decore o mantra do Manifesto Ágil, até que ele esteja tatuado de tal forma em sua mente que você passe a vivê-lo de forma integral.

O autor expõem  como o Scrum é e o modo que ele usou em seus projetos, algo semelhante ao livro Scrum em Ação/Scrum in Action mas ao mesmo tempo com uma abordagem bem diferente. Com o livro deu pra aprender um pouco mais como não “estragar” o Scrum, e como fazer as adaptações para o tipo de ambiente sem deixar a cheirinho de Scrum de toda manhã se transformar em algum dos odores.

O que abunda não prejudica, mas o que é demais atrapalha […]

Uma técnica apresentada no livro que eu gostei bastante é a utilização de Mapas Mentais, apesar de já ter visto isso antes e até mesmo ter comprado um livro pra aprender como fazer, os exemplos do livro me deram uma motivação maior para aprender a utilizá-lo de verdade e o mais importante é que agora vou tentar colocar a técnica em prática.

Não se aprisione a contratos que tornarão seu trabalho inútil e seu cliente infeliz

Pra finalizar, é mais um livro que  valeu o investimento, aprendi muito sobre Scrum e aprendi mais ainda como transmitir ideias, pois o autor escreve de maneira bem agradável, e isso me levou a chegar no último capítulo sem mesmo ter percebido que o livro já estava acabando.

Abraço!

Postagens Relacionadas:

1. Livro Scrum: Gestão ágil para projetos de sucesso
2. Livro SCJP (guia de bolso)
3. Scrum em Ação “Scrum in Action” você deveria ler

Fala galera,

Eu estou desenvolvendo um site para o meu casamento e queria compartilhar com vocês duas alternativas bem úteis que eu não conhecia e me ajudaram no processo de construção.

A primeira é o site editar-fotos.net, que é um site que disponibiliza as principais funcionalidades que um editor de imagens precisa ter, tudo gratuito. Possui redimensionamento de imagens, filtros, ajustes, e outras opções simples que precisamos no dia a dia. É uma boa saída para aqueles que não querem gastar com licença do Photoshop e nem instalar algum outro software gratuito.

Interface inicial do site

A segunda dica é um programinha utilizado para criar thumbnails – que são versões reduzidas de imagens – gratuito e muito prático. É o Easy Thumbnails, programa que possui uma interface bem simples e permite transformar várias fotos de uma vez e em diversos formatos. Ele permite também que seja selecionado o algoritmo utilizado na conversão das imagens.

Então é isso. Acho que não apresentei nenhuma novidade aos mais experientes, mas é sempre bom divulgar.

Valeu.

No related posts.

Olá pessoal, hoje vou postar uma introdução a um tema que utilizo em minha dissertação de mestrado que é chamado de Democracia Eletrônica, ou seja, e-Democracia (também muito conhecido pelo termo em inglês, e-Democracy.

O que vem a ser e-Democracy? São tipos de sistemas que se fazem do uso dos meios da tecnologia da informação e comunicação para prover melhorias para um determinado governo (regional, municipal, estadual, nacional ou global) atuando em processos democráticos dos mesmos.

Meio vago ainda né? Vou citar um exemplo para dar um pouco mais de clareza ao que vem a ser e-Democracy. O voto eletrônico brasileiro é um bom exemplo, pois é um meio digital eletrônico que beneficia e agiliza o processo de votação e apuração dos votos.

O voto eletrônico é utilizado desde o ano de 2000, é composto por urnas eletrônicas formadas por um sistema eletrônico embarcado em cada um das urnas e são distribuídas por todo o país em zonas eleitorais. Ao término das votações as urnas são recolhidas e os votos são contabilizados muito rapidamente.
Quem não se lembra que a apuração dos votos chegava demorar vários dias para sua definição.

Outro bom exemplo é o portal e-Democracia (http://edemocracia.camara.gov.br/) que não poderia ter um nome melhor do que esse.
O e-Democracia é um portal brasileiro que permite a participação da sociedade no debate de temas importantes para o país, como por exemplo, na discussão de novas propostas de lei

Segundo descrição do próprio e-Democracia, ele foi desenvolvido pela Câmara dos Deputados, é dividido em dois grandes espaços de participação: as Comunidades Legislativas e o Espaço Livre. No primeiro, você pode participar de debates de temas específicos, normalmente, relacionados a projetos de lei já existentes.

Essas Comunidades oferecem diferentes instrumentosde participação e, ainda, orientações quanto ao andamento da matéria no Congresso Nacional. Já no Espaço Livre, você mesmo pode definir o tema da discussão e ser o grande motivador dela. O debate será acompanhado pela equipe e-Democracia e pode vir a se tornar uma Comunidade Legislativa.

Os parlamentares envolvidos com a matéria acompanham as discussões e as consideram para auxiliar suas decisões.

Existem outros exemplos que não cito aqui mas através destes já podemos entender um pouco sobre o tema deste post.

Ferramentas como estas nos auxiliam na governança e nos aproximam de maneira simples da construção de uma sociedade mais justa.

Por que eu resolvi falar de e-Democracy hoje? Simplesmente para motivar a criação, a busca e o compartilhamento destes tipos de ferramentas entre todos os cidadãos. É imprescindível que saibamos o que esta a nossa disposição, o que podemos fazer para auxiliar o governo, a idéia do e-Democracy é sempre melhorar a sociedade em que vivemos.

Precisamos ser mais atuantes para que a engrenagem “cidadão” comece a movimentar positivamente a máquina chamada “Brasil”.

Bom, este foi uma pequena introdução ao tema e-Democracy, em breve postarei mais alguns tópicos que estão sendo utilizados em minha dissertação.

Se vocês conhecerem ferramentas úteis, comenta aqui em baixo, coloque o link para que outras pessoas também a conheçam ok…

Grande abraço a todos e fiquem com Deus.

No related posts.