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 em um único dia, 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, planilha foi transposta para a página do GitHub e 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!

Sincronizando rascunhos do Live Writer com a nuvem via Skydrive

<updated 08/01/2014>

Se há uma ferramenta boa que eu gosto para manter meu blog, esta é o Live Writer. Agendo meus posts, escrevo offline e além da agilidade para editar, inserir fotos, etc.

Porém, mesmo nessa versão 2012 do Windows Essentials, não veio uma atualização simples que esperávamos: a de mudar o local onde os posts são salvos.

Mas para que você quer mudar o local? (o padrão está em c:\users\seuusuario\My Weblog Posts)
Para sincronizar todos meus posts e rascunhos com o SkyDrive. E isto ajuda muito.

Abaixo como você pode fazer isto de forma simples e fácil.

  • Antes de tudo, mova (não copie) sua pasta My Weblog Posts para o diretório raiz do SkyDrive. Resumindo, você vai mover a pasta “C:\Users\<seu_usuario>\Documents\My Weblog Posts”  para “C:\Users\<seu_usuario>\SkyDrive“.
  • Abra o regedit
  • Vá para HKEY_CURRENT_USER\Software\Microsoft\Windows Live\Writer
  • Clique com o botão direito na pasta Writer e escolha Novo > New String Value
  • Dê o nome de PostsDirectory e depois clique para editar
  • Agora basta informar o diretório para onde você quer que os arquivos sejam salvos. Que é “C:\Users\<seu_usuario>\SkyDrive\My Weblog Posts”
  • Feche o regedit e reinicie.

Pronto. Todos posts salvos e publicados irão ficar no SkyDrive. Faça isto para todos os computadores em que você utiliza o Windows Live Writer.

Obs: Só não irá funcionar se você apontar para um diretório que precisa de privilégios de administrador.

Simples e útil. =)

Diferença entre int.Parse() e Convert.ToInt()

Olá pessoal. Esses dias ocorreu essa dúvida e confesso que parei para ler a documentação e brincar. Apesar de “simples”, creio que tenha muito developer que acaba confundindo o uso ou achando que é “tudo a mesma coisa.

E já sendo bem direto, no funcionamento não temos nenhuma diferença. Eu disse no funcionamento. Onde a entrega do objetivo primário é “converter para inteiro”.

Se você tem uma string e você sabe que ela sempre será um número inteiro (por exemplo, se algum serviço web está te entregando um número inteiro em formato string), você pode usar o Int32.Parse().

Agora se você está recebendo dados de entrada enviados pelo usuário (um formulário web por exemplo), você deve usar o Int32.TryParse(), uma vez que este método permite um controle mais refinado da situação quando o usuário informa um valor inválido. Este controle fica claro quando é retornado 0 sempre que não há sucesso na conversão para inteiro (seja nulo, overflow, formato inválido, etc).

Já o Convert.ToInt32() recebe um objeto como argumento e invoca o método Int32.TryParse() quando ele descobre que o objeto recebido é uma string. Por isso que quando ele não consegue converter para inteiro ele retorna 0 e não lança o ArgumentNullException. Com isso vemos que o Convert.ToInt32() é provavelmente um pouquinho mais lento do que Int32.Parse() porque ele tem que verificar o seu tipo no argumento.

E falando dem performance, fiz um teste que faz 900.000.000 de conversões de uma string para int usando os três métodos. O resultado temos abaixo.

image

Veja que o TryParse() é o mais veloz e o ConvertTo o mais lento. O código está no GitHub e você pode baixar para testar na sua máquina.

Por fim, gostaria de recaptular que o Int32.Parse() e Int32.TryParse() só podem converter strings. Convert.ToInt32() pode trabalhar com qualquer classe que implementa IConvertible, sendo assim, se você passar uma string via Convert, o efeito será equivalente aos métodos Parse/TryParse, porém sabe-se agora que teremos uma sobrecarga extra para comparações de tipo e outras coisinhas. Portanto, se você estiver convertendo strings, TryParse() é provavelmente a melhor opção.

É pra não ter mais dúvidas.
Tem subjeções? Deixe seu comentário.

Abraço!

Configurando o Proxy no Visual Studio 2010

Uma dica simples. Mas que sempre é preciso quando se está usando o VS2010 em uma rede com Proxy. Por exemplo, ao usar o Extension Manager, você não consegue fazer buscar online e recebe um erro como na tela abaixo:

PICD7EB.tmp

É preciso configurar o VS2010 para usar o proxy (padrão), que é do Internet Explorer.
Antes de tudo, abra o VS2010 em modo administrador e abra o arquivo devenv.exe.config. Que se encontra em *\Program Files\Microsoft Visual Studio 10.0\Common7\IDE.

No final do arquivo edite o system.net conforme o código abaixo:

  <system.net>
    <defaultProxy useDefaultCredentials="true" enabled="true">
      <proxy usesystemdefault="True" />
    </defaultProxy>
    <settings>
      <ipv6 enabled="true" />
      <servicePointManager expect100Continue="false" />
    </settings>
  </system.net>

Se quiser setar o proxy diretamente, adicione a propriedade proxyaddress na tag <proxy>.

Até a próxima.