Find file
Fetching contributors…
Cannot retrieve contributors at this time
148 lines (101 sloc) 5.66 KB

Projeto Atletismo

Criado em 2009 no curso de Laboratório de Programação Extrema da Universidade de São Paulo

Copyright: Universidade de São Paulo, 2009

Programadores

2009

  • Daniel Sguilaro
  • Edith Mamani
  • Eduardo Kasa (como coach)
  • Joao Paulo Mota
  • Marcela Ortega
  • Pierre-Marie Leveque
  • Rodrigo Flores

2010

  • Gustavo Vilela
  • Hugo Kondo
  • Itai Soares
  • Luiz Romagnoli
  • Omar Ajoue
  • Otavio Santana
  • Rodrigo Flores (como coach)

Configurando o ambiente

Gems necessárias

Deploy - Desenvolvimento

  • Authlogic
  • Formtastic

Teste

  • Todas as gems de desenvolvimento
  • remarkable_rails
  • rspec >= 1.30
  • rspec_rails
  • factory_girl
  • rcov

Criando o banco de dados

  1. Renomeie o arquivo na pasta de configuração dentro de 'database.sqlite3.yml' para 'database.hyml' (o exemplo utiliza SQLite3)

  2. Crie o banco de dados utilizando o comando

rake db:create

  1. Faça as migrações necessárias

rake db:migrate

  1. (opcional) para realizar testes, repita os passos 2 e 3 seguidos de RAILS_ENV=test

Configurações adicionais

Há dois ajustes que devem ser feitos para ter o site funcionando corretamente.

  • Configuração do banco de dados Bem como qualquer aplicação rails, vocẽ pode configurar o banco de dados que irá utilizar editando o arquivo config/database.yml
  • Active Mailer (ferramenta para envio de e-mails) Todos os e-mails criados são despachados utilizando um servidor SMTP. Você deve configurar um servidor SMTP à sua escolha no arquivo config/enviroinment.rb

Executar

  1. Execute o seguinte comando para iniciar o servidor:

./script/server

  1. Navegue à vontade. Por padrão, o servidor abrirá em localhost:3000

Testar

  • Execute rake spec para rodar todos os testes
  • Execute rake spec:rcov para obter o nível de cobertura de código

Observações relacionadas ao projeto

Introdução

O Atletismo é um sítio que visa facilitar o relacionamento entre treinadores e atletas. Inicialmente focado em atletismo, a intenção é que o sítio sirva como ferramenta para todas as modalidades de treino esportivo no futuro. Os usuários do sistema cadastram-se e escolhem entre participar como treinador ou atleta. No caso dos atletas, é necessária a escolha de um treinador para supervisão.

  • Atualmente, o treinador é capaz de realizar as seguintes tarefas: Acessar a calculadora de ritmos Visualizar a listagem de atletas Administrar os treinos de um atleta Um treino é uma rotina a ser realizada em um dia e reportada de volta no sistema com seu resultado. O treino é composto por vários itens de treino, que descreve os exercícios a serem realizados nesse treino. Visualizar as provas de um atleta O treinador visualiza as provas que um atleta cadastra. Provas são competições que um atleta participa e cadastra o resultado para que seu treinador acompanhe. Administrar os testes de um atleta Um teste é uma tarefa que o treinador passa para o atleta realizar e reportar os resultados. Serve também como acompanhamento de evolução. Editar os Exercícios e Objetivos utilizados nos treinos Os ítens de treino são classificados por tipo de exercício e objetivo. Estes dois filtros deverão utilizados futuramente na montagem de gráficos. A discretização dos ítens de treino citada acima auxiliará na totalização dos dados.

  • Quanto ao atleta, as seguintes tarefas podem ser realizadas: Visualizar os treinos e publicar comentários a respeito Cadastrar provas para acompanhamento do treinador Visualizar testes propostos e enviar seu resultado para o treinador

Problemas

  • Banco de dados (problema com user, atleta e treinador) Existe uma "confusão" no sistema, relacionada à escolha dos nomes. Todos os usuários possuem um registro na tabela "users", e por sua vez possuem uma ligação à tabela "atletas", referenciada pelo campo atleta_id na tabela users ou ligado à tabela "treinadores", referenciado pelo campo treinador_id. Apenas um destes campos será preenchido por vez, afinal, cada usuário só pode ser treinador OU atleta. A ambiguidade é que durante o desenvolvimento, é possível que você instancie um Atleta e confunda com a entidade User pois há campos em comum (a existência de um treinador_id em ambos), e isto não gerará erros de execução. É necessário tomar cuidado quanto a isto. Por tratar-se de um problema legado e sua modificação impactar gigantescamente na estrutura atual do projeto, optamos por nos adaptar a esta ambiguidade.

Estrutura

  • Namespace A utilização de namespaces foi trazida para separar melhor o código dos controllers referentes a atletas e treinadores. Um exemplo simples: com relação às provas. O Atleta cadastra e visualiza as provas, enquanto que o treinador apenas visualiza. Para evitar verificações condicionais, optamos por separar o código em duas regiões distintas, permitindo que a mesma ação, por exemplo, view, possa ser chamada de pontos diferentes e estar logicamente bem separada.

  • Branches Há duas "branches" no projeto: develop e master. A "branch" master contem a última versão estável, enquanto que a branch "develop" é utilizada pelos desenvolvedores.

Status do projeto

Até a data de entrega, o projeto está com 100% de cobertura de código e funcional. Não há links quebrados e realizamos uma gigantesca limpeza em arquivos não utilizados. Nem todas as rotinas estão devidamente separadas nos namespace devido. Isto é algo que poderia ser feito num primeiro passo de aprendizado, afinal, envolve apenas entender um pouco das rotinas e realizar a separação.