Profissional de TI*, um rock star diferente

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

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?

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] https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7knLItxCr0h8IlXr8lrYpziL6my0toU5lxTOM6Gp7vic5hvo1dcOrTJm3Ajm-qjVqHgKWiN-nNLWI4PV-9KX-k8AkFlfCFziItDZYEBbVmjPBUh7Oz-T1nhCtAWIpjLTNRz4U4_MG7EtK/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

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

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

"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.