0

LOGO_SEFAZO governador José Melo anunciou nesta sexta-feira, 3 de julho, que a Secretaria de Estado de Fazenda (Sefaz) vai entrar em regime de plantão emergencial para zerar o estoque de insumos e mercadorias que estão com a liberação atrasada por conta da greve dos servidores da Superintendência da Zona Franca de Manaus (Suframa). A medida foi tomada após decisão da Justiça Federal do Amazonas autorizando que o desembaraço realizado por técnicos da Sefaz substitua o dos servidores da Suframa, durante o período da paralisação.

Na última quarta-feira, 1º de julho, o governador determinou à Procuradoria Geral do Estado (PGE) que ingressasse com novo pedido na 3ª Vara da Justiça Federal do Amazonas para resolver o impasse em torno da liberação de mercadorias e insumos para o comércio e as fábricas do Polo Industrial de Manaus (PIM). Por conta da paralisação dos servidores da autarquia, que já dura 44 dias, cerca de 198 mil notas fiscais de produtos para abastecer o comércio e a indústria amazonense aguardam liberação.

Com a decisão judicial, a Sefaz poderá fazer o desembaraço das mercadorias sem a necessidade de liberação pela Suframa. “Isso significa que a liberação da Sefaz valerá pela da Suframa. Estamos preparados. Determinei que neste final de semana vamos entrar pela noite, fazer plantão de 24 horas, para ver se nos próximos cinco dias a gente consegue tirar todas as notas fiscais pendentes e os milhares de containers que estão entulhando e, com isso, regularizar a situação da entrada de insumos nas fábricas e do outro lado abastecer o mercado consumidor do Amazonas, que também estava contido”, disse o governador.

José Melo afirmou que a normalização do desembaraço nos portos e aeroportos deve ajudar a melhorar o desempenho na arrecadação do Estado. No primeiro semestre, as perdas na receita com o Imposto sobre Circulação de Mercadorias e Serviços (ICMS) chegaram a R$ 300 milhões, puxadas pelo baixo desempenho da indústria – que registrou queda de 18,2% na atividade industrial nos primeiros quatro meses. A greve também gerou impactos negativos na arrecadação. Segundo estimativa da Sefaz, cerca de R$ 200 milhões deixaram de ser recolhidos com o ICMS por conta da demora na liberação de mercadorias.

Fonte: Portal da SEFAZ/AM

2

Em Engenharia de software, um anti-padrão é um padrão de projeto de software que pode ser comumente usado mas é ineficiente e/ou contra-produtivo em prática.

ANTIO termo foi cunhado em 1995 por Andrew Koenig, inspirado pelo livro do Gang of Four Design Patterns, que desenvolveu o conceito de padrão de desenho de software. O termo foi largamente popularizado três anos depois pelo livro Anti Patterns, que estendeu o uso do termo além do campo de desenho de software para interações pessoais em geral.

De acordo com os autores do último, deve haver ao menos dois elementos chave para formalmente distinguir um anti-padrão real de um mau hábito, má prática ou má ideia.

Algum padrão repetido de ação, processo ou estrutura que inicialmente parecia benéfico, mas, como consequência produz mais malefícios do que benefícios, e uma refatoração de código existe que é claramente documentada, demonstrada na prática e reproduzível.

Várias ideias de anti-padrões são pouco mais que erros, discussões, problemas insolúveis, ou más práticas a serem evitadas, se possível. Às vezes chamados de armadilhas ou padrões escuros, esse uso informal do termo veio a referir classes de más soluções para problemas frequentemente reinventadas. Assim, vários candidatos a anti-padrões não seriam formalmente considerados anti-padrões.

Pela descrição formal de erros repetidos, é possível reconhecer as forças que levam à sua repetição e aprender como outros refatoraram códigos saindo desses padrões quebrados.

Anti-padrões organizacionais
  • Paralisia de análise: dedicar esforço desproporcional à fase de análise do projeto;
  • Vaca do dinheiro: um produto legado que às vezes leva à complacência sobre novos produtos;
  • Projeto por submissão (ou Design por comitê): o resultado de ter vários contribuintes para o projeto, mas nenhuma visão unificada;
  • Agravamento de compromisso (ou Escalação de Compromisso): falhar em revogar uma decisão quando a mesma se revela errada;
  • Gerência por perkele: estilo autoritário de gerência sem tolerância à divergências;
  • Departamentalização matricial: estrutura organizacional desfocada que resulta em lealdades
  • divididas ou subordinação dividida e falta de direção;
  • Risco moral: isolar alguém das consequências da sua decisão;
  • Gerência cogumelo: manter funcionários desinformados e mal-informados;
  • Aprisionamento tecnológico: fazer um sistema excessivamente dependente de um componente externo;
  • Stovepipe ou Silos: uma estrutura que suporta principalmente o fluxo vertical (de cima para baixo) de informação, mas inibe a comunicação organizacional;
  • Vendedor bloqueado: tornar um sistema excessivamente dependente de um componente externo.
Anti-patterns de Gerenciamento de Projetos
  • Marcha para a morte: todos sabem que o projeto caminha para um desastre, exceto o presidente da empresa, o CEO. Porém, a verdade permanece ocultada, escondida, e a sobrevida do projeto é mantida artificialmente até que o “Dia D” chega. Definição alternativa de marcha para a morte: funcionários sofrem pressões para trabalharem dias, noites e fins de semana em um projeto com prazo irracional;
  • Pensamento em grupo (ou Groupthink): durante o groupthink, membros do grupo evitam mencionar pontos de vista que estejam fora da zona de conforto do pensamento consensual.
    Fumaça e espelhos: demonstrar funções não implementadas como se já tivessem sido implementadas;
  • Software bloat (inchaço do software): permitir versões sucessivas de um sistema a fim de demandar cada vez mais recursos;
  • Modelo em cascata: Um velho método de desenvolvimento que lida inadequadamente com mudanças inesperadas.
Anti-padrão de análise
  • Apatia do espectador: quando uma decisão de análise é errada, mas quem percebe não faz nada pois afeta um número maior de pessoas.
Anti-padrões gerais de design
  • Inversão de abstração: não expor funcionalidades implementadas requiridas pelos usuários, então elas são re-implementadas em mais alto nível;
  • Grande bola de lama: um sistema sem uma estrutura reconhecível;
  • Gold plating: continuar a trabalhar em uma tarefa ou projeto passando do ponto em que esforço extra adiciona valor;
  • Gambiarra de entrada: falha ao especificar e implementar o manuseio de uma possível entrada inválida;
  • Inflação de interface: fazer uma interface tão poderosa que ela é extremamente difícil de implementar;
  • Condição de corrida: falhar ao ver as consequências de uma ordem alterada de eventos;
    Sistema chaminé: um sistema montado difícil de ser mantido pelos componentes mal-relacionados.
Anti-padrões de programação
  • Complexidade acidental: introdução de complexidade desnecessária em uma solução;
  • Ação à distância: interação inesperada entre partes distantes de um sistema;
  • Fé cega: falta de checar (a) a correção de um bug ou (b) o resultado de uma sub-rotina;
  • Âncora do barco: manter uma parte de um sistema que não tem mais uso;
  • Espera ativa: consumir CPU enquanto espera por algo acontecer, normalmente checando várias vezes ao invés de enviar mensagem;
  • Culto de programação: usar padrões sem saber o motivo;
  • Programando por exceção: adicionar código novo para lidar com cada caso especial quando esse é reconhecido;
  • Fluxo de lava: manter código indesejável (redundante ou de baixa qualidade) porque removê-lo é caro ou tem consequências imprevisíveis;
  • Números mágicos: incluir números inexplicados em algoritmos;
  • Strings mágicas: incluir literais no código para comparações inexplicadas;
  • Don’t repeat yourself: escrever código que contém padrões repetitivos, a serem evitados com o princípio da abstração;
  • Código espaguete: programas que têm a estrutura pouco compreensível, especialmente por mal uso das estruturas de código.
Anti-padrões metodológicos
  • Programação por copiar/colar: copiar (e modificar) código existente ao invés de criar soluções genéricas;
  • Martelo de ouro: assumir que uma solução favorit é aplicável universalmente;
  • Fator de improbabilidade: assumir que é improvável que um erro conhecido ocorra;
  • Otimização prematura: preocupar cedo com eficiência, sacrificando um bom desenho, manutenibilidade e às vezes até eficiência;
  • Reinventar a roda: falhar em adotar uma solução adequada e existente;
  • Reinventar a roda quadrada: falhar em adotar uma solução existente e no lugar adotar uma customizada que é bem pior.

Fonte: Wikipedia

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

GooglealgorithmNo dia 21 de abril de 2015, o Google mudou seu algorítmo de buscas originadas em dispositivos móveis para favorecer websites que são otimizados para smartphones. Isso irá afetar as buscas em todos os idiomas pelo mundo e terá um “significativo impacto em nossos resultados de busca”, afirmou o Google.

Com o teste de dispositivo móvel amigável desenvolvedores web podem determinar se o Googlebot irá considerar uma página amigável. A respectiva ferramenta online fornece os motivos porque uma página falha no teste e alguns conselhos sobre como corrigi-los. A ferramenta funciona para checar páginas individuais. Para validar sites inteiros, é recomendado que os desenvolvedores usem o Relatório de Usabilidade em Mobile, do Webmaster Tools.

Para considerar uma página web como sendo amigável para dispositivos móveis o Googlebot irá checar as seguintes condições:

  • a página não utilizará plug-ins de desktop, como o Flash;
  • o texto será largo o suficiente para poder ser lido sem precisar dar zoom;
  • o conteúdo permanece visível sem necessidade de rolagem horizontal ou zoom;
  • existe espaço suficiente entre os links para que o usuário possa toca-los sem o risco de ativar um outro.

O Guia do site amigável para dispositivos móveis dá conselhos sobre como tornar amigável um website para usuários móveis, com explicações sobre o design de websites responsívos, cabeçalhos HTTP Vary, tags alternativas e canônicas, sobre como lidar com tablets ou telefones com poucos recursos, e outros.

Fonte: Google News

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