• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Django para infográficos
 

Django para infográficos

on

  • 1,085 views

Apresentada no FISL11, mostra as idéias por trás de um back-end genérico para armazenagem e recuperação de dados para a produção de infográficos

Apresentada no FISL11, mostra as idéias por trás de um back-end genérico para armazenagem e recuperação de dados para a produção de infográficos

Statistics

Views

Total Views
1,085
Views on SlideShare
1,045
Embed Views
40

Actions

Likes
0
Downloads
1
Comments
0

2 Embeds 40

http://coderwall.com 29
http://www.linkedin.com 11

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Django para infográficos Django para infográficos Presentation Transcript

    • Django para infográficos
    • Do que precisávamos
      • Precisávamos de um back-end
      • Que pudesee gerar arquivos XML ou JSON
      • Que pudessem ser editados em tempo-real (ou quase isso)
      • Com uma interface jornalista-friendly
      • E que pudesse gerar diferentes formatos a partir dos dados que foram colocados lá
    • Em resumo...
      • Um CRUD bem feito
      • E um BD que cospe uns JSONS e, se não tiver outro jeito, um XML
    • CRUD bem-feito
    • Compatível com jornalistas
    • Gerando JSON [ { "campeao": 227, "vice": 12, "vice_nome": "Argentina", "ano": 1930, "campeao_nome": "Uruguai", "terceiro_nome": "Estados Unidos", "quarto_nome": "Iugoslu00e1via", "anfitriao": 227, "anfitriao_nome": "Uruguai", "quarto": 240, "campanhas": [ { "partidas_disputadas": 5, "saldo_de_gols": 8, "disputa_de_penaltis": 0, "gols_feitos": 16, "numero_de_pontos_ganhos": 8, "campanha": 196, "selecao_nome": "Argentina", "cartoes_vermelhos": 0, "selecao": 12, "quartas_de_final": 0, "semifinal": 1, "cartoes_amarelos": 0, "gols_sofridos": 8, "derrotas_nos_penaltis": 0, "numero_de_empates": 0, "numero_de_vitorias": 4, "final": 1, "vitorias_nos_penaltis": 0, "numero_de_derrotas": 1 }, { "partidas_disputadas": 2, "saldo_de_gols": -4, "disputa_de_penaltis": 0, "gols_feitos": 0, "numero_de_pontos_ganhos": 0, "campanha": 205, "selecao_nome": "Bu00e9lgica", "cartoes_vermelhos": 0, "selecao": 21, "quartas_de_final": 0, "semifinal": 0, "cartoes_amarelos": 0, "gols_sofridos": 4, "derrotas_nos_penaltis": 0, "numero_de_empates": 0, "numero_de_vitorias": 0, "final": 0, "vitorias_nos_penaltis": 0, "numero_de_derrotas": 2 }, { "partidas_disputadas": 2, "saldo_de_gols": -8, "disputa_de_penaltis": 0, "gols_feitos": 0, "numero_de_pontos_ganhos": 0, "campanha": 206, "selecao_nome": "Bolu00edvia", "cartoes_vermelhos": 0, "selecao": 29, "quartas_de_final": 0, "semifinal": 0, "cartoes_amarelos": 0, "gols_sofridos": 8, "derrotas_nos_penaltis": 0, "numero_de_empates": 0, "numero_de_vitorias": 0, "final": 0, "vitorias_nos_penaltis": 0, "numero_de_derrotas": 2 },
    • Do que não precisávamos?
      • Gerar os gráficos propriamente ditos
        • Componentes Flash ou JavaScript fariam essa parte
        • Ainda que a arquitetura permita fazermos isso, se quisermos muito
      • Servir páginas inteiras em torno dos componentes com dados
    • Designers fazem UI melhor do que eu
    • Por que Django?
      • O admin
      • O ORM
      • O módulo simplejson
      • O mapeamento de URLs
      • O framework de testes
    •  
    • O Admin
      • Jeito declarativo de definir interfaces de manutenção
      • Autenticação/autorização embutidas (já fiz um e já chega)
      • É o nosso CRUD
    • O ORM
      • Fácil de montar queries
      • Deixo que ele otimize tudo
      • Não escrevo SQL
      • Eventualmente, posso mudar de banco para um NoSQL se a performance melhorar alguma coisa (o pessoal do django-nonrel tem feito bom progresso)
      • Se precisar muito, posso escrever SQL tunado à mão
        • Mas nunca precisei
    • O módulo simplejson
      • simplejson.JSONEncoder(indent = 4).encode({'rotulo': 'meu dado', 'valor': 123})
      • Simples assim
      • Não é XML (e isso é bom)
    • O mapeamento de URLs
      • Permite criar a ilusão de arquivos estáticos
      • O cliente não precisa saber o que está acontecendo
      • As URLs são bonitas (memorizáveis)
        • A linha
      (r'^(?P<indicador_slug>[w-]*)_datas.json$', views.indicador_datas),
        • Cria URLs como
      http://servidor/aplicacao/pib_datas.json
      • E ficam amigáveis para caches
    • Como ficou
      • 2 servidores Apache com Django
      • 1 servidor MySQL
      • Quantos caches precisarmos (temos 2)
      • … atrás de um balanceador
      • Back-end atende até 400 requests por segundo (em cada servidor), mas nunca chega nem perto disso
      • BD se sente solitário, sem ter o que fazer
      • Caches atendem quase todos os requests
    • Tipos de dados
      • Cada tipo de dado pede uma aplicação diferente (no nosso modelo)
      • Há aplicações compartilhadas
        • Isso viola um pouco as recomendações oficiais
      from backend.common.models import Pais, UF
        • Mas resolve nosso problema de dados partilhados
        • e compartimenta o acesso aos dados
    • Como podemos crescer?
      • Mais caches por backend
      • Mais backends
      • Replicação no BD
      • BDs não relacionais (?)
      • Não estamos nem perto dos limites da infra-estrutura
    • Alternativas
      • Elastic Search tem sido pesquisado
        • Simples de usar
        • Pode ser persistido
        • … mas não pode cruzar dados e fazer queries complicadas no servidor
    • Dúvidas?