image1 image2 image3 image4 image5 image6 image7 image8 image9 image10
Data de criação:
Data de publicado:
Acessos: 2379

Se um dia disserem que é verdade, negarei com todas as forças.  Vamos dizer que essa história é uma ficção e que esse tipo de coisa nunca acontece nos meios corporativos.

Então toda e qualquer referência por aqui é pura imaginação minha, certo?

Pois então.  Sabem o que é virose?  Não?  Não minha opinião, é algo genial criado pelos médicos.  Já explico: pra quem tem filho, é comum ir ao médico pra ver alguma febre repentina que surge no meio da noite.  E, na falta de um diagnóstico, é comum ouvir o termo "ah, isso é algum virose".  Em geral trata-se com algum anti-termal (paracetamol ou algo do gênero) pra controlar a febre, e só.  Tem de se esperar passar.  

 Pois uma vez eu trabalhava com um sistema de stream de vídeo, e o vídeo, vez ou outra, mostrava umas áreas "quadriculadas" por alguma perda de pacotes da rede.  A questão é que a topologia estava exatamente assim:

O servidor de stream estava conectado num roteador de core, que ligava via fibra ótica (10 Gbps) ao switch core, que ligava no DSLAM.  O DSLAM dividia a saída em 2 VLANs: uma pra Internet em geral, e outra específica pra TV.  Não existia nada mais ligado nessa rede.

E quando é época de inferno astral, realmente não se tem muito o que fazer.  Pois bem no dia em que estávamos testando isso, surge uma "visita" inesperada do diretor da conta de vendas, querendo ver como andavam os testes.  No exato momento em que ele adentra a porta do recinto, a TV (talvez já mancomunada com algum ente espiritual maligno, algo como o exu-tranca-sistemas) resolve expor os pequenos pontos quadriculados.

A meia hora seguinte foi de sabatina de perguntas sobre o motivo dos quadriculados.  Resolveu-se que aquilo era inaceitável e que a topologia deveria ser revista.  Toda ela.

Não houve solução senão ir conectando o setupbox (a caixinha que convertia o stream pra saída de vídeo da TV) nos nós da rede para tentar detectar qual elemento estava falhando.  Primeiro retiramos a parte DSL (DSLAM e modem), ligando diretamente no switch core.  O quadriculado continuava lá.

Movemos diretamente para o roteador de core, apenas trocando a porta de fibra ótica para ethernet.  E o quadriculado continuava lá.

Então conectamos diretamente no servidor de stream, para assim já decretar sua morte e dizer que tínhamos encontrado a origem do problema.  E o vídeo passou normalmente...

Esse é o exato momento em que todo mundo fica com aquela cara de poker face.

Então resolvemos reconectar ao roteador, pois esse deveria ser o causador do problema.  Tudo conectado, fomos aos testes e... vídeo funcionando perfeitamente.  Nenhum problema aparente.

Então conectamos novamente ao switch core para verificar se o problema poderia ser a porta de via fibra ótica e...

Voltamos ao DSLAM e...

Assumimos que aquilo era obra do demônio, o exu-tranca-sistemas mesmo, e seguimos a vida em frente, ou melhor, continuamos com os testes.

Ao final do dia, recebo uma ligação de um alto escalão querendo saber se o problema havia sido resolvido.  Expliquei gentilmente que sim, e que todos os elementos de rede tinham sido revisados.  Então recebi a pergunta fatídica: qual era a origem do problema?  

Sem titubear, respondi:

- Virose de rede, mas já estamos administrando 10 pings de 4 em 4 horas, por 7 dias, para evitar inflamações nos links.

E tudo teria terminado aí, se não houvesse uma apresentação para altos executivos.  

No dia da tal apresentação, apareceram os distintos senhores, todos devidamente engravatados.  E começou-se a apresentação.  Eu, por ser um cara muito técnico, apenas fiquei ao fundo da sala assistindo a apresentação, que era ministrada por alguém que eu nunca tinha visto na vida, e que estava também devidamente engravatado.  E falava com bastante segurança sobre os testes realizados.  E tudo corria bem e tranquilo, com exibição perfeita do vídeo, quando, ao final da apresentação, o engravatado soltou em alto e bom som:

- E durante os testes, nossos técnicos encontraram uma virose de rede.  Mas eles trabalharam arduamente para elinimar esse vírus e agora garantem que os links não ficarão inflamados, não afetando a performance do vídeo.

Tive de sair da sala para não engasgar de tanto rir.

Data de criação:
Data de publicado:
Acessos: 2488

Desde o fim do ano passado, tenho percebido que o Estadão resolveu colocar um filtro de conteúdo em alguns de seus artigos na web.

Como o conteúdo pertence ao jornal, eles têm todo o direito de fazer esse tipo de abordagem.  Mas o que eu acho chato é que eles publicam esses artigos no twitter, e depois enfiam na sua cara o bloqueio.  

Enfiam?  Será?

Se enfiam na cara, quer dizer que roda na minha máquina e não na deles, certo?  Então eu posso dizer para meu navegador (no caso o Google Chrome) "não" ler esse bloqueio, não posso?  Claro que sim!

Depois de uma procura no código da página, encontrei um javascript que chama uma função fadeOut() para criar esse efeito.  Bastou então achar o arquivo javascript com tal função.  Pra isso contei ajuda do browser por linha de comando Lynx e um pouco de shell script.

for link in $(lynx \
   -source -dump \
   "http://www.estadao.com.br/noticias/esportes,pistorius-rejeita-acusacao-de-assassinato-da-namorada,997339,0.htm" | \
   grep js | \
   sed "s/.*src=\"//" | \
   grep estadao | \
   sed "s/\".*//" | \
   sed "s|^/|http://www.estadao.com.br/|" | \
   grep -v img.estadao)
   do 
   echo $link
   lynx -dump -source "$link" | \
      grep -i fadeout && \
      echo "ACHEI: $link" && \
      break
done

Então consegui achar que o vilão é o javascript de jquery:

http://www.estadao.com.br/estadao/novo/js/jquery-1.5.2.min.js

Bastou então usar o AdBlock Plus pra bloquear esse arquivo e tudo funcionou novamente.

 

Data de criação:
Data de publicado:
Acessos: 3951

Leap of faith, ou salto de fé, é um passo no vazio que se dá durante a série de jogos "Assassins Creed".  Basicamente significa "fechar os olhos e acreditar que vai dar certo".  Durante o jogo, existem lugares já marcados para usar o "salto da fé", onde em geral existem pombas, mas na vida real, nem tanto.

Não que eu tenha tentado pular da varanda de casa, nem tentado assassinar ninguém.  Nada disso.  Mas esses dias eu fiz um "salto de fé" ao cancelar meu serviço de banda larga do Net Virtua e assinar o de fibra óptica da TIM.  Como não existem muitas instalações e descrições, foi um passo seguido de fé, muita fé...

O acesso não é caro: paga-se por volta de R$ 60,00 por 35 Mbps de downstream e 20 Mbps de upstream.  Por mais ou menos R$ 50,00, o Net Virtua me fornecia somente 1 Mbps.  E esse não era o único problema com o Virtua: a latência de rede era o pior.  Simplesmente estava impossível de fazer qualquer coisa com o link, pois tudo tinha uma latência absurda, fazendo vídeos do Youtube engasgarem mesmo com a menor qualidade, e tornando impossível jogar jonline, como com "call of duty", na PSN do Playstation.  Não sei se é QoS mal feito do lado da Net, ou o que pode ser, mas com certeza não era o fato de ter somente 1 Mbps que fazia a diferença, pois tenho a mesma banda em outro lugar, também pelo Net Virtua, e não sofro desse problema.  

Pela monitoração do link, dava pra ver que dificilmente essa banda era totalmente utilizada.  Mesmo sem tráfego na rede, os tempos de respostas de ping alcançavam valores próximos de 800 ms, o que mudou para 10 ms em geral com o link da TIM.

helio@shibboleet:~$ ping -c 10 helio.loureiro.eng.br
PING helio.loureiro.eng.br (200.160.198.15) 56(84) bytes of data.
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=1 ttl=50 time=10.6 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=2 ttl=50 time=10.1 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=3 ttl=50 time=10.1 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=4 ttl=50 time=10.7 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=5 ttl=50 time=10.2 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=6 ttl=50 time=11.3 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=7 ttl=50 time=10.0 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=8 ttl=50 time=10.1 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=9 ttl=50 time=10.0 ms
64 bytes from cp01-tvt-db.durand.com.br (200.160.198.15): icmp_req=10 ttl=50 time=11.2 ms

--- helio.loureiro.eng.br ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 10.006/10.469/11.338/0.498 ms

E justamente pela falta de comentários sobre o Live TIM, fibra óptica, que resolvi escrever um pouco sobre o mesmo.

Primeiro que não é um serviço de fibra que chega em casa, o FTTH (Fiber To The Home).  É mais um FTTB (Fiber To The Building), pois a fibra óptica chega até o DG (Distribuidor Geral) do prédio, que fica no térreo, e daí é convertido por um DSLAM em VDSL, que então sobe para residência pelo sistema de par trançado de cobre, usado pela telefonia.  Na residência, ou melhor, no apartamento, é preciso um modem (CPE) de VDSL para converter esse sinal em rede ethernet.

Nesse ponto existe um lado que pode ser tanto ruim quanto bom: o CPE.  É um modem da ZTE fornecido pela TIM que levanta uma sessão PPPoE com a rede, recebendo o IP válido, e faz NAT de saída.  O serviço da TIM gentilmente fornece o login e senha de administração pra poder alterar os parâmetros (admin/admin), mas o CPE usa um firmware completamente limitado, que não permite mudar muita coisa.  É possível configurar o wifi que vem embutido e o endereçamento interno, mas acaba por aí.  Isso me levou a ter 2 nívels de NAT na minha rede interna: o já existente no roteador TP-Link TL-WR1043ND e que roda DD-WRT, e esse segundo NAT do CPE da ZTE.  Com isso, não consigo mais acessar por ssh as máquinas internas da minha rede.

 

Como não consegui acessar a portas das máquinas internas, utilizando port fowarding, não sei dizer se está faltando configuração no CPE ou se a TIM bloqueia as portas.  Isso no momento é chato, mas não é um problema que me faça voltar a usar o Net Virtua.  E também não quero desligar meu roteador com DD-WRT, pois o mesmo me ajuda a monitorar a rede com SNMP, entre outras coisas.  Eu testei a colocação de uma máquina logo atrás do CPE, com o roteamento de porta, e o mesmo não funcionou.  Então estou acreditando que a TIM realmente BLOQUEIA as portas ou o tráfego entrante.

Tentei fazer a configuração do DD-WRT totalmente em bridge, mas não consegui até o momento.  Então esse é um ponto negativo do Livre TIM: utilizar um PPPoE com NAT no modem sem possibilidade de mudar.  Como o acesso fornecido não tem limitação de quantidade de dados, não entendi muito bem o motivo de usar o PPPoE  - outro ponto que não vou classificar como negativo, mas diria que desnecessário.  Outra coisa que fiquei decepcionado foi em relação ao tipo de IP recebido: somente IPv4.  Eu já estava salivando de excitação esperando um IPv6 também.  Mas como o CPE é novo, provavelmente deve suportar upgrade.

Dos pontos positivos, a banda, o custo e o fato de não ter nem custo de instalação, nem contrato de serviço, podendo ser interrompido a qualquer momento.  Testei fazer download utilizando até 20 Mbps de downstream, com 10 de upstream liberado, e jogar ao mesmo tempo.  O resultado foi fantástico: sem problemas, nem latências, nem travamentos.  Ainda mandei um stream de vídeo no Youtube com mais um stream do NetFlix, ambos em HD, e... sem problema algum!

Foi um realmente um salto de fé no escuro, mas aparentemente o serviço IP da TIM é muito melhor que seu serviço de telefonia.  Não estou arrependido, mas só vou poder dar uma opinião sobre a qualidade geral do serviço após 6 meses de uso, no mínimo.

Atualização: Fri Feb 15 13:45:53 BRST 2013

Justamente quando estava escrevendo sobre a banda larga da TIM, fiquei quase 24 horas sem Internet.

 

Em termos de acesso à rede, isso é quase uma eternidade, o que desencadeou minha síndrome de abstinência internética.  Durante esse período, consegui acessar uma rede Wi-Fi de algum vizinho, que estava generosamente aberta sem senha alguma.  Nisso fui informado pelos amigo que o problema era um rompimento de fibra óptica, justamente na minha região.

http://tecnologia.uol.com.br/noticias/redacao/2013/02/05/rompimento-de-fibra-otica-afeta-servicos-da-tim-e-da-intelig.htm

Realmente foi muito azar ou acaso.  Acabei indo viajar até o carnaval, o motivo pelo qual não terminei de escrever e publicar esse post e só voltar a ele agora.  

Mas após esse incidente, o link voltou e está funcionando sem problemas.

Slideshare

Autor:
Data de criação:
Data de publicado:
Acessos: 2302

Finalmente resolvi publicar alguma coisa no slideshare.  Não que eu tenha tanta coisa assim pra compartilhar, mas estava ficando envergonhado de receber vários pedidos para "seguir" pessoas por lá, uma vez que nunca publiquei absolutamente nada.

Então fiz o upload de algumas apresentações antigas, realizadas entre 2002 e 2005 (acho), que fiz para eventos do Debian-SP, GTER (Grupo de Trabalhos de Engenharia de Redes, ligado ao Nic.BR) e Maratona HOWTO, esse último um evento de HOWTOS que foi ideaizado pela 4Linux, se não estou enganado.

São assunto variados, indo de roteamento avançado e controle de banda à PABX IP com Asterisk.  Provavelmente devem estar obsoletos, uma vez que faz mais de 10 anos que foram escritos, mas... ao menos publiquei algo por lá ;-)

 

http://www.slideshare.net/helioloureiro

 

Data de criação:
Data de publicado:
Acessos: 10674

XGH é uma das coisas mais genias que surgiu nos últimos tempos, descrevendo a estupidez que se aplica em métodos ágeis, mas que reflete bem o ambiente corporativo.  Infelizmente o site foi abandonado e seu conteúdo, apagado.

Mas com a ajuda do wayback machine, consegui resgatar o conteúdo, e estou replicando aqui, para que fique imortalizado na Internet.

Afinal, quem aqui nunca praticou XGH?

Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

Wayback: http://web.archive.org/web/20100404033640/http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

 

eXtreme Go Horse (XGH)

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

2017  helio.loureiro.eng.br   globbersthemes joomla templates