Categoria: Desenvolvimento

Subcategoria Moodle, específica para posts sobre desenvolvimento da plataforma Moodle.

Publicado em

Nova versão do Moodle: 2.6

No início de julho atualizamos os Moodles gerenciados pelo grupo ATP para 2.6, trazendo atualizações de segurança e novas funcionalidades. Como aconteceu em janeiro, há várias novidades boas para docentes e usuários em geral. Veja algumas novidades

Editor mais simples

O editor visual TinyMCE usado em fóruns e quase todos os outros lugares onde alunos e docentes entram com texto e imagens e outros objetos digitais foi simplificado. Ainda há acesso a todas as ferramentas clicando na primeira botão.

Tarefa: retorno anotando o arquivo PDF

Se a atividade “Tarefa” for configurada para receber arquivos o monitor ou docente pode agora fazer marcações e comentários no próprio PDF, usando nada mais que seu próprio navegador (se este for razoavelmente atualizada). O estudante verá dentro do seu navegador as marcações e comentários no seu próprio texto (o original não é modificado). Esta funcionalidade somente existe para arquivos PDF.

800px-AnnotatePDF

Tarefa: gravação de voz online

 

Atualizamos todas as atividades no Moodle do Stoa do tipo “Tarefa” que ainda estavam no formato legado (Moodle 2.2) para a atividade nova.

Veja também as novidades no site do Moodle (em inglês).

Para os responsáveis de ambientes de apoio a disciplinas do segundo semestre de 2014, veja um aviso importante sobre o visual e novo template do Moodle do Stoa, que vai entrar no ar no final de julho.

 

Publicado em

Quadro de notas do Moodle e PHP5.3.9

Descobrimos (e resolvemos) um problema que apareceu recentemente. Ao atualizar notas diretamente pelo quadro de notas, tutores percebiam que algumas notas não mudaram. Por exemplo, as notas dos alunos com nomes de digamos até M podiam ser atualizados, mas as notas dos alunos mais para baixo no quadro permanciam inalteradas. A razão é uma combinação de quadro de notas muito grandes e uma atualização de segurança recente do PHP.

Em algumas disciplinas os quadros de notas são bem grandes: podem conter mais do que 40 ou 50 colunas. Isto significa que ao atualizar uma nota diretamente pelo quadro de nota as notas de, digamos 25 alunos vezes 40 colunas ou da ordem de 1000 itens de nota  devem ser atualizados. Vimos que o navegador estava mandando todos os novos valores corretamente na requisição POST ao servidor. Mas  aparentemente o Moodle não processava os valores após 1000 itens.

Acontece que uma atualização do PHP (implementada 10 de janeiro 2012) introduz uma nova variável de configuração: “Added max_input_vars directive to prevent attacks based on hash collisions”. Esta nova variável é igual a 1000, por padrão. Portanto, a solução para quem lida com quadro de notas grandes no Moodle é usar um valor maior para a variável max_input_vars. Isto pode ser feito, por exemplo, colando em seu arquivo .htaccess a linha

php_value max_input_vars 10000

A variável foi acrescentado para proteger o seu servidor contra um ataque denial of service. Acreditamos que aumentando seu valor para 10 mil não aumente o risco deste tipo de ataque substancialmente (porque, sinceramente, há maneiras muito mais simples de fazer este ataque).

Publicado em

Checklist para configuração de um novo Moodle

Instalar um novo Moodle é simples, sobretudo se já tiver um pouco de experiência com a instalação de software Web. Mas preparar um ambiente de produção requer muita atenção em muitas detalhes. Veja um checklist para verificar ao instalar um novo Moodle.

Primeiro, a instalação básica.

  • Baixar o código. O jeito moderno é usar algum branch do git://git.moodle.org/moodle.git . Se quiser usar o nosso código (uma versão levemente customizado do código “upstream”, com alguns plugins e temas já pré-instalados), use 
    $ git init 
$ git remote add -t devel2 -f origin git://git.atp.usp.br/moodle.git 
$ git checkout -b meuprojeto origin/devel2

    A razão de não usar git clone é que não é necessário levar todos os branches para seu repositório local

  • Configurar o seu servidor Web (usamos Apache). Colocar ServerName e ServerAlias no VirtualHost. Aproveitar e mudar as configurações padrão da sua distribuição: KeepAliveTimeout 2, ServerLimit e MaxClients para algo como (memória disponível / 50M)* 80% (ou menos, se o seu base de dados fica na mesma máquina. Veja mais nas dicas de desempenho no Moodle Docs
  • Instalar um acelerador PHP (usamos APC, php-apc no debian e ubuntu )
  • Instalar um base de dados (usamos Mysql) e criar sua base. Aproveitar e mudar as configurações padrão da sua distribuição. Se usar innodb, o parâmetro mais importante é innodb_buffer_pool_size. Veja mais nas dicas de desempenho no Moodle Docs
  • Configurar o admin/cron.php (usando o crontab do root do servidor Web, por exemplo)
  • Configurar o tamanho máximo de uploads. Fazemos usando um arquivo .htaccess no raiz do site com 
    php_value upload_max_filesize 150M
php_value post_max_size 151M
  • Configurar backups! Usamos mysqldump para a base e rsync para moodledata.
Uma vez instalado, vem a configuração do Moodle
  • Decidir como os seus usuários vão se cadastrar e autenticar (em Plugins / Authentication). No nosso caso, isto envolve plugins de autenticação desenvolvidos por nós. Não esquecer escrever as instruções (colocar em Plugins / Authentication / Common Settings )
  • Configurar email (em Plugins / Message Outputs)
  • Decidir o template principal do site. Decidir se categorias e cursos podem usar templates próprios. Neste caso, colocar pelo menos o seu próprio logo nestes templates.
  • Configurar o menu principal (em Appearance / Temas ). Fazer links para as páginas de ajuda.
  • Baixar “language packs”.
  • Configurar os papeis (renomear Teacher para Docente, mudar permissões a gosto, criar outros papeis)
  • Ativar estatísticas (em Server / Statistics e também (!) em Advanced Features)
  • Colocar o código de Google Analytics (em Appearance / Aditional HTML)
  • Habilitar o filtro Latex (em Plugins / Filters). No debian o pacote texlive-latex-base traz quase tudo.
Que mais acham que não podemos esquecer?

 

Publicado em

O caminho para Moodle 2.1

O Moodle 2.1 saiu pouco tempo atrás e precisamos começar pensar sobre a migração dos nossos Moodles.

Para Redefor2 resolvemos ficar com 1.9 porque quando estava na hora de preparar o novo ambiente o Moodle 2.1 não tinha saído ainda e avaliamos que não conseguiríamos migrar os plugins não-padrão essenciais (GApps, OU Wiki etc.)

Mas para a Licenciatura em Ciências em 2012, o Moodle do Stoa e os outros Moodles para quais damos suporte a previsão é migrar para o Moodle2.1 em breve (para valores flexíveis de “breve”). Precisamos começar se acostumar com o novo interface, aprender as novas funcionalidades, etc.

Instalamos uma instância de testes no moodle21.atp.usp.br . Está rodando o branch devel21 do nosso repositório (que por sua vez está ligado ao branch MOODLE_21_STABLE do repo git upstream). A minha ideia é que o branch devel21 vai servir de base para os nossos novos moodles. A instância moodle21.atp.usp.br por agora está aberto para cadastro via email. Quem quiser experimentar, fiquem a vontade!

Veja uma guia interessante feito pelo pessoal do Synergy Learning (clique embaixo para um png que fiz a partir do pdf deles.)

Clique para ampliar, imagem CC-BY-NC-SA de http://www.synergy-learning.com/blog/moodle/the-moodle-2-1-administration-map/

E veja também esta apresentação do Ross Mackenzie, sobre o processo de migração do Open University.

 

Publicado em

SSO entre Moodle e Google Apps vs IPv6

No dia 7 de junho, as 21h BRT de repente começamos ter problemas com os logins no Moodle do Redefor. As sintomas eram: atrasos muito grandes na resposta do servidor, telas brancas em http://redefor.usp.br/cursos/login/login.php, etc. Às vezes conseguíamos se logar, geralmente após um delay de 20 ou 60 segundos. Descobrimos que podíamos resolver a lentidão dos logins desligando o plugin de autenticação que veio com a integração Moodle-Google Apps desenvolvido pelo Moodlerooms.

Logo o Ettore do CCE levantou a hipótese que os problemas seriam relacionados com o “dia IPv6“. Neste dia, durante 24h a partir das 22h horário do Brasil, o Google (e outros provedores de serviços na internet) ligaram o IPv6 nos seus serviços principais. Como explica o Ars Tecnica, isto pode levar a atrasos e time-outs quando o caminho entre 2 servidores não pode ocorrer via IPv6 mais o fall-back para IPv4 não ocorre imediatamente. O Ettore ajustou o firewall entre os servidores do cluster da Redefor e o resto de mundo, mas aparentemente não resolveu completamente o problema. Somente no dia 8 de junho as 21h tudo voltou a normal.

Aprendemos uma lição sobre modos de falha inesperado e sistemas aclopados não-fracamente. Não entendo porque o plugin de SSO falhou tão desastrosamente. O plugin de autenticação é responsáveis para responder requisições SAML que os servidores do Google fazem no Moodle da Redefor (que funciona como provedor de identidade). Não há razão de contatar os servidores do Google durante o processo de login no Moodle. Vamos ter que investigar o que este plugin exatamente faz…

Publicado em

Checklist para Editores do Redefor no ínício de um Módulo Novo

No projeto Redefor cada Módulo de 10 semanas é implementado usando um ambiente (disciplina, curso) com 10 “abas” ou tópicos.  Veja um checklist para os Editores verificar antes de inscrever os alunos e abrir o módulo:

  1. É importante que vocês nos ajudem a verificar se as configurações de seus cursos estão ok, segue uma pequena lista (eu acabo de verificar estes pontos, é só pra vocês ficarem a par do padrão)
    1. o campo “número de identificação do curso” TEM QUE ser igual ao nome curto;
    2. as inscrições nos cursos tem que estar fechadas;
    3. a opção “grupos separados” deve estar selecionada junto com “forçar” = “sim”
    4. os alunos estão impedidos de iniciar novas discussões em fóruns em sobrepor permissões (verificar a sobreposição de permissões para o papel “Estudante” em nível de ambiente).
  2. As semanas posteriores devem ser ocultadas (todos os recursos/atividades acessíveis através de links devem estar em semanas visíveis)
  3. Verifiquem se todos os recursos/links estão ok nas primeiras semanas (de preferência alterando o papel pra estudante)
  4. É bem importante que os Editores monitorem a utilização de atividades/recursos que ainda não forma utilizados no cursos. Se tiverem qualquer dúvida de configuração, nos perguntem!
  5. Notamos que alguns cursos ainda não tem nenhuma atividade na primeira semana. Esse é o plano ou vocês ainda não receberam o material?
  6. Para facilitar a organização do quadro de notas, a regra é colocar a semana no título da atividade.
  7. Se existe alguma atividade que exige um treinamento/orientação do tutor, o grupo ATP precisa ser avisado. Nós podemos cuidar disso.
  8. Visitem o fórum de tutores ou melhor ainda, assinem o fórum de tutores. Isso pode agilizar muito a detecção de problemas, em geral simples de resolver e que atrapalham a vida dos alunos.