Skip to content

Latest commit

 

History

History
147 lines (101 loc) · 5.66 KB

README.md

File metadata and controls

147 lines (101 loc) · 5.66 KB
Raw

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.