Posts de February, 2010

[Rafael Biriba] VirtualBox: VMs com IPs estáticos e internet de maneira simples

Monday, February 22nd, 2010

virtualbox-imageTem certas coisas que você só aprende tentando… Mas esse assunto foi muito além desse princípio.

Durante toda a semana, procurei por soluções para colocar 2 máquinas virtuais acessíveis pela minha máquina hospedeira, com ip fixo e com internet.

O que acontece é o seguinte: Quem possui as versões mais atuais do virtualbox (a minha é a 3.1.2), possui uma opção de adaptador de rede, que se chama host-only. Ela cria uma conexão de rede em seu sistema hospedeiro, e utiliza um DHCP próprio para gerenciar as VMs, e com isso você consegue tanto utilizar internet, quanto se comunicar entre máquina real e máquina virtual.

O problema é que preciso garantir que estou dando SSH para a VM certa. O DHCP pode comprometer essa garantia.

O que tentei fazer… Atribuir um ip fixo na máquina virtual. Mas sem utilizar o DHCP, faz com que a VM fique sem conectividade com a internet.

Procurando pelo google, vi várias soluções que se resumiam em criar interfaces de redes virtuais para cada VM e compartilhando a conexão de internet entre elas, alterando tudo no arquivo /etc/netwotk/interfaces (ubuntu) e mais algumas outras coisas.

Eu não só testei várias soluções, como nenhuma delas funcionou, e ainda fiquei com alguns problemas de rede, mas que foram facilmente resolvidos.

Não querendo complicar uma coisa tão simples, consegui achar uma solução que resolve tudo com apenas alguns cliques, sem alterar nenhuma configuração e nem arriscar problemas na sua rede atual (eth0) =D

Então, vamos para a solução final:

Existe uma outra opção para sua interface de rede no virtualbox: NAT. Ela atribui um IP para sua VM, que é inacessível não só entre a maquina real e a virtual, quanto entre as máquinas virtuais também… Essa opção apenas libera o acesso à internet para a VM.

A solução foi utilizar 2 interfaces de rede para cada VM. A primeira interface foi definida como NAT e a segunda como host-only. A ordem é importante… Certifique-se que a primeira interface é a NAT. Também é necessário desativar o DHCP do host-only (Vá em Arquivo > Preferências > Rede > “Edite a Rede Virtual do Host-Only” > “Na aba Servidor DHCP, desmarque a opção Habilitar Servidor”).

Feito isso, inicie a VM e atribua um IP fixo para a interface que utiliza o host-only… E como eu disse acima, essa interface com ip fixo fica acessível entre as máquinas virtuais e a real, perdendo apenas a conexão com a internet. Mas como você configurou uma interface NAT anteriormente, o problema está resolvido! :)

virtual-box-rede-2-interfaces

A imagem acima é um pedaço da descrição de uma das minhas máquinas virtuais que rodam num virtualbox para windows. A idéia é a mesma tanto para windows quanto para linux. ;)

Curiosidade: Note que no windows o nome do adaptador de rede para o host-only é “VirtualBox Host-Only Ethernet Adapter” e no linux é “vboxnet0″.

Dica rápida: Se o seu virtualbox foi instalado pelo aptitude/synaptic do ubuntu (linux), certamente você possui uma versão velha e com poucos recursos… Sugiro baixar uma versão mais atual no site do virtualbox.

Se conseguir uma outra solução, não deixe de compartilhar aqui! :)
Espero ter ajudado !


Leia também:

[Igor Macaubas] Novo Blog: Agile Tales

Thursday, February 11th, 2010

É com prazer que anuncio a criação de mais um blog de minha autoria: o Agile Tales. O objetivo deste segundo blog é bem semelhante ao objetivo do meu blog atual: contar histórias e escrever artigos sobre desenvolvimento ágil de software, e coisas afins. A única diferença é a linguagem: este novo blog está em inglês. Já tinha um tempo que eu estava querendo criar um blog em uma outra língua, e consegui realizar esta empreitada com ajuda do Marcos Pereira. O Agile Tales será um trabalho assim: a quatro mãos. Iremos escrever, contribuir um com o post do outro, e colaborar para criar posts de altíssima qualidade.

O que nos motivou a fazer opção pelo Inglês como língua foi a possibilidade de trocar idéias e experiências com uma quantidade maior de pessoas. Queremos que mais e mais pessoas leiam nossos artigos, e comentem, e compartilhem suas experiências. E nesse aspecto, a nossa língua-mãe deixa um pouco a desejar: existem cerca de 200 milhões de pessoas no mundo que falam Português, enquanto existem cerca de 2 bilhões de pessoas que falam Inglês.

Eventualmente, alguns posts que eu escrever por lá vão aparecer na sua versão Brasileira por aqui. Eventualmente, não (no caso desse primeiro post, não vou traduzi-lo para Português). Enfim, agora que o menino nasceu, vamos ver como ele vai crescer.

Não deixem de conferir: http://agiletales.com

[Igor Macaubas] Globo.com: Estamos contratando!

Tuesday, February 9th, 2010

Você já deve conhecer a Globo.com: somos um dos maiores portais da Internet Brasileira. Por trás deste portal, existe uma grande equipe, composta por profissionais extremamente dedicados, competentes, comprometidos e apaixonados pelo que fazem. E estamos contratando!

Precisamos de você, caro desenvolvedor. Mas não de qualquer desenvolvedor: precisamos de desenvolvedores astros do rock, ninjas, samurais, enfim, os melhores desenvolvedores que conseguirmos encontrar! Nossa equipe atualmente é composta por excelentes profissionais, e precisamos de pessoas que estejam no nível desta excelência para trabalhar com a gente. Por isso, não desanimamos com as barreiras geográficas: aceitamos currículos de todo o Brasil.

Não estamos procurando especificamente por desenvolvedores Java, Python ou Ruby. Aqui nós temos uma grande miscelânia de linguagens e tecnologias, e estamos procurando profissionais capazes de usar a ferramenta certa para cada problema. Sabemos que as pessoas têm suas preferências e especialidades, e nós respeitamos isso, mas procuramos por pessoas que sejam capazes de aprender e re-aprender, e que sejam capazes não só de programar, mas de arquitetar, analisar, testar e trabalhar com novas tecnologias o tempo todo. Mesmo assim, conhecimento em Java, Python, Ruby, PHP e C/C++ são um grande diferencial. Como somos uma empresa de Internet, é muito bom ter forte conhecimentos em HTML, CSS e JavaScript. Também é um plus se você conhecer técnicas como AJAX e as APIs de JavaScript mais conhecidas (jQuery, etc).

Utilizamos largamente métodos ágeis, não só para gestão (Scrum/Kanban/Lean), mas também contamos com práticas de engenharia (TDD, BDD, Pair-programming, Continuous Integration) para enfrentar nosso dia-a-dia. Nosso lema é qualidade – quase nunca viramos noites, e procuramos não trabalhar em horas extras – e mesmo assim entregamos software de qualidade, no prazo, sem bugs. Procuramos pessoas organizadas, dedicadas e comprometidas, que saibam trabalhar bem em equipe, para entregar software da mais alta qualidade.

Lidamos diariamente com uma grande sopa de letrinhas: Python, Django, webservices REST e SOAP, Atompub, Apache, JBoss, JBossWeb, Tomcat, Weblogic, plataformas de encoding de mídias, HTML/CSS, Javascript, Flash, AJAX, Java, Ruby on Rails, PHP, Perl, C, C++, Linux, Open Solaris, Shellscript, Oracle, MySQL, Memcached, Varnish, Selenium, CruiseControl, FIT/Fitnesse, JUnit, JMock, OpenSocial, Capistrano, Hibernate/JPA, Spring, Chef, Cucumber, dentre muitas outras coisas. E você agora tem a oportunidade de se juntar a nós e trabalhar com isso tudo!

Por último, mas não menos importante, nós somos todos nerds, apaixonados por tecnologia e pelo nosso trabalho, e não nos contentamos em fazer o feijão com arroz. Estamos constantemente procurando nos superar, aprender coisas novas e estar sempre à frente. Somos uma equipe jovem, descontraída, e em constante evolução. E procuramos pessoas assim!

As vagas são localizadas no Rio de Janeiro, na Barra da Tijuca, e se você topar o desafio, terá que se mudar para cá. Não aceitamos home-office, nem temos escritórios em outras regiões do Brasil. Nosso modelo de contratação é exclusivamente por CLT, com salário de mercado e plano de benefícios.

Se você acha que se enquadra, não perca tempo, nos envie seu currículo.

[Tiago Motta] Upload de arquivo com selenium server no firefox

Tuesday, February 9th, 2010

Para fazer upload de arquivo com selenium é preciso alterar seu selenium-server.jar liberando permissão para que seja possível manipular campos do tipo file por javascript. Para fazer isso, extraia o selenium-server.jar:

jar -xvf selenium-server.jar

Crie um arquivo chamado user.js no diretório customProfileDirCUSTFF contendo um código semelhante com o exibido abaixo:

user_pref("signed.applets.codebase_principal_support", true);

user_pref("capability.principal.codebase.p0.granted", "UniversalFileRead");user_pref("capability.principal.codebase.p0.id", "http://localhost");user_pref("capability.principal.codebase.p0.subjectName", "");

Repare que a liberação de acesso é feita por host. No caso do exemplo estou liberando apenas para o ambiente local. Se desejar liberar outros hosts baixa adicionar outros conforme o exemplo abaixo:

user_pref("signed.applets.codebase_principal_support", true);

user_pref("capability.principal.codebase.p0.granted", "UniversalFileRead");user_pref("capability.principal.codebase.p0.id", "http://localhost");user_pref("capability.principal.codebase.p0.subjectName", "");

user_pref("capability.principal.codebase.p1.granted", "UniversalFileRead");user_pref("capability.principal.codebase.p1.id", "http://globo.com");user_pref("capability.principal.codebase.p1.subjectName", "");

Feito isso, basta gerar novamente o jar e executá-lo.

jar cvfm selenium-server.jar ./META-INF/MANIFEST.MF -C ./ .java -jar selenium-server.jar

Já será possivel preencher o path de qualquer arquivo no campo como se ele fosse apenas um campo de textos. Isso no Firefox é claro.

[Victor Pantoja] Vaga de Estágio na Área de Infra-estrutura da Globo.com

Monday, February 8th, 2010

Venha trabalhar com  a gente e dê um clique decisivo no seu futuro.

ESTÁGIO EM TECNOLOGIA PARA GLOBO.COM

A GLOBO.COM é um dos 4 maiores portais brasileiros que possui em torno de 14 milhões de visitantes únicos domiciliar/mês;

Procuramos por Estudantes de Análise de Sistemas, Ciência da Computação, Engenharia da Computação e afins, com o perfil abaixo:

* Previsão de formatura: dezembro/2010 a dezembro/2011.
* Pessoas dinâmicas, criativas e fascinadas por internet.
* Interesse em estagiar com projeto e manutenção de infra-estrutura.

Envie seu currículo para talentos@corp.globo.com

Para maiores informações acesse: www.globo.com/estag

Espalhe a notícia para seus amigos e parentes que estejam interessados.

Avise-os por e-mail, MSN, Orkut ou pelo Twitter.

Não deixe-os perder essa oportunidade!

CONTAMOS COM SUA PARTICIPAÇÃO! DIVULGUE!

EQUIPE GLOBO.COM

[Rafael Biriba] Cloud Crowd: A primeira action

Monday, February 8th, 2010

cloud-crowd

Cloud Crowd é um controlador de filas para processamento paralelo, desenvolvido em ruby. Pode ser utilizado em Encoding de video, migração de arquivos e bancos de dados, redimensionamento de imagens e etc…

Uma explicação rápida: Em uma máquina você levanta o server, onde é gerenciado a fila (criação, exclusão, status das tarefas e etc…). Em outras máquinas você levanta o node, onde as terefas serão recebidas e executadas. Ao terminar, o node informa ao server, liberando-se para receber outra tarefa.

Essa semana comecei a desvendar os benefícios do Cloud Crowd, principalmente para encoding paralelo de vídeo. Mas antes, tive que entender como ele funciona e o que tem para nos oferecer.

Então, acompanhando o “tutorial” em http://wiki.github.com/documentcloud/cloud-crowd/writing-an-action, escrevi uma pequena action:

class HelloWorld < CloudCrowd::Action
   def process
      Thin::Logging.log("HelloWorld :: -- criando arquivo #{input}!")
      `touch #{input}`
      0
   end
end

Você passa um nome qualquer, e o script cria um arquivo em branco. Simples !?, Mas serviu bem para meus primeiros testes.

Também aproveitei e usei o log do Thin que é o servidor que o Cloud Crowd levanta, para registrar o evento de dentro da action… Isso significa que as mensagens de log da minha action foram registradas no arquivo de log do node que a executou… Se preferir você pode utilizar o Logger do Rails. Como foi apenas um experimento, utilizei o do Thin mesmo.

Cadastrando tarefas:

Para começar a utilizar sua action,  você precisa postar um JSON com as informações necessárias no server, para cadastrar uma tarefa. (Não preciso lembrar que o server e algum node deve estar rodando, certo ?)

Para isso, crie um script ruby, ou rode pelo irb os comandos*:

require 'rubygems'
require 'restclient'
require 'json'
RestClient.post('http://localhost:9173/jobs',{:job => { 'action' => 'hello_world' , 'inputs' => ['/home/rafael/arquivo_teste1', '/home/rafael/arquivo_teste2']}.to_json})

Considerando que o server está rodando na máquina que rodou o script. Caso contrário, altere o localhost pelo ip do Server. E os arquivos são criados (pelo comando “touch”) na máquina que roda o Node. Para fins de teste e desenvolvimento, é possível rodar o server e o node na mesma máquina, já que eles sobem em portas diferentes…

Então é isso… Você já pode paralelizar qualquer tarefa. Basta escrever suas próprias actions… ;)

 


Leia também:

[Rafael Biriba] Primeira festa de aniversário do blog

Friday, February 5th, 2010

1-ano-rafaelbiribablog-mini

Hoje (05/02), o blog comemora 1 ano de existência. E não existe nada melhor do que comemorar com festa.

Como o Blog está recebendo pequenos “ganhos” com as publicidades, resolvi organizar uma festa “simbólica” no dia 03/02 junto com o pessoal da Globo.com. Por sorte o Leonardo Quixadá (Client-Side do time de vídeos), fazia aniversário no mesmo dia da festa e aproveitou para comemorar o seu aniversário. (Mais abaixo o vídeo e as fotos da festa)

Desde o lançamento (05/02/2009) até agora, o blog teve quase 30 mil acessos e mais de 75 mil páginas visualizadas.

Aproveito a ocasião para agradecer ao Bruno Souza, que me incentivou a criar o blog. A idéia de compartilhar conhecimentos com o mundo e ter muitos e muitos acessos por mês foi tudo o que eu precisei ouvir para criar o blog.

whois-rafaelbiribablog

Agradeço também a todos os leitores, principalmente os assíduos, pelo apoio e participação nos comentários. Tem alguns que me mandam emails constantemente cobrando posts novos no blog. Prometo que vou pensar num jeito de recompensa-los… Quem sabe com promoções e sorteios ? :)

O maior desafio mesmo é escrever um post de qualidade. Se tiver algum blogueiro lendo isso, vai saber do que eu estou falando. Procurar um tema bom, escrever, revisar, consertar alguns erros, revisar de novo, e etc… Mas a recompensa de todo esse esforço vem ao analisar as estatísticas do blog ;)

Um abraço a todos os leitores,

Vídeo da festa:

http://www.youtube.com/watch?v=4ps8FDOPtJA

 

Fotos:

Banner improvisado em cima da hora !Arrumação Inicial =DFesta de aniversário do blog: 1 anoBolo ou tortinha simbólica da festa...Festa de aniversário do blog: 1 anoAlgumas pessoas da equipe de vídeos da Globo.comFesta de aniversário do blog: 1 anoFesta de aniversário do blog: 1 anoFesta de aniversário do blog: 1 ano5 min. depois da festa... haha

 


 


Leia também:

[Emerson Macedo] Não se apaixone pela sua tecnologia

Wednesday, February 3rd, 2010

Cansado das briguinhas recentes em listas de discussão, blogs e foruns sobre Ruby x Python, resolvi escrever sobre o assunto de forma totalmente imparcial. Serei imparcial, não por causa do blog, mas porque com esse tipo de assunto eu sempre geralmente sou imparcial, pois pela diversidade de empresas que trabalhei durante os meus mais de 12 anos de carreira, acabei sempre trabalhando com as 2 linguagens que eram o motivo da briguinha, em cada época distinta.

No início

Em meados de 1997/1998, pouco antes da bolha da internet, quando eu comecei a trabalhar profissionalmente, eu trabalhava com eletrônica e informática em uma empresa de automação de ponto e acesso. Tive a oportunidade de usar Delphi para desenvolver um protótipo de sistema integrado ao hardware de ponto e acesso dessa empresa, pois eles usavam um programas DOS para extrair dados e jogar num arquivo texto, e o outro programa DOS fazia a leitura desse arquivo para gerar o resuldado de ponto e o acesso. Foi uma experiência ótima, pois meu protótipo acessava diretamente o equipamento pela porta serial e já mostrava as informações em tempo real. Essa idéia foi pouco tempo depois usada pela fábrica para novas versões do software.

Nessa época, a programação desktop ainda reinava e as opções mais comuns eram Delphi e Visual Basic, então sempre algum colega ou outro puxava a sardinha pro lado do Delphi ou do VB. Nessa época, confesso que eu era meio bobo no assunto e eu acabava entrando na onda também, principalmente falando mau do coitado do VB. Tempos depois acabei trabalhando com VB em outros lugares e pude perceber que existia aplicação para ele dependendo do caso. Confesso que sempre gostei mais do Delphi, mas nesse momento eu deixava de ser um apaixonado e passava a fazer a escolha de forma mais racional.

Surge o desenvolvimento pra Web

Quando começei a trabalhar com web em meados de 2000, trabalhei com PERL, depois ASP e ColdFusion. Nesse tempo, surgiu a versão Beta do DotNET em 2001. Foi quando comecei a desenvolver aplicações desktop em WindowsForms e alguma coisa web, com o objetivo de aprender.

Passado pouco tempo e fui trabalhar numa empresa onde usavam tudo da Microsoft. Java nem pensar nessa empresa. Todos falavam mau da Sun e do Java. Nessa época eu já estava bem escaldado com isso e não ia cair nessa novamente, perdendo meu tempo discutindo sobre quem era melhor, Java ou DotNET.

Passado mais um tempo, fui para uma outra empresa onde tinha projetos em DotNET, mas também tinha projetos Java. Como eu já estava estudando Java fazia um tempo, era uma ótima oportunidade para por em prática em algum projeto. Assim que surgiu uma vaga, me ofereci para entrar num projeto de um grande ecommerce brasileiro (que por algumas questões não posso citar o nome). Esse projeto foi ótimo para eu por em prática meus conhecimentos de Java. Nesse momento eu percebi que o pessoal de Java também gostava de falar mau do pessoal de DotNET. Na minha mente estava bem claro que isso era pura perda de tempo, pois claramente nos projetos que eu havia trabalhado eu pude perceber o valor de cada uma dessas tecnologias em cada contexto.

Passou o tempo e acabei não trabalhando mais com DotNET. As empresas seguintes foram todas com Java, exceto aqui na globo.com, onde voltarei a falar mais pra frente.

Muitos FUDs

Uma coisa que sempre percebi nessas brigas é que raramente usava-se argumentos lógicos e bem fundamentados. Geralmente as discussões eram baseadas em achismos e usavam algum argumento falacioso ou duvidoso/pouco claro.

Quando trabalhei para algumas empresas de Telecomunicações, Bancos e Seguradoras aqui no Rio de Janeiro, quase sempre havia um bom legado em COBOL e seus velhinhos de plantão dando manutenção nesses sistemas. Volta e meia eu ouvia algo do tipo: “Esse negócio de Java é apertar botãozinho e ta tudo pronto. Homem que é homem programa em COBOL”. Isso não fazia o menor sentido e por mais que eu tentasse explicar pros caras que não era bem assim, não adiantava, já existia uma opinião sem fundamentos formada na cabeça deles.

Numa dessas últimas empresas que trabalhei (para um dos maiores Bancos do nosso país), eu era Arquiteto junto com mais 14 desenvolvedores em um projeto Java que precisava se comunicar com programas COBOL/CICS. Sabe o que os COBOLEIROS diziam? “Só usem java pra pegar o que for processado aqui no COBOL porque aqui é que aguenta o tranco. Esse negócio de Java só serve para a parte levinha“. Apesar de conhecer sobre todo o poder de processamento dos Mainframes, eu sabia que aquilo era apenas uma provocação, pois eu já havia trabalhado em sistemas web feitos com Java com volumes bem maiores que os desse sistema e tudo correu muito bem. Sendo assim, nem entrei em discussão sobre isso, pois eles já tinham se fechado para o assunto.

Nossos dias atuais

Hoje em dia está muito na moda o uso de linguagens dinâmicas como Ruby e Python para desenvolvimento de software, muitos deles aplicações web. Existem diversos casos de sucesso usando essas tecnologias, e mais uma vez surgem as brigas pra saber qual é a melhor: Ruby ou Python.

Não espere aqui uma opinião minha sobre o que é melhor entre as 2, pois isso não vai acontecer. Não porque eu não tenha preferências, mas simplesmente porque melhor ou pior sempre dependerá do contexto e não somente da tecnologia.

Python é uma linguagem muito usada no mundo opensource, tendo muitos aplicativos console e desktop desenvolvidos para linux. A primeira versão do Youtube foi escrita em Python (não sei se ainda é). O Google AppEngine apesar de suportar Java, foi construido para Python. Existem diversas iniciativas que usam Python e são bem sucedidas.

Ruby apesar de ser uma linguagem bem antiga (1993), só explodiu mesmo com a chegada do Rails (2004/2005). Antes disso ninguém ouvia falar de Ruby. Mesmo assim, Rails trouxe uma ascensão meteórica para o Ruby, surgindo um ecosistema incrível, com uma série de produtos bem sucedidos e documentações fantasticas, screencasts, entre outros. Destacou-se muito com as ferramentas de testes automatizados que tanto precisamos hoje em dia para desenvolvermos software com qualidade.

No time onde eu trabalho na globo.com, desenvolvemos projetos em Java, em Python/Django e Ruby on Rails (projeto atual). Cada uma das escolhas teve razões lógicas e seus benefícios (que se comprovaram). Essa versatilidade faz com que esse time possa trabalhar em praticamente qualquer projeto da empresa, já que tem conhecimento nas principais linguagens que a empresa trabalha. Isso é muito mais benéfico do que ficar preso a uma tecnologia, defendendo-a com unhas e dentes.

O Mito do não escala

Com o advento dessas linguagens dinâmicas, deu bem pra perceber como a maioria dos profissionais não entendia/não entende quase nada sobre escalabilidade de sistemas web. Assim como o COBOLEIRO falava que o Java não aguentava o tranco, começaram a falar que linguagens dinâmicas não escalavam, principalmente o famoso “Rails não escala”.

Certa vez eu lí um post de 2004 (antes do Rails) que já falava sobre esse mito de não escala. Vale a pena conferir aqui. E tem também um screencast mais recente(baixe o vídeo e assista) do Gregg Pollack que nos primeiros minutos mostra na maioria das vezes o que deixa um site lento. Dica: tem pouco a ver com a tecnologia usada.

Portanto, não caia nessa. Pesquise e aprenda como escalar sua aplicação, independente de você estar usando Python/Django Ruby/Rails, Java, DotNET ou qualquer outra tenologia do seu projeto.

Conclusão

Mesmo com essas 2 tecnologias (Ruby e Python) fazendo seu sucesso nos dias de hoje e tendo seu contexto para serem aplicadas, o pessoal ainda continua brigando pra defender a sua tecnologia preferida. Parece que cria-se uma paixão cega pela linguagem, como se fosse uma espécie de religião, saindo do racional e passando a ser totalmente irracional.

Dessa forma, meu conselho para todos os profissionais é que não entrem nessa de ficar defendendo sua tecnologia preferida e atirando pedra na tecnologia concorrente. Aprenda ambas e saiba onde e quando usar cada uma delas.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

[Emerson Macedo] Não se apaixone pela sua tecnologia

Wednesday, February 3rd, 2010

Cansado das briguinhas recentes em listas de discussão, blogs e foruns sobre Ruby x Python, resolvi escrever sobre o assunto de forma totalmente imparcial. Serei imparcial, não por causa do blog, mas porque com esse tipo de assunto eu sempre geralmente sou imparcial, pois pela diversidade de empresas que trabalhei durante os meus mais de 12 anos de carreira, acabei sempre trabalhando com as 2 linguagens que eram o motivo da briguinha, em cada época distinta.

No início

Em meados de 1997/1998, pouco antes da bolha da internet, quando eu comecei a trabalhar profissionalmente, eu trabalhava com eletrônica e informática em uma empresa de automação de ponto e acesso. Tive a oportunidade de usar Delphi para desenvolver um protótipo de sistema integrado ao hardware de ponto e acesso dessa empresa, pois eles usavam um programas DOS para extrair dados e jogar num arquivo texto, e o outro programa DOS fazia a leitura desse arquivo para gerar o resuldado de ponto e o acesso. Foi uma experiência ótima, pois meu protótipo acessava diretamente o equipamento pela porta serial e já mostrava as informações em tempo real. Essa idéia foi pouco tempo depois usada pela fábrica para novas versões do software.

Nessa época, a programação desktop ainda reinava e as opções mais comuns eram Delphi e Visual Basic, então sempre algum colega ou outro puxava a sardinha pro lado do Delphi ou do VB. Nessa época, confesso que eu era meio bobo no assunto e eu acabava entrando na onda também, principalmente falando mau do coitado do VB. Tempos depois acabei trabalhando com VB em outros lugares e pude perceber que existia aplicação para ele dependendo do caso. Confesso que sempre gostei mais do Delphi, mas nesse momento eu deixava de ser um apaixonado e passava a fazer a escolha de forma mais racional.

Surge o desenvolvimento pra Web

Quando começei a trabalhar com web em meados de 2000, trabalhei com PERL, depois ASP e ColdFusion. Nesse tempo, surgiu a versão Beta do DotNET em 2001. Foi quando comecei a desenvolver aplicações desktop em WindowsForms e alguma coisa web, com o objetivo de aprender.

Passado pouco tempo e fui trabalhar numa empresa onde usavam tudo da Microsoft. Java nem pensar nessa empresa. Todos falavam mau da Sun e do Java. Nessa época eu já estava bem escaldado com isso e não ia cair nessa novamente, perdendo meu tempo discutindo sobre quem era melhor, Java ou DotNET.

Passado mais um tempo, fui para uma outra empresa onde tinha projetos em DotNET, mas também tinha projetos Java. Como eu já estava estudando Java fazia um tempo, era uma ótima oportunidade para por em prática em algum projeto. Assim que surgiu uma vaga, me ofereci para entrar num projeto de um grande ecommerce brasileiro (que por algumas questões não posso citar o nome). Esse projeto foi ótimo para eu por em prática meus conhecimentos de Java. Nesse momento eu percebi que o pessoal de Java também gostava de falar mau do pessoal de DotNET. Na minha mente estava bem claro que isso era pura perda de tempo, pois claramente nos projetos que eu havia trabalhado eu pude perceber o valor de cada uma dessas tecnologias em cada contexto.

Passou o tempo e acabei não trabalhando mais com DotNET. As empresas seguintes foram todas com Java, exceto aqui na globo.com, onde voltarei a falar mais pra frente.

Muitos FUDs

Uma coisa que sempre percebi nessas brigas é que raramente usava-se argumentos lógicos e bem fundamentados. Geralmente as discussões eram baseadas em achismos e usavam algum argumento falacioso ou duvidoso/pouco claro.

Quando trabalhei para algumas empresas de Telecomunicações, Bancos e Seguradoras aqui no Rio de Janeiro, quase sempre havia um bom legado em COBOL e seus velhinhos de plantão dando manutenção nesses sistemas. Volta e meia eu ouvia algo do tipo: “Esse negócio de Java é apertar botãozinho e ta tudo pronto. Homem que é homem programa em COBOL”. Isso não fazia o menor sentido e por mais que eu tentasse explicar pros caras que não era bem assim, não adiantava, já existia uma opinião sem fundamentos formada na cabeça deles.

Numa dessas últimas empresas que trabalhei (para um dos maiores Bancos do nosso país), eu era Arquiteto junto com mais 14 desenvolvedores em um projeto Java que precisava se comunicar com programas COBOL/CICS. Sabe o que os COBOLEIROS diziam? “Só usem java pra pegar o que for processado aqui no COBOL porque aqui é que aguenta o tranco. Esse negócio de Java só serve para a parte levinha“. Apesar de conhecer sobre todo o poder de processamento dos Mainframes, eu sabia que aquilo era apenas uma provocação, pois eu já havia trabalhado em sistemas web feitos com Java com volumes bem maiores que os desse sistema e tudo correu muito bem. Sendo assim, nem entrei em discussão sobre isso, pois eles já tinham se fechado para o assunto.

Nossos dias atuais

Hoje em dia está muito na moda o uso de linguagens dinâmicas como Ruby e Python para desenvolvimento de software, muitos deles aplicações web. Existem diversos casos de sucesso usando essas tecnologias, e mais uma vez surgem as brigas pra saber qual é a melhor: Ruby ou Python.

Não espere aqui uma opinião minha sobre o que é melhor entre as 2, pois isso não vai acontecer. Não porque eu não tenha preferências, mas simplesmente porque melhor ou pior sempre dependerá do contexto e não somente da tecnologia.

Python é uma linguagem muito usada no mundo opensource, tendo muitos aplicativos console e desktop desenvolvidos para linux. A primeira versão do Youtube foi escrita em Python (não sei se ainda é). O Google AppEngine apesar de suportar Java, foi construido para Python. Existem diversas iniciativas que usam Python e são bem sucedidas.

Ruby apesar de ser uma linguagem bem antiga (1993), só explodiu mesmo com a chegada do Rails (2004/2005). Antes disso ninguém ouvia falar de Ruby. Mesmo assim, Rails trouxe uma ascensão meteórica para o Ruby, surgindo um ecosistema incrível, com uma série de produtos bem sucedidos e documentações fantasticas, screencasts, entre outros. Destacou-se muito com as ferramentas de testes automatizados que tanto precisamos hoje em dia para desenvolvermos software com qualidade.

No time onde eu trabalho na globo.com, desenvolvemos projetos em Java, em Python/Django e Ruby on Rails (projeto atual). Cada uma das escolhas teve razões lógicas e seus benefícios (que se comprovaram). Essa versatilidade faz com que esse time possa trabalhar em praticamente qualquer projeto da empresa, já que tem conhecimento nas principais linguagens que a empresa trabalha. Isso é muito mais benéfico do que ficar preso a uma tecnologia, defendendo-a com unhas e dentes.

O Mito do não escala

Com o advento dessas linguagens dinâmicas, deu bem pra perceber como a maioria dos profissionais não entendia/não entende quase nada sobre escalabilidade de sistemas web. Assim como o COBOLEIRO falava que o Java não aguentava o tranco, começaram a falar que linguagens dinâmicas não escalavam, principalmente o famoso “Rails não escala”.

Certa vez eu lí um post de 2004 (antes do Rails) que já falava sobre esse mito de não escala. Vale a pena conferir aqui. E tem também um screencast mais recente(baixe o vídeo e assista) do Gregg Pollack que nos primeiros minutos mostra na maioria das vezes o que deixa um site lento. Dica: tem pouco a ver com a tecnologia usada.

Portanto, não caia nessa. Pesquise e aprenda como escalar sua aplicação, independente de você estar usando Python/Django Ruby/Rails, Java, DotNET ou qualquer outra tenologia do seu projeto.

Conclusão

Mesmo com essas 2 tecnologias (Ruby e Python) fazendo seu sucesso nos dias de hoje e tendo seu contexto para serem aplicadas, o pessoal ainda continua brigando pra defender a sua tecnologia preferida. Parece que cria-se uma paixão cega pela linguagem, como se fosse uma espécie de religião, saindo do racional e passando a ser totalmente irracional.

Dessa forma, meu conselho para todos os profissionais é que não entrem nessa de ficar defendendo sua tecnologia preferida e atirando pedra na tecnologia concorrente. Aprenda ambas e saiba onde e quando usar cada uma delas.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

[Emerson Macedo] Não se apaixone pela sua tecnologia

Wednesday, February 3rd, 2010

Cansado das briguinhas recentes em listas de discussão, blogs e foruns sobre Ruby x Python, resolvi escrever sobre o assunto de forma totalmente imparcial. Serei imparcial, não por causa do blog, mas porque com esse tipo de assunto eu sempre geralmente sou imparcial, pois pela diversidade de empresas que trabalhei durante os meus mais de 12 anos de carreira, acabei sempre trabalhando com as 2 linguagens que eram o motivo da briguinha, em cada época distinta.

No início

Em meados de 1997/1998, pouco antes da bolha da internet, quando eu comecei a trabalhar profissionalmente, eu trabalhava com eletrônica e informática em uma empresa de automação de ponto e acesso. Tive a oportunidade de usar Delphi para desenvolver um protótipo de sistema integrado ao hardware de ponto e acesso dessa empresa, pois eles usavam um programas DOS para extrair dados e jogar num arquivo texto, e o outro programa DOS fazia a leitura desse arquivo para gerar o resuldado de ponto e o acesso. Foi uma experiência ótima, pois meu protótipo acessava diretamente o equipamento pela porta serial e já mostrava as informações em tempo real. Essa idéia foi pouco tempo depois usada pela fábrica para novas versões do software.

Nessa época, a programação desktop ainda reinava e as opções mais comuns eram Delphi e Visual Basic, então sempre algum colega ou outro puxava a sardinha pro lado do Delphi ou do VB. Nessa época, confesso que eu era meio bobo no assunto e eu acabava entrando na onda também, principalmente falando mau do coitado do VB. Tempos depois acabei trabalhando com VB em outros lugares e pude perceber que existia aplicação para ele dependendo do caso. Confesso que sempre gostei mais do Delphi, mas nesse momento eu deixava de ser um apaixonado e passava a fazer a escolha de forma mais racional.

Surge o desenvolvimento pra Web

Quando começei a trabalhar com web em meados de 2000, trabalhei com PERL, depois ASP e ColdFusion. Nesse tempo, surgiu a versão Beta do DotNET em 2001. Foi quando comecei a desenvolver aplicações desktop em WindowsForms e alguma coisa web, com o objetivo de aprender.

Passado pouco tempo e fui trabalhar numa empresa onde usavam tudo da Microsoft. Java nem pensar nessa empresa. Todos falavam mau da Sun e do Java. Nessa época eu já estava bem escaldado com isso e não ia cair nessa novamente, perdendo meu tempo discutindo sobre quem era melhor, Java ou DotNET.

Passado mais um tempo, fui para uma outra empresa onde tinha projetos em DotNET, mas também tinha projetos Java. Como eu já estava estudando Java fazia um tempo, era uma ótima oportunidade para por em prática em algum projeto. Assim que surgiu uma vaga, me ofereci para entrar num projeto de um grande ecommerce brasileiro (que por algumas questões não posso citar o nome). Esse projeto foi ótimo para eu por em prática meus conhecimentos de Java. Nesse momento eu percebi que o pessoal de Java também gostava de falar mau do pessoal de DotNET. Na minha mente estava bem claro que isso era pura perda de tempo, pois claramente nos projetos que eu havia trabalhado eu pude perceber o valor de cada uma dessas tecnologias em cada contexto.

Passou o tempo e acabei não trabalhando mais com DotNET. As empresas seguintes foram todas com Java, exceto aqui na globo.com, onde voltarei a falar mais pra frente.

Muitos FUDs

Uma coisa que sempre percebi nessas brigas é que raramente usava-se argumentos lógicos e bem fundamentados. Geralmente as discussões eram baseadas em achismos e usavam algum argumento falacioso ou duvidoso/pouco claro.

Quando trabalhei para algumas empresas de Telecomunicações, Bancos e Seguradoras aqui no Rio de Janeiro, quase sempre havia um bom legado em COBOL e seus velhinhos de plantão dando manutenção nesses sistemas. Volta e meia eu ouvia algo do tipo: “Esse negócio de Java é apertar botãozinho e ta tudo pronto. Homem que é homem programa em COBOL”. Isso não fazia o menor sentido e por mais que eu tentasse explicar pros caras que não era bem assim, não adiantava, já existia uma opinião sem fundamentos formada na cabeça deles.

Numa dessas últimas empresas que trabalhei (para um dos maiores Bancos do nosso país), eu era Arquiteto junto com mais 14 desenvolvedores em um projeto Java que precisava se comunicar com programas COBOL/CICS. Sabe o que os COBOLEIROS diziam? “Só usem java pra pegar o que for processado aqui no COBOL porque aqui é que aguenta o tranco. Esse negócio de Java só serve para a parte levinha“. Apesar de conhecer sobre todo o poder de processamento dos Mainframes, eu sabia que aquilo era apenas uma provocação, pois eu já havia trabalhado em sistemas web feitos com Java com volumes bem maiores que os desse sistema e tudo correu muito bem. Sendo assim, nem entrei em discussão sobre isso, pois eles já tinham se fechado para o assunto.

Nossos dias atuais

Hoje em dia está muito na moda o uso de linguagens dinâmicas como Ruby e Python para desenvolvimento de software, muitos deles aplicações web. Existem diversos casos de sucesso usando essas tecnologias, e mais uma vez surgem as brigas pra saber qual é a melhor: Ruby ou Python.

Não espere aqui uma opinião minha sobre o que é melhor entre as 2, pois isso não vai acontecer. Não porque eu não tenha preferências, mas simplesmente porque melhor ou pior sempre dependerá do contexto e não somente da tecnologia.

Python é uma linguagem muito usada no mundo opensource, tendo muitos aplicativos console e desktop desenvolvidos para linux. A primeira versão do Youtube foi escrita em Python (não sei se ainda é). O Google AppEngine apesar de suportar Java, foi construido para Python. Existem diversas iniciativas que usam Python e são bem sucedidas.

Ruby apesar de ser uma linguagem bem antiga (1993), só explodiu mesmo com a chegada do Rails (2004/2005). Antes disso ninguém ouvia falar de Ruby. Mesmo assim, Rails trouxe uma ascensão meteórica para o Ruby, surgindo um ecosistema incrível, com uma série de produtos bem sucedidos e documentações fantasticas, screencasts, entre outros. Destacou-se muito com as ferramentas de testes automatizados que tanto precisamos hoje em dia para desenvolvermos software com qualidade.

No time onde eu trabalho na globo.com, desenvolvemos projetos em Java, em Python/Django e Ruby on Rails (projeto atual). Cada uma das escolhas teve razões lógicas e seus benefícios (que se comprovaram). Essa versatilidade faz com que esse time possa trabalhar em praticamente qualquer projeto da empresa, já que tem conhecimento nas principais linguagens que a empresa trabalha. Isso é muito mais benéfico do que ficar preso a uma tecnologia, defendendo-a com unhas e dentes.

O Mito do não escala

Com o advento dessas linguagens dinâmicas, deu bem pra perceber como a maioria dos profissionais não entendia/não entende quase nada sobre escalabilidade de sistemas web. Assim como o COBOLEIRO falava que o Java não aguentava o tranco, começaram a falar que linguagens dinâmicas não escalavam, principalmente o famoso “Rails não escala”.

Certa vez eu lí um post de 2004 (antes do Rails) que já falava sobre esse mito de não escala. Vale a pena conferir aqui. E tem também um screencast mais recente(baixe o vídeo e assista) do Gregg Pollack que nos primeiros minutos mostra na maioria das vezes o que deixa um site lento. Dica: tem pouco a ver com a tecnologia usada.

Portanto, não caia nessa. Pesquise e aprenda como escalar sua aplicação, independente de você estar usando Python/Django Ruby/Rails, Java, DotNET ou qualquer outra tenologia do seu projeto.

Conclusão

Mesmo com essas 2 tecnologias (Ruby e Python) fazendo seu sucesso nos dias de hoje e tendo seu contexto para serem aplicadas, o pessoal ainda continua brigando pra defender a sua tecnologia preferida. Parece que cria-se uma paixão cega pela linguagem, como se fosse uma espécie de religião, saindo do racional e passando a ser totalmente irracional.

Dessa forma, meu conselho para todos os profissionais é que não entrem nessa de ficar defendendo sua tecnologia preferida e atirando pedra na tecnologia concorrente. Aprenda ambas e saiba onde e quando usar cada uma delas.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.