practica-final-2019-y-ant.tex

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final: MiTiempo (2019, mayo)}
\label{practica-final-2019-05}

El proyecto final de la asignatura consiste en la creación de una aplicación web, llamada ``MiTiempo'', que aglutine información sobre municipios de España, y especialmente información meteorológica sobre ellos. A continuación se describe el funcionamiento y la arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

La aplicación se encargará de descargar información sobre las condiciones meteorológicas de los municipios, disponibles públicamente en en sitio web de la AEMET, y de ofrecerla a los usuarios para que puedan monitorizar con facilidad las previsiones para aquellos municipios que les parezcan más interesantes, y comentar sobre ellos. De esta manera, un escenario típico es el de un usuario que elija los municipios que le parezcan de interés, y comente lo que le quiera sobre ellos.

%%----------------------------------------------------------------------------
\subsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}

  \item La práctica se construirá como un proyecto Django/Python3, que incluirá una o varias aplicaciones (apps) Django que implementen la funcionalidad requerida.

  \item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas en modelos de Django.

  \item Se usará la aplicación Django ``Admin Site'' para crear cuentas a los usuarios en el sistema, y para la gestión general de las bases de datos necesarias. Todas las bases de datos que contenga la aplicación tendrán que ser accesibles vía este ``Admin Site''.

  \item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que la práctica tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un \emph{banner} (imagen) del sitio, preferentemente en la parte superior izquierda.
  \item Una caja para entrar (hacer login en el sitio), o para salir (si ya se ha entrado).
  \begin{itemize}
    \item En caso de que no se haya entrado en una cuenta, esta caja permitirá al visitante introducir su identificador de usuario y su contraseña. 
    \item En caso de que ya se haya entrado, esta caja mostrará el identificador del usuario y permitirá salir de la cuenta (logout). Esta caja aparecerá preferentemente en la parte superior derecha.
  \end{itemize}
  \item Un menú de opciones, como barra, preferentemente debajo de los dos elementos anteriores (banner y caja de entrada o salida).
  \item Un pie de página con una nota de atribución, indicando ``Esta aplicación utiliza datos proporcionados por la AEMET'', y un enlace al sitio web de AEMET\footnote{Sitio web de AEMET: \url{https://aemet.es}}.
  \end{itemize}

Cada una de estas partes estará construida dentro de un elemento ``div'', marcada con un atributo ``id'' en HTML, para poder ser referenciadas fácilmente en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la práctica. Estas hojas definirán al menos el color y el tamaño de la letra, y el color de fondo de cada una de las partes (elementos) marcadas con un \emph{id}, tal como se indica en el apartado anterior.

\item Para obtener la información sobre previsión meteorológica de cada municipio se utilizará la información disponible en AEMET:

  \begin{itemize}
  \item Ejemplo de información para un municipio, en formato XML
    (para cada municipio, el número de cinco cifras que finaliza la URL
    se obtiene del documento descrito más abajo): \\
    \url{http://www.aemet.es/xml/municipios/localidad_28058.xml}
  \item Documento JSON con listado de municipios, incluyendo su nombre y
    su identificador para localizar los documentos anteriores (campo ``id\_old''): \\
    \url{https://raw.githubusercontent.com/CursosWeb/Code/master/Python-JSON/municipios.json}
  \end{itemize}
  
\end{itemize}

Funcionamiento general:

\begin{itemize}
  \item Los usuarios serán dados de alta en la práctica mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

  \item El listado de municipios se cargará de nuevo cada vez que arranque la aplicación, a partir de un fichero que será parte del proyecto Django. El listado se mantendrá en un diccionario en memoria, y no se guardará en almacenamiento persistente en la base de datos.

  \item Los usuarios registrados podrán crear su selección de municipios. Para ello, dispondrán de una página personal. Llamaremos a esta página la ``página del usuario''.

  \item La selección de municipios en su página personal la realizará cada usuario rellenando un formulario que estará en su página de usuario. Este formulario permitirá elegir un nombre de municipio. Si el municipio coincide con uno en el listado de municipios, se considerará válido, y se añadirá a la lista de municipios seleccionados por ese usuario. Si no es así, se le indicará que el nombre del municipio es erróneo.

  \item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá la página personal de cada usuario, para todos los usuarios del sitio.

\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Funcionalidad mínima}

La información para cada municipio se obtendrá a partir de la información pública ofrecida por AEMET, en forma de ficheros XML, como se indicaba anteriormente.

La {\bf interfaz pública} contiene los recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no), excepto donde se indica que se servirá una página XML:

\begin{itemize}
  \item /: Página principal de la práctica. Constará de un listado de poblaciones que han sido elegidas por algún usuario, y otro con enlaces a páginas de usuarios:
  
  \begin{enumerate}
    \item Mostrará un listado de los 10 municipios con más comentarios. Si no hubiera 10 municipios con comentarios, se mostrarán sólo los que tengan comentarios. Para cada municipio, incluirá información sobre:
    \begin{itemize}
    \item su nombre (que será un enlace que apuntará a la URL del municipio en el sitio de AEMET)\footnote{Por ejemplo \url{http://www.aemet.es/es/eltiempo/prediccion/municipios/fuenlabrada-id28058} (donde el identificador ``fuenlabrada-id28058'' puede encontrarse en el docuento JSON con el listado de municipios como campo ``url''}, 
    \item su altitud, latitud y longitud,
    \item su previsión de tiempo para mañana: probabilidad de precipitación (0 a 24), temperatura máxima y mínima, y descripción (0 a 24).
    \item y un enlace, ``Más información'', que apuntará a la página del municipio en la aplicación (ver más adelante).
    \end{itemize}
   
  \item También se mostrará un listado, en una columna lateral, con enlaces a las páginas personales disponibles. Para cada página personal mostrará el título que le haya dado su usuario (como un enlace a la página personal en cuestión) y el nombre del usuario. Si a una página personal aún no se le hubiera puesto título, este título será ``Página de usuario'', donde ``usuario'' es el identificador de usuario del usuario en cuestión.
  \item Tambień se mostrará un botón, que al pulsarlo se verán sólo los municipios con probabilidad de precipitacion mayor que cero. Si se vuelve a pulsar, se verán los que tengan ptobabilidad de precipitación igual a cero. Si se vuelve a pulsar una vez más, se volverán a ver todos los municipios.
   \end{enumerate}

  La página principial se ofrecerá también como un documento XML, que incluirá la misma lista de municipios, y un enlace al fichero XML que proporciona para cada uno de ellos la AEMET. Este documento se ofrecerá cuando se pida la URL de municipios, concatenando al final \verb|?format=xml|.

  La página principal en formato HTML includirá un enlace a la página principal en formato XML (``Descarga como fichero XML'').
  
  \item /{usuario}: Página personal de un usuario. Si la URL es ``/usuario'', es que corresponde al usuario ``usuario''. Mostrará los municipios seleccionados por ese usuario. Para cada municipio se mostrará la misma información que en la página principal. Los municipios deben aparecer en el orden en que los ha seleccionado el usuario (primero el que fue seleccionado más recientemente).

  La página de cada usuario se ofrecerá también como un documento XML, que incluirá la lista de municipios seleccionados, y un enlace al fichero XML que proporciona para cada uno de ellos la AEMET. Este documento se ofrecerá cuando se pida la URL del usuario, concatenando al final \verb|?format=xml|.

  La página de cada usuario en formato HTML includirá un enlace a la página de ese mismo usuario en formato XML (``Descarga como fichero XML'').

  \item /municipios: Página con todos los municipos que han sido seleccionados por algún usuario (aunque hayan sido luego ``desseleccionados''. Para cada uno de ellos aparecerá sólo el nombre, como un enlace a su página (ver más abajo), y el número de comentarios que se han puesto sobre él. En la parte superior de la página, habrá un formulario que permita filtrar según la temperatura máxima para mañana: se mostrarán solo los municipios que para mañana tengan previsión de temperatura máxima entre las dos que se indiquen, si se indican.

    La página de municipios se ofrecerá también como un documento XML, que incluirá la misma lista de municipios, y un enlace al fichero XML que proporciona para cada uno de ellos la AEMET. Este documento se ofrecerá cuando se pida la URL de municipios, concatenando al final \verb|?format=xml|.

    La página de municipios en formato HTML includirá un enlace a la página de municipios en formato XML (``Descarga como fichero XML'').

  \item /municipios/{id}: Página de un municipio en la aplicación. Mostrará toda la información razonablemente posible del documento XML obtenido de AEMET (en cuanto a predicción para mañana, en el rango 0 a 24 horas), incluyendo también al menos la que se menciona en otros apartados de este enunciado. También se incluirá un enlace a la página de este municipio en el sitio de AEMET. Además, se mostrarán todos los comentarios que se hayan puesto para este municipio. Esta información se actualizará cuando se consulte esta página de un minicipio, y a partir de este momento se mostrará actualizada en cualquier otra página del sitio. La información no se actualizará en ningún otro momento.
 
  \item /info: Página con información en HTML indicando la autoría de la práctica, explicando su funcionamiento y una brevísima documentación.

\end{itemize}

Todas las páginas de la interfaz pública incluirán un menú desde el que se podrá acceder a todos los municipios (URL /municipios) con el texto ``Todos'' y a la ayuda (URL /info) con el texto ``Info''. Todas las página que no sean la principal tendrán otra opción de menú para la URL /, con el texto ``Inicio''.

La {\bf interfaz privada} contiene los recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado):

\begin{itemize}
  \item Todos los recursos de la interfaz pública.

  \item /municipios/{id}: Además de la información que se muestra de manera pública:

    \begin{enumerate}
    \item Un formulario para poner comentarios sobre este municipio. Los comentarios quedarán a nombre del usuario que los ponga, y sólo se podrán poner por los usuarios registrados, una vez se han autenticado. Por tanto, bastará con que este formulario esté compuesto por una caja de texto, donde se podrá escribir el comentario, y un botón para enviarlo. El sistama anotará automáticamente quién está poniendo el comentario, y mostrará esa información cada vez que muestre el comentario (con el texto ``Comentado por'').
  \end{enumerate}

  \item /{usuario}: Además de la información que se muestra de manera pública:
  
  \begin{enumerate}
    \item Un formulario para cambiar el estilo CSS de todo el sitio para ese usuario. Bastará con que se pueda cambiar el tamaño y el color de la letra y el color de fondo. Si se cambian estos valores, quedará cambiado el documento CSS que utilizarán todas las páginas del sitio para este usuario. Este cambio será visible en cuanto se suba la nueva página CSS.

    \item Un formulario para elegir el título de su página personal.

    \item Un formulario para seleccionar un nuevo municipio. En este formulario se podrá poner el nombre de un municipio, que si existe, quedará seleccionado para este usuario.

    \item Un botón ``Quitar'' que aparecerá asociado a cada municipio seleccionado, que permitirá al usuario ``deseleccionar'' el municipio de su lista.
  \end{enumerate}
\end{itemize}

%Si es preciso, se añadirán más recursos (pero sólo si es realmente preciso) para poder satisfacer los requisitos especificados.

Dados los recursos mencionados anteriormente, no se permitirán los nombres de usuario ``municipios'' ni ``info'' (pero no hay que hacer ninguna comprobación para esto: se asume que no se darán de alta esos usuarios en el Admin Site).


%%----------------------------------------------------------------------------
\subsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

En el formulario de entrega se pide que se justifique por qué se considera funcionalidad optativa lo que habeis implementado. Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
  \item Inclusión de un \emph{favicon} del sitio
  
  \item Visualización de las páginas en formato JSON, de forma similar a como el enunciado indica para XML.

  \item Generación de un canal RSS, XML libre y/o JSON para los comentarios puestos en el sitio.

  \item Incorporación de datos del canal RSS de avisos de AEMET\footnote{Canales RSS de AEMET: \url{http://www.aemet.es/es/rss_info}} a la página principal y/o a otras páginas ofrecidas por la aplicación.
    
  \item Funcionalidad para acceder a datos ofrecidos por AEMT via su API de datos abiertos\footnote{AEMET open data: \url{https://opendata.aemet.es}}
  
  \item Funcionalidad de registro de usuarios: que la aplicación proporcione la funcionalidad de registrarse en el sitio.
  
  \item Uso de Javascript o AJAX para algún aspecto de la práctica (por ejemplo, para seleccionar un municipio para una página de usuario).

  \item Puntuación de municipios. Cada visitante (registrado o no) puede dar un ``+1'' a cualquier municipio que aparezca en el sitio. La suma de ``+'' que ha obtenido un municipio se verá cada vez que se vea el municipio en el sitio.
  
  \item Uso de elementos HTML5 (especificar cuáles al entregar)

  \item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

  \item Despliegue de la práctica en algún sitio de Internet, de forma que pueda accederse a ella. Por ejemplo, puede considerarse desplegar en un ordenador dedicado (por ejemplo, Raspberry Pi accesible directamente desde Internet), o en servicios como Google Computing Engine\footnote{GCP Engine Free: \url{https://cloud.google.com/free/}} o Heroku\footnote{Heroku Free: \url{https://www.heroku.com/free}}.
\end{itemize}

%%----------------------------------------------------------------------------
\subsection{Entrega de la práctica}

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} viernes, 24 de mayo de 2019 a las 03:00 (hora española peninsular)\footnote{Entiéndase la hora como jueves por la noche, ya entrado en viernes.}
       %{\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

  \item \textbf{Fecha de publicación de notas de prácticas:} sábado 25 de mayo, en el aula virtual.
%{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

  \item \textbf{Fecha de revisión de prácticas:} martes 28 de mayo, a las 12:00. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
%{\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
\end{itemize}

La entrega de la práctica consiste en {\bf rellenar un formulario} (enlazado en el Moodle de la asignatura) y en seguir las instrucciones que se describen a continuación.

\begin{enumerate}
  \item El repositorio contendrá todos los ficheros necesarios para que funcione la aplicación (ver detalle más abajo). Es muy importante que el alumno haya realizado una derivación (fork) del repositorio que se indica a continuación, porque si no, la práctica no podrá ser identificada: 

\url{https://gitlab.etsit.urjc.es/cursosweb/practicas/server/final-mitiempo/}

Los alumnos que no entreguen las práctica de esta forma serán considerados como no presentados en lo que a la entrega de prácticas se refiere. Los que la entreguen podrán ser llamados a realizar también una entrega presencial, que tendrá lugar en la fecha y hora de la revisión. Esta entrega presencial podrá incluir una conversación con el profesor sobre cualquier aspecto de la realización de la práctica.

Recordad que es importante ir haciendo commits de vez en cuando y que sólo al hacer push estos commits son públicos. Antes de entregar la práctica, haced un push. Y cuando la entreguéis y sepáis el nombre del repositorio, podéis cambiar el nombre del repositorio desde el interfaz web de GitLab. 
 
 \item Un vídeo de demostración de la parte obligatoria, y otro vídeo de demostración de la parte opcional, si se han realizado opciones avanzadas. Los vídeos serán de una {\bf duración máxima de 3 minutos} (cada uno), y consistirán en una captura de pantalla de un navegador web utilizando la aplicación, y mostrando lo mejor posible la funcionalidad correspondiente (básica u opcional). Siempre que sea posible, el alumno comentará en el audio del vídeo lo que vaya ocurriendo en la captura. Los vídeos se colocarán en algún servicio de subida de vídeos en Internet (por ejemplo, Vimeo, Twitch, o YouTube). Los vídeos de más de tres minutos tendrán penalización.

Hay muchas herramientas que permiten realizar la captura de pantalla. Por ejemplo, en GNU/Linux puede usarse Gtk-RecordMyDesktop o Istanbul (ambas disponibles en Ubuntu). OBS Studio\footnote{OBS Studio: \url{https://obsproject.com/}} está disponible para varias plataformas (Linux, Windows, MacOS). Es importante que la captura sea realizada de forma que se distinga razonablemente lo que se grabe en el vídeo.

En caso de que convenga editar el vídeo resultante (por ejemplo, para eliminar tiempos de espera) puede usarse un editor de vídeo, pero siempre deberá ser indicado que se ha hecho tal cosa con un comentario en el audio, o un texto en el vídeo. Hay muchas herramientas que permiten realizar esta edición. Por ejemplo, en GNU/Linux puede usarse OpenShot o PiTiVi.

  \item Se han de entregar los siguientes ficheros:

\begin{itemize}
  \item Un fichero README.md que resuma las mejoras, si las hay, y explique cualquier peculiaridad de la entrega (ver siguiente punto).
  \item El repositorio en el GitLab de la ETSIT deberá contener un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos dos usuarios con sus datos correspondientes, con al menos seis municipios en su página personal, al menos 12 municipios distintos seleccionados, y con al menos cinco comentarios en total.
  \item Cualquier biblioteca Python que pueda hacer falta para que la aplicación funcione, junto con los ficheros auxiliares que utilice, si es que los utiliza.
\end{itemize}

  \item Se incluirán en el fichero README.md los siguientes datos (la mayoría de estos datos se piden también en el formulario que se ha de rellenar para entregar la práctica - se recomienda hacer un corta y pega de estos datos en el formulario):

\begin{itemize}
  \item Nombre y titulación.
  \item Nombre de su cuenta en el laboratorio del alumno.
  \item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
  \item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
  \item URL del vídeo demostración de la funcionalidad básica
  \item URL del vídeo demostración de la funcionalidad optativa, si se ha realizado funcionalidad optativa
  \item Cuenta (login) y contraseña de los usuarios que están dados de alta en la aplicación.
  \item URL de la aplicación desplegada (si es que se ha desplegado)
\end{itemize}

Asegúrate de que las URLs incluidas en este fichero están adecuadamente escritas en Markdown, de forma que la versión HTML que genera GitLab los incluya como enlaces ``pinchables''.

\end{enumerate}


%%----------------------------------------------------------------------------
\subsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura con la versión de Django que se ha usado en prácticas.

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el navegador Firefox (considerándolos como canales RSS) disponibles en el laboratorio. Los documentos XML deberán ser correctos desde el punto de vista de la sintaxis XML, y por lo tanto reconocibles por un reconocedor XML, como por ejemplo el del módulo xml.sax de Python. Los documentos JSON generados deberán ser correctos desde el punto de vista de la sintaxis JSON, y por lo tanto reconocibles por un reconocedor JSON, como por ejemplo el del módulo json de Python

%%----------------------------------------------------------------------------
\subsection{Preguntas y respuestas}

A continuación, algunas preguntas relacionadas con el enunciado de esta práctica, junto con sus respuestas:

\begin{itemize}
\item ¿Es necesario utilizar los mecanismos provistos por Django para el control de sesiones y autenticación?

  En principio, esa es la solución recomendada. El principal problema suele ser asegurarse de que cuaquier mecanismo alternativo funciona al menos tan bien como el de Django, lo que no es en general trivial. De todas formas, salvo muy buenos motivos, la aplicación es una aplicación Django, y por lo tanto cuantas más facilidades de Django se usen (bien usadas), mejor.
  
\item ¿Puedo guardar en la base de datos los datos referentes a latitud, altitud, etc (datos que no varian nunca) y precipitación, temperatura, descripción, etc y cambiarlos cuando sea necesario (ya que estos si cambian)?

  Pueden almacenarse en tablas en la base de datos los datos correspondientes a poblaciones que han sido seleccionadas por al menos un usuario. En otras palabras, cada vez que un usuario seleccione un municipio, puedes guardar en una tabla en la base de datos los datos sobre ese municipio (includos latitud y longitud). Pero no puedes analizar todos los municipios que hay en el fichero JSON e incorporar su información a la base de datos.

  La información sobre un municipio que puedas almacenar en la base de datos deberá actualizarse cuando se acceda al fichero XML para ese municipio, según indica el enunciado (por ejemplo, porque un usuario selecciona ese municipio, o porque hay un acceso a su página de municipio).

\item Los archivos CSS que pueden modificar los usuarios, ¿dónde y cómo debemos guardarlos?

  La forma recomendada de hacerlo es mediante plantillas:

  \begin{itemize}
  \item En el directorio de plantillas incluirías una para la hoja CSS del sitio. Esa plantilla tendría como variables de plantilla los valores que quieras que los usuarios puedan cambiar (color de tipo de letra, tamaño de tipo de letra, etc.).
  \item Además, para cada usuario, tendrás una tabla donde se almacenarán los valores para ese usuario (normalmente, una fila de la tabla por usuario).
  \item Tendrás una vista en views.py que se encargará de generar la hoja CSS a partir de la plantilla. Esa vista es la que comprobará si la petición que está atendiendo corresponde a un usuario (en cuyo caso tendrá que obtener los valores para ese usuario de la tabla anterior), o no (en cuyo caso usará valores por defecto). Con los valores que obtenga, generará la hoja CSS a partir de la plantilla anterior.
  \item Por último, en urls.py tendrás una línea para indicar que si te piden el recurso que sirve la hoja de estilo, llamas a la vista anterior.
  \end{itemize}

\item ¿Qué partes de la página tiene que modificar el CSS ``customizable'' del usuario? En el enunciado de la práctica dice ``se usarán hojas CSS para cambiar al menos el tamaño y color de la letra, y el color del fondo, para los elementos marcados con un id, tal y como se especifica en el apartado anterior''. En el ``apartado anterior'' lo que se especifica es que el banner, caja de login, menú y pie de página tienen que ir cada uno en un elemento div con una id. ¿Significa esto que el CSS que personaliza el usuario se aplica solo a esos cuatro elementos, o aplica a toda la página? ¿En el caso de ser a cada uno de los cuatro elementos, debería el usuario poder modificar el color y letra de cada uno de ellos por separado, o aplicaría para los cuatro el mismo estilo?

  Creemos que el enunciado no es ambiguo. Debe haber, por un lado, estilos CSS que afecten, como mínimo, al tamaño y color de la letra, y al color de fondo, de los elementos que es obligatorio marcar con un id, según indica el enunciado (efectivamente, el banner, la caja de login, etc.) Pueden llevar todos los mismos valores, o valores diferentes, como quiera quien realice la práctica, pero los estilos tienen que estar aplicados específicamente a esos ids.

  Por otro lado, el usuario puede especificar unos cuantos valores para toda la página (según indica el enunciado: ``Un formulario para cambiar el estilo CSS de todo el sitio para ese usuario. Bastará con que se pueda cambiar el tamaño y el color de la letra y el color de fondo. Si se cambian estos valores, quedará cambiado el documento CSS que utilizarán todas las páginas del sitio para este usuario.`` Esto es, al indicar en el formulario valores para lo que puede personalizar el usuario (como mínimo el color de la letra y el color de fondo) estos valores se cambiarán para todo el sitio. Este color de letra y de fondo pueden aplicarse a todos los elementos que se muestren en el sitio, o sólo a algunos de ellos (por ejemplo, a todos los que no se ven afectados por los id mencionados anteriormente), según quiera el alumno. Lo importante es que el cambio afecte, en los elementos que se vean afectados, a todas las páginas del sitio. Naturalmente, si se decide cambiar por ejemplo la apariencia de todos los elementos del sitio, eso afectará también a los que tengan id Por eso quizás no sea una buena idea cambiar también estos elementos, desde el punto de vista estético, dado que quizás sea mejor que aparezcan con u  color de letra y/o de fondo diferente. Pero eso queda como decisión del alumno.
  
\item Si decido trabajar en la opción de despliegue de la aplicación, ¿dónde puedo realizar este despliegue?

  El despliegue puede realizarse en caulquier ordenador que esté conectado permanentemente a Internet durante el periodo de correción, en una dirección accesible desde cualquier navegador conectado a su vez a Internet. Esto puede ser por ejemplo un ordenador personal en un domicilio con acceso permanente a Intener, adecaudamente configurado (puede ser una Raspberry Pi o similar, si se busca una solución simple y de bajo coste). También puede ser un servicio en Internet, por ejemplo uno gratuito como los que ofrecen Google (instrucciones\footnote{GCP Quickstart Using a Linux VM:\\ \url{https://cloud.google.com/compute/docs/quickstart-linux}}, precios\footnote{Google Compute Engine Pricing:\\ \url{https://cloud.google.com/compute/pricing}}), Heroku (instrucciones\footnote{Heroku Deploying with Git:\\ \url{https://devcenter.heroku.com/categories/deploying-with-git}}, características\footnote{Heroku Free Dyno Hours:\\ \url{https://devcenter.heroku.com/articles/free-dyno-hours}}) o PythonAmywhere (instrucciones\footnote{Capítulo ``Deploy!'' de Django Girls Tutorial:\\ \url{https://tutorial.djangogirls.org/en/deploy/}}, precios\footnote{PythonAnywhere Plans and Pricing:\\ \url{https://www.pythonanywhere.com/pricing/}}).

\item Para las URLs de los documentos XML que ofrece MiTiempo, ¿puedo usar la terminación \verb|format=xml| en lugar de \verb|?format=xml| ?

  Sí. Debido a un error, los primeros enunciados mencionaban la terminación \verb|format=xml| para estos ficheros. Por ello, el alumno puede elegir entre servirlos con ese nombre de recurso, o con el que indica la versión final del enunciado, \verb|?format=xml|. Si aún no se ha realizado la implementación de ninguna de las dos formas, se recomienda hacerlo como indica el enunciado definitivo, porque eso permitirá utilizar la misma vista (view) que se utiliza para el documento HTML correspondiente, simplemente comprobando si la petición incluye una ``query string'' (utilizando los mecanismos pertinentes de Django). Pero como se ha dicho, si el alumno prefiere implementarlo de la otra forma, se considerara de la misma manera.
\end{itemize}


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2019, junio)}
\label{practica-final-2019-06}

El proyecto final para la convocatoria de junio de 2019 será la misma que la descrita para la convocatoria de mayo de 2019, con las siguientes consideraciones:

\begin{itemize}
  \item En vez de ``\emph{La página principal se ofrece rá también como un documento XML, que incluirá la misma lista de municipios, y un enlace al fichero XML que proporciona para cada uno de ellos la AEMET. Este documento se ofrecerá cuando se pida la URL de municipios, concatenando al final} \verb|?format=xml|' ahora será ``\emph{La página principal se ofrecerá también como un documento JSON, que incluirá la misma lista de municipios, y un enlace al fichero XML que proporciona para cada uno de ellos la AEMET. Este documento se ofrecerá cuando se pida la URL de municipios, concatenando al final} \verb|?format=json|''.
  \item En vez de ``\emph{Mostrará un listado de los 10 municipios con más comentarios. Si no hubiera 10 municipios con comentarios, se mostrarán sólo los que tengan comentarios}'' ahora será ``\emph{Mostrará un listado de los 10 municipios más seleccionados por los usuarios. Si no hubiera 10 municipios seleccionados, se mostrarán sólo los que se hayan seleccionado}''.
\end{itemize}

Las fechas de entrega, publicación y revisión de esta convocatoria quedan como siguen:

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} lunes, 1 de julio de 2019 a las 05:00 (hora española peninsular)\footnote{Entiéndase la hora como domingo por la noche, ya entrado el lunes.}.

  \item \textbf{Fecha de publicación de notas:} miércoles, 3 de julio de 2019, en la plataforma Moodle.

  \item \textbf{Fecha de revisión:} viernes, 5 de julio de 2019 a las 10:00.

\end{itemize}


\newpage

\newpage


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2018, mayo)}
\label{practica-final-2018-05}

El proyecto final de la asignatura consiste en la creación de una aplicación web que aglutine información sobre museos de la ciudad de Madrid. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

La aplicación se encargará de descargar información sobre los mencionados museos, disponibles públicamente en varios formatos en el portal de datos abiertos de Madrid, y de ofrecerlos a los usuarios para que puedan seleccionar los que les parezca más interesantes, y comentar sobre ellos. De esta manera, un escenario típico es el de un usuario que a partir de los museos disponibles, elija los que le parezca más adecuados, y comente sobre los que quiera.

%%----------------------------------------------------------------------------
\subsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}

  \item La práctica se construirá como un proyecto Django/Python3, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

  \item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas en modelos de Django.

  \item Se usará la aplicación Django ``Admin Site'' para crear cuenta a los usuarios en el sistema, y para la gestión general de las bases de datos necesarias. Todas las bases de datos que contenga la aplicación tendrá que ser accesible vía este ``Admin Site''.

  \item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que la práctica tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un \emph{banner} (imagen) del sitio, en la parte superior izquierda.
  \item Una caja para entrar (hacer login en el sitio), o para salir (si ya se ha entrado).
  \begin{itemize}
    \item En caso de que no se haya entrado en una cuenta, esta caja permitirá al visitante introducir su identificador de usuario y su contraseña. 
    \item En caso de que ya se haya entrado, esta caja mostrará el identificador del usuario y permitirá salir de la cuenta (logout). Esta caja aparecerá en la parte superior derecha.
  \end{itemize}
  \item Un menú de opciones, como barra, debajo de los dos elementos anteriores (banner y caja de entrada o salida).
  \item Un pie de página con una nota de atribución, indicando ``Esta aplicación utiliza datos del portal de datos abiertos de la ciudad de Madrid'', y un enlace a la página con los datos, y a la descripción de los mismos (ver enlaces más abajo).
  \end{itemize}

Cada una de estas partes estará marcada con propiedades ``id'' en HTML, para poder ser referenciadas en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la práctica. Estas hojas definirán al menos el color y el tamaño de la letra, y el color de fondo de cada una de las partes (elementos) marcadas con id que se indican en el apartado anterior.

\item Se utilizará, para componer la información sobre museos, la disponible en el portal de datos abiertos de la ciudad de Madrid:

  \item Fichero con los datos abiertos de museos proporcionado por el Ayuntamiento de Madrid: \\
    \url{https://datos.madrid.es/portal/site/egob/menuitem.c05c1f754a33a9fbe4b2e4b284f1a5a0/?vgnextoid=118f2fdbecc63410VgnVCM1000000b205a0aRCRD&vgnextchannel=374512b9ace9f310VgnVCM100000171f5a0aRCRD&vgnextfmt=default}

  \item Copia del fichero anterior en el repositorio CursosWeb/Code de GitHub: \\
    \url{https://github.com/CursosWeb/CursosWeb.github.io/tree/master/etc}
\end{itemize}

Funcionamiento general:

\begin{itemize}
  \item Los usuarios serán dados de alta en la práctica mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

  \item El listado de museos se cargará a partir del fichero XML cuando un usuario indique que se carguen. Hasta que algún usuario indique por primera vez que se carguen los datos, no habrá listado de museos en la base de datos te la aplicación.

  \item Los usuarios registrados podrán crear su selección de museos. Para ello, dispondrán de una página personal. Llamaremos a esta página la ``página del usuario''.

  \item La selección de museos en su página personal la realizará cada usuario a partir de información sobre museos ya disponibles en el sitio.

  \item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá la página personal de cada usuario, para todos los usuarios del sitio.

  \item Cualquier usuario podrá indicar que quiere una vista del sitio que incluya sólo los museos (los que en XML tienen el atributo de nombre ``Accesibilidad'' con valor ``1'').
\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Funcionalidad mínima}

Los museos se obtendrán a partir de la información pública ofrecida por el Ayuntamiento de Madrid en el Portal de Datos Abiertos, en forma de ficheros XML, como se indicaba anteriormente.

La {\bf interfaz pública} contiene los recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no):

\begin{itemize}
  \item /: Página principal de la práctica. Constará de un listado de museos y otro con enlaces a páginas personales:
  
  \begin{enumerate}
    \item Mostrará un listado de los cinco museos con más comentarios. Si no hubiera 5 museos con comentarios, se mostrarán sólo los que tengan comentarios. Para cada museo, incluirá información sobre:
    \begin{itemize}
      \item su nombre (que será un enlace que apuntará a la URL del museo en el portal esmadrid), 
      \item su dirección,
      \item y un enlace, ``Más información'', que apuntará a la página del museo en la aplicación (ver más adelante).
    \end{itemize}
   
  \item También se mostrará un listado, en una columna lateral, con enlaces a las páginas personales disponibles. Para cada página personal mostrará el título que le haya dado su usuario (como un enlace a la página personal en cuestión) y el nombre del usuario. Si a una página personal aún no se le hubiera puesto título, este título será ``Página de usuario'', donde ``usuario'' es el identificador de usuario del usuario en cuestión.
    \item Tambień se mostrará un botón, que al pulsarlo se pasará a ver en todos los listados los museos accesibles, y sólo estos. Si se vuelve a pulsar, se volverán a ver todos los museos.
   \end{enumerate}

  \item /{usuario}: Página personal de un usuario. Si la URL es ``/usuario'', es que corresponde al usuario ``usuario''. Mostrará los museos seleccionados por ese usuario (aunque no puede haber más de 5 a la vez; si hay más debería haber un enlace para mostrar las 5 siguientes y así en adelante, siempre de 5 en 5). Para cada museo se mostrará la misma información que en la página principal. Además, para cada museo se deberá mostrar la fecha en la que fue seleccionada por el usuario.

  \item /museos: Página con todos los museos. Para cada uno de ellos aparecerá sólo el nombre, y un enlace a su página. En la parte superior de la página, existirá un formulario que permita filtrar estos museos según el distrito. Para poder filtrar por distrito, se buscará en la base de datos cuáles son los distritos con museos.

  \item /museos/{id}: Página de un museo en la aplicación. Mostrará toda la información razonablemente posible de XML del portal de datos abierto del Ayuntamiento de Madrid, incluyendo al menos la que se menciona en otros apartados de este enunciado, la dirección, la descripción, si es accesible o no, el barrio y el distrito, y los datos de contacto. Además, se mostrarán todos los comentarios que se hayan puesto para este museo.
  
  \item /{usuario}/xml: Canal XML para los museos seleccionados por ese usuario. El documento XML tendrá una entrada para cada museo seleccionado por el usuario, y tendrá una estructura similar (pero no necesariamente igual) a la del fichero XML del portal del Ayuntamiento.

  \item /about: Página con información en HTML indicando la autoría de la práctica, explicando su funcionamiento.

\end{itemize}

Todas las páginas de la interfaz pública incluirán un menú desde el que se podrá acceder a todos los museos (URL /museos) con el texto ``Todos'' y a la ayuda (URL /about) con el texto ``About''. Todas las página que no sean la principal tendrán otra opción de menú para la URL /, con el texto ``Inicio''.

La {\bf interfaz privada} contiene los recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado):

\begin{itemize}
  \item Todos los recursos de la interfaz pública.
  
  \item /museos/{id}: Además de la información que se muestra de manera pública:

    \begin{enumerate}
      \item Un formulario para poner comentarios sobre este museo. Los comentarios serán anónimos, pero sólo se podrán poner por los usuarios registrados, una vez se han autenticado. Por tanto, bastará con que este formulario esté compuesto por una caja de texto, donde se podrá escribir el comentario, y un botón para enviarlo.
  \end{enumerate}

  \item /{usuario}: Además de la información que se muestra de manera pública:
  
  \begin{enumerate}
    \item Un formulario para cambiar el estilo CSS de todo el sitio para ese usuario. Bastará con que se pueda cambiar el tamaño de la letra y el color de fondo. Si se cambian estos valores, quedará cambiado el documento CSS que utilizarán todas las páginas del sitio para este usuario. Este cambio será visible en cuanto se suba la nueva página CSS.

    \item Un formulario para elegir el título de su página personal.
  \end{enumerate}
\end{itemize}

%Si es preciso, se añadirán más recursos (pero sólo si es realmente preciso) para poder satisfacer los requisitos especificados.

Dados los recursos mencionados anteriormente, no se permitirán los nombres de usuario ``museos'' ni ``about'' (pero no hay que hacer ninguna comprobación para esto: se asume que no se darán de alta esos usuarios en el Admin Site).


%%----------------------------------------------------------------------------
\subsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

En el formulario de entrega se pide que se justifique por qué se considera funcionalidad optativa lo que habeis implementado. Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
  \item Inclusión de un \emph{favicon} del sitio
  
  \item Generación de un canal XML para los contenidos que se muestran en la página principal.

  \item Generación de canales, pero con los contenidos en JSON

  \item Generación de un canal RSS para los comentarios puestos en el sitio.
  
  \item Funcionalidad para leer los datos del Ayuntamiento en otros formatos diferentes a XML: CSV, JSON...
  
  \item Funcionalidad de registro de usuarios
  
  \item Uso de Javascript o AJAX para algún aspecto de la práctica (por ejemplo, para seleccionar un museo para una página de usuario).

  \item Puntuación de museos. Cada visitante (registrado o no) puede dar un ``+1'' a cualquier museo del sitio. La suma de ``+'' que ha obtenido un museo se verá cada vez que se vea el museo en el sitio.
  
  \item Uso de elementos HTML5 (especificar cuáles al entregar)

  \item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Entrega de la práctica}

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} lunes, 21 de mayo de 2018 a las 03:00 (hora española peninsular)\footnote{Entiéndase la hora como domingo por la noche, ya entrado en lunes.}
       %{\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

  \item \textbf{Fecha de publicación de notas:} miércoles, 23 de mayo de 2018, en la plataforma Moodle.
%{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

  \item \textbf{Fecha de revisión:} jueves, 24 de mayo de 2018 a las 13:00.
%{\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
\end{itemize}

La entrega de la práctica consiste en rellenar un formulario (enlazado en el Moodle de la asignatura) y en seguir las instrucciones que se describen a continuación.

\begin{enumerate}
  \item El repositorio contendrá todos los ficheros necesarios para que funcione la aplicación (ver detalle más abajo). Es muy importante que el alumno haya realizado un fork del repositorio que se indica a continuación, porque si no, la práctica no podrá ser identificada: 

\url{https://github.com/CursosWeb/X-Serv-Practica-Museos}

Los alumnos que no entreguen las práctica de esta forma serán considerados como no presentados en lo que a la entrega de prácticas se refiere. Los que la entreguen podrán ser llamados a realizar también una entrega presencial, que tendrá lugar en la fecha y hora de la revisión. Esta entrega presencial podrá incluir una conversación con el profesor sobre cualquier aspecto de la realización de la práctica.

Recordad que es importante ir haciendo commits de vez en cuando y que sólo al hacer push estos commits son públicos. Antes de entregar la práctica, haced un push. Y cuando la entreguéis y sepáis el nombre del repositorio, podéis cambiar el nombre del repositorio desde el interfaz web de GitHub. 
 
 \item Un vídeo de demostración de la parte obligatoria, y otro vídeo de demostración de la parte opcional, si se han realizado opciones avanzadas. Los vídeos serán de una {\bf duración máxima de 3 minutos} (cada uno), y consistirán en una captura de pantalla de un navegador web utilizando la aplicación, y mostrando lo mejor posible la funcionalidad correspondiente (básica u opcional). Siempre que sea posible, el alumno comentará en el audio del vídeo lo que vaya ocurriendo en la captura. Los vídeos se colocarán en algún servicio de subida de vídeos en Internet (por ejemplo, Vimeo o YouTube). Los vídeos de más de tres minutos tendrán penalización.

Hay muchas herramientas que permiten realizar la captura de pantalla. Por ejemplo, en GNU/Linux puede usarse Gtk-RecordMyDesktop o Istanbul (ambas disponibles en Ubuntu). Es importante que la captura sea realizada de forma que se distinga razonablemente lo que se grabe en el vídeo.

En caso de que convenga editar el vídeo resultante (por ejemplo, para eliminar tiempos de espera) puede usarse un editor de vídeo, pero siempre deberá ser indicado que se ha hecho tal cosa con un comentario en el audio, o un texto en el vídeo. Hay muchas herramientas que permiten realizar esta edición. Por ejemplo, en GNU/Linux puede usarse OpenShot o PiTiVi.

  \item Se han de entregar los siguientes ficheros:

\begin{itemize}
  \item Un fichero README.md que resuma las mejoras, si las hay, y explique cualquier peculiaridad de la entrega (ver siguiente punto).
  \item El repositorio GitHub deberá contener un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos dos usuarios con sus datos correspondientes, con al menos cinco museos en su página personal, y con al menos cinco comentarios en total.
  \item Cualquier biblioteca Python que pueda hacer falta para que la aplicación funcione, junto con los ficheros auxiliares que utilice, si es que los utiliza.
\end{itemize}

  \item Se incluirán en el fichero README.md los siguientes datos (la mayoría de estos datos se piden también en el formulario que se ha de rellenar para entregar la práctica - se recomienda hacer un corta y pega de estos datos en el formulario):

\begin{itemize}
  \item Nombre y titulación.
  \item Nombre de su cuenta en el laboratorio del alumno.
  \item Nombre de usuario en GitHub.
  \item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
  \item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
  \item URL del vídeo demostración de la funcionalidad básica
  \item URL del vídeo demostración de la funcionalidad optativa, si se ha realizado funcionalidad optativa
\end{itemize}

Asegúrate de que las URLs incluidas en este fichero están adecuadamente escritas en Markdown, de forma que la versión HTML que genera GitHub los incluya como enlaces ``pinchables''.

\end{enumerate}


%%----------------------------------------------------------------------------
\subsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura con la versión de Django que se ha usado en prácticas.

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el navegador Firefox (considerándolos como canales RSS) disponibles en el laboratorio. Los documentos XML deberán ser correctos desde el punto de vista de la sintaxis XML, y por lo tanto reconocibles por un reconocedor XML, como por ejemplo el reconocedor del módulo xml.sax de Python.


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2018, junio)}
\label{practica-final-2018-06}

El proyecto final para la convocatoria de junio de 2018 será la misma que la descrita para la convocatoria de mayo de 2018, con las siguientes consideraciones:

\begin{itemize}
  \item En vez de /{usuario}/xml: Canal XML para los museos seleccionados por ese usuario, se ofrecerá el canal en formato JSON. El documento JSON tendrá una entrada para cada museo seleccionado por el usuario, y tendrá una estructura similar (pero no necesariamente igual) a la del fichero JSON del portal del Ayuntamiento.
  \item La página principal no mostrará los cinco museos más comentados, sino que mostrará los cinco museos más seleccionados por usuarios para sus páginas personales.
\end{itemize}

Las fechas de entrega, publicación y revisión de esta convocatoria quedan como siguen:

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} viernes, 28 de junio de 2018 a las 05:00 (hora española peninsular)\footnote{Entiéndase la hora como jueves por la noche, ya entrado el viernes.}.
       %{\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

  \item \textbf{Fecha de publicación de notas:} domingo, 1 de julio de 2018, en la plataforma Moodle.
%{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

  \item \textbf{Fecha de revisión:} martes, 3 de julio de 2018 a las 12:00.
%{\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
\end{itemize}


\newpage

\newpage

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2017, mayo)}
\label{practica-final-2017-05}

El proyecto final de la asignatura consiste en la creación de una aplicación web que aglutine información sobre aparcamientos en la ciudad de Madrid. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

La aplicación se encargará de descargar información sobre los mencionados aparcamientos, disponibles públicamente en formato XML en el portal de datos abiertos de Madrid, y de ofrecerlos a los usuarios para que puedan seleccionar los que les parezca más interesantes, y comentar sobre ellos. De esta manera, un escenario típico es el de un usuario que a partir de los aparcamientos disponibles, elija los que le parezca más adecuados, y comente sobre los que quiera.

%%----------------------------------------------------------------------------
\subsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}

  \item La práctica se construirá como un proyecto Django/Python3, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

  \item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas en modelos de Django.

  \item Se usará la aplicación Django ``Admin Site'' para crear cuenta a los usuarios en el sistema, y para la gestión general de las bases de datos necesarias. Todas las bases de datos que contenga la aplicación tendrá que ser accesible vía este ``Admin Site''.

  \item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que la práctica tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un \emph{banner} (imagen) del sitio, en la parte superior izquierda.
  \item Una caja para entrar (hacer login en el sitio), o para salir (si ya se ha entrado).
  \begin{itemize}
    \item En caso de que no se haya entrado en una cuenta, esta caja permitirá al visitante introducir su identificador de usuario y su contraseña. 
    \item En caso de que ya se haya entrado, esta caja mostrará el identificador del usuario y permitirá salir de la cuenta (logout). Esta caja aparecerá en la parte superior derecha.
  \end{itemize}
  \item Un menú de opciones, como barra, debajo de los dos elementos anteriores (banner y caja de entrada o salida).
  \item Un pie de página con una nota de atribución, indicando ``Esta aplicación utiliza datos del portal de datos abiertos de la ciudad de Madrid'', y un enlace al XML con los datos, y a la descripción de los mismos (ver enlaces más abajo).
  \end{itemize}

Cada una de estas partes estará marcada con propiedades ``id'' en HTML, para poder ser referenciadas en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la práctica. Estas hojas definirán al menos el color y el tamaño de la letra, y el color de fondo de cada una de las partes (elementos) marcadas con id que se indican en el apartado anterior.

\item Se utilizará, para componer la información sobre aparcamientos disponibles, la disponible en el portal de datos abiertos de la ciudad de Madrid:

  \item Fichero con los datos abiertos de aparcamientos para residentes proporcionado por el Ayuntamiento de Madrid: \\
    \url{http://datos.munimadrid.es/portal/site/egob/menuitem.ac61933d6ee3c31cae77ae7784f1a5a0/?vgnextoid=00149033f2201410VgnVCM100000171f5a0aRCRD&format=xml&file=0&filename=202584-0-aparcamientos-residentes&mgmtid=e84276ac109d3410VgnVCM2000000c205a0aRCRD&preview=full}

  \item Descripción del fichero: \\
    \url{http://datos.madrid.es/portal/site/egob/menuitem.c05c1f754a33a9fbe4b2e4b284f1a5a0/?vgnextoid=e84276ac109d3410VgnVCM2000000c205a0aRCRD&vgnextchannel=374512b9ace9f310VgnVCM100000171f5a0aRCRD&vgnextfmt=default}
      
  \item Copia del fichero anterior en el repositorio CursosWeb/Code de GitHub: \\
\end{itemize}

Funcionamiento general:

\begin{itemize}
  \item Los usuarios serán dados de alta en la práctica mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

  \item El listado de aparcamientos se cargará a partir del fichero XML cuando un usuario indique que se carguen. Hasta que algún usuario indique por primera vez que se carguen los datos, no habrá listado de aparcamientos en la base de datos te la aplicación.

  \item Los usuarios registrados podrán crear su selección de aparcamientos. Para ello, dispondrán de una página personal. Llamaremos a esta página la ``página del usuario''.

  \item La selección de aparcamientos en su página personal la realizará cada usuario a partir de información sobre aparcamientos ya disponibles en el sitio.

  \item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá la página personal de cada usuario, para todos los usuarios del sitio.

  \item Cualquier usuario podrá indicar que quiere una vista del sitio que incluya sólo los aparcamientos accesibles (los que en XML tienen ``accesibility'' con valor ``1'').
\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Funcionalidad mínima}

Los aparcamientos se obtendrán a partir de la información pública ofrecida por el Ayuntamiento de Madrid en el Portal de Datos Abiertos, en forma de ficheros XML, como se indicaba anteriormente.

La {\bf interfaz pública} contiene los recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no):

\begin{itemize}
  \item /: Página principal de la práctica. Constará de un listado de aparcamientos y otro con enlaces a páginas personales:
  
  \begin{enumerate}
    \item Mostrará un listado de los cinco aparcamientos con más comentarios. Si no hubiera 5 aparcamientos con comentarios, se mostrarán sólo los que tengan comentarios. Para cada aparcamiento, incluirá información sobre:
    \begin{itemize}
      \item su nombre (que será un enlace que apuntará a la url del aparcamiento en el portal esmadrid), 
      \item su dirección,
      \item y un enlace, ``Más información'', que apuntará a la página del aparcamiento en la aplicación (ver más adelante).
    \end{itemize}
   
  \item También se mostrará un listado, en una columna lateral, con enlaces a las páginas personales disponibles. Para cada página personal mostrará el título que le haya dado su usuario (como un enlace a la página personal en cuestión) y el nombre del usuario. Si a una página personal aún no se le hubiera puesto título, este título será ``Página de usuario'', donde ``usuario'' es el identificador de usuario del usuario en cuestión.
    \item Tambień se mostrará un botón, que al pulsarlo se pasará a ver en todos los listados los aparcamientos accesibles, y sólo estos. Si se vuelve a pulsar, se volverán a ver todos los aparcamientos.
   \end{enumerate}

  \item /{usuario}: Página personal de un usuario. Si la URL es ``/usuario'', es que corresponde al usuario ``usuario''. Mostrará los aparcamientos seleccionados por ese usuario (aunque no puede haber más de 5 a la vez; si hay más debería haber un enlace para mostrar las 5 siguientes y así en adelante, siempre de 5 en 5). Para cada aparcamiento se mostrará la misma información que en la página principal. Además, para cada aparcamiento se deberá mostrar la fecha en la que fue seleccionada por el usuario.

  \item /aparcamientos: Página con todos los aparcamientos. Para cada uno de ellos aparecerá sólo el nombre, y un enlace a su página. En la parte superior de la página, existirá un formulario que permita filtrar estos aparcamientos según el distrito. Para poder filtrar por distrito, se buscará en la base de datos cuáles son los distritos con aparcamientos.

  \item /aparcamientos/{id}: Página de un aparcamiento en la aplicación. Mostrará toda la información razonablemente posible de XML del portal de datos abierto del Ayuntamiento de Madrid, incluyendo al menos la que se menciona en otros apartados de este enunciado, la información de latitud y longitud, la descripción, si es accesible o no, el barrio y el distrito, y los datos de contacto. Además, se mostrarán todos los comentarios que se hayan puesto para este aparcamiento.
  
  \item /{usuario}/xml: Canal XML para los aparcamientos seleccionados por ese usuario. El documento XML tendrá una entrada para cada aparcamiento seleccionado por el usuario, y tendrá una estructura similar (pero no necesariamente igual) a la del fichero XML del portal del Ayuntamiento.

  \item /about: Página con información en HTML indicando la autoría de la práctica y explicando su funcionamiento.

\end{itemize}

Todas las páginas de la interfaz pública incluirán un menú desde el que se podrá acceder a todos los aparcamientos (URL /aparcamientos) con el texto ``Todos'' y a la ayuda (URL /about) con el texto ``About''. Todas las página que no sean la principal tendrán otra opción de menú para la URL /, con el texto ``Inicio''.

La {\bf interfaz privada} contiene los recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado):

\begin{itemize}
  \item Todos los recursos de la interfaz pública.
  
  \item /aparcamientos/{id}: Además de la información que se muestra de manera pública:

    \begin{enumerate}
      \item Un formulario para poner comentarios sobre este aparcamiento. Los comentarios serán anónimos, pero sólo se podrán poner por los usuarios registrados, una vez se han autenticado. Por tanto, bastará con que este formulario esté compuesto por una caja de texto, donde se podrá escribir el comentario, y un botón para enviarlo.
  \end{enumerate}

  \item /{usuario}: Además de la información que se muestra de manera pública:
  
  \begin{enumerate}
    \item Un formulario para cambiar el estilo CSS de todo el sitio para ese usuario. Bastará con que se pueda cambiar el tamaño de la letra y el color de fondo. Si se cambian estos valores, quedará cambiado el documento CSS que utilizarán todas las páginas del sitio para este usuario. Este cambio será visible en cuanto se suba la nueva página CSS.

    \item Un formulario para elegir el título de su página personal.
  \end{enumerate}
\end{itemize}

%Si es preciso, se añadirán más recursos (pero sólo si es realmente preciso) para poder satisfacer los requisitos especificados.

Dados los recursos mencionados anteriormente, no se permitirán los nombres de usuario ``aparcamientos'' ni ``about'' (pero no hay que hacer ninguna comprobación para esto: se asume que no se darán de alta esos usuarios en el Admin Site).


%%----------------------------------------------------------------------------
\subsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

En el formulario de entrega se pide que se justifique por qué se considera funcionalidad optativa lo que habeis implementado. Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
  \item Inclusión de un \emph{favicon} del sitio
  
  \item Generación de un canal XML para los contenidos que se muestran en la página principal.

  \item Generación de canales, pero con los contenidos en JSON

  \item Generación de un canal RSS para los comentarios puestos en el sitio.
  
  \item Funcionalidad de registro de usuarios
  
  \item Uso de Javascript o AJAX para algún aspecto de la práctica (por ejemplo, para seleccionar un aparcamiento para una página de usuario).

  \item Puntuación de aparcamientos. Cada visitante (registrado o no) puede dar un ``+1'' a cualquier aparcamiento del sitio. La suma de ``+'' que ha obtenido un aparcamiento se verá cada vez que se vea el aparcamiento en el sitio.
  
  \item Uso de elementos HTML5 (especificar cuáles al entregar)

  \item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Entrega de la práctica}

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} miércoles, 24 de mayo de 2017 a las 03:00 (hora española peninsular)\footnote{Entiéndase la hora como miércoles por la noche, ya entrado el jueves.}
       %{\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

  \item \textbf{Fecha de publicación de notas:} sábado, 27 de mayo de 2017, en la plataforma Moodle.
%{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

  \item \textbf{Fecha de revisión:} lunes, 29 de mayo de 2017 a las 13:00.
%{\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
\end{itemize}

La entrega de la práctica consiste en rellenar un formulario (enlazado en el Moodle de la asignatura) y en seguir las instrucciones que se describen a continuación.

\begin{enumerate}
  \item El repositorio contendrá todos los ficheros necesarios para que funcione la aplicación (ver detalle más abajo). Es muy importante que el alumno haya realizado un fork del repositorio que se indica a continuación, porque si no, la práctica no podrá ser identificada: 

\url{https://github.com/CursosWeb/X-Serv-Practica-Aparcamientos/}

Los alumnos que no entreguen las práctica de esta forma serán considerados como no presentados en lo que a la entrega de prácticas se refiere. Los que la entreguen podrán ser llamados a realizar también una entrega presencial, que tendrá lugar en la fecha y hora de la revisión. Esta entrega presencial podrá incluir una conversación con el profesor sobre cualquier aspecto de la realización de la práctica.

Recordad que es importante ir haciendo commits de vez en cuando y que sólo al hacer push estos commits son públicos. Antes de entregar la práctica, haced un push. Y cuando la entreguéis y sepáis el nombre del repositorio, podéis cambiar el nombre del repositorio desde el interfaz web de GitHub. 
 
 \item Un vídeo de demostración de la parte obligatoria, y otro vídeo de demostración de la parte opcional, si se han realizado opciones avanzadas. Los vídeos serán de una duración máxima de 3 minutos (cada uno), y consistirán en una captura de pantalla de un navegador web utilizando la aplicación, y mostrando lo mejor posible la funcionalidad correspondiente (básica u opcional). Siempre que sea posible, el alumno comentará en el audio del vídeo lo que vaya ocurriendo en la captura. Los vídeos se colocarán en algún servicio de subida de vídeos en Internet (por ejemplo, Vimeo o YouTube).

Hay muchas herramientas que permiten realizar la captura de pantalla. Por ejemplo, en GNU/Linux puede usarse Gtk-RecordMyDesktop o Istanbul (ambas disponibles en Ubuntu). Es importante que la captura sea realizada de forma que se distinga razonablemente lo que se grabe en el vídeo.

En caso de que convenga editar el vídeo resultante (por ejemplo, para eliminar tiempos de espera) puede usarse un editor de vídeo, pero siempre deberá ser indicado que se ha hecho tal cosa con un comentario en el audio, o un texto en el vídeo. Hay muchas herramientas que permiten realizar esta edición. Por ejemplo, en GNU/Linux puede usarse OpenShot o PiTiVi.

  \item Se han de entregar los siguientes ficheros:

\begin{itemize}
  \item Un fichero README.md que resuma las mejoras, si las hay, y explique cualquier peculiaridad de la entrega (ver siguiente punto).
  \item El repositorio GitHub deberá contener un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos dos usuarios con sus datos correspondientes, con al menos cinco aparcamientos en su página personal, y con al menos cinco comentarios en total.
  \item Cualquier biblioteca Python que pueda hacer falta para que la aplicación funcione, junto con los ficheros auxiliares que utilice, si es que los utiliza.
\end{itemize}

  \item Se incluirán en el fichero README.md los siguientes datos (la mayoría de estos datos se piden también en el formulario que se ha de rellenar para entregar la práctica - se recomienda hacer un corta y pega de estos datos en el formulario):

\begin{itemize}
  \item Nombre y titulación.
  \item Nombre de su cuenta en el laboratorio del alumno.
  \item Nombre de usuario en GitHub.
  \item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
  \item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
  \item URL del vídeo demostración de la funcionalidad básica
  \item URL del vídeo demostración de la funcionalidad optativa, si se ha realizado funcionalidad optativa
\end{itemize}

Asegúrate de que las URLs incluidas en este fichero están adecuadamente escritas en Markdown, de forma que la versión HTML que genera GitHub los incluya como enlaces ``pinchables''.

\end{enumerate}


%%----------------------------------------------------------------------------
\subsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura con la versión de Django que se ha usado en prácticas.

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el navegador Firefox (considerándolos como canales RSS) disponibles en el laboratorio. Los documentos XML deberán ser correctos desde el punto de vista de la sintaxis XML, y por lo tanto reconocibles por un reconocedor XML, como por ejemplo el reconocedor del módulo xml.sax de Python.


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2017, junio)}
\label{practica-final-2017-06}

El proyecto final para la convocatoria de junio de 2017 será la misma que la descrita para la convocatoria de mayo de 2017, con las siguientes consideraciones:

\begin{itemize}
  \item La puntuación de aparcamientos será requisito de la práctica básica.
  \item El formulario para poner comentarios deja de ser un requisito de la práctica básica.
\end{itemize}

Las fechas de entrega, publicación y revisión de esta convocatoria quedan como siguen:

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} jueves, 29 de junio de 2017 a las 03:00 (hora española peninsular)\footnote{Entiéndase la hora como jueves por la noche, ya entrado el viernes.}.
       %{\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

  \item \textbf{Fecha de publicación de notas:} sábado, 1 de julio de 2017, en la plataforma Moodle.
%{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

  \item \textbf{Fecha de revisión:} lunes, 4 de julio de 2017 a las 13:00.
%{\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
\end{itemize}


\newpage

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2016, mayo)}
\label{practica-final-2016-05}

El proyecto final de la asignatura consiste en la creación de una aplicación web que aglutine información sobre alojamientos en la ciudad de Madrid. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

La aplicación se encargará de descargar información sobre los mencionados alojamientos, disponibles públicamente en formato XML en el portal de datos abiertos de Madrid, y de ofrecerlos a los usuarios para que puedan seleccionar los que les parezca más interesantes, y comentar sobre ellos. De esta manera, un escenario típico es el de un usuario que a partir de los alojamientos disponibles, elija los que le parezca más adecuados, y comente sobre los que quiera.

%%----------------------------------------------------------------------------
\subsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}

  \item La práctica se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

  \item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas en modelos de Django.

  \item Se usará la aplicación Django ``Admin Site'' para crear cuenta a los usuarios en el sistema, y para la gestión general de las bases de datos necesarias. Todas las bases de datos que contenga la aplicación tendrá que ser accesible vía este ``Admin Site''.

  \item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que la práctica tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un \emph{banner} (imagen) del sitio, en la parte superior izquierda.
  \item Una caja para entrar (hacer login en el sitio), o para salir (si ya se ha entrado).
  \begin{itemize}
    \item En caso de que no se haya entrado en una cuenta, esta caja permitirá al visitante introducir su identificador de usuario y su contraseña. 
    \item En caso de que ya se haya entrado, esta caja mostrará el identificador del usuario y permitirá salir de la cuenta (logout). Esta caja aparecerá en la parte superior derecha.
  \end{itemize}
  \item Un menú de opciones, como barra, debajo de los dos elementos anteriores (banner y caja de entrada o salida).
  \item Un pie de página con una nota de atribución, indicando ``Esta aplicación utiliza datos del portal de datos abiertos de la ciudad de Madrid'', y un enlace al XML con los datos, y a la descripción de los mismos (ver enlaces más abajo).
  \end{itemize}

Cada una de estas partes estará marcada con propiedades ``id'' en HTML, para poder ser referenciadas en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la práctica. Estas hojas definirán al menos el color y el tamaño de la letra, y el color de fondo de cada una de las partes (elementos) marcadas con id que se indican en el apartado anterior.

\item Se utilizará, para componer la información sobre alojamientos disponibles, la disponible en el portal de datos abiertos de la ciudad de Madrid:

  \begin{itemize}
  \item Descripción: \\
    \url{http://bit.ly/1T24Zsq}
  \item Fichero XML con los datos (en español): \\
    \url{http://www.esmadrid.com/opendata/alojamientos_v1_es.xml} \\
    \url{http://cursosweb.github.io/etc/alojamientos_es.xml}
  \item Fichero XML con los datos (en inglés): \\
    \url{http://www.esmadrid.com/opendata/alojamientos_v1_en.xml} \\
    \url{http://cursosweb.github.io/etc/alojamientos_en.xml}
  \item Fichero XML con los datos (en francés): \\
    \url{http://www.esmadrid.com/opendata/alojamientos_v1_fr.xml} \\
    \url{http://cursosweb.github.io/etc/alojamientos_fr.xml}
  \item Hay ficheros XML con los datos en otros idiomas
  \end{itemize}
\end{itemize}

Funcionamiento general:

\begin{itemize}
  \item Los usuarios serán dados de alta en la práctica mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

  \item El listado de alojamientos se cargará a partir del XML con los datos en español sólo cuando un usuario indique que quiere que se carguen. Hasta que algún usuario indique por primera vez que se carguen los datos, no habrá listado de alojamientos en la base de datos te la aplicación.

  \item Los usuarios registrados podrán crear su selección de alojamientos. Para ello, dispondrán de una página personal. Llamaremos a esta página la ``página del usuario''.

  \item La selección de alojamientos en su página personal la realizará cada usuario a partir de información sobre alojamientos ya disponibles en el sitio.

  \item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá la página personal de cada usuario, para todos los usuarios del sitio.

  \item Cualquier usuario, al ver la página de alojamientos de cualquier usuario (incluido él mismo), podrá pedir verla en otro de los idiomas disponibles. En ese caso, la aplicación descargará el documento XML con el listado de alojamientos en el idioma elegido, buscará los alojamientos en cuestión, y usará sus datos para mostrar la misma página, pero con los datos sobre los alojamientos en ese idioma. La aplicación no almacenará estos datos en otro idioma en la base de datos, de forma que si se le vuelve a pedir lo mismo, volverá a descargar el fichero XML. 
\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Funcionalidad mínima}

Los alojamientos se obtendrán a partir de la información pública ofrecida por el Ayuntamiento de Madrid en el Portal de Datos Abiertos, en forma de ficheros XML, como se indicaba anteriormente.

La {\bf interfaz pública} contiene los recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no):

\begin{itemize}
  \item /: Página principal de la práctica. Constará de un listado de alojamientos y otro con enlaces a páginas personales:
  
  \begin{enumerate}
    \item Mostrará un listado de los diez alojamientos con más comentarios. Si no hubiera 10 alojamientos con comentarios, se mostrarán sólo los que tengan comentarios. Para cada alojamiento, incluirá información sobre:
    \begin{itemize}
      \item su nombre (que será un enlace que apuntará a la url del alojamiento en el portal esmadrid), 
      \item su dirección, 
      \item una imagen suya en pequeño formato, 
      \item y un enlace, ``Más información'', que apuntará a la página del alojamiento en la aplicación (ver más adelante).
    \end{itemize}
   
    \item También se mostrará un listado, en una columna lateral derecha, con enlaces a las páginas personales disponibles. Para cada página personal mostrará el título que le haya dado su usuario (como un enlace a la página personal en cuestión) y el nombre del usuario. Si a una página personal aún no se le hubiera puesto título, este título será ``Página de usuario'', donde ``usuario'' es el identificador de usuario del usuario en cuestión.
   \end{enumerate}

  \item /{usuario}: Página personal de un usuario. Si la URL es ``/usuario'', es que corresponde al usuario ``usuario''. Mostrará los alojamientos seleccionados por ese usuario (aunque no puede haber más de 10 a la vez; si hay más debería haber un enlace para mostrar las diez siguientes y así en adelante, siempre de diez en diez). Para cada alojamiento se mostrará la misma información que en la página principal. Además, para cada alojamiento se deberá mostrar la fecha en la que fue seleccionada por el usuario.

  \item /alojamientos: Página con todos los alojamientos. Para cada uno de ellos aparecerá sólo el nombre, y un enlace a su página. En la parte superior de la página, existirá un formulario que permita filtrar estos alojamientos según varios campos, como, por ejemplo, por su categoría (por ejemplo, ``Hoteles'') y su subcategoría  (por ejemplo, ``4 estrellas'') .

  \item /alojamientos/{id}: Página de un alojamiento en la aplicación. Mostrará toda la información de los elementos ``basicData'' y ``geoData'' obtenida del XML del portal de datos abierto del Ayuntamiento de Madrid. Además, se mostrarán cinco fotos entre las que se pueden obtener del mismo documento XML (o menos, si en el documento no hay tantas), y todos los comentarios que se hayan puesto para este alojamiento.
  
  \item /{usuario}/xml: Canal XML para los alojamientos seleccionados por ese usuario. El documento XML tendrá una entrada para cada alojamiento seleccionado por el usuario, y tendrá una estructura similar (pero no necesariamente igual) a la del fichero XML del portal del Ayuntamiento.

  \item /about: Página con información en HTML indicando la autoría de la práctica y explicando su funcionamiento.

\end{itemize}

Todas las páginas de la interfaz pública incluirán un menú desde el que se podrá acceder a todos los alojamientos (URL /alojamientos) con el texto ``Todos'' y a la ayuda (URL /about) con el texto ``About''. Todas las página que no sean la principal tendrán otra opción de menú para la URL /, con el texto ``Inicio''.

La {\bf interfaz privada} contiene los recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado):

\begin{itemize}
  \item Todos los recursos de la interfaz pública.
  
  \item /alojamientos/{id}: Además de la información que se muestra de manera pública:

    \begin{enumerate}
      \item Un formulario para poner comentarios sobre este alojamiento. Los comentarios serán anónimos, pero sólo se podrán poner por los usuarios registrados, una vez se han autenticado. Por tanto, bastará con que este formulario esté compuesto por una caja de texto, donde se podrá escribir el comentario, y un botón para enviarlo.
    \item Un botón para cada uno de los idiomas en que está disponible el documento XML en el portal del Ayuntamiento. En caso de que el usuario pulse uno de esos botones, la aplicación descargará el XML correspondiente al idioma seleccionado, buscará en él la información sobre el alojamiento en cuestión, y si está disponible, la mostrará en pantalla en ese idioma (además de la información que ya estaba disponible). Si el alojamiento no está disponible en ese idioma, se pondrá un mensaje indicándolo. Esta información en otros idiomas no se guardará en la base de datos.
  \end{enumerate}

  \item /{usuario}: Además de la información que se muestra de manera pública:
  
  \begin{enumerate}
    \item Un formulario para cambiar el estilo CSS de todo el sitio para ese usuario. Bastará con que se pueda cambiar el tamaño de la letra y el color de fondo. Si se cambian estos valores, quedará cambiado el documento CSS que utilizarán todas las páginas del sitio para este usuario. Este cambio será visible en cuanto se suba la nueva página CSS.

    \item Un formulario para elegir el título de su página personal.
  \end{enumerate}
\end{itemize}

%Si es preciso, se añadirán más recursos (pero sólo si es realmente preciso) para poder satisfacer los requisitos especificados.

Dados los recursos mencionados anteriormente, no se permitirán los nombres de usuario ``alojamientos'' ni ``about'' (pero no hay que hacer ninguna comprobación para esto: se asume que no se darán de alta esos usuarios en el Admin Site).


%%----------------------------------------------------------------------------
\subsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

En el formulario de entrega se pide que se justifique por qué se considera funcionalidad optativa lo que habeis implementado. Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
  \item Inclusión de un \emph{favicon} del sitio
  
  \item Generación de un canal XML para los contenidos que se muestran en la página principal.

  \item Generación de canales, pero con los contenidos en JSON

  \item Generación de un canal RSS para los comentarios puestos en el sitio.
  
  \item Funcionalidad de registro de usuarios
  
  \item Uso de Javascript o AJAX para algún aspecto de la práctica (por ejemplo, para seleccionar un alojamiento para una página de usuario).

  \item Puntuación de alojamientos. Cada visitante (registrado o no) puede dar un ``+1'' a cualquier alojamiento del sitio. La suma de ``+'' que ha obtenido un alojamiento se verá cada vez que se vea el alojamiento en el sitio.
  
  \item Uso de elementos HTML5 (especificar cuáles al entregar)

  \item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Entrega de la práctica}

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} lunes, 23 de mayo de 2016 a las 02:00 (hora española peninsular)\footnote{Entiéndase la hora como domingo por la noche, ya entrado el lunes.}
       %{\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

  \item \textbf{Fecha de publicación de notas:} martes, 24 de mayo de 2016, en la plataforma Moodle.
%{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

  \item \textbf{Fecha de revisión:} miércoles, 25 de mayo de 2016 a las 13:30.
%{\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
\end{itemize}

La entrega de la práctica consiste en rellenar un formulario (enlazado en el Moodle de la asignatura) y en seguir las instrucciones que se describen a continuación.

\begin{enumerate}
  \item El repositorio contendrá todos los ficheros necesarios para que funcione la aplicación (ver detalle más abajo). Es muy importante que el alumno haya realizado un fork del repositorio que se indica a continuación, porque si no, la práctica no podrá ser identificada: 

\url{https://github.com/CursosWeb/X-Serv-Practica-Hoteles/}

Los alumnos que no entreguen las práctica de esta forma serán considerados como no presentados en lo que a la entrega de prácticas se refiere. Los que la entreguen podrán ser llamados a realizar también una entrega presencial, que tendrá lugar en la fecha y hora de la revisión. Esta entrega presencial podrá incluir una conversación con el profesor sobre cualquier aspecto de la realización de la práctica.

Recordad que es importante ir haciendo commits de vez en cuando y que sólo al hacer push estos commits son públicos. Antes de entregar la práctica, haced un push. Y cuando la entreguéis y sepáis el nombre del repositorio, podéis cambiar el nombre del repositorio desde el interfaz web de GitHub. 
 
 \item Un vídeo de demostración de la parte obligatoria, y otro vídeo de demostración de la parte opcional, si se han realizado opciones avanzadas. Los vídeos serán de una duración máxima de 3 minutos (cada uno), y consistirán en una captura de pantalla de un navegador web utilizando la aplicación, y mostrando lo mejor posible la funcionalidad correspondiente (básica u opcional). Siempre que sea posible, el alumno comentará en el audio del vídeo lo que vaya ocurriendo en la captura. Los vídeos se colocarán en algún servicio de subida de vídeos en Internet (por ejemplo, Vimeo o YouTube).

Hay muchas herramientas que permiten realizar la captura de pantalla. Por ejemplo, en GNU/Linux puede usarse Gtk-RecordMyDesktop o Istanbul (ambas disponibles en Ubuntu). Es importante que la captura sea realizada de forma que se distinga razonablemente lo que se grabe en el vídeo.

En caso de que convenga editar el vídeo resultante (por ejemplo, para eliminar tiempos de espera) puede usarse un editor de vídeo, pero siempre deberá ser indicado que se ha hecho tal cosa con un comentario en el audio, o un texto en el vídeo. Hay muchas herramientas que permiten realizar esta edición. Por ejemplo, en GNU/Linux puede usarse OpenShot o PiTiVi.

  \item Se han de entregar los siguientes ficheros:

\begin{itemize}
  \item Un fichero README.md que resuma las mejoras, si las hay, y explique cualquier peculiaridad de la entrega (ver siguiente punto).
  \item El repositorio GitHub deberá contener un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos dos usuarios con sus datos correspondientes, con al menos cinco alojamientos en su página personal, y con al menos cinco comentarios en total.
  \item Cualquier biblioteca Python que pueda hacer falta para que la aplicación funcione, junto con los ficheros auxiliares que utilice, si es que los utiliza.
\end{itemize}

  \item Se incluirán en el fichero README.md los siguientes datos (la mayoría de estos datos se piden también en el formulario que se ha de rellenar para entregar la práctica - se recomienda hacer un corta y pega de estos datos en el formulario):

\begin{itemize}
  \item Nombre y titulación.
  \item Nombre de su cuenta en el laboratorio del alumno.
  \item Nombre de usuario en GitHub.
  \item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
  \item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
  \item URL del vídeo demostración de la funcionalidad básica
  \item URL del vídeo demostración de la funcionalidad optativa, si se ha realizado funcionalidad optativa
\end{itemize}

Asegúrate de que las URLs incluidas en este fichero están adecuadamente escritas en Markdown, de forma que la versión HTML que genera GitHub los incluya como enlaces ``pinchables''.

\end{enumerate}


%%----------------------------------------------------------------------------
\subsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura con la versión de Django que se ha usado en prácticas.

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el navegador Firefox (considerándolos como canales RSS) disponibles en el laboratorio. Los documentos XML deberán ser correctos desde el punto de vista de la sintaxis XML, y por lo tanto reconocibles por un reconocedor XML, como por ejemplo el reconocedor del módulo xml.sax de Python.


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2016, junio)}
\label{practica-final-2016-06}

El proyecto final para la convocatoria de junio de 2016 será la misma que la descrita para la convocatoria de mayo de 2016, salvo la siguiente cuestión:
 
Los comentarios incluirán información sobre quién los ha introducido, y cada hotel sólo podrá tener un comentario por cada usuario.

Además, las fechas de entrega, publicación y revisión quedan como siguen:

\begin{itemize}
  \item \textbf{Fecha límite de entrega de la práctica:} lunes, 27 de junio de 2016 a las 02:00 (hora española peninsular)\footnote{Entiéndase la hora como domingo por la noche, ya entrado el lunes.}. Se ha de entregar el código en GitHub y rellenar el formulario de entrega (incluyendo los enlaces a los vídeos de presentación).
       %{\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

  \item \textbf{Fecha de publicación de notas:} martes, 28 de junio de 2016, en la plataforma Moodle.
%{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

  \item \textbf{Fecha de revisión:} jueves, 30 de junio de 2016 a las 13:00.
%{\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.
\end{itemize}



\newpage

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2015, mayo y junio)}
\label{practica-final-2015-05}

El proyecto final de la asignatura consiste en la creación de una aplicación web que aglutine información sobre actividades culturales y de ocio que tienen lugar en el municipio de Madrid. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

La aplicación consiste en descargarse datos de actividades culturales (disponbiles públicamente en formato XML) y ofrecer estos datos a los usuarios de la aplicación para que puedan gestionar la información de la manera con consideren más conveniente. De esta manera, un escenario típico es el de un usuario que a partir de las actividades existentes, incluya en su perfil las que le interesen.

%%----------------------------------------------------------------------------
\subsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}

\item La práctica se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item Se usará la aplicación Django ``Admin Site'' para crear cuenta a los usuarios en el sistema, y para la gestión general de las bases de datos necesarias. Todas las bases de datos que mantenga DeLorean tendrá que ser accesible vía este ``Admin Site''.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que la práctica tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones.
  \item Una caja para entrar (hacer login en el sitio), o para salir (si ya se ha entrado). En caso de que no se haya entrado en una cuenta, esta caja permitirá al visitante introducir su identificador de usuario y su contraseña. En caso de que ya se haya entrado, esta caja mostrará el identificador del usuario y permitirá salir de la cuenta (logout).
  \item Un pie de página con una nota de copyright.
  \end{itemize}

Cada una de estas partes estará marcada con propiedades ``id'' en HTML, para poder ser referenciadas en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la práctica. Estas hojas definirán al menos el color y el tamaño de la letra, y el color de fondo de cada una de las partes (elementos) marcadas con id que se indican en el apartado anterior.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item Los usuarios serán dados de alta en la práctica mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

\item Los usuarios registrados podrán crear su selección de actividades de cultura y de ocio. Para ello, dispondrán de una página personal. Llamaremos a esta página la ``página del usuario''.

\item La selección de actividades en su página personal la realizará cada usuario a partir de información sobre actividades de ocio y cultura ya disponibles en el sitio.

\item Las actividades de ocio y cultura se actualizarán sólo cuando un usuario indique que quiere que se actualicen.

\item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá la página personal de cada usuario, para todos los usuarios del sitio.

\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Funcionalidad mínima}

Las actividades de ocio y de cultura se toman de interpretar la información pública ofrecida por el Ayuntamiento de Madrid en el Portal de Datos Abiertos, y que es la siguiente:
    \begin{itemize}
      \item Actividades Culturales y de Ocio Municipal en los próximos 100 días: \\
        \url{http://goo.gl/809BPF}
    \end{itemize}

Interfaz pública: recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no):

\begin{itemize}
\item /: Página principal de la práctica. Mostrará un listado de las diez actividades de ocio y cultura más próximas en el tiempo, que incluya información sobre su título, el tipo de evento y la fecha del mismo. También se mostrará un listado, probablemente en un lateral, con las páginas personales disponibles. Para cada página personal mostrará el título (como un enlace a la página personal), el nombre de su usuario y una pequeña descripción. Si a una página personal aún no se le hubiera puesto título, este título será ``Página de usuario'', donde ``usuario'' es el identificador de usuario del usuario en cuestión.

\item /usuario: Página personal de un usuario. Si la URL es ``/usuario'', es que corresponde al usuario ``usuario''. Mostrará las actividades de ocio y de cultura seleccionadas por ese usuario (aunque no puede haber más de 10 a la vez; si hay más debería haber un enlace para mostrar las diez siguientes y así en adelante, siempre de diez en diez). Para cada actividad de ocio y de cultura se mostrará al menos el título y la fecha de los eventos (con un enlace a la página /actividad de cada evento, ver más adelante). Además, para cada actividad se deberá mostrar la fecha en la que fue seleccionada por el usuario.

\item /actividad/{id}: Página de una actividad de cultura o de ocio. Mostrará toda la información obtenida del XML del portal de datos abierto del Ayuntamiento de Madrid. Además, se mostrará su ``información adicional'', conseguida a partir de seguir la URL con información adicional. Esta información adicional es la que se puede encontrar si seguimos el enlace justo debajo de ``Amplíe información''. Se puede hacer uso del módulo \emph{Beautiful Soup} para llevar a cabo esta funcionalidad.

\item /usuario/rss: Canal RSS para las actividades seleccionadas por ese usuario.

\item /ayuda: Página con información HTML explicando el funcionamiento de la práctica.

\item /todas: Página con todas las actividades de ocio y de cultura. En la parte superior de la página, existirá un formulario que permite filtrar estas actividades según varios campos, como, por ejemplo, la fecha, la duración, el precio o el título.
\end{itemize}

Todas las páginas de la interfaz pública incluirán un menú desde el que se podrá acceder a todas las actividades (URL /todas) con el texto ``Todas'' y a la ayuda (URL /ayuda) con el texto ``Ayuda''. Todas las página que no sean la principal tendrán otra opción de menú para la URL /, con el texto ``Inicio''.


Interfaz privada: recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado).

\begin{itemize}
  \item Todos los recursos de la interfaz pública.
  \item /todas: Además de la información que se muestra de manera pública:
  \begin{itemize}
    \item Se mostrará el número de actividades de ocio y de cultura disponibles para el canal, y la fecha en que fue actualizado por última vez.
    \item Existirá un botón para actualizar las actividades a partir del canal de actividades. Si se pulsa este botón, se tratarán de actualizar las actividades accediendo al canal de actividades del Ayuntamiento de Madrid. Al terminar la operación se volverá a mostrar esta misma página /todas, actualizada.
    \item La lista de actividades disponibles en el canal de actividades.
    \item Junto a cada actividad de la lista, se incluirá un botón que permitirá elegir la actividad para la página personal del usuario autenticado. Tras añadir una actividad a la página del usuario, se volverá a ver en el navegador la página /todas.
  \end{itemize}

  \item En la página /usuario que corresponde al usuario autenticado se mostrará, además de lo ya mencionado para la interfaz pública, un formulario en el que se podrá especificar la siguiente información:

  \begin{itemize}
    \item Los parámetros CSS para el usuario autenticado (al menos los indicados anteriormente para ser manejados por un documento CSS). Si el usuario los cambia, a partir de ese momento deberá verse el sitio con los nuevos valores, y para ello deberá servirse un nuevo documento CSS.
    \item El título de su página personal.
  \end{itemize}
\end{itemize}

%Si es preciso, se añadirán más recursos (pero sólo si es realmente preciso) para poder satisfacer los requisitos especificados.

Dados los recursos mencionados anteriormente, no se permitirán los nombres de usuario ``actividad'', ``ayuda'' ni ``todas'' (pero no hay que hacer ninguna comprobación para esto: se asume que no se darán de alta esos usuarios en el Admin Site).



%%----------------------------------------------------------------------------
\subsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
\item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

\item Generación de un canal RSS para los contenidos que se muestran en la página principal.

\item Uso de AJAX para algún aspecto de la práctica (por ejemplo, para seleccionar una actividad para una página de usuario).

\item Puntuación de actividades. Cada visitante (registrado o no) puede dar un ``+1'' a cualquier actividad del sitio. La suma de ``+'' que ha obtenido una actividad se verá cada vez que se vea la actividad en el sitio.

\item Comentarios a actividades. Cada usuario registrado puede comentar cualquier actividad del sitio. Estos comentarios se podrán ver luego en la página personal.

\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Entrega de la práctica}

\textbf{Fecha límite de entrega de la práctica:} domingo, 24 de mayo de 2015 a las 23:59 (hora española peninsular). {\bf Convocatoria de junio:} miércoles, 24 de junio de 2015 a las 23:59 (hora peninsular española).

\textbf{Fecha de publicación de notas:} martes, 26 de mayo de 2015, en la plataforma Moodle.
{\bf Convocatoria de junio:} viernes, 26 de junio, en la plataforma Moodle.

\textbf{Fecha de revisión:} viernes, 29 de mayo de 2014 a las 12:00. {\bf Convocatoria de junio:} martes, 30 de junio a las 13:30. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.

La práctica se entregará realizando {\bf dos} acciones:

\begin{enumerate}
  \item Rellenando un formulario web, que pedirá la siguiente información:
  \begin{itemize}
    \item Nombre de la asignatura.
    \item Nombre completo del alumno.
    \item Nombre de su cuenta en el laboratorio.
    \item Nombres y contraseñas de los usuarios creados para la práctica. Éstos deberán incluir al menos un usuario con cuenta ``marty'' y contraseña ``marty'' y otro usuario con cuenta ``doc'' y contraseña ``doc''.
    \item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
    \item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
    \item URL del vídeo demostración en YouTube que muestre la funcionalidad básica
    \item URL del vídeo demostración en YouTube con la funcionalidad optativa, si se ha realizado funcionalidad optativa
  \end{itemize}

  \item Subiendo la práctica a un repositorio GitHub. El nombre del repositorio se dará al entregar la práctica. Así, para ir realizando la práctica se recomienda crearse un repositorio en GitHub con el nombre que queráis, e ir haciendo commits. Recordad que es importante ir haciendo commits de vez en cuando y que sólo al hacer push estos commits son públicos. Antes de entregar la práctica, haced un push. Y cuando la entreguéis y sepáis el nombre del repositorio, podeis cambiar el nombre del repositorio desde el interfaz web de GitHub. 
  
    El repositorio GitHub deberá contener un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos dos usuarios con sus datos correspondientes, y con al menos cinco actividades en su página personal.
\end{enumerate}

Los vídeos de demostración serán de una duración máxima de tres minutos (cada uno), y consistirán en una captura de pantalla de un navegador web utilizando la aplicación, y mostrando lo mejor posible la funcionalidad correspondiente (básica u opcional). Se valorará negativamente que los vídeos duren más de 3 minutos (de la experiencia de cursos pasados, tres minutos es un tiempo más que suficiente si uno no entra en detalles que no son importantes). Siempre que sea posible, el alumno comentará en el audio del vídeo lo que vaya ocurriendo en la captura. Los vídeos se colocarán en YouTube y deberán ser accesibles públicamente al menos hasta el 31 de mayo, fecha a partir de la cual los alumnos pueden retirar el vídeo (o indicarlo como privado).

Hay muchas herramientas que permiten realizar la captura de pantalla. Por ejemplo, en GNU/Linux puede usarse Gtk-RecordMyDesktop o Istanbul (ambas disponibles en Ubuntu). Incluso hay alguna aplicación web como Screen-O-Matic. Es importante que la captura sea realizada de forma que se distinga razonablemente lo que se grabe en el vídeo.

En caso de que convenga editar el vídeo resultante (por ejemplo, para eliminar tiempos de espera) puede usarse un editor de vídeo, pero siempre deberá ser indicado que se ha hecho tal cosa con un comentario en el audio, o un texto en el vídeo. Hay muchas herramientas que permiten realizar esta edición. Por ejemplo, en GNU/Linux puede usarse OpenShot o PiTiVi.

Los alumnos que no entreguen las práctica de esta forma serán considerados como no presentados en lo que a la entrega de prácticas se refiere.

%%----------------------------------------------------------------------------
\subsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura con la versión de Django que se ha usado en prácticas (Django 1.7.*).

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el navegador Firefox (considerándolos como canales RSS) disponibles en el laboratorio.


\newpage

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\section{Proyecto final (2014, mayo)}
\label{practica-final-2014-04}

El proyecto final de la asignatura consiste en la creación de una aplicación web que aglutine información sobre el estado de las carreteras y relacionada. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener. Llamaremos a la aplicación DeLorean, como tributo a los casi 30 años de la primera película ``Regreso al Futuro''.

La aplicación consiste en descargarse datos de tráfico (disponbiles públicamente en formato XML) y ofrecer estos datos a los usuarios de la aplicación para que puedan gestionar la información de la manera con consideren más conveniente. De esta manera, un escenario típico es el de un usuario que indique una provincia (o incluso una carretera) en la que está interesado; en su página personal aparecerán todas las incidencias de tráfico que cumplan esos requisitos, en tiempo real.

%%----------------------------------------------------------------------------
\subsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}

\item DeLorean se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item Se usará la aplicación Django ``Admin Site'' para crear cuenta a los usuarios en el sistema, y para la gestión general de las bases de datos necesarias. Todas las bases de datos que mantenga DeLorean tendrá que ser accesible vía este ``Admin Site''.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que DeLorean tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones.
  \item Una caja para entrar (hacer login en el sitio), o para salir (si ya se ha entrado). En caso de que no se haya entrado en una cuenta, esta caja permitirá al visitante introducir su identificador de usuario y su contraseña. En caso de que ya se haya entrado, esta caja mostrará el identificador del usuario y permitirá salir de la cuenta (logout).
  \item Un pie de página con una nota de copyright.
  \end{itemize}

Cada una de estas partes estará marcada con propiedades ``id'' en HTML, para poder ser referenciadas en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de DeLorean. Estas hojas definirán al menos el color y el tamaño de la letra, y el color de fondo de cada una de las partes (elementos) marcadas con id que se indican en el apartado anterior.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item Los usuarios serán dados de alta en DeLorean mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

\item Los usuarios registrados podrán crear su selección de estados de carretera de DeLorean. Para ello, dispondrán de una página personal. Llamaremos a esta página la ``página del usuario''.

\item La selección de incidencias en su página personal la realizará cada usuario a partir de información sobre incidencias ya disponibles en el sitio.

\item Las incidencias se actualizarán sólo cuando un usuario indique que quiere que se actualicen.

\item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá la página personal de cada usuario, para todos los usuarios del sitio.
\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Funcionalidad mínima}

Interfaz pública: recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no):

\begin{itemize}
\item /: Página principal de DeLorean. Mostrará un listado de las últimas diez incidencias y posteriormente otro listado con las páginas personales disponibles. Para cada página personal mostrará el título (como un enlace a la página personal), el nombre de su usuario y una pequeña descripción. Si a una página personal aún no se le hubiera puesto título, este título será ``Página de usuario'', donde ``usuario'' es el identificador de usuario del usuario en cuestión.

\item /usuario: Página personal de un usuario. Si la URL es ``/usuario'', es que corresponde al usuario ``usuario''. Mostrará las incidencias seleccionadas por ese usuario (aunuque no puede haber más de 10 a la vez, como se indicará más adelante). Para cada incidencia se mostrará la ``información pública de cada incidencia'', ver más adelante.

\item /usuario/rss: Canal RSS para las incidencias seleccionadas por ese usuario.

\item /ayuda: Página con información HTML explicando el funcionamiento de DeLorean.

\item /todas: Página con todas las incidencias. En la parte superior de la página, existirá un formulario que permite filtrar las incidencias según varios campos, como, por ejemplo, provincia, tipo, longitud.
\end{itemize}

Todas las páginas de la interfaz pública incluirán un menú desde el que se podrá acceder a todas las incidiencias (URL /todas) con el texto ``Todas'' y a la ayuda (URL /ayuda) con el texto ``Ayuda''. Todas las página que no sean la principal tendrán otra opción de menú para la URL /, con el texto ``Inicio''.

Interfaz privada: recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado).

\begin{itemize}
\item Todos los recursos de la interfaz pública.
\item /incidencias: Página con la lista de incidencias disponibles en DeLorean:

  \begin{itemize}
  \item Las incidencias se toman de interpretar la información pública ofrecida por la Dirección General de Tráfico (DGT), y que es la siguiente:
    \begin{itemize}
      \item Información de incidencias en carreteras (canal de incidencias): \\
        \url{http://www.dgt.es/incidencias.xml}
    \end{itemize}

  \item Se mostrará el número de incidencias disponibles para el canal, y la fecha en que fue actualizado por última vez.
  \item Existirá un botón para actualizar las incidencias a partir del canal de incidencias. Si se pulsa este botón, se tratarán de actualizar las incidencias accediendo al canal de incidencias de la DGT. Al terminar la operación se volverá a mostrar esta misma página, actualizada.
  \item La lista de incidencias disponibles en el canal de incidencias, incluyendo para cada una la ``información pública', ver más adelante.
  \item Junto a cada incidencia de la lista, se incluirá un botón que permitirá elegir la incidencia para la página personal del usuario autenticado. Tras añadir una incidencia a la página del usuario, se volverá a ver en el navegador la página /incidencias.
  \end{itemize}

\item En la página /usuario que corresponde al usuario autenticado se mostrará, además de lo ya mencionado para la interfaz pública, un formulario en el que se podrá especificar la siguiente información:

  \begin{itemize}
  \item Los parámetros CSS para el usuario autenticado (al menos los indicados anteriormente para ser manejados por un documento CSS). Si el usuario los cambia, a partir de ese momento deberá verse el sitio con los nuevos valores, y para ello deberá servirse un nuevo documento CSS.
  \item El título de su página personal.
  \end{itemize}
\end{itemize}

Si es preciso, se añadirán más recursos (pero sólo si es realmente preciso) para poder satisfacer los requisitos especificados.

Dados los recursos mencionados anteriormente, no se permitirán los nombres de usuario ``incidencias'', ``ayuda'' ni ``todas'' (pero no hay que hacer ninguna comprobación para esto: se asume que no se darán de alta esos usuarios en el Admin Site).


Como información pública de cada incidencia se mostrará:
\begin{itemize}
  \item El tipo de incidencia
  \item La provincia de la incidencia y la carretera
  \item La fecha en que fue publicada la incidencia en el sitio original (junto al texto ``publicada en'').
  \item La fecha en que fue seleccionada para la página personal del usuario (junto al texto ``elegida en'').
  \item La información detallada de la incidencia (toda la demás información de la incidencia que se puede extraer del XML)
\end{itemize}



%%----------------------------------------------------------------------------
\subsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
\item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

\item Generación de un canal RSS para los contenidos que se muestran en la página principal.

\item Uso de AJAX para algún aspecto de la práctica (por ejemplo, para seleccionar una incidencia para una página de usuario).

\item Puntuación de incidencias. Cada visitante (registrado o no) puede dar un ``+1'' a cualquier incidencia del sitio. La suma de ``+'' que ha obtenido una incidencia se verá cada vez que se vea la incidencias en el sitio.

\item Comentarios a incidencias. Cada usuario registrado puede comentar cualquier incidencia del sitio. Estos comentarios se podrán ver luego en la página personal.

\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Entrega de la práctica}

\textbf{Fecha límite de entrega de la práctica:} sábado, 24 de mayo de 2014 a las 03:00 (hora española peninsular).

\textbf{Fecha de publicación de notas:} lunes, 26 de mayo de 2014, en la plataforma Moodle.

\textbf{Fecha de revisión:} miércoles, 28 de mayo de 2014 a las 12:00. Se requerirá a algunos alumnos que asistan a la revisión {\bf en persona}; se informará de ello en el mensaje de publicación de notas.

La práctica se entregará subiéndola al recurso habilitado a tal fin en el sitio Moodle de la asignatura. Los alumnos que no entreguen las práctica de esta forma serán considerados como no presentados en lo que a la entrega de prácticas se refiere. Los que la entreguen podrán ser llamados a realizar también una entrega presencial, que tendrá lugar en la fecha y hora exacta se les comunicará oportunamente. Esta entrega presencial podrá incluir una conversación con el profesor sobre cualquier aspecto de la realización de la práctica.

Para entregar la práctica en el Moodle, cada alumno subirá al recurso habilitado a tal fin un fichero tar.gz con todo el código fuente de la práctica. El fichero se habrá de llamar practica-user.tar.gz, siendo ``user'' el nombre de la cuenta del alumno en el laboratorio.

El fichero que se entregue deberá constar de un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos dos usuarios con sus datos correspondientes, y con al menos cinco incidencias en su página personal. Se incluirá también un fichero README con los siguientes datos:

\begin{itemize}
  \item Nombre de la asignatura.
  \item Nombre completo del alumno.
  \item Nombre de su cuenta en el laboratorio.
  \item Nombres y contraseñas de los usuarios creados para la práctica. Éstos deberán incluir al menos un usuario con cuenta ``marty'' y contraseña ``marty'' y otro usuario con cuenta ``doc'' y contraseña ``doc''.
\item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
\item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
\item URL del vídeo demostración en YouTube que muestre la funcionalidad básica
\item URL del vídeo demostración en YouTube con la funcionalidad optativa, si se ha realizado funcionalidad optativa
\end{itemize}

Además, parte de la información del fichero README se incluirá a su vez en un formulario web a la hora de realizar la entrega.

Los vídeos de demostración serán de una duración máxima de 3 minutos (cada uno), y consistirán en una captura de pantalla de un navegador web utilizando la aplicación, y mostrando lo mejor posible la funcionalidad correspondiente (básica u opcional). Se valorará negativamente que los vídeos duren más de 3 minutos (de la experiencia de cursos pasados, tres minutos es un tiempo más que suficiente si uno no entra en detalles que no son importantes). Siempre que sea posible, el alumno comentará en el audio del vídeo lo que vaya ocurriendo en la captura. Los vídeos se colocarán en YouTube y deberán ser accesibles públicamente al menos hasta el 31 de mayo, fecha a partir de la cual los alumnos pueden retirar el vídeo (o indicarlo como privado).

Hay muchas herramientas que permiten realizar la captura de pantalla. Por ejemplo, en GNU/Linux puede usarse Gtk-RecordMyDesktop o Istanbul (ambas disponibles en Ubuntu). Incluso hay alguna aplicación web como Screen-O-Matic. Es importante que la captura sea realizada de forma que se distinga razonablemente lo que se grabe en el vídeo.

En caso de que convenga editar el vídeo resultante (por ejemplo, para eliminar tiempos de espera) puede usarse un editor de vídeo, pero siempre deberá ser indicado que se ha hecho tal cosa con un comentario en el audio, o un texto en el vídeo. Hay muchas herramientas que permiten realizar esta edición. Por ejemplo, en GNU/Linux puede usarse OpenShot o PiTiVi.

%%----------------------------------------------------------------------------
\subsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura con la versión de Django que se ha usado en prácticas (Django 1.7.*).

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Se recomienda construir una o varias aplicaciones complementarias para probar la descarga y almacenamiento en base de datos de los canales que alimentarán las revistas.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el navegador Firefox (considerándolos como canales RSS) disponibles en el laboratorio.


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------

\section{Proyectos finales anteriores}

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2013, mayo)}
\label{practica-final-2013-05}

El proyecto final de la asignatura consiste en la creación de un selector de noticias a partir de canales, como aplicación web. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener. Llamaremos a la aplicación MiRevista.

%%----------------------------------------------------------------------------
\subsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}
\item La práctica consistirá en una aplicación web que servirá los datos a los usuarios.

\item MiRevista se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item Se usará la aplicación Django ``Admin Site'' para mantener los usuarios con cuenta en el sistema, y para la gestión general de las bases de datos necesarias. Todas las bases de datos que mantenga MiRevista tendrá que ser accesible vía este ``Admin Site''.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que MiRevista tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones.
  \item Una caja para entrar (hacer login en el sitio), o para salir (si ya se ha entrado). En caso de que no se haya entrado en una cuenta, esta caja permitirá al visitante introducir su identificador de usuario y su contraseña. En caso de que ya se haya entrado, esta caja mostrará el identificador del usuario y permitirá salir de la cuenta (logout).
  \item Un pie de página con una nota de copyright.
  \end{itemize}

Cada una de estas partes estará marcada con propiedades ``id'' en HTML, para poder ser referenciadas en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de MiRevista. Estas hojas definirán al menos el color y el tamaño de la letra, y el color de fondo de cada una de las partes (elementos) marcadas con id que se indican en el apartado anterior.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item Los usuarios serán dados de alta en MiRevista mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

\item Los usuarios registrados podrán crear su selección de noticias en MiRevista. Para ello, dispondrán de una página personal, en la que trabajarán. Llamaremos a esta página la ``revista del usuario''.

\item La selección de noticias de su revista la realizará cada usuario a partir de canales RSS de sitios web ya disponibles en el sitio.

\item Además, si hay un canal no disponible en el sitio, un usuario podrá indicar sus datos para que pase a estar disponible.

\item Los contenidos de cada canal se actualizarán sólo cuando un usuario indique que quiere que se actualicen (esta indicación se hará por separado para cada canal que se quiera actualizar).

\item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá la revista de cada usuario, para todos los usuarios del sitio.
\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Funcionalidad mínima}

Interfaz pública: recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no):

\begin{itemize}
\item /: Página principal de MiRevista. Mostrará la lista de las revistas disponibles, ordenadas por fecha de actualización, en orden inverso (las revistas actualizadas más recientemente, primero). Para cada revista se mostrará su título (como un enlace a la página de la revista), el nombre de su usuario y la fecha de su última actualización (fecha en que se añadió una noticia a esa revista por última vez). Si a una revista aún no se le hubiera puesto título, este título será ``Revista de usuario'', donde ``usuario'' es el identificador de usuario del usuario en cuestión.

\item /usuario: Página de la revista de un usuario. Si la URL es ``/usuario'', es que corresponde al usuario ``usuario''. Mostrará las 10 noticias de la revista de ese usuario (no puede haber más de 10, como se indicará más adelante). Para cada noticia se mostrará la ``información pública de noticia'', ver más adelante.

\item /usuario/rss: Canal RSS para la revista de ese usuario.

\item /ayuda: Página con información HTML explicando el funcionamiento de MiRevista.
\end{itemize}

Además, todas las páginas de la interfaz pública incluirán un menú desde el que se podrá acceder la ayuda (URL /ayuda) con el texto ``Ayuda''.

Además, todas las página que no sean la principal tendrán otra opción de menú para la URL /, con el texto ``Revistas''.

Interfaz privada: recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado).

\begin{itemize}
\item Todos los recursos de la interfaz pública.
\item /canales: Página con la lista de los canales disponibles en MiRevista:

  \begin{itemize}
  \item Para cada canal se mostrará el nombre del canal (apuntando a la página de ese canal en MiRevista, ver más adelante), el logo del canal, el número de mensajes disponibles para el canal, y la fecha en que fue actualizado por última vez.
  \item Además, en esta página se mostrará un formulario en el que se podrá introducir una URL, que se interpretará como la URL de un nuevo canal. Esta será la forma de añadir un nuevo canal para que esté disponible en el sitio. Cuando se añada un nuevo canal se tratarán de actualizar sus contenidos a partir de la URL indicada: si esta operación falla (bien porque la URL no está disponible, bien porque no se puede interpretar su contenido como un documento RSS), no se añadirá el canal como disponible. En cualquier caso, tras tratar de añadir un nuevo canal se volverá a ver la página /canales en el navegador.
  \end{itemize}

\item /canales/num: Página de un canal en MiRevista. ``num'' es el número de orden en que se hizo disponible (si fue el segundo canal que se hizo disponible en el sitio, será /canales/2). Mostrará:

  \begin{itemize}
  \item El nombre del canal (según venga como titulo en el canal RSS correspondiente) como enlace apuntando al sitio web donde se puede ver el contenido del canal (ojo: el contenido original, no el canal RSS)
  \item Junto a él pondrá entre paréntesis ``canal'', como enlace al canal RSS correspondiente en el sitio original
  \item Un botón para actualizar el canal. Si se pulsa este botón, se tratarán de actualizar las noticias de ese canal accediendo al documento RSS correspondiente en su sitio web de origen. Al terminar la operación se volverá a mostrar esta misma página /canales/num.
  \item La lista de noticias de ese canal, incluyendo para cada una la ``información pública de noticia'', ver más adelante.
  \item Junto a cada noticia de la lista, se incluirá un botón que permitirá elegir la noticia para la revista del usuario autenticado. Si al añadirla la lista de noticias de esa revista fuera de más de 10, se eliminarán las que se eligieron hace más tiempo, de forma que no queden más de 10. Tras añadir una noticia a la revista del usuario, se volverá a ver en el navegador la página /canales/num correspondiente al canal en que se seleccionó.
  \end{itemize}

\item En la página /usuario que corresponde al usuario autenticado se mostrará, además de lo ya mencionado para la interfaz pública, un formulario en el que se podrá especificar la siguiente información:

  \begin{itemize}
  \item Los parámetros CSS para el usuario autenticado (al menos los indicados anteriormente para ser manejados por un documento CSS). Si el usuario los cambia, a partir de ese momento deberá verse el sitio con los nuevos valores, y para ello deberá servirse un nuevo documento CSS.
  \item El título de la revista del usuario autenticado.
  \end{itemize}
\end{itemize}

Si es preciso, se añadirán más recursos (pero sólo si es realmente preciso) para poder satisfacer los requisitos especificados.

Dados los recursos mencionados anteriormente, no se permitirán los nombres de usuario ``canales'' ni ``ayuda'' (pero no hay que hacer ninguna comprobación para esto: se asume que no se darán de alta esos usuarios en el Admin Site).


Como información pública de noticia se mostrará:
\begin{itemize}
\item El título de la noticia, como enlace a la noticia en el sitio web original.
\item La fecha en que fue publicada la noticia en el sitio original (junto al texto ``publicada en'').
\item La fecha en que fue seleccionada para esta revista (junto al texto ``elegida en'').
\item El contenido de la noticia.
\item El nombre del canal de donde viene la noticia, como enlace a la página de ese canal en MiRevista.
  \end{itemize}



%%----------------------------------------------------------------------------
\subsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
\item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

\item Generación de un canal RSS para los contenidos que se muestran en la página principal.

\item Uso de AJAX para algún aspecto de la práctica (por ejemplo, para seleccionar una noticia para una revista).

\item Puntuación de noticias. Cada visitante (registrado o no) puede dar un ``+1'' a cualquier noticia del sitio. La suma de ``+'' que ha obtenido una noticia se verá cada vez que se vea la noticia en el sitio.

\item Comentarios a revistas. Cada usuario registrado puede comentar cualquier revista del sitio. Estos comentarios se podrán ver luego en la página de la revista.

\item Autodescubrimiento de canales. Dada una URL (de un blog, por ejemplo), busca si en ella hay algún enlace que parece un canal. Si es así, ofrécelo al usuario para que lo pueda elegir. Esto se puede usar, por ejemplo, en la página que muestra el listado de canales, como una opción más para elegir canales (``especifica un blog para buscar sus canales'').
\end{itemize}


%%----------------------------------------------------------------------------
\subsection{Entrega de la práctica}

\textbf{Fecha límite de entrega de la práctica:} 22 de mayo de 2013.

La práctica se entregará subiéndola al recurso habilitado a tal fin en el sitio Moodle de la asignatura. Los alumnos que no entreguen las práctica de esta forma serán considerados como no presentados en lo que a la entrega de prácticas se refiere. Los que la entreguen podrán ser llamados a realizar también una entrega presencial, que tendrá lugar en la fecha y hora exacta se les comunicará oportunamente. Esta entrega presencial podrá incluir una conversación con el profesor sobre cualquier aspecto de la realización de la práctica.

Para entregar la práctica en el Moodle, cada alumno subirá al recurso habilitado a tal fin un fichero tar.gz con todo el código fuente de la práctica. El fichero se habrá de llamar practica-user.tar.gz, siendo ``user'' el nombre de la cuenta del alumno en el laboratorio.

El fichero que se entregue deberá constar de un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos tres usuarios con sus datos correspondientes, y con al menos cinco noticias en su revista, y al menos tres canales RSS diferentes. Se incluirá también un fichero README con los siguientes datos:

\begin{itemize}
\item Nombre de la asignatura.
\item Nombre completo del alumno.
\item Nombre de su cuenta en el laboratorio.
\item Nombres y contraseñas de los usuarios creados para la práctica. Éstos deberán incluir al menos un usuario con cuenta ``marta'' y contraseña ``marta'' y otro usuario con cuenta ``pepe'' y contraseña ``pepe''.
\item Canales disponibles en el sitio, incluyendo su URL
\item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
\item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
\item URL del vídeo demostración de la funcionalidad básica
\item URL del vídeo demostración de la funcionalidad optativa, si se ha realizado funcionalidad optativa
\end{itemize}

El fichero README se incluirá también como comentario en el recurso de subida de la práctica, asegurándose de que las URLs incluidas en él son enlaces ``pinchables''.

Los vídeos de demostración serán de una duración máxima de 2 minutos (cada uno), y consistirán en una captura de pantalla de un navegador web utilizando la aplicación, y mostrando lo mejor posible la funcionalidad correspondiente (básica u opcional). Siempre que sea posible, el alumno comentará en el audio del vídeo lo que vaya ocurriendo en la captura. Los vídeos se colocarán en algún servicio de subida de vídeos en Internet (por ejemplo, Vimeo o YouTube).

Hay muchas herramientas que permiten realizar la captura de pantalla. Por ejemplo, en GNU/Linux puede usarse Gtk-RecordMyDesktop o Istanbul (ambas disponibles en Ubuntu). Es importante que la captura sea realizada de forma que se distinga razonablemente lo que se grabe en el vídeo.

En caso de que convenga editar el vídeo resultante (por ejemplo, para eliminar tiempos de espera) puede usarse un editor de vídeo, pero siempre deberá ser indicado que se ha hecho tal cosa con un comentario en el audio, o un texto en el vídeo. Hay muchas herramientas que permiten realizar esta edición. Por ejemplo, en GNU/Linux puede usarse OpenShot o PiTiVi.

%%----------------------------------------------------------------------------
\subsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura con la versión de Django que se ha usado en prácticas (Django 1.7.*).

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Se recomienda construir una o varias aplicaciones complementarias para probar la descarga y almacenamiento en base de datos de los canales que alimentarán las revistas.

Los usuarios registrados pueden, en principio, hacer disponible cualquier canal de cualquier blog. Sin embargo, para la funcionalidad mínima es suficiente que MiRevista funcione con blogs de WordPress.com.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el navegador Firefox (considerándolos como canales RSS) disponibles en el laboratorio.


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2012, diciembre)}
\label{practica-final-2012-12}

El proyecto final de la asignatura consiste en la creación de un planeta, o agregador de canales, como aplicación web. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener. Llamaremos a la aplicación MiPlaneta.

%%----------------------------------------------------------------------------
\subsubsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}
\item La práctica consistirá en una aplicación web que servirá los datos a los usuarios.

\item MiPlaneta se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item Se usará la aplicación Django ``Admin Site'' para mantener los usuarios con cuenta en el sistema, y para la gestión general de las bases de datos necesarias (todas las bases de datos que mantenga MiPlaneta tendrá que ser accesible vía este ``Admin Site''.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que MiPlaneta tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones.
  \item Un pie de página con una nota de copyright.
  \end{itemize}

Cada una de estas partes estará marcada con propiedades ``id'' en HTML, para poder ser referenciadas en hojas de estilo CSS.

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de MiPlaneta. Estas hojas definirán al menos el color de fondo y del texto, y alguna propiedad para las partes marcadas que se indican en el apartado anterior.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item Los usuarios serán dados de alta en MiPlaneta mediante el módulo ``Admin Site'' de Django. Una vez estén dados de alta, serán considerados ``usuarios registrados''.

\item Los usuarios registrados podrán especificar en MiPlaneta su número de usuario en el Moodle de la ETSIT. Por ejemplo, si la página de perfil de un usuario en el Moodle de la ETSIT es \url{http://docencia.etsit.urjc.es/moodle/user/profile.php?id=8} (llamaremos a la página a la que apunta esta URL la ``página del usuario en el Moodle de la ETSIT'') su número de usuario es 8. Puede obtenerse el número de usuario en el Moodle de la ETSIT a través de los enlaces a ese usuario en los mensajes que pone en sus foros, por ejemplo.

\item Cada usuario registrado podrá indicar el blog que le representa en MiPlaneta. Para ello, especificará la URL del canal RSS correspondiente a ese blog.

\item Habrá una URL para actualizar los contenidos.

\item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá los artículos en la base de datos e información pública para cada usuario.
\end{itemize}


%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad mínima}

Interfaz pública: recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador) para cualquier visitante (sea usuario registrado o no):

\begin{itemize}
\item /: Página principal de MiPlaneta. Lista de los últimos 20 artículos, por fecha de publicación, en orden inverso (más nuevos primero). Para cada artículo se mostrará la ``información pública de articulo'', ver más abajo.

\item /users: Lista de usuarios registrados de MiPlaneta. Para casa usuario se mostrará la ``información resumida de usuario'', ver más abajo.

\item /users/alias: Información sobre el usuario que tiene el alias ``alias'' en MiPlaneta. El alias es el nombre de usuario que tiene como usuario registrado, fijado con el módulo ``Admin Site''. Se incluirá la ``información completa de usuario'', ver más abajo.

\item /update: Actualización de los artículos de todos los blogs. Cuando sea invocada, se bajarán todos los canales y se almacenarán en la base de datos los artículos correspondientes. Si un artículo ya estaba en la base de datos, no debe almacenarse dos veces. Al terminar, enviará una redirección a la página principal.
\end{itemize}

Además, todas las páginas de la interfaz pública incluirán un formulario para poder autenticarse si se es usuario registrado, y un menú desde el que se podrá acceder a / (con el texto ``página principal''), a /users (con el texto ``listado de usuarios'') y a /update (con el texto ``actualizar'').

Interfaz privada: recursos a servir como páginas HTML completas para usuarios registrados (una vez se han autenticado).

\begin{itemize}
\item Todos los recursos de la interfaz pública.
\item /conf: Configuración de usuario. Tendrá un formulario en el que se podrá especificar:
  \item Un número de usuario del Moodle de la ETSIT
  \item La URL del canal RSS de un blog
  \item El color de fondo de todas las páginas del blog
  \item El color del texto normal de todas las páginas del blog
\end{itemize}

Además, todas las páginas de la interfaz privada incluirán el nombre y la foto del usuario registrado (según aparecen en su perfil el en Moodle de la ETSIT), una opción para cerrar la sesión y un menú que incluirá las mismas opciones que el menú público más otra que permita acceder a /conf con el texto ``configuración''.

Tanto el color de fondo como el del texto normal de las páginas deberán recibirse en el navegador como parte de un documento CSS.

Detalles de las distintas informaciones mencionadas:

\begin{itemize}
\item Información pública de artículo. Se mostrará:
  \begin{itemize}
  \item Del artículo: su título (que será un enlace al artículo en su blog original) y su contenido (tal y como venga especificado en el canal).
  \item Del blog original que lo contiene: el nombre del blog, un enlace al blog, y otro a su canal RSS.
  \item Del usuario del Moodle de la ETSIT correspondiente: el nombre, que será un enlace a ``/users/alias'' (el alias en MiPlaneta) y la foto.
  \end{itemize}

\item Información resumida de usuario. Se mostrará:
  \begin{itemize}
  \item Del usuario del Moodle de la ETSIT correspondiente: el nombre, la foto, el enlace a su sitio web. El nombre será un enlace a ``/users/alias'' (el alias en MiPlaneta).
  \item Del blog original que lo contiene: el nombre del blog, que será un enlace a ese mismo blog.
  \end{itemize}

\item Información completa de usuario. Se mostrará:
  \begin{itemize}
  \item Del usuario del Moodle de la ETSIT correspondiente: el nombre, la foto, el enlace a su sitio web, y un enlace a su perfil en Moodle de la ETSIT.
  \item Del blog original que lo contiene: el nombre del blog, un enlace al blog, y otro a su canal RSS, todos los artículos almacenados para ese blog.
  \item De cada artículo: su título (que será un enlace al artículo en su blog original) y su contenido (tal y como venga especificado en el canal).
  \end{itemize}
\end{itemize}


Además de estos recursos, se atenderá a cualquier otro que sea necesario para proporcionar la funcionalidad indicada.


%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
\item Atención al idioma indicado por el navegador. El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador.

\item Generación de un canal RSS para los contenidos que se muestran en la página principal.

\item Uso de AJAX para algún aspecto de la práctica (por ejemplo, en los formularios de /conf)

\item Puntuación de artículos. Cada usuario registrado puede puntuar cualquier artículo del sitio, por ejemplo entre 1 y 5. Estas puntuaciones se podrán ver luego junto al artículo en cuestión.

\item Comentarios a artículos. Cada usuario registrado puede comentar cualquier artículo del sitio. Estos comentarios se podrán ver luego junto al artículo en cuestión (en la página de ese artículo).

\item Soporte para logos. Cada blog o artículo de un blog se presentará junto con un logo que represente al blog en cuestión.

\item Autodescubrimiento de canales. Dada una URL (de un blog, por ejemplo), busca si en ella hay algún enlace que parece un canal. Si es así, ofrécelo al usuario para que lo pueda elegir. Esto se puede usar, por ejemplo, en la página de configuración de usuario, como una opción más para elegir canales (``especifica un blog para buscar sus canales'').
\end{itemize}


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2011, diciembre)}
\label{practica-final-2011-12}

%[Este enunciado es aún tentativo, incompleto, y está sujeto a cambios]

El proyecto final de la asignatura consiste en la creación de un sitio web de creación de revistas con resúmenes de información procedente de sitios terceros, MetaMagazine. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

%%----------------------------------------------------------------------------
\subsubsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}
\item La práctica consistirá en una aplicación web que servirá los datos a los usuarios.

\item La aplicación web se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item Se usará la aplicación Django ``Admin site'' para mantener los usuarios con cuenta en el sistema, y para la gestión general de las bases de datos necesarias.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que toda la aplicación tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones también en la parte superior.
  \item Un pie de página con una nota de copyright.
  \end{itemize}

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la aplicación.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item El sitio MetaMagazine ofrece como servicio la construcción de revistas con resúmenes de información obtenidos a partir de canales RSS de ciertos sitios terceros. Para construir una revista, primero se extraerán noticias de los canales correspondientes. Para cada noticia, se buscarán las URLs incluidas en su texto. Para cada URL, se visitará la página correspondiente, y se extraerá de ella la información (texto, imágenes, etc.) deseada. Con esta información se compondrá una página HTML que será la que se sirva a los navegadores que visiten la revista de ese usuario.

\item Cada usuario autenticado podrá construir una revista indicando en qué información de sitios terceros están interesados (eligiendo los canales RSS correspondientes), e indicando cuántas noticias de cada uno se tomarán como máximo cuando se actualice la revista. Cuando un usuario autenticado indica un nuevo canal en el que está interesado, el sistema genera una revista para ese sitio a partir de su canal (usando el número de noticias que ha seleccionado), y se lo muestra al usuario. Si el usuario lo acepta, se toma nota del sitio y de los contenidos de la revista en la base de datos.

\item Cuando cualquier visitante de MetaMagazine acceda a la revista creada por un usuario, podrá ver la información almacenada para esa revista. Además, la página de la revista incluirá un mecanismo para actualizarla, bajando información de los sitios correspondientes. En la actualización, para cada canal sólo se considerará el número de noticias más actuales que haya seleccionado el creador de la revista (y se ignorarán las más antiguas, salvo que ya estén en la base de datos). No se eliminarán las noticias antiguas de la base de datos al actualizar las revistas.

\item Cuando esté visitando MetaMagazine un visitante sin autenticar, le aparecerá una caja para autenticarse. Si es un usuario autenticado, le aparecerá un mecanismo para salir de la cuenta (``desautenticarse'').
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad mínima}

Esta es la funcionalidad mínima que habrá de proporcionar la aplicación:

\begin{itemize}
\item Para cada revista (correspondiente a un usuario registrado del sitio) se mostrará a cualquier visitante:
  \begin{itemize}
  \item El título de la revista.
  \item Un enlace a los canales y sitios web correspondientes a esos canales, y la fecha de última actualización (para cada uno de ellos).
  \item Para cada canal, un mecanismo para actualizar en la base de datos la información extraída las páginas web que referencie.
  \item El texto de las noticias de los sitios elegidos para esa revista.
  \item Para cada noticia, un mecanismo para desplegar la información extraída las páginas web que referencie.
  \item Un mecanismo para desplegar (de una vez) la información extraída de todas las noticias.
  \end{itemize}

\item Para cada noticia, la información que se mostrará será:
  \begin{itemize}
  \item Enlace a la página de la noticia en MetaMagazine.
  \item Los enlaces a las páginas web cuya URL aparezca en la noticia.
  \item Para cada una de esas páginas, las primeras 50 palabras que incluyan (basta con considerar, por ejemplo, las primeras 50 palabras incluidas en elementos $<p>$).
  \item Para cada una de esas páginas, 5 de las imágenes que incluyan, si las hubiera.
  \item Para cada una de esas páginas, los vídeos de Youtube, si los hubiera.
  \end{itemize}

\item Para cada revista (correspondiente a un usuario registrado del sitio) se mostrará al usuario que la construye:

  \begin{itemize}
  \item Toda la información anterior, que se muestra también para cualquier visitante.
  \item El título de la revista de forma que se pueda cambiar.
  \item Una zona para incluir nuevos canales en la revista, que incluirá:
    \begin{itemize}
    \item Un menú con la opción de sitios de los que se podrán incluir canales.
    \item Un formulario para indicar qué canal del sitio elegido se incluirá.
    \end{itemize}
  \item Para cada canal de la revista, un mecanismo para eliminarlo.
  \end{itemize}

\item Como mínimo, se podrán seleccionar los siguientes tipos de canales:
  \begin{itemize}
  \item Canales RSS correspondientes a usuarios de Twitter\footnote{Para el usuario ``jgbarah'': \\
    \url{https://twitter.com/statuses/user_timeline/jgbarah.rss}}.
  \item Canales RSS correspondientes a usuarios de Identi.ca\footnote{Para el usuario ``jgbarah'': \\
    \url{http://identi.ca/jgbarah/rss}}.
  \item Canales RSS correspondientes a usuarios de Youtube\footnote{Para el usuario ``user'': \\
\url{http://gdata.youtube.com/feeds/api/videos?max-results=5&alt=rss&author=user}}.
  \end{itemize}
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Esquema de recursos servidos (funcionalidad mínima)}

Recursos a servir como páginas HTML completas (pensadas para ser vistas en el navegador):

\begin{itemize}
\item /: Página principal de MetaMagazine, con texto de bienvenida y contenidos de una de las revistas (aleatoriamente, se elegirá una cada vez que se reciba una nueva visita, y se incluirán sus contenidos, que deberán ser iguales a los que se verían en la página de esa revista).
\item /channels: Lista de canales activos, con enlace a los RSS correspondientes
\item /magazines: Lista de revistas disponibles, con enlace a cada una de ellas.
\item /magazines/user: Revista del usuario ``user''
\item /news/id: Página de la noticia ``id'' en MetaMagazine: título de la noticia y elementos a mostrar (enlaces de la noticia, primeras palabras de los sitios web en esos enlaces, imágenes en esos enlaces, etc.)
\end{itemize}

Recursos a servir con texto HTML listo para empotrar en otras páginas (esto es, texto que pueda ir dentro de un elemento $<body>$):

\begin{itemize}
\item /api/news/id: Para la noticia ``id'', elementos a mostrar (enlaces de la noticia, primeras palabras de los sitios web en esos enlaces, imágenes en esos enlaces, etc.)
\end{itemize}

Además de estos recursos, se atenderá a cualquier otro que sea necesario para proporcionar la funcionalidad indicada.


%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}

\item Recurso /conf: Configuración del usuario, para usuarios registrados. Incluirá campos para editar su nombre público, su contraseña (dos veces, para comprobar).
\item Recurso /conf/skin: Configuración del estilo (skin), para usuarios registrados. Mediante un formulario, el usuario podrá editar el fichero CSS que codificará su estilo, o podrá copiar el de otro usuario. Cada usuario tendrá un estilo (fichero CSS) por defecto, que el sistema le asignará si no lo ha configurado.
\item Recurso /rss/user: Canal RSS para la revista del usuario ``user'', con las 20 últimas entradas (del canal que sea.
\item Uso de AJAX para otros aspectos de la aplicación. Por ejemplo, para indicar qué canales se quieren.
\item Puntuación de revistas. Cada usuario registrado puede puntuar cualquier revista del sitio, por ejemplo entre 1 y 5. Estas puntuaciones se podrán ver luego junto a la revista en cuestión.
\item Puntuación de noticias. Cada usuario registrado puede puntuar cualquier noticia del sitio, por ejemplo entre 1 y 5. Estas puntuaciones se podrán ver luego junto a la noticia en cuestión.
\item Comentarios a noticias. Cada usuario registrado puede comentar cualquier noticia del sitio. Estos comentarios se podrán ver luego junto a la noticia en cuestión.
\item Soporte para avatares. Cada canal se presentará junto con el avatar (el logo que ha elegido el usuario en el sitio original, como por ejemplo Twitter) del canal.
\item Mejoras en la identificación de la información de las páginas web enlazadas. Por ejemplo, seleccionar las imágenes descartando las que probablemente son pequeños iconos (analizando el tamaño de la imagen), o identificando otros elementos relevantes.
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura, con la versión de Django instalada en /usr/local/django (Django 1.3.1).

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Se recomienda construir una o varias aplicaciones complementarias para probar la descarga y almacenamiento en base de datos de los canales que alimentarán el planeta.

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2012, mayo)}
\label{practica-final-2012-05}

%[Este enunciado es aún tentativo, incompleto, y está sujeto a cambios]

El proyecto final a entregar en la convocatoria extraordinaria (mayo de 2012) será como la de la entrega ordinaria (práctica~\ref{practica-final-2011-12}), con las diferencias que se indican en los siguientes apartados.

%%----------------------------------------------------------------------------
\subsubsection{Arquitectura y funcionamiento general}

Con respecto a las de la práctica de la convocatoria ordinaria, el enunciado tiene los siguientes cambios:

\begin{itemize}
\item En lugar de canales RSS se utilizarán canales Atom para descargar las noticias de los sitios terceros.
\item Para construir una revista, en lugar de indicar qué información se quiere de cada sitio tercero, se indicarán cadenas de texto. Estas cadenas se utilizarán como hashtags en los sitios terceros que los soporten, o como cadenas de búsqueda en los que no. Por lo tanto, el usuario especificará una cadena, que se usará para definir qué canales Atom de los sitios terceros habrá que considerar (ver funcionalidad mínima más adelante).
\item Al definir su revista, un usuario podrá por tanto especificar cadenas, igual que antes especificaba canales de un sitio tercero. Ahora, cada cadena indicará qué canales de todos los sitios terceros hay que considerar para esa revista.
\end{itemize}

El resto queda igual.

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad mínima}

Con respecto a la de la práctica de la convocatoria ordinaria, el enunciado tiene los siguientes cambios:

\begin{itemize}
\item Para cada cadena que un usuario especifique en su revista se bajará información de, como mínimo, los siguientes canales (los ejemplos serían para la cadena ``urjc''):
  \begin{itemize}
  \item Canal Atom correspondiente al hashtag de Twitter definido por esa cadena\footnote{Para el hashtag ``\#urjc'': \\
    \url{http://search.twitter.com/search.atom?q=\%23urjc}}.
  \item Canal Atom correspondientes al hashtag de Identi.ca definido por esa cadena\footnote{Para el hashtag ``\#urjc'': \\
    \url{http://identi.ca/api/statusnet/tags/timeline/urjc.atom}}.
  \item Canal Atom correspondientes a la búsqueda en Youtube de esa cadena\footnote{Para la búsqueda ``urjc'': \\
\url{http://gdata.youtube.com/feeds/api/videos?q=urjc&max-results=5&alt=atom}}.
  \end{itemize}

\end{itemize}

El resto queda igual.



%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2010, enero)}

El proyecto final de la asignatura consiste en la creación de un planeta, o agregador de canales, como aplicación web. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

%%----------------------------------------------------------------------------
\subsubsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}
\item La práctica consistirá en una aplicación web que servirá los datos a los usuarios.

\item La aplicación web se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item Se usará la aplicación Django ``Admin site'' para mantener los usuarios con cuenta en el sistema, y para la gestión general de las bases de datos necesarias.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que toda la aplicación tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones también en la parte superior.
  \item Un pie de página con una nota de copyright.
  \end{itemize}

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la aplicación.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item Los usuarios indicarán en qué canales (blogs) están interesados. Para ello, cada usuario podrá especificar un número en principio ilimitado de URLs, cada una correspondiente a un canal que le interesa.
\item Cuando un usuario indica que le interesa un blog, se baja el canal correspondiente y se almacenan en la base de datos los artículos referenciados en él.
\item Cuando un usuario acceda a la URL de actualización de sus blogs, se bajan los canales correspondientes a todos ellos, y se almacenan en la base de datos los artículos correspondientes. Si un artículo ya estaba en la base de datos, no debe almacenarse dos veces.
\item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá los artículos en la base de datos e información pública para cada usuario.
\item Sólo los navegadores con un usuario autenticado podrán personalizar en qué blogs están interesados.
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad mínima}

\begin{itemize}
\item Para cada artículo en la base de datos del planeta, se mostrarán (salvo que se indique lo contrario) su título (que será un enlace al artículo en su blog original), un enlace al blog original que lo incluye, y su contenido (tal y como venga especificado en el canal).
\item El planeta mostrará en una interfaz pública (visible por cualquiera que no tenga cuenta en el sitio) todos los artículos que tenga en la base de datos, organizados en los siguientes recursos:

  \begin{itemize}
  \item /: Lista de los últimos 20 artículos, por fecha de publicación, en orden inverso (más nuevos primero).
  \item /blog: Lista de los últimos 20 artículos del blog ``blog'', por fecha de publicación, en orden inverso (más nuevos primero).
  \item /blog/num: Artículo número ``num'' del blog ``blog'', siendo ``0'' el artículo más antiguo de ese blog que se tiene en la base de datos.
  \end{itemize}

\item Además, el planeta mostrará en una interfaz privada (visible sólo para un usuario concreto cuando se autentica como tal) los artículos que éste haya seleccionado, organizados en los siguientes recursos:

  \begin{itemize}
  \item /custom: Lista de los últimos 20 artículos, por fecha de publicación, en orden inverso (más nuevos primero), de los blogs seleccionados por el usuario.
  \end{itemize}

\item Además, habrá ciertos recursos donde los usuarios registrados podrán (una vez autenticados) configurar ciertos aspectos del sitio:

  \begin{itemize}
  \item /conf: Configuración del usuario. Incluirá campos para editar su nombre público, su contraseña (dos veces, para comprobar), y los blogs en los que está interesado. Estos blogs se podrán elegir bien de un menú desplegable (en el que estarán los que ya se están bajando) o indicando sus datos (la URL de su canal correspondiente).
  \item /conf/skin: Configuración del estilo (skin) con el que el usuario quiere ver el sitio. Mediante un formulario, el usuario podrá editar el fichero CSS que codificará su estilo, o podrá copiar el de otro usuario. Cada usuario tendrá un estilo (fichero CSS) por defecto, que el sistema le asignará si no lo ha configurado.
  \item /update: Actualizará los artículos de los blogs en los que está interesado el usuario.
  \end{itemize}

\item Para cada usuario, se mantendrán ciertos recursos públicos con información relacionada con ellos:

  \begin{itemize}
  \item /user: Nombre de usuario y lista de blogs que interesan al usuario ``user''.
  \item /user/feed: Canal RSS  con los 20 últimos artículos que interesan al usuario ``user''.
  \end{itemize}

\item El idioma de la interfaz de usuario del planeta tendrá en cuenta lo que especifique el navegador, y podrá ser especificado también en la URL /conf para los usuarios registrados (entre opciones para indicar un idioma particular, o ``por defecto'', que respetará lo que indique el navegador).

\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
\item Uso de AJAX para algún aspecto de la práctica (por ejemplo, para elegir un nuevo blog, o para subir comentarios)
\item Puntuación de artículos. Cada usuario registrado puede puntuar cualquier artículo del sitio, por ejemplo entre 1 y 5. Estas puntuaciones se podrán ver luego junto al artículo en cuestión.
\item Comentarios a artículos. Cada usuario registrado puede comentar cualquier artículo del sitio. Estos comentarios se podrán ver luego junto al artículo en cuestión (en la página de ese artículo).
\item Soporte para logos. Cada blog o artículo de un blog se presentará junto con un logo que represente al blog en cuestión.
\item Autodescubrimiento de canales. Dada una URL (de un blog, por ejemplo), busca si en ella hay algún enlace que parece un canal. Si es así, ofrécelo al usuario para que lo pueda elegir. Esto se puede usar, por ejemplo, en la página de configuración de usuario, como una opción más para elegir canales (``especifica un blog para buscar sus canales'').
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Entrega de la práctica}

La práctica se entregará el día del examen de la asignatura, o un día posterior si así se acordase. La entrega se realizará presencialmente, en el laboratorio donde tienen lugar las clases de la asignatura habitualmente.

Cada alumno entregará su práctica en un fichero tar.gz, que tendrá preparado antes del comienzo del examen, y cuya localización mostrará al profesor durante el transcurso del mismo. El fichero se habrá de llamar practica-user.tar.gz, siendo ``user'' el nombre de la cuenta del alumno en el laboratorio.

El fichero que se entregue deberá constar de un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos tres usuarios, y cinco blogs con sus noticias correspondientes. Se incluirá también un fichero README con los siguientes datos:

\begin{itemize}
\item Nombre de la asignatura.
\item Nombre completo del alumno.
\item Nombre de su cuenta en el laboratorio.
\item Nombres y contraseñas de los usuarios creados para la práctica.
\item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
\item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura, con la versión de Django instalada en /usr/local/django (Django 1.1.1).

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Se recomienda construir una o varias aplicaciones complementarias para probar la descarga y almacenamiento en base de datos de los canales que alimentarán el planeta.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el agregador Liferea.

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2010, junio)}

El proyecto final para entrega en la convocatoria extraordinaria de junio será similar a la especificada para la convocatoria ordinaria de enero. En particular, deberá cumplir las siguientes condiciones:

\begin{itemize}
\item La arquitectura general será la misma, salvo:
  \begin{itemize}
  \item En lugar de incluir en las plantillas Django un menú de opciones en la parte superior de las páginas, ese menú estará en una columna en la parte derecha de cada página.
  \end{itemize}
\item El funcionamiento general será el mismo, salvo:
  \begin{itemize}
  \item Cuando un usuario indica que le interesa un blog, no se almacenan en la base de datos los artículos de ese blog.
  \item No habrá URL de actualización de los blogs de un usuario.
  \item Los artículos correspondientes a un blog se actualizarán sólo cuando se visualice una página del planeta que incluya artículos de ese blog. En ese momento, los artículos nuevos (los que no estaban ya en la base de datos) se bajarán a dicha base de datos.
  \end{itemize}
\item La funcionalidad mínima será la misma, salvo:
  \begin{itemize}
  \item No se implementará el recurso ``/update'', dado que el funcionamiento de la actualización será diferente, como se ha indicado anteriormente.
  \item El recurso ``/user'' incluirá la lista de los últimos 20 artículos, por fecha de publicación, en orden inverso (más nuevos primero), de los blogs seleccionados por el usuario, además del nombre de usuario.
  \item Cada usuario registrado podrá puntuar cualquier artículo del sitio entre 1 y 5. Estas puntuaciones se podrán ver junto al artículo en cuestión, en todos los sitios donde aparece un enlace a él en el planeta.
  \end{itemize}
\item La funcionalidad optativa será la misma, salvo la puntuación de artículos, que ya ha sido mencionada como funcionalidad mínima.
\end{itemize}

El resto de condiciones serán iguales que en la convocatoria de enero de 2010.

%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2010, diciembre)}

La entrega de esta práctica será necesaria para poder optar a aprobar la asignatura.
 Este enunciado corresponde con la convocatoria de diciembre.

El proyecto final de la asignatura consiste en la creación de una aplicación web de resumen y cache de micronotas (microblogs). En este enunciado, llamaremos a esa aplicación ``MiResumen'', y a los resúmenes de micronotas para cada usuario, ``microresumen''.

Los sitios de microblogs permiten a sus usuarios compartir notas breves (habitualmente de 140 caracteres o menos). Entre los más populares pueden mencionarse Twitter\footnote{\url{http://twitter.com}} e Identi.ca\footnote{\url{http://identi.ca}}. La aplicación web a realizar se encargará de mostrar las micronotas que se indiquen, junto con información relacionada. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

%%----------------------------------------------------------------------------
\subsubsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}
\item La práctica consistirá en una aplicación web que servirá los datos a los usuarios.

\item La aplicación web se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item Se usará la aplicación Django ``Admin site'' para mantener los usuarios con cuenta en el sistema, y para la gestión general de las bases de datos necesarias.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que toda la aplicación tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones también en la parte superior, a la derecha del banner del sitio.
  \item Un pie de página con una nota de copyright.
  \end{itemize}

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la aplicación.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item Se considerarán sólo micronotas en Identi.ca. Llamaremos a los usuarios de Identi.ca ``micronoteros''.
\item MiResumen mantendrá usuarios, que habrán de autenticarse para poder configurar la aplicación.
\item Cada usuario de MiResumen indicará qué micronoteros de Identi.ca le interesan, configurando una lista de micronoteros.
\item Cuando un usuario indica que le interesa un micronotero, MiResumen bajará el canal RSS correspondiente, y se almacenarán en la base de datos las micronotas referenciadas en él.
\item Cuando un usuario acceda a la URL de actualización de su microresumen, se bajan los canales correspondientes a todos los micronoteros que tiene especificados, y se almacenan en la base de datos las micronotas correspondientes. Si una micronota ya estaba en la base de datos, no debe almacenarse dos veces.
\item Cualquier navegador podrá acceder a la interfaz pública del sitio, que ofrecerá los microresúmenes de cada usuario.
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad mínima}

\begin{itemize}
\item Para cada micronota en la base de datos del planeta, se mostrarán (salvo que se indique lo contrario) su texto, un enlace a la micronota en Identi.ca, el nombre del micronotero que la puso (con un enlace a su página en Identi.ca), y la fecha en que la puso, 
\item MiResumen mostrará en una interfaz pública (visible por cualquiera que no tenga cuenta en el sitio) todas las micronotas que tenga en la base de datos, organizadas en los siguientes recursos:

  \begin{itemize}
  \item /: Microresumen de las últimas 50 micronoticias, ordenadas por fecha inversa de publicación, en orden inverso (más nuevos primero).
  \item /noteros/micronotero: Microresumen de las últimas 50 micronoticias del micronotero ``micronotero'', ordenadas por fecha inversa de publicación, en orden inverso (más nuevos primero).
  \item /usuarios/usuario: Microresumen de las últimas 50 micronoticias de los micronoteros que sigue el usuario ``usuario'', ordenadas por fecha inversa de publicación.
  \item /usuarios/usuario/feed: Canal RSS  con las 50 últimas micronotas que interesan al usuario ``usuario''.
  \end{itemize}

\item Además MiResumen proporcionará ciertos recursos donde los usuarios registrados podrán (una vez autenticados) configurar ciertos aspectos del sitio:

  \begin{itemize}
  \item /conf: Configuración del usuario. Incluirá campos para editar su nombre público, su contraseña (dos veces, para comprobar), y el idioma que prefiere (al menos deberá poder elegir entre español e inglés).
  \item /conf/skin: Configuración del estilo (skin) con el que el usuario quiere ver el sitio. Mediante un formulario, el usuario podrá editar el fichero CSS que codificará su estilo, o podrá copiar el de otro usuario. Cada usuario tendrá un estilo (fichero CSS) por defecto, que el sistema le asignará si no lo ha configurado.
  \item /micronoteros: Lista de los micronoteros seleccionados por el usuario, junto con enlace a su página en Identi.ca. El usuario podrá eliminar un micronotero de la lista, o añadir uno nuevo mediante POST sobre ese recurso. Los micronoteros se podrán elegir bien de un menú desplegable (en el que estarán los que tiene seleccionados cualquier usuario de MiResumen) o indicando su nombre de micronotero en Identi.ca.
  \item /update: Actualizará las micronotas de los micronoteros en los que está interesado el usuario.
  \end{itemize}

\item El idioma de la interfaz de usuario del planeta será el especificado en la URL /conf para los usuarios registrados. Para los visitantes no registrados, será español.

\end{itemize}

Para la generación de canales RSS y para la internacionalización se podrán usar los mecanismos que proporciona Django, o no, según el alumno considere que le sea más conveniente.

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
\item Uso de Ajax para algún aspecto de la práctica (por ejemplo, para solicitar actualización de la lista de micronotas, o para suscribirse a un micronotero picando sobre una micronota suya).
\item Promoción de micronotas. Cada usuario registrado puede promocionar (indicar que le gusta) cualquier micronota del sitio. Cada micronota se verá en el sitio junto con el número de promociones que ha recibido.
\item Soporte para avatares. Cada micronota se presentará junto con el avatar (imagen) correspondiente al micronotero que la ha puesto.
\item Soporte para Twitter y/o otros sitios de microblogging (micronotas) además de Identi.ca
\item Enlace a URLs. Se identificarán en las micronotas los textos que tengan formato de URL, y se mostrará esa URL como enlace.
\item Enlace a micronoteros referenciados. Se identificarán en las micronotas los textos que tengan formato de identificador de micronotero (@nombre), y se mostrarán como enlace a la página del micronotero en cuestión.
\item Suscripción a los mismos micronoteros a los que esté suscrito otro usuario. Un usuario podrá indicar que quiere suscribirse a la misma lista de micronoteros que otro, indicando sólo su identificador de usuario.
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Entrega de la práctica}

La práctica se entregará electrónicamente en una de las dos fechas indicadas:

\begin{itemize}
\item El día anterior al examen de la asignatura, esto es, el 12 de diciembre, a las 18:00.
\item El 30 de diciembre a las 23:00.
\end{itemize}

Además, los alumnos que hayan presentado las prácticas podrán tener que realizar una entrega presencial en una de las dos fechas indicadas:

\begin{itemize}
\item El día del examen, esto es, el 14 de diciembre, al terminar el examen de teoría. La lista de alumnos que tengan que hacer la entrega presencial se indicará durante el examen de teoría.
\item El día 10 de enero, a las 16:00. La lista de alumnos que tengan que hacer la entrega presencial se indicará con anterioridad en el sito web de la asignatura.
\end{itemize}

La entrega presencial se realizará en el laboratorio donde tienen lugar habitualmente las clases de la asignatura.

Cada alumno entregará su práctica colocándola en un directorio en su cuenta en el laboratorio. El directorio, que deberá colgar directamente de su directorio hogar (\$HOME), se llamará ``pf\_django\_2010''.

El directorio que se entregue deberá constar de un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos tres usuarios, y cinco micronoteros con sus micronotas correspondientes. Entre los usuarios, habrá en la base de datos al menos los dos siguientes.

\begin{itemize}
\item Usuario ``pepe'', contraseña ``XXX''
\item Usuario ``pepa'', contraseña ``XXX''
\end{itemize}

Cada uno de estos usuarios estará ya siguiendo al menos dos micronoteros.

Se incluirá también en el directorio que se entregue un fichero README con los siguientes datos:

\begin{itemize}
\item Nombre de la asignatura.
\item Nombre completo del alumno.
\item Nombre de su cuenta en el laboratorio.
\item Nombres y contraseñas de los usuarios creados para la práctica.
\item Nombres de al menos cinco micronoteros cuyas noticias estén en la base de datos de la aplicación.
\item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
\item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
\end{itemize}

Es importante que estas normas se cumplan estrictamente, y de forma especial lo que se refiere al nombre del directorio, porque la recogida de las prácticas, y parcialmente su prueba, se hará con herramientas automáticas.

[Las normas de entrega podrán incluir más detalles en el futuro, compruébalas antes de realizar la entrega.]


%%----------------------------------------------------------------------------
\subsubsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura, con la versión 1.2.3 de Django.

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Se recomienda construir una o varias aplicaciones complementarias para probar la descarga y almacenamiento en base de datos de los canales que alimentarán MiResumen.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el agregador Liferea y el que lleva integrado Firefox.

%%----------------------------------------------------------------------------
\subsubsection{Notas de ayuda}

A continuación, algunas notas que podrían ayudar a la realización de la práctica. Gracias a los alumnos que han contribuido a ellas, bien preguntando sobre algún problema que han encontrado, o incluso aportando directamente una solución correcta.

\begin{itemize}
\item \textbf{Conversión de fechas:}

La conversión de fechas, tal y como vienen en el formato de los canales RSS de Identi.ca, al formato de fechas datetime adecuado para almacenarlas en una tabla de la base de datos se puede hacer así:

\begin{verbatim}
from email.utils import parsedate
from datetime import datetime

dbDate = datetime(*(parsedate(rssDate)[:6]))
\end{verbatim}

El uso de ``*'' permite, en este caso, obtener una referencia a la tupla de siete elementos que contiene los parámetros que espera datetime() (que son siete parámetros).

Más información sobre parsedate() en la documentación del módulo email.utils de Python.

\item \textbf{Envío de hojas CSS:}

Para que el navegador interprete adecuadamente una hoja de estilo, puede ser conveniente fijar el tipo de contenidos de la respuesta HTTP en la que la aplicación la envía al navegador. En otras palabras, asegurar que cuando el navegador reciba la hoja CSS, le venga adecuadamente marcada como de tipo ``text/css'' (y no ``text/html'' o similar, que es como vendrá marcado normalmente lo que responda la aplicación).

En código, bastaría con poner la cabecera ``Content-Type'' adecuada al objeto que tiene la respuesta HTTP que devolverá la función que atiende a la URL para servir la hoja CSS (normalmente en \texttt{views.py}):

\begin{verbatim}
myResponse = HttpResponse(cssText)
myResponse['Content-Type'] = 'text/css'
return myResponse
\end{verbatim}

\end{itemize}


%%----------------------------------------------------------------------------
%%----------------------------------------------------------------------------
\subsection{Proyecto final (2011, junio)}

La entrega de esta práctica será necesaria para poder optar a aprobar la asignatura.
 Este enunciado corresponde con la convocatoria de junio.

El proyecto final de la asignatura consiste en la creación de una aplicación web de resumen y cache de micronotas (microblogs). En este enunciado, llamaremos a esa aplicación ``MiResumen2'', y a los resúmenes de micronotas para cada usuario, ``microresumen''.

Los sitios de microblogs permiten a sus usuarios compartir notas breves (habitualmente de 140 caracteres o menos). Entre los más populares pueden mencionarse Twitter\footnote{\url{http://twitter.com}} e Identi.ca\footnote{\url{http://identi.ca}}. La aplicación web a realizar se encargará de mostrar las micronotas que se indiquen, junto con información relacionada. A continuación se describe el funcionamiento y arquitectura general de la aplicación, la funcionalidad mínima que debe proporcionar, y otra funcionalidad optativa que podrá tener.

%%----------------------------------------------------------------------------
\subsubsection{Arquitectura y funcionamiento general}

Arquitectura general:

\begin{itemize}
\item La práctica consistirá en una aplicación web que servirá los datos a los usuarios.

\item La aplicación web se construirá como un proyecto Django, que incluirá una o varias aplicaciones Django que implementen la funcionalidad requerida.

\item Para el almacenamiento de datos persistente se usará SQLite3, con tablas definidas según modelos en Django.

\item No se mantendrán usuarios con cuenta, ni usando la aplicación Django ``Admin site'' ni de otra manera. Por lo tanto, para usar el sitio no hará falta registrarse, ni entrar en una cuenta.

\item Se utilizarán plantillas Django (a ser posible, una jerarquía de plantillas, para que toda la aplicación tenga un aspecto similar) para definir las páginas que se servirán a los navegadores de los usuarios. Estas plantillas incluirán en todas las páginas al menos:
  \begin{itemize}
  \item Un banner (imagen) del sitio, en la parte superior.
  \item Un menú de opciones justo debajo del banner, formateado en una línea.
  \item Un pie de página con una nota de copyright.
  \end{itemize}

\item Se utilizarán hojas de estilo CSS para determinar la apariencia de la aplicación. Estas hojas se almacenará en la base de datos.
\end{itemize}

Funcionamiento general:

\begin{itemize}
\item Se considerarán sólo micronotas en Identi.ca. Llamaremos a los usuarios de Identi.ca ``micronoteros''.
\item MiResumen2 recordará a todos sus visitantes. A estos efectos, consideraremos como sesión de un visitante todas las interacciones que se hagan con el sitio desde el mismo navegador (por lo tanto, se podrán usar cookies de sesión para mantener esta relación).
\item MiResumen2 mostrará notas de Identi.ca, que se irán actualizando según se indica en el apartado siguiente.
\item Los visitantes de MiResumen2 podrán seleccionar cualquier micronota que aparezca en él.
\item Cada visitante podrá ver las micronotas que ha seleccionado, por orden inverso de publicación en Identi.ca, en un listado que incluirá también la fecha en que seleccionó cada micronota.
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad mínima}

\begin{itemize}
\item Para cada micronota en la base de datos del planeta, se mostrarán (salvo que se indique lo contrario):
  \begin{itemize}
  \item el texto de la micronota
  \item un enlace a la micronota en Identi.ca
  \item el nombre del micronotero que la puso (con un enlace a su página en Identi.ca)
  \item la fecha en que se publicó en Identi.ca
  \item un botón para que cualquier visitante pueda seleccionar esta nota (o deseleccionarla si ya la había seleccionado)
  \item si el usuario ha seleccionado la micronota, la fecha en que la había seleccionado
  \item un número que representará el número de visitantes que han seleccionado esta micronota
  \end{itemize}

\item MiResumen2 mostrará en una interfaz pública (visible por cualquiera que visite el sitio) todas las micronotas que tenga en la base de datos, organizadas en los siguientes recursos:

  \begin{itemize}
  \item /: Microresumen de las últimas 30 micronoticias almacenadas en MiResumen2, ordenadas por fecha inversa de publicación (más nuevos primero). Además, incluirá un enlace al recurso de actualización (ver más abajo), y al microresumen de las 30 siguientes micronoticias (/30, ver más abajo)
  \item /nnn: Microresumen de las micronoticas entre la nnn y la nnn+29, según el orden de fecha inversa de publicación (más nuevos primero, con números más bajos). Se considerará que la micronota más reciente es la micronota 0. Así, /0 mostrará lo mismo que / , /30 mostrará las 30 micronotas siguientes a las mostradas en / y /40 mostrará las micronotas de la 40 a la 67.
  \item /update: Recurso de actualización: cuando se acceda a él, MiResumen2 accederá al RSS de la página principal de Identi.ca y extraerá de él las últimas 20 micronotas (o menos, si no hay tantas micronotas en el canal que no estén ya en la base de datos), almacenándolas en la base de datos y mostrándolas.
  \item /selected: Listado de todas las micronotas seleccionadas por el visitante actual, ordenadas por fecha de publicación inversa (más nuevas primero).
  \item /feed: Canal RSS  con las 10 micronotas más recientes (por fecha de publicación) que ha seleccionado el visitante actual. 
  \item /conf: Configuración del visitante. Incluirá campos para editar el nombre del visitante, que se mostrará en todas las páginas del sitio que se sirvan a ese visitante.
  \item /skin: Configuración del estilo (skin) con el que el visitante quiere ver el sitio. Mediante un formulario, el visitante podrá editar el fichero CSS que codificará su estilo (y que se almacenará en la base de datos). Si no lo han cambiado, los visitantes tendrán el estilo CSS por defecto del sitio.
  \item /cookies: Página HTML que incluirá un listado de las cookies que se están usando con cada uno de los visitantes conocidos para la aplicación, en formato listo para que cada cookie pueda ser copiada y pegada en un editor de cookies.
  \end{itemize}

\end{itemize}

Para la generación de canales RSS y la gestión de sesiones y/o cookies se podrán usar los mecanismos que proporciona Django, o no, según el alumno considere que le sea más conveniente.

%%----------------------------------------------------------------------------
\subsubsection{Funcionalidad optativa}

De forma optativa, se podrá incluir cualquier funcionalidad relevante en el contexto de la asignatura. Se valorarán especialmente las funcionalidades que impliquen el uso de técnicas nuevas, o de aspectos de Django no utilizados en los ejercicios previos, y que tengan sentido en el contexto de esta práctica y de la asignatura.

Sólo a modo de sugerencia, se incluyen algunas posibles funcionalidades optativas:

\begin{itemize}
\item Uso de Ajax para algún aspecto de la práctica (por ejemplo, para seleccionar y deseleccionar una micronota).
\item Votación de micronotas. Cada visitante podrá dar una puntuación entre 0 y 10 a cada micronota. Cuando se muestre cada micronota en el sitio, además de los demás datos que se han mencionado, se incluirá la media de las votaciones que ha tenido, y el número de votaciones que ha tenido esa micronota. Una vez que un visitante ha votado una micronota, no puede volver a votarla, ni cambiar su votación.
\item Soporte para avatares. Cada micronota se presentará junto con el avatar (imagen) correspondiente al micronotero que la ha puesto.
\item Soporte para Twitter y/o otros sitios de microblogging (micronotas) además de Identi.ca
\item Enlace a URLs, etiquetas y micronoteros referenciados. Se identificarán en las micronotas los textos que tengan formato de URL, y se mostrará esa URL como enlace, los que tengan formato de etiqueta (tag, nombres que comienzan por \#), mostrándolos como enlace a la página Identi.ca para ese tag, y los micronoteros referenciados (nombres que comienzan por @), mostrándolos como enlace a la página del micronotero en cuestión en Identi.ca.
\item Recomendación de micronotas. En una página, se mostrarán las micronotas que probablemente interesen al micronotero, basada en la historia de elecciones pasadas. El algoritmo a usarse puede ser: busca los tres visitantes que más notas hayan elegido en común con las del visitante actual, y muestra todas las micronotas que hayan elegido esos visitantes y el visitante actual aún no ha elegido.
\end{itemize}

%%----------------------------------------------------------------------------
\subsubsection{Entrega de la práctica}

La práctica se entregará electrónicamente como muy tarde el día 17 de junio a las 23:00.

Además, los alumnos que hayan presentado las prácticas podrán tener que realizar una entrega presencial el día que esté fijado el examen de teoría de la asignatura. La entrega presencial se realizará en el laboratorio donde tienen lugar habitualmente las clases de la asignatura.

Cada alumno entregará su práctica colocándola en un directorio en su cuenta en el laboratorio. El directorio, que deberá colgar directamente de su directorio hogar (\$HOME), se llamará ``pf\_django\_2010\_2''.

El directorio que se entregue deberá constar de un proyecto Django completo y listo para funcionar en el entorno del laboratorio, incluyendo la base de datos con datos suficientes como para poder probarlo. Estos datos incluirán al menos cinco visitantes diferentes, cada uno con al menos 3 micronotas elegidas, y un total de al menos 50 micronotas en la base de datos de MiResumen2

Se incluirá también en el directorio que se entregue un fichero README con los siguientes datos:

\begin{itemize}
\item Nombre de la asignatura.
\item Nombre completo del alumno.
\item Nombre de su cuenta en el laboratorio.
\item Resumen de las peculiaridades que se quieran mencionar sobre lo implementado en la parte obligatoria.
\item Lista de funcionalidades opcionales que se hayan implementado, y breve descripción de cada una.
\end{itemize}

Es importante que estas normas se cumplan estrictamente, y de forma especial las que se refieren al nombre del directorio, porque la recogida de las prácticas, y parcialmente su prueba, se hará con herramientas automáticas.

[Las normas de entrega podrán incluir más detalles en el futuro, compruébalas antes de realizar la entrega.]


%%----------------------------------------------------------------------------
\subsubsection{Notas y comentarios}

La práctica deberá funcionar en el entorno GNU/Linux (Ubuntu) del laboratorio de la asignatura, con la versión 1.2.3 de Django.

La práctica deberá funcionar desde el navegador Firefox disponible en el laboratorio de la asignatura.

Se recomienda construir una o varias aplicaciones complementarias para probar la descarga y almacenamiento en base de datos del canal que alimentarán MiResumen.

Los canales (feeds) RSS que produce la aplicación web realizada en la práctica deberán funcionar al menos con el agregador Liferea y el que lleva integrado Firefox.

Se recomienda utilizar alguna extensión para Firefox que permita manipular cookies para poder probar la aplicación simulando varios visitantes desde el mismo navegador.

%%----------------------------------------------------------------------------
\subsubsection{Notas de ayuda}

A continuación, algunas notas que podrían ayudar a la realización de la práctica. Gracias a los alumnos que han contribuido a ellas, bien preguntando sobre algún problema que han encontrado, o incluso aportando directamente una solución correcta.

\begin{itemize}
\item \textbf{Conversión de fechas:}

La conversión de fechas, tal y como vienen en el formato de los canales RSS de Identi.ca, al formato de fechas datetime adecuado para almacenarlas en una tabla de la base de datos se puede hacer así:

\begin{verbatim}
from email.utils import parsedate
from datetime import datetime

dbDate = datetime(*(parsedate(rssDate)[:6]))
\end{verbatim}

El uso de ``*'' permite, en este caso, obtener una referencia a la tupla de siete elementos que contiene los parámetros que espera datetime() (que son siete parámetros).

Más información sobre parsedate() en la documentación del módulo email.utils de Python.

\item \textbf{Envío de hojas CSS:}

Para que el navegador interprete adecuadamente una hoja de estilo, puede ser conveniente fijar el tipo de contenidos de la respuesta HTTP en la que la aplicación la envía al navegador. En otras palabras, asegurar que cuando el navegador reciba la hoja CSS, le venga adecuadamente marcada como de tipo ``text/css'' (y no ``text/html'' o similar, que es como vendrá marcado normalmente lo que responda la aplicación).

En código, bastaría con poner la cabecera ``Content-Type'' adecuada al objeto que tiene la respuesta HTTP que devolverá la función que atiende a la URL para servir la hoja CSS (normalmente en \texttt{views.py}):

\begin{verbatim}
myResponse = HttpResponse(cssText)
myResponse['Content-Type'] = 'text/css'
return myResponse
\end{verbatim}

\end{itemize}