Autor: Luiz Ricardo (Página 14 de 16)

Experiências de uma monografia

Cursar uma pós-graduação, aproveitar ao máximo todas as matérias, adquirir conhecimento em diversas áreas, fazer networking, amadurecer profissionalmente, etc. Tudo isso é muito bom, mas é preciso uma monografia para obter plenamente a formação almejada.

Enquanto estou na reta final do desenvolvimento de uma monografia sobre estimação de software para finalizar o curso de Especialização em Engenharia de Software, meu orientador sugeriu que eu escrevesse sobre esta experiência. Gostei muitíssimo da ideia e, nas próximas linhas, irei discorrer brevemente sobre o desafio de escrever um texto acadêmico que, espero, seja de um bom nível.

Tudo aqui foi baseado na minha própria experiência pessoal. Isso significa que não pretendo escrever um guia completo, mas talvez evitar que o leitor caia em certas armadilhas. Imagine isso como uma conversa entre dois colegas sobre o assunto, sendo que um já passou pela experiência.

Desenvolver uma monografia bem feita não é fácil. É necessário tempo, dedicação e persistência. Se você somente quer um diploma, pode parar de ler agora. Não perca tempo.

O que é uma monografia

A wikipédia dá uma definição bem clara: é um tipo de trabalho acadêmico escrito com base em pesquisa sobre um determinado ponto da ciência.

Geralmente uma monografia não inclui novas descobertas, dados inéditos ou reflexões elaboradas, mas é fundamental para a formação e amadurecimento do estudante, permitindo que este adquira profundos conhecimentos que, muitas vezes, vão além do escopo do texto.

Um Projeto

Minha primeira dica é: pense na monografia como um projeto. Ela não é somente um texto grande cheio de citações que você escreverá uma vez.

Analogamente ao software, você terá que desenvolvê-la iterativamente numa espécie de modelo evolucionário. Falei grego? Tradução: você terá de escrever, revisar, melhorar, reescrever, corrigir, reorganizar, revisar, incrementar, reescrever, reordenar até atingir um texto de bom nível.

A monografia deve ser bem estrutura e possuir sequência lógica de argumentos. Cada parágrafo deve convergir para a afirmação ou argumento central.

Não faça isso!

Não escolha qualquer tema

O tema é muito importante para você. Será necessário aprofundar-se nele. Provavelmente você investirá mais do seu tempo nisso do que em qualquer disciplina do curso. Pense muito bem de que área você gosta e cujo aperfeiçoamento pode trazer benefícios profissionais.

Um professor que tive dizia que devemos escolher um tema que já conhecemos, dentro da nossa “zona de conforto”. Discordo. Primeiro porque a maioria das vezes que pensamos conhecer um tema, na verdade o conhecimento consiste em experiências empíricas ou estudos superficiais. O tiro pode sair pela culatra quando você percebe que o iceberg é muito maior do que realmente se pode ver.

Não comece escrevendo

É uma tentação começar a escrever logo, tanto quanto codificar um sistema sem a devida análise. Se o leitor tem experiência em projetos, aproveite a metáfora e aplique seus conhecimentos de engenharia.

Antes de produzir algo, é necessário ter certo grau de profundidade no assunto. Discuta com seu orientador os conceitos envolvidos e procure nivelar o entendimento sobre os assuntos que você deseja incluir.

Leia o máximo que você puder em potenciais bibliografias e faça muitas anotações. Posteriormente, quando a estrutura do trabalho já estiver delineada, será possível distribuir as referências nos devidos tópicos e evitar a necessidade de ler todo o material novamente.

É muito ruim você chegar num estágio avançado, com prazo curto, e descobrir que um capítulo inteiro não faz sentido e jogá-lo fora. Ou ainda perceber que é necessário acrescentar um novo capítulo com noções teóricas sobre uma área que você nem cogitava, o que significa voltar ao estágio de pesquisa, incluir novas bibliografias, e assim por diante.

Não saia de casa sem…

Um ótimo orientador

Tive dificuldades em conseguir um orientador. Os professores com que tinha alguma afinidade ou decidiram não orientar nenhum trabalho ou não respondiam e-mails. É um problema que vários alunos do curso enfrentaram, acabando por ficar com qualquer orientador que aceitasse o trabalho. Infelizmente, isso não se resume à instituição em que estou matriculado.

Devido a essa dificuldade, resolvi escrever a monografia por conta própria e esperava que assim algum professor se interessasse. Lembre-se: não faça isso!

As disciplinas regulares haviam terminado e eu não tinha mais contato direto com os professores. Como ainda não tive retorno de e-mails, decidi concluir a monografia por conta e simplesmente pedir a aprovação para qualquer professor.

Entenda que eu estou acostumado a estudar por conta própria, aprender sozinho. Não espero muito de professores, até porque boa parte não sabe muito além do conteúdo da disciplina. Minha expectativa se resumia a aprender somente com a pesquisa.

Porém, minha obstinação em não fazer as coisas mal feitas não me deixou em paz. Falei com o coordenador do curso e ele me sugeriu contatar outros docentes da faculdade que não foram meus professores. Essa foi a solução. Finalmente encontrei um orientador de verdade. Então percebi como isso faz toda a diferença.

Com poucas horas de conversa, ele já abriu a minha visão para conceitos que talvez eu demorasse alguns anos para captar e que, segundo ele, muitos autores também não conseguem perceber. Praticamente reestruturei e reescrevi toda a monografia, mas não porque isso foi exigido, é algo natural.

A coisa tem funcionado mais ou menos assim: primeiro ele examina um ponto do meu trabalho. Se não está bom, ele não diz algo como “isto está errado, escreva dessa outra forma”. Ele faz uma pergunta, que muitas vezes é mais que suficiente para que eu enxergue minha ignorância e acabe com um facepalm. Depois ele explica de forma bem detalhada o conceito. Pronto! Após analisar alguns pontos dessa forma minha mente já está novamente carregada de ideias e preparada para mais uma rodada de revisões. Não é preciso riscar todo o trabalho de vermelho.

Enfim, se você quer mais que ler e juntar material sobre um assunto (o que para mim não justifica um curso), desbravar novos horizontes e agregar novas visões e abordagens sobre o tema, amadurecer realmente, seja um bom discípulo e procure um bom mestre.

Boas fontes bibliográficas

Alguns autores, ou grupo de autores, podem ter uma visão um tanto tendenciosa sobre um tema.

Vou tomar os processos ágeis e “tradicionais” como exemplo. Dependendo do material que você tiver disponível, terá a impressão de que um determinado processo ágil é a sétima maravilha do mundo e que ele resolve todos os problemas em projetos de software. Por outro lado, ao ler um livro de CMMI ou RUP você acabará com a ideia de que a empresa que adota esses processos terá sucesso garantido em todos os projetos.

Há alguns meses eu diria que seria possível, depois de pesquisa suficiente, determinar qual modelo, processo, técnica ou método de estimação é o melhor. Depois percebi que não é possível fazer tal afirmação de forma objetiva e científica. Mais recentemente, após algumas conversas com meu orientador, percebi que a questão em si não é apenas estimar. A estimação contribui para algo maior, que é o entendimento do ambiente do projeto e a variáveis que o influenciam. Enfim, a questão não é o método em si, mas determinar a essência do problema, o que estamos tentando resolver. A partir disso, seleciona-se uma abordagem adequada, entendendo seus princípios e como ela contribui para a solução.

Enfim, não estou afirmando que você deva evitar livros que adotam certo ponto de vista. Apenas garanta que estão incluídos pontos de vista conflitantes e que você entendeu qual é a questão realmente em jogo para tentar conciliar essas visões.

Ler muito

Sem leitura, seu texto será resumido a conhecimento empírico. Nivele seus conceitos e terminologias com o dos autores para diminuir o retrabalho futuro.

Anotar tudo o que achar interessante

Não adianta escrever um texto academicamente maravilhoso sem citar as fontes. Aquela afirmação genial que você não se lembra de onde tirou não terá peso acadêmico sem o respaldo do autor original.

Além disso, imagine-se tendo que parar de escrever e perder um tempo precioso para folhear todo um livro a procura de um trecho interessante.

Discutir as ideias com seu orientador

Antes de colocar as ideias principais no “papel”, verifique se você não está equivocado.

Ler ainda mais

Já enfatizei a importância de ler e de selecionar boas fontes bibliográficas. Entretanto, na medida em que você amadurece no entendimento do tema, revisões ajudarão a manter o foco e novas leituras preencherão as lacunas.

Abordagens para uma monografia

Seja egoísta, no bom sentido

Pense no que você quer ou precisa aprender. Não espere salvar o mundo ou revolucionar o mercado através do trabalho, pois ainda que ele seja muito interessante e referenciado, o principal beneficiário do conteúdo acaba sendo o próprio autor, o qual leva consigo todo o conhecimento incluído ali.

Também não procure agradar seu professor simplesmente concordando com tudo o que ele propor. Tenha forte consideração pelos conselhos dele, mas lembre-se que no seu dia-a-dia como profissional ele provavelmente não estará lá para lhe dar as respostas.

Iterativa e Incremental

Estruture o esqueleto do trabalho, ou seja, defina os capítulos e os principais tópicos. Verifique se isso faz sentido como um raciocínio contínuo. Então comece a preencher os “espaços” com conteúdo de forma que cada citação ou ideia que você teve irá para seu provável destino final. Ao terminar você provavelmente terá ideias de tópicos que faltaram. Tome nota de tudo, tire dúvidas com o orientador, leia mais e então revise cada item desde o começo, do começo ao fim.

Dessa forma, você itera sobre todo o texto várias vezes e incrementa o conteúdo dos tópicos a cada revisão. Como em qualquer projeto, faça isso até que o conteúdo esteja suficientemente bom segundo seus critérios e do orientador.

Conclusão

Uma monografia pode ser encarada como um “trabalhinho” de final de curso ou como uma poderosa ferramenta de aprendizado através de pesquisa e orientação.

Meu conselho é: use-a como um trampolim para crescimento profissional e também pessoal. Encare-a como um projeto a ser desenvolvido, não fique satisfeito em ajuntar um punhado de teoria, lute até extrair algo que faça sentido no mundo real, no seu dia-a-dia, de forma que você não saia o mesmo desse processo.

Aprenda Inglês de Graça

Aprender outro idioma é fundamental. Ponto. Inglês é essencial para a área de TI. Ponto.

Estudar numa escola ou com um professor particular pode ser muito bom, embora seja necessário conciliar horários, se locomover até o local, correr o risco de não ter um professor qualificado ou imprevistos pessoais que não permitam o aproveitamento das aulas. Ou você simplesmente gosta de correr atrás do conhecimento por conta.

Buscar material na internet ou através de livros é uma forma de aprender ou aperfeiçoar o outro idioma. Existe bastante conteúdo online para autoaprendizagem, inclusive gratuito. É possível estudar e aprender de graça!

Por um lado, quem busca um curso online com tutores e certificados pode acessar o www.englishtown.com, que conta com alunos de todo o mundo, professores nativos e cujo certificado tem equivalência a exames reconhecidos como IELTS e TOEFL.  Mas tudo isso tem um preço, partindo de R$ 119,00 mensais. Entretanto, este site também disponibiliza gratuitamente e-mails diários com lições de Inglês. Conclusão: só vale a pena se houver tempo, interesse e dedicação.

Por outro lado, há opções gratuitas para se aperfeiçoar o Inglês sem compromisso. Vejamos duas delas que eu pessoalmente recomendo:

British Concil – Learning English

Site: http://learnenglish.britishcouncil.org/en/

Possui uma variedade interessante de conteúdo: gramática, vocabulário, vídeos, áudios, atividades, jogos e até piadas. Uma categoria interessante é Business & Work, com vários assuntos e atividades relacionadas a empresas e ao mercado de trabalho. Outra seção importante é a que ajuda na preparação para o exame IELTS.

Além do Learning English, o British Concil disponibiliza outros três subsites:

  1. Learning English Teens: conteúdo para adolescentes
  2. Teaching English: conteúdo para professores de Inglês
  3. Learning English Kids: conteúdo para crianças

English as a Second Language Podcast (ESLPOD)

Site: http://www.eslpod.com

Disponibiliza conteúdo em áudio (aproximadamente 3 vezes na semana) para treino de vocabulário e entendimento do inglês falado.

Cada lição começa geralmente com um diálogo de fácil entendimento, em velocidade reduzida e num contexto específico. Então, o professor revisa toda a conversa, analisando o significado de expressões e chamando a atenção para gramática, etc. Ao final, o mesmo diálogo é repetido, mas desta vez de forma natural, como um norte-americano falaria no dia-a-dia.

Opcionalmente pode-se adquirir o guia de estudo para cada podcast por US$ 10,00 mensais.

Agora é com você. Dedique-se e aprenda Inglês de graça.

Planning Poker existe, sem brincadeira

No último post, mencionei um tal de planning poker e um colega achou que era parte da brincadeira. Para quem não conhece, talvez a frase em questão talvez não tenha feito tanto sentido:

Coloque uma equipe de juniors num processo ágil, eles vão começar a estimar usando planning poker e provavelmente vão continuar jogando poker até o final do projeto.
Para quem já conhece é chover no molhado. Mas vamos lembrar que ainda existem muitas pessoas que desconhecem completamente os processos ágeis ou apenas ouviram falar deles. E nem sempre é culpa é do indivíduo em si, pois quantos formandos saem de um curso de Ciências da Computação sem nem ouvir falar desse assunto. Isso aconteceu comigo. O único contato com Engenharia de Software foi uma disciplina cujo conteúdo consistia em alguns capítulos do Pressman.

Infelizmente muitas universidades não contam com professores que possuem experiência de mercado, outras vezes a grade curricular não ajuda. Existem professores que ensinam o mesmo conteúdo há tantos anos que dá a impressão de que a tecnologia não evoluiu. Outros são inexperientes e adotam um livro guia, apenas resumem o conteúdo.

O que é Planning Poker?

É uma forma de criar estimativas. 

Estimação é uma atividade fundamental de todo processo ágil. A cada início de iteração (sprint), as estórias de usuário (requisitos) que serão implementadas precisam ser detalhadas e estimadas. Esta é uma tarefa realizada em conjunto por todo o time (equipe).

Com o Planning Poker a tarefa de estimar pode ser mais interessante e divertida, o entendimento dos requisitos é melhor entendido pela equipe e há motivos para se acreditar que tenha bons resultados.

Adaptei uma explicação de como a técnica funciona do site www.crisp.se, detalhada a seguir.

Estimativas sem Planning Poker

Há um problema típico com as estimativas em equipe. Vamos supor que estamos na Reunião de Planejamento do Sprint e o Product Owner diz:

Pessoal, qual o tamanho dessa estória de usuário aqui?

Então a equipe começa a pensar sobre o tamanho dessa estória (em homem-dia nesse caso):

Sem Planning Poker - Passo 1

O sr. 

A acredita que ele sabe exatamente o que deve ser feito e acha que levará 3 dias. Os senhores C são mais pessimistas. D e E estão pensando em qualquer outra coisa. Então o sr. A se antecipa e diz: “vai levar 3 dias”.

Sem Planning Poker - Passo 2

Isso deixa 

B e C confusos, duvidando de suas estimativas. O sr. E volta a si e nem sabe o que está sendo estimado, enquanto D continua cochilando. Quando o Product Owner pergunta ao resto da equipe sobre suas estimativas, todos acabam sendo influenciados por A, que respondeu primeiro, e respondem:

Sem Planning Poker - Passo 3

Estimando com Planning Poker

Agora, imagine cada membro a equipe segurando o seguinte maço de cartas:

Cartas Planning Poker

Vamos refazer a estimação. O 

Product Owner diz: “Pessoal, qual o tamanho dessa estória de usuário aqui?” Mais uma vez, a equipe começa a pensar.

Com Planning Poker - Passo 1

Desta vez, ninguém se antecipa. Cada um seleciona uma carta contendo sua estimativa e a deixa virada sobre a mesa. Depois que todos colocam suas cartas, os senhores 

D e E acordam. Eles admitem que dormiram e perguntam qual estória está sendo estimada, pois é difícil chutar estimativas dessa forma. Quando todos terminam, as cartas são viradas simultaneamente, revelando as estimativas de cada pessoa.

Com Planning Poker - Passo 2

Ops! Houve uma grande divergência. A equipe, principalmente o sr. 

A e o sr. C, precisam discutir a estória e porque suas estimativas estão tão distintas. Depois de alguma discussão, o sr. A percebe que esqueceu algumas tarefas importantes que deveriam ser incluídas na estória. O sr. C percebe que, com o design que o sr. A apresentou, a estória pode ser menor que 20. Depois de 3 minutos de conversa, um novo round de estimação é feito para a mesma estória:

Com Planning Poker - Passo 3

Houve convergência, ainda que parcial. Então eles concordam que uma estimativa de valor 5 deve estar próxima o bastante e partem para a próxima estória.

Porque essa estranha série de números?

Cartas Os números grandes tem menos granularidade. Por quê? Porque não há o número 21, por exemplo? Algumas razões:

  • Aumentar a velocidade o processo de estimação limitando a quantidade de escolhas (número de cartas).
  • Evitar a falsa sensação de precisão (acurácia) para as estimativas mais altas.
  • Encorajar a equipe a dividir grandes estórias em menores.

Uma estimativa alta (maior que 20, por exemplo), geralmente significa que a estória não foi bem compreendida. Seria uma perda de tempo discutir se a estória vale 19, 20 ou 22,5. A estória é grande e pronto. Se for necessário detalhar a estória, deve-se quebrá-la em estórias menores.

Cartas Especiais

A carta “zero” significa que a estória já foi implementada ou que ela é ínfima, consistindo talvez em alguns minutos de trabalho.
A carta “interrogação” (“?”) significa que a pessoa não tem absolutamente nenhuma ideia. Nada. É raro acontecer, mas se a frequência aumentar a equipe deve discutir mais as estórias e tentar chegar a um melhor entendimento.
A carta “xícara de café” significa: “Estou cansado demais para pensar. Vamos fazer uma pausa”.

PSP – Personal Software Process

Não espere qualidade da sua empresa, seja a qualidade!

De quem é a culpa da má qualidade dos softwares?

Acho que todos já ouvimos falar sobre modelos de maturidade como CMMI ou MPS.BR e processos como o RUP, Scrum ou XP. Quase sempre isso vem acompanhado de comentários críticos e pessimistas de como a nossa empresa está longe de ser maduro e prover produtos de qualidade.

Por outro lado, mesmo empresas que investem em maturidade do processo muitas vezes esquecem que ele não é uma bala de prata. Não existe processo ótimo sem ótimas pessoas. É um mito industrial a possibilidade de criar um processo perfeito que seja independente do nível e da maturidade dos indivíduos envolvidos.

Isso pode ser bem observado na literatura sobre processos. Processos “pesados” ou rígidos são recomendados quando há equipes imaturas, sem experiência e disciplina adequadas. Já com equipes experientes, maduras e disciplinadas quase não existe necessidade de processo.

Por isso é que os processos ágeis, por exemplo, somente são recomendados quando há pessoas muito competentes envolvidas no projeto. Como disse meu orientador: “coloque uma equipe de juniors num processo ágil, eles vão começar a estimar usando planning poker e provavelmente vão continuar jogando poker até o final do projeto”.

O mesmo é aplicável a empresas que disponibilizam salas de entretenimento, por exemplo. Muita gente gostaria de trabalhar no Google e ter uma sala com vídeo-game, mas o que geralmente não se pensa é que qualquer vaga nesse tipo de empresa são preenchidas por pessoas maduras e focadas, que possuem muito compromisso e dedicação.

Resumindo, a culpa pela falta de qualidade e organização em uma empresa é compartilhada por todos os níveis da mesma. Porém, em teoria, todos sabem o que as empresas deveriam fazer.

Mas o que cada um pode contribuir, individualmente ou em equipe?

Após criador o CMM, Watts Humphrey aplicou todos os seus princípios até o nível 5 em projetos individuais durante 3 anos, financiado pelo SEI (Software Engineering Inistitute). Assim surgiu o Personal Software Processos (PSP). Enquanto o CMM ou CMMI é aplicado ao processo de engenharia de software de uma organização, o PSP organiza o trabalho individual de um engenheiro de software.

Antes de pensar numa certificação CMMI, as empresas deveriam focar em melhorar os indivíduos que a compõe através do PSP. Quando as pessoas amadurecem e passam a utilizar um processo pessoal de desenvolvimento por saberem que é algo bom, então adotar um modelo como CMMI é natural, pois elas já absorveram sua filosofia e não é necessário forçar ninguém a usar boas práticas de desenvolvimento que de outro modo não se entenderia a razão.

Mas o que é o PSP, afinal?

É um processo de desenvolvimento de software pessoal, que você e eu podemos adotar como engenheiros de softwares (desenvolvedores), independente do tipo de projeto e de onde trabalhamos.

O PSP é baseado nos seguintes princípios de qualidade e planejamento:

  • Todo engenheiro de software é diferente; para serem mais efetivos, os engenheiros precisam planejar o seu trabalho e devem basear os seus planos em seus próprios dados pessoais.
  • Para melhorar consistentemente seu desempenho, os engenheiros precisam usar pessoalmente processos bem definidos e com medição.
  • Para produzir produtos de qualidade, os engenheiros precisam se sentir pessoalmente responsáveis pela qualidade dos seus produtos. Produtos superiores não são produzidos por acaso; os engenheiros devem batalhar para fazer um trabalho de qualidade.
  • Custa menos encontrar e corrigir erros cedo em um projeto do que mais tarde.
  • É mais eficiente prevenir defeitos do que encontrá-los e corrigi-los.
  • O jeito certo é sempre o mais rápido e o mais barato de fazer o trabalho.

Enfim, os engenheiros de software devem adotar um processo pessoal bem definidos, medir e registrar o tempo que gastaram em cada atividade e a qualidade do produto que entregaram, ajustar o processo através dos dados obtidos para melhorar os próximos projetos e atividades, além de focar na qualidade do trabalho que desempenham.

A estrutura do PSP

A figura acima mostra o fluxo conceitual do PSP. Através dos requisitos, usa-se “scripts” como guia em cada case do processo (planejamento, modelagem, revisão da modelagem, codificação, revisão da codificação, compilação, testes e finalização). Em cada fase, dados de tempo e defeitos são coletados e consolidados com o que foi planejado, permitindo a avaliação do processo atual.

O PSP também provê boas práticas e guias para os diversos aspectos do processo pessoal: planejamento, coletagem de dados, qualidade (medição e prevenção), modelagem, disciplina pessoal, etc. Não entrarei em detalhes sobre cada um desses itens neste artigo, mas vamos a um exemplo.

A fim de prevenir defeitos num software o PSP estabelece o gerenciamento da qualidade através de três práticas:

  1. Anotar as causas dos erros que já ocorreram e usar esses dados para aperfeiçoar o processo de modo que esse tipo de defeito não ocorra mais, ou seja, que não se cometa os mesmos erros novamente.
  2. Usar método de modelagem e notação adequados para contruir o modelo completo, pois isso força o desenvolvedor a pensar e entender todo o domínio, o que resulta em menos enganos.
  3. Uma consequência direta do item 2: com o modelo completo e entendido, gasta-se menos tempo codificando, o que reduz a quantidade de erros. Estudos realizados em 298 projetos demonstraram que os engenheiros introduzem 1,76 erros por hora no design e 4,20 erros por hora na codificação, logo, quanto menos código melhor.
O maior desafio do PSP, o mesmo de qualquer processo, é que as pessoas que o adotam continuem a usá-lo com o passar do tempo. Uma forma de ajudar nisso é manter um ambiente que facilite ao indivíduo usar o processo. Para isso o SEI criou o Team Software Process (TSP), que, aplicado numa empresa, fornece aos engenheiros o ambiente disciplinado que eles precisam para o uso contínuo do PSP.

Resultados

A seguir, o gráfico de “Acurácia da Estimação de Esforço” demonstra que na medida em que o indivíduo progride no uso do PSP, ele fornece estimativas mais próximas da realidade. Após 10 programas desenvolvidos as estimativas melhoraram em aproximadamente duas vezes.

Já o gráfico de “Melhoria no Nível de Defeitos” demonstra que, na medida em que se usa o PSP, menos erros são introduzidos nas fases anteriores, ou seja, gasta-se menos tempo corrigindo problemas.

Por último, o gráfico de “Resultados de Produtividade” mostra que não houve mudança significativa no desempenho.

A conclusão do estudo, realizado com 298 projetos pequenos, é que o PSP ajuda a melhorar as estimativas e melhorar a qualidade através da redução de defeitos, embora a produtividade em linhas de código permaneça a mesma. Isso faz muito sentido, já que a melhoria na programação está mais relacionada com o conhecimento da linguagem e a lógica do desenvolvedor, os quais podem ser desenvolvidos através de estudo dirigido.

Fonte: http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm

Inserção em massa no SQL Server

Como inserir vários registros em uma tabela com valores sequenciais? Por exemplo, como podemos obter uma série de datas?

A resposta mais simples seria utilizar um cursor ou laço (loop), mas a execução de ambos é demasiadamente lenta para muitos registros. O desempenho máximo somente será obtido se a inserção for feita de uma só vez em um comando INSERT. Para isso, podemos usar uma tabela auxiliar com valores sequenciais de forma que possamos usar esses valores para derivar aqueles que necessitamos. Mas como obter tal tabela?

Uma das formas de unir velocidade e praticidade é criar uma tabela com um campo IDENTITY. Entretanto, não gosto da ideia de criar uma tabela física para auxiliar em operações completamente ortogonais às funcionalidades do sistema.

Opção fácil para poucos registros

A tabela MASTER..SPT_VALUES possui números sequenciais de 0 (zero) a 2047 e é nativa do SQL Server. O exemplo abaixo insere 2000 linhas com datas sequenciais de uma só vez:

INSERT INTO DATAS (DATA, DIADASEMANA)
SELECT DATEADD(d, NUMBER, @DATAINICIAL), DATEPART(DW,DATEADD(d, NUMBER, @DATAINICIAL))
FROM MASTER..SPT_VALUES
WHERE TYPE='P' AND NUMBER BETWEEN 0 AND 1999

Portanto, com essa tabela é possível fazer uma inserção em massa utilizando a coluna NUMBER e alguma função que calcule o valor do campo a partir do valor sequencial. No exemplo, a função DATEADD gera datas a partir da @DATAINICIAL, até 2000 dias à frente, e também armazena o dia da semana de cada data.

Porém, há uma questão sobre o uso de uma tabela do usuário MASTER, pois ela pode não ser acessível para você. E se não houver possibilidade de obter a devida permissão?

Utilizando uma tabela auxiliar em memória

Um outro método muito eficiente, mas que exige um pouco de Transact-SQL, é usar uma Variável do tipo TABLE. Confira o seguinte exemplo:

DECLARE @T TABLE (NUMBER INT)
DECLARE @I INT, @LIMITE INT

SET @I = 0
SET @LIMITE = 25000
WHILE @I < @LIMITE
BEGIN
    INSERT INTO @T (NUMBER) VALUES (@I)
    SET @I = @I + 1
END

Este código leva menos de 1 segundo para executar e cria uma tabela na memória com números de 0 a 24.999. Usando ainda o exemplo de geração de datas, podemos inserir 25 mil linhas de uma só vez, como mostra o novo exemplo abaixo:

DECLARE @DATAINICIO DATETIME
SET @DATAINICIO = '2001-01-01'
SELECT DATA, DATEPART(DW, DATA)
FROM (SELECT @DATAINICIO + NUMBER DATA FROM @T) T

Conclusão

Já usei várias vezes esse recurso para melhorar o desempenho de cálculos financeiros que envolvem parcelas, justo e vencimentos em feriados. Certa vez consegui diminuir o tempo de execução de uma procedure de cálculos, que levava 20 minutos para inserir 23 mil registros, para cerca de 20 segundos, gerando 150 mil registros.

Embora para alguns os exemplos acima possam soar como algum tipo de gambiarra, o conhecimento e a correta aplicação de tais recursos podem ser essenciaus quando as restrições de desempenho são prioridade.

SQL Server: o porquê do ponto duplo (“..”) para acessar outros bancos

Você já se perguntou por que usa-se um ponto duplo (“..”) para acessar uma tabela de outro banco de dados no SQL Server?

USE BD1
GO
SELECT * FROM BD2..TABELA

Já vi algumas pessoas questionarem e acho que a primeira reação é supor que seja uma espécie de operador especial.

Bem, para entender isso é preciso saber que um objeto (como uma tabela) no SQL Server possui uma identificação assim:

Servidor.BancoDeDados.Schema.Objeto

Com relação ao Schema, as pessoas criam geralmente todos os objetos no Schema padrão, o dbo. Como os objetos estão no mesmo Schema, especificá-lo é opcional.

Mas, quando esquecemos do “.dbo” nos CREATEs e outras DDLs, é bem provável termos problemas no futuro, pois o Schema padrão do usuário utilizado para executar scripts no cliente pode ser diferente. Já vi casos onde metade dos objetos ficavam num Schema e metade em outro.

Então, se você quer acessar uma tabela e está no mesmo servidor, usando (USE) o mesmo banco de dados e o mesmo Schema, poderá omitir todos estes utilizar apenas o nome da tabela:

SELECT * FROM Objeto

Agora vamos supor que você esteja usando (USE) um banco chamado BD1. Como faríamos para acessar uma tabela de um BD2? Seria tão simples como o exemplo abaixo?

USE BD1
GO
SELECT * FROM BD2..Objeto

A resposta é: depende!

Se os dois objetos não estiverem no mesmo Schema, então você deveria especificar o schema entre os dois pontos, assim:

USE BD1
GO
SELECT * FROM BD2.dbo.Objeto

Portanto, os dois pontos (“..”) seguidos significam que você está omitindo o Schema e solicitando ao SQL Server que utilize o padrão para o seu usuário.

Simples assim.

Plugin Sysdeo para Tomcat Melhorado

Numa empresa que usa o Tomcat como padrão, através do plugin Sysdeo do Eclipse, os desenvolvedores precisavam a todo momento executar clean refresh nos projetos, além de editar e salvar um arquivo texto qualquer ou ainda iniciar o Tomcat duas vezes, caso contrário o sistema não inicializava corretamente.

Aparentemente, tudo isso era necessário porque, ao ser iniciado pela primeira vez depois de alguma ação no Eclipse (recompilar código, por exemplo), o plugin não incluia os jars do projeto no classpath do Tomcat, acabando sempre num ClassNotFoundException.

Não me pergunte porque a empresa não muda de container ou usa o “Servers” do Eclipse.

Como esse problema afetava quase todos os desenvolvedores da empresa, preparei uma versão modificada do plugin Sysdeo, forçando um refresh no projeto e a resspectiva atualização das bibliotecas externas. Basicamente, duas linhas de código a mais na classe TomcatBootstrap.

Até hoje as alterações não apresentaram efeitos colaterais.

Para atualizar sua versão:

  1. Baixe o plugin aqui: com.sysdeo.eclipse.tomcat_3.3.1
  2. Feche o Eclipse
  3. Vá na pasta …eclipseplugins
  4. Remova a pasta do plugin antigo (com.sysdeo.eclipse.tomcat_x.y.z)
  5. Descompacte o zip na pasta de plugins
  6. Reinicie o Eclipse

Disponível em

https://github.com/utluiz/com.sysdeo.eclipse.tomcat

Evite reiniciar o Tomcat 6 e deixe a inicialização mais rápida

Otimizações geralmente não caem bem em ambientes de desenvolvimento.

Imagine um desenvolvedor tendo que reiniciar o Tomcat a cada alteração em arquivos estáticos ou JSPs durante o desenvolvimento de uma determinada tela do sistema.
Para evitar isso, altere o arquivo context da sua aplicação da seguinte forma, acrescentando ou modificando os parâmetros antiJARLocking e antiResourceLocking para false.
Exemplo:
<Context (...)
    antiJARLocking="false" antiResourceLocking="false">

Agora o Tomcat 6 vai iniciar mais rapidamente e reconhecer alterações nos arquivos do sistema, ficando apenas limitado a cache de frameworks, como JSF, por exemplo.

Explicação

O antiResourceLocking faz com que o Tomcat crie uma pasta TEMP e copie todos os arquivos da aplicação para lá. Então ele ignora o que está na pasta original da aplicação.

Algo semelhante aplica-se ao antiJarLocking, mas com os jars da lib.

Além de desperdiçar espaço em disco, isso atrapalha o desenvolvimento de telas. Ativar esses recursos é indicado para ambientes de produção.

Com isso, o Tomcat também vai iniciar mais rapidamente, porque ele não vai mais ficar sincronizando todos os arquivos da aplicação para a pasta TEMP.

Tomcat lento no Eclipse com o plugin Sysdeo

Numa empresa que usa Tomcat como web container, alguns desenvolvedores relataram uma lentidão na inicialização e na depuração dos sistemas.

Um colega disse que a única solução encontrada até o momento era criar um novo workspace e importar os projetos do antigo.

Depois de pesquisar um pouco, encontrei em num fórum pelo mundo afora (não vou lembrar onde) algo relacionado a breakpoints. Bingo!

Se você está enfrentando um problema semelhante, ou seja Tomcat + Eclipse + Sysdeo + Lentidão, apague todos os breakpoints e há uma grande chance do seu workspace voltar ao normal.

Oracle Certified Master, Java EE 5 Enterprise Architect (310-052)

A certificação de arquiteto é o último nível a ser alcançado dentro todas as certificações Java.

Um arquiteto Java EE seria capaz de definir a base tecnológica de um sistema em Java atendendo os requisitos não funcionais (segurança, escalabilidade, desempenho, disponibilidade, etc.) dentro das restrições do projeto.

Os requisitos são:

  • Ter certificação inicial como Programador Java
  • Ter pelo menos uma das certificações intermediárias, tais como: Componentes Web (JSP e Servlets), Enterprise Java Beans (EJBs), Desenvolvedor Java e outros.

Entretanto, o processo para concluir essa certificação não é tão simples como as demais.

Se você tem pretensão de atingir este nível, arranje tempo e prepare o bolso.

Em primeiro lugar, são três fases: uma prova, um projeto e um questionário sobre o projeto. Todos em Inglês. Cada um deve ser pago separadamente (uns 300 e poucos reais).

Além disso, dependendo do seu nível de experiência com Java, você terá que estudar diversos materiais.  Entre as bibliografias que eu recomendaria estão:

  • Design Patterns do GoF
  • Core JEE PAtterns (2ª ed.)
  • SCEA for Java Study Guide (2ª ed.)

Porém, a lista contempla apenas a primeira fase, ou seja, a prova. Esta contém 64 questões e deve-se obter pelo menos 60% de aproveitamento. Em geral as questão contém um cenário específico e você deve identificar a melhor solução para o dado cenário.

Em nenhuma das fases é necessário conhecer as APIs em detalhes, como decorar tags, métodos e itens do Deployment Descriptor, mas deve-se ter conhecimento abrangente das APIs e suas respectivas capacidades, aplicabilidades, vantagens e desvantagens. As principais APIs são: JSP, Servlet, JSF, EJB 3.0, JPA, JMS, JAX-WS (é bom saber o básico sobre JAXB, JAXR e StAX), JAAS, SAAJ e JMX. Então já se prepare para estudar ainda outros materiais diferentes.

A segunda fase consiste em propor uma arquitetura para um sistema fictício atendendo os requisitos não funcionais propostos. A modelagem pode ser feita usando UML e sua correta utilização conta na nota. Para quem possui relativa experiência com UML e passou a fase anterior, este passo deve ser mais fácil, pois são requeridos apenas quatro diagramas (classes, componentes, deployment e sequência ou colaboração).

Na terceira e última fase você responde a um questionário com 8 questões abertas sobre a segunda fase, de forma a provar que foi você quem fez a arquitetura e verificar se suas decisões de projeto foram tomadas conscientemente (por exemplo, a API X foi usada para atender o requisito de desempenho ainda que sacrificando a manutenibilidade). Esta fase é a mais fácil, desde que você tenha realmente feito o projeto e consiga se expressar em Inglês.

Enfim, é um longo caminho (principalmente na primeira fase), correspondendo tanto monetariamente quanto em dificuldade à quase 3 certificações distintas.

Para saber mais, veja a página oficial.


Update:

Desde o ano passado, a Oracle definiu que seria obrigatório realizar um curso, dentre alguns reconhecidos por ela, além de passar nas 3 fases da certificação de arquiteto. Isso não me casou tanta surpresa, já que as demais certificações dessa empresa dependem de cursos.

Porém, todavia, entretanto, contudo… não considero justo obrigar profissionais que usam uma determinada tecnologia, software ou ferramenta diariamente, enfim, conhecem todos os detalhes, a pagar pelo curso para obter um certificado, o qual obteriam sem nenhum problema apenas estudando por conta, como é o meu caso.

Sei que estou advogando em causa própria, mas fica aqui o meu singelo protesto.

Página 14 de 16

Creative Commons O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.