Dessa vez, o artigo foge um pouquinho do desenvolvimento(mas nem tanto, já que a ROM em questão foi customizada). Eu sou o feliz proprietário de um HTC Magic, que por padrão vem com o Android 1.5, e também proprietário de um Motorola Milestone que não me faz tão feliz assim, que por padrão vem com Android 2.0, mas que já possui atualização para o 2.1 disponível(tanto a Retail – original da motorola – como das operadoras TIM e Vivo aqui no Brasil).

Porém, a HTC havia dito que o Magic não tem hardware o suficiente para rodar o Android 2.2. O que ninguém entende é por que pouco tempo depois, eles enviaram à Rogers(operadora de telefonia canadense) uma ROM do 2.2 para Magic, para ser customizada(esta ROM está prevista para sair oficialmente até outubro). Porém, mesmo ainda faltando tempo para a versão oficial sair, o pessoal do fórum xda lançou uma versão do Android 2.2 para o HTC Magic/myTouch 3g. E é baseada nela que está este artigo. Tive alguns probleminhas da primeira vez que utilizei esta rom, alguns processos ficavam fechando repentinamente(incluindo o telefone, logo eu ficava sem sinal). Fucei e achei algumas manhas, por isso resolvi escrever este artigo. Os links com os arquivos necessários estão no final do artigo. Todos os procedimentos e os arquivos no final do post são para aparelhos 32A. Não esqueça de fazer o backup nandroid para quaisquer emergências, e certifique-se de ter a bateria carregada em no mínimo 80%. Lembrando que não me responsabilizo por nenhum dano ocorrido ao seu aparelho, faça o procedimento por sua conta e risco.

Iniciando o processo – fazendo o root e atualizando a radio

Se o seu aparelho ainda não está “rootado”, ou seja, ainda não tem permissão de root, este vídeo explica bem como fazer. Observe que há a instalação de um aplicativo com a extensão .APK, que nos permite restaurar a radio do aparelho. A radio, o arquivo .img em questão e necessário para o procedimento que iremos executar está no fim do artigo. Cuidado para não utilizar a radio errada, isso poderá transformar seu aparelho em um lindo tijolo HTC. Para se certificar que o seu aparelho é 32A, faça como mostrado no começo do vídeo, desligando o aparelho e religando segurando o botão voltar. A tela branca deverá exibir na 1ª linda o modelo do aparelho. Agora, seu aparelho já deverá estar com o Radio Sapphire 1.70. No link no final do artigo, faça download do arquivo recovery-RA-sapphire-v1.7.0H.img.

Atualizando a SPL

Depois disso, devemos atualizar a SPL do aparelho, utilizando a SPL de final 2005. Para isso, devemos renomear o arquivo para update.zip e colocá-lo no cartão de memória. Desligue o aparelho e o reinicie em modo recovery (segurando o botão home – a casinha). Navegue até a opção “flash zip from sdcard”. Lá deve aparecer o arquivo update.zip. Aplica a atualização, e aí é que vem os macetes: Volte ao menu inicial, entre na opção “partition sdcard”, e depois escolha a opção “Partition SD”. Deixe 128mb para swap, e deixe 512mb para a partição ext2. Volte ao menu inicial, vá em “wipe”, e aplique TODOS os wipes. Agora ligue seu aparelho à usb do computador(se já esteve ligado durante todo o processo, não tem problema) volte ao menu inicial, e selecione a opção “USB-MS toggle” para montar o cartão de memória como drive externo no seu pc.

Finalizando e instalando a ROM

Coloque a rom do Android 2.2 no diretório raiz do seu cartão sd, volte ao menu inicial e vá novamente à opção “flash zip from sdcard”. O arquivo update.zip não estará mais lá, pois o cartão de memória foi formatado, só aparecerá o arquivo da ROM. Aplique o update e seja feliz

É importante lembrar que o primeiro boot costuma ser meio demorado, algo entre 3 a 10 minutos. Se passado esse tempo o aparelho não entrou no sistema operacional, é por que o procedimento não deu certo. Reinicie na tela de recovery(segurando o botão home), ative o modo usb, copie seu  backup nandroid para o cartão, volte ao menu inicial, vá a ” backup/restore” e restaure a versão antiga do sistema operacional.

Abaixo, dois vídeos que fiz ao testar a ROM nova:

Links:

SPL: http://www.gadget-space.com/htc-magic-spl-hboot-collection/

Radio: http://files.androidspin.com/downloads.php?dir=amon_ra/RECOVERY/

ROM Android 2.2 (Froyo): http://forum.xda-developers.com/showthread.php?t=723520

Em tempo: Procurei por “flash player” no market, e achei. Mas mesmo assim, tentei acessar um site feito em flex, e não consegui.
Em tempo 2: Cometi um errinho – O HTC Dream, que eu cito no vídeo como sendo um dos nomes do HTC Magic é na verdade um dos nomes do G1, primeiro aparelho lançado com android no mercado.

Abraços e keep coding!

Datasets tipados x Datasets não tipados

Este artigo é sobre DataSets não-tipados. Por padrão, um DataSet não é tipado, pois as colunas de seus DataTables devem ser referenciadas por uma variável do tipo string, por exemplo: meuDataSet.Tables[0]["ColunaDesejada"]. Existem ainda os DataSets fortemente tipados, que são classes que extendem a classe DataSet(e a classe DataTable) e incluem propriedades e membros específicos aos dados representados pelos dataset. Apesar desse tipo de dataset sofrer(muito, diga-se de passagem) de problemas de performance(sobre os quais eu irei discorrer ao longo do artigo), eles ainda assim são mais utilizados do que os DataSets não tipados.

Os fundamentos do DataReader

Antes de explicar por que eu preferi utilizar DataReaders ao invés de DataSets nas minhas aplicações, é necessário que tenhamos conhecimento sobre os DataReaders e DataSets. Estes dois objetos tem regras diferentes: DataSets são projetados para ser uma cópia em memória da fonte de dado, enquanto um DataReader  é projetado para ser um “motoboy” entre a camada de banco de dados e uma aplicação .NET.

No ADO.NET, um provider é uma fonte de dados, e existem classes específicas para trabalhar com alguns tipos de providers. Temos as classes SqlConnection, SqlCommand, SqlDataAdapter, e SqlDataReader para trabalhar com o provider SqlClient ; Temos ainda as classes OleDbConnection, OleDbCommand, OleDbDataAdapter, e OleDbDataReader para trabalhar com o providerOleDb. Objetos prefixados com o nome de um provider (Sql, OleDb, Oracle, Odbc, etc.) são objetos específicos do provider. Eles são projetados para esse provider em particular. O DataReader é um exemplo disso (i.e., SqlDataReader, OleDbDataReader, etc.).

Para trabalhar com dados utilizando um DataReader, você deve inicialmente estabelecer uma conexão com a base de dados e especificar a query a ser executada. Depois, o DataReader é criado e age como uma ponte entre a aplicação  .NET e a fonte de dados. Por exemplo, podemos utilizar o códigi abaixo:

O DataReader carrega um registro da base de dados de cada vez. Cada vez que o métodoRead() method  é chamado, o DataReader discarta o registro atual, volta ao banco de dados e traz o próximo resultado do resultset. O método Read()  retorna true se uma linha é lida na base de dados, e false se  não houver mais nenhuma linha.

DataReaders  são objetos de dados conectados, pois necessitam de uma conexão com o banco de dados ativa. Lembre-se, o DataReader é somente um “motoboy”  entre a aplicação e a base de dados. Obviamente, não podem trazer informações do banco depois que a conexão foi fechada. Além disso, um DataReader é limitado a ser somente leitura, e só lê “para frente”, ou seja: As informações obtidas do banco de dados através do DataReader não podem ser modificadas por ele, nem serem trazidas em ordem aleatória. Ao invés disso, um  DataReader está limitado a acessar os registros em ordem sequencial, do primeiro ao último, um de cada vez.

Os fundamentos do DataSet

DataSets são objetos mais complexos e cheios de característica do que os DataReaders. Enquanto DataReaders simplesmente “passam” pelos dados de uma base de dados, DataSets podem ser pensados como uma base de dados em memória(e é exatamente isso que eles são – uma cópia do banco de dados na memória). Do mesmo jeito que uma base de dados é composta por um conjunto de tabelas, um DataSet é composto de uma coleção de objetos DataTable. Enquanto uma base de dados tem relacionamentos entre suas tabelas, extendidos através de várias constraints de integridade de dados nos campos das tabelas, um DataSet pode também ter relacionamentos entre seus DataTables e constraints nos campos dos DataTables.

Ao contrário do DataReader, o DataSet é um objeto de dados neutro com relação a providers. Não existe SqlDataSet ou OleDbDataSet – apenas o bom e único DataSet. É responsabilidade do  provider do objeto DataAdapter “traduzir” os dados de um provider específico em um DataSet netro de providers. O trecho de código abaixo ilustra como popular um DataSet com os dados de uma query:

Como o trecho de código acima mostrou, o método Fill() do DataAdapter popula o DataSet com os resultados da query específica. Por trás disso, o DataAdapter está utilizando um DataReader para ler os resultados da query e popular o DataSet. O DataSet é um objeto de dados desconectado. Uma bez preenchido, a conexão é fechada e o conteúdo do DataSet pode ser manipulado e examinado.

Partindo do princípio que o DataSet representa uma coleção de dados separada e desconectada, não é surpresa nenhuma que seus dados sejam manipuláveis. Adicionalmente, o DataSet tem algumas capacidade de XML muito boas. Por exemplo, podemos serializar um DataSet em XML utilizando seu método WriteXml() ; Adicionalmente, pode-se popular um DataSet de um XML previamente formadado, utilizando o método ReadXml().

O “comércio” entre DataSet e DataReader

Independentemente de trazer ou não seus dados usando um DataSet ou um DataReader, podemos exibí-los em DataGrids, DataLists, or Repeaters utilizando exatamente o mesmo código. Na prática, definimos a propriedade DataSource dos Web Controls como um DataReader ou um DataSet, e então chamamos o método DataBind(). O ASP.NET transforma o trabalho com dados em algo tão fácil que os desenvolvedores talvez não parem pra pensar qual a melhor forma de se utilizar.”É tudo igual”, não importa o jeito de acessar.

Mas nem tudo é igual.Claramente, há uma grande diferença entre os atributos de um dataset e um datareader, logo também há uma diferença enorme de performance entre eles. Resumindo, a quantidade de atributos de um DataSet’s faz com que sua performance seja bem menor, comparada com o DataReader.

De acordo com este artigo, o DataReader é aproximadamente TRINTA VEZES mais rápido que o DataSet. Para volumes grande de dados, a diferença entre ambos é bem acentuada. O gráfico abaixo, por exemplo, ilustra os resultados de um teste efetuado pelo autor do artigo citado acima buscando de 100 a 1000 registros usando um DataSet (a linha rosa) e um DataReader (a linha azul marinho). Como mostra o gráfico, trazer 1000 registros com um DataReader é mais de 30 mais rápido do que utilizando um DataSet (0.28 segundos contra 8.89 segundos). Notável, não?

Outros gráficos de desempenho podem ser observados aqui, em comparações entre DataSet e DataReader em um cenário com um número comum de acessos. O resultado final é o mesmo. No entanto, o artigo diz:

Em todos os testes, percebemos que a performance doDataReader foi melhor que a do DataSet. Como mencionado anteriorment, o DataReader oferece uma performance melhor pois evita a sobrecarga de memória associada à criação do DataSet.(…) O DataReader é uma escolha melhor para aplicações que necessitam de leitura optizimada dos dados. O quanto antes os dados traduzidos do DataReader forem utilizados, o DataReader e a conexão fechados, maior será a performance.

Quando um DataSet é útil?

Apesar das limitações, o DataSet tem seus usos, caso contrário ele não seria um componente central do .NET Framework. No entando, creio que é raro(isto é, se existir) um uso para o DataSet em uma aplicação Web. Em toda a minha experiência, só vi uso para DataSets em duas ocasiões:

Em aplicações desktop(WinForms). Considere uma aplição desktop de entrada de dados. Um usuário pode iniciar o programa, carregar os dados de vendas do servidor de banco de dados, fazer algumas alterações, e então salvá-las. Esta é a situação ideal para se utilizar um DataSet. Ele permite serem lidos em um DataSet residente na memória do computador do usuário, o que confere ao usuário a habilidade de trabalhar com os dados sem fazer constantes consultas ao banco de dados. Após editar os dados, eles podem fazer um batch update, gerenciando de forma harmoniosa quaisquer mudanças ocorridas enquanto o usuário trabalhava desconectado. Além disso, considerando que o DataSet é uma armazenagem de dados desconectada, estes dados podem ser obtidos offline. Um vendedor visitando um cliente pode carregar estes dados e consultá-los em seu notebook enquanto está no trânsito, ou no escritório do cliente.

Uma situação como esta pode surgir em uma aplicação web. Porém, é um caso específico. Eu aconselharia nesse caso um dataset em sessão, utilizando as mesmas técnicas de batch editing e updating, ou – o mais indicado – uma cópia dos dados não em um dataset, mas em um XML local(por exemplo, consumindo um WebService que automaticamente serialize esse DataSet em um XML).

Agora, quantas vezes você já fez isso no seu desenvolvimento ASP.NET diário? Quase sempre, eu aposto que é porque você provavelmente não deveria estar usando DataSets! Enquanto os controles ASP.NET não diferenciam quais objetos estão sendo sua fonte de dados, você provavelmente deve estar sofrendo coma perda de performance escolhendo usar DataSets.

Razões para utilizar um DataSet… e razões pelas quais você provavelmente não deve utilizá-lo

Neste artigo, eu implicitamente afirmei: “Utilizem DataReades em aplicações web, não DataSets!” Existem alguns cenários em uma aplicação web em que o DataSet parece ser a única saída. Por exemplo, imagine que você quer armazenar em cache algumas informações do banco de dados que serão utilizadas em várias páginas ao longo do site. Estes dados podem ser específicos de um usuário, e armazenados em sessão, ou podem ser os mesmos para todos os usuários ou podem ser os mesmos para todos os usuários e, portanto, armazenados no cache de dados. No entanto, um DataReader não pode ser armazenado em cache porque ele é um objeto de dados conectado, e conexões com um banco de dados deve ser de curta duração. Ou seja, a última coisa na vida que queremos é uma conexão aberta armazenada no cache. Portanto, se você quiser ter dados armazenados em cache do banco de dados pode parecer que a única opção é usar um DataSet.

Mas não é a única opção. Você pode, ao invés disso, criar uma classe que tem as propriedades dos campos da tabela que você está armazenando no DataSet(em resumo, um objeto de negócio). E então, quando precisar você precisar armazenar os dados, utilizará um DataReader para ler as linhas e para cada iteração, criará um novo objeto dessa classe, e adicionará a um List do tipo criado. Você pode assim guardar essa coleção em cache. Este método não é apenas mais eficiente, mas eu pessoalmente acho que aumenta a facilidade de manutenção do código, diminuindo o acoplamento. Além disso, os DataSources dos WebControls do .NET são do tipo Object, logo, a chamada do método Bind() funcionará igualmente.

Outra razão pela qual você poderá pensar em utilizar um DataSet é acessar aleatoriamente os dados de uma busca, no caso de serem dados utilizados repetidamente. Por exemplo, popular uma DropDownList em função de outra. Neste caso, ainda assim é melhor acessar o banco com um DataReader, executando a query utilizando como parâmetro o item selecionado na DropDownList “pai”, manipular os dados como descrito acima(com uma coleção tipada), e popular a DropDownList dependente com os resultados.

Conclusão
Neste artigo, examinamos os fundamentos de dois tipos de acesso a dados fornecidos pelo ADO.NET: O DataReader e o DataSet. Ambos os objetos tem seus usos em aplicações .NET mas, na minha opinião, os DataSets são raramente(quando muito) úteis em aplicações ASP.NET. Existem sempre exceções, mas na ampla maioria dos casos, apenas DataReaders devem ser utilizados.

Nota: Apesar de existirem formas mais fáceis de se acessar dados atualmente(Como o facílimo LINQ to Entities), a forma mais utilizada(e performática) de acesso a dados ainda é com objetos de ADO.NET puros.

É isso. Em breve, vem a segunda parte do artigo. Abraços e keep coding!

1)Gerentes não tem conhecimento técnico: E em sua maioria, nem querem ter. Mas querem mandar nos desenvolvedores. EM TESE, desenvolvedores são subordinados a arquitetos de software(não confundir com arquiteto da informação – papel muito em destaque nas empresas de TI hoje em dia e coisa que qualquer estariágio faz), engenheiros de software ou analistas de sistema. Mas todos bem sabemos que não é assim. Poucos são os gerentes que tem a noção de que são gerentes DO PROJETO. E muitas empresas dão o aval para que o gerente se comporte assim. Porém, em programação e em qualquer profissão, seja do meio de TI ou não, ninguém respeita um chefe que não sabe fazer o nosso trabalho. Ninguém gosta de dizer “fiz uma classe X que faz routing das socilitações na camada view”, e o gerente falar “ok, agora explica”. Sim, dá raiva. Não é necessário que o gerente saiba todas as linguagens e todos os termos técnicos. Mas saber o que é uma classe  já é um bom começo. Saber o que é MVC, saber o que é uma procedure, o que é ORM, isso já adianta. E dá aos desenvolvedores mais alguns anos de vida, devido à redução do stress e da frustração de se sentir falando com uma porta.

2)Estrelismos(a.k.a “Eu sou a lenda”, ou “Eu sou o projeto”): Alguns gerentes tendem a achar que eles são o projeto, e nada anda sem eles. Partindo dessa premissa, podemos afirmar que nenhuma metodologia ágil funciona, ou seja: É besteira. Se o gerente está doente e faltou dois dias, o analista continuará fazendo os diagramas, os programadores desenvolvendo, os testers testando – e óbvio, o comecial estará cobrando. Essa postura muitas vezes soa(e é) arrogante por parte do gerente, que parece estar dizendo que o seu trabalho é mais importante do que o dos outros. E quando se fala em trabalho em equipe, todas as partes são importantes.

3) Nunca questionar, contrariar ou negociar prazos do cliente: Isso é algo que (literalmente) tira o sono da equipe. Se o cliente estima um prazo, esse prazo deve ser repassado à equipe e caso não seja aceito, deve ser negociado com o cliente. Lembrando que se uma empresa contrata serviços de desenvolvimento de software, é por que ela NÃO desenvolve software, logo não sabe quanto tempo demora pra fazer. Ou, caso tenha uma equipe interna, a equipe já está saturada de trabalho ou não tem os skills necessários para esse trabalho. Não adianta contratar mais programadores, os que já estão no projeto terão de parar o que estão fazendo para explicar aos mais novos detalhes do software, e os mais novos terão um tempo de ambientação com o produto a ser desenvolvido, com o ambiente de trabalho, com os novos colegas, etc. Lembre-se: Nove mulheres não fazem um filho em um mês.

4) Não utilizar ferramentas adequadas: Muitas empresas tem sistemas próprios para controles de tarefas e atividades. Porém, é sempre importante ter tudo isso listado, organizado e detalhado. Utilizar o Microsoft Project(ou outra ferramenta semelhante, como o Planner, o Gantt Project e o OpenProj) não só é uma boa prática, como é sinal de BOM SENSO. Além de ficar muito mais fácil de apresentar o que está sendo feito para os seus superiores, e para o cliente. E tenha sempre em mente que cada vez que você ignora isso e passa tarefas via e-mail a um programador, Deus mata um bebê foca.

5)Não assumir falhas, ou complexo de Homer Simpson(”A culpa é minha, e eu coloco ela em quem eu quiser”): Isso é vital não só na gestão de projetos, mas em qualquer área de liderança. Gestores ganham a confiança e admiração quando conseguem admitir que erraram, além de aumentar isso quando se demonstram abertos a sugestões. Sócrates já dizia: “Só sei que nada sei”. E é sempre bom não esquecer que quando algo dá errado, o que devemos procurar não são os culpados, mas sim as formas de corrigir o erro e satisfazer a necessidade do cliente. O IDGNow publicou  uma boa matéria sobre isso, disponível aqui.

Bom, é isso. Espero que o texto ajude a diminuir conflitos entre as equipes e mostre algumas falhas cometidas. Ainda escreverei um texto semelhante, sobre programadores. Só espero que não digam que eu traí o movimento do #SouDev.

Abraços e keep coding!

xhtmlConformance – Esse é um dos problemas mais comuns:

O código acima não vai funcionar com o ASP.NET AJAX. o que se costuma esquecer é que isso é definido no arquivo machine.config do servidor. Podemos sobrescrever essa configuração diretamenta na aplicação. Mas, se você não estiver tendo problemas com isso, nem se dê ao trabalho de configurar. Caso tenha esse problema, aqui estão as configurações certas:

Instalar o ASP.NET AJAX – Usuários normalmente não instalam o ASP.NET AJAX Extensions, o que torna o problema facilmente corrigível. A primeira coisa a se fazer é checar a documentação disponível sobre a instalação. O download e a documentação estão disponíveis aqui. Não se esqueça de instalar tanto na máquina de desenvolvimento, quanto no servidor – ou você terá sérios problemas na sua aplicação(ela não vai rodar, simplemente). Se você estiver usando visual studio 2005 você é velho tá esperando o quê pra trocar? precisa instalar o SP1 do Visual Studio 2005 installed, que traz os componentes necessários para a utilização dos Extensions(Leia-se: O control toolkit da Microsoft). E reserve um bom tempo para fazer isso, já que a instalação do visual studio demora 5 anos, o suficiente para já ter o Visual Studio 2010 instalado na sua máquina bastante, então é bom se programar para isso. Se estiver utilizando versões antigas da biblioteca, também pode experimentar erros.

Configuração do AJAX – Outro problema comum é tentar utilizar Ajax em sites muito antigos(por exemplo, migrados do framework 1.0, ou criados antes da aplicação do SP1 do VS2005). Basicamente, a não ser que você crie um ASP.NET AJAX Web Site utilizando o novo template que vem com o SP1 do Visual Studio 2005(e já está disponível nas versões mais recentes – ASP.NET AJAX Enabled Web Application), o AJAX não funcionará sem configuração. O que precisa ser feito é modificar o web.config com as configurações específicas do ASP.NET AJAX. Este processo está bem detalhado na documentação da biblioteca. Se estiver tendo problemas para configurar o web.config, sugiro que você crie um novo projeto do tipo ASP.NET AJAX Enabled Web Application, copie o web.config e faça as alterações necessárias para o seu site, substituindo seu antigo web.config.

Controles incompatíveis com o UpdatePanel – Tive esse problema essa semana. Tive que incluir alguns controles do tipo UpdatePanel em uma página que continha um mapa do google utilizando a biblioteca subgurim, que mostrei em outro artigo. Foi só colocar os painéis na página, que o mapa não era mais exibido. Ao procurar na documentação do UpdatePanel, dê uma olhada na sessão “Controls that Are Not Compatible with UpdatePanel Controls”. Alguns controles mais simples(Como os Validators) podem ter seus conflitos resolvidos simplesmente alterando a propriedade EnableClientScript para “false”.

A lista não está completa, mas já engloba a maior parte dos problemas ocorridos diariamente. Além dos apresentados aqui, é comum o aparecimento de problemas como manchas na pele e dor no corpo quando se tem dengue conflito entre as triggers do UpdatePanel, User Controls dentro de UpdatePanels e UpdatePanels dentro de MasterPages(o que eu particularmente acho abominável). É bom sempre checar a documentação do ASP.NET AJAX para se familiarizar com os controles e sua forma de funcionamento.

Bem, é isso. Críticas e sugestões, os comentários estão abertos. Abraços e keep coding!

No código acima, definimos meio trilhão de caracteres dentro de uma expressão regular que checa caracteres válidos dentro de uma URL. Isso é necessário para que não fiquemos obtendo bad responses do servidor do TinyURL sem necessidade. Abaixo, faremos o método que realmente encurta as URLs. Observe o código:

O código acima, através de requisições ao servidor do TinyURL, transforma o endereço recebido como parâmetro, em uma URL encurtada de forma automatizada, sem que seja necessário entrar no site para tal operação. É uma operação muito comum nos clientes desktop do Twitter, devido à limitação de 140 caracteres.
Bem, por enquanto é só. Críticas e sugestões, os comentários estão abertos!

Abraços e keep coding!

Vamos começar nossa discusão com uma visão geral da seqüência de eventos inerentes à autenticação e à autorização cada vez que uma solicitação nova é feita à página.
Quando uma requisição chega ao IIS, ele checa a validade. Se o modo de autenticação estiver definido como anônimo(como é padrão), a requisição é aprovada automaticamente. Mas se o modo de autenticação do web.config estiver definido de forma diferente, o IIS realiza a autenticação específica antes de repassar a solicitação ao ASP.NET.

O ASP.NET por sua vez checa se a representação está habilitada(falaremos sobre representação posteriormente neste artigo). Caso esteja habilidade, o ASP.NET executa com a identidade da entidade que está realizando a operação. Do contrário, a aplicação executa a ação com a identidade local do IIS e os privilégios locais definidos para a conta de usuário do ASP.NET. Por fim, o ASP.NET engine executa uma checagem de autorização nos recursos solicitados pelo usuário autenticado, e caso ele seja autorizado, retorna a requisição pelo pipeline do IIS.

Vamos falar sobre autenticação, autorização e representação e como implementá-los em ASP.NET.

Autenticação

A autenticação determina quando um usuário tem ou não uma determinada permissão, baseada nas suas credenciais. Um usuário está autorizado a acessar os recursos, desde que esteja autenticado. O arquivo Web.config contém todas as configurações para um aplicativo ASP.NET, incluindo a forma de autenticação. Um provedor de autenticação é utilizado para checar a identidade dos usuários em um sistema. Existem 3 formas de se autenticar um usuário no ASP.NET:

- Windows authentication
- Forms authentication
- Passport authentication

Forms Authentication

Este tipo de autenticação é baseado em cookies, que armazenam login e senha do usuário em arquivos texto ou em uma base de dados. Ele utiliza cookies de persistência e de sessão. Depois que um usuário está autenticado, suas credenciais são armazenadas em cookies válidos para aquela sessão. Quando o usuário não está autenticado e requisita uma página que requer autorização, é direcionado para a página de login da aplicação. O código abaixo demonstra como aplicar isso ao ASP.NET.

Perceba que o símbolo ” ? ” representa todos os usuários anônimos ou não autenticados. Normalmente, o usuário digita login e senha, clica no botão de login e o form valida os valores através de uma camada de persistência(base de dados). O código abaixo demonstra como isso pode ser validado:

O método RedirectFromLoginPage cria um ticket de autenticação e o utiliza para redirecionar o usuário, agora já autenticado, de volta à pagina solicitada, ou à uma página padrão pré-definida. O código abaixo demonstra como podemos especificar credenciais de usuário diretamente no web.config.

Independentemente da técnica de autenticação utilizada, você deve encriptar o Web.config por razões de segurança. Abordarei isso posteriormente.

Você também pode utilizar a autenticação via Forms para verificar a autenticidade de um usuário em uma base de dados onde uma base de dados armazene esse tipo de informação. O código abaixo ilustra como isso pode ser feito. O método ValidarUsuario, a ser chamado diretamente na página, recebe como parâmetros login e senha, e chama o método ValidarNaBaseDeDados(que será abstraído), que por sua vez conecta-se ao banco de dados e verifica se os dados estão corretos. No caso, os parâmetros serão os textos de dois controles do tipo TextBox. Observe o código do botão de Login na página:

E o código da classe de negócio responsável pelo Login:

Windows Authentication

A autenticação Windows é utilizada para autenticação baseada em usuários do Windows, geralmente utilizando LDAP como base de dados de usuários, utilizando o Active Directory para tal. Porém, é apenas aplicável em ambientes de intranet, aonde há um administrador com controle total sobre a rede. O código abaixo demonstra como configurar a autenticação Windows no ASP.NET.

Perceba que o símbolo ” * ” indica que todos os usuários, incluindo anônimos e não autenticados, terão acesso.A autenticação Windows se subdivide nos seguintes tipos:

-Autenticação anônima(Anonymous Authentication)
-Autenticação Básica(Basic Authentication)
-Autenticação sumária(Digest Authentication)
-Autenticação integrada ao Windows(Integrated Windows Authentication)

No modo de autenticação anônima, o IIS permite que qualquer usuário acesse a aplicação ASP.NET, sem nenhuma checagem de autenticação. No modo de autenticação básica, os usuários serão solicitados a digitar usuário e senha do Windows(este é um modo deveras inseguro).

A autenticação sumária é idêntica à básica, com a diferença que a senha é encriptada antes de ser enviada pela rede. No modo de autenticação integrada, a senha não é enviada através da rede, mas sim, o aplicativo usa alguns protocolos de autenticação de rede para que funcione.

Autenticação via passaporte

A autenticação via passaporte é uma autenticação centralizada, que utiliza o passaporte .NET da microsoft para autenticar os usuários em uma aplicação. Permite que o usuário crie um Login simples e uma senha para acessar qualquer site que implemente o serviço SSI do Passport .Abaixo, uma demonstração de como utilizar a autenticação Passport no ASP.NET.

Autorização

Autorização é o processo de determinada a acessibilidade a um recurso para um usuário já autenticado, e somente neles, garantindo que nenhum usuário não autenticado tenha acesso à aplicação. A sintaxe para autorização específica em ASP.NET segue abaixo.

Em ASP.NET, existem 3 formas de autorização:

-Autorização de URL
-Autorização de arquivo
-Autorização baseada em ACLs

Autorização de arquivo

A autorização de arquivos é executada através do FileAuthorizationModule, e é ativada quando a aplicação está configurada para utilizar autenticação Windows. Ela checa a lista de controle da acesso(Access Control List – ACL ) do arquivo para determinar se o usuário possui permissão de acessá-lo. As permissões de ACL são verificadas pelo Windows identity, ou caso a representação esteja ativa, pelo Windows identity do processo do ASP.NET.

Autorização de URL

A autenticação de URL é feita através do AuthorizationModule, que mapeia usuários e regras para URLs em aplicações ASP.NET. Este módulo pode ser utilizado para seletivamente permitir ou negar acesso a certas partes da aplicação(geralmente diretórios) para alguns usuários ou regras(grupos de usuários).

A autorização, tal qual a autenticação, é especificada no arquivo Web.config da aplicação. Abaixo, um exemplo de como se configura a autorização no ASP.NET .

Também é possível especificar o local para o qual uma ou mais regras de autorização são aplicáveis. Observe abaixo:

Também é possível restringir ou permitir acesso ao GET ou ao POST para um ou mais usuários da aplicação ASP.NET. O código a seguir habilita o post para o usuário Bruno, enquanto nega para o resto dos usuário. Isto permite definir quem tem permissão para alterar dados na aplicação,ou apenas visualizá-los.

Representação

De acordo com a documentação oficial da Microsoft, “Quando se utiliza da representação, as aplicações ASP.NET podem opcionalmente executar com a identidade do client que as está executando”. Geralmente isto é feito para evitar complicações com autenticação e autorização no código da aplicação. Ao invés disso, você conta com o IIS para autenticar o usuário e também fornecer os tokens de autenticação ao ASP.NET. A aplicação, agora representa o cliente, e em seguida, depende das configurações dos diretórios e arquivos NTFS para permitir ou não o acesso. Assegure-se de que a partição está em formato NTFS, caso contrário as permissões não terão como ser concedidas.

Note que a representação está desabilita por padrão e pode ser especificada no Web.config, como demonstrado abaixo:

Ou, para desabilitar:

Para representar uma entidade em particular, especifique-a no seu Web.config:

Bem, por enquanto é isso. Continuarei a falar sobre segurança em ASP.NET posteriormente em outros artigos. Críticas e sugestões, os comentários estão abertos.

Abraços e keep coding.

Primeiros passos

O primeiro passo é fazer um cadastro no próprio google para obter uma chave de acesso ao Maps. Isso pode ser feito aqui.

Já tendo sua chave de acesso, pegaremos agora o Subgurim, uma biblioteca freeware para acesso à API dos mapas do Google. Faça o Download e extraia na pasta Projects do Visual Studio.

Crie um novo projeto de ASP.NET webforms, e dê a ele o nome que preferir. Em seguida, no Solution Explorer, clique com o botão direito em References, e vá em Add Reference. Clique na aba Browse, navegue até a pasta onde foi extraída a DLL do Subgurim, e adicione-a ao projeto. Após isso, abra seu web.config e adicione a chave que você obteve:

Aqui cabe citar algo curioso: Eu modifiquei o nome da chave, de “googlemaps.subgurim.net” para apenas “googlemaps”, e ao executar a página nos ambientes de teste e produção, obtive uma mensagem de erro dizendo que a chave estava sendo utilizada em outro site, embora estivesse rodando normalmente na minha máquina de desenvolvimento. Provavelmente há alguma dependência forte dentro da biblioteca com relação ao nome do atributo. Sugiro que deixem exatamente este nome.

Mãos à obra

Vamos supor que temos uma empresa, cuja matriz fica em Porto Alegre, com filiais em Curitiba e São Paulo. Queremos exibir nosso endereço no mapa, assim que o cliente selecionar a filial que deseja em um DropDownList. O mapa será inicialmente carregado com o endereço da matriz. Criaremos um DropDownlist cujo Value é o endereço da empresa, e o texto exibido é composto por cidade e estado. Note que é preciso registrar o assembly, logo após a diretiva inicial da página. O código do seu arquivo ASPX deve ficar assim:

Adicionei aqui um UpdatePanel, para dar a impressão de atualização automática, e um ScriptManager para gerenciá-lo. Utilizaremos as propriedades Value de cada um dos itens da DropDownlist como parâmetro para obter o mapa do Google. Dessa forma, o usuário não terá de digitar o endereço para obter a localização no mapa, pois é a nossa intenção automatizar tudo. Reproduza o código abaixo, no seu arquivo CS de code-behind:

Detalhamento

Importamos os namespaces Subgurim.controles para termos acesso aos webcontrols responsáveis pela exibição do mapa, e o System.Configuration para que pudéssemos acessar a chave do Google através do web.config. O Google maps necessita das coordenadas(Latitude e Longitude) para centralizar um ponto e/ou traçar dois pontos através da Teoria dos grafos, por isso enviamos uma requisição com o endereço inicialmente, obtivemos as coordenadas e só então as passamos como parâmetros para o mapa.
É importante lembrar que o Google Maps não é 100% preciso. Às vezes, remover o bairro da string do endereço, ou trocar o endereço por “CEP:NumeroDoCep, Brasil” encontra endereços ditos desconhecidos, não encontrados como demonstrei aqui. Sugiro que, caso necessário, façam uma rotina condicional para contornar esse problema.

Bem, por enquanto é isso. Críticas e sugestões, os comentários estão abertos. Abraços e keep coding!

Mais uma linguagem?

O Axum (anteriormente conhecida pelo codinome Maestro) é uma linguagem de programação de domínio de concorrência específica, com base em um modelo de atores. É uma linguagem orientada a agentes com uma sintaxe C-like que , sendo uma linguagem específica de domínio, é destinada ao desenvolvimento de partes de uma aplicação de software onde haja concorrência, ou seja: Tem um uso específico. Mas ele contém o suficiente para uso geral em construções em que não é preciso mudar para uma linguagem de propósito geral de programação (como C#) para as partes seqüenciais dos componentes de concorrência. Basicamente, é voltada a aproveitar toda a capacidade das novas CPUs através de paralelismo. Pode ser encontrado aqui: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cfe70d5d-37aa-4c4c-8eeb-d4576c41baa2

Escrever um programa com paralelismo, geralmente, requer dividir uma solução em um N número de tarefas paralelas. Certos problemas são facilmente amenizáveis com a paralelização, pois as tarefas são executadas independentemente umas das outras, mas em outros casos as tarefas são interdependentes  e requerem orquestração. O Axum foi pensado para coordenar tarefas concorrentes e  escrever aplicações responsivas frente à latência.

Com o axum, os programadores podem organizar a orquestração entre componentes de uma maneira muito próxima à solução. Em outras palavras, se você puder modelar sua solução pensando em componentes interativos, progamar em Axum será fácil, e irá melhorar e facilitar a correção de bugs referentes a concorrência.

O maior motivo para se escrever uma aplicação com paralelismo é também o mais óbvio: O software fica mais rápido! -Além do desejo de que o software faça mais enquanto é executado. Isso é essencial a aplicações que precisam processar entradas de dados dos usuários enquanto executam tarefas em background.

Um dos objetivos de Axum é permitir que você programe sem se preocupar com concorrência – o seu programa torna-se rápido e responsivo por padrão, não como resultado de uma adequação.

Além de trazer novas possibilidades para o trabalho com concorrência, o Axum remove uma capacidade que historicamente causa problema: A possibilidade irrestrita de compartilhar e alterar estados entre tarefas diferentes. O modelo de isolamento do Axum garanto acesso “disciplinado” aos estados compatilhados, o que previne muitos erros comuns de programação.

O componente fundamental do Axum é o Ator(ou Agente), que nada mais é do que uma entidade isolada que executa tarefas em paralelos com outros atores. Trocando em miúdos, os atores executam ações em diferentes domínios, e objetos instanciados em um domínio não podem ser acessados por outro, e os domínios não compartilham recursos entre si(ex:memória). Ao invés disso, é utilizado o conceito de troca de mensagens. Para coordenar os atores ou utilizar a requisição de um ator como recurso de outro, uma mensagem explícita precisa ser enviada para o ator. O Axum fornece canais para isso. A linguagem foi inspirada em linguagens como Ada e SR.

Alguns recursos presentes no C# também estão presentes no Axum, porém nem todos. A saber:

Presentes

- Todas as expressões do C# 3.0, incluindo Lambda e Linq

- Todos os statements do  C# 3.0, incluindo return e brake

- Declaração de métodos e campos

- Delegates e enums

Ausentes

-Classes, interfaces e structs

-Sobrecarga de operadores

-Propriedades

-Constantes

-Métodos e campos estáticos

E as novidades que o  Axum traz podem ser divididos em 5 grupos:

-Agentes e domínios

-Canais

-Schema

-Redes

-Fluxo de controle intercalado

Das novas funcionalidades trazidas pelo Axum citadas acima, as 3 primeiras são referentes a isolamento de estado e troca de informações entre regiões isoladas da aplicação. Os dois últimos tratam de orquestração de mensagens pelos dados e controle de fluxo, respectivamente.

Agentes(atores) e domínios

Agentes são a menor unidade de isolamento no Axum. São similares a classes, mas a referência à instância de um agente não pode ser armazenada em qualquer lugar. Ao invés disso, agentes interagem entre si através de trocas de mensagens passando por canais pré-definidos. Esses canais definem portas distintas por onde passam os dados. Os canais ainda podem definir protocolos formais para a troca de informações entre comunicadores.

Um domínio é a unidade de isolamento imediatamente maior que um agente: Pode ser descrito como uma classe que possui somente campos privados e métodos, isolados de todos os outros domínios. Apenas os construtores estão disponíveis fora da definição do domínio. Agentes podem ser aninhados dentro de um domínio, tendo acesso ao estado do domínio, mas seus acessos são automaticamente orquestrados para prevenir conflitos.

Para definir os dados que trafegam entre os domínios, os agentes e as aplicações, o Axum permite um tipo especial de transferência de dados, chamado de Schema, muito parecido com o schema utilizado por um documento XML trafegado entre webservices. Um schema define a estrutura e as regras para os dados que transitam entre componentes isolados,  como os agentes.

O conceito central da interação entre os agentes é o de mensageria, como por exemplo passar valores entre componentes de forma síncrona ou assíncrona.Através do recebimento de  instruções e fluxos de controle intercalados, a manipulação de mensagens em uma estrutura semelhante, a um controle de fluxo, é simples.

Pequeno Exemplo

Eu sou um cara bastante tradicional, então começaremos com o clássico “Olá mundo”.  Após instalar o o Axum à partir do link que eu forneci acima(perceba que há versões diferentes para Visual Studio 2008 e Visual Studio 2010), crie um projeto em Axum:

Projeto sendo criado no Visual Studio

Após a criação do projeto, o Visual Studio gerará um pouco de código como de costume. seu código deve estar parecido com isso:

Observe que a sintaxe realmente é bem próxima ao C#. Substitua o código gerado pelo VS, com o código abaixo:

Analisando um pouco do código, perceberemos algumas coisas. Repare na segunda linha, o código começa com a palavra “agent”: Esse trecho de código é um agente ou ator. Como Eu expliquei acima, o Axum é baseado em um conceito conhecido dentro da computação como “Modelo de atores”, e os atores são entidades autônomas que interagem entre si através da troca de mensagens. Escrever um software em Axum é basicamente definir agentes e suas interações.

Bem, por enquanto é isso. Pretendo continuar com mais alguns artigos sobre o Axum. Críticas e sugestões, os comentários estão abertos.

Abraços e keep coding!

Arrays multidimensionais

Arrays multidimensionais: Nada mais são que arrays dentro de outros arrays. Abaixo, um exemplo de como fazer isso:

Indexando arrays

Você pode indexar a partir do fim de um array usando o sinal de menos (­), onde ­1 é o índice do
último elemento; Também podemos usar faixas de valor (entre um índice inicial e final separados
por dois sinais de ponto – .. ):

O ruby possui um alias para arrays de strings, que é o %w. Observe um exemplo abaixo:

Hashes

Hashes também são coleções, assim como os arrays. A diferença é que o índice dos Arrays é sempre numérico, e Hashes são coleções par-valor onde os índices podem ser objetos também.

Mesmo que os arrays forneçam uma boa forma de indexar uma coleção de itens por número, há situações
que seria mais conveniente indexar de alguma outra forma. Se, por exemplo, ao listar os filmes da sua coleção de DVDs,seria mais significativo ter cada filme indexado pelo nome e/ou pelo gênero, ao invés de números: 26, 42 e assim por diante. O Ruby possui uma classe que permite que você faça isso: A classe Hash. Hashes são conhecidos em outras linguagens como dicionários(em java e em .NET, classes que implementam a interface IDictionary). Tal qual um dicionário de verdade, as entradas são indexadas por uma chave única (em um dicionário, seria uma palavra) e um valor (em um dicionário, seria a definição da palavra).

Você pode criar um hash criando uma nova instância da classe Hash:

Ambos os exemplos acima criam um Hash vazio. Um objeto Hash sempre têm um valor padrão –
isto é, um valor que é retornado quando nenhum valor específico é encontrado em um dado índice.
Nestes dois exemplos, segundoHash é inicializado com o valor default,”um filme qualquer”. A variável primeiroHash não é inicializado com um valor então seu valor padrão será nil. Tendo criado um objeto Hash, podemos adicionar itens a ele usando uma sintaxe semelhante à dos
arrays – isto é, colocando um índice nos colchetes e usando o sinal de igual para atribuir um
valor.A diferença óbvia aqui é que, com um array, o índice ( a chave ) deve ser um número inteiro; com
um Hash, ele pode ser qualquer item de dado único. Observe o exemplo abaixo:

Muitas vezes, a chave pode ser um número ou, como no código acima, uma string. Por princípio,
uma chave pode ser qualquer tipo de objeto. Dada uma classe Qualquer, a seguinte atribuição é totalmente válida:

Existe uma forma mais simples de criar e inicializar hashes. Adicione a chave seguida por => e o valor associado. Cada par chave-valor deve ser separado por uma vírgula e o lote todo colocado entre os sinais de chaves {}:

Repare que no código acima, as últimas duas linhas tentam imprimir chaves que não existem. Nesse caso, o ruby exibe o valor default, que é definido no momento em que a instância é criada. Para o hash de nome segundoHash, definimos esse valor na instância, no código um pouco acima, quando o instanciamos(foi passado como parâmetro para o método new). No caso do hash musicHash, será retornado o valor nil.

Os hashes ainda possuem os métodos keys e values, que retornam um array com os respectivos valores.

Métodos

Os métodos em ruby tem algumas particularidades(que podem ser utilizadas para o bem ou para o mal). Observe o código abaixo:

Ambos são o mesmo método, apenas com pequenas diferenças na declaração. O Ruby não exige parênteses na declaração ou na invocação de métodos(embora seja uma boa prática utilizá-los), e embora tenha a palavra return como reservada, não exige que ela seja colocada no retorno do método, pois o interpretador considera sempre a última linha como um retorno.

O ruby também possui métodos estáticos, ou seja: Métodos de classe, que não precisam de uma instância para serem chamados. Observe abaixo um exemplo:

Na classe acima, o método Soma é precedido pela palavra self, o que indica que é um método estático e não precisa de um objeto instanciado para ser chamado. Observe o que ocorre ao chamarmos ambos os métodos sem instanciarmos a classe:

Invocação de métodos no Ruby

Ao chamar o método soma que foi definido como estático, temos o resultado esperado(3), mas ao chamar o método Subtracao obtemos um erro, pois não instanciamos o objeto anteriormente.

Por convenção, os métodos em ruby, ao contrário das classes, começam com letra minúscula. Escrevi os métodos com letras maiúsculas por que eu sou um imbecil por costume, já que a minha linguagem “nativa” de programação é o C#.

Bem, por enquanto é isso. Sugestões e críticas, os comentários estão abertos.

Abraços e keep coding.

Arrays(Vetores)

Em Ruby, um array é um objeto que contém um número de items. Estes items podem ser variáveis(como strings, inteiros, Hash etc)  ou até mesmo outros objetos(incluindo outros arrays para criar um array/vetor multimensional). Uma vez que os items foram agrupados em um array, você pode realizar tarefas como ordenação em ordem alfabética ou numérica, acessar e alterar o valor atribuído a cada item do array e até mesmo passar o grupo de items como argumento para um método. Há mais de uma forma de se criar um array em Ruby. Essencialmente, um array é uma instância da classe Array. Logo, podemos criar um array diretamente atribuindo valores a ele, ou simplesmente criar como um objeto, como demonstrado abaixo:

O construtor da classe Array tem algumas sobrecargas, logo poderíamos ter passado como parâmetro para ele apenas o tamanho do array (Ex: Array.new 7 ),o tamanho e um valor padrão para os elementos (Ex: Array.new 7, “hoje”) ou diretamente os valores  de cada elemento (Ex:  Vetor = [1,2,3]). Abaixo há uma pequena demonstração sobre as mais variadas formas de se instanciar um Array.

As várias maneiras de se instanciar um array

Outros métodos que temos ainda para arrays são empty?,shift, pop,push,delete, delete_at e size. O primeiro verifica se o array está vazio, shift remove o primeiro elemento do array, pop remove o último elemento do array,push adiciona um elemento, delete remove um elemento passado como parâmetro,delete_at remove um elemento que esteja em uma posição passada como parâmetro e size retorna o tamanho do array. Execute o código abaixo e verifique o resultado:

Observe o resultado do código acima:

Exclusão de objetos em um array

Os arrays em Ruby permitem infinitas possibilidades. Notem que o array acima possui elementos Fixnum e strings também. Sim, arrays em ruby podem conter diferentes tipos de elementos. Acessar elementos em arrays também é algo bem simples. Podemos acessar através do índice, ou através do próprio elemento. Execute o código abaixo e veja os resultados:

Outra coisa interessante do ruby é a subtração de vetores, algo inexistente em linguagens como Java e C#. Execute o código abaixo e observe o resultado:

O resultado é um vetor com os elementos que estão no primeiro vetor, mas não no segundo: Ordenação de arrays é também muito simples em Ruby. Utilizando o método sort!, ordenamos o array, e utilizando o método reverse (cuja utilização já foi demonstrada quando falei de strings – lembrando que strings nada mais são que arrays de caracteres), podemos ordenar nossos arrays sem nenhum problema. Experimente rodar o código abaixo, e verifique os resultados:

Ordenação de Arrays no Ruby

E para terminar, vamos fazer uma atribuição de valores a mais de um elemento ao mesmo tempo. Execute o código abaixo, e veja como o Ruby faz isso:

Sobrescrevendo elementos de um array

Bem, por enquanto é só. Os Arrays são uma ferramenta muito poderosa no Ruby, e ainda há muito a falar sobre eles, mas tópicos mais avançados deixarei para que vocês descubram. Dúvidas, críticas e sugestões, os comentários estão abertos. Espero que tenham gostado do artigo(e do fato de não estar mais centralizado, hehe). Abraços e keep coding!