Processos, threads, non-blocking I/O, Node.js

Se você está confuso sobre esse “trens” que estão na “moda” Processos, Threads, Non-Blocking I/O e Node.js

Esse post pode te ajudar

Processos vs Threads

Definição rápida
Java e .Net = Thread
Ruby e Python  = Processo
Explicação
Thread – aplicações web em Java e .Net utilizam um Thread pool, ou seja, quando é feita uma requisição a uma aplicação web em Java ou .Net, o servidor de aplicação coloca a requisição em uma thread do Thread do pool, com isso uma única instância de um servidor de aplicação consegue atender simultaneamente várias requisições (= tamanho do pool)
Processo – aplicações web em Ruby e Python não usam Thread pool, portando uma instância de um application server, só atende uma requisição por vez. Devido esse cenário, geralmente aplicações nessas linguagens utilizam mais de uma instância do application server configuradas em load balancing, dessa forma a aplicação pode atender a mais de uma requisição simultaneamente
Ambas soluções podem ser escaláveis de forma vertical (aumento de hardware) e/ou horizontal (aumento de maquinas/servidores)
No caso do uso de Processo, um possível problema é que precisa de várias instâncias do servidor de aplicação no mesmo servidor para atender simultâneas requisições e isso pode consumir muita memória, mas por outro lado, em Java e .Net, geralmente os servidores de aplicação mesmo com uma única instância consome mais memória que muitas instâncias de servidores de aplicação Ruby e Python

Non-Blocking I/O

Uma forma “intuitiva” de explicar o Non-Blocking I/O é chama-lo de Asynchronous I/O, que é uma variação do seu nome. Geralmente em linguagens de programação quando é feita uma operação de I/O ela bloquea a execução até a operação finalizar
Pseudo código
mensagem = abrir_arquivo('mensagem.txt')
gravar_e_fechar_arquivo(mensagem, 'texto...texto...text')
chamada_a_qualquer_outro_metodo
No caso de I/O Bloqueante, que é o que estamos acostumados a usar, a chamada_a_qualquer_outro_metodo só será executada após a operação gravar e fechar o arquivo, isso pode demorar muito tempo
Agora imagine se o método chamada_a_qualquer_outro_metodo demore 10 segundos para ser executado e se fizerem 5 requisições simultâneas para ele
1 requisição – 10 segundos
2 requisição – 10 segundos da primeira + 10 = 20 segundos
5 requisição – 40 segundos da primeira + 10 = 50 segundos
Esse bloqueio não acontece somente para gravação direta em arquivo, drivers de banco de dados como o mysql também podem ser bloqueantes para operações de escrita
O Non-Blocking I/O, Asynchronous I/O, evented I/O…,  resolve esse problema de uma forma que é muito comum para programadores JavaScript que estão acostumados com chamadas Ajax
$.ajax({ url: 'test.html', success: function(){
alert('Pablo');
}});
alert('Hello World ');
No exemplo acima será exibido um primeiro alert ‘Hello World’ e logo em seguida o segundo alert ‘Pablo’, pois a chamada em Ajax não trava a execução do processo

Chamada não Bloqueante com Node.js

Um bom é simples exemplo para uma operação de I/O não bloqueante é com Node.js que usa JavaScript V8
var fs = require(‘fs’);
fs.writeFile(‘message.txt’, ‘Hello Node’, function (err) {
if (err) throw err;
console.log(‘It\’s saved!’);
});
Qualquer operação que estiver abaixo do fs.writefile será executada sem tem que esperar o resultado do operação de I/O. O Node.js também tem opção sincrona para gravação de arquivo através do fs.writeFileSync

Conclusão

Coloquei esses dois temas no mesmo post, pois são soluções que podem se complementar. Por exemplo resolvendo o gargalo de I/O através de servidores de aplicação asynchronous como Jetty e o nginx (se pronuncia engine X)
Qual é melhor ou pior? Tudo depende de cada caso, de cada problema para ser resolvido
Na minha opinião, hoje em dia não se pode mais fazer como a poucos anos atrás “eu Programo em Java, só faço coisas em Java, um cadastro… faço em Java, um relatório… faço Java e etc”. Hoje em dia, cada vez, cada problema deve ser analisado e levantado qual é a melhor solução, incluindo qual tecnologia usar. Até com Java a coisas mudaram, a Sun Oracle já não é mais a provedora do que usar com Java, fazer uma aplicação web em Java, não significa (não mesmo!) que será JSF + EJB

, , , , , ,

2 Comments

GitHub – Múltiplos forks para o mesmo repositório

Fonte: http://pablocantero.com/blog/2010/10/20/github-multiplos-forks-para-o-mesmo-repositorio/

Para poupar que você leia esse artigo até o final e sinta-se enganado, adianto que NÃO É POSSÍVEL de forma direta, somente por meios alternativos como criar um branch ou remover as referências do projeto original

Motivação

Fiz um fork de um projeto onde fiz muitas mudanças, portanto eu não queria fazer um pull request de todas as mudanças, pois não iria ter sentido para o projeto original

Pensei em fazer um novo fork do projeto original, pois assim eu poderia contribuir com as mudanças relevantes de forma isolada, mas infelizmente isso não é possível

Solução

Solucionei o problema deixando a cópia do projeto original como um branch “original-nome-do-projeto” no meu fork

A solução foi baseada em um comentário do support staff do GitHub.

matilde:~ pablo$ cd workspace/gesture-translate/gtranslate
matilde:gtranslate pablo$ git remote add upstream http://github.com/bpierre/gtranslate.git
git fetch upstream
git branch original-gtranslate upstream/master
git checkout original-gtranslate

  1. Acessei o diretório do projeto que eu já tinha feito o fork
  2. Criei um novo branch com base branch master do projeto original
  3. Fiz checkout do novo branch

Após fazer as mudanças relevantes ao projeto original subi as alterações para o GitHub

git commit -a -m "Mudanças relevantes para o projeto original"
git push origin original-gtranslate

Na página do GitHub mudei do branch master para o branch original-gtranslate

E por fiz um pull request das mudanças feitas no branch original-gtranslate


Pensamentos

Após escrever esse artigo fiquei na dúvida “será que realmente é necessário criar um novo fork?”, no meu caso, acho que usar um branch foi a solução mais simples, que infelizmente não me veio a cabeça inicialmente

A solução com branch além de resolver plenamente o meu problema, também me possibilita fazer merges entre os branchs

que infelizmente não me veio a cabeça inicialmente

Esse comentário me faz lembrar do Axioma 1 do 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.

Principais referências

http://support.github.com/discussions/repos/2420-multiple-forks#comment_958975

,

No Comments

Sony lança TV com Android neste final de semana

Sony Android TV

A japonesa Sony saiu na frente e vai colocar no mercado a partir deste final de semana seu primeiro televisor rodando o sistema Android com acesso à Internet utilizando o navegador Chrome. A novidade estará disponível nas lojas próprias da Sony(as famosas Sony Style) e provavelmente nas lojas da Best Buy.

As TVs serão de LCD (será por causa do custo ?) de 24 à 46 polegadas e terá preço inicial (recomendado) variando entre 600 e e 1400 USD. Valor um pouco alto para o mercado americano, mas parece que a Sony tenta fazer um “test-drive” para ver quanto o consumidor quer pagar para poder navegar pela TV no conforto do seu sofá.

Sony até disponibilizou um site Android Sony Developer/ que promete manter os usuários registrados bem informados sobre o que vem por aí.

Eu gostei da iniciativa da Sony de utilizar o Android, isso abre mais um “mercado” para o desenvolvimento de aplicações para a plataforma (Televisores) que até então era MUITO fechado, por outro lado, a tela de LCD poderia ser de LED. Quem sabe se fizer sucesso eles acabam fazendo TVs de LED e Plasma também.

Estou ansioso para ver o que vem por aí na próxima CES.

, , , , , , , , ,

No Comments

GAE – Primeiras impressões – Envio de e-mail

fonte: http://pablocantero.com/blog/2010/10/03/gae-primeiras-impressoes-envio-de-e-mail/

GAE + Java

Esse post foi baseado em um e-mail que eu enviei para uma lista de e-mail que faço parte, graças a esse e-mail que eu me motivei para criar esse blog, mas só agora depois de vários posts que resolvi publica-lo

Meus primeiros instantes com o GAE foram emocionantes, eu estava ali com um PaaS na mão, com o poder de aumentar recursos da minha plataforma com apenas alguns cliques e um cartão de crédito :D

Lembrando que ao adicionar recursos na plataforma do GAE, vc adiciona um pagar até…


Se você adicionar 10 dólares de CPU hour, não quer dizer que vai pagar 10 dólares, e sim, que pagará até no máximo 10 dólares, somente se o recurso for consumido. Sendo que as quotas são renovadas diariamente. Fantástico, né?!

Google Plugin for Eclipse

Para os primeiros passos com o GAE, o Google Plugin for Eclipse é altamente recomendado, ele é uma forma rápida e fácil de criar projetos, testar localmente e fazer deploys em produção

Meu primeiro projeto

Depois de uma serie de projetos de brincadeirinha prova de conceito, Hello World, CRUD Básico e etc. Achei um amigo que tinha uma necessidade de enviar Clipping Diário de Notícias, que consistia em um cadastro de de contatos e envio de e-mail diário com um pdf em anexo (upload via BlobStore)

Péssima idéia

O GAE não é recomendado para sistemas de envio de e-mail em massa devido algumas restrições da plataforma, como quantidade de e-mail por minuto, tamanho de anexo no e-mails e etc. Mas só fui descobrir após experimentar

Restrição do Sender

O GAE tem algumas restrições para o remetente do e-mail, que precisa ser um e-mail de um dos administradores da aplicação ou o usuário corrente logado. Se você tentar enviar um e-mail pelo GAE com um remetente do tipo contato@suaempresa.com.br, noreply@suaempresa.com.br, clipping@suaempresa.com.br e etc. Esses e-mails deverão ser os mesmos usados pelo usuário corrente logado ou estarem cadastrados como administradores da aplicação. Em nenhuma das situação é comum ter um contato@suaempresa.com.br, como usuário logado ou admintrador, né?!

Descrição do sender na Low-level API para envio de e-mail

http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/mail/MailService.Message.html#setSender%28java.lang.String%29

Sender
must correspond to the valid email address of one of the admins for this application, or to the email address of the currently logged-in user. Sender is really the From: field of the email.

Na hora que li isso, pensei: vou usar a API do Java Mail apontando para o meu servidor SMTP, assim tenho total controle sobre o envio de e-mail

An app cannot use the JavaMail interface to connect to other mail services for sending or receiving email messages. SMTP configuration added to the Transport or Session is ignored.

Para mandar e-mail pelo GAE você só pode usar o serviço de envio de e-mail do GAE. Isso não impede de enviar e-mail usado outros serviços por outros meios Web Services, REST, requisição http e etc,  e esses outros meios delegarem para outros serviços de envio de e-mail

Lembrando que se cadastrar contato@suaempresa.com.br como adminstrador, esse e-mail terá privilégios de acessar a administração do GAE e inclusive adicionar recursos ($$$) na plataforma

Restrição de envio de e-mails por minuto

Na conta free do GAE, vc tem uma restrição de 1 e-mail (leia-se um destinatário) por minuto, quando vc ativa a versão paga, muda para 5200, tudo aumenta, processamento e etc, mas sem custo, o custo só acontece depois que vc excede o que ganhou a mais, só por habilitar a opção paga

Acoplamento com GAE

É quase inevitável não acoplar seu sistema com o GAE, devido uma serie Not supported APIs do GAE, e a facilidade para usar alguns recursos do GAE usando bibliotecas do Google.  Migrar uma aplicação do GAE para outro container ou application server, muito provavelmente será uma tarefa árdua

Ambiente de desenvolvimento vs Produção

Talvez isso já esteja melhor, mas quando eu testei com Google Plugin for Eclipse, funcionar em desenvolvimento não garante que funcionará em produção. Mais de uma vez, testei em desenvolvimento, estava funcionando, quando eu fazia o deploy em produção não funcionava

Datastore Indexes

Um coisa bem legal é o Datastore Index que pode ser configurada para ser gerada automaticamente em desenvolvimento. Habilitando a opção datastore-indexes autoGenerate=”true” no datastore-indexes.xml

<datastore-indexes autoGenerate="true">

Conforme vc for usando suas entidades no seu ambiente de desenvolvimento, ele vai automaticamente criando indexes para suas entidades com base na utilização. Muito bom!

O lado ruim e que as vezes o GAE fica horas para gerar os indexes em produção, e só após a geração desses indexes as entidades ficam disponíveis

BigTable

Com o  BigTable estou usando JDO (achei que os tutorias do GAE incentivam mais para usar JDO que JPA). Devido o modelo não relacional do BigTable, perdi um pouco das facilidades do ORM

MailModel tem uma lista ContactModel

Como ContactModel não é filho de MailModel (owned relationship), para fazer esse relacionamento tive que fazer

List<Long> contactsId;

ContactModel é uma unowned, ele tem uma PrimaryKey Long e não uma Key (com.google.appengine.api.datastore.Key). Para mais detalhes http://code.google.com/appengine/docs/java/datastore/dataclasses.html

Portanto no meu Service, após fazer o load de qualquer MailModel, tenho que carregar os ContactModel manualmente com base nos contactsId (tchau lazy load, olá eager load?!)

Conclusões

Apesar de eu talvez ter enfatizado um lado restritivo do GAE, ainda é uma ótima plataforma, claro, com algumas restrições. Tem que levar em consideração o que você quer desenvolver, para um sistema de envio de e-mail não é bom, mas para outras coisas, pode ser

No post GAE + Eclipse + Maven, demonstro como usar o GAE diretamente com Maven que pode ser mais produtivo posteriormente que com somente o Google Plugin for Eclipse

Spring + GAE

Para usar o Spring MVC com o GAE tem algumas restrições de bibliotecas, baixar o archetype do Spring MVC não funcionará diretamente. Criei um projeto http://github.com/phstc/spring-gae no github, com uma aplicação com Maven + Google Plugin for Eclipse + Spring MVC 3 pronta para uso!

, ,

No Comments

Como seria um Nerd no poder?

Fonte: http://www.sharedmemory.com.br/blog/2010/10/como-seria-um-nerd-no-poder/

Esse post é antigo e o original é em inglês. Mas com todo esse assunto de eleição não dá para deixar de pensar como seria um verdadeiro nerd do mal no poder. Enviado pelo meu bom amigo @Ricardo_Alves.

AS 100 COISAS A FAZER QUANDO ME TORNAR UM SENHOR DO MAL.

1. Minhas Legiões do Terror terão capacetes com visores de acrílico, e não
placas tampando o campo de visão.

2. Meus dutos de ventilação serão pequenos demais para alguém rastejar por
eles.

3. Meu nobre meio irmão, do qual usurpei o trono, será morto, não mantido
anônimo em uma cela esquecida em minha masmorra.

4. Fuzilamento não é bom demais para meus inimigos.

5. O Artefato que é a fonte de meu poder não será mantido na Montanha do
Desespero, além do Rio de Fogo guardado pelos Dragões da Eternidade. Será
mantido em uma caixa forte convencional. Isso também se aplica ao objeto
que é minha única fraqueza.

6. Não irei me gabar da situação de meus inimigos antes de matá-los.

7. Quando tiver capturado meu adversário e ele disser “Olhe, antes de me
matar, pelo menos me conte sobre o que você planeja fazer.” Eu direi “não”
e atirarei nele. Pensando bem, vou atirar nele e depois dizer “não”.

8. Depois de raptar a linda princesa, iremos nos casar imediatamente em
uma discreta cerimônia civil, não um espetáculo de três semanas de duração
durante as quais a fase final de meu plano será implementado.

9. Não incluirei um mecanismo de autodestruição a não ser que seja
absolutamente necessário. Se o for, não será um grande botão vermelho
escrito “Perigo, não aperte”. O grande botão vermelho “Não Aperte” irá
disparar uma saraivada de balas em qualquer um estúpido o bastante para
apertá lo. Ao mesmo tempo, botões “LIGA/DESLIGA” não serão claramente
indicados em meus painéis.

10. Não levarei meus inimigos para interrogatório no centro de meu
castelo. Um pequeno hotel, na periferia de meu Reino servirá
perfeitamente.

11. Serei seguro de minha superioridade. Assim, não sentirei necessidade
de prová-la, deixando pistas na forma de charadas ou permitindo que meus
inimigos mais fracos permaneçam vivos, para mostrar que não representam
ameaça para mim.

12. Um de meus conselheiros será uma criança de cinco anos. Qualquer falha
em meus planos que ela seja capaz de detectar será corrigida antes da
implementação.

13. Todos os inimigos mortos serão cremados. Os corpos levarão repetidos
tiros de munição de grosso calibre. Ninguém será deixado para morrer no
fundo de um penhasco. O anúncio de suas mortes, bem como a respectiva
celebração do evento, serão adiados até depois dos procedimentos acima
mencionados.

14. O herói não terá direito a um último beijo, último cigarro ou qualquer
tipo de último pedido.

15. Nunca usarei nenhum dispositivo com um contador digital. Se achar que
tal dispositivo é essencial, o marcarei para ativação quando o contador
chegar em 117 e o heróis estiver começando a pensar em um plano para
desativá-lo.

16. Nunca usarei a frase “Antes de matá-lo, há uma coisa que desejo
saber”.

17. Quando empregar pessoas como conselheiros, ocasionalmente irei escutar
seus conselhos.

18. Se um jovem e atraente casal entra em meu Reino, irei monitorar
cuidadosamente suas atividades. Se descobrir que são felizes e
apaixonados, os ignorarei. Entretanto, se as circunstâncias os forçaram a
ficar juntos, contra sua vontade, e se passam todo
o tempo implicando e criticando um ao outro exceto em ocasiões quando
estão salvando a vida um do outro, momento em que há toques de tensão
sexual no ar, ordenarei imediatamente sua execução.

19. Não irei ter um filho. Apesar de suas risíveis e mal planejadas
tentativas de usurpar meu poder sempre falharem, isso pode se tornar uma
distração fatal em um período crucial.

20. Não terei uma filha. Ela iria ser tão bonita quando má, mas uma
simples olhada para a expressão no rosto do herói e ela irá trair o
próprio pai

21.Apesar de ser uma forma comprovada de aliviar o stress, não irei
soltar risadas maníacas. Com essas risadas, quando ocupado, é muito
fácil deixar de perceber pequenas nuances e acontecimentos que um
indivíduo mais atento pode identificar e responder à altura.

22.Irei contratar um estilista talentoso para criar uniformes originais
para minhas Legiões do Terror, ao contrário de certos modelos baratos
que os fazem parecer tropas nazistas, legiões romanas ou hordas
de selvagens mongóis. Todos foram eventualmente derrotados e quero que
minhas tropas tenham uma inspiração moral mais positiva.

23.Não importa o quão tentador seja a perspectiva de poder ilimitado, não
irei absorver qualquer campo de energia maior que minha cabeça.

24.Irei manter um estoque especial de armas de baixa tecnologia e treinar
minhas tropas em seu uso. Assim, mesmo que os heróis consigam destruir
meu gerador de energia e/ou desativar as armas de energia padrão, minhas
tropas não serão sobrepujadas por um bando de selvagens armados com
lanças e pedras.

25.Irei manter uma estimativa realista de minhas forças e fraquezas.
Mesmo que isso tire parte da diversão do trabalho, pelo menos nunca
irei dizer a frase ‘Não, não pode ser! EU SOU INVENCÍVEL!!!” (após a
qual, normalmente a morte é instantânea.)

26.Não importa o quão bem funcione. Jamais irei construir qualquer
tipo de equipamento que seja completamente indestrutível exceto por
um pequeno e virtualmente inacessível ponto vulnerável.

27.Não importa o quão atraentes certos membros da rebelião podem ser.
Provavelmente em algum lugar há alguém igualmente atraente que não
está tentando desesperadamente me matar. Assim, pensarei duas vezes
antes de ordenar que uma prisioneira seja levada a meus aposentos.

28.Nunca construirei uma única unidade de nada importante. Todos
os sistemas essenciais terão painéis de controles e fontes de força
redundantes. Pela mesma razão, sempre carregarei pelos menos duas
armas carregadas, todo o tempo.

29.Meu monstro de estimação será mantido em uma jaula bem segura,
da qual ele não poderá escapar e na qual não poderei cair por acidente.

30.Irei me vestir com cores claras e alegres, isso deixará meus inimigos
confusos.

31.Todos os magos incompetentes, escudeiros, bardos sem talento e
ladrões covardes em meu Reino serão executados. Meus inimigos certamente
desistirão e abandonarão sua cruzada se não tiverem um parceiro cômico
ao lado.

32.Todas as camponesas ingênuas e peitudas que servem bebidas em
tabernas serão trocadas por garçonetes experientes e profissionais,
que não irão dar apoio ao herói ou servir de par romântico para seu ajudante.

33.Não terei um ataque de fúria e matarei o mensageiro que me trouxe más
notícias só para mostrar o quão mal realmente sou. Bons mensageiros são
difíceis de achar.

34.Não exigirei que as mulheres em postos de comando em minha
organização usem tops de aço inoxidável. A moral da tropa fica bem melhor
com um código de vestimenta mais casual. Ao mesmo tempo, roupas feitas
inteiramente de couro serão reservadas para ocasiões formais.

35.Nunca vou me transformar em uma cobra. Isso nunca funciona.

36.Não irei deixar crescer um cavanhaque. Nos velhos tempos
fazia com que você parecesse diabólico, hoje o torna um membro frustrado
da Geração X.

37.Não irei prender membros do mesmo grupo no mesmo bloco da masmorra.
Muito menos na mesma cela. Se são prisioneiros importantes, irei manter
a única chave da cela comigo, ao invés de deixar uma cópia com cada
guarda do destacamento da prisão.

38.Quando meu tenente de confiança disser que minhas legiões do Terror
estão perdendo uma batalha, eu acreditarei nele. Afinal, ele é meu
tenente de confiança.

39.Se um inimigo que acabei de matar tem irmãos ou filhos em algum lugar,
irei encontrá los e executá los imediatamente, ao invés de esperar que
cresçam nutrindo sentimentos de vingança contra mim.

40.Se eu não tiver escapatória a não ser me envolver em uma batalha,
certamente não liderarei na frente de minhas Legiões do Terror, nem
irei procurar o líder adversário entre o exército inimigo.

41. Não irei ser cavalheiresco ou bom esportista. Se possuir uma super
arma contra a qual não há defesa, a usarei assim que for possível, ao
invés de mantê-la guardada.

42. Assim que meu poder estiver estabelecido, irei destruir todos aqueles
inconvenientes dispositivos de viagem no tempo.

43. Quando capturar o herói, terei certeza de também capturar seu
cachorro, macaco, furão ou qualquer outro bichinho bonitinho de dar nojo,
capaz de desamarrar cordas e roubar chaves, que por acaso ele tenha como
mascote.

44. Irei manter uma saudável dose de ceticismo quando capturar a linda
rebelde e ela disser que está atraída por meu poder e boa aparência, e
alegremente trairá seus companheiros se eu deixá-la tomar parte em meus
planos.

45. Só irei contratar caçadores de recompensa que trabalhem por dinheiro.
Aqueles que trabalham por prazer tendem a fazer coisas tolas como
equilibrar as chances, para dar ao outro cara uma disputa justa.

46. Terei um claro entendimento sobre quem é responsável pelo que em minha
organização. Por exemplo, se meu general fracassou, não irei sacar minha
arma, apontar para ele, dizer “e este é o preço do fracasso” então
subitamente apontar e matar um subalterno qualquer.

47. Quando um conselheiro disser “Meu Lorde, ele é somente um homem. O que
apenas um homem pode fazer?” Eu responderei: “Isso!” e matarei o
conselheiro.

48. Se descobrir que algum fedelho começou uma cruzada para me destruir,
irei chaciná-lo enquanto ele ainda é um fedelho, ao invés de esperar que
cresça e se torne um adulto.

49. Tratarei qualquer monstro que eu venha a controlar através de mágica
ou tecnologia com respeito e ternura. Assim, se perder o controle sobre
ele, não virá imediatamente atrás de mim por vingança.

50. Se descobrir a localização aproximada do único artefato que pode me
destruir, não irei mandar todas as minhas tropas para recuperá-lo. Ao
contrário, mandarei as tropas atrás de alguma outra coisa, e discretamente
colocarei um anúncio de “procura-se, g ratifica-se bem “, em um jornal
local.

51. Meus computadores principais terão seu próprio sistema operacional,
que será totalmente incompatível com IBM PCs ou Macs.

52. Se um dos guardas de minha masmorra começar a esboçar preocupação com
as condições na cela da linda princesa, ele será imediatamente transferido
para uma função com menos envolvimento com pessoas.

53. Irei contratar um time de arquitetos e pesquisadores de alto nível
para examinar meu castelo e me informar de quaisquer passagens secretas e
túneis abandonados que eu tenha conhecimento.

54. Se a linda princesa que capturei disser “Nunca irei me casar com você!
Nunca! Está ouvindo? Nunca!” eu direi: “Tudo bem.” E a executarei.

55. Não farei uma barganha com uma criatura demoníaca e depois tentarei
desfazê-la apenas porque me senti com vontade.

56. Os mutantes deformados e malucos psicóticos terão seu lugar em minhas
Legiões do Terror. Entretanto antes de mandá-los em uma importante missão
secreta que demande tato e sutileza, verificarei se há alguém mais
igualmente qualificado, e que atraia menos atenção.

57. Minhas Legiões do Terror serão treinadas em tiro básico. Qualquer um
que não consiga aprender a acertar algo do tamanho de um homem a 10 metros
de distância, será usado como alvo.

58. Antes de utilizar qualquer tipo de artefato ou máquina capturada, irei
ler cuidadosamente o manual de instruções.

59. Se for necessário fugir, não irei parar para fazer uma pose dramática
e dizer uma frase profunda.

60. Nunca irei construir um computador inteligente que seja mais esperto
do que eu.

61. Pedirei a meu conselheiro de cinco anos de idade que tente decifrar
qualquer código que eu estiver pensando em adotar. Se ele o decifrar em
menos de 30 segundos, não será usado. Nota: Isso também se aplica a
passwords.

62. Se meus conselheiros perguntarem “Por que está arriscando tudo nesse
plano louco?” Não irei prosseguir até ter uma resposta que os satisfaça.

63. Irei projetar os corredores de minha fortaleza para que não haja
alcovas ou suportes estruturais protuberantes que possam ser usados como
abrigo por intrusos durante um tiroteio.

64. Lixo será eliminado em incineradores, não compactadores. E eles serão
mantidos acesos, sem aquele nonsense de chamas que se ativam através de
túneis de acesso, em intervalos previsíveis.

65. Irei me consultar com um psiquiatra e me curar de todas as estranhas
fobias e bizarros hábitos compulsivos que possam se mostrar uma
desvantagem.

66. Se for obrigatório que existam terminais de computador de acesso
público, os mapas que mostram meu complexo terão uma sala claramente
marcada como Sala de Controle Central. Essa sala será a Câmara de
Execução. A sala de controle central de verdade est ará indicada como
Câmara de Contenção de Transbordamento do Esgoto.

67. Meu teclado de segurança na verdade será um scanner de impressões
digitais. Qualquer um que observe um usuário digitar seu código e
consequentemente tente digitar a mesma sequência irá ativar o alarme
central.

68. Não importa quantos curtos circuitos há no sistema, meus guardas serão
instruídos a tratar cada câmera de segurança com defeito como caso de
emergência total.

69. Pouparei a vida de alguém que tenha me salvado no passado. Isso só é
razoável se estimular outros a fazê-lo. Entretanto a oferta só é válida
uma única vez. Se querem que os poupe novamente, é melhor que salvem minha
vida mais uma vez.

70. Todas as parteiras serão banidas de meu reino. Os bebês nascerão em
hospital supervisionados pelo Estado. órfãos serão colocados em lares
adotivos, não abandonados na floresta para serem criados por criaturas
selvagens.

71. Quando meus guardas se separarem para procurar por intrusos, eles
sempre andarão em grupos de pelo menos dois. Serão treinados para que se
um desaparecer misteriosamente no meio da patrulha, o outro iniciará
imediatamente um alerta e chamará por reforços, ao invés de ficar
procurando o colega pelas esquinas.

72. Se eu decidir testar a lealdade de um assistente, para descobrir se
ele pode ser promovido a homem de confiança, terei um grupo de atiradores
de elite por perto, caso a resposta seja não.

73. Se todos os heróis estão ao lado de um mecanismo esquisito e me
desafiando, usarei uma arma convencional, ao invés de disparar minha super
arma invencível contra eles.

74. Não concordarei em deixar os heróis partirem livres, se vencerem uma
competição, mesmo que meus conselheiros digam que está tudo arranjado e
que é impossível para eles ganhar.

75. Quando criar uma apresentação multimídia de meu plano, feita para que
meu conselheiro de cinco anos de idade possa facilmente entender os
detalhes, não irei chamar o disco de “Projeto Overlord” e deixá lo solto
em minha mesa.

76. Irei instruir minhas Legiões do Terror para atacarem o herói em massa,
ao invés de ficarem em volta dele esperando enquanto um ou dois atacam de
cada vez.

77. Se o herói correr para meu telhado, não irei atrás dele em uma
tentativa de atirá-lo do alto. Também não lutarei com ele na beira de um
despenhadeiro. (No meio de uma ponte de cordas sobre um rio de lava
derretida não vale nem a pena considerar.)

78. Se tiver um surto de insanidade e decidir oferecer ao herói a chance
de rejeitar um emprego como meu Braço Direito, irei reter sanidade o
suficiente para esperar que meu atual Braço Direito saia da sala antes de
fazer a oferta.

79. Não direi para minhas Legiões do Terror “E ele deve ser trazido
vivo!”. A ordem será: “E tentem trazê-lo vivo se for razoavelmente
viável”.

80. Se acontecer de minha máquina do Juízo Final possuir um botão de
reversão, assim que tiver sido usada irei derretê-la e cunhar uma edição
especial limitada de moedas comemorativas.

81. Se minhas tropas mais fracas falharem na tentativa de eliminar o
heróis, mandarei minhas melhores tropas, ao invés de perder tempo mandando
tropas progressivamente mais fortes, a medida em que ele se aproxima de
minha fortaleza.

82. Quando lutar com o herói no alto de uma plataforma em movimento, o
tiver desarmado, e estiver a ponto de acabar com sua vida, e ele olhar
para algo atrás de mim e se jogar no chão, me jogarei imediatamente no
chão também, ao invés de fazer uma express ão inquisitiva e olhar para
trás para ver o que ele viu.

83. Não irei atirar em nenhum de meus inimigos se eles estiveram de pé em
frente a um suporte crucial de uma estrutura pesada, perigosa e
precariamente equilibrada.

84. Se estiver jantando com o herói, colocar veneno em sua taça, e
subitamente tiver que sair da sala por alguma razão, pedirei novos
drinques para nós, ao invés de tentar decidir se ele trocou ou não os
copos.

85. Não deixarei que prisioneiros de um sexo sejam vigiados por membros do
sexo oposto.

86. Não implementarei nenhum plano cujo passo final sejam horrivelmente
complicado, como “alinhe as 12 Pedras do Poder no altar sagrado então
ative o medalhão no momento do eclipse total”. Ao invés disso, meu plano
será ativado com a frase “aperte o botão “.

87. Terei certeza de que minha Máquina do Juízo Final está devidamente
dentro das regras de instalação, e corretamente aterrada.

88. Meus tonéis de produtos químicos perigosos ficarão tampados quando
fora de uso. Também não irei construir passagens e escadas sobre eles.

89. Se um grupo de subordinados falhar miseravelmente em sua missão, não
lhes darei uma grande bronca por sua incompetência, e em seguida enviar o
mesmo grupo para tentar de novo.

90. Depois de capturar a super arma do herói, não vou imediatamente
dispensar minhas legiões e relaxar minha guarda pessoal porque acredito
que qualquer um que possua a arma é invencível. Afinal, o herói tinha a
arma e eu a tomei dele.

91. Não vou projetar uma Sala de Controle Central em que todos os
terminais deixem o operador de costas para a porta principal.

92. Não irei ignorar o mensageiro esbaforido e obviamente agitado até que
minha cavalgada ou outro entretenimento pessoal termine. O que ele tem a
dizer pode ser importante.

93. Se chegar a falar com o herói ao telefone, não irei ameaçá-lo. Ao
contrário, direi que sua perseverança me deu uma nova visão da futilidade
de minhas ações malvadas, e que se ele me deixar em paz por alguns meses
de quieta contemplação irei provavelme nte voltar para o caminho do Bem.
(heróis são incrivelmente fáceis de se enganar, quanto a isso).

94. Se eu decidir realizar uma execução dupla do herói e de um subordinado
que tenha falhado ou me traído, farei com que o herói seja executado
primeiro.

95. Quando efetuando uma prisão, meus guardas não deixarão que parem e
peguem um objeto aparentemente inútil, por puro valor sentimental.

96. Minha masmorra terão sua própria equipe médica qualificada, completa
com guarda costas. Assim se um prisioneiro ficar doente e seu colega de
cela disser ao guarda que é uma emergência, o guarda chamará um grupo de
trauma, ao invés de abrir a cela para
dar uma olhada.

97. Minhas portas serão projetadas para se que alguém destrua o painel de
controle do lado de fora, a porta feche, e se destrua o painel do lado de
dentro, a porta abre. Não vice versa.

98.As celas de minhas masmorras não conterão objetos com superfícies
reflexivas ou nada que possa ser transformado em cordas.

99.Qualquer conjunto de dados de importância crucial será acondicionado em
arquivos de 1.45Mb, para não caberem em um único disquete.

100.Finalmente, para manter todos os meus súditos contentes e
descerebrados, irei prover a cada um acesso Internet ilimitado, grátis.

,

No Comments

Apple libera iOS 4.2 Beta

Fonte: http://www.outofmemory.blog.br/2010/09/16/apple-libera-ios-4-2-beta/

Ontem recebi um email da Apple dizendo que já estava disponível a versão 4.2 beta do iOS, devo confessar que fiquei surpreso pois foi a primeira vez que vi a Apple lançar uma versão oficial do iOS (4.1) e a beta (4.2) praticamente na mesma semana.

Infelizmente ainda não tive tempo de baixar e instalar no iPhone, mas pelo que eu li, tem algumas coisas interessantes. Alem de finalmente unificar as plataformas (mesma versão de iOS para iPhone e iPad) e do Multitask para o iPad, ainda introduziram o AirPrint (para o iPad) e o AirPlay, entre outras funcionalidades.

Leia versão completa em : http://www.outofmemory.blog.br/2010/09/16/apple-libera-ios-4-2-beta/

, ,

No Comments

Algumas Características do QPI ( Quick Path Interconnect)

fonte: http://waltergargarela.blogspot.com/2010/09/algumas-caracteristicas-do-qpi-quick.html

QPI é um modelo novo de conexão ao processador que tem por ênfase a melhorar de comunicação com dispositivos internos de I/O, diferente dos antigos processadores que usam um barramento externo para comunicação para I/O e para acesso à memória. Neste ponto já podemos ver que no QPI não há o trafego de acesso à memória pois os processadores já possuem um controlador de memória integrado e as memórias estão conectadas diretamente ao processador, ou seja, nos modelos que usam o FSB (Front Side Bus) o tráfego de dados de memória e I/O compartilham o mesmo barramento.

Ponto para o QPI que trabalha com mais folga na carga de dados, pois o acesso à memória é feito diretamente pelo processador.

Em uma matéria sobre o QPI, feita pelo Gabriel Torres e o Cássio Lima, foram citadas muitas comparações do QPI com o HyperTranport da AMD e o FSB para servir de referência de maneira que fique mais fácil a compreensão e mais clara a diferença entre tecnologias concorrentes e novas tecnologias. Vale lembrar que esta tecnologia não está apenas atrelada ao processador, tanto o QPI como o HyperTranport são inovações de sistema e arquitetura de comunicação tendo como ponto e foco principal o processador, mas que afetam principalmente os controladores de I/O que devem se adequar as velocidades, freqüências e conexões com esta nova interconexão (QPI).

Em comparação com o FSB o Quick Path Interconnect possui dois canais de comunicação entre o processador e o Hub controlador de I/O (SouthBridge), se comparado com o FSB que além de receber o tráfego de comunicação à memória e I/O, tinha apenas uma única via ou canal de comunicação, que tinha de ser partilhado com todo o tráfego. Já o QPI possuindo uma carga menor do fluxo de dados e duas vias de comunicação, sendo uma para leitura e outra para escrita, abaixo tem uma citação mais técnica do pessoal do Clube do Hardware que esclarece bem que apesar do QPI transferir menos bits por pulso de clock que o FSB o QPI tem um clock muito mais alto.

Cada pista é capaz de transferir 20 bits por vez. Desses 20 bits, 16 são bits de dados e os 4 bits restantes são usados para um código de correção de erros chamado CRC (Cyclical Redundancy Check ou Controle de Redundância Cíclica), que permite ao receptor verificar se os dados recebidos estão intactos.

A primeira versão do barramento QuickPath trabalhará com um clock de 3,2 GHz transferindo dois dados por pulso de clock (técnica chamada DDR, ou taxa de transferência dobrada), fazendo com que o barramento funcione como se tivesse rodando a um clock de 6,4 GHz (a Intel usa a unidade GT/s – que significa bilhões de transferências por segundo – para representar isto). Como 16 bits são transmitidos por vez, nós temos uma taxa de transferência máxima teórica de 12,8 GB/s em cada pista (6,4 GHz x 16 bits / 8). Você verá algumas pessoas dizendo que o barramento QuickPath Interconnect tem uma taxa de transferência máxima teórica de 25,6 GB/s já que elas multiplicam a taxa de transferência por dois para cobrir os dois caminhos de dados. Nós não concordamos com essa metodologia. Em resumo, isto é mesmo de dizer que o limite de velocidade de uma pista é de 160 Km/h só porque existe um limite de velocidade de 80 Km/h em cada direção. Não faz sentido.

Comparado ao tradicional barramento frontal o QuickPath transmite menos bits por pulso de clock, mas funciona com um clock muito mais alto. Atualmente o barramento frontal mais rápido disponível nos processadores Intel é de 1.600 MHz (na verdade 400 MHz transferindo quatro dados por pulso de clock; o QuickPath funciona com um clock base oito vezes maior), o que resulta em uma taxa de transferência máxima teórica de 12,8 GB/s, a mesma do QuickPath. O QuickPath, no entanto, oferece 12,8 GB/s em cada direção, enquanto que um barramento frontal de 1.600 MHz oferece esta largura de banda tanto para as operações de leitura quanto escrita – e ambas não podem ser executadas ao mesmo tempo no barramento frontal, limitação não presente no QuickPath. Além disso, como o barramento frontal transfere tanto requisições de memória quanto de entrada/saída, sempre há mais dados sendo transferidos neste barramento se comparado ao QuickPath, que transporta apenas requisições de entrada/saída. Portanto o QuickPath trabalha “mais folgado” e por isso tem uma largura de banda disponível maior.

http://www.clubedohardware.com.br/artigos/Tudo-o-Que-Voce-Precisa-Saber-Sobre-o-Barramento-QuickPath/1554/2

Até aqui falamos de desempenho e diferenças entre os sistemas de interconexões e barramentos, mas uma boa novidade no QPI é a preocupação da INTEL em ter embutido um item de confiabilidade que ainda não estava muito presente no mercado.

Cada via de conexão do QPI pode ser tratada ou dividida em quatro sub-vias, dividindo assim a carga de 20bit por vez em cada via em 5bit por cada sub-via, o sistema ainda identifica se uma destas sub-vias tem um problema, isola ou desliga esta sub-via danificada e desta forma mantêm o sistema funcionando com um desempenho menor, mas funcionando. Este tipo de característica deverá aparecer mais nos processadores Xeon que são destinados principalmente para servidores e usados em algumas estações de trabalho de alto desempenho.

Coloquei aqui alguns dos principais pontos e características do Quick Path Interconnect e maiores informações poderão ser vistas na matéria completa do Clube do Hardware e no próprio site da Intel.

, , ,

No Comments

Gestão Matricial de Equipes de TI (Parte 1 – Problemas atuais)

Fonte:  http://blog.rpsinfo.com.br/2010/03/16/gestao-matricial-de-equipes-de-ti-parte-1-problemas-atuais/

O mercado atual, no que se refere a tecnologia da informação, se consolidou em um modelo de trabalho extremamente pautado nas tercerizações e nas contratações baseadas em pessoas jurídicas devido a todas as questões financeiras que provavelmente você que está lendo este artigo já deve estar cansado de saber (caso você não saiba, mande um e-mail e terei o maior prazer em explicar), e tal cenário, apesar de sanar alguns problemas e facilitar algumas situações gerenciais, criou outros problemas que fazem muitos gestores de equipes de TI literalmente perderem o sono com tais dificuldades gerenciais, problemas que na sua grande maioria estão ligados ao fator “gestão de pessoas”.

Vamos enumerar alguns destes problemas:

1) Por ser um modelo de contratação baseado em pessoas jurídicas, os distratos são mais fáceis e é muito comum um colaborador chegar da noite pro dia e se desligar da empresa/projeto deixando seus gestores com o problema deste desfalque não planejado.

2) É difícil, pra não dizer quase impossível, criar um plano de carreira que possa ser motivador financeiramente além de proporcionar a oportunidade de realização para profissionais que não ambicionam carreiras gerenciais, profissionais que queiram única e exclusivamente atuar em contextos técnicos.

3) É difícil definir uma estrutura de cargos / papéis / salários que seja justa e motivadora ao mesmo tempo, que de forma transparente permita ao profissional saber o que ele precisa fazer pra chegar ao patamar financeiro que ele ambiciona em curto, médio e longo prazo.

4) Muitos profissionais ruins e pouco produtivos conseguem esconder suas limitações e falta de produtividade dentro do time, levando com isso méritos da realização de todos os demais ou levando todos ao fracasso da não entrega ou da falta de qualidade do trabalho que acaba sendo atribuída ao time como um todo e não somente ao indivíduo.

5) Facilmente vemos alguns profissionais extremamente sobrecarregados e outros osciosos dentro de seus projetos.

6) Gestores que muitas vezes não geram resultados tão efetivos ao projeto quanto alguns profissionais mais envolvidos na realização acabam sendo muito melhor remunerados e tal discrepância salarial desmotiva o profissional que se vê garantindo a entrega.

7) Quando o profissional questiona sobre quais perspectivas existem pra ele na empresa quando ele não tem mais para onde crescer verticalmente, a empresa fica sem resposta e fatalmente em pouco tempo também perderá este talento.

Estes são só alguns dos muitos problemas que podemos presenciar hoje de forma muito comum em times de TI desde os menores até os grandes, onde seu gerenciamento é basicamente baseado em modelos hierárquicos de cargos e salários.

Daí vem a pergunta, “como é possível resolver isso?”.

Antes de responder, vamos primeiro fazer um pequeno exercício de reflexão nos colocando no lugar de um profissional que trabalha em baixo de uma estrutura hierárquica e que tem acima dele um determinado gestor, e que para ele poder ganhar mais ou ter mais oportunidades de realização precisa ser promovido para este cargo acima dele que hoje é ocupado por este gestor, com isso as alternativas que lhe restam são esperar que seu gestor seja promovido e que com isso ele tenha a chance de ocupar o seu cargo, esperar que seu gestor seja demitido e que com isso ele tenha a chance de ocupar o seu cargo, esperar que seu gestor morra e que com isso ele tenha a chance de ocupar o seu cargo ou então mudar de emprego… se você fosse este profissional, como você se sentiria? se você fosse este profissional, o que você faria? se você fosse este profissional, o que você gostaria que fizessem por você?

Pode ser que você ache que tudo isso que eu estou apresentando aqui seja pura e simplesmente fictício e fora da sua realidade, pode ser que você nuca tenha se deparado com nenhum destes problemas, pode ser que você esteja extremamente feliz  e satizfeito com a forma como você gerencia seu time de TI ou como você é gerenciado dentro de um time de TI e todos estes cenários que eu te apresentei são surreais e improvavéis, pode ser que você acredite no papai noel, no coelhinho da páscoa e no sací-perere, enfim se este for o seu caso, agradeço por ter lido este post até aqui e te recomendo não perder mais tempo por aqui, caso contrário peço que você leia a sequência deste artigo e debata comigo sobre a proposta que será apresentada para sanar tais problemas se não na sua totalidade, pelo menos na sua maioria.

No próximo post vamos tentar responder estas perguntas…

, ,

No Comments