Mutamblog

ASP.NET MVC NerdDinner

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 03 May 2009 19:55:00 -0700

Ele é um vice-presidente na MS. Ele dirige os times que constroem o CLR, o ASP.NET, o IIS, o Silverlight e ferramentas do Visual Studio para interagir com o Visual Studio.

Sim, ele é o Scott Gu (thrie). E, quando você acha que ele não tem mais tempo, ele escreve um tutorial completo sobre o ASP.NET MVC com um pouco menos de 200 páginas. Amazing.

Você pode baixar o PDF, ou ler on-line, dividido por tópicos. Ou comprar o livro do qual este é só o primeiro capítulo.

Boa leitura.

Tech-Ed Brasil 2009 em agosto

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 26 Apr 2009 19:30:00 -0700

É isso aí!

Comece a separar os cascalhos, a bufunfa, a pila, a grana, venda parte da sua coleção de HQs (só aqueles mixes da Panini...) ou aquele seu boneco do Batman com a cara do Adam West: o Tech-Ed Brasil 2009 está confirmado para agosto!

Dias 25, 26, e 27 de agosto. Mais no site oficial.

Aventuras fabulosas do Eric Lippert

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 19 Apr 2009 21:07:00 -0700

Se você programa em C#, o blog do Eric Lippert é um achado.

Ele trabalha na MS na divisão de desenvolvimento e seu trabalho é, basicamente, desenhar software (principalmente o C#).

Com bastante frequência ele escreve sobre decisões de design e detalhes de implementação da linguagem e deixa claro os motivos pelos quais referências não são endereços, as diferenças entre propriedades explícitas versus automáticas e sobre representação e identidade (um post muito interessante sobre o operador cast).

Vá conhecer. Vale a pena.

Fabulous Adventures in Coding

Silverlight 3.0 - Mas já?

blog.nospam@nospam.mutambal.com (SrECosta) — Wed, 15 Apr 2009 21:33:00 -0700

É impressionante a capacidade da MS de tornar obsoleta uma tecnologia recém-lançada...

Nem bem viramos a chave para o Silverlight 2.0 já dá pra baixar o beta do 3.0. E agora? Qual é o mais sensato a fazer? Continuar implementando o 2.0 ou apostar no 3.0?

Com "mais de 50 novas características, incluindo o suporte para rodar aplicações fora do browser, melhoras dramáticas na performance de exibição de vídeos.." e por aí vai. Fica difícil decidir.

E vamos que vamos pois a roda não pára de girar.

Introdução ao desenvolvimento utilizando certificados digitais - Parte 2

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 12 Apr 2009 17:14:00 -0700

Previously on Mutamblog Galactica... Ops!

Entendendo o uso de chaves pública e privada

Um certificado digital é basicamente um arquivo de dados. É necessário um mecanismo que proteja o seu conteúdo de maneira que seus dados não possam ser alterados. Para confiar nos dados é necessário que se possa confiar no seu emissor. O mecanismo que possibilita a proteção dos dados do certificado é a criptografia assimétrica de chaves pública e privada.

É mais fácil entender a criptografia de chaves assimétricas por comparação com a criptografia de chave simétrica. Nesta última, a chave utilizada para criptografar (cifrar seria um termo melhor) um dado é a mesma chave utilizada para descriptografá-lo (descifrá-lo). Já no caso da criptografia de chaves pública e privada é utilizada uma chave para criptografar o dado (a chave pública) e é utilizada outra (a chave privada) para descriptografá-lo.

O grande senão da criptografia simétrica é que, por motivo de somente existir uma chave, ela deve ser conhecida tanto por quem está criptografando algum dado quanto por quem irá descriptografá-lo. Por exemplo, se você utilizar esta criptografia para proteger um arquivo antes de enviá-lo para um amigo, este amigo somente poderá descriptografá-lo se também conhecer a chave.

Já no modelo assimétrico a chave pública pode ser amplamente divulgada mantendo-se segredo somente da chave privada. No exemplo que citei, você poderia criptografar o arquivo utilizando a chave pública do seu amigo e, uma vez que somente ele conhece a chave privada correspondente, somente ele poderia descriptografá-lo. Você pode criptografar quantos arquivos (ou mensagens) quiser que somente ele teria condições de utilizá-los. Nem mesmo você que criptografou os arquivos será capaz de descriptografá-los.

Voltando aos certificados, de maneira geral o fluxo de utilização das chaves inicialmente é este:

O primeiro passo para a geração de um certificado é a geração do par de chaves.
Uma vez que o par de chaves tenha sido gerado, é criada a requisição com os dados do indivíduo.
Esta requisição é assinada utilizando a chave privada.
A requisição é enviada para a CA junto com uma cópia da chave pública (observe que, normalmente, a CA não precisa conhecer a chave privada do certificado).
A CA, ao receber a requisição, valida sua assinatura utilizando a chave pública associada.
Se a CA confiar na assinatura e nos dados do indivíduo ela procede gerando o certificado.
Em seguida a CA utiliza a sua própria chave privada (também chamada de raiz) para assinar o certificado.
Finalmente, a CA devolve o certificado gerado junto com uma cópia da sua chave pública.
Se quem realizou a requisição confiar na CA pode ou não proceder com a instalação do certificado.

A assinatura de um certificado é o que permite confiar seus dados. Sempre que é necessário apresentar um certificado é necessário apresentar a sua assinatura. E a sua assinatura é validada contra o seu par de chaves.

A maior fraqueza de um sistema baseada em par de chaves é a proteção das chaves privadas. Se uma CA tem a sua chave privada desprotegida e roubada todos os certificados gerados por ela estarão comprometidos. Num nível abaixo, se a chave privada de um certificado é conhecida, o mesmo certificado também estará comprometido.

O algoritmo criptográfico utilizado para gerar o par de chaves é o RSA¹. A partir daqui podemos falar dos famosos padrões de criptografia de chave pública.

Padrões de criptografia de chave pública (PKCS)

A melhor parte dos padrões de criptografia de chave pública é que eles não são realmente um padrão oficial da indústria mas o são de facto. Explico: depois de inventarem o algoritmo de chave pública os caras da RSA publicaram uma série de artigos, os tais padrões, para promover diversos usos para o algoritmo. A indústria como um todo adotou a maioria destes padrões e, embora eles não tenham sido publicados por autoridades técnicas (ANSI, ISO, IETF, você diz qual), eles têm este super-status.

Chamados de PKCS ou public-key cryptography standards, há cerca de quinze padrões (você pode acessar a documentação original completa no site da RSA). Cada um destes padrões corresponde a um propósito de uso para uma chave pública, por exemplo, assinar ou encriptar mensagens, como armazenar chaves privadas e por aí vai.

Para nossa pequena introdução os padrões relevantes são: PKCS #7, PKCS #10 e PKCS#12. Tem também o PKCS #11 mas eu falarei dele somente quando comentar sobre CSPs (esse, como diria um amigo meu, é "nervoso"). :)

PKCS #7 e PKCS #10

O padrão PKCS #7 e PKCS #10 são, normalmente, utilizados em conjunto. Lembra-se quando eu comentei um pouco mais acima sobre o fluxo inicial de utilização do par de chaves? Eu omiti alguns detalhes na esperança de que eles ficassem mais claros agora. :)

Quando a requisição de um certificado é criada para ser enviada para uma CA ela é formatada utilizando o padrão PKCS #10 (seu nome de batismo é Certification Request Standard), ou seja, a CA recebe a requisição neste formato. Este formato é binário mas pode ser convertido para texto (em base 64). Veja um exemplo (que eu peguei lá na Wikipedia):

Quando a CA envia de volta o certificado gerado ele é formatado utilizando o padrão PKCS #7 (cujo nome de pia é Cryptographic Message Syntax Standard), ou seja, o processo que gerou a requisição recebe de volta um certificado neste formato. Este formato também é binário e também pode ser convertido para um texto em base 64. Sem exemplo agora, depois eu edito o post e coloco um...

Update (em 27/04/2009): meu amigo Badaró me mandou um link com um certificado em base 64. Superinteressante porque você pode baixá-lo e ter como checar seu conteúdo. Para quem não quiser baixá-lo, ele está logo abaixo (copie-o e cole num arquivo .CER que você conseguirá abri-lo e visualizar os detalhes do indivíduo e da CA associada):

PKCS #12

Normalmente um certificado digital não é transmitido ou mantido junto de sua chave privada. Porquê? Bem simples: seria o equivalente a trancar uma gaveta e manter a chave presa na fechadura. Contudo, há situações em que isto é necessário. Por exemplo, quando se precisa fazer backup de uma CA. Neste caso é feito um backup do certificado raiz da CA junto com sua chave privada para que, em caso de perda da CA (HDs fritam, servidores pegam fogo, principalmente os da Telefonica...) a CA possa ser reinstalada utilizando o mesmo certificado raiz.

Neste caso, o certificado digital é salvo num arquivo (extensão .p12 ou .pfx) junto com seu par de chaves. O formato deste arquivo obedece o padrão PKCS #12 (ou Personal Information Exchange Syntax Standard para os puros de coração). É importante ressaltar que o certificado digital é salvo protegido por um algoritmo simétrico ou seja, para gerar o arquivo você informa uma senha e para utilizá-lo depois também terá de informar a senha novamente.

Ok, agora que falamos um pouco sobre as chaves pública e privada podemos prosseguir para o conceito de PKI.

Infra-estrutura de chave pública (PKI)

Uma infra-estrutura de chave pública ou public-key infraestructure ou PKI (para simplificar) é toda estrutura voltada para gerenciar certificados digitais e suas chaves públicas.

É mais ou menos assim: ao conjunto de processos responsável por associar numa CA, de maneira indubitável, um indivíduo com uma chave pública é dado o nome de PKI. Sendo assim, a PKI não é uma tecnologia mas sim um conjunto de processos. Somando tudo que se requer para gerenciar indivíduos e suas chaves públicas é que se denomina PKI. (Vale lembrar que por indivíduo deve-se entender uma pessoa ou um hardware ou um serviço.)

No mundo MS, o componente mais importante de uma PKI é a CA ou Certificate Authority. Este é um componente que pode ser instalado a partir dos sistemas operacionais de servidor (Windows 2000 / 2003 / 2008) e é encontrado lá no Adicionar / Remover Programas.

Há basicamente dois tipos de CA, na visão MS: Enterprise e Standard.

Enterprise: é a CA instalada em conjunto com o Active Directory (AD). É a CA mais poderosa e cheia de recursos que a MS oferece pois você tem numa solução integrada tanto a base de usuários quanto os certificados digitais. Exclua um usuário e o seu certificado digital será revogado, por exemplo.
Standard: é a CA instalada num ambiente sem o Active Directory (ou pelo menos sem integração). Permite gerar certificados normalmente, porém, não conta com uma série de facilidades e recursos disponíveis na versão Enterprise. Isto fica claro porque a CA não conhece a base de usuários. Exclua um usuário e você terá de possuir um processo / procedimento para revogar o certificado digital correspondente, por exemplo.

Não vou entrar no mérito de instalação da CA pois existem ótimos tutoriais de como proceder. Veja este aqui da IT Central para ter uma idéia.

No próximo post...

Ok, falta pouco para o final desta série introdutória (mentira!) . :) Eu preciso comentar sobre cryptostore, snap-ins do Windows, CSPs e outras coisas mais. Aí entraremos no .NET Framework, ActiveX e código (at last!). Fique comigo e mande ver nos comentários!

Abraços.

¹ Trivia: RSA vem de Ron Rivest, Adi Shamir e Leonard Adleman, seus inventores. Eles também fundaram a empresa RSA para poder divulgar seu trabalho e poder ganhar um dinheirinho. :)

Codificando .Net e-magazine edição 09

blog.nospam@nospam.mutambal.com (SrECosta) — Wed, 08 Apr 2009 06:15:00 -0700

Oi.

Para 2009 eu tinha decidido não fazer mais posts de anúncios: o objetivo era evitar ser mais um blog de ecos como tantos por aí. Saiu isso, lançado aquilo, versão beta daquilo outro, etc.

Contudo, o anúncio da edição 09 da revista eletrônica da comunidade Codificando .Net eu não podia deixar passar batido. Por dois motivos:

O novo projeto da revista, principalmente o gráfico, ficou muito melhor. O Diego Nogare e o Alexandre Tarifa conseguiram montar uma equipe bem competente para tocar a revista.
A Fernanda Sallai, nossa estagiária aqui na Pakua, faz parte dessa equipe. :)

Os tópicos cobertos pela revista estão mais abrangentes e a edição 09 possui artigos sobre Scrum, Silverlight, cubos Olap, recursos de auditoria no SQL Server e muito mais.

Acesse o site e faça o download gratuito do arquivo PDF. Vale a pena.

Introdução ao desenvolvimento utilizando certificados digitais

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 05 Apr 2009 18:29:00 -0700

O básico: certificados digitais são utilizados para identificar indivíduos, recursos e serviços dentro de um ambiente computacional.

Agora, um pouco mais extendido. :)

É tudo uma questão de identidade. Pessoas, empresas, softwares, todos precisam informar quem são e de onde vêm.

A beleza dos certificados digitais é que eles garantem uma estrutura em que estes indivíduos podem afirmar quem são, porém, com condições e mecanismos que permitem sua confirmação. Cada certificado digital contém informações básicas sobre seu proprietário e, mais importante, sobre a entidade que pode confirmá-lo.

A adoção deste tipo de certificado aumenta diariamente. Não entenda com isto que estes certificados são tecnologia futura. Longe disso. Os certificados são tecnologia utilizada no dia a dia e, citando dois exemplos, você não faria compras na internet ou pagaria contas no seu banco on line se eles já não houvessem sido implantados. Quando o dinheiro, ou melhor, crédito, começou a ser utilizado na internet os certificados já estavam lá pois era necessário "confiar" na identidade dos sites que lidavam com isto.

Entender o uso dos certificados digitais e para quê eles servem é presumivelmente simples. O complicado é entender como eles funcionam e toda a estrutura que os suporta. Você pode aprender sobre certificados digitais com uma visão de TI, ou seja, preocupando-se com a infra-estrutura que os faz funcionar ou, como eu, aprender como desenvolver software para interagir com toda esta infra-estrutura: você pode ter de gerar certificados, armazená-los, excluí-los (o termo correto é revogá-los) e validá-los. No mínimo.

De que tipo de certificados digitais estou falando?

Dos que dependem de autoridades certificadoras (CAs)¹. Lembra quando comentei que um certificado não apenas contém informações sobre seu proprietário mas também contém informações sobre a entidade que pode confirmá-lo? Então. Esta entidade é chamada de autoridade certificadora (ou certificate authority ou CA para os íntimos).

Uma CA possui dois propósitos básicos:

Gerar os certificados digitais (você não "cria" um certificado - você envia uma requisição para uma CA fazê-lo);
Manter uma lista atualizada de certificados gerados por ela que não são mais válidos (a famosa CRL ou certificate revocation list);

E, afinal, o que é um certificado digital?

Um certificado digital é um arquivo. Ele é especialmente formatado (encodado seria um termo melhor) e obedece a um padrão chamado X.509. Atualmente este padrão está na versão 3 e dita que um certificado contenha estas informações:

Version / Versão: a versão do formato do certificado;
Serial number / Número serial: uma sequência alfanumérica que identifica de forma única o certificado (pelo menos para a CA que o gerou);
Algorithm ID / ID do algoritmo: as informações de um certificado não são mantidas em texto simples (o arquivo é criptografado). Este campo indica qual algoritmo criptográfico foi utilizado. Exemplos são: MD5 (em desuso) e SHA-1;
Issuer / Emissor: identifica quem é a CA;
Validity (Not Before / Not After) / Validade (Não antes de / Não depois de): esta é uma informação crucial num certificado. Todo certificado é válido somente por um intervalo de tempo. Desta forma, um certificado não é valido antes da data inicial e nem tampouco é válido após a data final. Somente durante o período indicado ele é válido, mesmo que ele não tenha sido revogado;
Subject / Sujeito ou Indivíduo: é para quem o certificado foi gerado. É o "proprietário" do certificado;
Public key info / Informações da chave pública: vou comentar sobre chaves mais adiante;
Signature algorithm / Algoritmo da assinatura: cada certificado possui uma assinatura digital criptografada. Este campo indica qual algoritmo criptográfico foi utilizado;
Signature / Assinatura: é a assinatura digital criptografada do certificado. É gerada a partir das informações do próprio certificado e é o que impede que as informações do certificado sejam "temperadas" (ou modificadas, se preferir);
Tem mais campos, opcionais, mas estes são todos os campos realmente relevantes.

Como um certificado digital é gerado?

Olhando para trás seria melhor ter escrito "emitido" mas como escrevi "gerado" em todo o texto acima vai ficar assim mesmo...

Um certificado digital é gerado em dois passos (de maneira geral): requisição e emissão. Qualquer software que obedeça os protocolos certos pode criar uma requisição para um certificado, contudo, somente uma CA é capaz de emití-lo.

O primeiro passo para a geração de um certificado é gerar sua requisição. Uma requisição, como implica o nome, é um "pedido" enviado para a CA com todas as informações sobre o indivíduo que se deseja gerar o certificado assim como informações sobre a própria requisição. A requisição também é criptografada e esta criptografia deve obedecer a um dos algoritmos criptográficos que a CA consegue lidar. Não adianta nada enviar um requisição criptografada com SHA2-256 se a CA somente lida com SHA1.

A única informação obrigatória sobre um indivíduo é o subject (ou CN ou common name). Common name é a identificação única de um indivíduo (ou recurso ou serviço). Se você já trabalhou com Active Directory ou outro repositório LDAP um exemplo de CN pode ser CN=Eduardo Costa,OU=pakua. Mas um CN é simplesmente a identificação do indivíduo para o qual você está gerando o certificado. Além do CN uma requisição (e posteriormente o certificado) pode armazenar também estas informações:

E-mail;
Empresa;
Departamento;
Cidade;
País.

Finalmente, é necessário definir um propósito para o certificado digital a ser gerado. Sim, certificados digitais possuem propósitos. Um certificado digital pode ser utilizado para autenticação (o caso clássico, quando ele serve para certificar a identidade do proprietário e permitir o acesso a algum recurso) mas também pode ser utilizado para assinar código-fonte, assinar e-mails, criptografar arquivos e por aí vai.

A partir destas informações a requisição é gerada (e eu vou mostrar como fazer isto via código - aguarde e confie) e enviada para a CA de destino. Quando uma requisição chega até a CA ela pode aceitar a requisição e gerar o certificado ou então aguardar para uma aprovação manual da requisição ou finalmente negá-la.

Caso a requisição seja aceita, por processo automático ou manual, a CA retornará um certificado digital novinho.

Onde os certificados digitais estão sendo utilizados?

Eles são utilizados para certificar conexões SSL (o famoso https dos bancos e comércio eletrônico). Para assinar código-fonte, para assinar executáveis e bibliotecas (você não executa um ActiveX no IE - facilmente - sem assiná-lo com um certificado), para criptografar dados sigilosos, para criptografar conversas e vídeo pela internet, para assinar manifestos ClickOnce e, nas empresas, para certificar funcionários utilizando single-sign-on. Empresas estão baseando o acesso a sistemas e recursos pela validação dos certificados digitais gerados para seus funcionários e colaboradores.

No próximo post...

Eu falei que o assunto era extenso? Pois é. Eu ainda não falei sobre chaves pública-privada, nem sobre PKI, nem sobre PKCS7 / PKCS10 / PKCS12, nem sobre a Microsoft CA, e não mostrei uma única linha de código. Tenha paciência. Estou tentando cobrir o básico para o código fazer sentido lá na frente. Continue comigo e mande ver nos comentários.

Abraços.

¹ O outro caso que conheço são as "web of trust". É o mecanismo que faz funcionar o PGP e no qual não há necessidade de CAs centralizadoras para os certificados (é um modelo descentralizado por definição). Esta fora do escopo desta série. Pelo menos por enquanto... :)

Série sobre certificados digitais

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 29 Mar 2009 22:26:00 -0700

Oi.

Estou pensando seriamente em escrever uma série de posts sobre certificados digitais. Por experiência própria, sei bem o quanto é complicado encontrar informações sobre o tema...

Com esta história de nota fiscal eletrônica, comunicação segura, gerenciamento de identidades e tudo o mais, acho que pode valer a pena.

Abril logo está aí. Vamos ver. Sigam-me os bons.

Citação - Em Deus eu acredito...

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 22 Mar 2009 19:28:00 -0700

"Em Deus eu acredito. Para os demais solicito certificado X509."

Anônimo até eu lembrar quem disse isto para o Gustavo Picoloto que depois me contou...

Folksonomia é um conceito utópico?

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 15 Mar 2009 16:15:00 -0700

Sabe, folksonomia é um conceito bacana. Ele dita que os usuários são os próprios responsáveis por organizar as informações garantindo assim uma "naturalidade" na organização e no "idioma / linguajar" em que isto é feito.

Você faz isto o tempo todo: qualquer sistema que você tenha utilizado e que lhe peça para incluir tags sobre o conteúdo que você está inserindo é um sistema folksonômico¹. Youtube, del.icio.us, flickr, sistemas de blog como o blogengine (o que eu utilizo), e por aí vai.

Na teoria é lindo. Estes sistemas vão agregando conteúdo semelhante baseado nas inserções dos usuários e, claro, os usuários são beneficiados por essa mineração do conteúdo. Você chega no meu blog, clica na tag asp.net e encontra todos os posts que eu relacionei sobre isso.

O problema é para isto dar realmente certo e os resultados forem justos o sistema depende de mim! E eu sou humano, se é que me entende. :)

Entenda, num dia um dado post pode ser relacionado à asp.net. No outro, .net framework. No outro, jQuery. E finalmente, programação defensiva. Eu vejo pessoas colocando dez tags no mesmo conteúdo / post, talvez com a intenção de abranger o máximo possível de categorias. Funciona? Sim. Mas gera ruído.

Eu olho meus posts passados e não entendo como eu categorizei tal coisa em tal tag. Até pensei em passar uma madrugada corretiva, relendo e revisando todos os meus posts. Mas, pôxa, são cento e tantos (e olha que eu não escrevo muito...). Não pude prosseguir.

Para mim, folksonomia é interessante mas está fadado ao insucesso. Ele ajuda a sair do caos organizacional mas não é uma solução completa.

E qual seria uma solução melhor? Não sei. Aguardo sugestões.

¹ Ok, eu realmente acredito que, como o Acre, esta palavra existe.

Vim, vi e tuitei

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 08 Mar 2009 22:49:00 -0700

Oi.

Muito se discute sobre a utilização do Twitter como ferramenta de microblogging. Tem gente que gosta, tem gente que não gosta, tem gente que não fala coisa com coisa.

Contudo, tem gente que tuita coisas realmente úteis. Dê uma olhada nos usuários abaixo e os adicione se também acreditar no conteúdo:

@elijahmanor: asp.net, asp.net mvc, jquery
@dennes: asp.net, sql server, .net
@uaudecadadia: silverlight

O Dennes Torres compilou várias dicas de usuários do Twitter controlados por times da MS. Vale a pena dar uma lida. É um mecanismo muito bom para acompanhar os times dos produtos e as novidades.

É isso. Boas tuitadas.

Um projeto não termina quando acaba

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 01 Mar 2009 13:27:00 -0700

Outro dia lançamos o site de um cliente. Pode-se ter a ilusão de que, quando um site/sistema está em produção, o projeto está terminado. Ledo engano.

Pra atender bem um cliente é necessário acompanhá-lo na pós-implantação. No mínimo para se certificar de que o trabalho foi bem feito.

Sistemas web são criaturas arredias e é necessário muito esforço para deixá-los bem. Veja: você precisa testar no Firefox, no IE 6/7/8 (já está pra sair oficialmente mas o beta já está no mercado faz um tempinho...), no Safari, no Opera, no Chrome, etc, etc.

Há pequenos gaps que você somente perceberá quando estiver em produção. Quando os dados forem reais e não lorem ipsum (aliás, deixando bem claro, odeio lorem ipsum...), você perceberá que alguns determinados textos não encaixam, que uma div desce pra onde não devia e que a performance com cache ainda não está ideal.

É a vida. Não tem jeito. O melhor a fazer é se planejar desde antes de assinar o contrato para acomodar esta pós-implantação. Planeje seus recursos.

Utilize usuários diferentes para homologação e produção

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 22 Feb 2009 12:37:00 -0700

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é.

Como assim? Explico: o usuário e senha pra conectar no servidor de homologação era o mesmo usuário e senha pra conectar no servidor de produção. Os neurônios em estado dormente e a ausência de café no organismo o fizeram confundir o ip do servidor de produção 110.110.110.106 com o ip de homologação 110.110.110.109.

Uma vez que o usuário e senha era o mesmo ele só foi perceber quando o cliente ligou perguntando "cadê meu sistema?". ;)

Por isso, nunca, nunca, nunca, jamais mesmo, permita que seja utilizado o mesmo usuário para acessar os ambientes de homologação e produção.

É isso.

¹ Foi um programador mas não conte pra ninguém, ok? Isto pode horrorizar muitas pessoas mas há empresas em que um programador cuida do design, banco de dados, infra-estrutura e, provavelmente, faz café.

Etiqueta básica sobre participar em fóruns on line

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 15 Feb 2009 19:25:00 -0700

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:

Escolha o local correto

Uma questão de ASP.NET deve ser inserida no fórum de... ASP.NET! Entenda, um fórum gira em torno de um assunto. Cada assunto é dominado por um grupo de pessoas especialistas naquela tecnologia e/ou expertise. Fazer uma pergunta de uma tecnologia ou assunto diferente fará com que as pessoas não respondam. Portanto, antes de inserir sua pergunta, certifique-se de que irá fazê-lo no fórum adequado.

Seja específico

Conte detalhes. Coloque um pedaço de código. Diga como reproduzir o problema. Não seja tímido. Escreva de forma simples, porém correta. Não faça perguntas subjetivas ou de pouco aspecto prático. Evite o non-sense (ex. "se um programa quebra na floresta e não há ninguém monitorando...").

Seja gentil

Ninguém é obrigado a responder. Muito menos quando se escreve numa pergunta "Esta aqui é para os feras/gênios/gurus/ninjas/jedis/nome do especialista XYZ!". Trate as pessoas com respeito. Todos querem ajudar, mas você tem que merecer ser ajudado.

Monitore as respostas e dê feedback

Ao fazer uma pergunta você assume o compromisso de monitorar as respostas. Certamente alguém vai doar algum tempo da própria vida (nossa, isso foi meio dramático...) pra escrever sua resposta então o mínimo que se pode fazer é dar algum feedback em retorno. Diga se funcionou, se não funcionou, ou como acontece muitas vezes, informe mais alguns detalhes para quem está ajudando.

Encerre a questão

Alguém lhe deu uma resposta certeira para o problema? Ótimo, feche a questão! Não, mas você mesmo encontrou a resposta? Ótimo, feche a questão! A maioria dos sistemas de fóruns possui mecanismos para que a pessoa que fez uma pergunta possa indicar qual resposta resolveu a questão. É a forma de as pessoas no fórum saberem que o assunto está fechado e que todos estão felizes. Em fóruns que permitem busca interna é comum exibir os tópicos dos fóruns ordenados por ordem de "respondido/não respondido". Faz sentido as perguntas que supostamente possuem respostas OK aparecem antes das perguntas que ainda estão pendentes, correto? Já vi muitas perguntas nos fóruns com a resposta certa para o problema, porém, com a questão em um estado não resolvido.

Mas e se você estiver do outro lado do "balcão"?

Quase tudo vale. Seja gentil, seja educado, monitore sua resposta, seja claro e específico no texto. Criticar a pergunta em si é válido? É, mas tem de ser feito com jeito. Responder com "Hey, vai no Google, baby!" também não ajuda de verdade. No mínimo, aponte uma direção ou passe um link que você entende que vá ajudar. Ok?

Tem alguma dica extra? Manda ver nos comentários!

É isso aí.

Programação defensiva: assumindo atitude negativa para escrever código mais forte

blog.nospam@nospam.mutambal.com (SrECosta) — Sun, 08 Feb 2009 19:33:00 -0700

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:

private bool IsAdministrator(string userName) {
    bool isAdministrator = true;
    try {
        // Consulta ao banco, checagem do perfil, etc
    }catch{
    }
    return(isAdministrator);
}

Qual é o problema com este método? A princípio, nada. Se tudo ocorrer bem na consulta ao banco, em seguida à validação do perfil, o método é capaz de avaliar se o usuário possui ou não o perfil administrativo. Mas... e se ocorrer um exceção? Se a consulta ao banco falhar ou se a checagem não puder ser feita? Aí o método retorna "Sim, este usuário é administrador.".

Isto acontece porque a variável isAdministrator é setada (isso existe?) de maneira positiva. O método assume que o usuário possui o perfil administrativo e aí consulta o banco para provar o contrário. Ocorrendo alguma exceção, como o bloco catch esconde qualquer problema, o método retorna um resultado positivo. E coisas ruins acontecerão ao aplicativo...

Existe pelo menos duas maneiras rápidas de trabalhar com este tipo de situação, contudo, tudo depende muito mais de se fazer um esforço consciente para evitar este tipo de coisa. Shit happens ^(c) Forrest Gump. :) Mas você tem que estar preparado para antecipá-la. Como?

Para todos as classes e métodos que você escrever, pense que coisas ruins vão acontecer a ele. O banco de dados vai ficar fora do ar por alguns segundos, o input do usuário vai ser viciado, alguém vai (não você, claro) esquecer de informar aquele parâmetro importantíssimo no arquivo de configuração ou sua classe/método vai ser burlada de alguma forma. Eu sei, não é um jeito Pollyanna de viver, mas vai salvar sua pele várias vezes. Assuma o resultado negativo primeiro, que causa menor impacto, e aí tente prová-lo contrário.

Voltando ao método acima, só pra fechar o exemplo, seria razoável:

Assumir um valor negativo para a variável isAdministrator de saída e daí fazer as checagens no banco.
Ocorrendo uma exceção, forçar o valor da variável isAdministrator para falso. Ora, se ocorreu uma exceção, melhor remediar, certo?

Utilizando ambos os expedientes o método ficaria assim:

private bool IsAdministrator(string userName) {
    bool isAdministrator = false;
    try {
        // Consulta ao banco, checagem do perfil, etc
    }catch{
        isAdministrator = false;
    }
    return(isAdministrator);
}

E é isso. Código mais robusto no capricho.