Tendencia e Curiosidades

0

IMG_5334Na manhã desta última segunda-feira, dia 17/08/2015, aconteceu a abertura oficial do XIV Simpósio Brasileiro de Qualidade de Software (SBQS 2015), realizado no Studio 5 Centro de Convenções, em Manaus, Amazonas e nós da IntSoft Consultoria estamos presentes e atentos as novidades tecnológicas. O evento é promovido anualmente pela Sociedade Brasileira de Computação (SBC) e pelo Programa Brasileiro de Qualidade e Produtividade em Software (PBQP-SW) e realizado pela Universidade Federal do Amazonas – UFAM.

O evento favorece o intercâmbio de informações e tem como objetivo reunir pesquisadores, profissionais, empresários, professores e estudantes de diversas áreas para discutir sobre o estado atual, tendências, métodos, técnicas, ferramentas de software, evidências e experiências práticas da área de qualidade de software.

O SBQS tornou-se um fórum em que a comunidade científica e a indústria na área de software se encontram para compartilhar experiências, discutir problemas e soluções da área de qualidade de software e estabelecer novas parcerias.

O evento será composto de palestras técnicas da academia e de relatos de experiência da indústria, além de minicursos e da presença de palestrantes convidados, de reconhecido destaque na área de qualidade de software.

A programação do SBQS 2015 conta com:

v13_programacaoDetalhada

Por: Elderson Jammer

0

googleplus001O Material Design Lite (MDL) do Google permite adicionar o look and feel do Material Designem websites. O Material Design é a linguagem visual padrão para Android e que, agora, o Google propõe como multiplataforma.

De acordo com o Google, o MDL têm os requisitos para que seja caracterizado como “lite”:

  • Tem poucas dependências de forma que é fácil de instalar e usar;
  • Não depende de frameworks, permitindo que os desenvolvedores façam sua integração com qualquer cadeia disponível de ferramentas para front-end;
  • Sua base de código é relativamente pequena;
  • Têm foco restrito, implementando as boas práticas do material design e não é um framework abrangente.

O MDL não é a primeira implementação de HTML/CSS/JS do material design e existem alternativas como o Materialize e Material Bootstrap. A principal vantagem que o MDL trás em relação a estas opções desenvolvidas pela comunidade, de acordo com o Google, é que o MDL foi desenvolvido “com a colaboração das equipes de Material Design e Chrome UX e é constantemente revisado buscando aderência às especificações do material design”.

Antes do MDL, o Polymer era a implementação canônica de material design para CSS/JS. Porém, comparado ao MDL, o Polymer tem escopo maior e vai além do domínio visual, incluindo componentes para comunicação de dados e componentes não especificados pelo material design.

Até o presente momento, o MDL não é otimizado nem suporta o uso de componentes individuais, por exemplo, um botão. Ainda sim, para desenvolvedores que querem usar apenas uma parte dos componentes MDL, é possível criar uma distribuição MDL customizada comentando componentes indesejados do material-design-lite.css e scripts inadequados do Gulpfile. Feito isso, basta executar gulp.

O MDL segue a convenção BEM de forma que os nomes para cada classe css são consistentes, isolados e expressivos. O Google detalha quais boas práticas eles seguiram ao aplicar BEM no desenvolvimento do MDL. Por outro lado, o BEM pode levar a explosão no comprimento dos nomes de classes e, de acordo com o feedback inicial, o MDL parece ser sensível a esse problema, por exemplo, ao necessitar de dezessete nomes de classe diferente para um simples card que é um conceito básico do material design.

O Google afirma que o MDL funciona em todos os navegadores modernos (Chrome, Firefox, Opera, Microsoft Edge e Safari) com degradação suave em navegadores como o IE9. Também sugerem referenciar a CDN para incluir o MDL no website, mas também é possível baixar ou importá-lo via npm ou Bower.

Fonte: Portal InfoQ

0

XIVsimposioO Simpósio Brasileiro de Qualidade de Software (SBQS) é um evento anual da Comissão Especial de Engenharia de Software da Sociedade Brasileira de Computação (SBC) e do Comitê do Programa Brasileiro da Qualidade e Produtividade em Software (PBQP-SW). O evento tem como objetivo reunir pesquisadores, profissionais, empresários, professores e estudantes de diversas áreas, interessados em questões relativas à qualidade de software.

O Simpósio também favorece o intercâmbio de informações entre pesquisadores nacionais e estrangeiros de renome, e entre indústria e usuários, sobre o estado atual e tendências, em termos de métodos, técnicas, ferramentas de software, evidências e experiências práticas da área de Qualidade de Software.

Em 2015, o XIV SBQS será realizado pela primeira vez em Manaus e pela segunda vez na Região Norte, organizado pelo Instituto de Computação (IComp) da Universidade Federal do Amazonas (UFAM).

O SBQS tornou-se um fórum em que a comunidade científica e a indústria da área de software se encontram para compartilhar experiências, discutir problemas e soluções da área de qualidade de software e estabelecer novas parcerias. A programação do SBQS 2015 conta com:

  • Apresentação de palestrastes convidados de reconhecido destaque na área de Qualidade de Software
  • Apresentação dos trabalhos técnicos e relatos de experiência da indústria
  • Concursos de Teses e Dissertações em Qualidade de Software (CTDQS)
  • Workshop de Teses e Dissertações em Qualidade de Software (WTDQS)
  • Encontro da Qualidade e Produtividade em Software (EQPS)
  • III Workshop de Transparência em Sistemas (WTRANS)
  • Mini-cursos

Fonte: Portal SBQS 2015

0

web_developmentRecentemente Mark Nottingham, presidente do Grupo de Trabalho do HTTP na IETF, tentou responder a pergunta O que é a Web? Como ele disse, essa pergunta deveria ter uma resposta simples, uma vez que todos usam a Web, mas que no fundo acaba sendo bastante controverso. Nottingham inicia com:

Durante muito tempo, a definição mais aceita de Web é de algo que tem uma URL. Essa é a visão do “sistema de informação da web”. Vem sendo percebido que os três pilares da Web são: identificadores, formatos e protocolos. As URLs são as mais universais e estáveis.

Infelizmente como Nottingham mencionou, essa visão tem limitações. Por exemplo: por essa definição o WS-* estava na Web e ainda muitas pessoas tentam debater isso. Do mesmo modo, muitos serviços RESTFul estariam nessa definição, já que todos eles possuem URLs e os benefícios do HTTP. No entanto, nenhuma das abordagens podem ser usadas normalmente no navegador de modo significativo:

[…] na melhor das hipóteses obtém um retorno no formato blob de XML ou JSON, sem o uso correto dos links. No entanto há exceções, tal como as pessoas da indústria fazendo APIs de hipermídia, elas são as exceções.

Isso, então mostra uma definição mais restrita do significado de estar na Web: alguma coisa que pode ser feita no navegador. Obviamente isso incluí qualquer coisa que tem uma definição de URL, HTTP e HTML, se o navegador não estiver envolvido.

A visão “o que pode ser feito no navegador Web” tem mudado para o que agora é chamado de Plataforma Web […] e sendo o elemento central do que está acontecendo no W3C. O W2C tem focado muito em tornar a Web em uma plataforma que pode competir com os seus concorrentes, isto é o iOS e Android.

No entanto, como Nottingham mencionou, está definição não cai bem com tudo. Roy Fielding twittou:

Novamente, com mais sentimentos… a Web não é a “Plataforma Web”; isso é apenas como alguns usuários de arquiteturas tentam suprimir a originalidade, a favor de um sistema operacional fraco.

Apesar de Nottingham concordar com Fielding em certo grau e que isso será sempre útil para usuários sem navegadores, a Plataforma Web é especialmente interessante quando falamos de interoperabilidade e padrões.

Isso porque assumimos que os navegadores definem a Web como uma “plataforma” cheia de questões que pensamos estar resolvidas, mas que foram jogadas no ar novamente.

Por agora, a definição de pontos de extensão em padrões tipicamente precisam de formulário de coordenação. Tal como o uso dos registros dos IETFs. No entanto, se os navegadores são componentes da Plataforma Web então…

[…] não serão necessários registros e namespaces; basta editar a especificação – fornecer as informações completas dessa especificação refletindo o que é esperado dos navegadores. O argumento será na Web baseada nos navegadores, outros softwares usando essa especificação não devem divergir do comportamento dos navegadores Web, porque fazendo dessa forma poderá causar problemas de interoperabilidade e, assim, reduzir o valor do software. Então, apenas garanta que os navegadores estão caminhando em passos firmes e documente o que eles fazem nas especificações; não será necessário nenhum registro mal elaborado.

Como observado, isso pode ser usado na especificação do WebCrypto para documentar quais algoritmos estão disponíveis. Porque os navegadores implementam o que quiserem ser compatíveis e interoperáveis. Uma vez que essa abordagem funcione bem, é provável que tenhamos outras APIs e especificações orientadas para navegadores. No entanto, há situações nas quais isso não está muito claro, como por exemplo:

Na área do HTTP, por exemplo, reconhecemos que outros agentes de usuários como rastreadores na Web (Web crawlers) e ferramentas de testes querem ficar perto dos navegadores, enquanto outros usos de protocolos não querem se envolver com navegadores. Os links relacionados são amplamente baseadas em tornar aespecificação do HTML5 prática, por isso usamos um wiki e falamos sobre como fazer o mesmo com as especificações do IETF.

Conforme Nottingham, outra área que a abordagem focada no navegador Web produz soluções interessantes é o versionamento. Muitas implementações de navegadores mudaram seus ciclos de lançamentos para versões mais curtas do que antigamente, alguns até com atualizações automáticas. Portanto, o lançamento de versões de especificações do HTML, entre outros, não ajudam, porque o que é importante é o que está implementado atualmente.

Isso permite que as especificações se tornem como “Padrões de Vida”, […] tal como, atualizações constante de documentos, baseando não apenas na evolução natural dos documentos (sendo uma API, formato ou conceito), mas também incorporando correções de bugs, exemplos aperfeiçoados e um melhor alinhamento com a realidade do que a Web atualmente é.

O problema aqui é que essa abordagem provavelmente não funcionará muito bem com aqueles não interessados em usar navegadores.

Por exemplo, pessoas que querem definir critérios de conformidade para o governo acharam isso enlouquecedor. Isso também pode se referir a documentações problemáticas.

Como de costume, uma versão raramente conterá tudo e Nottingham acredita que a abordagem do versionamento “da web” será abordada com base em cada caso, com um versionamento meticuloso para algumas coisas como o HTTP e nem tanto para outras como o HTML. É interessante notar que apesar do W3C siga na direção de publicar snapshots de Padrões Vivos, para os usuários que precisam referenciar alguma versão especifica “do termo” no documento. É claro que isso levanta o problema de como tratar as mudanças que quebram a compatibilidade:

A resposta no caso do HTML é que eles tanto a) não irão, ou b) coordenarão isso e resolverão os problemas logo no começo (provavelmente porque já há problemas de interoperabilidade e foi considerado o menor mal). Para outras coisas como mudanças em API, liberar as coisas com novos nomes (mesmo que sendo apenas o último digito) permite realizar implementações de forma incremental, mantendo em mente que a especificação é para assuntos novos e ainda mantém o estilo de estar “vivo”.

O que faz dessa definição de Web significar para o modesto navegador e também a abordagem de seguir o navegador como uma definição de Web? Bem, como Nottingham discute, tem sido um longo tempo que os navegadores são clientes dominantes da “janela” para a Web.

[…] agora temos telefones, TVs, carros e muito mais fazendo parte da Web. Essa pressão para incluir mais tipos de dispositivos, juntos com navegadores não tradicionais surgindo de lugares como China e Índia, colocaram o modelo “siga o navegador” sob uma certa quantidade de stress.

Como Nottingham iniciou a notícia com a questão “O que é a Web?”, pode parecer simples e todos acreditamos saber a resposta, mas a realidade é um pouco diferente. Como a Web continua evoluindo, com mais mudanças nos protocolos como o HTTP, e navegadores, mais a influência dos dispositivos móveis, internet das coisas, entre outros, sendo que “na Web” e a definição de “O que é a Web?” possuindo variações.

Na sua opinião, o que é a Web?

Fonte: InfoQ

0

O homem que criou a Lei de Moore, que diz que o poder de processamento cresce exponencialmente a cada dois anos, afirma que esperava que esta só se mantivesse real até 1975.

2013-03-01-bitsO princípio teórico foi formulado em 1965 e Moore esperava que essa Lei só fosse realidade até daí a dez anos. O co-fundador da Intel explica que está «admirado» por verificar que a Lei se mantém atual ainda nos nossos tempos. «Não fazia ideia de que se tornaria tão precisa durante tanto tempo», afirmou Moore, num evento que celebrou precisamente 50 anos sobre a criação desta teoria.

O desafio é, daqui a cinco ou dez anos, termos engenheiros com capacidades suficientes para manter a teoria real, disse Moore, citado pela Cnet. Outro desafio adicional prende-se com os custos elevados que implica o desenvolvimento e pesquisa para novos chips. Em 1966, uma fábrica de processadores custava 14 milhões de dólares, em 1995 1,5 mil milhões e atualmente pode chegar aos dez mil milhões de dólares. Os fabricantes estão dedicados a manter a Lei de Moore real, duplicando a capacidade de processamento e diminuindo o tamanho dos componentes, mas também estão à procura de alternativas.

Gordon Moore revelou ainda estar desapontado pela diminuição de investimento por parte do governo dos EUA na investigação científica e que não podia prever o boom das redes sociais ou de aplicações como o Google Earth que dão tanto ao consumidor, quase gratuitamente.

Fonte: Exame Informática