Começando do zero! Veja quais são as principais tecnologias exigidas do desenvolvedor .NET

Olá a todos.
Obrigado a todos pelo feedback do meu último post. Foram mais de 3100 acessos (até o momento), muitos RTs no twitter, posts no facebook, LinkedIn e alguns e-mails. Bacana ver que foi útil. E prometo compilar todos os feedbacks e fazer um post de complemento dentre alguns dias.

Bom, continuando nosso raciocínio, já parou pra pensar o quanto você estuda e sempre aparecem coisas novas… e mais… e mais… e mais? Pois é. É bastante “letrinha”. E exige uma certa organização que já falei em outro post (vale a leitura).

Esses dias abri uma planilha e comecei a listar as tecnologias que eu já sabia, o que eu estava estudando e o que precisava saber. E ao mesmo tempo pensei “E se eu estivesse começando do zero? Seria muito legal ter a visão do que trilhar e por onde seguir.”.

Por onde começar?Um certo tempo atrás precisávamos saber “apenas” HTML, CSS, JavaScript (pouco) ASP e FTP. Agora a situação é bem diferente.

Coincidentemente vi pelo twitter o recente post do MVP de ASP.NET Ashraf Alam que tem nexo com a lista que eu tinha feito. Então com base nesta ideia, adicionei mais duas colunas ficando:

  • Coluna Tipo: Onde estou trabalhando? Em qual camada de interesse?
  • Coluna Finalidade: Em qual ocasião devo usar?
  • Coluna Tecnologia: o nome da tecnologia

tabela

Considerações:

  1. Em negrito e em fundo mais escuro as tecnologias essenciais, de escala 1 (as que você precisa dominar primeiro).
  2. Esta é uma lista para uma pessoa com perfil em desenvolvimento web utilizando .NET
  3. A lista trata-se apenas de tecnologia e ferramentas. Boas práticas, conceitos, padrões e técnicas não estão contidos aqui.
  4. Esta é uma tentativa de clarear o que cada coisa faz e que tecnologia atenderá isso.
  5. Poderia ter uma coluna de prioridade (preferi pintar o fundo de uma cor mais forte para destacar dos demais).
  6. Acabei não colocando coisa muito específica (como frameworks de testes, mocks, etc) e outra tecnologia mais avançada e não tão popular ainda (como dapper).
  7. Esta planilha está no GitHub. Alterem a vontade, republiquem, alterem…
    1. UPDATED: Já recebemos alguns pull requests e a planilha já se encontra atualizada e de fácil colaboração.
  8. Pretendo atualizar este post sempre que necessário. Irei adicionar um texto com uma data em cada update.

O Scott Hanselman fez um post sobre o “que você precisaria aprender caso fosse recomeçar denovo”, muito bom, leia. O Marcos Vinícius fez uma versão bem detalhada para Front End Developers. Vale a pena ver também.

Para developers .NET é isto.
Dá pra melhorar, acessem o repositório do GIT e ajude a manter esta lista para uso e referência de todos.

É isso.. Abraço!

10 Coisas que todo desenvolvedor .NET deveria saber

Algumas pessoas sempre me perguntam o que é preciso saber para ser um desenvolvedor .NET. Confesso que não gosto de falar aquela resposta padrão: “basta ter lógica de programação”, mas também acabo não respondendo com exatidão e então resolvi criar um artigo para que toda vez que me perguntarem eu direcionar para este post.

A lista abaixo é simples e básica. Mas são perguntas que geralmente são feitas em entrevistas de emprego e que nem sempre são respondidas como devem ser.

Para alinharmos, levantei alguns tópicos que são essenciais. Assim como um jogador de futebol tem que chutar e cabecear para ser um jogador, um desenvolvedor .NET* precisa saber no mínimo os dez itens abaixo (* estou abstraindo o skill de software developer, que está contido aqui, mas é um pouco maior). Vamos lá:

#1 Conceitos de Orientação a Objetos (OOP)

Sim. Os conceitos. O desenvolvedor .NET deve pelo menos ser capaz de explicar os principais conceitos de OOP em uma maneira muito simples. Estas são habilidades básicas e se tiver alguma dificuldade é bom parar por aqui, reforçar e consolidar esta fase. No site da MSDN tem um conteúdo legal.

#2 Princípios SOLID

Os princípios do SOLID, criado pelo Robert Martin (Uncle Bob), são diretrizes que podem ser aplicadas ao codificar para evitar ou refatorar o que o Martin Fowler chama de code smell. Ou seja, algo que indica que tem um problema ou não está legal no código.

SOLID exige que você seja bem resolvido com o #1 que acabamos de falar.

O Shivprasad Koirala, MVP da Índia, escreveu o artigo SOLID architecture principles using simple C# que deixa explica bem cada letra do acrônimo SOLID utilizando C#.

#3 JavaScript, jQuery, C# e ASP.NET

Estes quatro itens estão no eixo principal do conhecimento do desenvolvedor .NET (exceto em algumas exceções (neste ponto) onde o ASP.NET não está incluso, como no desenvolvimento de aplicações Windows Client, Phone Apps, Games, Serviços entre outros)

Os desenvolvedores não podem saber apenas C# e SQL. Só isto já não mais basta. Hoje é exigido bem mais, como trivial HTML e CSS e outras linguagens e frameworks como AngularJS, RequiredJs, NodeJs, KnockoutJS, etc. E para javaScript, em questão, é preciso saber basicamente a escrever o código JS que os patterns como Module e Closure vão te ajudar demais.

#4 Garbage Collector e IDisposable

Uma das melhores características de desenvolvimento .NET é a falta de esforço e preocupação para destruir instâncias de objetos, cancelar assinatura de eventos, fechar fluxos, etc. Geralmente você deixa isto para o Garbage Collector, que “tudo fica bem”. Muitos developers não se preocupam, ou nunca analisaram o 1º,2º ou 3º ciclo de coleta do gen. Atitudes como podem gerar catastrofes no seu código como o conhecido Memory leaks. Parece que a preocupação com o controle de memória praticamente não há com desenvolvedor atual. É importante saber como funciona.

Uma maneira útil de garantir que os recursos gerenciados estão corretamente limpo em tempo hábil é implementar a interface IDisposable em seus objetos. Entenda mais e veja como controlar isto nos links abaixo:

#5 Box e UnBoxing

Ainda falando sobre memória e performance, este é um problema tratado deste o .NET 2.0 e que até hoje vários desenvolvedores não entendem box e unboxing e acabam afetando o desempenho e uso de memória do software.

#6 Tipo por referência e tipos por valor

Quando um recrutador lhe pede para explicar este problema de box/unboxing, eles também podem te pedir para explicar a diferença entre os reference types e os value types. O tipo de valor pode ser considerado como o valor real de um objeto, enquanto um tipo de referência, tipicamente, contém o endereço do valor real, ou nulo.

#7 Diferença entre MVC e WebForms

Também é um passo base. É importante saber a diferença, benefícios e contras que cada um possui mesmo que o resultado possa ser “semelhante” a princípio. O que na verdade não é!

O webforms tem uma maneira bem direta e simples no desenvolvimento, mas é bem difícil controlar a interface como é possível obter usando MVC utilizando JavaScript e o CSS. E isto é fundamental quando está desenvolvendo aplicações ricas e inteligentes.

Rolou uma discussão boa desse assunto no Programmers Stack Exchange e você pode acompanhar um pouco lá.

Vale também entender o ASP.NET SPA no meio disso tudo também.

#8 Banco de Dados SQL, Oracle e No-SQL

SQL Server e Oracle são essenciais, mas não são os “fazem tudo” de qualquer cenário. É hora de acordar e observar que vários outros cenários podem ser atendidos com bancos No-SQL.

Os bancos de dados No-SQL estão ganhando força enorme por causa de sua velocidade geral, facilidade de uso e benefícios de escalabilidade. Existem vários. Mas os mais conhecidos são:

#9 Visual Studio IDE

Atalhos, Plugins de terceiros, NuGet, etc. Conhecer as teclas de atalho faz toda diferença, pois você imageganha velocidade na execução das tarefas. Trabalhar com plugins certos como o PowerTools, TestDriven, Web Essentials, entre outros.

imageHá vários apaixonados pelo ReSharper, tanto que se desinstalar da máquina já não consegue fazer mais nada. Por isto eu recomendo instalar este plugin apenas depois que estiver bem seguro ou familiarizado com o desenvolvimento C#.

#10 Reference Source – O código fonte do .NET Framework

Bom, o reference source é o código fonte do .NET Framework disponível para consulta. Dai você pode falar: “mas pra que eu preciso do código fonte?”.

A resposta é que você pode aprender muito mais do .NET vendo como o código foi escrito, como ele funciona e como ele se comporta. Esta curiosidade de ver o código precisa ser uma constante.

Pode ser acessado pelo endereço http://referencesource.microsoft.com


O Scott Hanselman escreveu uma lista em 2005 (claro que está obsoleta), mas tem algumas coisas relevantes que não citei como por exemplo Reflection, diferença entre Orientação a Interface x Orientação a Objetos x Orientação a Aspectos. Atualizando, poderia citar muitas outras coisas como o próprio LINQ, Delegates, Generics, usar o Nuget, fazer deploy em nuvem. entre outras coisas de base.

Particularmente, eu posso dizer que se você se sentiu pouco seguro em alguns dos tópicos acima reserve um tempo na sua agenda e corra atrás para estudar, tirar dúvidas e treinar. Principalmente se você pretende trabalhar em boas empresas ou nos USA onde os processos seletivos exigem bem esta base sólida.

Para encerrarmos por aqui, deixo uma boa dica de leitura para complementar o conteúdo: The 4 Most Important Skills for a Software Developer.

Quer completar? Ficou algo de fora?
Vamos lá.. Nos ajude a completar…

Abraço!

LINQ – Any() x Contains()

Existem dois tipos de developer: os que apenas querem fazer funcionar e os que querem entender o que estão fazendo para fazer funcionar direito (leia-se bem feito).

Se você é o segundo, provavelmente já se questionou em algum momento quando se usa Any() ou Contains() nas consultas com LINQ. É claro que a resposta é: depende! (hehe). Em grande parte dos casos o resultado será o mesmo e o comportamento semelhante.

Só para recaptular:

Contains() é um método e o seu desempenho depende muito do próprio uso. Em um List tem complexidade O(n), enquanto em um HashSet seria O(1).

Any() é um método de extensão, é mais flexível. Podemos aplicar uma lambda/delegate. Isto teria uma complexidade de O(n).

Vale lembrar que Contains() também possui um método de extensão IEnumerable<T>, que pensando bem, possui uma instância em quase todas coleções.

Se você for fazer algum benchmark, verá que em grande parte das vezes o Any() é um pouco mais lento que Contains() porque não precisa invocar um delegate para cada elemento, ele utiliza a instância Equals. (apenas e se o tipo T não implementa a interface IEquatable<T>) Mas no final das contas se você olhar para a complexidade uma a uma, esta performance será quase a mesma. Agora acho que deu pra entender o porque da resposta “depende”.  =)

Se ainda não deu pra entender, veja bem:

Any()
Determina se qualquer elemento de uma seqüência satisfaz uma condição.
IEnumerable.Any(Extension method)
colecao.Any(i => i == 1);

Contains()
Determina se um elemento está em uma coleção.
IEnumerable.Contains(Object Method)
colecao.Contains(1);

E ainda também temos o Exists(), que não falamos aqui. Ele determina se a List(T) contém elementos que atendam às condições definidas por uma condição.
List.Exists (Object method)

Mas nem tudo são flores.
Usando Contains() com Entity Framework/NHibernate a saída SQL será transcrita para a clausula “WHERE IN”. E aí que mora o perigo, pois isto afeta o desempenho da aplicação, além do problema de alguns bancos como o Oracle que tem o limite de 1000 na clausula IN (ou seja, passou disso você tem 2 problemas).

Para o Entity Framework 6 o problema de performance utilizando Contains foi melhorado, quanto à clausula IN fique atento nos testes para atender o seu cenário e caso seja preciso um Join resolve.

Já passou por algo semelhante? Está usando o EF6? Mande seu feedback. =)
Abraço.

<Post atualizado (em vermelho) com a contribuição do Rodrigo Vidal e Abner das Dores.>

MVP Award, 7 anos consecutivos

Este é apenas um post de comemoração.
Pelo 7º ano consecutivo recebi o título de MVP da Microsoft e isto não me torna melhor do que ninguém, mas me torna mais motivado profissionalmente e ainda mais motivado em estar engajado dentro da comunidade técnica fazendo o que fiz nestes últimos 12 anos.

Abaixo um pedaço do sonhado e-mail…

Abaixo o meu award ficando bem bonito a cada ano que passa. =)

 

Agora é aguardar o momento para retornar a Seattle no MVP Summit deste ano, que sem dúvida é um dos grandes benefícios de ser um MVP.

Estaremos em sinonia…
Abraço.

User Group Meeting – ASP.NET Identity

E retornamos os encontros técnicos!
Hoje, em pleno sábado de copa do mundo reunimos logo cedo para colocar em pauta o ASP.NET Identity, que por sinal ficou bastante flexível e sintético.

top.crop_1170x350_0,0

O código e os questionamentos levantados estão no GitHub do DevGoiás e caso você queira se juntar a nós, você pode participar e colaborar por lá também.

O slide é básico, focamos mais no código. De toda forma serve para referência. Está abaixo:

foto
Membros do grupo produzindo código. Produtivo.

Agradecimento aos sponsors desta reunião: GitHub, Apress, Microsoft, JetBrains e Not In California que gentilmente nos concedeu o espaço.

Se você quer participar do próximo encontro, fique ligado no meu twitter e no canal do DevGoiás no Facebook.

Até a próxima!

UPDATE 1

Na reunião surgiu uma dúvida da migração do Membership para o Identity. E no final da semana saiu um txt no projeto do Identity do Codeplex com as instruções e scripts para esta migração. Caso alguém teste esta migração deixe o feedback.

https://aspnet.codeplex.com/SourceControl/latest