Arquivo da categoria: Técnicas

.NET, Banco de Dados, Certificação, Dica de leitura, Mova-se, Técnicas, Visual Studio

Certificações Microsoft – Por onde começo?

Olá pessoal, o objetivo desse post é esclarecer um pouco mais sobre a nova linha de certificações Microsoft, e também ajudar a direcionar aquele profissional que pretende obter uma certificação mas não sabe por onde começar.

A Microsoft criou uma linha de certificações chamada MTA – Microsoft Technology Associate. Essas provas são a “base da pirâmide” para uma carreira nas tecnologias Microsoft. O objetivo dessas provas são fornecer um conhecimento sólido dos fundamentos na tecnologia em que você pretende se especializar. Fazendo uma prova MTA, você já é um MTA Certification e já possui os conhecimentos fundamentais para seguir em frente.

Dentro do nível MTA, o profissional deve escolher qual área pretende seguir carreira, podendo optar por uma das três áreas conforme figura 1.

Áreas Microsoft

Figura 1 – Áreas na plataforma Microsoft

Mais detalhes: http://www.microsoft.com/learning/en-us/mta-certification.aspx

Como já sabemos o nível MTA visa garantir o conhecimento necessário para as outras provas (MCSD e MCSA ou quem sabe um dia MCM), então essa prova é obrigatória? Não, você não precisa se tornar um MTA para fazer as outras provas. Se você já é um profissional que tem experiência na sua tecnologia, então você pode pular esse nível. Porém se você está começando agora, certamente esse é o seu ponto de partida na carreira.

Em resumo, agora temos o nível MTA (de cada área) para iniciar, e a partir desse nível, cada um escolhe a carreira que pretende seguir. Para compreender melhor como ficou o RoadMap das provas vamos ver a figura 2.

Provas Microsoft

Clique para Download em PDF.

Figura 2 – RoadMap das provas

Existem dois centros de testes que você pode agendar a sua prova, Certiport para quem é estudante e Prometric para quem não possui nenhum vínculo acadêmico. Para o caso dos estudantes, é necessário verificar se a sua instituição está registrada no Certiport, verifique com seu professor ou chefe do departamento.

Um caminho para aprender e ajudar na preparação para as provas no nível MTA é através do Microsoft Virtual Academy que oferece diversos treinamentos gratuitos para desenvolvedores, profissionais de infra e banco de dados.

Lembrando que o mercado está carente de profissionais qualificados, enquanto sobram ideias, planos de marketing, investimentos dos mais variados, profissionais com uma boa qualificação ainda são uma pequena parcela do mercado, portanto uma certificação será muito bem vinda!

 Abraços!

Padrão
.NET, Boas Práticas, Técnicas

String VS StringBuilder – O Coiote não pega o Papa Léguas!

O título desse post remete a dois personagens bem conhecidos de todos (principalmente das crianças) em que um deles sempre tenta capturar o outro, porém esse último é muito mais veloz e raramente se dá mal. A ideia por trás dessa analogia é que algumas vezes tentamos utilizar tipos de dados com limitações de desempenho em nossos códigos e então saímos fazendo mil coisas (“gambiarras”) para tentar se aproximar do melhor desempenho possível, nem preciso comentar o resultado final. Esse fato no leva ao problema de atualização de conhecimento, pesquisas, estudos sobre as novidades de uma linguagem e/ou uma ferramenta. Aquela famosa frase “Para quem só conhece o martelo como ferramenta, parafuso é prego” cabe perfeitamente aqui.
Quando precisamos trabalhar com strings, o primeiro tipo que vem a mente é o tipo String ou string (essa última é apenas um apelido). Legal, esse é o tipo mais conhecido, e naturalmente, mais usado. Acontece que um objeto do tipo String é imutável, o que isso significa? Significa que uma vez atribuído um valor a um objeto desse tipo, esse valor jamais mudará, isso mesmo, jamais mudará. Mas então como eu consigo fazer concatenações e o novo valor é atribuído ao objeto? O que ocorre por baixo dos panos é algo que talvez você nunca imaginasse, a cada nova atribuição de valor a um objeto String, é criado um novo objeto semelhante que agora contém o valor antigo mais o valor atual. Isso mesmo, um novo objeto é criado e isso é transparente aos desenvolvedores. Você simplesmente solicita o valor do objeto e lá está ele.
No momento em que um novo objeto é criado, o objeto antigo continua na memória heap a disposição do garbage collector. A figura 1 mostra esse cenário, podemos ver que ao final das concatenações sucessivas temos um único objeto que iremos trabalhar e mais quatro objetos aguardando para serem eliminados da memória.

StringVSStringBuilderFigura 1

A cada nova iteração criamos um novo objeto e descartamos o antigo, isso causa um overhead imenso nas aplicações e um péssimo aproveitamento da memória do computador. Ma então o que devemos fazer quando precisarmos utilizar strings em iterações? A solução presente no .NET chama-se StringBuilder. Essa classe foi especialmente desenhada para trabalhar com strings dinâmicas, strings em que o valor muda constantemente e garante uma performance excelente quando recebe grande quantidade de dados. Os métodos disponíveis para trabalhar com StringBuilder fazem uma referência a mesma instância e não a uma nova como no caso da String. Vamos ver na prática como isso funciona. A figura 2 mostra dois métodos, o primeiro faz um loop de 20000 iterações utilizando um objeto StringBuilder e ao final exibe em milissegundos o tempo gasto. O segundo método faz a mesma coisa porém utilizando um objeto String.

ExemploCodigo

Figura 2

ExemploStringBuilder_2

Figura 3

Ao compararmos os resultados da figura 3, podemos concluir a enorme diferença no tempo de execução. Quando chamamos o método que utiliza String, gastamos um tempo de 2637 milissegundos e o mesmo loop utilizando StringBuilder consumiu apenas 10 milissegundos.
Então o tipo de dados String é um tipo ruim de trabalhar? A resposta é que String não é um tipo de dados ruim para trabalhar, porém ela atende exatamente aquilo que ela se propôs a atender, trabalhar com strings estáticas ou com poucas mudanças.

Abraços!

Padrão
Boas Práticas, Fundamentos, Técnicas

Design Patterns – Singleton

Olá Pessoal,

No mundo da O.O. uma das  práticas que podemos aplicar em diversos cenários são os Design patterns (ou Padrões de Projeto), que por sinal são modos de resolver problemas recorrentes e que garantem boa reutilização e também expressam de uma forma elegante a resolução de um determinado problema.

Os Design Patterns são classificados em:

  • Padrões de Criação;
  • Padrões  de Estruturas e
  • Padrões de Comportamento.

Cada uma dessas classificações acima englobam diversos tipos de padrões. Nesse post abordaremos o Design Patterns chamado Singleton. Esse Pattern é caracterizado por permitir apenas uma instância de um objeto no sistema e fornecer um ponto de acesso a essa instância, sendo caracterizado como um padrão de criação.

Existem contextos em que poderá haver a necessidade de ter esse tipo de implementação. Por exemplo com classes que possuem dados sobre o sistema, sobre um determinado dispositivo. Imagine que você esta trabalhando em uma aplicação mobile e precisa capturar algum dado do aparelho, ou atualizar determinada informação. Outro exemplo seria configurações de um aplicativo que poderiam ser solicitadas em determinados momentos da execução. Diversos são os cenários que podemos aplicar essa técnica.

O padrão Singleton também é alvo de várias discussões, alguns acham que não há necessidade de utilizar dessa forma, outros preferem combinar padrão Factory, pois poderá limitar a herança e/ou polimorfismo. Enfim, essa é uma discussão para outro momento.

Para transformar uma classe em Singleton existem 3 modificações a serem feitas na classe.

1 – Criar uma instância privada e estática dessa classe;

2 – Criar um método que seja o ponto de acesso ao único objeto criado e

3 – Tornar o construtor padrão privado.

Abaixo temos uma classe chamada Dispositivo bem simples, vamos transformá-la num Singleton. A classe possui dois atributos (Marca e Modelo) e dois métodos chamados Ligar e Desligar além da sobrecarga do método ToString Conforme figura 1.

Singleton1Figura 1 – Classe Comum de Um Dispositivo

Com a nossa classe comum, vamos fazer as três alterações citadas acima para transformá-la num Singleton. As alterações podem ser acompanhadas na figura 2.

Singleton2

Figura 2 – Classe com as alterações necessárias para atender o padrão Singleton.

A partir desse momento, a forma de utilização dessa classe deixa de ser como já conhecemos, não podemos mais instanciar um objeto dessa classe usando o operador new, isso é feito internamente pelo método getInstance que passa a ser o nosso ponto de acesso ao objeto da classe Dispositivo. Na figura 3 podemos ver como deverá ser utilizada.

Singleton3Figura 3 – Exemplo de uso

Essa é a forma que deverá ser utilizada. O método getInstance, verifica se há alguma instância já criada, caso não haja, será criada uma nova instância senão, ele retornará a instância já existente. A Figura 4 mostra o exemplo em funcionamento.

Singleton4

Figura 4 – Exemplo em execução

Bom, essa é uma forma de tratar um tipo de situação num determinado contexto, porém isso exige cuidado na aplicação ou seja, quando aprendemos sobre Design Patterns, costumamos contrair uma doença chamada “Patternite” onde queremos aplicar sempre, seja qual for o pattern. Porém o ideal é deixar que a plicação “peça” o padrão mais adequado, o desenvolvedor perceberá que aquela situação será bem tratada se for aplicado o pattern X.

Quanto ao Singleton, existe um detalhe que será comentado num próximo post, ele não é thread safe, ou seja se mais de uma thread solicitar esse objeto, teremos problemas, e existem formas de contornar essa situação que serão vistas em breve!

Abraço!

Padrão
Processos, Técnicas

Agilidade X Qualidade de Software

 Olá pessoal, um dia desses, a Sara Barbosa colocou a seguinte questão no twitter: “Agilidade não é o mesmo que qualidade, Qualidade não é o mesmo que agilidade ?!” Preferi não responder na hora pois essa é uma questão que envolve muitos pontos de vista, e são inúmero os fatores que podem influenciar um projeto. A interpretação que dei a essa questão é se um produto desenvolvido de forma ágil sempre terá qualidade e se um produto de qualidade significa que foi desenvolvido de forma ágil.

Bom, primeiro precisamos ter uma definição sobre o que é qualidade de software. O primeiro ponto, sobre esse assunto é, qualidade para quem? Cliente ou desenvolvedor ou ambos? Claro que o ideal é que o produto tenha qualidade para o cliente e para o desenvolvedor, pois isso resultará em bons resultados na entrega, manutenção e evolução do software.

Os processos ágeis têm como principal objetivo a adaptação as mudanças, pois sabemos que elas são inevitáveis. A partir do momento em que começamos a parar de lutar contra as mudanças e passamos a utilizá-las para atingir o nosso objetivo, teremos como resultado um produto com maior qualidade para o nosso cliente e também para os desenvolvedores. Existem práticas ágeis de desenvolvimento que contribuem muito para obter um código mais limpo, mais legível e consequentemente mais fácil de manter e evoluir. Práticas da XP (Extreme Programming) como programação em par e TDD são bons exemplos que podemos utilizar. Portanto, quando trabalhamos com processos ágeis, estamos mais próximos dos objetivos e consequentemente da qualidade do produto.

Quando temos um produto de software de boa qualidade nas mãos, não necessariamente isso significa que ele foi desenvolvido por um processo ágil. Em primeiro lugar, vamos analisar a seguinte questão: Qual é a metodologia (ou processo) de desenvolvimento mais ágil que existe? Talvez muitas coisas venham em sua mente agora, mas a resposta a essa pergunta, é o famoso DEPENDE. Por que? Porque a agilidade empregada em uma organização pode variar, ela depende do tamanho do time de desenvolvimento, depende dos recursos disponíveis, do tamanho do projeto, da presença de alguém fornecendo feedback e acompanhando o desenvolvimento do produto, etc. Para uma organização envolvida em um projeto de grande porte, geograficamente distribuído e envolvendo dezenas de desenvolvedores, talvez um RUP seja o processo mais ágil que eles consigam trabalhar, ou até mesmo um Waterfall. Nesse cenário, o caminho até o objetivo final pode ser mais oneroso, mas isso não significa que o resultado não seja um produto de boa qualidade.

Portanto, adotando processos ágeis estamos caminhando para um resultado de qualidade, tanto para o cliente quanto para o desenvolvedor, porém a agilidade não é o único caminho para se atingir a qualidade esperada num produto de software, sendo assim, qualidade não necessariamente significa agilidade.

Recomendo fortemente dar uma lida no texto produzido por Klaus Wuestefeld entitulado:  O Círculo Vicioso do Software Retranqueiro, retrata bem o cenário que vivemos no desenvolvimento de softwares.

Padrão
Técnicas

Não testar x TDD

Olá pessoal, esse post foi sugerido por um amigo meu, Leonardo Cidral, ele indicou esse assunto, e é um tema bem interessante e que está cada vez mais em evidência no desenvolvimentos de softwares, então vamos lá.

Testar aplicações deve ser um item primordial do desenvolvimento de sistemas, faz parte do seu profissionalismo. Você não terá um sistema estável, fácil de modificar, com baixo custo de manutenção se você não realiza testes. Isso mais cedo ou mais tarde, acarretará grandes problemas.

Existem 2 tipos de desenvolvedores  que não realizam testes:

  •  Chuck Norris
  •  Desenvolvedor amador

Você é Chuck Norris? Provavelmente não, então já sabe qual sua classificação.

“Desenvolvedor que não testa, é como um cirurgião que não lava as mãos!” (Robert C. Martin “Uncle Bob”). 

Mas o que é TDD?

A sigla significa Test Driven Development – Desenvolvimento Dirigido por Testes. È uma técnica que visa escrever os testes antes mesmo de escrever o código fonte! Estranho? No começo pode parecer que sim, mas com o tempo você verá os benefícios que ele trará no seu dia a dia.

Essa prática foi popularizada por Kent Beck na eXtreme Programming (XP), ela parte da ideia que será escrito um código apenas para o teste falho passar. Não haverá linhas de códigos desnecessárias no seu sistema, cada parte do seu código será testada antes de entrar em produção.  

Como funciona?

TDD = Test First Desing (TFD) + Refactoring

A primeira coisa a se fazer é escrever um pequeno teste antes mesmo de o código existir.  O primeiro teste escrito irá falhar, claro, ainda não há código para testar, em seguida você escreve o código e testa novamente, se passar, o próximo passo é a refatoração. A partir daí esse é o ciclo que será seguido. É importante que você avance os testes seguindo os baby steps, ou seja, avance em passos bem curtos, para ter um bom controle do seu código, com o passar do tempo, você começa a adquirir segurança nessa técnica, pode ir um pouco além, mas é sempre prudente e recomendado que não avancemos muito na hora de escrever um teste.

Fluxo TDD

Um desing limpo e agradável.

Imagine a seguinte situação, você vai até a cozinha prepara o alimento, se alimenta e sai, você não lavou a louça. No dia seguinte repete a situação, e no outro também e assim vai fazendo…. Essa rotina de preparar se alimentar e sair, é a mais rápida nesse momento, você consegue ganhar tempo com isso, porém algum tempo depois você terá uma cozinha imunda, você não tem nem coragem de entrar nela, a sua vontade nesse momento seria eliminá-la do resto da sua casa e reconstruir uma nova, nem as baratas conseguem sobreviver mais lá.

Essa analogia, é exatamente o que ocorre com os códigos  criados de qualquer jeito, chega um momento que os programadores têm medo de fazer qualquer alteração, aquele fonte agora tem vida própria, é praticamente um hardware, é impossível alterar ele sem causar outros problemas. Durante  o seu desenvolvimento, as funcionalidades eram adicionadas sem o mínimo de cuidado, não havia refatoração nesse código, não havia o mínimo de boas práticas, havia muito CTRL+C e CTRL+V. Não podemos negar que há também outros fatores que contribuem para isso.

O TDD garante um desing limpo, ágil, produtivo no momento atual e no futuro também. Todo o seu código fonte é escrito na medida em que atende a especificação, nada além disso será necessário, em seguida você executa o teste e se ele passar, pronto, só refatorar . Quem está no comando agora são as especificações de testes que foram criadas, elas são quem guiarão o seu fonte para atingir o resultado.

Quando você usa TDD, seu resultado será um código bem testado, refatorado, limpo, onde  sua manutenção será extremamente rápida e produtiva hoje e no futuro, e não haverá funcionalidades surpresa para o usuário, o código está livre de bugs, o programador tem segurança no seu código, grandes alterações não afetarão o funcionamento do sistema.Precisamos deixar claro que o TDD não é de uso obrigatório, mas testes SÃO OBRIGATÓRIOS

Um ponto que merece ser destacado é que o TDD se utiliza dos testes para dirigir o desenvolvimento, mas o foco real é o design da aplicação, e não os testes, ou seja, no momento que você escreve um teste e o código ainda não existe, então não há testes nesse momento, o que há é uma especificação para atender um determinado requisito, no instante seguinte, você escreve o código, realiza o teste e ele passa, agora você tem um teste nas mãos, mas antes disso aquela especificação não testava nada, apenas especificava algo. 

No exato momento em que escrevo esse post (02:25 da manhã), vejo na tv uma reportagem sobre o sistema da Prodesp que está causando uma enorme dor de cabeça para unidades do DETRAN em São Paulo, o sistema trava, e não mais retorna, alunos são dispensados das aulas, outros aguardam um tempão para tentar fazer suas aulas, os funcionários estão no limite da paciência. A Prodesp se manifestou por telefone, informando que tem conhecimento do problema, e está trabalhando para corrigir. Alegam que o problema tem como causa, o grande número de instrutores que acessam o sistema simultaneamente.

Será que existe algum teste que poderia prever essa situação? Claro que sim! Será que tiveram o cuidado de fazer? Acho que a reportagem já respondeu!

Atenção! TESTES SÃO OBRIGATÓRIOS!

Referências:

 http://www.agiledata.org/essays/tdd.html

http://unplugged.giggio.net/unplugged/post/TDD-nao-existe.aspx

Abraços!

Padrão