Hospedagem Profissional

Hospedagem Profissional
Clique aqui e ganhe US$ 10,00 para testar durante 1 mês a melhor hospedagem: Digital Ocean!

quarta-feira, 31 de outubro de 2012

Consumidor poderá exigir velocidade de internet contratada a partir de amanhã

Entram em vigor a partir desta quinta-feira as novas regras de qualidade da internet fixa no país estabelecidas pela Agência Nacional de Telecomunicações (Anatel). Os consumidores poderão exigir uma velocidade instantânea da internet, que não poderá ser menor do que 20% da contratada pelo usuário, em 95% das medições realizadas.

Até agora, as empresas não tinham nenhuma obrigação. Caso o usuário contratasse 1 mega de velocidade, não significava que ele realmente estava recebendo esta velocidade no seu computador.

No primeiro ano, a velocidade instantânea é de 20 %. Nos doze meses seguintes, será de 30% e, a partir de então, é de 40%.

As empresas também são obrigadas a ter uma velocidade média da banda larga fixa. Ela é o resultado da média de todas as medições realizadas no mês. A meta a partir de agora é de 60%, nos doze primeiros meses. A partir de novembro de 2013, será de 70% e, a partir de então, sempre de 80%.

As empresas tiveram um ano para adaptar os seus equipamentos as novas regras de qualidade da Anatel estabelecidas no Regulamento de Gestão da Qualidade do Serviço de Comunicação Multimídia. Aquelas que não cumprirem as metas de qualidade poderão ser punidas pela agência.

Fonte: O Globo

Existe uma entidade oficial criada justamente para o acompanhamento da qualidade dos serviços de banda larga, é a EAQ.

A Entidade Aferidora da Qualidade (EAQ) foi criada em atendimento à Resolução Anatel n.º 574, de 28 de outubro de 2011, como parte do processo de aferição dos indicadores de qualidade das redes de telecomunicações que suportam o acesso à Internet em banda larga no Brasil.

No link abaixo você pode efetuar o teste de velocidade de sua banda larga:

Infelizmente o percentual entregue será apenas de 20% do contratado, depois 30% no segundo ano e 40% a partir disso. Eu discordo, se contrato um serviço e pago por ele, quero 100% do serviço prestado.

terça-feira, 23 de outubro de 2012

Palestra sobre Trac no Javac 2012

Pessoal, no último sábado, dia 20/10/2012, foi realizado o Javac 2012 na Univag.

 
Tive a oportunidade de falar um pouco sobre o Trac utilizado em conjunto com o SVN.


Segue a apresentação :



Infelizmente, a parte de demonstração vai ficar faltando, porém gostaria de deixar uma dica importante para quem se interessou pelo assunto, é o seguinte, existe um serviço on-line chamado Project Locker que permite a criação de uma conta gratuita para até 2 usuários e 200Mb de espaço para gerenciar infinitos projetos de software utilizando Trac com SVN ou Trac com Git.


Eu utilizo esse serviço já a alguns anos e recomendo.

Para aqueles que se interessaram, podem clicar aqui para se cadastrar gratuitamente para utilizar o serviço.


Em nome da organização, agradeço os quase 200 participantes que estiveram presentes e que contribuíram com uma quantidade significativa de alimentos que será doada para uma instituição de caridade.

 Em breve divulgarei aqui algumas apresentações das outras palestras do evento.


quarta-feira, 10 de outubro de 2012

Javac 2012 - Encontro de Desenvolvedores Java de MT

Será realizado no dia 20/10/2012 no Centro Universitário Univag em Várzea Grande o Javac 2012.

O evento já tradicional no estado de MT contará com várias palestras relacionadas ao mercado de desenvolvimento de software utilizando a linguagem de programação Java.

Estarei participando como palestrante com o seguinte tema: Gestão de configuração de Projetos Java com Trac e SVN

Conto com sua presença! ;)

Mais detalhes no cartaz abaixo.



Para se inscrever, clique aqui!

terça-feira, 2 de outubro de 2012

Integração Contínua

O texto abaixo é a uma tradução autorizada do artigo escrito pelo Martin Fowler. Para acessar a versão original em inglês, clique aqui . Caso você tenha sugestões para tornar a tradução melhor, compartilhe através da seção de comentários no final da página.

The text bellow is an authorized translation of the article written by Martin Fowler. To access the original english version, click here . If you have any suggestion to make the translation better, share it via comments section at the end of the page.

Construindo um componente usando Integração Continua

 Para mim, a forma mais fácil de explicar o que Integração Contínua (IC) é e como trabalha é mostrando um pequeno exemplo de como isso funciona com o desenvolvimento de uma pequena parte do sistema. Vamos assumir que eu tenho que fazer alguma coisa para uma parte do sistema, não importa realmente que tarefa é – por enquanto vou supor que isso é pequeno e que pode ser feito um poucas horas ( vamos explorar tarefas maiores e outros problemas mais tarde ). Começo pegando uma cópia atual do código fonte e colocando na minha máquina de desenvolvimento. Faço isso utilizando um sistema de controle de código para ter uma cópia de trabalho a partir do código principal.

O parágrafo acima irá fazer sentido para pessoas que usam sistema de controle de código, mas não será para aqueles que não usam. Então deixe-me explicar rapidamente: um sistema de controle de código mantém todo o código fonte de um projeto em um repositório. O estado atual do sistema geralmente é chamado de mainline( ou linha principal). Em qualquer momento um desenvolvedor pode fazer uma cópia da versão principal em sua máquina, e isso é chamado de check out. A cópia em uma máquina de um desenvolvedor é chamada de cópia de trabalho (na maior parte de tempo você estará atualizando sua cópia de trabalho junto a principal).

Agora eu pego minha cópia de trabalho e faço o que preciso para completar minha tarefa. Isso irá consistir em alterar o código de produção e também adicionar ou alterar os testes automatizados. Integração Contínua assume um alto nível de testes que são automatizados no software: uma facilidade que eu chamo de self-testing code ( ou código auto-testável). Frequentemente estes usam uma versão da popular framework de teste xUnit.

Um vez que eu terminei (e isso geralmente acontece em vários lugares quando eu estou trabalhando), eu faço uma build (ou desenvolvimento de uma versão) automatizada na minha máquina de desenvolvimento. Assim, o código fonte em minha cópia de trabalho é pego, compilado e transformado em um executável – e então é executado os testes automáticos. Somente se todas as builds e testes não tiverem erros que tudo será considerado bom.

Com uma boa build, eu posso então pensar em colocar minhas alterações no repositório. A questão é, claro, que outras pessoas podem fazer (e geralmente fazem) mudanças na versão principal antes de eu ter a chance de fazer um commit ( ou atualizar o repositório principal com a minha versão do código). Sendo assim, primeiro eu atualizo minha cópia de trabalho com as mudanças feitas pelos outros e crio uma nova build. Se as mudanças deles chocarem com as minhas mudanças, será exibido erros tanto na compilação quanto nos testes. Neste caso é minha a responsabilidade de corrigir estes erros e repetir o processo até que minha cópia local esteja sincronizada com a versão principal.

Uma vez que tenho as alterações na minha própria build de uma cópia devidamente sincronizada eu posso finalmente fazer o commit na versão principal, que atualiza o repositório. Entretanto meu commit não termina meu trabalho. Nós fazemos uma build novamente, mas agora em uma maquina de integração baseada na versão principal do código. Somente com o sucesso desta build poderemos dizer que as minhas alterações foram feitas. Sempre existe uma chance de eu ter esquecido alguma coisa na minha máquina e o repositório não ser atualizado corretamente. Somente quando minha build de alterações for lançada com sucesso na máquina de integração é que o meu trabalho terminou. A build de integração pode ser executada manualmente por mim ou ser feita automaticamente usando o Cruise.

Se um choque ocorrer entre as versões de dois desenvolvedores, isso geralmente é pego quando o segundo desenvolvedor atualizar sua cópia local com as builds feitas pelos outros. Caso não, a build de integração deve falhar. De qualquer modo o erro é detectado rapidamente. Nesse momento a tarefa mais importante é consertar os problemas, e fazer sua build voltar a funcionar corretamente. Em um ambiente de Integração Contínua você nunca deve ter uma build de integração com falhas por muito tempo. Um bom time deve ter muitas builds corretas por dia. Más builds podem ocorrer de tempos em tempos, mas devem ser consertadas rapidamente.