Bytes Every Day

A explosão do mobile no mundo e, mais especificamente no Brasil, é algo assustador. O infográfico abaixo mostra como esta tendencia vem  forte e promete continuar. Não tem mais jeito! É obrigatório pensar em mobile em qualquer projeto, seja este novo ou já implantado. Talvez mais do que pensar no usuário ou analisar tendências a urgência em adotar o desenvolvimento para mobile veio com força total após o anúncio da Google em Abril de 2015 de que os sites com suporte para mobile ganhariam destaque nas buscas. Porém, além da decisão de adotá-lo, temos de encarar o fato de que o mundo mobile tem inúmeros desafios mesmo para aqueles que já trabalham com Web para desktop (apesar da Internet na verdade ser única, seja no celular, tablet, notebook ou desktop). AS DIFICULDADES Se você é do tempo em que o padrão era o IE6 sabe como era terrível trabalhar com um navegador que não seguia os padrões w3c, aliás, um navegador que adotava os padrões que queria e dane-se o resto.

'Mobile First Design with HTML5 and CSS3' é um livro da editora 'Packt Publishing' para quem quer um passo a passo a partir do zero na criação de seu primeiro projeto de website responsivo (RWD). Para tal missão o autor utiliza o framework '320 and Up' como base. O conceito por trás do Mobile First ou 'Mobile Antes' é pensar em seu projeto levando em consideração inicialmente a experiência do usuário em um smartphone. A experiência em desktops ou telas grandes será sempre uma adaptação do primeiro caso. Esta lógica inverte a anterior, quando o Mobile era considerado uma novidade e estava engatinhando. Esta linha de pensamento para desenvolvimento deve ser seguida não em todos os casos mas naqueles em que você sabe antecipadamente que a maior parte dos usuários acessarão via smartphone. Outro motivo que pode levar um projeto a seguir o 'Mobile First' é a tendência de que no futuro os acessos via smartphones serão a esmagadora maioria, f

Existe uma linha de pensamento na comunidade de desenvolvedores que recomenda que para dar maior segurança a um sistema, e assim evitar ataques, deve-se fornecer a menor quantidade possível de informações sobre o mesmo. Pegando esta ideia como padrão para nossos projetos uma das coisas que podem dar informação valiosa para crackers são as mensagens de erro na execução do sistema.  Mensagens de erro deveriam ser vistas apenas pelos desenvolvedores, não pelos usuários Tais mensagens podem informar, por exemplo, caminhos de arquivos e estrutura de diretórios desprotegidos, senhas de acesso a banco de dados e versões de software que podem ser utilizadas como base para busca de brechas de segurança. Assim não exibir tais erros é fundamental para manter o sistema o mais protegido possível, além de dar uma cara mais profissional ao projeto, afinal é bem feio seu usuário final ver uma mensagem dizendo que o sistema apresentou erro. Porém devemos lembrar também que para os desenvo