Encomendei o bolo e os salgadinhos, mas quando fui buscar, tive um pequeno probleminha: na loja não havia velas com formato de números. Só havia velas simples.

Colocar uma única velinha estava fora de cogitação. Então pensei inicialmente em comprar a quantidade de velas equivalentes a idade da pessoa. Mas como a pessoa tinha a idade maior que 20, achei que seria um exagero de velas em cima do bolo.

Daí me veio a seguinte idéia nerd: Porque não utilizar um sequência de velinhas acessas e apagadas representando a idade em formato binário ao invés de decimal. Como a idade era menor que 32, logo percebi que bastavam 5 velinhas para representá-la. Ao invés de mais de 20 como na primeira idéia.

O bolo e a sequência de velinhas ficaram organizados como na figura abaixo:

A vela acessa representa o número 1 (um) e a vela apagada representa o número 0 (zero). A sequência de velas portanto representa o número 11001 (um, um, zero, zero, um). Meio esquisito a princípio mais é isso mesmo que você leu. O cumprimento ao aniversariante fica: “Parabéns pelos seus um, um, zero, zero, um anos de idade.”

Obs.: Antes do aniversariante soprar as velinhas eu tive que explicar um pouco sobre os números binários. A estratégia foi bem aceita. Ufa!

Agora tentem adivinhar que idade esse número binário representa em decimal. Se tiver pressa digite no google a seguinte expressão: 0b11001 in decimal e aperte enter, ou simplesmente clique no link anterior.

Grande abraço.

O texto original foi escrito por por Dan Wohlbruck e você pode encontrar aqui.

Aconteceu em 1928 no mês de setembro

Dan Wohlbruck acrescenta à sua série: “Quando isso aconteceu?” Ensaios sobre a história do primeiro robô de aparência humana. Ele relata, de forma surpreendentemente, que “Eric foi uma substituição simples e bem sucedida para o Duque de York.”

Em 20 de setembro de 1928, Eric, o primeiro robô de aparência humana, abriu a Exposição da Sociedade de Engenheiros modeladores em Londres(Society of Model Engineers). Capitão William Richards, um jornalista e veterano da Primeira Guerra Mundial, e AH Reffell, um engenheiro, foram os inventores. Capitão Richards se inspirou para construir Eric quando o Duque de York, que foi convidado para abrir a exposição, não pôde comparecer à cerimônia. A apresentação de Eric é descrita no site cyberneticzoo.com desta maneira:

“Eric se levantou, inclinou a cabeça, olhou para a direita, à esquerda, e, com gestos apropriados, deu um discurso de abertura de quatro minutos.”

Eric foi feito de alumínio e pesava aproximadamente 63kg. Os movimentos de Eric eram produzidos por pequenos motores elétricos e seus olhos eram lâmpadas elétricas. A voz de Eric foi enviada por transmissão de rádio sem fio e emitida através de uma caixa de som na boca. Eric não conseguia pensar e ele não tinha nenhuma capacidade computacional. Eric foi uma substituição simples e bem sucedida para o Duque de York.

(Eric pode ser visto aqui.)

Outros Robôs Pioneiros

Eric não foi a primeira máquina de aparência humana já projetada, no entanto. Ninguém além de Leonardo da Vinci, usou como tema: robôs. Em 1957, um pesquisador italiano, olhando através de documentos de da Vinci, descobriram um modelo de um cavaleiro mecânico. O projeto incluia diagramas engrenagens e motores para dar poder ao guerreiro. Em 2002, por um documentário da BBC, o robô de Leonardo da Vinci foi construído.

Na sequência do robô Eric, houve uma série de outros robôs com aparência humana, mas não muitas máquinas humanas de trabalho. Durante a Segunda Guerra Mundial, no entanto, foi iniciado um trabalho sério para fazer substituições humana. Em 1943, Warren McCulloch e Walter Pitts, produziram trabalhos pioneiros em redes neurais. Em 1946, George Devol inventou um dispositivo que controlava máquinas utilizando registos magnéticos; e em 1948, Norbert Wiener, então no MIT, publicou o livro cujo título cunhou o termo Cibernética. Também em 1948, um inventor pouco conhecido chamado William Grey Walter construiu duas tartarugas mecânicas chamadas Elmer e Elsie, que realmente pareciam, moviam-se, e agiam como tartarugas.

Em 1956, em uma conferência em Dartmouth, Marvin Minsky e John McCarthy inventou o termo inteligência artificial para descrever máquinas pensantes.

De Elmer e Elsie, avançamos para 1961, quando o primeiro robô industrial foi trabalhar carregando carcaças e com auto-solda na linha de montagem da General Motors. O braço robótico, chamado Unimate, pesava cerca de 1 814kg e executava instruções armazenadas em um cilindro magnético. Unimate foi a criação de Devol e Joseph Engelberger, que fundou a empresa Unimation. Até o momento, Unimate é o mais bem sucedido de todos os robôs industriais.

Em 1973, o foco do desenvolvimento da robótica havia se mudado da Grã-Bretanha, através os EUA, para o Japão, onde a universidade Waseda demonstrou Wabot-1. Wabot-1 foi o primeiro robô em escala antropomórfica construído no mundo. Tinha sistemas separados para o controle dos membros, visão e comunicação. O Wabot-1 falava japonês e usava ​​orelhas artificiais, olhos e uma boca artificial. O Wabot-1 andou com as pernas e segurou com as mãos que possuiam sensores táteis.

Um inseto mecânico de 180kg

A corrida segue adiante. Em março de 1982, Odetics, Inc. de Anaheim, Califórnia, introduziu o ODEX I e até criou uma nova palavra para descrever a máquina: funcionoide. ODEX I caminhou com seis pernas e pesava menos de 180kg. Odetics disse que ODEX I demonstrou atributos exclusivos para “robôs móveis”. Em uma reportagem sobre o funcionoide, A revista “Robotics Age” escreveu, ” Odetics destina-se a ser o primeiro funcionoide a fazer parte de uma nova era na indústria da robótica em que uma unidade multifuncional pode literalmente caminhar pela fábrica e atuar em praticamente qualquer lugar. ”

Para não ficar para trás, em 1986, a Honda apresentou o primeiro modelo do seu robô ASIMO. ASIMO é um pouco menor do que um adulto médio, e em 2005 ele tinha 34 graus de liberdade de circulação (três na cabeça, sete em cada braço, dois em cada mão, um no tórax, seis em cada perna).

Apesar de terem aparência humana, ou mesmo de realizarem ações humanas, o robô só atinge o objetivo de substituir os seres humanos nos filmes e na ficção científica. Em 1940 e 1941, Isaac Asimov começou sua série de romances e contos sobre robôs. Então, em 1950, ele publicou o livro Eu, Robô, que é uma coleção de muitos de seus contos. Foi em um desses contos que Asimov introduziu suas famosas três leis da robótica. Os livros de Asimov inspirou os personagens marcantes de Star Wars: C3P0 e R2D2.

No livro de Asimov: “A Fundação e a Terra”, o robô Daneel é encontrado vivo na lua. Ele já existe há 20 mil anos e admite que foi gentilmente orientar o progresso da galáxia e que respeita as Leis da Robótica.

O desafio da construção de máquinas para substituir os humanos ainda não acabou. Ele começou há mais de 80 anos atrás, com Eric, o robô, e foi “quando isso aconteceu”.

É importante não generalizar a linguagem Ruby como se fosse algo que resolverá todos os seus problemas. Ela tem propósito geral, mas será adequada em determinados contexto e outros não, como todas as outras linguagens. O propósito desse post do Kate Cunningham que eu traduzi é mostrar que as características do Ruby são muito harmônicas com as características necessárias em um ambiente efetivo de aprendizado. Isso não quer dizer que o aluno deva estacionar no Ruby. Ele terá o caminho facilitado para o mundo da programação com Ruby, mas isso será só o primeiro passo. Ele deverá sim, aprender outras linguagens, pois é a única forma de se aprimorar como profissional de uma área tão dinâmica. O texto original você encontra aqui. Fique agora com a tradução:

A linguagem Ruby tem recebido muita atenção na última década, especialmente com o advento do Ruby on Rails em 2005. Enquanto a blogosfera está utilizando Ruby a muito tempo, vamos nos perguntar como, exatamente, a linguagem Ruby é propícia para um ambiente educacional.

Copyright (C) 2008 Ruby Association LLC

Claro, podemos ir para a relevância da linguagem Ruby, pois se você está recebendo treinamento em um ambiente educacional para se tornar um programador de computador, e você não sabe o Ruby, então você está ficando cada vez mais fora do circuito. No entanto, linguagens de programação vêm e vão, e educação não é sobre as tendências, é sobre as idéias que sustentam o valor no decorrer dos anos.

Vamos então olhar para a filosofia de linguagem Ruby e ver como é propício à aprendizagem. Por um lado, Ruby é flexível. Ele não tem a rigidez de Java ou PHP. Em um ambiente que maximiza o aprendizado, a flexibilidade é fundamental. E Ruby é tão flexível quanto possível. Yukihiro Matsumoto, o  criador da linguagem Ruby, notou o que ele estava pensando quando ele começou a trabalhar com linguagem de programação: “É engraçado, quando eu usei PHP para desenvolver ou as coisas que eu fiz em Java, eu estava sempre à procura de algo mais.”

Outra grande coisa sobre Ruby é seu reforço da capacidade para a criatividade. Como muitos programadores Ruby notaram, Ruby é mais alinhado com o pensamento humano. Desta forma, é muito fácil de usar. E precisamente porque é mais fácil de usar, é mais versátil quando se trata de ser criativo.

A apresentação de slides sobre a linguagem Ruby explica como Ruby auxilia a criatividade. Afirma que os seres humanos perdem produtividade quando são forçados por “tarefas repetitivas, tarefas desnecessariamente complexas  e resolvendo problemas que não estão dentro do domínio de aplicação.” Desde que Ruby efetivamente se livra dessas tarefas repetitivas e de tarefas voltadas para máquinas, há mais espaço aberto para ser criativo. Com os alunos, especialmente, a produção criativa é a chave para a aprendizagem de forma eficaz.

Um aspecto do processo de aprendizagem que é absolutamente crítico para a eficácia educacional é diversão. Nós geralmente não pensamos sobre a diversão quando nós pensamos sobre a educação. Mas reflita sobre seus próprios anos escolares no passado. Se você pensar bem, você percebe que os assuntos que você aprendeu mais e reteve o conteúdo eram aqueles em que você estava se divertindo. Este divertimento, claro, resulta em parte da criatividade. Quando você está sendo produtivo, você está se divertindo.

Ao contrário de outras linguagens de programação, você pode fazer muita coisa com Ruby, mesmo se você está apenas nos estágios iniciais de aprendizagem. Para os estudantes, o processo de aprendizagem é frustrante e é um pouco prejudicado quando pequenos erros aparecem no caminho de chegar aos conceitos maiores. Linguagens de programação como C++ podem dificultar o aprendizado dos conceitos maiores porque pequenos erros no código sempre aparecem durante o processo. Já usando o  Ruby o aluno não passa por essas pequenas dificuldades quando está iniciando o aprendizado.

Naturalmente, estes são apenas indicações básicas de que Ruby é a melhor ferramenta de aprendizagem para os interessados em programação de computadores, especialmente os iniciantes. No entanto, assim como na educação como um todo, em que mudanças conceituais básicas no processo de aprendizagem levam os alunos para as melhores práticas na aprendizagem,  Ruby oferece a possibilidade de uma aprendizagem fácil, divertida, criativa, por força da simples virtude de que a linguagem foi feita para pragmaticamente funcionar dessa forma. Em análise final, Ruby foi feito para estudantes, jovens e idosos, iniciantes e mais avançados.

Por Kate Cunningham

O ponto chave é que não dá mais para ficar somente na frente do computador (nerd 1.0). Agora o Nerd tem que ser sociável, tem que equilibrar seu gosto por tecnologia com seus relacionamentos interpessoais, seja com amigos, trabalho ou o que for (Nerd 2.0).

A tecnologia é importante sim, mas ela deve estar sempre em função das pessoas e nunca o contrário.

Durante o OxenteRails 2010, uma das booth babes me falou que se surpreendeu com os participantes, pois eles não se isolavam. Sempre tinha alguém para tirar alguma dúvida com elas, para pedir para colocar os postits no quadro de feedback, para chamar para jogar video game junto com eles, para tirar fotos, ou seja, estavam sempre interagindo. Ela complementou que a idéia distorcida que ela tinha do nerd anti-social mudou completamente.

Outro depoimento foi da representante do SEBRAE que chegou no evento e imaginou: Como é que eu vou fazer para explicar os recursos que posso oferecer num local que só tem nerd? Mas o tempo foi passando e logo
ela detectou que ali tinha consultores, professores, desenvolvedores, ou seja, Nerds sociáveis e produtivos.

A própria estrutura do evento foi organizada para facilitar interações entre indivíduos. O Ignite OxenteRais que começou na quinta-feira é um ótimo exemplo disso. O Ignite é um mini evento informal em que as pessoas palestravam durante 5 minutos, trocavam idéias e faziam amizades. Nos dias 6 e 7 de agosto, no final da programação oficial, os participantes se reuniam em algum barzinho da cidade, esse outro mini evento se chama #horaextra.

Alguns dos nerds 2.0 que estavam no Oxente Rails tinham inclusive vocações artísticas. Nesse quesito eu cito o Cukier que recebeu o prêmio da mais bela voz, com o Forró do Elomar e também a Banda Plataformatec fazendo uma performance com vocal e guitarra em um jogo do playstation.

Cito agora o Henrique Bastos: Esse ambiente de confraternização permite ir além do que ampliar a rede de contatos. Permite a criação de uma rede de confiança, que é muito mais significativo para a comunidade e para cada participante.

Um conjunto de idéias bem significativas que representa essa nova visão você pode encontrar no Manifesto Pequenas Ações (Small Acts), com o slogan: Pequenas ações fazem grandes revoluções.  Qualquer um pode se cadastrar e se associar a esse manifesto.

Não podia deixar de colocar aqui outro ponto: A participação feminina no evento. Apesar da grande maioria serem homens, tivemos Cecilia Fernandes palestrando sobre metodologias ágeis,  Tahis Camilo que mostrou o dia-a-dia do seu trabalho na Hashrocket e por fim, a Gleide, que palestrou sobre Ti Verde na desconferência. Portanto o Nerd 2.0 não pode mais dizer que tecnologia é coisa de homem. As mulheres, apesar de estarem em pequeno número, mandaram bem!

E então? Tá esperando o que?

Se você anda passando tempo demais no computador e se esquece da importância da socialização (Nerd 1.0)  fica aqui o alerta: Faça um Git Clone desse novo formato de ver o mundo da tecnologia e atualize a sua visão Nerd para a versão 2.0.

Bônus: Se você ainda tem um pouco de dificuldade de fazer o upgrade para a versão Nerd 2.0, não entre em pânico. Essa mudança pode ser feita de forma gradual. Portanto, se essa idéia fez com que você se preocupasse, tente descontrair um pouco. Para isso, acesse Fuças – a revista de fofocas nerd criada pela comunidade do Piauí. Outro site que vai te ajudar a se descontrair e ganhar confiança para o upgrade é o site de tirinhas nerd: nerdson.

Bônus 2: Não deixem de acessar também o post criado por Alexandre Gomes:  Manifesto 2.0

Quem tiver algum depoimento a respeito desse tema pode deixar seu comentário aqui.

Um abraço e até o próximo Papo de Nerd!

Esse mini-livro é uma jornada linha a linha, teste por teste, utilizando a técnica do Desenvolvimento Orientado a Comportamento (Behavior Driven Development) em um projeto muito interessante: Simulação dos dados do jogo War!

Eu escrevi esse pequeno livro para aprender BDD e RSpec, por isso eu tinha que falar sobre algo simples e de preferência que fosse divertido. Então eu pensei: Por que não jogar dados! Porque não jogar dados do jogo War!
Então aqui está: Aprenda BDD jogando dados!

A aplicação que nós criaremos juntos usa duas classes: Dice e WarDice. No primeiro capítulo eu construo o arquivo RSpec da classe Dice e a classe Dice simultaneamente e passo a passo até todos os testes tornarem-se verdes.

No segundo capítulo eu continuo o desenvolvimento com a classe WarDice, aquela que fará a simulação de cada dado do jogo war!

Finalmente, no terceiro capítulo eu uso as classes criadas em uma divertida aplicação feita em shoes. A filosofia desse livro é aprender fazendo coisas divertidas. Em uma palavra: Experimentação.

Então eu espero que você aproveite esse livro simples mas também muito instrutivo. Os testes usados nesse livro não são uma solução definitiva. Eles são somente possibilidades no meio de outras. Como eu disse, eu o escrevi para aprender RSpec. Você pode enviar sugestões, clonar o projeto, modificá-lo e codificá-lo de outra forma. Quem sabe não faremos juntos a versão 2.0 desse livro .

Fique agora com o livro:

O código fonte completo da aplicação você pode baixar em:
http://github.com/valeriofarias/shoes-war-dice

O texto completo do livro e o código fonte do gerador de livros você pode baixar em:
http://github.com/valeriofarias/learn-bdd-playing-dice-book

se preferir pode também baixar a versão em inglês do livro:
http://valeriofarias.com/learn-bdd-playing-dice-ebook/

I wrote this tiny book to learn BDD and RSpec for myself. I would want to start with a little example. And if was possible with a funny example too. Then I thought: Why not playing dice! Why not playing war dice! Then there you are: Learning BDD playing dice!

The app that we’ll create together uses two classes: Dice and WarDice.

The first chapter I start to construct the RSpec file of Dice class and the Dice class simultaneously and step by step until all of the tests become green.

The second chapter I go on with the WarDice class, that is a simulation of each dice of war game!

Finally, the third chapter I use the classes in a funny shoes application.

The philosophy of this book is to learn making funny things. In one word: Experimentation. Then I hope you enjoy this simple but also instructive book.

The tests used in this book aren’t a silver bullet. They are only a way between some others. How I told, I made to learn RSpec. You can send suggests, clone the project, modify it and codify in other ways. Who knows we’ll playing together in the 2.0 version of this book .

Now just read the book and have fun!

The complete source code of application you can download in
http://github.com/valeriofarias/shoes-war-dice/tree

The complete ebook text and source code you can download in:
http://github.com/valeriofarias/learn-bdd-playing-dice-book

Eu me inspirei bastante no trabalho da equipe do Acesso Digital, que divulgou a algum tempo atrás o slogan “Acessibilidade de Verdade”, que é a soma de Acessibilidade, padrões web e usabilidade.

Na monografia eu amplio mais essa idéia criando a seguinte fórmula didática:

Recursos = (Arquitetura da Informação + Padrões Web + Acessibilidade + Usabilidade + Acompanhamento de Tendências )

Acessibilidade de Verdade = Recursos + Foco no Usuário + Bom senso

Cada tópico da “fórmula” é aprofundado.  Além disso,  eu complemento a monografia com um estudo de caso que mostra minha experiência na construção das várias versões do Portal UERN e também com uma entrevista e um pequeno teste de usabilidade com um usuário que acessa a interface via JAWS.

Entenda a palavra fórmula como um recurso didático para criar uma sensação de unidade entre áreas tão diversificadas presentes no desenvolvimento Web. Não é receita de bolo. Repito, é só um recurso didático para facilitar a compreensão.

O texto está sobre licensa Creative Commons, que permite você fazer o que quiser com ele, só precisa citar o autor.

Fique à vontade para ler, divulgar, modificar, baixar o texto.

Espero que goste e assim que você ler, deixe sua opinião sobre o que você achou do conteúdo abordado.

Um abraço e fique com o texto:

Quem vem linguagens como C, Java, Delphi, C# e usa a linguagem Ruby pela primeira vez, tende a programar em Ruby do mesmo jeito que programava na linguagem que já era fluente. Lendo o post abaixo você perceberá que linguagens que tem características  funcionais, como o Ruby, possibilitam formas próprias de organizar o código (Jeito Ruby) , mais especificamente nesse texto, escrito por Jon Dahl, você verá as formas mais eficientes de fazer iterações (loops) em Ruby. A versão original você encontra aqui. Fique agora com a tradução:

Se você é um programador, você provavelmente já trabalhou com um ou mais livros que te ensinava a sintaxe de uma nova linguagem. Eu tive essa experiência com uma meia dúzia de linguagens, como C, Javascript e Perl.
Estes livros tipicamente introduzem loops no meio da discussão de sintaxe, depois de tipos de dados e controle de fluxo, mas antes de I/O e de recursos avançados.

Loops são quase sempre apresentadas de acordo com esta fórmula:

Texto introdutório: “E se você quiser fazer uma operação mais de uma vez”?
Introduz o loop while, mostrando a diferença entre do while e while do.
Apresenta o laço for, o primo louco do while.

(Bonus) Introduz o laço foreach se a linguagem é suficientemente de alto nível. E é isso – você sabe como fazer um loop através de código e é hora de seguir em frente.

Não tão rápido. Se você for sortudo o bastante para usar uma linguagem que possui traços de programação funcional, você não deve usar um laço dessa maneira.

O ponto
De agora em diante, eu vou usar Ruby para exemplos, mas este artigo não é sobre Ruby. É sobre a transição de loops primitivos para iterar usando coleções, e sobre a transição de funções genéricas (como each) para funções mais específicas (como map).

De loops para métodos que percorrem a própria lista
Durante os últimos meses, estive trabalhando no Tumblon, uma aplicação Rails de porte médio. Eu trabalhei em 15-20 aplicações Ruby nos últimos três anos, provavelmente, totalizando 50.000 linhas de código Ruby.

Eu só usei um laço primitivo uma vez.

Esse laço primitivo era um loop{} loop, sempre percorrer uma lista tarefas à procura do que executar. Em outras palavras, um laço sem nenhuma condição de saída além de ^C, ou uma falha do servidor.

Eu só usei um loop simples em um caso porque o conceito each geralmente é uma opção melhor. Essa implementação Ruby será familiar para quem já viu código Ruby antes:

["horse", "pig", "cow"].each  do |animal|
puts "Old MacDonald has a #{animal}"
end

(Sim, eu tenho uma criança pequena.)

Isto é muito mais enxuto do que as alternativas usando for e while. Ele representa melhor o que estamos fazendo: não estamos iterando com uma condição de saída, estamos interagindo entre os elementos de uma matriz. Mas e se você quiser fazer algo um número fixo de vezes? Você pode interpretar isso como percorrer a seguinte lista: [1,2,3,4,5,6,7,8,9,10].each{}. Mas claro que Ruby dispõe de uma versão mais simples para isso: 10.times{}.

Portanto, se seu loop rodar através de uma lista de algum tipo, each é a melhor abstração para esse tipo de problema. E, na minha experiência de construção de aplicações Ruby, a maioria dos loops percorrem listas. Parsing XML? Iterando por uma lista. Somando números? Iterando por uma lista. Leitura em um arquivo texto? Lendo o STDIN? Trabalhando com linhas em um banco de dados? Iterando por uma lista. Isso é o que o loop each faz bem.

Além do arr.each
Mas each não é a palavra final. É um passo acima das primitivas for ou while quando trabalha com o conjunto de valores, mas muitos loops each devem ser substituídos por outros métodos de array, como map, inject e select.

Quando each é útil? Simples: quando você quiser criar efeitos externos ao array, como salvar no banco de dados, imprimir um resultado na tela, ou enviar uma chamada de serviço web. Nestes casos, você não está preocupado com o valor de retorno; você deseja alterar o estado na tela, o disco, o banco de dados, ou outra coisa. Dê uma olhada neste código.

User.find(:all).each do |user|
Notification.deliver_email_newsletter(user)
end

Você não necessita que o código acima retorne valor, você só precisa que o e-mail seja entregue.

Mas não use each se você quer extrair algum valor novo de um array. Em vez disso, dê uma olhada em outros três métodos poderosos: map, inject e select.

Para entender vamos analisar o código abaixo que itera por um array e cria um novo array com elementos que correspondem a determinada condição, usando each.

active_users = []
users.each do |user|
active_users << user if user.active?
end
active_users

A primeira e última linhas são feias. Por que você tem que inicializar e retornar active_users? Resposta: porque este é um abuso (má utilização) do método each. Nesse caso é muito melhor você usar select (ou seu equivalente, find_all):

users.select do |user|
user.active?
end

Usando select o código fica menor, mais fácil de entender e menos propenso a erros. E mais importante, ele claramente encapsula um uso comum de each (e looping em geral).

Duas outras funções-chave: map e inject (ou reduce) – complementam select e seguem um padrão semelhante. E não é de surpreender que eles formam a base do paradigma mapreduce para processamento distribuído. Eu escrevi mais sobre map e reduce em outro artigo, e aqui é um atalho para saber quando usar essas funções:

Resumo
Use each para mudar o estado. Caso contrário use métodos funcionais de matriz que retorna um valor. Dessa forma seu código ficará mais limpo e menos propenso a falhas.

Aprendendo a refatorar

1. Inicializar um valor vazio, ou matriz, ou o que quiser (new_arr = [])
2. arr.each, alterando o valor inicializado
3. Devolver o valor (return new_arr)

Sempre que você detectar esse padrão, você sabe que existe um laço each que precisa ser substituído.

Visitei a  primeira loja mas não consegui efetuar a compra, porque ela só fazia entrega de 8h às 12h e de 14h às 18h, ou seja, eu precisaria faltar o trabalho para poder receber esses garrafões d’água, ou então, esperar até o fim de semana (mais 4 dias sem água).

Devido esse problema de incompatibilidade de horários com o primeiro vendedor, fui em busca de um segundo vendedor.

Cheguei no local e fiz a encomenda dos três garrafões. A marca da água mineral era nova no mercado local. A vendedora falou que a água era muito boa, de ótima qualidade. Daí começou a discussão:

Valério diz:
Minha senhora, não me leve a mal, mas quem decide se a água é boa ou ruim sou eu.

vendedora diz:
olha, mas eu tenho que dizer que é boa, pois estou te vendendo.

Valério diz:
entendo seu lado, mas insisto que independente do que você disser quem vai decidir se é boa ou não sou eu, depois que provar a água.

vendedora diz:
Olhe o seguinte exemplo: o meu filho tem esse carro que faz entrega. Se ele for vender o carro, você acha que ele iria dizer que o carro é ruim? Claro que ele tem que dizer que o carro é bom.

Valério diz:
minha senhora, ele poderia dizer o que ele quiser mas eu só iria tomar a decisão de comprar depois que testasse o carro e constatasse que ele realmente estava em bom estado.

vendedora diz:
você trabalha em que?

Valério diz:
trabalho na área de informática, criando programas de computador.

vendedora diz:
quando você vai vender seu produto, você não diz que ele é bom não?

Valério diz:
Quando vou vender meu produto eu dou minhas referências, mostro os clientes que já estão usando, caso seja um programa já pronto. Caso seja um software novo eu crio protótipos e pergunto ao cliente se é isso que ele quer, ou seja, se está bom. Se ele me responder que falta algo eu complemento para obter finalmente a resposta: está bom! Essa resposta tem que vir dele, não de mim.

A conversa terminou por aí. Não sei se ela compreendeu o que eu estava falando, mas mesmo não concordando com os argumentos dela não desistir da compra, já que água é necessidade básica . Se o objetivo dela era me persuadir, funcionaria muito melhor os seguintes argumentos:

• essa é uma água nova no mercado local, mas ela é uma das mais vendidas na capital.
• a fonte dessa água pelas pesquisas se aproxima bastante em qualidade da água X que domina o mercado local.
• Ou mesmo algo mais simples como: Olha, eu gostei bastante dela e várias pessoas que conheço gostaram, mas gostaria que você testasse e me confirmasse se ela é de sua preferência.

Acho que o titulo desse post ficou bem claro agora. Se quisermos criar relações de confiança e respeito com nossos clientes (fidelizar). É preciso fornecer meios para que o cliente tome a decisão final, orientando, contando exemplos, fornecendo referências de outras pessoas que usam o produto e deixar sempre o cliente livre para decidir se quer ou não, se gosta ou não.

Um abraço e até o proximo post.

São 94 botões no total. Em um dos meus aplicativos eu cheguei a usar 41 desse botões.  Mas aproveitando a atualização eu resolvi dar uma enxugada na quantidade de botões, pois pode-se facilmente perceber que a maioria quase nunca é utilizado. Depois de uma breve análisa das funcionalidades refiz a configuração da barra para o formato a seguir:

• Não permitir sublinhado para não deixar os usuário cairem em mal costume de sublinhar o texto além do necessário.
• Fiz questão de deixar de fora as barras de alinhamento, pois o padrão de alinhamento que utilizo nos meus aplicativos é à esquerda. 
• A seção de list box com formatação eu preferi não utilizar já que os tamanhos e cores são padronizados.  É possível que eu habilite no futuro o item styles, mas para isso os usuários tem que compreender que ele estará aplicando uma formatação predefinida.
• a seção copiar, colar achei desnecessária, pois geralmente os usuários usam o ctrl+c e ctrl+v mesmo. Deixo claro para eles que copiem do word para o bloco de notas para eliminar o “lixo” (caracteres de formatação), depois é só copiar o conteúdo do bloco de notas, sem nenhuma formatação e colar no editor.
• A seção de links e imagens não tenho o que comentar pois é imprescindível. 
• Achei interessante deixar como complemento os botões de subscrito e sobrescrito para eventuais necessidades, bem como o de inserir símbolos.
• Na penútima seção eu deixo a régua para divisão de seções, a tabela que é muito útil quando usada de forma apropriada, um botão que remove a formatação eu acho bastante interessante para evitar que o usuário comum tenha que acessar o código HTML fazer a mudança e finalmente o editor de HTML que é imprescindível já que tem coisas que só podem ser “resolvidas na unha mesmo”.
• Finalizo a barra no canto direito com o botão de preview para ter uma noção de como o texto ficará. 

O resultado é uma barra super enxuta e o script de configuração você pode ver abaixo:

tinyMCE.init({
mode : "textareas",
theme : "advanced",
plugins : "table,save,layer,advhr,inlinepopups,advimage,advlink,emotions,iespell,insertdatetime,preview,zoom,flash,searchreplace,print,paste,directionality,fullscreen,noneditable,contextmenu,wordcount",
theme_advanced_buttons1 : "bold,italic, strikethrough,|,bullist,numlist,|,undo,redo,|,link,unlink,anchor,image,|,sub,sup,charmap,|,hr,table,removeformat,code,|,preview",
theme_advanced_buttons2 : "",
theme_advanced_buttons3 : "",
theme_advanced_buttons4 : "",
theme_advanced_toolbar_location : "top",
theme_advanced_toolbar_align : "left",
theme_advanced_statusbar_location : "bottom",
theme_advanced_resizing : true
});

Gostaria de citar 2 plugins em especial que adiciono no script:

1. wordcount – contador de palavras. Tem um sistema de artigos ciêntíficos que gerencio que vai utilizar esse recurso para facilitar a vida do usuário na hora de saber se o texto está dentro do tamanho limite. 
2. inlinepopups – já não aguentava mais a versão antiga abrir uma nova janela popup para cada inclusão de imagem ou link. Esse plugin aumenta bastante a usabilidade

Agora queria saber a sua opinião. Que tipo de editor você usa e porque você escolheu? Quem sabe eu não mude de editor depois do seu argumento!