Edwin Carlo Ribeiro Marinho

List ou IList: eis a questão

2011-09-07T12:31:00.000-07:00

Este texto é uma tradução do post que escrevi para o blog Dive Into Code.

Em um dia de reflexão durante uma conversa no trabalho, surge uma questão: Por que tantos desenvolvedores utilizam sempre referência para List<T> no lugar de IList<T> em C#? Mas a resposta convincente para esta pergunta não apareceu. Dessa forma o princípio de depender de abstrações e não de implementações concretas estaria sendo desprezado.

Aparentemente não é a primeira vez que esta dúvida aparece. E é possível notar que boa parte dos desenvolvedores que usam List<T> no lugar de IList<T> já foram programadores Java um dia. Seria este o motivo?

Em C# costuma-se utilizar a letra “I” no início do nome de interfaces. Pessoas que já programaram em Java poderiam se confundir, uma vez que List em Java representa a interface e LinkedList e Stack seriam exemplos de implementações. E é importante notar que, em C#, LiskedList<T>, Queue<T> e Stack<T> não implementam IList<T>, pois não fornecem acesso por índice.

Torna-se necessário entender mais a classe genérica List<T>, e as interfaces que ela implementa (IEnumerable<T>, ICollection<T>, IList<T>, IEnumerable, ICollection e IList). Assim, tais interfaces poderiam ser utilizadas como referência no lugar da classe concreta.

Uma vez que foi entendido um pouco mais sobre as interfaces e o que elas forneciam em termos de funcionalidade, era necessário fazer as alterações em algum projeto que fosse utilizado sempre List<T>. No primeiro momento, substituindo ao menos o retorno de um método de List<T> para IEnumerable<T>. Com esta mudança, apareceram alguns erros de compilação, faltava o método Add(T). Porém com ICollection<T> o código funcionou normalmente. Em alguns outros casos o IEnumerable<T> atendia a necessidade, pois só era necessário percorrer os ítens da lista retornada.

Mais adiante, foi encontrada uma situação em que era necessário acessar um ítem específico da estrutura, que foi resolvido utilizando a interface IList<T> como retorno. Até que apareceu um AddRange(IEnumerable<T>) de List<T> sendo utilizado, que poderia ser facilmente substituído por um extension method para ICollection.

Mas depois de todas as alterações surge a pergunta número dois: Todas as operações estavam sendo realizadas no local correto? Ficava mais fácil notar que determinadas classes estavam fazendo mais do que deveriam fazer, uma vez que o retorno de cada método era mais consciente.

No final, a refatoração obteve sucesso, todos os retornos de métodos que eram List<T> foram substituídos por uma interface adequada. Com um pouco mais de pesquisa foi possível notar que não só desenvolvedores com costume da interface List em Java faziam referência para List<T>, mas muitas pessoas utilizam a referência para List<T> devido aos recursos providos pela implementação. Um método como AddRange(IEnumerable<T>) poderia ser chamado em qualquer local. Uma proposta tentadora. Entretanto, depender de abstrações faz com que o código se torne mais flexível. E depender de interfaces que contem apenas as funcionalidades necessárias, limita a não tentar fazer em uma classe o que não deveria ser responsabilidade dela.

Caixa de papel, vidro, webcam e voilà! Um piano multitoque

2011-04-26T05:18:00.000-07:00

Na faculdade, mais especificamente na cadeira de Processamento Digital de Imagem e Voz, era necessário a elaboração de um projeto que pudesse utilizar de conceitos demonstrados nas aulas. Surgiu, então, a idéia de Marcus Lira para criar um piano multitoque.

Inicialmente a idéia parecia complicada de ser alcançada em apenas um período. Alguns integrantes do grupo estariam concentrando forças no trabalho de conclusão de curso e todos tinham outras cadeiras a cumprir. Mas seguimos com esse projeto.

O que estávamos nos propondo a fazer não se tratava de algo novo e tinhamos direcionamento para seguir. Utilizamos, então, o CCV para fazer boa parte do nosso trabalho. Como iríamos usar o protocolo TUIO, procuramos uma implementação de cliente que pudesse atender nossas necessidades. E assim, selecionamos o MT4j para desenvolver a UI.

Para a reprodução do som do piano escolhemos utilizar o Minim 2.1.0 BETA.

O código da aplicação desenvolvida pode ser encontrado no repositório do Google code. E como resultado segue o primeiro vídeo. Não sou bom em tocar piano, então não tente encontrar uma melodia.

Como as coisas estavam meio bagunçadas nesse primeiro vídeo, foi feita uma nova versão. Nessa segunda versão do device, houve melhora na captação do toque devido a iluminação que entrava na caixa.

Mais informações, sobre como o projeto foi realizado, podem ser encontradas no relatório que escrevemos. E sim, o trabalho foi simples de ser executado.

Como testar quando o software não tem botões?

2011-04-18T10:29:00.000-07:00

Texto que escrevi para o blog Bytes don't Bite!

Mencionei anteriormente da importância, para uma pessoa que trabalha com testes de software, de se ter conhecimentos sobre como desenvolver e ter uma visão do ambiente em que o software opera. Tais conhecimentos podem ser considerados facultativos para diversos profissionais de teste, mas em certos casos se tornam obrigatórios.

O que acontece, por exemplo, quando não existe uma UI para testar? Este cenário acontece quando o software desenvolvido trata-se de uma API (Application Programming Interface). O teste de API requer o desenvolvimento de uma aplicação que simule o uso real das chamadas.

Uma vez que se trata de testes de API, Josh Poley menciona que muitas técnicas diferentes serão sugeridas, dependendo do testador. Entretanto, o mesmo apresenta uma situação que funcionou bem para os testes do Sistema Operacional do Xbox.

Participei de dois projetos em que aplicações eram desenvolvidas para que o produto principal pudesse ser testado. No primeiro, o produto desenvolvido continha implementações de JSRs para um emulador de J2ME. Nos testes, então, eram criadas aplicações J2ME, que tinham a proposta de avaliar as classes definidas em cada especificação.

No outro projeto, foi criada uma API para comunicação com determinadas impressoras. Nesta aplicação, uma das funcionalidades era o envio de uma linguagem intermediária para API, que gerava um comando (PCL / PJL / HP-GL) correspondente e mandava para impressão. Para tal funcionalidade, era necessário o conhecimento das entradas e saídas esperadas (tanto da linguagem intermediária como do comando enviado para impressora). Os testes foram desenvolvidos em C++, simulando uma aplicação real que utilizaria a API.

Mas antes de começar a desenvolver os testes, é necessário dedicar um tempo para o planejamento do que será testado. Dependendo da complexidade da aplicação, um documento de testes pode auxiliar nessa atividade.

Já na criação dos testes, deve-se pensar como o ambiente pode ser preparado para identificar certas situações, como por exemplo, o uso de um arquivo corrompido ou a ausência de conexão de rede. A atividade de forçar falhas, em uma aplicação, pode ser considerada bem interessante. Uma vez que se detêm conhecimento para criar testes que forcem defeitos, o entusiasmo é enorme. Mas atenção, a prioridade deve ser dada ao fluxo principal, primeiro crie testes para as situações em que se espera que o software funcione.

Alguns cenários são mais complexos de serem testados. Casos como atualização de estruturas de dados, modificação de certos recursos e chamadas da API que não possuem retorno, necessitam de alguma forma de verificação. Uma função que não tem retorno, por exemplo, deve mudar de alguma forma o estado da aplicação. Em um teste a uma chamada que remove algum valor de uma lista e não tem valor de retorno, pode ser necessário usar de chamadas para percorrer a lista e verificar os valores, tendo assim certeza de que o valor solicitado foi removido.

James Whittaker e Alan Jorgensen relataram que, em teste de API, alguns problemas interessantes para os testadores são: garantir que a aplicação varia os parâmetros das chamadas de modo a expor possíveis falhas; gerar combinações interessantes de parâmetros; configurar o ambiente externo e os dados internos que afetam a API; variar a seqüência de chamadas da API para exercitar de várias formas as funcionalidades.

No blog de testes da Google, em um dos posts é mencionado que testes de chamadas isoladas da API não conseguem simular o cenário real. Para uma calculadora, testar as chamadas isoladamente pode ser efetivo. Mas para aplicações em que a ordem das chamadas pode interferir no resultado, devem ser testadas tanto as chamadas isoladas como combinações entre elas.

A organização dos testes é importante para facilitar a manutenção. Códigos bem escritos podem auxiliar no entendimento da equipe sobre o que está sendo testado. Então, caso possível, o uso de um guia com padrões de codificação é bem vindo. Dessa forma, a equipe irá se acostumar a escrever de forma que todos entendam. Quando o cenário de teste é complexo, a documentação no código ajuda a entender do que se trata.

A qualidade do código de teste pode influenciar diretamente na qualidade do produto testado. Erros nos testes podem omitir falhas importantes nos produtos.

Mas quem vigia os vigilantes? Quem testa o código de teste? Como garantir que os testes estão corretos? Quando se escreve códigos de teste, a atenção deve ser dobrada. Com isso é importante a cultura de revisão de código, programação em pares ou alguma outra forma que auxilie na diminuição de erros. Criar log da execução pode ajudar na identificação de problemas.

Pelo fato de os testes serem parecidos, a prática do copy & paste vai parecer tentadora. Mas evitar esta prática pode evitar vários problemas. Recomendo uma apresentação de Borba, para ter a visão dele sobre código duplicado. E, se em algum momento achar que o código de teste pode melhorar, melhore!

Nos projetos que trabalhei, a padronização dos testes foi um ponto importante, para transferência de conhecimento aos que precisavam entender o que estava sendo testado. Para o emulador de J2ME, foi criado um framework no qual as aplicações de teste deveriam ser desenvolvidas. Em ambos os projetos, certos testes precisavam de uma confirmação visual, mas ainda assim foi possível avaliar tais cenários, só demandava uma confirmação do testador. Nos testes foram contempladas variações de parâmetros e combinações de chamadas. Também foram utilizadas algumas técnicas de teste como pairwise, classe de equivalência, valores limite, etc. Os testes eram documentados e tanto o documento como o código passavam por um processo de inspeção. Sempre que possível, os testes eram projetados para necessitarem da menor intervenção humana, realizando o maior número de testes ao apertar um único botão.

Incentivando uma briga

2011-03-22T08:49:00.000-07:00

Texto que escrevi para o blog Bytes don't Bite!

Por muitas vezes refleti se as pessoas, que trabalham com testes de software, devem ter habilidades de desenvolvimento. Não nego que possuir conhecimento do negócio é necessário para o profissional da área de testes. Mas, entender sobre a estrutura do que é testado, que antes de tudo é um software, também é importante.

James Whittaker, que já trabalhou com testes na Microsoft e atualmente trabalha na Google, escreveu um livro que demonstra algumas técnicas para se “quebrar” um software. As falhas exibidas são bem interessantes, e possíveis de serem atingidas em abordagem caixa-preta.

Como testador, pude experimentar algumas técnicas mencionadas no livro. Vou relatar sobre a aplicação de uma dessas técnicas em um projeto que trabalhei. No software desenvolvido, um usuário poderia criar menus que seriam acessados através de um servidor. Quando acessado um determinado item do menu, uma ação seria acionada. Uma das ações disponíveis era verificar o usuário que estava acessando o item e direcionar para outra ação.

Na imagem acima, quando um usuário A acessa o ITEM 2 do MENU, a ação 2 é chamada. Uma vez que a AÇÃO 2 identifica que é o usuário A, a AÇÃO 3 é acionada. Olhando para este exemplo, tendo em vista que uma ação de decisão envolve processamento, já é possível reproduzir a falha. A idéia é forçar um processo a ser executado várias vezes. Imagine uma ação parecida com a AÇÃO 2 no lugar da AÇÃO 3, apontando para AÇÃO 2 quando o usuário for A.

Agora, imagine o usuário A acessando o MENU pelo servidor. Ele tenta acessar uma vez o ITEM 2, vai para a AÇÃO 2, que o direciona para AÇÃO 3. A AÇÃO 3 o manda de volta para AÇÃO 2, que o manda mais uma vez para AÇÃO 3. Vai para AÇÃO 2… Deu pra entender que nunca vai parar? Bastaram algumas requisições feitas com o usuário A para ser necessário reiniciar o servidor, pois o serviço havia ficado indisponível.

No livro “How to Break Software”, James Whittaker demonstra falhas que podem ser provocadas tanto pela interface com o usuário como através de outro software. Ele ainda fala que muitos têm dificuldade em entender o ambiente em que o software funciona. Na experiência que tive com testes de software até o momento, me deparei com vários testadores que somente interagiam com a porção de botões, ou outros componentes visuais, que lhe eram oferecidos através de especificações. Tais testadores desconsideravam sistema de arquivos, componentes externos, sistema operacional, rede, relacionamento com outras funcionalidades, etc.

Com esse post, pretendo incentivar uma briga.

Testadores, aprendam onde os desenvolvedores deixam os bugs. Acreditem, boa parte das falhas de um software estão no código! Estudem formas diferentes de se encontrar os problemas. Entenda o sistema operacional, analise o código fonte do software, entenda de redes, estude as falhas dos frameworks utilizados, avaliem a segurança do produto (não usem a desculpa de que segurança é um requisito não-funcional), estudem tudo o que for válido para certificar a qualidade do software.

Desenvolvedores, vocês vão deixar? Vejam o que esses testadores poderão fazer com o código produzido por vocês! Se aproximem do pensamento dos testadores, vejam como eles agem. Desenvolvam o senso crítico. Dêem seu máximo para que falhas comuns não aconteçam. Estudem onde os bugs aparecem para poder evitá-los!

No final, essa disputa saudável, entre evitar e encontrar os bugs, é uma forma de se obter um software de qualidade e uma equipe em evolução contínua.

Profissional de TI*, um rock star diferente

2009-06-14T17:52:00.000-07:00

Começarei este post com uma simples pergunta: Sua companheira** fica tão feliz quanto você ao ver seu código milagroso para a solução de um problema?

"Gatinha, deixa eu te mostrar meu último código fonte!"

É fato, não somos rock stars. Não fazemos um gol e dedicamos ao nosso filho em rede internacional. Não incorporamos o personagem de uma forma que transmita a emoção para o público. No máximo, iremos aparecer no jornal entre uma das várias reportagens do Kaká ou de mais um novo filme do Brad Pitt.

- Mas, quem era aquele naquela entrevista que passou?
- Era o co-inventor desse tal de USB.
- Ah...
[silêncio]
- O Brad Pitt está mesmo um gato nesse novo filme, não é amiga?
...

E o nome? Onde foi mencionado o nome de Ajay Bhatt? Será que ele é menos importante para a história da humanidade quanto Pelé, Ronaldinho, Elvis, etc? Fala-se de computador e o máximo que se escuta em nomes é Bill Gates. E acredite, muitas pessoas acham que não existe diferença entre linux e windows e não sabem o que é Microsoft.

A ciência é feita para que outros cientistas nos admirem. Exibimo-nos para quem pode entender a complexidade do que fazemos. Sério, o computador não é criado de uma hora pra outra.

Está cada vez mais difícil encontrar mulheres na nossa área. E as que entram normalmente se afastam da área técnica. Para quais mulheres seremos, então, o macho dominante***? Como iremos nos exibir para as fêmeas da região se elas não nos acham atraentes?

E deixo mais perguntas. Será que no momento em que nós, brasileiros, valorizarmos mais a ciência e a engenharia veremos mais os resultados de mentes criativas no nosso país? Ou eu vou matricular o meu filho na escolinha de futebol para que ele tenha um bom futuro por aqui?

* TI: Tecnologia da Informação
** Estou assumindo que você é mais um dos homens na área de TI.

*** Exemplo de machos dominantes: pessoas da área de direito ou medicina (para os que investem na mente), jogadores de futebol ou artistas (não faz diferença qual, basta aparecer na televisão e parecer bonitinho)

Fim de semana

2009-04-26T06:51:00.000-07:00

Manhã de sábado ensolarada, ideal para curtir uma praia. Acordo cedo (7 horas da manhã), me arrumo e por volta das 9 horas... Vou para casa de Henrique fazer trabalhos da faculdade. Primeira brincadeira, GRASP (trabalho de Engenharia de Software II) com Marcus e Antônio Carlos. Chegado o meio dia e dada por encerrada a atividade voltada para GRASP para aquele momento, pois ainda restam várias realizações para se fazer, inicia-se a jornada junto com a LPC2129 (plaquinha já com uma aplicação embarcada do nosso professor). Nesse caso o grupo está composto por Edson, Henrique e eu.

começa agora...

Sistemas Embarcados (o projeto)

Primeiro dia

A aplicação poderia acender e apagar os LEDs de acordo com o botão que fosse pressionado. Em nosso poder estava, também o código desta aplicação. Foi ai, então que resolvemos tentar embarcar a mesma aplicação. Problema, como deveriamos configurar o Flash Magic e os jumpers da plaquinha para embarcar uma aplicação?

Tentamos de várias formas: tira jumper, coloca jumper, haddoken pra trás no soco forte... nada. Mas, segundo o Flash Magic a aplicação havia sido embarcada, sendo que os LEDs não ligavam. Surgiu então a dúvida, será que a plaquinha morreu? Fomos (meu grupo) buscar a outra plaquinha que estava com Antônio (um colega de outro grupo) pra tentar com ela.

Conseguimos fazer, exatamente, a mesma coisa com a outra placa. Nada de LEDs acendendo. A hora foi se passando, entrou a noite e fui para casa levando comigo uma das placas para continuar tentando.

Liguei para Bruno Cartaxo (membro do outro grupo) e peguei com ele as configurações exatas para o Flash Magic com a LPC2129. Para minha alegria, funcionou! Naquele momento era só festa, modificar o código do professor, colocar esse e não aquele LED para acender, agora apaga, agora acende, etc. Dá pra notar, fiquei feliz.

Depois comecei a tentar desvendar a porta Ethernet, descobri a existência do uIP que resolvia esse problema e pude, então, escrever uma aplicação embarcada para acender e apagar os LEDs com um cliente Socket em Java para controlar cada um deles. Agora, resta conseguir embarcar um servidor WEB que permita controlar os LEDs a partir dele, já que o problema IP foi resolvido. Estou empolgado, pois o FreeRTOS parece atender a esta necessidade! Depois que os LEDs puderem ser acesos pelo servidor WEB o objetivo passará a ser acender uma lâmpada a partir dele.

Quem testa o botão vermelho?

2008-11-09T15:22:00.000-08:00

Para aqueles que possuem a atividade de teste de software o que vem a ser falado não é novidade. Sempre, acredite, o software vai apresentar problemas durante o desenvolvimento. Não duvidando da competência da equipe que o desenvolve, mas pelo fato de serem humanos, os desenvolvedores podem cometer erros. A pergunta do título é simples. Quem irá testar o botão vermelho (aquele que exige a operação mais complicada e/ou no caso de todas as outras darem errados)?

Fora este cenário ainda pode-se pensar em situações como sistemas cirúrgicos, de segurança, aéreos, militares, etc. Como é possível simular situações que não são esperadas. Como é possível provar que funciona um software que não pode dar errado?

Fazendo uma analogia, imagine o que seria de Davi se a pedra não derrubasse o Golias. No mínimo ele ficaria machucado. Para executar o arremesso da pedra Davi deve ter calculado, estudado a posição do vento, condições de altura, movimento da atiradeira, peso da pedra, etc. Será que realmente isto ocorreu? Independente se foi bem estudado ou não vale se pensar que, muito provavelmente, a ira de Golias seria bem maior após uma tentativa de o derrubarem. E representando esta analogia em tempos atuais (mas não tão atuais assim) pode-se imaginar que o esforço que tiveram pra se reerguer em Hiroshima poderia ser revertido para revidar o ataque caso a bomba caísse sem surtir o efeito que era previsto.

Com o tempo passa-se a ficar um pouco neurótico. Será que o software do equipamento que será utilizado para auxiliar na realização de uma cirurgia em mim (um exemplo) foi testado adequadamente? E se faltar energia, o cirurgião poderá realizar todos os procedimentos manualmente para me manter vivo????

Calma, segundo o TMM nível 5 o teste "é um processo com o objetivo de prevenir defeitos" (o que dará assunto para um próximo post). Basicamente, não será necessário testar (entenda-se por testes manuais) de fato o meu software. Poderá até ser realizado um ciclo de testes para "garantir" alguma coisa (que funciona, que não funciona, que atende os requisitos, etc) mas não será tão necessário já que todos os defeitos foram prevenidos.

Mas a pergunta continua, você se colocaria de cobaia para um teste de erro de um sistema cirúrgico ou daria uma martelada em uma bomba* para provar que uma tremulação durante o transporte não iria a fazer entrar em atividade?

* Sei que uma bomba não é um software, é só um exemplo para mostrar um erro grave que pode ser cometido e envolve risco

Imagens (por ordem que aparecem):
[1] http://2.bp.blogspot.com/_cLovCogpnbc/Rml6VgtIwxI/AAAAAAAAACQ/wpn0tgQ42VQ/s1600-h/bot%C3%83%C2%A3o+vermelho.jpg acessado em 09/11/2008
[2] http://www.palavradaverdade.net/Humor/charge0420-20Davi20e20Golias.gif acessado em 09/11/2008
[3] Eu mesmo que fiz para o post! ;)

Ensinando o computador: Estruturas Condicionais

2008-10-05T18:34:00.000-07:00

Para ajudar aqueles que estão iniciando na área de programação, uma pequena e breve explicação sobre estruturas condicionais simples e compostas (utilizando o comando SE).

Antes de tudo devemos perceber que o computador é, de certa forma, "cego". O que acontece é que o mesmo se comporta de acordo com o que programadores dizem que deve ser feito em cada situação, reconhecendo um conjunto limitado de instruções.
Para que este responda de acordo com as expectativas devem-se dar as instruções corretas. Sabe-se que os programas são executados de cima para baixo de forma sequencial. Mas em certos momentos será necessário modificar este curso de acordo com as decisões que devem ser tomadas. Isto poderá ser feito através de perguntas realizadas pelo comando SE (em inglês IF).

Existem três situações bem definidas dentro da programação, para o comando SE, que são: Estrutura Condicional Simples, Composta ou Encadeada.

Fluxograma
Uma breve explicação sobre fluxograma para logo em seguida dar continuidade ao foco principal do post.

Fluxograma “é um tipo de diagrama, e pode ser entendido como uma representação esquemática de um processo, muitas vezes feito através de gráficos que ilustram de forma descomplicada a transição de informações entre os elementos que o compõem. Podemos entendê-lo, na prática, como a documentação dos passos necessários para a execução de um processo qualquer. É uma das Sete Ferramentas da Qualidade. Muito utilizada em fábricas e indústrias para a organização de produtos e processos.” [ Wikipedia, acessado em 5 de outubro de 2008]

Formas para representação do fluxograma

Como exemplo será utilizado o seguinte cenário: "Minha mãe me impôs uma condição para que eu pudesse andar de bicicleta. Para que eu pudesse pegar a bicicleta, antes eu deveria tomar banho". A partir do que foi especificado pode-se extrair o seguinte fluxograma:
Agora, indo ao que interessa, pode-se obter o seguinte algoritmo a partir do fluxograma apresentado:

Estrutura Condicional SE (Simples)

Algoritmo
--DECLARE tomeiBanho, LÓGICO
--ler tomeiBanho;
--Se (tomeiBanho) então
----(andar de bicicleta, oba!)
--Fim-Se
Fim-Algoritmo

Estrutura Condicional SE (Composta)
Repare que agora possui o comando senão

Algoritmo
--DECLARE tomeiBanho, LÓGICO
--ler tomeiBanho;
--Se (tomeiBanho) então
----(andar de bicicleta, oba!)
--senão
----(ficar triste, pois mamãe não deixa andar de bicicleta sem tomar banho)
--Fim-Se
Fim-Algoritmo

Lógica de programação: a primeira vista

2008-08-24T19:42:00.000-07:00

Era dezembro de 2004, quando fui para a primeira aula de lógica de programação no ITECI. Um pouco atrasado chego ao local e, sem sequer me ser questionado o nome, sou colocado em uma sala por uma das atendentes do local. A aula já havia iniciado e tinham muitas pessoas na sala. O instrutor exibe um slide com a seguinte frase: "A caneta está na gaveta, para pegar a caneta preciso abrir a gaveta". Claro! É óbvio que para pegar uma caneta que está dentro da gaveta eu preciso antes abrir a gaveta.

Olhei para os lados me questionando: "Será que alguém daqui não sabe abrir uma gaveta e tirar a caneta?". Estaria eu em uma sala para pessoas, digamos assim, "especiais". Todos pareciam normais a minha volta (apesar de serem da área de TI).

Chega o intervalo, resolvo perguntar ao instrutor se eu estava, realmente, na sala de lógica de programação. Para minha surpresa... Estava! Começamos a ver outros procedimentos simples do cotidiano e eu ainda a me perguntar se valeria a pena um curso daquele. Era claro que eu sabia tirar caneta de gaveta, abrir geladeira, fazer uma ligação de orelhão para um amigo.

Chega a hora de fazermos fluxogramas...

"Faça uma ligação para um amigo pelo orelhão", era o que dizia o exercício para fazermos em um fluxograma. Isso eu sei... Pega cartão... Liga pra o amigo... se não atender, liga de novo... atendeu, falou, "tchau"! Entrego o fluxograma feliz da vida. Acabei antes de todo mundo... [ÊÊÊÊ!!!]

O instrutor pergunta: "Se eu não tiver cartão?". Volto... Nem sento na cadeira e coloco um outro bloquinho daqueles que representa uma condição... setinha pra lá... setinha pra cá... Pronto! Está aqui meu fluxograma "completão"! E ele pergunta: "E se o orelhão estiver quebrado?".

Para resumir a história, passei a noite inteira fazendo um fluxograma que não cabia em várias folhas juntas de papel paltado. E no final acabei percebendo que tirar uma caneta da gaveta não é um procedimento tão simples. Precisamos dizer para a máquina o que ela vai fazer em cada situação. Somos nós quem damos a inteligência que ela possui.

Eu possuia uma visão leiga de que para fazer um software era apenas questão de desenhar uma tela e dizer "Alakazam!" para que tudo estivesse resolvido. Vi que não é tão fácil como muitos imaginam. Já mais a frente no curso, depois de passar duas semanas virando noites e reunindo-se na casa dos colegas de grupo, apresento o projeto (feito em Java com Swing, todo na mão, tinha até DesktopPane no meio, que tirei nota máxima) para minha mãe e ela fala: "Tu passou duas semanas dormindo mal pra fazer essa coisa?". Mas quer saber? Valeu, muito, a pena.

Cenários a se pensar para construir? Existem muitos... Para quebrar... Mais ainda!

Para deixar claro... Não consegui fazer a ligação de orelhão sem que o intrutor quebrasse em algum lugar, que sorrindo me disse: "Está bom por este, vamos para um próximo exercício!".

Motivação

2008-08-10T18:05:00.000-07:00

"Motivação", este foi o tema do primeiro texto que tive a oportunidade de ler do professor Douglas Daniel Del Frari. Grato, sou, a Deus por poder trabalhar no mesmo ambiente que esta pessoa, onde posso trocar idéias nas horas de almoço. O que mais me admira neste profissional é o empenho para passar, não somente para seus alunos mas, para a comunidade o seu conhecimento, o que ele acredita ser importante e valioso para a área de tecnologia da informação. Não é fácil encontrar professores que se importem tanto com os alunos a ponto de ajustar a própria aula para que todos possam tirar proveito do conteúdo. Espero um dia ter o privilégio de estar em alguma aula ministrada por ele.

A motivação para se criar o blog já existia, mas foi a partir do post de como se preparar para o mercado de trabalho que foi dada a partida. Espero demonstrar aqui coisas que considero importantes para atuar na área. E tentar, até mesmo, me manter atualizado quanto a tendências do mercado.

Assumi este casamento com o desenvolvimento de software a algum tempo com a ajuda e apoio do meu pai, outro profissional da área que admiro bastante (profissionalmente e pessoalmente). Esse amor que adquiri por desenvolver é o que me faz ficar feliz durante e após as noites de sono que não tenho por estar estudando ou fazendo projetos. Esse amor é a minha motivação. Tomando uso das palavras de um poeta, que seja eterno enquanto dure. Que venham mais linhas de códigos que tragam vontade de pôr molduras e pendurar na sala de casa. E venham mais noites não dormidas que gerem bons resultados.

Falando um pouco mais do meu pai. O que seria de mim se não fosse por ele? Foi ele quem me disse: "Se você pretende mesmo fazer ciências da computação este curso é interessante". O curso ao qual ele se referia era o de programador trainee (que eu havia pego o folder). O preço pago por se antecipar, alguns períodos chatos na faculdade em que eu pensava que poderia estar em outros lugares aprendendo alguma coisa. Mas de tudo deu pra se tirar algum aprendizado. Voltando ao meu pai, não teria dia melhor para dizer o quanto ele é importante. Feliz dia dos pais, "painho", apesar de estar, quase, no final do dia! Obrigado por tudo!

Para deixar claro os meus agradecimentos, obrigado Deus, "painho", "mainha", minha irmã, e a todos aqueles que me dão, de alguma forma, motivação para continuar a enfrentar meus desafios. Do mundo, sabemos que, não levaremos nada. Então espero plantar, quem sabe aqui, bons frutos para aqueles que nele, irão, passar.