maluco :: brain dump

Você procura uma solução rápida para traduzir seu site de forma rápida ? Com este código, você pode traduzir rapidamente a informação que você deseja, sem o usuário ter que solicitar a tradução por exemplo.

Esta biblioteca em Javascript encapsula o /Google Translator API/ e trabalha tanto no navegador como no servidor, como a Node.JS.

Mais informações em http://maraksquires.com/translate.js/.

Veja um código:

var sys = require('sys');
var colors = require('./colors'); // colors are fun!
var translate = require('./translate');

// note: the translator is  English=>Spanish by default
translate.text('I want tacos please.', function(text){

  sys.puts('I want tacos please.'.red + ' => '.cyan + text.yellow);
  var input = 'Spanish', output = "Japanese";
  translate.text({input:input,output:output}, text, function(text2){

    var input = 'Japanese', output = "English";
    sys.puts(text.yellow + ' => '.cyan + text2.blue);
    translate.text({input:input,output:output}, text, function(text3){

       sys.puts(text2.blue + ' => '.cyan + text3.red);
       sys.puts('English'.red+'=>'+'Spanish'.yellow+'=>'+'Japanese'.blue+'=>'+'English'.red  +'\ntaco request has been normalized. ^_^'.green);
    });
  }); 
});

O conformismo, é um pratica do dia-a-dia. Todo dia estamos aceitando novas ideias sem pensar. Fica aqui o experimento de Asch que é um exemplo clássico.

Veja mais em http://en.wikipedia.org/wiki/Asch_conformity_experiments .

Existe um série de soluções e textos na Internet divulgando resolução de problemas baseado no modelo de concorrência das linguagens Scala e Erlang, porém o que me incomoda profundamente é querer comprar eles a bibliotecas de threads ou estrategias de processos no kernel.

Existe muita coisa "estranha" sendo comentada, como por exemplo comparar um modelo de thread de uma linguagem (ou biblioteca) com um de sistema operacional, o que nada tem haver...

Isto me lembra, aquele velho papo de que fork() duplica o processo e assim você tem todo o trabalho e "gasto" de recursos, pois você esta criando um novo espaço, e aí as pessoas esquecem que os sistemas operacionais modernos tratam o fork() relacionados ao CoW, ou seja.. você realmente vai estar utilizando todo este recurso, como era no Minix, só se você realizar alguma escrita no processo novo....

Mas, voltando ao tópico.. o modelo tradicional mais utilizado para tratar concorrência é baseado em threads, porém existem diferenças significativas entre os sistemas operacionais (a pthread é uma boa tentativa, mas sempre estão tentando as alternativas), principalmente relacionado aos métodos disponíveis.(Para quem tiver interesse, acompanhe este projeto no kernel do Linux).

Neste modelo as tarefas em concorrência são dividas pelo método utilizado de thread disponível pela biblioteca ou sistema operacional, e a principal característica é que todas estas tarefas utilizam um espaço compartilhado na memória.

O primeiro problema é quando duas tarefas tentam incrementar o mesmo objeto na memória compartilhada, ambos irão obter o valor do objeto, incrementar e então armazenar na memória o novo valor, como esta operação não é atômica, você pode ter problemas obtendo uma informação errada deste objeto.

A solução para este problema é a utilização de um sistema de /lock/, no qual um processo na hora de obter o valor, pode setar uma trava no objeto para leitura, porém o problema pode se repetir na hora de setar o lock, e ele ficar eternamente em /lock/ causando um problema conhecido, o /deadlock/.

Existem vários /workarounds/ para estes problemas, porém estes seriam os dois principais problemas encontrados na maioria dos algorítimos e mecanismos disponíveis de thread nos sistemas operacionais e bibliotecas.

O modelo /actor/ foi desenvolvimento em 1973 pela primeira vez, no qual ele tem uma solução alternativa em relação a concorrências para tratar os problemas causados pelo modelo /threading/ e /locking/.

Neste modelo, todos os objetos são atores, que possuem uma caixa de correio. Todas as interações são baseadas em mensagens, no qual vários atores podem trocar mensagem entre eles, e conforme as mensagens vão chegando, elas são executadas no objeto relacionado (FIFO). Isto significa que todas o processo é assíncrono, não há confirmação de execução no mesmo momento e isto pode ser considerado eventualmente consistente.

Outro ponto importante é que não há objetos compartilhados na memória e sim apenas atores, isto significa que não há problemas de acesso simultâneo há um objeto, todos os estados são alterados dependendo das mensagens. Então no caso de uma alteração depender do próprio valor do objeto, você não irá obter problemas, pois a referencia sempre será o status do objeto atual na fila, e não na hora do envio da mensagem por exemplo, dentre outras características.

Existem diferenças de implementação entre as duas linguagens, a Scala oferece mais opções, até mesmo de mensagens sincronizadas no modelo /actor/, porém exige mais cuidado do programador para evitar erros, já no Erlang ela é mais limitada e menos flexível para o programador.

A escolha /trade-off/ na minha opinião para este tipo de linguagem esta muito relacionado a sua necessidade de concorrência, elas se utilizam do mesmo modelo para esta tarefa, porém tem propostas diferentes para o programador, no qual a Scala tenta oferecer mais recursos como linguagem, e a Erlang é mais conservadora em relação a inovações, e na minha opinião é a que melhor cumpre o seu papel.

Inspirado por este modelo, existem bibliotecas como por exemplo para o Python que se chama PARLEY. Recomendo também a leitura de sistemas de filas, como o RabbitMQ que esta também cada vez mais frequente na utilização para suprir este tipo de necessidade.

Uma solução me chamou atenção esta semana na lista da linux-kernel, no qual Edward Allcutt relatou um problema que pode ser comum em ambientes de servidores web, e no mesmo e-mail uma patch para o problema.

Segundo ele, em uma configuração comum de um servidor web PHP, no qual utiliza o mecanismo prefork-MPM do Apache, com o mod_php e um código utilizando memória compartilhada, em uma possível falha que gere uma falha de segmento, pode gerar simultaneamente vários /coredumps/ e isto gerar uma necessidade de escrita de no caso de 10-20 /coredumps/ de até 150-200MB de arquivos, e com isto todo o sistema poderia ficar por alguns minutos sem responder por conta desta demanda.

A solução, foi restringir o número de criação de /coredumps/ simultaneamente.

O principio da ergonomia é estudar o conforto e a adaptação aos objetos e interfaces visando aumentar a produtividade e a satisfação das pessoas, e a usabilidade segundo /Jakob Nielsen/ é a medida de qualidade dos objetos e interfaces acrescidas à utilidade dos mesmos.

A interação entre humano e computador (IHC) é o estudo em relação a usabilidade de software, no qual tem como principal objetivo tornar a utilização da aplicação mais simples e intuitiva possível.

Existem domínios diferentes dentro deste contexto, que podemos dividir pelas competências profundas em atributos humanos ou características de IHC, e podemos dizer que são:

Ergonomia física

São as características humanas anatômicas, antropométricas, fisiológicas e biomecânicas, e como estas se relacionam com a atividade física.

Ergonomia cognitiva

Relacionada com os processos mentais, tais como: percepção, memória, raciocínio e respostas motoras, no geral como estes processos afetam as interações entre pessoas e outros elementos do sistema.

Ergonomia organizacional

É a otimização de sistemas sociotécnicos, incluindo suas estruturas organizacionais, políticas e processos, no qual podemos comentar sobre a comunicação, o gerenciamento de recursos humanos, trabalho em equipe e participativo.

Ergonomia "Design" (ErgoDesign)

Para "Grandjean" é "a implementação de uma aplicação dos princípio da ergonomia ao processo de design, o resultado deve ser um produto atrativo e amigável". O precursos desta abordagem foi o design Henry Dreyfuss que foi o primeiro designer industrial que implementou ativamente a aplicação da antropometria no projeto de produtos.

Com este domínios, é possível dividir que os principais pontos para se refletir e planejar em ergonomia de software são:

1. Esforço mínimo do usuário
2. Memória mínima do usuário
3. Frustração mínima
4. Maximizar o uso de padrões e hábitos
5. Máxima tolerância para diferenças humanas e mudanças humanas. (interoperabilidade)
6. Notificação imediata de problemas
7. Controle máximo de tarefas pelo usuário
8. Apoio máximo as tarefas.

Como já comentado em outros /posts/ sobre usabilidade neste mesmo blog, é que é necessário criar testes práticos, e que as metodologias em geral devem trabalhar sempre para melhorar estes pontos por exemplo.

O trabalho para conseguir uma boa usabilidade do software pelo usuário deve ser um esforço continuo, pois implica em grandes dificuldades e exige esforços de pesquisa que vão além de pesquisas quantitativas. Como diria Meiset e Enderwick a tecnologia não existe isoladamente. O usuário que é influenciado por ela e que também a influencia em um ciclo interativo de uso.

Este é um assunto extenso, e pode ser divido em vários pontos, mas o principal ponto que quero retirar sobre a ergonomia é que podemos re-utilizar seus conceitos para criar uma melhor interação entre humano e computador e é valido para todos os desenvolvedores e designers.

O Facebook criou um mecanismo interessante para medir a qualidade de uma mensagem no seu status, oferecendo um botão simples "Like" abaixo de cada entrada no /news feed/ do usuário, na semana passada eles adicionaram este botão também aos comentários efetuados por todos.

Mas o que há de interessante neste pequeno botão, é que a audiência tem uma medição de qualidade maior, além do que simplesmente o total de pessoas que estão lendo.

Se você gostou, representa que a informação nova é *interessante* para você. Muitas pessoas podem bater o olho, mas não dedicarem tanta concentração...

Ele me lembrou o teste MOS, no qual é utilizado muito em testes de qualidade de ligação na telefonia, onde são feitos testes práticos com apenas duas questões com notas de 1 à 5, para saber qual a qualidade da conversa e do áudio recebido. (O grande problema que ele é subjetivo, porém é o teste mais respeitado na área, já que a automatização deste teste é extremamente complexo)

Porém, esta metodologia do Facebook com este botão, com apenas duas notas e uma questão: "Você realmente gostou da informação ? " SIM ou NÃO, você pode obter resultados baseados em "qualidade" de informação (ou palavras ? frases ?) e não apenas quantidade.

• http://github.com/kanaka/noVNC

Eu estava pesquisando aplicações que estão sendo desenvolvidas sobre a  WebSockets, e encontrei no github este projeto que me chamou atenção.

Ele implementa o VNC utilizando-se do HTML5, e como muitos navegadores não suportam ele ainda, existe no próprio repositório uma solução emergencial que se utiliza do Adobe Flash para simular a especificação.

E o que eu quero falar é mesmo sobre o websockets...

Hoje existem soluções como o Comet, que não é nativo no navegador e efetua a manutenção de duas conexões, uma para enviar e outra para receber, e além de ter que contar com conexões de longa duração podendo ser afetada por /proxys/ e /firewalls/.

A proposta do WebSockets é para que esta conectividade seja padrão nos navegadores (apesar de já existirem soluções para não depender deles como forma de introdução a especificação), e que você utilize apenas uma conexão com o servidor, no qual ela é full-duplex.

O interessante é que com este conceito podemos estar livres em breve, de /hacks/ alucinantes para que coisas simples funcionam de forma "simples".

E como ele consegue isto ? A primeira grande diferença, é que a proposta faz parte do projeto HTML5, segundo que estando presente nos navegadores é possível criar a conectividade full-duplex, e ele resolve e trata de questões como /proxys/ com utilização de tuneis, porém perceba, tudo isto esta na especificação e consequentemente em breve nos navegadores, você terá mais tempo para pensar nas regras de negócio do que tratar da conectividade.

Retirado da especificação da w3, veja a interface:

[Constructor(in DOMString url, in optional DOMString protocol)]
interface WebSocket {
  readonly attribute DOMString url;

  // ready state
  const unsigned short CONNECTING = 0;
  const unsigned short OPEN = 1;
  const unsigned short CLOSING = 2;
  const unsigned short CLOSED = 3;
  readonly attribute unsigned short readyState;
  readonly attribute unsigned long bufferedAmount;

  // networking
           attribute Function onopen;
           attribute Function onmessage;
           attribute Function onerror;
           attribute Function onclose;
  boolean send(in DOMString data);
  void close();


};
WebSocket implements EventTarget;

Com esta interface, você basicamente pode adicionar funções de callback para os eventos, de quando a conexão for aberta, quando existir alguma mensagem, quando for fechada ou quando tiver um erro. Seria como fazer :

myWebSocket var = WebSocket novo (ws://servidor.com.br/)

= Função myWebSocket.onopen (evt) (alert ("Conexão aberta ..."););
= Função myWebSocket.onmessage (evt) (alert ("mensagem recebida:" + evt.data););; 
= Função myWebSocket.onclose (evt) (alert ("Conexão fechada.");); 
myWebSocket.postMessage ("Olá Web Socket! Comet Adeus!");
myWebSocket.disconnect ();

Veja mais:

http://www.kaazing.org/confluence/display/KAAZING/What%2Bis%2BKaazing%2BOpen%2BGateway

http://dev.w3.org/html5/spec/


 

O principio do multi-método de forma resumida é uma função que tem múltiplas versões, no qual elas se diferenciam pelo tipo dos seus argumentos.

É a terceira vez (ou quarta ?) que vou até o CPAN, para encontrar uma solução para tratar esta minha necessidade em relação a multi-métodos, e sempre estou parando neste módulo, que simplificou muito uma implementação que estava trabalho... O nome deste módulo é MooseX::MultiMethods.

Com este módulo, ele te dá habilidades para criar "versões" diferentes da sua função baseado no /tipos/ do Moose.

É muito simples, entender o conceito e como implementar, e na documentação do próprio módulo há um exemplo, no qual dispensa explicações técnicas... Veja:

    package Paper;    use Moose;
    package Scissors; use Moose;
    package Rock;     use Moose;
    package Lizard;   use Moose;
    package Spock;    use Moose;

    package Game;
    use Moose;
    use MooseX::MultiMethods;

    multi method play (Paper    $x, Rock     $y) { 1 }
    multi method play (Paper    $x, Spock    $y) { 1 }
    multi method play (Scissors $x, Paper    $y) { 1 }
    multi method play (Scissors $x, Lizard   $y) { 1 }
    multi method play (Rock     $x, Scissors $y) { 1 }
    multi method play (Rock     $x, Lizard   $y) { 1 }
    multi method play (Lizard   $x, Paper    $y) { 1 }
    multi method play (Lizard   $x, Spock    $y) { 1 }
    multi method play (Spock    $x, Rock     $y) { 1 }
    multi method play (Spock    $x, Scissors $y) { 1 }
    multi method play (Any      $x, Any      $y) { 0 }

    my $game = Game->new;
    $game->play(Paper->new, Rock->new);     # 1, Paper covers Rock
    $game->play(Spock->new, Paper->new);    # 0, Paper disproves Spock
    $game->play(Spock->new, Scissors->new); # 1, Spock smashes Scissors

Você acabou de criar o seu jogo Rock-Paper-Scissors-Spock-Lizard.

Além de tratar os /tipos/, você pode manipular o Moose para poder tratar os "valores"  e assim criar versões diferentes da tua função.

Encontrei o membase procurando por outros bancos de dados.

Minha primeira pergunta era, outro banco de dados baseado em memória ? Existe espaço para isto !? E quando comecei a ler o site, encontrei a resposta rapidamente para isto...

Retirado do próprio site, http://membase.org/ :

Does the world really need another NoSQL database?

Before embarking on what has (so far) amounted to nearly 10 man-years of development effort, we invested countless hours trying to convince ourselves that the answer to that question was "no." No sane person embarks on a project of this magnitude without careful evaluation of existing solutions.

Esta nota, fez com que eu continua-se a ler sobre ele... E a resposta, foi boa para esta pergunta, ela basicamente cobre algumas necessidades que já tive e acabei adaptando ou utilizando o Redis.

Mas que "coisas" são estas ?

Ele adiciona persistência de disco, e você pode me falar na lata... Redis ! E as semelhanças acabam por aqui.

O sistema de replicamento de dados do Redis é muito simples, mas funciona para sua proposta inicial. O que este novo projeto inova, é como a replicação funciona, inserindo um mecanismo de hierarquia nos /nós/ para resolver conflitos de divisão.

Outro ponto interessante, é que o design do software é /multitenancy/, e me pareceu muito interessante do que utilizar máquinas virtuais, já que isto pode gerar uma economia significativa de memória, e evitar desperdiço de recursos em alguns cenários.

A minha conclusão, é que eles não "reinventaram a roda" pois utilizam o memcache para armazenar os dados, e o trabalho esta na "frente" dele para poder lhe dar a flexibilidade que você precisa, e resolver casos comum de utilização de um banco de dados como cache em memória.

O projeto é patrocinado pela NorthScale, Zunga e NHN.

Retirado do dicionario michaelis.

entusiasta
en.tu.si.as.ta
adj m+f (gr enthousiastés) Que se entusiasma; que se exprime com entusiasmo; que se dedica vivamente a uma coisa: Entusiasta pela música. Antôn: indiferente, frio. s m +f Pessoa que se entusiasma; admirador fervoroso; sectário fanático.

evangelista
e.van.ge.lis.ta
sm (lat evangeliu+ista) 1 Autor de um dos quatro evangelhos (São Mateus, São Marcos, São Lucas e São João). 2 Sacerdote que canta ou recita o Evangelho na missa; evangelizador. s m+f Pessoa que preconiza uma doutrina.