Certa manhã um usuário¹ precisava liberar espaço em disco do servidor de homologação.

Como era praxe, conectou no servidor de homologação, acessou o SQL Server e... apagou o banco de dados de produção. Depois desconectou e, sem desconfiar do imenso #fail, foi tomar café. Leia mais...

Fóruns são excelentes lugares para buscar por suporte e ajuda. Normalmente são gratuitos e, claro, são tão bons quanto a comunidade que os rodeia.

A grande maioria das pessoas, na minha opinião, chega a um fórum fazendo buscas (já falei sobre isto aqui, dê uma olhada). Fica alguns minutos, lê alguns tópicos e vai embora. Se der sorte, alguém já passou pelo problema, já pediu ajuda e já obteve uma resposta satisfatória. Ótimo.

Contudo, pode ser necessário abrir um novo tópico ou criar uma nova pergunta. Ser humilde o suficiente para explicitar que precisa de ajuda (ora, todo mundo precisa). Nesta hora, antes de mais nada, é muito valioso seguir uma etiqueta básica que melhorará suas chances de obter uma resposta: Leia mais...

Essa é bem simples, porém, exige uma certa experiência para começar a utilizá-la. É mais fácil entender com um exemplo. Vejamos:

Num dado aplicativo, quando o usuário precisa executar uma ação administrativa, o aplicativo faz uma consulta a um método para verificar se o usuário possui o perfil administrativo. Se possuir, o aplicativo permite ao usuário executá-la, caso contrário, é óbvio, não permite. Entenda um método como o abaixo: Leia mais...

Lidar com arquivos em um sistema pode parecer simples à primeira vista. Será?

Certa vez, faz alguns anos, um cliente acionou o suporte técnico informando que os usuários do seu sistema não conseguiam mais carregar arquivos.

Os logs de exceções foram avaliados, não havia nenhuma alteração no hardware, última versão estável do sistema no ar faz algumas semanas, enfim, tudo aparentemente normal. Até que se decidiu dar uma olhadinha no local onde os arquivos estavam sendo gravados... juntos. Um pouco mais de 60 mil arquivos numa mesma pasta. Em um disco formatado em FAT32. :O Leia mais...

Oi.

     É muito fácil escrever código. Difícil é escrever código que outras pessoas entendam e que consigam dar manutenção. Veja bem, você pode ter aqueles seus projetos pessoais nos quais você escreve como um lobo solitário (excelente mangá...) sem se preocupar se daqui a seis meses você será capaz de lembrar como ele funciona ou não (e, se funcionar, que importa, certo?). 

     Por outro lado, se você trabalha em equipe, para a sanidade e felicidade de todos, algum padrão tem que ser adotado. Não importa o tamanho da equipe, a partir de duas pessoas, já vale o esforço de adotar um padrão de codificação. Todos ganham.

     Adotar um padrão de codificação, se o seu time não possui um, pode ser... complicado. As pessoas tendem a defender o próprio estilo com muito “vigor”, se é que me entende (a Cúpula do Trovão vêm à cabeça...). Leia mais...

Oi.

     Recebi pelo MS Press Book Connection. Em comemoração aos 25 anos da MS Press, até o dia 24/12 você pode baixar o livro "Writing Secure Code for Vista" do Michael Howard e do David LeBlanc. Não é o "Writing Secure Code", infelizmente, mas é quase tão valioso.

     Os autores são referências no assunto de segurança de software. O Michael Howard, por exemplo, é um dos caras responsáveis pela metodologia Security Development Lifecycle (SDL) na MS. Dê uma olhada no blog dele. Vale a pena.

     O livro pode ser obtido aqui.

Abraços.

Olá.

     O Mauro Sant'Anna apresentou dois webcasts sobre componentes de arquiteturas multi-camadas. Muito interessantes, o primeiro webcast tem foco teórico e o segundo é bem mais prático.

     Nas palavras do Mauro:

Nesta apresentação uso como base o esquema colorido do documento “Designing Application and Services” do site Paterns & Practices e digo o que significa cada caixinha, quais as possibilidade de organização (1 a 4 camadas), questões de que tipo de dados são tocados entre camadas, de quebra lógica e física, serialização, segurança e aderência a SOA. Ela é baseada em experiência prática e bastante temperada pelas minhas opiniões a respeito de bibliotecas ORM, análise orientada a objetos, OOP remota e outros tópicos.

     Baixei, assisti, são bem curtos, um pouco menos de uma hora cada um. Às vezes é polêmico, mas certamente vale a pena.

     Parte 1 Parte 2

     Você vai precisar ter um ID do Passport para prosseguir (se você tem uma conta do hotmail ou msn já é suficiente).

Abraços.

Olá.

     Region é um recurso da maioria das linguagens modernas de programação que permite ao programador agrupar trechos do código-fonte utilizando um nome ou frase (embora aqui eu esteja citando o C# mais claramente). Não tem efeito nenhum efeito sobre compilação ou sobre a lógica/performance do código-fonte em si, mas sim, permite melhorar sua legilibidade.

     Ora, é muito bom quando você acessa um código-fonte e a leitura do mesmo está dividida em blocos. Facilita muito a leitura.

     Por outro lado, algumas vezes o programador perde a noção da quantidade de regions a utilizar no código e acaba super-utilizando este recurso. O resultado final é um código-fonte com leitura muito quebrada e, por causa disso, difícil de ler. A cada X linhas o pensamento é interrompido por um Region que necessita ser expandido para que a leitura continue.

     No exemplo abaixo, criei uma classe para demonstrar como o abuso na utilização de Region dificulta a leitura do código-fonte. Chega a ser engraçado, você abre o código-fonte e encontra algo inocente como exibido na imagem abaixo:

     E então você começa a expandir region após region até exibir todo o código-fonte e no final se depara com um código-fonte como definido nessa imagem. A proporção de regions utilizadas supera em muito a complexidade do código-fonte: a classe contém um construtor padrão, uma propriedade, um método privado e outro público, porém, há não menos que 20 regions definidas. Exagero é pouco, certo?

     Novamente, o uso das regions é bem-vindo desde que sua utilização sirva para melhorar a leitura do código-fonte. Agrupar trechos comuns do código, utilizando poucas mas bem posicionadas regions torna a leitura "agradável". Dividir excessivamente o código-fonte utilizando muitas regions quebra a sequência/fluência de leitura. Evite.

Eduardo.

Olá.

     Qualquer código-fonte é passível de revisão, consertos e melhorias. Na maioria das vezes, na minha opinião, estas alterações (ou refatorações, se preferir) são auto-contidas e transparentes, em outras vezes isto não é possível. Por exemplo, quando um método tem seu comportamento interno alterado porém tanto sua assinatura quanto seu retorno continuam com os mesmos tipos, pode-se dizer que esta alteração foi transparente pois quaisquer outras classes/métodos que o consumam não são afetados.

     Em outras vezes pode ser necessário modificar a assinatura do método ou a sua saída. Os motivos variam, claro, mas pode acontecer de se estar melhorando a legilibidade do método, ou eliminando "números mágicos" ou simplesmente porque a mesma funcionalidade do método já existe em outra classe. Por exemplo, durante a revisão de um código-fonte encontra-se um  método como o abaixo:
     public string InserirUsuario(string nome, int idade, int tipoDeSexo) {...}

     O parâmetro tipoDeSexo é do tipo inteiro mas quais números inteiros recebe? Se não houver documentação, talvez seja necessário ler o código para descobrir que 1 é igual a masculino e 2 é igual a feminino. Por outro lado, informações deste tipo são melhores representadas por enumerações. Partindo daí há duas possibilidades:

1. Criar uma enumeração, alterar a assinatura do método trocando o parâmetro inteiro tipoDeSexo pela enumeração e alterar a chamada do método em todos os locais do código-fonte;
2. Criar uma enumeração, criar um novo método com a assinatura refeita, mover a implementação do primeiro método pro segundo e marcar o primeiro método como "obsoleto".

     A implementação do item 2 ficaria mais ou menos assim:
     public enum TiposDeSexo {Masculino = 1, Feminino = 2}

     [Obsolete("Esta versão do método está obsoleta. Utilize a 2a versão deste método.")]
     public string InserirUsuario(string nome, int idade, int tipoDeSexo) { return(InserirUsuario(nome, idade, (TiposDeSexo)tipoDeSexo))); }

     public string InserirUsuario(string nome, int idade, TiposDeSexo tipoDeSexo) { ... }

     A vantagem de se criar um novo método é não ter que alterar todo o código-fonte buscando todos os locais que chamam o método InserirUsuario passando um inteiro para o parâmetro tipoDeSexo. Isto poderá ser feito aos poucos e cada caso de uma vez. Mantem-se a compatibilidade com todo o código, o que é bom. Ao mesmo tempo, o método foi marcado como "obsoleto". Isto significa que em todas as vezes que alguém precisar utilizar o método InserirUsuario será notificado de que a 1a versão do método está antiga e não deveria mais ser utilizada. No futuro, depois que todas as chamadas para a 1a versão do método tiverem sido alteradas para a 2a, o método em si pode ser removido do código-fonte. Muito bom, certo?

     Dei toda essa volta pra informar que a MS possui um site que informa uma lista de todas as APIs do .NET Framework 2.0 que foram marcadas como obsoletas. Esta página informa também as APIs substitutas que você pode utilizar e, principalmente, quais APIs não possuem substitutas (ou seja, a API "estacionou" em termos de evolução de código).

     Ainda que uma API esteja marcada com o atributo "[Obsolete]" você é livre para continuar utilizando. O único inconveniente é que o compilador gera avisos ("warnings") para cada linha de código que utilizar uma API obsoleta. Dependendo da quantidade de ocorrências a lista pode encher a paciência.

     O site é este aqui. É possível visualizar a listagem por assembly (dll) ou por namespace (o que é mais legal).

Eduardo.

Olá.

     Comecei minha carreira faz nove anos. De início, em 1999, fui estagiário numa multinacional e dei meus primeiros passos em atendimento, suporte e relacionamento com as pessoas. Depois de certo tempo, já como funcionário, desenvolvi meu primeiro projeto ASP.NET, modificando o portal IBuySpy (lembra?) para rodar numa intranet, lá pelos idos de 2003.

     Foi uma experiência enriquecedora ainda mais quando o projeto começou a quebrar o SQL Server 2000. Sério, havia um procedimento de carga de dados seguido de um procedimento de cálculos de estatísticas que, invariavelmente, travava a instância do SQL Server. Na época, aproveitando o contrato de suporte com a MS Corp (dado que a matriz da empresa mantinha um contrato guarda-chuva ou algo assim), foi designado um profissional da MS especialista em banco de dados para lidar com o problema, o Robert.

     Ele não falava português (assim como eu não falava inglês) então obviamente a comunicação fluía de maneira excelente. Felizmente havia um administrador da área de infra (Oi, Leonardo!) que falava ambos os idiomas e foi o que nos salvou. :) Duas semanas após avaliar o servidor e levar uma cópia do banco de dados o Robert comunicou que havia um problema no SQL Server 2000 comunicando com o ADO.NET e que seria corrigido num hotfix a ser liberado pela MS Corp. Nice! Meu primeiro projeto com ASP.NET e já consegui um hotfix da MS.

     Em 2004 eu fui trabalhar para uma outra multinacional. É uma potência em termos de mídia digital e está por trás de grandes projetos, os quais, infelizmente não posso divulgar. Não, não é a Real... Lá eu realmente me tornei um desenvolvedor e aprendi muito. Aplicações ASP.NET, serviços Windows, XML, JavaScript, fora o período em que fui "coordenador".

     Foi um tempo de grande aprendizado mesmo. Se você tiver sorte irá encontrar uma empresa na qual você tenha de lidar com desenvolvimento, partes de design, configurações de servidores, integrações com sistemas externos, enfim, uma empresa na qual você será desafiado a crescer profissionalmente em várias frentes e não somente desenvolvimento de código.

     Em 2007 saí para ser consultor no meu empregador atual, desenvolvendo para uma empresa do governo. Não vou comentar nada pois ainda é recente, porém, semana que vem cumpro o final do meu aviso prévio (sim, você leu bem, consultor cumprindo aviso prévio) e mudarei de trabalho pela 4a vez em nove anos (foram cinco anos e meio na 1a, dois anos e meio na 2a e um ano na atual). Eu não esperava mudar de trabalho tão cedo pois tenho a tendência de ficar um bom tempo em cada um deles mas, surgiu uma oportunidade para realizar um sonho antigo: trabalhar para a minha própria empresa. Não a Mutambal (oh!) mas uma empresa da qual também sou sócio.

     O meu ex-gerente está criando sua própria empresa (também um objetivo antigo dele) e me convidou para fazer parte do quadro de sócios. No futuro eu vou comentar mais sobre isto e especialmente sobre os detalhes envolvidos na criação de uma nova empresa. Existem muitos desafios a serem vencidos antes mesmo de se pisar no escritório no dia da inauguração e acredito que valerão alguns bons posts. Vou cuidar da área de desenvolvimento e espero montar um time excelente (anúncio de vagas aqui, logo, logo). Já temos projetos, já temos clientes, e já temos um sistema fantástico a ser desenvolvido.

     Particularmente o meu objetivo em ser consultor sempre foi o de acumular patrimônio suficiente para poder criar a minha própria empresa de software (não necessariamente consultoria). Óbvio que esse processo iria levar anos, claro, e é por isso que foi uma grata surpresa ter sido convidado. Foi um belo atalho para mim.

     Por fim, eu queria comentar sobre a importância de saber sair bem de uma empresa. Eu sempre tomei o cuidado pessoal / profissional de sair honesta e dignamente dos meus trabalhos. Nunca briguei, nunca levantei e fui embora, nunca deixei a equipe com um projeto no meio (ou pelo menos sem cumprir algum tipo de milestone) e sempre mantive bom relacionamento com as pessoas.

     Você não sabe o que o futuro reserva. Sair de uma empresa intempestivamente: não cumprindo nenhum tipo de aviso prévio ("fico até sexta", na quarta-feira à tarde não vale); discutindo com seu chefe/equipe; deixando claro que seu chefe é um idiota e a empresa é uma m*rda ou tomando atitudes covardes (como sumir do mapa) certamente irão diminuir a validade da sua carreira. Você pode tomar um golpe do destino, querer voltar, e encontrar as portas fechadas. É muito triste quando isso acontece.

     Na área de desenvolvimento é comum ouvir que as vagas de trabalho são "urgentes" ou "de início imediato". Recrutadores frequêntemente causam angústia nos candidatos por dar a entender que se o candidato não puder começar no dia seguinte perderá a vaga. Se a empresa não pode esperá-lo por, não sei, duas semanas, significa normalmente que você está sendo convocado para apagar um incêndio ou para ajudar a apagar um e este não é exatamente um bom jeito de começar num trabalho novo...

Eduardo.