Criando o primeiro projeto em Django, rápido e fácil.

13, maio 2012   •   (Não há comentários)   •   Autor: Thiago Dieb

Olá pessoal, estou de volta, tentando manter o rigor de escrever pelo menos um post a cada semana. Como sempre, não estou com muito tempo, mas acho que estou melhorando na minha organização.

Nesse final de semana recebi uma demanda bem pequena de um projeto e decidi que iria desenvolvê-lo em Django, sabendo que ainda não tinha feito nada para o blog sobre isso, resolvi criar um pequeno post para os iniciantes nesse Framework.

O que é o Django ?

O Django é um framework em Python. Ele possue uma arquitetura diferenciada, MTV (model, template e viewer). Tem poucas diferenças com o padrão MVC. Mas para continuar, em outro post explicarei melhor sobre esses detalhes. O Django se destaca por sua facilidade na criação rápida dos projetos.

Virtualização de ambiente

Como uma boa prática em projeto com python, devemos instalar um ambiente separada para cada projeto, assim podemos utilizar versões diferentes de bibliotecas em projetos distintos sem ter interferencia entre eles.

Vamos lá, primeiro como gerenciador global dos pacotes, precisaremos instalar o EASY_INSTALL:

$ sudo apt-get install python-setuptools python-dev build-essential

Em seguida por meio dele vamos instalar o PIP, um instalador de pacotes do python.

$ sudo easy_install pip

Agora só falta instalar o virtualenv que o é responsável pela criação dos ambientes para os projetos.

$ sudo pip install virtualenv

$ sudo pip install virtualenvwrapper

Seguindo, vamos criar a pasta do nosso projeto, criar o ambiente e ativar o ambiente. Depois disso qualquer pacote que instalarmos ficará isolado com relação ao resto do sistema,

$ mkdir projeto_django && cd projeto_django

$ virtualenv –no-site-packages env

$ source env/bin/activate

Estamos nesse instante na parte fácil que é instalar o Django e começar a brincar. Detalhe, deveremos estar com o ambiente ativado

$ pip install django

Criando projeto Django

Após a preparação do ambiente, enfim vamos criar nosso projeto Django com o comando django-admin.py usando o argumento startproject. Em seguida entre na pasta criada.

$ django-admin.py startproject projeto

$ cd projeto

Observe que foi gerado uma estrutura parecida como da imagem ao lado.

O arquivo manage.py será nosso gestor do projeto, por meio dele, criaremos aplicações, faremos o sincronismo com o banco de dados, iniciaremos o servidor de teste e muitas outras opções.

Os arquivos que estão na subpasta com o mesmo nome do projeto terá a finalidade de configuração de diretivas e  definição das urls.
Vamos testar para saber se o projeto está funcionando corretamente, assim execute o comando seguinte e acesso no browser: http://127.0.0.1:8000/

$ python manage.py runserver

Criando as aplicações

O Django como em vários outros frameworks, trabalha com modularização de aplicações, possibilitando a interações entre elas.

Com base no projeto que recebi, criaremos uma aplicação para controle de fotos.

$ python manage.py startapp fotos

Com a execução do comando, foi criado uma pasta chamada fotos e dentro dela mais três arquivos:

  • models.py  - definição dos modelos da base de dados utilizada pela aplicação
  • tests.py – definição dos teste
  • views.py – definição das chamada de funcionalidades

Partindo diretamente para a criação do modelo do banco de dados da nossa aplicação, vamos editar o arquivo models.py

from django.db import models

class Evento(models.Model):

nome = models.CharField(max_length=200)
data = models.DateTimeField()
local = models.CharField(max_length=200)

def __unicode__(self):

return self.nome

class Imagem(models.Model):

evento = models.ForeignKey(Evento)
legenda = models.CharField(max_length=200)
foto= models.ImageField(upload_to=’images’)

def __unicode__(self):

return self.legenda

Neste momento vamos definir o banco de dados e habilitar a aplicação no projeto, essa configurações devem ser feitas no settings.py. Observe os trechos de códigos a seguir:

Note que foi utilizado o sqlite3, mas poderia ser configurado com qualquer uma das quatro opções:  postgresql_psycopg2′, ‘mysql’, ‘sqlite3′ ou ‘oracle’

DATABASES = {

‘default’: {

‘ENGINE’: ‘django.db.backends.sqlite3′,
‘NAME’: ‘./schema.sql’,
‘USER’: ”,
‘PASSWORD’: ”,
‘HOST’: ”,
‘PORT’: ”,

}

}

INSTALLED_APPS = (

‘django.contrib.auth’,
‘django.contrib.contenttypes’,
‘django.contrib.sessions’,
‘django.contrib.sites’,
‘django.contrib.messages’,
‘django.contrib.staticfiles’,
‘fotos’,

)

Agora a etapa se resume em criar o modelo físico do banco com um comando de sincronização. Além do model que escrevemos, esse comando criará mais algumas tabelas de manipulação de usuário o que já é padrão para o Django, assim não precisamos nos preocupar com essa parte.

Antes de criarmos o banco, devemos executar outro comando, pois, como estamos usando um campo do tipo imagem no model em nossa aplicação o Django precisará de um pacote para manipulação das imagens, assim será necessário instalá-lo.

$ pip install pil

$ python manage.py syncdb

Admin em um piscar de olhos

Por fim, para temos realmente algo mais visível do projeto, vamos criar rapidamente o CRUD da aplicação, na qual representa a parte administrativa.

Primeiro vamos remover alguns comentários do arquivo urls.py, deixando-o como está abaixo.

OBS: adicionei uma url que não é padrão para termos acessarmos as imagens do upload.

from django.conf.urls import patterns, include, url
from django.conf import settings

 

from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns(”,

url(r’^admin/’, include(admin.site.urls)),

url(r’^media/(?P<path>.*)$’, ‘django.views.static.serve’, {‘document_root’: settings.MEDIA_ROOT}),

)

Dentro da pasta da aplicação “fotos” criaremos o arquivo admin.py, para registrar os módulos para área administrativa.
from fotos.models import Evento,Imagem
from django.contrib import admin

admin.site.register(Evento)
admin.site.register(Imagem)

Será necessário outra alteração no arquivo settings.py para habilitar a aplicação de administração no projeto, adicione a linha: ’django.contrib.admin’,  no array,  INSTALLED_APPS.

Pronto, só precisamos sincronizar novamente o banco e iniciar o servidor de teste.

python manage.py syncdb
python manage.py runserver


Maravilha, estamos com a aplicação de certa forma pronta, acesse o endereço: http://127.0.0.1:8000/admin e coloque o usuário e senha criados no momento da geração do banco.

Foi rápido não foi ? Criamos um CRUD da nossa aplicação em pouquíssimo tempo.

Temos muitas outras possibildiades com Django, infelizmente em um único post isso não é possível.

Recomendo a visita nesses sites:

Fico por aqui, até a próxima.

 

 

Como desbloquear iPhone 4 com baseband 04.11.08 de graça.

1, maio 2012   •   (Não há comentários)   •   Autor: Thiago Dieb

Semana passa após muita tempo esperando, consegui desbloquear meu iPhone 4.  Comprei ele no Estados Unidos, sabendo que estava bloqueado pela operadora AT&T, esperei um tempo até conseguir usar, pois tive que adiquir o chip GEVEY.

Depois de uma desatenta atualização para o IOS 5.0, meu baseband (firmware do modem) foi modificado para versão 04.11.08 e desde lá estou com o aparelho parado.

Com uma insistente pesquisa sobre o modo de desbloquei oferecido pela AT&T, encontrei diversas posts sobre o assunto mas nenhum muito concreto, até que em um fórum encontrei o caminho das pedras.

Vou descrever duas formas diferentes para solicitar o desbloqueio, sugiro que tente as duas para garantir.

Para adiantar um pouco a história e ajudar quem quer desbloquear, vou contar como é o procedimento normal para solicitar o desbloqueio:

  1. Você deve entrar em contato via bate-papo ou telefone com a AT&T, informando que gostaria de desbloquear seu iPhone.
  2. Eles vão pedir o número do telefone registrado no momento da compra, mas não é preciso fornecer, só informe a eles que comprou seu telefone sem contrato de fidelidade.
  3. Em seguida irão registrar seu pedido e em 10 dias enviarão um e-mail exigindo alguns itens que deverão ser enviado via fax. Um desses itens é o comprovante de compra, é muito importante que tenha.
    • Encontrei um problema nessa parte, enviar um fax para o número que me fornecerão, no caso um 0800 do Estados  Unidos, e agora? Consegui por meio do site http://www.faxzero.com.
  4. Após enviar do fax com tudo que foi solicitado, chegará em sua caixa uma mensagem com os passos necessários para efetuar o desbloqueio via iTunes.

Eu consegui de outra forma, um pouco mais rápida:

  1. Enviei um e-mail para os endereços: partnershipops@att.com, icare3@amcustomercare.att-mail.com
    • Com o assunto: Help to unlock
    • Podem seguir esse modelo de solicitação:
      “To whom it may concern:
      My name is SEU_NOME, and I own an iPhone 4 that was purchased via Apple Storea an AT&T retail location and is therefore locked to AT&T’s service. I would like to request that you unlock my iPhone, as I reside overseas (PAIS) and therefore cannot use AT&T’s services. My device’s IMEI is NUMERO_IMEI, and I am awaiting your response.”
  2. Após 4 dias me responderam pedindo que enviasse via fax os seguintes itens:
    • Labeled “iPhone Device Unlock Request”
      Your name:
      Email Address:
      Case Number:
      IMEI Number:
      Receipt showing price paid for device
    • Envie o fax pela ferramenta http://www.faxzero.com, a mesma mencionado acima.
  3. Depois de dois dias responderam-me informando que deveria fazer atualização do apararelho via iTunes para efetuar o desbloqueio, Vualá, iPhone desbloqueado sem gastar nada.

Caso não tenha o comprovante de compra, sugiro que utilize o GEVEY ultra que pode ser comprado nesse site http://www.applenberry.com

Galera fica ai a dica e brevemente estou com novos posts.

Fontes:

http://forums.macrumors.com/archive/index.php/%2520download%2520piarco%2520/t-1355053-p-2.html

http://www.iphonefaq.org/archives/971891

Quais as principais diferenças entre o Symfony2 e Symfony1 ?

11, agosto 2011   •   (Não há comentários)   •   Autor: Thiago Dieb

Estou de volta com um post direcionado à área técnica. O objetivo deste post é apresentar as principais diferenças da nova versão do Framework Symfony, com relação a versão anterior. O post se fez necessário, houve algumas mudanças bem relevantes.

Pra quem não conhece o Symfony1, ele tem uma abordagem muito parecida com o Zend Framework, com sua essência na arquitetura MVC. Um detalhe interessante é a abertura na camada de Model, permitindo o vínculo com outros Frameworks conhecidos por ORM`s, como: Propel e Droctrine.

Abaixo tenho um demonstrativo da relação dos principais itens técnicos sobre as duas versões:

symfony 1,4 Symfony 2,0
Estabilidade Estável Estável
Data de lançamento 11/2009 07/2011
Últimas 1.4.13 2.0.0
Apoio 3 anos n / a
PHP versão > = 5.2.4 > = 5.3.2
Versões ORM Propel: 1.4 
Doutrina: 1.2
Doutrina: 2.1
Fim da manutenção 11/2012 n / a
Documentação Documentação Documentação
Instalação Instruções detalhadas Instruções detalhadas
Repositório principal http://svn.symfony-project.com/branches/1.4 http://github.com/symfony/symfony.git

 

O salto da versão do Symfony não é por acaso, tanto sua estrutura quanto seu conceito foram afetados, e com certeza a forma de criação dos projetos. Então vamos lá.

Symfony2 vs Symfony1.

Ressalto que todas habilidades aplicadas para dominar um projeto no Symfony1 continuam a ser muito relevante no desenvolvimento em Symfony2.

Estrutura de Diretórios

Com uma pequena analise em uma projeto com Symfony2, percebemos que houve várias alterações em sua estrutura de diretórios. Suas mudança aplicam-se:

/app

No Symfony1, o projeto contém uma ou mais aplicações, e todos dentro do diretório/app. Por padrão no Symfony2, encontraremos apenas uma aplicação no projeto. Nesse diretório teremos configurações específicas para cache, logs e diretórios de templates, bem como uma classe Kernel (AppKernel), que será responsável por definir quais bundles serão utilizados na aplicação.

/src

Esse diretório é bem parecido com o diretório /plugins do Symfony1. Seu propósito foi de centralizar todos o códigos de uma determinada aplicação em um só lugar. No Symfony1, tínhamos vários apps, onde poderíamos compartilhar vários plugins e outros códigos PHP. Porém ficavam em diretórios separados. No Symfony2, a vida é muito mais simples porque todo o código deve estar em um pacote.

/vendor

O /vendor é equivalente ao diretório /lib/vendor do Symfony1, abrangendo todas as bibliotecas vendor e bundles. Por padrão, encontraremos nesse diretório os arquivos da biblioteca Symfony2, juntamente com várias outras bibliotecas dependentes, como Doctrine2, Twig e SwiftMailer.

/web

Quase não houve alterações nesse diretório. A diferença mais notável é a ausência dos diretórios /css, /js, /images. Isso é intencional. Como todos os códigos PHP devem ficar juntos, os ativos também devem estar dentro do mesmo pacote.
Com a ajuda de um comando de console, os arquivos do diretório Resources/public/ de cada pacote é copiado ou simbolicamente ligado ao diretório /web/bundles/.
Isto permite-lhe manter os ativos organizados dentro do seu pacote, mas ainda torná-los disponíveis ao público.

Autoloading

Autoloading mudou no Symfony2, agora é mais universal, mais rápido, e independente da necessidade de limpar o cache.
No Symfony1, autoloading foi feito através de pesquisas em todo o projeto para buscar os arquivos de classe PHP e incluía em cache estas informações em uma matriz gigante.
Quem lida com esse processo no Symfony2 é uma nova classe chamada : UniversalClassLoader. A idéia por trás do autoloader é simples: o nome da classe (incluindo o namespace) deve coincidir com o caminho para o arquivo que contém essa classe. Veja o exemplo:

namespace Sensio\Bundle\FrameworkExtraBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
// ...
class SensioFrameworkExtraBundle extends Bundle
{
// ...

Usando o Console

Com o Symfony1, o console está no diretório raiz do seu projeto e é chamado symfony:
php symfony

No Symfony2, o console é agora no sub-diretório app:
php app/console

Aplicações

Em um projeto Symfony1, é comum ter várias aplicações: uma para o frontend e outra para o backend, por exemplo. No Symfony2, só precisamos criar uma aplicação (uma aplicação de blog, um aplicativo de intranet, …). Na maioria das vezes, se quisermos criar uma segunda aplicação, podemos em vez disso criar outro projeto e compartilhar alguns pacotes entre eles.

Caso precisarmos separar a interface e os recursos de backend de alguns pacotes, criaremos sub-diretórios para os controladores, sub-diretórios para modelos, configurações de semântica, configurações de roteamento, e assim por diante.

Claro, não há nada de errado em ter várias aplicações em um projeto. A segunda aplicação significaria um novo diretório, por exemplo, /my_app, com a mesma configuração básica do diretório /app.

Bundles and Plugins

Um plugin no Symfony1 pode conter arquivos de configuração, módulos, bibliotecas PHP, ativos e qualquer outra coisa relacionada ao seu projeto. Em Symfony2, a idéia é que um plugin seja substituído por  ”pacote” (bundle). Um conjunto ainda mais poderoso do que um plugin.

Um plugin deve ser ativada dentro da classe ProjectConfiguration, isso quando utilizamos o Symfony1:

// config/ProjectConfiguration.class.php
public function setup()
{
$this->enableAllPluginsExcept(array(/* some plugins here */));
}

No Symfony2, os bundles são ativadas dentro do AppKernel:

// app/AppKernel.php
public function registerBundles()
{
$bundles = array(
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Symfony\Bundle\TwigBundle\TwigBundle(),
// ...
new Acme\DemoBundle\AcmeDemoBundle(),
);
return $bundles;
}

Routing (routing.yml) e Configuração (config.yml)

No Symfony1, os arquivos de configuração routing.yml e app.yml foram carregados automaticamente dentro de qualquer plugin. O processo muda um pouco no Symfony2, roteamento e configuração da aplicação fica dentro de um pacote que devem ser incluídos manualmente. Por exemplo, para incluir um recurso de roteamento de um pacote chamado AcmeDemoBundle, faremos o seguinte:

# app/config/routing.yml
_hello:
resource: "@AcmeDemoBundle/Resources/config/routing.yml"

Isso irá carregar as rotas encontradas no Resources/config/routing.yml do AcmeDemoBundle. O especial @AcmeDemoBundle é uma sintaxe de atalho que, internamente, resolve para o caminho completo para esse pacote.
Podemos usar esta mesma estratégia para trazer na configuração de um pacote:

# app/config/config.yml
imports:
- { resource: "@AcmeDemoBundle/Resources/config/config.yml" }

 

Essas são as principais modificações, porém não acabamos por ai. Recomendo, caso queria inciar a criação de projetos utilizando Symfony2, não deixe de ler a documentação, isso é essencial.

Fico por aqui.

Fontes:
http://symfony.com/doc/current/cookbook/symfony1.html