Estamos procurando um bom desenvolvedor com o seguinte perfil:

– HTML avançado, incluindo tópicos como HTML5, canvas, vídeo e desenvolvimento web para iPhone/iPad
– Javascript avançado (saber só jQuery, sem entender a linguagem não vale)
– Experiência em desenvolvimento web/server side
– Entendimento básico de infra-estrutura. Protocolos, redes e funcionamento de um
sistema de computadores.
– Flash/ActionScript3 é um baita bônus.
– Paixão por produtos, mais do que tecnologias, técnicas e código.
– Saiba trabalhar em conjunto com outras disciplinas do projeto (Designer, UX, clientes)
buscando o sucesso do produto.

Os produtos desenvolvidos pelo time beta atualmente utilizam Ruby on Rails 3, MongoDB, Solr, entre outras
tecnologias. Dito isso, ressaltamos que é mais importante que o candidato tenha um perfil auto-didata e
inovador do que ser especialista nessas tecnologias.

Se você se encaixa em pelo menos 70% desse perfil e têm garra para aprender
envie um email para beta@corp.globo.com com:

– Pequena apresentação
– Endereço do LinkedIn (preferência) ou currículo em PDF
– Endereço do github
– Últimos 3 livros que leu (técnicos e não técnicos)

A Globo.com oferece contratação apenas por CLT, com salário de mercado e plano de benefícios. Estamos
localizados na Barra da Tijuca, Rio de Janeiro. Damos suporte à pessoas de outros estados que queiram
mudar para o Rio.

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

O Dev in Rio 2009, uma conferência inédita sobre desenvolvimento de software que acontecerá no próximo dia 14 de setembro no Centro de Convenções SulAmérica, no Rio de Janeiro!

O evento está sendo organizado pelo Guilherme Chapiewski em parceria com o Henrique Bastos e a realização está sendo coordenada pela Arteccom.

Informações no site do evento.

Criamos a cultura de criar uma integração contínua para todos os projetos. Isso envolve testes unitários, funcionais e de aceitação.

Nossos sites possuem dois perfis: iphone e standard (para tudo que não for iphone). Essa diferenciação é feita através de uma regra de apache (mod_rewrite) que inclui /iphone ou /standard na URL sem que o usuário veja. Para rodar os testes de integração contínua, essa regra não é criada e chamamos a url com o /perfil

Pois bem: estamos trabalhando em uma aplicação WEB em que não é possível passar o /perfil
por alguns motivos. Então, nos deparamos com um problema: como testar os múltiplos perfis de handsets?

A solução foi criar dois profiles no Firefox (iPhone e Standard) e passa-los para o Selenium. Separamos os testes de aceitação nos dois profiles e rodamos um após o outro (usamos Makefile).

Um profile pode ser criado com o comando $ firefox -P.

Mas veio a pergunta: como criar um profile iPhone e outro standard? A solução foi usar o about:config do Firefox (digite isso no campo url: ‘about:config’, sem as aspas. Não mexa nos campos se você não souber o que está fazendo).

O campo selecionado de vermelho é exatamente o que deve ser alterado. No momento da criação do profile, alteramos essa propriedade de acordo com o profile que estamos criando. Dê dois cliques e digite o user-agent que você deseja. Eu uso ‘iPhone’ para o profile iPhone e ‘NokiaN90′ para o profile standard.

Eu salvei em /home//iphone e /home//standard. O selenium deve ser inicializado assim:
$ java -jar selenium.jar -firefoxProfileTemplate “/home/usuario/iphone” ou
$ java -jar selenium.jar -firefoxProfileTemplate “/home/usuario/standard”

Depois, joguei esses profiles dentro do projeto e acertei o selenium para chama-los a partir do novo path.

Os testes funcionaram perfeitamente. A título de curiosidade, o trecho do Makefile está abaixo:
selenium_up: selenium_down
@echo “Running selenium server with $(profile) profile…”
@java -jar data/selenium-server/selenium-server.jar -firefoxProfileTemplate data/selenium-server/profiles/$(profile) 2>&1 > /dev/null &

Chame o make passando o profile:
$make selenium_up profile=iphone
$make selenium_up profile=standard

E tudo deve funcionar.

Nessa filosofia, apresento aqui a maneira que me parece bem interessante de rodar uma aplicação django:

$make runserver

Bem prático, não?

Tudo que fiz foi criar um makefile com a seguinte macro:

runserver:
        @echo "Running aplicacao seu_dominio:3001..."
        @export PYTHONPATH=`pwd`:`pwd`/dango_project:$$PYTHONPATH && \
                export DJANGO_SETTINGS_MODULE=dango_project.settings.dev && \
                cd dango_project && python manage.py runserver seu_dominio:3001

Explicando melhor, imagine que você criou o django project projetoTeste. Imagine agora que, dentro deste projeto, você criou um diretório settings contendo o arquivo dev.py (settings para ambiente de desenvolvimento: lembrando que o settings.py pode ter o nome que você quiser! Recomendo apenas que faça sentido).

Substitua em runserver a variável aplicacao pelo nome fantasia que você quer dar para o seu projeto e dango_project por projetoTeste.

runserver:
        @echo "Running minha aplicacao teste teste.com:3001..."
        @export PYTHONPATH=`pwd`:`pwd`/projetoTeste:$$PYTHONPATH && \
                export DJANGO_SETTINGS_MODULE=projetoTeste.settings.dev && \
                cd projetoTeste && python manage.py runserver seu_dominio:3001

Claro que o Makefile e o projetoTeste está no mesmo nível (mesmo diretório pai).

Existem diversas maneiras de se criar esse Makefile e não vou tomar o vosso tempo com isso.

O runserver é legal para aplicações locais. Para coisas sérias, recomendo o WSGI.

Tudo rodando muito bem com o tradicional runserver 3001 (costumo criar um make para isso).

Claro que chamar uma URL passando a porta fica, no mínimo, deselegante. Solução: usar mod_proxy, mod_python ou WSGI. Optei por este último por diversos motivos que fogem do escopo deste post.

Configuração feita, para minha surpresa o CSS não estava sendo encontrado… Tentei alterar as configurações do WSGI várias vezes, e nada. Acabei percebendo que o problema não era apenas com o CSS, mas como tudo que fosse estático (normalmente, dentro de /admin_media ou /media)

Depois de uma batalha de algumas horas com o WSGI e uma dica no grupo de discussão do Django, consegui configurá-lo para funcionar bem. O problema era basicamente o apache, que procurava o diretório de media em seu docroot.

A solução que escolhi está postada abaixo (preservei algumas informações e removi alguns tabs para caber na tela):

<VirtualHost *:80>
        ServerName seu_dominio_.com

ErrorLog "|/usr/sbin/cronolog /usr/local/logs/dir/apache/projeto_%Y%m%d_error.log"
CustomLog "|/usr/sbin/cronolog /usr/local/logs/dir/apache/projeto_%Y%m%d_access.log" combined

        DocumentRoot "/usr/local/django/projeto"

        Alias /media/ "/usr/local/django/path_deploy/projeto/media/"

        <Location "/media/">
                SetHandler None
                <LimitExcept GET>
                        Require valid-user
                </LimitExcept>

                Order Allow,Deny
                Allow from all
        </Location>

Alias /admin_media/ "/var/lib/python-support/python2.5/django/contrib/admin/media/"

        <Location "/admin_media/">
                SetHandler None
                <LimitExcept GET>
                        Require valid-user
                </LimitExcept>

                Order Allow,Deny
                Allow from all
        </Location>

        WSGIScriptReloading on
        WSGIScriptAlias / /usr/local/django/path_deploy/projeto/django.wsgi
        WSGIDaemonProcess nome_do_deamon user=usuario group=grupo processes=2 threads=25 stack-size=524288

        <Directory /usr/local/django/path_deploy/projeto>
                Order deny,allow
                Allow from all
        </Directory>

 </VirtualHost>

Claro que eu precisei criar um usuário para a aplicação. Sempre crio um usuário específico para cada aplicação que desenvolvo (boa prática).

Só uma observação: sempre que o apache receber uma requisição /media ou /admin_media ele irá tratar sozinho, sem repassar para a aplicação. Isso pode ser interessante para questões de carga na aplicação.

Uma das novidades descritas é a barra de localização mais iconográfica e colorida. Na proposta, quando o usuário digita sobre a barra, ela ficaria verde. Se estiver em repouso, a tonalidade harmoniza com o resto dos ícones. A cor fica azul se estiver ocioso e vermelho quando está carregando, entre outras possibilidades.