O evento contou com cerca de 500 atividades e todas de que participei foram interessantes e geraram debates produtivos. Na terça-feira, 14 de maio, participei de uma oficina tutorial sobre CSS3 com o Bert Bos, um dos criadores do padrão CSS. Como o conheci pessoalmente, não podia perder a oportunidade de fazer uma entrevista com ele sobre algumas questões sobre as quais tenho curiosidade, como: o contexto que o levou a trabalhar nos primeiros rascunhos do padrão CSS, o que ainda falta ser aprimorado e a sua perspectiva para a evolução do CSS e do HTML em longo prazo.

Confira a entrevista completa abaixo:

Versão em inglês aqui.

1. Quais eram as necessidades específicas e o contexto que o levaram a trabalhar nos primeiros rascunhos do padrão CSS ?

Quando Tim Berners-Lee criou seu primeiro navegador Web, este possuía folhas de estilos, mas apenas para o usuário. A ideia era que o autor especificasse o conteúdo de um documento, mas que o navegador junto com o usuário determinassem como melhor exibi-lo.

Durante certo tempo, esse foi o modelo, afinal de contas, o usuário é quem melhor sabe qual tipo de tela ele tem, de quais cores ele gosta mais, o quão grande são as janelas em seu sistema. Foram criados diversos outros navegadores que permitiam ao usuário configurar a exibição do conteúdo, como o Viola e o Mosaic. Eu mesmo criei também um navegador dessa forma, chamado Argo. As folhas de estilo no meu navegador eram mais poderosas, mas ainda assim apenas para o usuário, e não para o autor.

Os primeiros autores na Web eram em sua maioria cientistas. Eles estavam acostumados a escrever documentos e deixar outra pessoa decidir sua aparência: jornais científicos normalmente fornecem suas próprias folhas de estilo (em LaTeX, por exemplo), assim o HTML se encaixou bem nesse modelo.

Mas conforme a Web se tornava mais popular, designers começaram a se interessar e a opinião deles era de que, por serem designers, eles sabiam com mais propriedade que os usuários como apresentar um documento da melhor forma. Assim como a aparência de um livro lhe informa sobre que tipo de livro se trata, a aparência de um documento deveria também lhe dizer algo sobre seu conteúdo.

Mas, naquela época, em 1994, isso era impossível de se fazer usando HTML. Assim, duas coisas aconteceram: os designers perceberam que o HTML permitia o uso de imagens, e então eles começaram a substituir textos por imagens, porque assim eles tinham total controle. E o Netscape, o primeiro navegador comercial, notando essa demanda dos designers, começou a adicionar extensões proprietárias ao HTML, como atributos de cor e de plano de fundo, um elemento <center>, e elementos de espaçamento.

Os usuários não estavam felizes com isso: você não pode redimensionar imagens ou recortar e colar partes delas, e imagens também não proviam acessibilidade. E os elementos proprietários faziam os documentos ficarem grandes e difíceis de serem mantidos, e mais difíceis para o usuário aplicar estilos. E, assim, pessoas na lista de discussão www-talk@w3.org começaram a procurar soluções.

Se você quiser ler a história completa do que aconteceu naquela época, você pode ler o capítulo relevante no livro que Håkon e eu escrevemos ou a tese de PhD do Håkon. Em suma: diversas pessoas propuseram linguagens de folhas de estilo, algumas vezes versões simplificadas do que já existia no mundo do SGML, por que o HTML foi derivado do SGML. Duas dessas linguagens eram a “Cascading HTML Style Sheets” do Håkon e a minha linguagem “Streaming Style Sheets”.

Quando eu olhei para a linguagem do Håkon, eu vi uma ideia interessante, que era a de que você poderia ter um tipo de negociação entre o que o autor propunha e o que o usuário queria. Nós começamos a trabalhar juntos, combinando as ideias dele e as minhas (por exemplo, seletores contextuais e a aplicação de folhas de estilos para outros tipo de documento além de HTML), nós inventamos uma nova sintaxe e logo nossa proposta (chamada “Cascading Style Sheets” omitindo o “HTML” do nome) se tornou a mais popular, e outras pessoas começaram a contribuir.

Em 1995, o novo grupo de trabalho de HTML assumiu a tarefa, de modo a torná-lo um padrão. E um pouco depois o grupo se separou, formando o grupo de trabalho de CSS existente ainda hoje.

2. Você já considerou aplicar regras de estilo CSS em outros tipos de conteúdo (além de HTML)? Se isso já foi feito, você poderia fornecer um exemplo? Caso contrário, você poderia discutir em que outros conteúdos poderia ser útil o uso de CSS?

Uma das ideias da minha proposta original de folhas de estilo era justamente isto: usar a mesma linguagem de folhas de estilo para uma ampla gama de documentos, não apenas para HTML (meu próprio navegador podia exibir muitos documentos SGML, e HTML era apenas uma subclasse destes).

Naquela época, ainda não existia XML, mas nós pensamos que deveríamos ter uma linguagem de folhas de estilo para SGML simples ou qualquer coisa que tivesse uma estrutura simples de árvore.

Quando o XML foi criado um pouco depois, acabou combinando muito bem com o que tínhamos em mente e assim o CSS pôde ser utilizado com grande parte de documentos XML também.

E o CSS pode ser usado, e está de fato sendo usado, para outras coisas também. Um exemplo é a biblioteca de interfaces gráficas Qt. Ela usa CSS para aplicar estilo aos componentes da interface gráfica.

 3. Quais partes da atual versão da estecificação do CSS você acha que ainda precisa de mais aprimoramentos?

Tem muitas coisas que ainda estão faltando, especialmente agora que editores estão usando CSS fortemente para editoração de livros, tanto em papel quanto para e-books.

Originalmente nós desenhamos o CSS para ser a linguagem de estilos simples, e adicionamos XSL (por exemplo, XSLT + XSL-FO) para as tarefas complexas, como edição de livros. Mas, no momento, o desenvolvimento do XSL parou, e nós não sabemos quando ele irá continuar, e então os editores estão migrando para o CSS.

Apenas para dar alguns exemplos de coisas que estão faltando no CSS: para o tratamento adequado de hipertexto, nós precisamos de elementos colapsantes (veja aqui) ou, de modo geral, uma forma de alternar o estado de elementos (e não apenas ‘checkboxes’) entre dois possíveis estilos. Nós também não temos ainda containers que formem uma pilha de páginas em abas.

E temos *muito* trabalho a ser feito para tudo que envolva texto paginado: notas de rodapé, elementos flutuantes no topo ou no pé da página, texto que se estenda atravessando colunas, divisão de texto em múltiplos fluxos e alinhamento desses fluxos de texto em um template de página baseado em uma grade, referências cruzadas (como “veja página 7″), índices alfabéticos, ‘copyfitting’ (fazer um texto caber exatamente em um espaço alocado), cabeçalhos e rodapés contendo texto bidirecional ou fórmulas matemáticas etc. Eu comecei a colecionar uma lista de requisitos que pode sr vista aqui.

4. Qual é a sua perspectiva para a evolução do CSS e do HTML em longo prazo? Como você acha que essas tecnologias evoluirão nas próximas décadas?

Foi muito bom o HTML4 ter permanecido sem modificações por tanto tempo. Isso nos permitiu compreendê-lo e criar softwares interessantes. Nós esperávamos certos tipos de aplicações, mas algumas vezes levou muitos anos para que as pessoas se tornassem capazes de efetivamente criá-los. Por exemplo, nós esperávamos que algo como os microformatos fosse surgir, mas levou bastante tempo até algumas pessoas de fato descobrirem como fazê-lo corretamente. E algumas coisas foram inesperadas e apenas descobertas depois.

Então, de certa forma, é uma pena que agora nós tenhamos que migrar nossos softwares para o HTML5, mesmo que o HTML5 adicione novas funcionalidades interessantes. Eu estou lentamente migrando meus softwares, mas levará um bom tempo até que eu possa fazer com o HTML5 o que eu posso fazer com o HTML4. Assim, estou esperançoso de que grande parte de tudo o que é o HTML5, ou sua próxima revisão, volte a permanecer estável por 10 ou 15 anos.

Para o CSS, não tenho muita certeza sobre o que quero. Como visto acima, há várias coisas que precisamos adicionar para satisfazer os vários novos usos. Mas o CSS não foi desenhado para tarefas complexas. Ele foi feito para ser usado por usuários comuns para aplicação de estilos simples. Ao contrário do proposto, o CSS está se tornando complexo demais para a maioria das pessoas. Então talvez seja o momento de se recomeçar do zero criando duas novas linguagens: uma simples que todas as pessoas saibam usar, mas que talvez seja limitada na quantidade de controles detalhados que oferece, e uma avançada, adequada até mesmo para editoração complexa de livros e revistas. Mas eu ainda não vi nenhuma proposta que tenha me agradado.

É bom ver diversos pré-processadores de CSS para ajudar os usuários avançados, como o SASS e o LESS. Eu tinha esperança de eles aparecessem mais cedo. Espero que eles se desenvolvam e se tornem ainda melhores. Por outro lado, estou surpreso com o tamanho de algumas folhas de estilo que as pessoas têm criado. As mais complexas que eu mesmo criei têm 10 kbytes, e a maioria é bem menor que isso. Fico me questionando se eles estão fazendo a coisa certa…

Dessa forma, em termos práticos, acho que ainda iremos adicionar novas funcionalidades ao CSS durante os próximos poucos anos. Haverá, sem dúvidas, novos módulos no CSS3, e alguns módulos que já estão finalizados serão provavelmente estendidos ou substituídos por um módulo do CSS4.

Continuaremos mantendo a retrocompatibilidade do CSS, mas isso também significa se tornará gradativamente mais difícil de adicionar novas funcionalidades a ele, e suas sintaxes poderão não ser as mais intuitivas.

Tradução técnica: Felipe Sanches

O post Entrevista com Bert Bos, criador do padrão CSS apareceu primeiro em .

O tratamento de erros vai permitir que o aplicativo lide de forma mais amigável com os erros, exibindo mensagens de erros adequadas em cada situação. O registro de erros permitirá que possamos encontrar e corrigir os erros que ocorreram durante a execução da aplicação.

O que você vai aprender:

• Como adicionar manipulação de erro global para a configuração do aplicativo;
• Como adicionar o tratamento de erros a nível de aplicação, de página e de código;
• Como registrar erros para posterior análise;
• Como exibir mensagens de erro que não comprometam a segurança;
• Como implementar módulos registro de erros e manipuladores (ELMAH) de registro de erros;

Este artigo foi integralmente baseado no artigo original: http://www.asp.net/web-forms/tutorials/aspnet-45/getting-started-with-aspnet-45-web-forms/aspnet-error-handling (com algumas alterações e portado para a linguagem VB .NET).

Conceitos

As aplicações ASP.NET devem ser capaz de lidar com os erros que ocorrem durante a execução de uma forma consistente. A ASP.NET usa o Common Language Runtime (CLR), que fornece uma maneira de notificar as aplicações de erros de uma maneira uniforme. Quando ocorre um erro, uma exceção é lançada. Uma exceção é qualquer erro, condição ou comportamento inesperado que um aplicativo encontra durante sua execução.

Na plataforma .NET, uma exceção é um objeto que herda da classe System.Exception. Uma exceção é lançada a partir de uma área de código onde ocorreu um problema. A exceção é passada para a pilha de chamadas, um lugar onde a aplicação fornece código para manipular a exceção. Se o aplicativo não tratar a exceção, o navegador é forçado a exibir os detalhes do erro.

Como melhor prática, lidamos com os erros ao nível do código usando blocos try/catch /finally dentro do código. Geralmente, colocamos esses blocos de modo que o usuário possa corrigir problemas no contexto em que eles ocorrem. Se os blocos de tratamento de erros estiverem muito longe de onde ocorreu o erro, torna-se mais difícil fornecer aos usuários a informação do que ele precisa para corrigir o problema.

Classe de exceção

A classe Exception é a classe base da qual as exceções herdam. A maioria dos objetos de exceção são instâncias de alguma classe derivada da classe Exception, como a classeSystemException, a classe IndexOutOfRangeException, ou a classe ArgumentNullException. A classe Exception tem propriedades, tais como a propriedade StackTrace, a propriedadeInnerExceptio e a propriedade Message, que fornecem informações específicas sobre o erro que ocorreu.

Hierarquia de herança de exceção

O runtime tem um conjunto base de exceções que derivam da classe SystemException, que ele lança quando uma exceção for encontrada. A maioria das classes que herdam da classe de exceção, como a classe IndexOutOfRangeException e a classe ArgumentNullException, não implementam membros adicionais. Portanto, a informação mais importante para uma exceção pode ser encontrada na hierarquia das exceções, o nome da exceção, e as informações contidas no exceção.

Hierarquia manipulação de exceção

Em uma aplicação ASP.NET Web Forms, exceções podem ser tratadas com base em uma hierarquia de tratamento específico. Uma exceção pode ser tratada nos seguintes níveis:

1. Nível de aplicação;
2. Nível de página;
3. Nível de código.

Quando um aplicativo lida com exceções, informações adicionais sobre a exceção que é herdada da classe Exception muitas vezes podem ser recuperadas e exibidas para o usuário. Além do nível de aplicativo, página e código, você também pode lidar com exceções no nível de módulo HTTP e/ou usando um manipulador personalizado IIS.

Tratamento de erros a nível de aplicação

Você pode lidar com erros padrão no nível do aplicativo, quer seja modificando a configuração de seu aplicativo ou adicionando um manipulador Application_Error no arquivoGlobal.asax de sua aplicação.

Você pode lidar com erros padrão e erros de HTTP adicionando uma seção customErrors no arquivo Web.config. A seção customErrors permite que você especifique uma página padrão para a qual os usuários serão redirecionados quando ocorrer um erro. Ele também permite que você especifique páginas individuais para erros de código específicos de status.

A seguir, temos um exemplo de configuração feita no arquivo web.config que define o tratamento de erro neste escopo:

<configuration>
 <system.web>
 <customErrors mode="On" defaultRedirect="ErrorPage.aspx?handler=customErrors%20section%20-%20Web.config">
 <error statusCode="404" redirect="ErrorPage.aspx?msg=404&amp;handler=customErrors%20section%20-%20Web.config"/>
 </customErrors>
 </system.web>
</configuration>

Infelizmente, quando usamos a configuração para redirecionar o usuário para uma página diferente, não temos os detalhes do erro que ocorreu.No entanto, podemos capturar os erros que ocorrem em qualquer lugar na aplicação, adicionando código para o manipulador Application_Error no arquivo Global.asax, conforme mostra o exemplo a seguir:

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
        ' dispara quando um erro ocorrer
        Dim exc As Exception = Server.GetLastError()

        If TypeOf exc Is HttpUnhandledException Then
            ' Passa o erro para a página de erro.
            Server.Transfer("ErrorPage.aspx?handler=Application_Error%20-%20Global.asax", True)
        End If
    End Sub

Tratamento de erro a nível de página

Um manipulador a nível de página retorna o usuário para a página onde o erro ocorreu, mas como as instâncias dos controles não são mantidas, não haverá mais nada na página. Para fornecer os detalhes do erro para o usuário, devemos escrever especificamente os detalhes do erro na página.

Devemos usar um manipulador de erro a nível de página para registrar erros sem tratamento ou para levar o usuário para uma página que pode exibir informações úteis.

Este exemplo de código mostra um manipulador para o evento de erro em uma página ASP.NET. Este manipulador captura todas as exceções que não estão sendo tratadas dentro do bloco try/catch na página.

Private Sub Page_Error(sender As Object, e As EventArgs)

Dim exc As Exception = Server.GetLastError()
' Trata o erro
If TypeOf exc Is HttpUnhandledException Then
     ErrorMsgTextBox.Text = "Ocorreu um erro nesta página " 
End If
    ' LImpar ao erro a partir do servidor
    Server.ClearError()
End Sub

Depois de tratar um erro, você deve limpá-lo, chamando o método ClearError do objeto Server (classe HttpServerUtility); caso contrário, você vai ver um erro que tenha ocorrido anteriormente.

Tratamento de erro a nível de código

A instrução try-catch consiste em um bloco try seguido de uma ou mais cláusulas de captura, que especificam os manipuladores para exceções diferentes. Quando uma exceção é lançada, o Common Language Runtime (CLR) procura a instrução catch que trata esta exceção.

Se o método atualmente em execução não contém um bloco catch, a CLR olha para o método que chamou o método atual, e assim por diante, até a pilha de chamadas. Se nenhum bloco catch é encontrado, a CLR exibe uma mensagem de exceção não tratada para o usuário e para a execução do programa.

O exemplo de código a seguir mostra uma maneira comum de usar try/catch/finally para manipular erros:

Try
    file.ReadBlock(buffer, index, buffer.Length)
Catch e As FileNotFoundException
    Server.Transfer("NoFileErrorPage.aspx", True)
Catch e As System.IO.IOException
    Server.Transfer("IOErrorPage.aspx", True)
Finally
    If file IsNot Nothing Then
 	file.Close()
   End If
End Try

No código acima, o bloco try contém o código que precisa ser protegido contra uma possível exceção. O bloco é executado até que uma exceção é lançada ou o bloco é concluído com êxito. Se uma excepção FileNotFoundException ou uma exceção IOException ocorre, a execução é transferida para uma página diferente. Em seguida, o código contido no bloco finally é executado, se ocorreu um erro ou não – o código do bloco finally sempre será executado.

Incluindo o suporte ao registro de erros

Antes de adicionar a manipulação de erros em nossa aplicação, vamos adicionar o suporte ao registro de erros, adicionando uma classe ExceptionUtility na pasta de Logic do nosso projeto.

Ao fazer isso, cada vez que o aplicativo tratar um erro, os detalhes do erro serão adicionados ao arquivo de log de erros.

Clique com o botão direito do mouse sobre a pasta Logic e selecione Add -> New Item;

A seguir, selecione Visual Basic -> Code e o template Class e informe o nome ExceptionUtility.vb e clique no botão Add;

A seguir, digite o código abaixo neste arquivo:

Imports System
Imports System.Collections.Generic
Imports System.Linq
Imports System.Web
Imports System.IO

Namespace WingtipToys.Logic
    ' Creia o nosso utilitário de tratamenteo de exceptions
    Public NotInheritable Class ExceptionUtility
        ' Todos os métodos são estativiso 
        Private Sub New()
        End Sub

        ' Registra uma exceção
        Public Shared Sub LogException(exc As Exception, source As String)
            ' Inclui a logica para as registrar as exceções
            ' Pega o caminho absoluto para o arquivo de log
            Dim logFile As String = "App_Data/ErrorLog.txt"
            logFile = HttpContext.Current.Server.MapPath(logFile)

            ' Abre o arquivo de log para acnexar e escrever o log
            Dim sw As New StreamWriter(logFile, True)
            sw.WriteLine("********** {0} **********", DateTime.Now)
            If exc.InnerException IsNot Nothing Then
                sw.Write("Inner Exception Type: ")
                sw.WriteLine(exc.InnerException.[GetType]().ToString())
                sw.Write("Inner Exception: ")
                sw.WriteLine(exc.InnerException.Message)
                sw.Write("Inner Source: ")
                sw.WriteLine(exc.InnerException.Source)
                If exc.InnerException.StackTrace IsNot Nothing Then
                    sw.WriteLine("Inner Stack Trace: ")
                    sw.WriteLine(exc.InnerException.StackTrace)
                End If
            End If
            sw.Write("Exception Type: ")
            sw.WriteLine(exc.[GetType]().ToString())
            sw.WriteLine("Exception: " + exc.Message)
            sw.WriteLine("Source: " + source)
            sw.WriteLine("Stack Trace: ")
            If exc.StackTrace IsNot Nothing Then
                sw.WriteLine(exc.StackTrace)
                sw.WriteLine()
            End If
            sw.Close()
        End Sub
    End Class
End Namespace

Quando ocorre uma exceção, ela pode ser gravada em um arquivo de log de exceção chamando o método LogException. Este método tem dois parâmetros: o objeto da exceção e uma string contendo detalhes sobre a origem da exceção. O log de exceção é gravado no arquivo ErrorLog.txt na pasta App_Data.

Adicionando uma página de erro

Em nossa aplicação usaremos uma página para exibir erros. A página de erro é projetada para mostrar uma mensagem de erro segura para os usuários do site. No entanto, se o usuário for um desenvolvedor fazendo uma solicitação HTTP que está sendo servida localmente na máquina onde reside o código, iremos exibir detalhes de erro adicionais na página de erro que serão vistas apenas pelo desenvolvedor.

Clique com o botão direito do mouse sobre o nome do projeto e selecione Add -> New Item. Selecione Visual Basic -> Web e, a seguir, o template Web Form using Master Page e informe o nome ErrorPage.aspx e clique no botão Add.

Selecione o arquivo Site.Master como a página principal e, em seguida, escolha OK.

A seguir, substitua a marcação existente pelo código a seguir:

<%@ Page Title="" Language="vb" AutoEventWireup="false" MasterPageFile="~/Site.Master" CodeBehind="ErrorPage.aspx.vb" Inherits="WingTipToys.ErrorPage" %>
<asp:Content ID="Content1" ContentPlaceHolderID="HeadContent" runat="server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="FeaturedContent" runat="server">
     <h2>Erro:</h2>
    <p></p>
    <asp:Label ID="FriendlyErrorMsg" runat="server" Text="Label" Font-Size="Large" style="color: red"></asp:Label>

    <asp:Panel ID="DetailedErrorPanel" runat="server" Visible="false">
        <p>
            Erro Detalhado:
            <br />
            <asp:Label ID="ErrorDetailedMsg" runat="server" Font-Bold="true" Font-Size="Large" /><br />
        </p>
        <p>
            Tratamento Erro:
            <br />
            <asp:Label ID="ErrorHandler" runat="server" Font-Bold="true" Font-Size="Large" /><br />
        </p>
        <p>
            Mensagem de erro Detalhada:
            <br />
            <asp:Label ID="InnerMessage" runat="server" Font-Bold="true" Font-Size="Large" /><br />
        </p>
        <pre>
            <asp:Label ID="InnerTrace" runat="server"  />
        </pre>
    </asp:Panel>

</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderID="MainContent" runat="server">
</asp:Content>

No arquivo code-behind ErrorPage.aspx.vb inclua o código abaixo:

Imports System
Imports System.Collections.Generic
Imports System.Linq
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls
Imports WingTipToys.WingtipToys.Logic

Public Class ErrorPage
    Inherits System.Web.UI.Page

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        ' Cria as mensagens de erro seguras
        Dim generalErrorMsg As String = "Ocorreu um problema na aplicação web. Tente novamente. " + "Se o ocorre persistir contacte o suporte técnico."
        Dim httpErrorMsg As String = "Ocorreu um erro HTTP. Página não encontrada. Tente novamente."
        Dim unhandledErrorMsg As String = "O erro não foi tratado pelo código da aplicação."

        ' exibe as mensagens de erro
        FriendlyErrorMsg.Text = generalErrorMsg

        ' Determina onde o erro foi tratado
        Dim errorHandler__1 As String = Request.QueryString("handler")
        If errorHandler__1 Is Nothing Then
            errorHandler__1 = "Error Page"
        End If

        ' pegao ultimo erro do servidor.
        Dim ex As Exception = Server.GetLastError()

        ' Pega o numero do erro passado como um valor querystring 
        Dim errorMsg As String = Request.QueryString("msg")
        If errorMsg = "404" Then
            ex = New HttpException(404, httpErrorMsg, ex)
            FriendlyErrorMsg.Text = ex.Message
        End If

        'Se a exceção não existe mais, cria uma exceção genérica
        If ex Is Nothing Then
            ex = New Exception(unhandledErrorMsg)
        End If

        ' exibe os detalhes de erro somente para o desenvolvedor.SOMENTE ACESSO LOCAL
        If Request.IsLocal Then
            'mensagem de erro detalhada
            ErrorDetailedMsg.Text = ex.Message

            ' mostra onde o erro foi tratado
            ErrorHandler.Text = errorHandler__1

            ' mostra o acesso local 
            DetailedErrorPanel.Visible = True

            If ex.InnerException IsNot Nothing Then
                InnerMessage.Text = ex.[GetType]().ToString() + "<br/>" + ex.InnerException.Message
                InnerTrace.Text = ex.InnerException.StackTrace
            Else
                InnerMessage.Text = ex.[GetType]().ToString()
                If ex.StackTrace IsNot Nothing Then
                    InnerTrace.Text = ex.StackTrace.ToString().TrimStart()
                End If
            End If
        End If

        ' registra a exceção
        ExceptionUtility.LogException(ex, errorHandler__1)

        ' limpa o erro do servidor
        Server.ClearError()
    End Sub

End Class

Quando a página de erro for exibida, o evento Page_Load é executado. No manipulador Page_Load, o local onde o erro foi primeiro tratado é determinado. Então, o último erro que ocorreu é obtido através do método GetLastError do objeto Server.

Se a exceção não existir mais, uma exceção genérica será criada. Então, se o pedido HTTP foi feita localmente, todos os detalhes do erro serão mostrados. Neste caso, apenas a máquina local executando a aplicação web vai ver esses detalhes do erro. Depois que as informações do erro forem exibidas, o erro é adicionado ao arquivo de log e o erro é eliminado do servidor.

Exibindo mensagens de erro não tratadas para a aplicação

Ao adicionar uma seção customErrors no arquivo Web.config, você pode rapidamente tratar erros simples que ocorrem na aplicação. Você também pode especificar como lidar com erros com base no seu valor de código de status, como 404 – Arquivo não encontrado.

Abra o arquivo web.config da raiz do projeto e inclua a seção customErrors no interior do nó conforme abaixo:

A seção customErrors especifica o modo, o que é definido como “On” (mode=”On”). Também especifica o defaultRedirect, que diz à aplicação para qual página navegar quando ocorrer um erro.

Além disso, adicionamos um elemento de erro específico que define como lidar com um erro 404 quando uma página não for encontrada. Mais adiante, vamos adicionar o tratamento de erro adicional que irá capturar os detalhes de um erro a nível de aplicação.

Testando a aplicação

Execute a aplicação pressionando CTRL+F5 (ou clicando no botão do menu que executa a aplicação). O navegador irá abrir e apresentar a página Default.aspx:

Informe a seguinte URL no navegador para provocar um erro: http://localhost:674846/NoPage.aspx (o número da porta para sua aplicação será diferente).

A página de erro ErrorPage.aspx será exibida conforme a figura a seguir:

Quando você solicita a página NoPage.aspx que não existe, a página de erro irá mostrar a mensagem de erro simples e as informações de erro detalhadas (se detalhes adicionais estiverem disponíveis).

No entanto, se o usuário solicitou uma página inexistente a partir de um local remoto, a página de erro só vai mostrar a mensagem de erro em vermelho.

Incluindo uma exceção para testes

Para verificar como o aplicativo irá funcionar quando ocorre um erro, você pode deliberadamente criar condições de erro. Vamos lançar uma exceção de teste quando a página padrão for carregada para ver o que acontece.

Abra o arquivo code-behind Default.aspx.vb e no evento Load da página inclua o código abaixo:

Public Class _Default
    Inherits Page

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
        Throw New InvalidOperationException("O Erro : InvalidOperationException " + "õcorreu no evento Page_Load ná página Default.aspx.")
    End Sub
End Class

No código acima estamos criando uma exceção do tipo InvalidOperationException, que irá ocorrer quando a página Default.aspx for carregada.

Testando a aplicação

Execute a aplicação novamente pressionando CTRL+F5 (ou clicando no botão do menu que executa a aplicação). O navegador irá abrir e apresentar a página Default.aspx.

A página exibirá a mensagem de erro conforme abaixo:

Adicionando o tratamento de erros a nível de aplicativo

Em vez de capturar a exceção usando a seção customErrors no arquivo Web.config, onde você ganha pouca informação sobre a exceção, você pode interceptar o erro no nível da aplicação e recuperar detalhes do erro.

Abra o arquivo Global.asax e atualize o código do evento Application_Error conforme abaixo:

 Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
        ' pega o último erro do servidor
        Dim exc As Exception = Server.GetLastError()

        If TypeOf exc Is HttpUnhandledException Then
            If exc.InnerException IsNot Nothing Then
                exc = New Exception(exc.InnerException.Message)
                Server.Transfer("ErrorPage.aspx?handler=Application_Error%20-%20Global.asax", True)
            End If
        End If

    End Sub

Quando ocorre um erro na aplicação, o manipulador Application_Error é chamado. Nesse manipulador, a última exceção é recuperada e revisada. Se a exceção ocorreu sem um tratamento e a exceção contém detalhes de uma exceção interior (InnerException não é nulo), a aplicação transfere a execução para a página de erro onde os detalhes da exceção são exibidos.

Testando a aplicação

Execute a aplicação novamente pressionando CTRL+F5 (ou clicando no botão do menu que executa a aplicação). O navegador irá abrir e apresentar a página Default.aspx.

A página exibirá a mensagem de erro conforme abaixo:

Adicionando o tratamento de erros a nível de página

Podemos adicionar a manipulação de erros a nível de página para uma página, seja adicionando um atributo ErrorPage na diretiva @Page da página, ou pela adição de um manipulador de eventos Page_Error ao código-behind da página. Vamos adicionar um manipulador de eventos Page_Error que irá transferir a execução para a página ErrorPage.aspx.

Abra o arquivo code-behind Default.aspx.vb e inclua o código para o evento Page_Error() conforme abaixo:

Private Sub Page_Error(sender As Object, e As EventArgs)
        ' pega o ultimo erro do servidor.
        Dim exc As Exception = Server.GetLastError()

        ' trata o erro
        If TypeOf exc Is InvalidOperationException Then
            ' Passa o erro para pagina de erro
            Server.Transfer("ErrorPage.aspx?handler=Page_Error%20-%20Default.aspx", True)
        End If
    End Sub

Quando ocorre um erro na página, o manipulador de eventos Page_Error é chamado. Nesse manipulador, a última exceção é recuperada e revisada. Se um erro do tipo InvalidOperationException ocorrer, o manipulador de eventos Page_Error transfere a execução para a página de erro onde os detalhes da exceção são exibidos.

Testando a aplicação

Execute a aplicação novamente pressionando CTRL+F5 (ou clicando no botão do menu que executa a aplicação). O navegador irá abrir e apresentar a página Default.aspx.

A página exibirá a mensagem de erro conforme abaixo:

Após essa bateria de testes, remova ou comente o código usado no evento Load da página Default.aspx para lançar deliberadamente um erro.

Usando ELMAH

ELMAH (módulos de registro de erros e manipuladores) é uma unidade de registro de erros que você conecta em sua aplicação ASP.NET como um pacote NuGet. A ELMAH oferece os seguintes recursos:

• Registro de exceções não tratadas;
• Uma página da Web para exibir todo o log de exceções não tratadas;
• Uma página da Web para exibir os detalhes de cada exceção logada;
• Uma notificação por e-mail de cada erro no momento em que ocorre;
• Um feed RSS dos últimos 15 erros do registro.

Antes de trabalhar com o ELMAH, temos que instalá-lo. Isto é fácil usando o instalador de pacotes NuGet.

Obs: O NuGet é uma extensão do Visual Studio que faz com que seja fácil de instalar e atualizar bibliotecas de código aberto e ferramentas no Visual Studio.

Com o projeto aberto no Visual Web Developer for Web, clique no menu TOOLS  e a seguir selecione Library Package Manager -> Manage Nuget Packages for Solution.

A janela - Manage Nuget Packages - será exibida. Selecione o item OnLine e digite na caixa de busca a palavra ELMAH. O pacote ELMAH deverá ser exibido no topo da lista de itens encontrados. Clique no botão Install para instalar o pacote ELMAH. A instalação apresentará uma tela solicitando a confirmação para instalar o pacote no projeto. Confirme clicando em OK.

Obs: Você deve estar conectado para poder baixar o pacote.

Se for solicitado, recarregar os arquivos abertos, selecione “Sim para Todos” (Yes to All).

O pacote ELMAH adiciona entradas na seção <modules> do nó <system.webServer> no arquivo Web.config. Se o sistema solicitar se você deseja recarregar o arquivo Web.config modificado, clique em Sim(Yes).

Com essa etapa concluída, estamos pronto para usar o pacote ELMAH.

Visualizando o log ELMAH

Ver o log ELMAH é fácil, mas primeiro vamos criar uma exceção não tratada que será gravada no log ELMAH.

Pressione CTRL + F5 para executar nossa aplicação. A seguir, digite a seguinte URL (usando o seu número de porta) no navegador para provocar uma exceção não tratada no log ELMAH: localhost:64786/NoPage.aspx.

A página de erro será exibida conforme abaixo:

Para visualizar o log de erros ELMAH digite a url no navegador: http://localhost:64786/elmah.axd

O log de erros ELMAH será exibido indicando informações sobre a ocorrência:

Se você clicar no link Details, irá obter os detalhes da exceção:

Atenção!!! Cuidado ao usar o recurso ELMAH, pois qualquer um pode ler o código de erro acessando a página, e existem exploits (um exploit é um programa de computador ou uma sequência de comandos que se aproveita das vulnerabilidades de um sistema) que exploram isso.

• Veja como hackear Elmah aqui.
• Para implementar seguro (não testei): http://haacked.com/archive/2007/07/24/securely-implement-elmah-for-plug-and-play-error-logging.aspx

***

Colaboração de Vitor Hugo.

Neste artigo aprendemos como manipular erros ao nível da aplicação, a nível da página, e do nível de código. Aprendemos também a registrar erros tratados e sem tratamento para posterior análise. Além disso, aprendemos  sobre a importância das mensagens de erro seguras.

E com isso encerramos essa série de tutoriais onde acompanhamos a criação de uma aplicação ASP .NET Web Forms usando o Visual Studio Express For Web 2012.

Embora a aplicação possa ser melhorada em muitos aspectos, o objetivo foi mostrar como podemos criar aplicações dinâmicas com acesso a dados usando recursos integrados do Visual Studio.

Espero que esses artigos tenham contribuído para aguçar o seu desejo em aprender mais sobre a tecnologia ASP .NET, pois o que vimos foi só a ponta do Iceberg.

Bom estudo!!!

O post ASP .NET 4.5 Web Forms – Tratamento de erros e registro de log – Parte 09 apareceu primeiro em .

Seguindo o mesmo padrão de layout aplicado no Razr D3, o Motorola Razr D1 é um smartphone compacto, com preço competitivo e bons recursos. Equipado com TV digital, dois cartões SIM e processador de 1 GHz, o gadget roda o Android 4.1.2 sem muitos engasgos e com desempenho acima da média para a categoria.

Custando 529 reais, o D1 é uma opção mais econômica para quem precisa gerenciar duas linhas e não abre mão de maior velocidade nas tarefas básicas. O processador ARMv7 com um núcleo de 1 GHz, somado à memória RAM de 1 GB, garantiu em nossos testes uma boa experiência de uso. O smartphone rodou os principais aplicativos, como Facebook, Instagram e games sem grandes problemas. Há lentidão em alguns pontos, como na gestão do app de TV digital e com muitos aplicativos abertos simultaneamente, mas nada acima do normal para um smartphone de entrada.

Benchmark Quadrant (em pontos)
Barras maiores indicam melhor desempenho

Benchmark AnTuTu (em pontos)
Barras maiores indicam melhor desempenho

Ao contrário de outros modelos com TV digital, o D1 não possui uma antena retrátil. A sintonia dos canais é feita quando os fones de ouvido estão conectados. Dessa forma, assim como para a sintonia de rádio, o cabo dos fones assume o papel da antena. Na prática isso resulta em uma redução na força de sinal. Em nossos testes, isso não significou perda em qualidade ou recepção de menos canais, mas houve demora na sintonia. O aplicativo de TV exibe guia de programação, grava trechos dos programas direto no cartão microSD e salva capturas de tela. O layout é muito similar ao do Atrix TV Dual, também da Motorola.

Com 3,5 polegadas, a tela do D1 oferece 480 por 320 pixels. O brilho intenso e a fidelidade nas cores compensam a resolução baixa. É possível reparar serrilhados em menus e ícones do sistema. O resultado com vídeos também não é dos melhores. Por outro lado, há precisão nos toques e, no geral, a interface da Motorola, que se aproxima do Android em sua versão pura, causa boa impressão.

Com 5 megapixels, a câmera do Razr D1 faz fotos medianas em boas condições de luz. Durante a noite ou em ambientes pouco iluminados, o excesso de ruído e a falta de flash LED tornam o registro de imagens inviável. Os vídeos são gravados em 480p a 30 quadros por segundo.

Fonte: http://info.abril.com.br/reviews/smartphones/motorola-razr-d1.shtml

O post Aparelho gerencia dois cartões SIM e sintoniza TV Digital no Android 4.1.2 apareceu primeiro em .

Se antes o consumidor que tinha um problema com um produto dependia de um grande veículo de comunicação, agora basta estar conectado à internet para ele possa fazer barulho nas redes sociais. Este é o Prosumer.

Mas as empresas mal se acostumaram a este novo cenário e vem aí a evolução disso tudo que é o Supersumer. É um consumidor bem diferente do que vemos hoje. Ele está conectado 24 horas por dia e quer atendimento a qualquer hora e em qualquer lugar.

É o consumidor que usará Google Glass e outros gadgets que nem conhecemos ainda. Quase um consumidor cibernético que poderá transmitir falhas ou reclamações em tempo real e sua rede de contatos irá reverberar este problema até em alguns casos causar dores fortes de cabeça nos gestores.

Mas como podemos nos preparar para estes novos cenários que virão? Pode parecer clichê mas não vamos resolver novos problemas com soluções antigas. É preciso que os SACs se renovem urgentemente. Sistemas de informação de marketing, BI – Business Inteligence e SAC totalmente integrados farão toda a diferença.

E para um superconsumidor vamos precisar de um SuperSAC que use referenciamento geográfico, dispositivos móveis e vídeo-chamadas. Dei uma palestra recentemente sobre o tema:

E se você acha tudo isso muito utopia dê uma olhada no vídeo abaixo:

O vídeo está em inglês mas basicamente uma consumidora recebe a câmera quebrada, entra em contato com o SAC que já identifica o defeito e fala que irá trocar o produto, porém como a cliente precisa do produto o quanto antes a equipe localiza uma loja que tem a câmera nas imediações da casa da cliente. Pode parecer tudo muito utópico para a realidade brasileira, mas sinto que precisamos pelo menos discutir estas novas relações você não acha?

O post Você conhece o Supersumer? apareceu primeiro em .

Entretanto, muita gente ainda vê o Business Intelligence como algo distante, que só serve para as grandes empresas. Mas essa é uma visão equivocada. Na verdade o BI é uma ferramenta que pode ser adaptada para o tamanho de qualquer empresa.

Uma pesquisa realizada pela ComputerWorld Brasil, em 2010, mostrou que na América Latina foram investidos cerca de us$ 504 milhões em BI, sendo que metade dessa quantia veio para o Brasil. Segundo a consultoria IDC, em pesquisa do mesmo ano, as pequenas e médias empresas já estavam optando por essa solução, mas utilizando versões mais simples. Ou seja, pode-se afirmar que implementação do BI nesSas empresas é apontada como responsável por diversos resultados positivos, entre eles: redução de custos, melhoria de processos e aumento da retenção de clientes.

Mas se ainda assim você não está convencido, proponho que imagine a seguinte situação: uma rede de três mercadinhos que precisa saber quais são os produtos mais vendidos no começo do mês (momento de mais compra pelos consumidores em virtude do recebimento do salário). Essa informação é muito importante e interfere automaticamente no departamento de compras, logística, estoque e até na exposição dos produtos na loja, e o gestor precisa tomar uma decisão rapidamente para atender bem e não ficar sem produtos ou ficar com muitos produtos que não vendem em estoque. E é aí que entra o BI para resolver isso tudo.

Um sistema de Business Intelligence ajuda na tomada de decisão, e as possibilidades são muito maiores do que acabei de citar. Com as métricas e os KPIs corretos, é possível enxergar e entender melhor o cenário de atuação de qualquer empresa, seja grande ou pequena, e como agir de maneira correta e assertiva.

Uma pequena fábrica de sapatos, por exemplo, precisa saber quais são os clientes que mais compram sapatos masculinos bico fino na região Sudeste? Quais os modelos mais vendidos de sandálias para o Nordeste e quanto isso representa das vendas totais da empresa? As respostas dessas perguntas influenciam na elaboração da próxima coleção e, se a empresa não tem isso nas mãos, fica muito complicado decidir e garantir sucesso.

Podem ser perguntas simples, mas difíceis de serem respondidas em um primeiro momento. EsSas informações, no entanto, podem gerar insights valiosíssimos para a sua pequena empresa, capazes de gerar uma economia de tempo e custos. E ainda pode e deve influenciar na estratégia de vendas dos seus produtos ou serviços.

E isso tudo já pode ser acessado pelo tablet ou smartphone do dono da empresa. Com uma ferramenta de BI móvel, é possível acessar, analisar e cruzar dados estando em qualquer lugar.

Enfim, as possibilidades de utilização do Business Intelligence são inúmeras. Será que não é isso o que está faltando para a sua pequena ou média empresa crescer cada vez mais?

O post Business Intelligence para pequenas empresas apareceu primeiro em .

Hoje o Israel atua em uma agência em São Paulo que atende contas de grandes marcas do varejo online. O Israel participou do 15×2 falando sobre um tema muito importante e delicado para empresas de todos os portes: gestão de crises nas mídias sociais.

O que é na verdade o 15×2?

O 15×2 é o meu mais novo projeto de conteúdo. Meu objetivo com ele é trazer o que há de mais relevante em vários campos de forma objetiva e rápida: em 15 minutos.  Irei conversar com pessoas de vários segmentos e, a partir de algumas perguntas, apresentar para você o que há de mais relevante em cada área. Tudo em 15 minutos. Isso mesmo, pá-pum!

O nome 15×2 surgiu justamente pelo formato do videocast: 15 minutos, um tema e duas pessoas. As pessoas serão eu, Camila Porto, e meus convidados a conversar sobre várias coisas. As conversas serão em vídeo, podem ser gravadas ou transmitidas ao vivo pelo YouTube. Espero que você goste e que o conteúdo visto aqui, seja um grande impulsionador para que você busque mais conhecimento.

Vamos ao que interessa?

A seguir você encontra o 15×2 Episódio 1: Gestão de crises nas mídias sociais com o Israel Degásperi

Links comentados no 15×2

• Martha Gabriel: Gestão de Crises em Mídias Sociais;
• Marcelo Vitorino: Presença Online;
• Gratidão – Vaynerchuk, Gary;
• Marketing de Relacionamento Total – Evert Gummesson

Até mais!

O post 15×2 – Gestão de crises com Israel Degásperi apareceu primeiro em .

Outras equipes vivem por seus sistemas de rastreamento de bugs, usando ferramentas como Jira, Bugzilla ou FogBugz para registrar erros, bem como alterações e outros trabalhos. Há argumentos a serem feitos para ambas as abordagens.

Argumentos para rastreamento de bugs – e para não rastrear bugs

Em Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin e Janet Gregory examinam os prós e os contras do uso de um sistema de rastreamento de falhas.

Usar um sistema para rastrear bugs pode ser a única forma eficaz de gerir os problemas de equipes que não podem se encontrar face a face – por exemplo, equipes distribuídas e espalhadas por diversos fusos horários. Também pode ser útil para equipes que herdaram bugs abertos em um sistema legado; e um mal necessário para as equipes que são forcadas a acompanhar bugs, por razões de compliance. As informações em um banco de dados de bugs é uma base de conhecimento potencial para testadores e desenvolvedores novos na equipe – eles podem rever os erros que foram encontrados antes na área do código em que eles estão trabalhando para compreender os problemas com os quais têm que lidar. E os dados de bugs podem ser usados para coletar métricas e criar tendências sobre erros – se você acha que as métricas de erros são úteis.

Mas a visão Lean/Agile é que o uso de um sistema de rastreamento de falhas em sua maioria atrapalha e atrasa as pessoas. A equipe deve manter o foco na busca por erros, corrigi-los, e depois esquecê-los. Os erros são os resíduos, e tudo sobre ele é desperdício – informações mortas, e o tempo morto que seria melhor usado para entregar valor. Pior, usar um sistema de rastreamento de falhas impede testadores e desenvolvedores de falar uns com os outros e incentiva os testadores a terem uma “Política de Qualidade” mental. Sem uma ferramenta, as pessoas têm de falar umas com as outras, e têm que aprender a andar bem juntos.

Esse é um ponto de vista tático, a curto prazo, com foco no que é necessário para obter o software correto e funcionando. É um pensamento no projeto, e não no produto.

Bugs a longo prazo

Mas se você está trabalhando em um sistema por um longo tempo, como nós, se você está administrando um produto ou executando um serviço, você sabe que não é assim tão simples. Você não pode apenas olhar para o que está diante diante de você, e onde você quer estar em um ano ou mais. Você também tem que olhar para trás, para o trabalho que foi feito antes, os problemas que aconteceram antes, as decisões que foram tomadas antes, para entender por que você está onde está hoje e para onde você pode ir no futuro.

Devido a alguns problemas que nunca vão embora. E outros problemas que voltarão, a não ser que você faça alguma para impedi-los. E você vai descobrir que outros problemas que você pensou que havia liquidado nunca foram embora realmente. As informações de bugs antigos, o que aconteceu e o que foi feito para corrigi-los (ou por que não puderam ser corrigidos), que soluções alternativas trabalhadas (ou não) podem ajudá-lo a continuar a melhorar o sistema e como você pode construí-lo e mantê-lo funcionando.

Porque você deve entender o histórico de alterações e correções no código se você for modificá-lo. Se você gosta da forma como o código está hoje, você pode querer saber como e por que ele ficou assim. Se você não gostar, você vai querer saber como e por que ficou dessa forma – é arrogante supor que você não vai cometer os mesmos erros ou ser forçado para os mesmos tipos de situações. Controle de revisão irá dizer-lhe o que foi alterado, quando e quem fez isso, o sistema de reastreamento de bugs vai dizer por quê.

Porque você precisa saber onde você tem instabilidade e risco no sistema. Você precisa identificar um código propenso a bugs – código que contem muitos erros, o código que lhe irá custar muito para manter e causará muitos problemas, o código que é muito caro para manter funcionando da maneira como está hoje. O código que você deve rescrever o mais rápido possível para melhorar a estabilidade e reduzir seus custos . Mas você não consegue identificar esse código sem saber o histórico de problemas no sistema.

Porque você pode precisar provar aos auditores, reguladores, clientes e investidores que está fazendo um trabalho responsável de testar e encontrar os erros, corrigi-los e acabar com as correções.

E porque você quer saber o quão eficaz a equipe é em encontrar, corrigir e prevenir erros. Você está vendo menos bugs hoje? Ou mais bugs? Você está vendo os mesmos tipos de erros – você está cometendo os mesmo erros? Ou erros diferentes?

Você precisa controlar todos os bugs?

Enquanto os bugs são encontrados cedo o suficiente, há pouco valor em monitorá-los. É quando os erros escapam que eles precisam ser monitorados: erros que o desenvolvedor não encontra de imediato por conta própria, ou em emparelhamento, ou através do controles automáticos padrão e os testes que são executados em Integração Continua.

Não fazemos log de

• defeitos encontrados em testes unitários ou outros testes automatizados – a menos que, por algum motivo, o problema não possa ser corrigido imediatamente;
• problemas encontrados em avaliações pelos pares – a menos que algo na revisão seja considerado significativo e não possa ser abordado imediatamente. Ou um problema é encontrado em uma revisão final, após os testes começarem, e o código terá que ser testado novamente. Ou o revisor encontra algo errado no código que não foi alterado, um bug antigo – ainda é um problema que precisa ser olhado, mas ele pode estar preparado para lidar com ele agora. Todos os problemas encontrados nas revisões externas, como uma revisão de segurança ou uma auditoria, são registrados;
• resultados de analise estática – a maioria dos problemas capturados por essas ferramentas são simples erros de codificação que podem ser vistos e corrigidos imediatamente, e também costuma haver uma boa quantidade de ruídos (falsos positivos) que deve ser filtrada. Nós executamos verificações de análise estática e as revisamos diariamente, e registramos apenas os resultados se concordamos que a descoberta é real, mas o desenvolvedor não está preparado para corrigi-lo imediatamente (o que quase nunca acontece, a menos que estejamos executando uma nova ferramenta contra uma base de dados já existente pela primeira vez). De qualquer forma, muitas ferramentas de análise estática têm seus próprios sistemas para rastrear resultados de análise estática, por isso sempre podemos voltar e rever questões pendentes depois;
• erros encontrados quando os desenvolvedores e testadores decidem se juntar para testar mudanças no início do desenvolvimento, principalmente quando estão explorando como algo deveria funcionar – não costumamos registrar erres erros, a menos que não possam ser/não serão corrigidos (podem ser reproduzidos mais tarde, por exemplo)

Bug é algo terrível de se desperdiçar

Nós registramos todos os outros erros, independentemente de eles serem encontrados em produção, em testes internos, testes de parceiros, testes de aceitação do usuário, ou teste externo (como um pen test). Porque na maioria das vezes, quando o software é entregue a um testador, ele deveria estar funcionando. Se o testador encontra bugs, especialmente sérios, então essa é uma informação importante para o testador, para o desenvolvedor, e para o resto da equipe. Ele destacar os riscos. Ele pode mostrar onde são necessários mais testes e opiniões. Ele pode destacar problemas mais profundos no projeto, a falta de compreensão que poderia causar outros problemas.

Se você acredita que o teste fornece informações importantes não apenas sobre o estado do seu software, mas também sobre como você o está projetando e construindo – então todo mundo precisa ser capaz de ver essa informação, e compreendê-la ao longo do tempo. Alguns problemas podem não ser vistos ou compreendidos de imediato, ou no tempo de 1 ou 2 semanas. Pode demorar um pouco antes de você reconhecer que tem uma grave deficiência no projeto ou que algo está quebrado em sua abordagem de desenvolvimento ou em sua cultura. Você precisa experimentar alguns problemas antes de começar a encontrar relações entre eles e antes que você possa olhar para a raiz de seu problema. Você vai precisar de dados do passado, afim de resolver os problemas no futuro.

Rastrear bugs não é um desperdício se você aprender com os bugs. Jogar fora as informações sobre bugs é o verdadeiro desperdício.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em   http://swreflections.blogspot.com.br/2013/02/a-bug-is-terrible-thing-to-waste.html

O post Bug é algo terrível para se desperdiçar apareceu primeiro em .

Durante a conferência CHI 2013, a principal conferência acadêmica que envolve interação com computadores realizada em Paris, havia um estande de uma empresa que estava demonstrando este produto. Não era exatamente a produtora do Oculus, mas consegui experimentar o mundo virtual que eles estavam demonstrando.

A primeira impressão não foi das melhores. Tive um pouco de dificuldade para colocar o Oculus, pois apesar das duas tiras laterais ajudarem a fixar o aparelho, a tira que vai sobre a cabeça é a mais complicada de se colocar. Acredito que esta tira possa dificultar a colocação do aparelho em algumas pessoas, especialmente aquelas que não querem tirar o boné ou o chapéu. Contudo, me pareceu que o uso desta terceira tira é para evitar um peso considerável na cara do usuário, que acabaria forçando o pescoço, e não para ajudar o correto posicionamento do aparelho.

Além disso, fiz questão de experimentar este HMD sem tirar meus óculos de grau. Não tenho um caso muito grave de miopia e por isso quis experimentar a resolução do dispositivo sem nenhum tipo de obstáculo visual. Após alguns ajustes e com ajuda do pessoal do stand que demonstrava o mundo virtual, consegui colocaro dispositivo como mostra a figura abaixo:

Outro detalhe que notei e que pode ser percebido na imagem acima é que a tira lateral encobre parte da orelha. Esta configuração é necessária, pois como pode ser visto a tira não é fina. Deste modo é provável que o usuário sinta algum desconforto após o uso prologando do Oculus, especialmente se ele for utilizado em conjunto com fones de ouvido do tipo headset que tentam isolar o máximo de ruído externo pela pequena pressão que almofadas do headset fazem na cabeça.

O peso do aparelho não foi algo que me incomodou, porém destaco que isso é devido à tira que vai sobre a cabeça. Novamente, é provável que alguns usuários possam sentir o pescoço cansado depois do uso prolongado.

Logo que comecei a visualizar as imagens, alguém me auxiliou para segurar um controle que seria utilizado para a navegação no mundo virtual. Como o HMD é apenas um display, é necessário empregar algum tipo de controle de alta precisão para a interação com o modo como o conteúdo que está sendo exibido. O expositor escolheu o Razer Hydra, que é um controle de movimento com muita precisão voltado para o mercado de PCs. Como este controle é muito preciso e de ótima qualidade, muitos profissionais que estão avaliando e montando produtos com o Oculus estão empregando de forma quase unânime o Razer Hydra.

A resolução do Oculus não é a das melhores – algo que foi confirmado pela equipe que está trabalhando com ele. Por se tratar de um produto enviado para desenvolvedores, ele ainda vai sofrer algumas modificações antes de chegar ao consumidor final; incluindo melhorias na resolução. De qualquer maneira, mesmo com o as lentes adequadas (sim, é possível escolher entre alguns pares de lentes de acordo com caraterísticas do usuário) pude notar que dentro dele é possível observar o vão entre os buracos que contém as lentes responsáveis por mostrar o conteúdo. Isso não me incomodou, mas serve como um lembrete que a experiência de visão não é totalmente imersiva e é diferente de uma tela contínua. Um dos motivos para se utilizar duas lentes é a possibilidade de projetar conteúdo diferente nelas e fornecer a sensação de paralax e possivelmente aplicações esteroscópicas.

Do ponto de vista de desenvolvimento, ainda é preciso que o fabricante forneça recursos para que os designers e programadores possam utilizar o dispositivo de modo que ele forneça algo além da visão que uma televisão pode proporcionar em aplicações novas e já existentes. Por exemplo, o Oculus capta razoavelmente bem movimentos de cabeça e adapta o seu conteúdo a ele. Em um jogo pode ser que o personagem esteja com as mãos amarradas e com uma mordaça na boca. Neste cenário o personagem precisa dar ‘cabeçadas’ em uma estante para cair uma faca que ele pegue com o pé para conseguir escapar. Neste exemplo, a movimentação da cabeça pode ser uma técnica de gameplay que, se utilizada de forma correta, pode tornar mais interessante as interações proporcionadas no jogo.

Ainda falando sobre a movimentação da cabeça do usuário, quando mexi minha cabeça de um lado para o outro notei uma nítida falta de resolução. Algo que também havia percebido quando assisti no cinema o filme O Hobbit em uma sala onde a projeção que não foi em 48 quadros por segundo, quando muita coisa acontecia ao mesmo tempo. Neste caso, fica claro o evento de motion blur que acontece, ou seja, a tela fica embaçada quando se movimenta a câmera. Este tipo de efeito pode ser suavizado e tratado de forma melhor uma vez que existem sensores que captam o movimento da cabeça do usuário no Oculus.

Também notei o fato que o Oculus utiliza um fio ligado a uma pequena caixa contendo conectores HDMI e USB. Bem, com novas tecnologias de transmissão e compressão de dados é possível imaginar que futuras versões possam ser utilizadas sem fio, mas acredito que isso ainda vai demorar um pouco. Em geral, o aparelho é interessante, mas cabe principalmente aos desenvolvedores trabalhar corretamente o conteúdo para que a experiência do usuário seja superior a, por exemplo, o uso de uma televisão com resolução 4k.

Para finalizar, destaco o vídeo clip da música Amazing, da banca Aerosmith (uma das minhas preferidas e que está sempre ligada em tecnologia) que mostra como era a perspectiva de realidade virtual nos início dos anos noventa. Não sei quanto a vocês, mas para mim as aplicações de realidade virtual, realidade aumentada e realidade mista que temos hoje estão caminhando para uma direção um pouco diferente desta visão apresentada neste clip.

O post Testando o Oculus Rift apareceu primeiro em .

Dicas para publicar conteúdo atraente:

• Mostre aos usuários por trás das cenas, os bastidores de como funciona um e-commerce, por exemplo;
• Apresente aos seus seguidores o que você está trabalhando ou o que te inspira, suas referências;
• Informar seguidores sobre a história da marca.

Instagram API

Utilize a API para acessar o seu próprio conteúdo e/ou conteúdo gerado pelo usuário com base no nome de usuário, hashtag ou localização. Os usuários estão postando milhões de fotos no Instagram a cada dia. Aproveite para utilizar a API e ver onde e como os usuários estão falando sobre sua marca.

Dicas de como usar a API:

• Criar uma galeria de fotos relacionadas com a sua marca, produto ou causa;
• Mostrar fotos em tempo real durante os eventos ao vivo;
• Imprimir fotos para usar em telas ou para presentear aos usuários em eventos;
• Criar um mapa digital de suas próprias fotos ou de onde os usuários estão marcados em sua marca;
• Incentive que os usuários enviem fotos para concursos ou campanhas.

Comunidade e pessoas no Instagram

A comunidade no Instagram é extremamente ativa. Encontre maneiras de se conectar com seus seguidores e oportunidades para se envolver com eles para falar sobre a sua marca.

Dicas de como se envolver com a comunidade:

• Organizar um InstaWalk ao redor da cidade ou nos bastidores de um evento;
• Promover um Instagram MeetUp;
• Criar desafios hashtag semanais.

Melhores práticas

Mudança de perspectiva

Cadastre-se em uma conta pessoal, bem assim você pode experimentar as experiências de um usuário. Você vai descobrir como você deseja consumir conteúdo, como você interage com outros usuários e que tipo de imagens que você encontra são interessantes.

Experiência

Cada marca tem um público diferente e quer envolve-lo de diferentes formas. Experiência com tipos de fotos para compartilhar e quantas fotos são publicadas por dia ou semana. Ouça o feedback de seus usuários para ajustar as ações. É preciso saber quem é seu público e entender o que ele gosta para começar a usar uma nova plataforma.

Compartilhe conteúdo atraente

Publicar fotos que os usuários não possam ver em outro lugar – por trás das cenas ou fotos sneak peeks do que está por vir. Não tenha medo de experimentar, e prestar atenção no que os usuários gostam e comentar mais.

Conte sua história

As fotos que você postar podem contar uma história sobre a sua marca. Os usuários podem dizer o que acham quando você posta uma foto. Ser autêntico sobre o conteúdo que você compartilha irá ajudá-lo a construir conexões genuínas com seus seguidores.

Expandir o seu público

Conectando sua conta do Instagram para suas outras redes sociais é uma ótima maneira de deixar seus seguidores sabendo que você se juntou ao Instagram, e isso ajudará a fazer crescer o seu público-alvo. Também torna mais fácil compartilhar o conteúdo que você postar no Instagram para suas outras contas a fim de aumentar seu alcance e exposição.

Publicar constantemente

Os usuários geralmente gostam de ver uma variedade de fotos a partir de diferentes contas em seu feed. Publicar muitas vezes o suficiente para manter usuários envolvidos, mas mantê-los querendo mais. Espalhe suas mensagens ao longo do dia ou ao longo de vários dias.

Envolver-se com a comunidade

Interagir com a comunidade Instagram, tanto no aplicativo quanto em pessoa. Faça perguntas em sua legenda e responda aos comentários. Promover eventos locais Grupos Meetup . Incentivar os usuários a usarem hashtags nas fotos em seus eventos, é muito importante.

Algumas dicas e recursos para começar a usar o Instagram para sua marca ou empresa.

1. Central de Ajuda Negócios O Centro de Ajuda fornece recursos e respostas às perguntas mais frequentes;
2. Blog Empresas O blog destaca grandes contas da marca, o envolvimento da comunidade, exemplos exclusivos API e dicas gerais de como gerenciar uma conta da marca;
3. API para desenvolvedor.

O post Instagram para vendas e negócios apareceu primeiro em .

O Sandbox do PayPal é um ambiente onde podemos testar os recursos do PayPal e integrar aplicações com as APIs. O Sandbox é praticamente um clone do ambiente de produção e seu objetivo é oferecer um ambiente para testar os recursos e integrações para se evitar problemas que poderiam existir se os testes fossem feitos no ambiente de produção.

O ambiente Sandbox é, de fato, uma das ferramentas mais importantes durante o processo de integração. Nesse artigo, usaremos como base todo o conteúdo descrito no artigo anterior, porém, para o público brasileiro.

Diferenças entre os dois ambientes do PayPal Sandbox

O Sandbox do PayPal é composto por dois ambientes distintos:

PayPal Developer

O ambiente PayPal Developer é onde o desenvolvedor pode gerenciar as contas de teste, verificar os emails enviados pelo PayPal para seus clientes, testar as notificações de pagamento e, até, criar novas contas de teste.

PayPal Sandbox

O ambiente PayPal Sandbox é o equivalente ao ambiente de produção. Toda a interface e usabilidade do PayPal Sandbox foi desenvolvida para oferecer a mesma experiência e funcionalidade do ambiente de produção, facilitando assim o processo de teste.

Características do ambiente Sandbox

Abaixo algumas características específicas do ambiente PayPal Sandbox, ao compará-lo com o ambiente de produção

• Sandbox é um ambiente de teste, desenvolvido para que o desenvolvedor possa verificar a integração, antes de colocá-la em produção.
• Dentro do Sandbox é possível criar quantas contas forem necessárias, sejam elas com perfil de indivíduos ou de empresas.
• Os valores das transações são fictícios. Nenhum saldo ou débito acontecerá de fato. Todas as transações são apenas para fins de teste e, como tal, são meramente demonstrativos.
• Todos os dados utilizados nas contas criadas no Sandbox podem ser fictícios. Não é necessário informar documentos válidos ou números de cartão de crédito existentes.
• As contas criadas no PayPal Developer existem apenas no ambiente Sandbox.

Utilizando o PayPal Sandbox

O primeiro passo para utilizar o PayPal Sandbox, é ter uma conta PayPal. Para isso, o desenvolvedor deverá ir até a página principal a página principal da PayPal e criar uma conta ou, se já possuir uma conta PayPal, ir até PayPal Developer e fazer login utilizando sua conta PayPal.

Assim que o desenvolvedor abrir a página do PayPal Developer, a seguinte interface será exibida:

No topo, do lado direito, o desenvolvedor verá o botão Log in with PayPal. Ao clicar nesse botão, uma janela solicitando o email e senha da conta PayPal será exibida e, ao informar as credenciais, a tela do PayPal Developer será atualizada com o nome do desenvolvedor:

Assim que estiver logado, o desenvolvedor já poderá utilizar todas as ferramentas oferecidas pelo PayPal Developer e também pelo PayPal Sandbox.

Criando contas de teste

Uma das tarefas mais comuns dentro do PayPal Developer, é a criação de contas de teste. Essas contas são importantes para a integração pois, somente através delas, o desenvolvedor conseguirá testar sua integração, seja com uma conta de vendedor, ou com uma conta de cliente.

Para se criar uma conta de teste, o desenvolvedor deverá seguir os passos abaixo:

• Clicar em Applications no menu principal do PayPal Developer:

• Clicar em Sandbox accounts no menu lateral do PayPal Developer:

• Clicar no botão Create Account na tela Sandbox test accounts:

• Preencher o formulário de criação de conta com dados fictícios:

Assim que o formulário tiver sido preenchido e o desenvolvedor tiver clicado no botão Create account, a nova conta de teste será listada na página Sandbox accounts:

A partir desse momento, o desenvolvedor conseguirá fazer login no PayPal Sandbox utilizando a conta recém criada. Para isso, o desenvolvedor pode clicar sobre a nova conta e, então, clicar no linkSandbox Site ou acessar https://sandbox.paypal.com e fazer login utilizando o e-mail e a senha cadastrada no formulário de criação de conta:

Gerando as credenciais da API

Após fazer login em https://sandbox.paypal.com com a conta de teste, o desenvolvedor perceberá que o ambiente é idêntico ao de produção. Assim, da mesma forma que gerenciamos as contas no ambiente de produção, podemos fazê-lo no ambiente Sandbox

Para utilizar uma conta para testar uma integração, o desenvolvedor precisará gerar as credenciais da API. Para isso, os seguintes passos deverão ser seguidos:

• Fazer login https://sandbox.paypal.com utilizando uma conta de teste:

• No menu principal, clicar em Profile:

• Na tela de ferramentas de venda, clicar em Request API credentials, no grupo Account Information:

• Na nova tela, escolha a opção 2 da opção 1:

• Na nova tela, clique em View API Signature da opção 2:

• Copie os dados exibidos na última tela:

Após criada as credenciais da API, elas também estarão disponíveis através do PayPal Developer. Para visualizá-la, basta clicar sobre a conta de vendedor e, então, no link profile:

Ao clicar em profile, uma janela popup será exibida com dados da conta e as credenciais da API:

PayPal Sandbox para o público brasileiro e outras localizações

Na seção anterior vimos como podemos criar contas para diversos países apenas clicando no botão Create account. Porém, diversos países não estão listados entre as opções de criação de conta ao utilizar o processo anterior, como é o caso do Brasil.

Apesar de não estar listado, o desenvolvedor conseguirá criar contas de teste para qualquer uma das localizações abaixo:

• Australia
• Austria
• Belgium
• Brazil
• Canada
• China
• Denmark
• France
• Germany
• Hong Kong
• Israel
• Italy
• Japan
• Mexico
• Netherlands
• Norway
• Poland
• Russia
• Singapore
• Spain
• Sweden
• Switzerland
• Turkey
• United Kingdom
• United States

Criando contas de teste

Tudo o que o desenvolvedor precisa fazer para criar uma conta de teste para qualquer um dos países acima, é seguir os passos abaixo:

• Acessar https://sandbox.paypal.com e clicar no botão Criar conta:

• Na nova tela, selecione Brasil em Seus país ou região e escolha entre Para você para criar contas de clientes, ou Para sua empresa para criar contas de vendedores:

• Após selecionar o país, uma tela com um formulário de cadastro será exibida. Lembre-se de preencher o formulário com dados fictícios.

• Após preencher o formulário, clique no botão Continuar

Assim que a conta brasileira tiver sido criada, siga os passos descritos na seção ‘Gerando as credenciais da API’ para gerar as credencias da API.

O post Utilizando o novo PayPal Sandbox apareceu primeiro em .