Victor Pantoja

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

Não podia deixar de compartilhar esse vídeo muito bom mostrando a luz voltando ao Rio de Janeiro após o apagão.

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.

Trabalho desenvolvendo aplicativos e sites para dispositivos móveis e temos algumas maneiras de simular user-agents para testar os sites.

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.

Na empresa em que trabalho, criamos a excelente cultura de automatizar tudo que pode ser automatizado.

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.

Levantei uma aplicação simples que usa o admin do django com algumas alterações de CSS e template. Crei um diretório /media no meu projeto para colocar os arquivos CSS que criei.

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.

A Mozilla divulgou algumas imagens do que pode vir a ser a versão 4.0 do Firefox para Windows. Segundo a empresa, a idéia é encorajar os usuários a comentar e dar sugestões para o desenvolvimento da nova versão do browser.

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.

Após o número excessivo de invasões nos últimos meses, a equipe do Twitter fez alterações em sua API para limitar o número de tentativas de login.

Aplicativos de terceiros, que interagem direto com o microblog, poderão entrar com dados de senha e nome de usuário apenas 15 vezes em uma hora.

Apesar de a novidade ser considerada um avanço, nenhum alerta foi dado aos desenvolvedores de add-ons e extensões para o serviço.

O aplicativo Wikipedia Mobile chega a sua versão final após meses de testes. A principal novidade é o novo servidor, que guarda 18 milhões de páginas já no formato especial para os smartphones. Mas, por enquanto, apenas em inglês e alemão.

O usuário de iPhone, Android, Kindle ou Palm Pre será encaminhado automaticamente para a versão mobile do site sempre que clicar em algum link. Haverá também a opção de visualizar a versão clássica do verbete.

Quem tem outros modelos de celular pode acessar o endereço mobile.wikipedia.org, e ver uma versão light do site.

O anúncio do Google Chrome OS foi feito em um post no blog oficial do Google. Criado com o kernel do Linux e quase nada mais, o sistema operacional será superenxuto, feito sob medida para rodar o navegador Chrome (e provavelmente o Google Gears). Ao que parece, os usuários vão executar todas as aplicações dentro do browser.

O Chrome OS começará a aparecer em netbooks no ano que vem. Por terem hardware menos potente, eles pedem um sistema mais simples e leve. Serão a primeira frente de ataque do Google à Microsoft, que já estava certa de que faria o Windows 7 dominar esse mercado. A empresa de Mountain View, no entano, nega essa intenção. “É um sistema operacional pensado para os dias de hoje”, disse Félix Ximenes, diretor de comunicação do Google Brasil, em entrevista coletiva nesta quarta-feira (8). “Hoje em dia as pessoas passam muito mais tempo nos seus computadores online do que fazendo outras atividades.”

Como o código será aberto, nada impede que o Chrome OS ganhe mais funcionalidades, passe a rodar softwares além do navegador, e se torne complexo o suficiente para competir de igual para igual com o Windows e até para o Ubuntu e as outras distribuições Linux com foco no usuário final.

“Estamos redesenhando completamente a arquitetura de segurança, para que os usuários não tenham que lidar com vírus, malware e atualizações de segurança. Simplesmente deve funcionar”, disseram executivos do Google no blog oficial.