Problemas com Wifi lenta perdendo pacotes

Problema: Perda de pacotes via wifi
Computador: Notebook Vostro 3550
Roteador: D-Link DIR-600
Sistema Operacional: Windows 7

Há poucos dias me deparei com um problema que muitas veze só é percebido quando sua conexão não é das melhores. Falamos da perda de pacotes. Para constatar o problema comecei fazendo o famoso ping no server da google. ( para quem nao sabe, basta ir em executar, digitar CMD, abrir o prompt de comanda e digitar: ping 8.8.8.8 -t) Peguei um cafézinho e comecei a observar.. Depois de um tempinho você dá control C e pára o processo para ver qual o percentual de perda de pacotes. 

No meu caso se tratavam de mais de 20% de perda.. Fui além.. dei um ping no meu roteador e percebi o mesmo problema. Ou seja, a perda de pacotes se dava entre o roteador e notebook. Ou seja, ou o problema é no roteador ou no notebook. O que fiz? Testei outros dispositivos na mesma rede e parecia estar tudo OK. Estranho. Logo, o problema estava no notebook mesmo. Comecei a desinstalar uma série de aplicativos. Atualizei a BIOS do notebook, atualizei os drivers no site da DELL. Fui além, fui no site da INTEL e peguei a versão mais atual do driver do WIFI. Mas nada resolvia. Mudei o canal do roteador para ver se o problema era alguma interferencia (mudei do 6 para o 0 ou 9), mas NADA. 

Depois de exaustivas tentativas chego a SOLUÇÃO!..

Solução: Basta ir no controle de perfis de energia (Opções de Energia) do seu Windows, alterar configurações do Plano, alterar Configurações de Energia Avançada e lá está a Configuração de Adaptadores Sem Fio. 

Lá você altera para Desempenho Máximo, tanto em bateria quanto na tomada e seu problema estará resolvido. O seu notebook passará a não poupar energia para se comunicar e usará o máximo de sua potencia Wifi. ;)

Uma breve conversa sobre Metodologias Ágeis

As metodologias tradicionais herdam características de engenharias tradicionais. Ou seja, projetam tudo antes e só depois de muitos processos massivos usam a mão-de-obra para executar o trabalho. Mas, isso dá certo com software em que os requisitos são vagos, incertos, mudam todo tempo?

Estima-se que nos modelos tradicionais em torno 40% do que é desenvolvido não será utilizado. Porém, diferente das metodologias tradicionais observa-se nas metodologias ágeis que as características dos projetos são definidas com maior firmeza. Por que? As metodologias ágeis trabalham somente com aquilo que de fato gera valor ao cliente, usuário e a organização. É o famoso faça simples e somente o necessário. Daí surge um importante valor ágil: SIMPLICIDADE.

Diferente do processo tradicional em que o escopo é fixo e o tempo e custo são variáveis as metodologias ágeis utilizam um processo inverso. Seu escopo não é definido, o foco é num constante feedback que gera um produto incrementalmente. E já que falamos de um produto evolutivo e assim adaptativo (ou seja, que se transforma de acordo com as necessidades que surjam) um outro importante valor surge. A CORAGEM, eis que seus fiéis elementos são as mudanças e estas são sempre bem vindas.

Podemos definir os processos e metodologias ágeis como iterativo, incremental, auto-gerenciavel (programador pode optar por suas preferências), auto-organizavel, equipe multi-funcional, foco nas pessoas, valor agregado ao cliente, produtos de
qualidade. E estes não são grandes novidades, mas princípios herdados de Lean.

Assim, em agiles, há um modelo comportamental não exato, constrói-se só o necessário, se houver algo errado o processo é paralisado e elimina-se tudo que não agrega valor. E tudo isso alinha-se facilmente a parte de uma filosofia de trabalho em que é dado poder aos trabalhadores (empower) em que se aproveita o limite dos profissionais dando poder à ponta. E o que isso gera? Mais respeito aos trabalhadores que passam a ter grande poder de voz e conseqüentemente um uso maximizado da capacidade da carga produtiva e incentivo.

Para que fique mais clara a origem das metodologias ágeis podemos demonstrar o 7 princípios básicos de Lean:

1. Elimina desperdicio
2. Aumenta feedback
3. Comprometimento do tempo
4. Entregas rapidas
5. Construa a integridade do sistema
6. Poder ao time (empower)
7. Enxergar o todo

É isso, em breve continuamos a conversa.

Como criar um Produto de Backlog?

O Product Backlog é um documento de alto nível do projeto em que estão contidas as features, atividades, etc. que o cliente deseja. A linguagem desse documento é a do cliente (histórias). Deve-se fugir de qualquer orientação técnica, essas envolvem o "HOWTO". As histórias possuem uma estimativa de complexidade e o valor de negócio para o cliente, isso ajudará na priorização.

Etapas do processo:

1. Reunião com cliente e seu time para ouvir os “o quê” (“O QUÊ” e não o “HOWTO”)
2. Reunião com time para discutir os pontos levantados (planning poker das histórias, SÓ HISTÓRIAS)
3. Reunião com o cliente e dar um feedback.

A classificação de priorização dos requisitos pode ser dada por:
1. Tem que ser feito na primeira versão (urgente)
2. Seria bom se fosse realizado, mas pode ser retirado
3. Realizar se houver tempo
4. Versões futuras


Há um template de produto de backlog altamente eficiente e complexo feito com macros excel da belga Boulevart. Confiram aqui.

Nesse link vocês podem ver um exemplo extremamente simples de uma tabela com o produto backlog.

Destruindo a civilização com Nanotecnologia

Um vídeo curioso, engraçado e com uma forte crítica ao nosso tão primado futuro nanotecnológico.

CMMI e Agilidade

Em uma nota técnica do SEI sobre CMMI e Agile, há o seguinte parágrafo (pág. 8):

http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html

Chapter 3: Factors that Affect Perception

Section 3.2 Lack of Accurate Information

Discussion of Agile methods in CMM/CMMI settings was frequently peppered with anecdotes equating Agile with "no discipline." In fairness, the XP community (unintentionally) invited this censure. Even the name "extreme programming" conjures up an image of skateboard parks or the rule-breaking anarchy of off-piste snowboarding. Certain readings of the Agile Manifesto (excerpted in Section 5) might bear resemblance to this perception.

Traduzindo-se:

Capítulo 3: Fatores que Afetam a Percepção

Seção 3.2: Falta de Informação Acurada

A discussão dos métodos Ágeis nos círculos de CMM/CMMI foi frequentemente apimentada com piadas igualando Agile a "sem disciplina". Com justiça, a comunidade XP (não intencionalmente) gerou esta censura. Até o nome "programação extrema/radical" traz à mente a imagem de parques de prática de skate ou a anarquia de quebrar regras dos esquiadores de neve fora de pista. Certas leituras do Manifesto Ágil (ver fragmento na Seção 5) podem se assemelhar a esta percepção.

Custo intelectual X Horas de trabalho

Era uma vez uma empresa transportadora de cargas. Trabalhava transportando
cargas bilionárias, petróleo e toda essa espécie de coisas. A menina dos olhos da empresa era um grande e novíssimo navio, que fora fabricado ao custo de 2 bilhões de dólares. Um dia de serviço desse navio custava à empresa US$ 100.000 dolares. Após somente 6 meses de serviço, o navio
simplesmente parou de funcionar. Foram chamados técnicos e mais engenheiros e mais mecânicos do fabricante, que ao término de 1 mês não conseguiram resolver o problema de jeito nenhum. 30 dias com esse navio parado siginificava um prejuízo de 3 milhões de dólares para a empresa, e seus donos estavam à beira de um colapso nervoso quando foi dada a idéia de
chamar um especialista independente, que já tinha enfrentado problemas semelhantes e se saído muito bem, devido à sua experiência imensa com a complexa mecânica naval.

Eis que no dia seguinte, chega o especialista. Senta-se em frente a uma das partes do motor, tenta ligar, pressiona alguns botoes, balança a cabeça, murmura algo para si mesmo... e puxa uma chave de fenda da sua caixa de ferramentas. Desaparece por entre os motores por alguns instantes, e ao retornar diz: “problema resolvido”. Apenas ao toque de um botão, o motor
responde o navio começa a funcionar novamente no ato.

O presidente da empresa ficou impressionado, e perguntou ao especialista quanto ele lhe devia. O especialista respondeu:

- A conta é US$ 1 milhão, por favor.

O presidente da empresa ficou indignado, e falou:

- US$ 1 milhão por apenas alguns minutos de trabalho? Para apertar um parafuso? Eu sei que o meu navio é um navio de 2 bilhões de dólares, mas 1 milhão é absurdo! Pagarei somente se receber uma nota fiscal com todos os detalhes que justifiquem esse valor!

O especialista simplesmente balançou a cabeça afirmativamente e saiu.

Na manhã seguinte, o presidente recebe a nota fiscal com o serviço descriminado. Ao terminar a leitura, não hesitou e mandou que fosse paga no ato.

A nota fiscal dizia:

Serviços realizados:

Visita técnica – cortesia

Apertar um parafuso – US$ 0,10

Saber qual parafuso apertar – US$ 999.999,90”

Em suma, um problema que era remexido há um mês e sem solução foi resolvido em poucos minutos. Um erro comum é querer fazer comparações entre complexidade x tempo. Isso é errado. Quando estimamos em SCRUM utilizando planning poker, levamos em consideração o tamanho de uma história, relativo à sua complexidade – esqueça as horas. Trabalhamos com processos empíricos, lembram? Não dá para querer controlar como controlamos uma linha de
montagem.

E no final, uma estimativa é somente uma estimativa – não é uma previsão, e não precisam ser certas. Obviamente, quando atingimos uma certa regularidade e melhoramos nossa exatidão das estimativas, ganhamos mais previsibilidade e temos melhores condições de nos planejar para o futuro. Mas isso é uma coisa que vem naturalmente, assim como a velocidade do time (normalmente, entre 3 – 6 Sprints), e não pode ser forçada.

Esse texto foi redigido pelo Igor Macaubas da lista scrum-brasil.

Adicionar e remover elementos HTML com Javascript

As noções básicas

Conheçam uma eficiente solução para adição e remoção de itens em HTML utilizando javascript. O efeito é similar ao utilizado nos botões de anexar do google ao se adicionar um novo anexo ou remover.

Assim, você tem três elementos básicos: adição de eventos; criação e junção de elementos, bem como a capacidade para removê-los.

Por exemplo:

incluir evento / adição / remoção

* element.addEventListener(el, type, fn);
* parent.appendChild(element);
* parent.removeChild(element);

Para esta tarefa básica, utilizam-se essas duas ações como um "esqueleto" para agir com sua API que irá se adequar conforme o DOM object e o Event object.

Dom e Event

var Dom = {
get: function(el) { },
add: function(el, dest) { },
remove: function(el)
};

Event = {
add: function(el, type, fn) { }
};

Seu código pode ficar encapsulado quando se adiciona este comportamento ao evento de ‘load’.


Implementação

Event.add(window, 'load', function() {
// enclosed implementation here
});

Com isso, sua interface ganha em performance e em usabilidade.

O preenchimento dos campos.

Interface

var Dom = {
get: function(el) {
if (typeof el === 'string') {
return document.getElementById(el);
} else {
return el;
}
},
add: function(el, dest) {
var el = this.get(el);
var dest = this.get(dest);
dest.appendChild(el);
},
remove: function(el) {
var el = this.get(el);
el.parentNode.removeChild(el);
}
};
var Event = {
add: function() {
if (window.addEventListener) {
return function(el, type, fn) {
Dom.get(el).addEventListener(type, fn, false);
};
} else if (window.attachEvent) {
return function(el, type, fn) {
var f = function() {
fn.call(Dom.get(el), window.event);
};
Dom.get(el).attachEvent('on' + type, f);
};
}
}()
};

Implementação

Event.add(window, 'load', function() {
var i = 0;
Event.add('add-element', 'click', function() {
var el = document.createElement('p');
el.innerHTML = 'Remove This Element (' + ++i + ')';
Dom.add(el, 'content');
Event.add(el, 'click', function(e) {
Dom.remove(this);
});
});
});

Como utilizar um quadro em Scrum?

Esse vídeo da Sovis Sistemas elaborado pelo Jordano Gonzatto apresenta como a estrutura de um quadro organizado em timebox pode ser utilizado para um gerenciamento de negócios com Scrum.

Conheça, também, o trabalho desenvolvido pelo Bluesoft aqui.

Livros recomandados para seu sucesso profissional

Os 7 hábitos de pessoas altamente eficazes - Stephen R. Covey

Casais inteligentes enriquecem juntos - Gustavo Cerbasi

Investimentos inteligentes - Gustavo Cerbasi

Superdicas para se tornar um verdadeiro líder - Paulo Gaudêncio

Superdicas para vender e negociar bem - Carlos Alberto Júlio

Como se tornar um líder servidor - James Hunter

A estratégia do Oceano Azul - W. Chan Kim e Renée Mauborgne

A lógica do Cisne Negro - Nassim Nicholas

Não há "bala de prata"

Autor/fonte: Tradução: Christian Reis; Adaptação: Helio Bentzen

Este texto foi baseado no artigo Brooks, 1986, “No Silver Bullet: essence and accidents of software engineering” que afirma não haver um avanço tecnológico que gere uma melhora na produtividade, simplicidade e confiabilidade da construção de software. Apontam-se, ainda, alguns caminhos promissores em desenvolvimento.

Introdução

Há, ainda, hoje, grande discussão em torno de como melhorar a produtividade na construção de sistemas complexos. Há duas partes bastante distintas que constituem as atividades relacionadas ao desenvolvimento do software: atividades essenciais, que envolvem a criação de um modelo conceitual para o sistema, e atividades acidentais, que envolvem a própria implementação do sistema em um programa. O objeto deste artigo é defender que avanços significativos conquistados até hoje foram promovidos em cima das questões acidentais do software, e que ganhos da mesma proporção no desenvolvimento das atividades essenciais são muito mais difíceis de serem alcançados.

Desenvolver softwares é uma difícil tarefa?

A própria natureza do software torna improvável que haja uma solução mágica para os problemas no desenvolvimento de sistemas, como ocorrido na integração eletrônica para a construção de hardwares complexos. Não é que o software evolui muito lentamente; na realidade, o hardware é que evolui muito rapidamente; não há paralelos tecnológicos no mundo com a velocidade da inovação em hardware.

Analisando os pontos inerentes à essência dos problemas no desenvolvimento de software, há os seguintes pontos particulares:

. Complexidade: Há poucos elementos repetitivos e idênticos, e fazer crescer o software envolve muito trabalho além de agregar ou repetir componentes menores. Não há crescimento linear para o software;

. Conformidade: Não há conforto em um princípio unificado. O software, por ser uma criação muito recente, precisa ser adaptado a todo tipo de instituição e sistema já existente;

. Adaptabilidade: Por poder ser alterado muito facilmente, o software sofre pressão por mudança e alteração constante;

. Invisibilidade: O software não é espacialmente representável: não existe um diagrama ou esquema lógico que o descreva. São necessárias muitas representações para conseguir um entendimento visual do sistema.

Conquistas passadas resolvem problemas acidentais

Passando pelas conquistas do passado que promoveram melhoras de produtividade na criação do software, temos:

. Linguagem de alto nível: Embora realmente muito importante na melhora de produtividade, este avanço só tem impacto sobre a complexidade acidental, e não no problema em si;

. Time-sharing: Sistemas modernos resolveram o problema de turnaround que realmente existia com os sistemas de processamento Batch. No entanto, este problema não faz parte do problema essencial ao desenvolvimento de software;

. Ambientes unificados: Bibliotecas integradas e formatos de arquivos unificados fazem, na prática, ser possível integrar estruturas conceituais cujo projeto já previa esta integração, de forma que não resolveram nenhum problema essencial ao trabalho de construir um sistema de software.

Proposições de soluções mágicas:

. Linguagens de alto nível: Não atacam a essência do problema, embora realmente ajudem o desenvolvedor a desenvolver técnicas novas de projetar o sistema;

. Orientação a objetos: Resolvem questões acidentais provendo tipos abstratos de dados e uma hierarquia de tipos. No entanto, não resolvem questões relacionadas à análise ou projeto de software;

. Inteligência artificial: segundo Parnas, O uso de IA não é uma bala de prata, pelo simples fato de resolver problemas muito específicos, e requerer trabalho e criatividade para permitir aplicar uma solução a novas questões;

. Programação automática: Até hoje não se viu algo que passe uma especificação diretamente para código; em geral, se existem, tem aplicação muito específica;

. Programação gráfica: Embora muito de faça analogia com procedimentos gráficos para desenvolver hardware, resta a dificuldade sempre de se visualizar a estrutura conceitual que representa o software. O uso de muitos diagramas é necessário, e isto reduz a eficiência e compreensão da visualização;

. Verificação de programas: Embora realmente tenha impacto sobre teste e validação do software criado, tem alto custo de aplicação, e não resolve o problema da especificação incorreta ou imprecisa;

. Ambientes e ferramentas: O retorno destes avanços será sempre marginal, porque apóia o acidental através de mecanismos de validação de sintaxe e semântica, e apoio a memória do desenvolvedor;

. Workstations: Edição e composição já são adequadamente suportadas pelas velocidades atuais de computadores. A compilação já não é um gargalo significativo ao processo de desenvolvimento.

Ataques promissores à essência do problema

A tarefa é objetiva, melhorar o desenvolvimento de software deve-se atacar os aspectos essenciais do software.

Utilizar componentes prontos

Uma solução boa para a construção é justamente não construí-lo; há já disponíveis grandes quantidades de componentes prontos, tornando muito mais rápido e barato desenvolver. Custos baixos de hardware e a aplicação geral da computação têm levado os usuários a requererem menos soluções customizadas para seus problemas, de forma que software padronizado passa a ser uma alternativa.

Refinar requisitos e prototipação rápida

A tarefa mais difícil é sempre decidir o que construir. Uma técnica excelente para resolver o problema é extrair e refinar iterativamente a funcionalidade do sistema; permitem que os requisitos evoluam, o que é muito mais natural do que forçar os clientes a especificarem sozinhos.

Desenvolvimento incremental

A forma mais natural de se desenvolver é justamente criar um esqueleto inicialmente desprovido de funcionalidade, e adicionar esta funcionalidade incrementalmente. Esta técnica se aplica bem tanto a projetos pequenos quanto a projetos grandes.

Ter bons projetistas

A grande questão de melhorar o processo de desenvolvimento envolve melhorar a qualidade do pessoal atribuído as atividades de desenvolvimento. Bons desenvolvedores e gerentes são raros, mas são o ponto único de maior impacto na produtividade de uma equipe de desenvolvimento.

Bibliografia

Brooks, F. P. (1986), No silver bullet: essence and accidents of software engineering, in H. Kugler, ed., “`Information Processing 86”', Elsevier Science (North Holland), pp. 1069-1076.

Parnas, D. (1985), “Software aspects of strategic defense systems”, Communications of the ACM 28(12), 1326-1335.