Wiki de EGC - Contribuciones del usuario [es]

Gestión de integración con redes sociales - 17 18 - G2

2018-02-04T16:07:55Z

Crigalbla: /* Mapa de herramientas */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en el lugar deseado de nuestra página web. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.1.0 v1.1.0]:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==
'''Lenguajes utilizados:''' PHP, HTML, CSS y JavaScript (jQuery).
'''Editor de código fuente:''' [https://notepad-plus-plus.org Notepad++] y [https://www.sublimetext.com Sublime Text].
'''Sistema de control de versiones:''' [https://git-scm.com Git].
'''Repositorio de código:''' [https://github.com GitHub].
'''Máquina virtual (con Docker y WordPress):''' [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian].

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>''' (opcional)

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==
Tanto la construcción como la integración continua se ha realizado con [https://travis-ci.org/ Travis CI]. Para ello, ha sido necesario configurar el [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] para poder instalar Docker y, a su vez, los servicios MySQL, WordPress y Apache. Travis CI está sincronizado con la rama master. Cada vez que se realiza un cambio en esta rama, se procede a iniciar la integración continua automáticamente.

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

Se realizaron al terminar todas las tareas relacionadas con un milestone. Éste está asociado a un release.

Tras unir todas las ramas de cada miembro con la rama develop y resolver los conflictos, si los hubiera, se procedía a subir el código fuente de la rama develop a la rama principal (master). Para ello, fue necesario realizar un pull request ([https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/25 ver ejemplo]), que debía ser aprobado por el coordinador. En éste se mencionaba los cambios de la nueva versión y el milestone al cual está asociado.

Todas las versiones del proyecto se encuentran en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases release de GitHub].

=== Gestión de despliegue ===

El despliegue se automatizó a través de [https://travis-ci.org/ Travis CI]. Para ello es necesario incluir un [https://docs.travis-ci.com/user/languages/php/ fichero de configuración] y sincronizar el proyecto con este servicio.

=== Gestión de entregas ===

La entrega se realizó a través de un ZIP que contiene el código fuente. Se realizaron dos versiones del producto software: v1.0.0 y v1.1.0. La documentación se entregó en formato wiki.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==
En cuanto a las herramientas usadas para este proyecto, se ha empleado una máquina virtual de Debian, esta posee el contenedor software Docker instalado para poder realizar las tareas necesarias. Por otro lado, tenemos una imagen instalada de WordPress en Docker, mediante la cual, se suben y pruebas los plugins del proyecto, lo que conlleva a una gestión de la integración con el sistema SPLC. Como gestor de base de datos nos encontramos con MySQL. Es necesario el uso del servidor HTTP Apache donde se ejecuta nuestro imagen de Wordpress.

Como lenguaje de programación se ha trabajado con PHP, empleando como herramientas de desarrollo Notepad++/Sublime Text, estos no son caracterizados como IDE (entornos de desarrollos integrados) pero para este proyecto que no necesita de muchas líneas de código y de gran complejidad, su fácil uso puede agilizar los procesos de instalación y programación. Para gestionar todo el código fuente se ha utilizado git, mas concrétamente un repositorio alojado en GitHub, el cual integra un sistema de control de versiones que facilita las adaptaciones.

Para la gestión de la integración continua, automatizar las pruebas y el despliegue, se ha empleado la herramienta Travis CI sincronizada con el repositorio de GitHub. Para estas pruebas se ha usado la versión 5.4 y 5.5 de PHP.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues creó un nuevo issue en GitHub con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado]; asignando a un responsable, un milestone y añadiéndolo al proyecto. Además, añadió tres etiquetas: Telegram, WhatsApp, task y new functionality (dado que se trataba de un cambio que añadía una funcionalidad). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# Para poder controlar la evolución de la nueva tarea, entró en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] e hizo clic en <code>+Add cards</code> para colocar la tarea en la columna '''To Do'''.
# El responsable de la nueva tarea, entró en el kanban de GitHub y colocó la tarea en la columna '''In progress''' cuando empezó con ella.
# En su repositorio local, creó una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accedió a la rama de desarrollo <code>git checkout develop</code>. Y después creó la rama y accedió a ella <code>git branch -b <nombreRama></code>.
# Implementó los cambios en la nueva rama. Para ello, añadió código en la función '''widget''' de la clase '''class-share-button-widget.php''' para crear los botones. Además, creó un formulario en la función '''form''' para poder cambiar el texto por defecto asociado al enlace a compartir. También añadió nuevas clases CSS para los estilos de los botones y una línea de código en la función '''update''' para persistir el texto introducido en el formulario: <code>$instance['telegramText'] = trim(strip_tags($new_instance['telegramText']));</code>.[[Archivo:Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png|600px|thumb|center|Código fuente de los botones para Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/2/20/Ejercicio-de-propuesta-de-cambio-Telegram-WhatsApp.png]] [[Archivo: Ejercicio-de-propuesta-de-cambio-Telegram.png|600px|thumb|center|Código fuente del formulario para Telegram|link=https://1984.lsi.us.es/wiki-egc/images/egc/a/aa/Ejercicio-de-propuesta-de-cambio-Telegram.png]]
# Por cada funcionalidad completada, realizó un commit. Además, escribió varios comentarios en el hilo del issue para explicar los cambios realizados. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356739335 Ver comentario del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15#issuecomment-356879957 ver comentario del botón de WhatsApp].[[Archivo: Share-button-widget.png|422px|thumb|center|Botones de Telegram y WhatsApp|link=https://1984.lsi.us.es/wiki-egc/images/egc/c/cc/Share-button-widget.png]]
# Para confirmar los cambios, primero preparó el fichero modificado para ser confirmado <code>git add <nombreFichero></code>. Luego realizó el commit <code>git commit</code>. Éste debía tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. A continuación, subió la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit del botón de Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit del botón de WhatsApp].
# Una vez completada la tarea, realizó un merge entre la nueva rama donde implementó la funcionalidad y la rama develop. Para ello, accedió a la rama de desarrollo <code>git checkout develop</code> e hizo el merge <code>git merge <nombreRama></code>. A continuación, subió el cambio al repositorio <code>git push origin develop</code>.
# Colocó la tarea en la columna '''Done''' en el kanban y cerró el issue.
# El encargado de la gestión de los issues realizó un '''pull request''' para hacer un merge entre la rama develop y master, que debía tener el visto bueno del coordinador. En esta petición se escribió un comentario con los cambios de la nueva versión (changelog). [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/pull/37 Ver pull request].
# Así, el cambio pasó a la rama principal y, por tanto, al estar sincronizado ésta con Travis CI, se procedió con la integración continua. Para ello, hay que tener configurado el fichero '''.travis.yml''', donde se indica el lenguaje de programación del proyecto (PHP), las versiones a utilizar y el software necesario a instalar: WordPress, MySQL, Apache y PHP Unit (para las pruebas).

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-14T18:59:04Z

Crigalbla: /* Gestión de liberaciones, despliegue y entregas */

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf Diario del grupo]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
El sistema heredado es la web del congreso SPLC 2017 que está montada con [https://es.wordpress.org WordPress], un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Además, WordPress es un software de código abierto que dispone de una API muy bien documentada y flexible. Ésta dispone de muchos métodos que facilitan la implementación y la integración de un plugin dentro de una web.

Para cumplir con el trabajo encomendado, el equipo de integración de redes sociales desarrolló un plugin, '''SocialHub by EGC''', desde cero, dado que se decidió no heredar código de otros plugins, ya que ninguno satisfacía las necesidades del subsistema. El objetivo de este plugin es integrar servicios como '''Twitter''', '''Facebook''', '''Google+''', '''LinkedIn''', '''Instagram''', '''Reddit''', '''Feedly''', '''Flipboard''', '''Telegram''' o '''WhatsApp'''. Esto permite que la página esté conectada estrechamente con las redes sociales más conocidas, para atraer visitantes y fomentar la interacción mutua. Para ello, el plugin dispone de seis widgets:

# '''Botones para compartir''' en cada red social el contenido deseado de la web.
# '''Caja de comentarios de Facebook''' para realizar un comentario en cualquier página de la web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
# '''Botones para seguir''' los perfiles sociales de la web.
# '''Línea de tiempo (timeline) de redes sociales''', es decir, una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter y Facebook.
# '''Botón RSS''' para generar un archivo XML para poder seguir las publicaciones de la web o conectar con una cuenta del agregador de noticias Feedly o Flipboard.
# '''Botón de mensaje directo''' que permite crearlo y enviarlo a una cuenta concreta de Twitter o establecer una conversación por Hangouts.

Además, cada widget de '''SocialHub by EGC''' tiene un formulario de configuración que permite cambiar las cuentas y otras opciones desde el back-end de WordPress.

Para poder probarlo en la web de forma local, se ha usado la máquina virtual [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing Debian] propuesta por el grupo de integración.

== Descripción del sistema ==
El plugin SocialHub by EGC está implementado en el mismo lenguaje que WordPress, es decir, en PHP. WordPress da cierta libertad para organizar la estructura de directorios y ficheros. Aunque la carpeta raíz del plugin debe llamarse igual que el fichero PHP principal. La estructura elegida para el plugin ha sido la siguiente.

📁socialhub-egc (carpeta raíz)
🗒socialhub-egc.php (PHP principal donde se hace uso de las APIs y se importan las clases de los widgets y los estilos)
📁css (carpeta que contiene el CSS que dará formato a los widgets)
🗒styles-socialhub.css
📁widgets (carpeta donde van las clases PHP que implementan cada widget)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php
📁img (carpeta que contiene imágenes para algunos widgets)

El fichero principal de SocialHub by EGC contiene una serie de métodos para importar el resto de archivos PHP (clases) que contienen los widgets. Para ello, hace uso de las funciones ''include_once'' y ''register_widget''. La primera importa el código fuente y la segunda agrega el widget al conjunto de la web. Además, también se cargan los estilos alojados en el directorio css en el front-end. Para ello, se usa la función ''wp_register_style'' y ''wp_enqueue_style''. Por último, se hace uso de las APIs necesarias embebiéndolas en el código HTML del front-end.

Al separar la implementación de los widgets del fichero principal, si se quisiera ampliar el plugin en un futuro, se podría trabajar en la implementación sin afectar al resto.

Como se ha mencionado anteriormente, cada una de las clases PHP se identifica con uno de los seis widgets, descritos en el apartado anterior. Estás clases heredan de la clase ''WP_Widget'' de WordPress. Esto es un requisito. Además, es necesario sobrescribir algunos métodos:

# '''__construct:''' el constructor al cual le indicamos el nombre, la descripción y el ID del widget.
# '''widget:''' en la cual debe ir todo el código HTML que se muestra en el front-end.
# '''update:''' necesario para persistir los datos del formulario cada vez que configuramos un widget.
# '''form:''' la cual es llamada para crear el formulario de configuración del widget.

Suponiendo que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en el lugar deseado de nuestra página web. Para ello, hay que acceder al back-end y entrar en la opción ''customize'' del menú. Una vez dentro, basta seleccionar el widget y arrastrarlo al lugar donde se quiera poner.

=== Cambios que se han desarrollado para el proyecto ===
Dado que no se heredó un plugin y, por tanto, se partió desde cero, se estipularon una serie de cambios a aplicar sobre la primera versión. Esos cambios fueron los siguientes.

# '''Widget para compartir contenido:''' se han añadido dos botones más para compartir contenido en Telegram y WhatsApp. Además, se ha añadido una opción en el formulario de configuración para añadir un remitente al tweet que genera el botón de compartir en Twitter.
# '''Widget para timelines:''' se ha mejorado la personalización de los mismos y se ha añadido la opción de listar los tweets por un hashtag en el formulario de configuración.
# '''Widget que integra una caja de comentarios:''' se ha añadido un botón para ocultar los comentarios y un shortcode para integrarlo dentro de un artículo. Además, se han añadido dos opciones en el formulario de configuración: configurar el número de mensajes por defecto y el color de fondo.
# '''Widget para RSS:''' se ha cambiado el diseño del icono RSS. Además, se han añadido dos botones para seguir un perfil: Feedly y Flipboard.
# '''Widget para mensajes directos:''' se ha añadido un botón para iniciar una conversación a través de Hangouts y se ha mejorado la estética del botón de mensaje directo de Twitter. Además, se ha añadido una opción en el formulario de configuración para introducir un mensaje por defecto.

== Planificación del proyecto ==
Se planificaron dos milestones, cada uno asociado a un entregable:
# '''[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/releases/tag/v1.0.0 v1.0.0]:''' es la primera versión del plugin, que contiene los seis widgets.
# '''v1.1.0:''' es la segunda versión del plugin, que incorpora nuevos cambios (descritos en el apartado anterior) e integración continua y automatización de las pruebas.

Para realizar estas entregas y dado que el equipo de desarrollo estaba formado por seis personas, se decidió dividir el trabajo por widget.

Widget para timelines -> Ruano Enríquez, Carlos
Widget para enviar un mensaje directo -> García Rodríguez, Luis Miguel
Widget para RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido -> Huerta Cebolla, Juan
Widget para seguir los perfiles -> Martínez Suarez, Daniel Jesús

Para consultar más información sobre la planificación del proyecto (fechas significativas, actas de reuniones y tareas), consulta el [https://1984.lsi.us.es/wiki-egc/images/egc/e/ef/Diario_del_grupo.pdf diario del grupo].

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar un issue interno ===
Se trabajó con el gestor de issues de GitHub. Para ello, un miembro del equipo fue el encargado de canalizar todos los issues que se registraban. Cuando se encontraba un error o surgía una petición de cambio, se siguieron los siguientes pasos:

# Se reportaba al encargado de los issues por los canales de comunicación del equipo o en las reuniones. Éste se encargaba de registrarlo con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado] y las [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Etiquetas_.28labels.29 etiquetas] que correspondían, que se explicarán a continuación. Además, asignaba a un responsable y un milestone.
# El responsable trabajaba en la incidencia. Si un commit estaba relacionado con el issue, se incluía en el pie del commit <code>Issue #<id de la incidencia></code>. También añadía comentarios al hilo del issue. Esto permitía seguir una traza de la evolución del mismo y las decisiones tomadas.
# Una vez completado el issue, el responsable se encargaba de cerrarlo escribiendo un comentario si fuera conveniente.

Si por error o por que se detectara que el issue aún no hubiera sido terminado, se reabría.

'''Ejemplos'''
# Incidencia relacionada con un bug en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/24 Ver ejemplo]
# Petición de cambio para añadir una nueva funcionalidad en un widget. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/26 Ver ejemplo]

=== Procedimiento para registrar un issue externo ===
En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargó de averiguar el protocolo a emplear.
Sin embargo, si en un issue interno se requería la intervención de un miembro externo del equipo, se realizaba un comentario dentro del hilo mencionando a dicho miembro. En este [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/11#issuecomment-355746062 enlace] hay un ejemplo de petición de ayuda al coordinador del equipo de integración.

=== Formato ===
Se siguió el formato propuesto por el equipo de integración con algunas modificaciones:

# '''Título:''' debía identificar el tipo de incidencia, ser descriptivo y breve.
# '''Prioridad:''' en función de la rapidez que debía ser atendida, se establecieron cuatro grados (urgente, alta, media y baja).
# '''Descripción:''' resumen sobre la incidencia. Éste debía ser muy explícito y podía contener referencias a otros issues o commits relacionados, e imágenes.

[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
# Etiquetas de tipo:
## ''' task:''' representa una tarea concreta necesaria para completar los entregables.
## ''' documentation:''' representa una tarea de documentación.
## '''enhancement:''' representa una tarea que mejora el código o una funcionalidad.
## '''new functionality:''' representa una tarea que implican una nueva funcionalidad en el sistema.
## '''bug:''' fallo encontrado en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el responsable.
## '''in progress:''' el responsable ya está trabajando en la misma.
## '''finished:''' ya ha sido resuelta.

Además, cada red social tiene su propia etiqueta y para las tareas marcadas con <code>task</code> no es obligatorio utilizar las etiquetas de estado. Éste se controlará a través del kanban de GitHub.

=== Tareas ===
Tanto las tareas (todos los issues marcados con la etiqueta <code>task</code>) como su asignación se acordaban en las reuniones. Para gestionarlas, se utilizó el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub]. La persona encargada de una tarea tenía que ir moviéndola por los diferentes estados: '''To Do''', '''In progress''' y '''Done'''. Además, debía añadir comentarios al hilo del issue que permitiera seguir una traza de la evolución de la misma y las decisiones tomadas.

[[Archivo:Kanban-GitHub.png|723px|thumb|center|Kanban|link=https://1984.lsi.us.es/wiki-egc/images/egc/4/49/Kanban-GitHub.png]]

== Gestión del código fuente ==
Para llevar un control del código fuente se utilizó [https://es.wikipedia.org/wiki/Git Git], concretamente la plataforma de desarrollo [https://es.wikipedia.org/wiki/GitHub GitHub]. Para ello, se creó un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales repositorio] dentro de la [https://github.com/EGC-G2-Trabajo-1718 organización] creada por el equipo de integración.

=== Commits ===
Cada vez que se completó una funcionalidad o se solucionó un error, se realizó un commit con un mensaje que siguió el formato propuesto por el equipo de integración con algunas modificaciones. Para ello, se procedió del siguiente modo.

'''git add <nombreFichero>''' (para agregar el fichero al índice)
'''git commit'''

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>''' (opcional)

'''git push origin <nombreRama>''' (para subir los cambios al repositorio de GitHub)

'''Ejemplos'''
# Commit de tipo "add". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/f08710be6eb61dc1a47f88604457c3b3ff1207df Ver ejemplo]
# Commit de tipo "fix". [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/9860566a175a6efcb328267600311bec286a6ca6 Ver ejemplo]

=== Ramas (branches) ===
Disponemos de varias [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/branches/all ramas]:
# Una rama por cada desarrollador, donde se implementó la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integró todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción por si hiciera falta.
# Una rama '''manual''' para documentación de ayuda.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas principales|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Para crear una rama basta con ir a la rama padre con <code>git checkout <ramaPadre></code> y, a continuación, escribir <code>git branch <ramaHija></code> para crearla.

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

=== Gestión de liberaciones ===

En cuanto a las liberaciones, son realizadas al terminar la funcionalidad completa de un plugin. La primera versión fue realizada tras unir todas las ramas de cada miembro con la rama develop. Si ha sido necesario se han resuelto los conflictos. Se asigna una versión al plugin y una vez hecho, cada rama de cada miembro es eliminada para más tarde crear ramas nuevas donde empezar una siguiente versión del plugin.

=== Gestión de despliegue ===

El equipo de integración obtendrá el código, cuando disponga de este, lo exportará a Debian. Para ello simplemente copiará el código en Debian y se asegurará de que el código copiado tiene los permisos necesarios (755 en linux). Posteriormente activará el plugin en la web, luego debe dirigirse a la pestaña customize donde seleccionará el lugar donde añadir el widget, finalmente solo debe de elegir el widget a desplegar rellenando su formulario si lo precisa.

=== Gestión de entregas ===

La entrega se realiza a través de un ".zip" que contendrá todos los ficheros realizados para la entrega. Se realizarán dos entregables: v1.0.0 y v1.1.0.

=== Política de nombrado e identificación de los entregables ===

Los entregables tendrán la siguiente nomenclatura: X.Y.Z

* X => Se utiliza para cambios importantes como cambios en la arquitectura.
* Y => Se utiliza para cambios menos importantes como nuevas funcionalidades.
* Z => Se utiliza para corrección de errores o mejoraras en el código que no impliquen un cambio de funcionalidad.

== Mapa de herramientas ==

Tenemos una máquina virtual con Debian configurado con Docker. En dicha máquina tenemos una carpeta compartida en la cual tenemos los ficheros para utilizar nuestro WordPress en local. MySQL, Docker y WordPress se integran con Apache. Se ha trabajado con PHP el cual se ha ido escribiendo el codigo tanto en Notepad++ y Sublime Text, dependiendo del miembro del equipo. Una vez que dichos ficheros en PHP se han probado en nuestro local, con la ayuda de git se comitea y se añade a GitHub a nuestro repositorio.

[[Archivo:mapaH.jpg|576px|thumb|center|Mapa de herramientas|link=https://1984.lsi.us.es/wiki-egc/images/egc/f/f6/MapaH.jpg]]

== Ejercicio de propuesta de cambio ==
A continuación, se mostrará un ejemplo real de un cambio realizado. Éste consistía en añadir dos botones más al widget para compartir contenido: Telegram y WhatsApp.

# El encargado de la gestión de los issues crea un nuevo issue en GitHub, con el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Formato formato adecuado], asignando a un responsable, un milestone y añadiéndola al proyecto. [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/issues/15 Ver issue].
# El responsable de la nueva tarea, entra en el [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 kanban de GitHub] y coloca la tarea en la columna '''In progress'''.
# Crea una rama con su nombre a partir de la rama develop donde desarrollar la nueva funcionalidad. Primero accede a la rama de desarrollo <code>git checkout develop</code>. Y después crea la rama <code>git branch -b <nombreRama></code>.
# Implementa los cambios en la nueva rama. Por cada funcionalidad completada, realiza un commit. Además, escribe un comentario en el hilo del issue. Para confirmar los cambios, primero prepara el fichero cambiado para ser confirmado <code>git add <nombreFichero></code>. Luego realiza el commit <code>git commit</code>. Éste debe tener el [https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_de_integraci%C3%B3n_con_redes_sociales_-_17_18_-_G2#Commits formato correcto]. Por último, sube la rama al repositorio de GitHub <code>git push origin <nombreRama></code>.[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/2eca7ca443600de4ba0812099648ae4b39849105 Ver commit botón Telegram] o [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/commit/3a0270f9945f5cf6dcab20add94b878ff05e802d ver commit botón WhatsApp].
# Una vez completada la tarea, realiza un merge entre la nueva rama donde se ha implementado la funcionalidad y la rama develop. Accede a la rama de desarrollo <code>git checkout develop</code> y hace el merge <code>git merge <nombreRama></code>. Por último, sube el cambio al repositorio <code>git push origin develop</code>.
# Coloca la tarea en la columna '''Done''' en el kanban y cierra el issue.
# Por último, el encargado de la gestión de los issues realiza un pull request para hacer un merge entre la rama develop y master, que debe tener el visto bueno del coordinador. Así, el cambio pasa a producción.

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T11:34:44Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T11:33:45Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T11:33:00Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T11:32:08Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T11:31:46Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T11:00:39Z

Crigalbla: /* Planificación del proyecto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T10:54:02Z

Crigalbla: /* Cambios que se han desarrollado para el proyecto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-13T10:53:09Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T17:35:08Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter y Reddit. Para ellos habrá 6 widgets, los cuales son mencionados en el siguiente apartado junto con el miembro del grupo encargado de diseñarlo. Dicho de otra forma, la principal funcionalidad es conseguir que la página esté conectada estrechamente con las redes sociales. Las funcionalidades elegidas son las siguientes:

'''Botones de compartir''', se trata de un widget que permite compartir en cada red social (si esta dispone de ello) el contenido deseado de la web.
'''Caja de comentarios de Facebook''', haciendo uso de la API de Facebook, esta caja nos permitirá comentar en cualquier página de nuestra web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
'''Botón de seguir''', botones de las diferentes redes sociales de la web para poder seguirlas con nuestras cuentas personales.
'''Linea de tiempo (timeline) de redes sociales''', una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter, Facebook, Instagram y Google+.
'''RSS''', botón que genera un archivo RSS para poder seguir las publicaciones de la web.
'''Mensajes directo en Twitter''', botón que permite crear y enviar un mensaje directo a una cuenta concreta de Twwiter.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en el lugar deseado de nuestra página web. Esto quiere decir que podemos añadir el widget x sin tan siquiera tener que introducir los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en el lugar deseado de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación mencionada brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T17:34:54Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter y Reddit. Para ellos habrá 6 widgets, los cuales son mencionados en el siguiente apartado junto con el miembro del grupo encargado de diseñarlo. Dicho de otra forma, la principal funcionalidad es conseguir que la página esté conectada estrechamente con las redes sociales. Las funcionalidades elegidas son las siguientes:

'''Botones de compartir''', se trata de un widget que permite compartir en cada red social (si esta dispone de ello) el contenido deseado de la web.
'''Caja de comentarios de Facebook''', haciendo uso de la API de Facebook, esta caja nos permitirá comentar en cualquier página de nuestra web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
'''Botón de seguir''', botones de las diferentes redes sociales de la web para poder seguirlas con nuestras cuentas personales.
'''Linea de tiempo (timeline) de redes sociales''', una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter, Facebook, Instagram y Google+.
'''RSS''', botón que genera un archivo RSS para poder seguir las publicaciones de la web.
'''Mensajes directo en Twitter''', botón que permite crear y enviar un mensaje directo a una cuenta concreta de Twwiter.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

= Descripción del sistema =
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en el lugar deseado de nuestra página web. Esto quiere decir que podemos añadir el widget x sin tan siquiera tener que introducir los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en el lugar deseado de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación mencionada brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T17:34:18Z

Crigalbla: /* Cambios que se han desarrollado para el proyecto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T17:29:15Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter y Reddit. Para ellos habrá 6 widgets, los cuales son mencionados en el siguiente apartado junto con el miembro del grupo encargado de diseñarlo. Dicho de otra forma, la principal funcionalidad es conseguir que la página esté conectada estrechamente con las redes sociales. Las funcionalidades elegidas son las siguientes:

'''Botones de compartir''', se trata de un widget que permite compartir en cada red social (si esta dispone de ello) el contenido deseado de la web.
'''Caja de comentarios de Facebook''', haciendo uso de la API de Facebook, esta caja nos permitirá comentar en cualquier página de nuestra web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
'''Botón de seguir''', botones de las diferentes redes sociales de la web para poder seguirlas con nuestras cuentas personales.
'''Linea de tiempo (timeline) de redes sociales''', una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter, Facebook, Instagram y Google+.
'''RSS''', botón que genera un archivo RSS para poder seguir las publicaciones de la web.
'''Mensajes directo en Twitter''', botón que permite crear y enviar un mensaje directo a una cuenta concreta de Twwiter.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en el lugar deseado de nuestra página web. Esto quiere decir que podemos añadir el widget x sin tan siquiera tener que introducir los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en el lugar deseado de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T17:25:29Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter y Reddit. Para ellos habrá 6 widgets, los cuales son mencionados en el siguiente apartado junto con el miembro del grupo encargado de diseñarlo. Dicho de otra forma, la principal funcionalidad es conseguir que la página esté conectada estrechamente con las redes sociales. Las funcionalidades elegidas son las siguientes:

'''Botones de compartir''', se trata de un widget que permite compartir en cada red social (si esta dispone de ello) el contenido deseado de la web.
'''Caja de comentarios de Facebook''', haciendo uso de la API de Facebook, esta caja nos permitirá comentar en cualquier página de nuestra web, permitiendo incluso reflejar esos comentarios en nuestro tablón.
'''Botón de seguir''', botones de las diferentes redes sociales de la web para poder seguirlas con nuestras cuentas personales.
'''Linea de tiempo (timeline) de redes sociales''', una secuencia de publicaciones ordenadas cronológicamente para las redes sociales Twitter, Facebook, Instagram y Google+.
'''RSS''', botón que genera un archivo RSS para poder seguir las publicaciones de la web.
'''Mensajes directo en Twitter''', botón que permite crear y enviar un mensaje directo a una cuenta concreta de Twwiter.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T14:21:51Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter y Reddit. Para ellos habrá 6 widgets, los cuales son mencionados en el siguiente apartado junto con el miembro del grupo encargado de diseñarlo. Dicho de otra forma, la principal funcionalidad es conseguir que la página esté conectada estrechamente con las redes sociales.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T14:21:34Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter y Reddit. Para ellos habrá 6 widgets, los cuales son mencionados en el siguiente apartado junto con el miembro del grupo encargado de diseñarlo. Dicho de otra forma, la principal funcionalidad es conseguir que la página esté conectada estrechamente con las redes sociales.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T14:15:54Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

El proyecto consistirá en desarrollar un plugin para WordPress desde cero, no se ha heredado/utilizado código de otros plugins ya que ninguno se adaptaba a las necesidades que se querían cubrir. El objetivo de este plugin es integrar las distintas redes sociales Google+, Facebook, Linkedln, Twitter == CONTINUAR ==

En cuanto al plugin, como ya se ha comentado anteriormente, contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código, todo en un único archivo .php.

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T11:59:35Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

En cuanto al plugin, como ya se ha comentado anteriormente, contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código, todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commits. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un [https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 tablero] de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T11:58:35Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con [https://es.wordpress.org WordPress] un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

En cuanto al plugin, como ya se ha comentado anteriormente, contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código, todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commits. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T11:56:50Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con WordPress un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

En cuanto al plugin, como ya se ha comentado anteriormente, contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código, todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commits. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T11:56:34Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con WordPress un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

En cuanto al plugin, como ya se ha comentado anteriormente, contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código, todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commits. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-12T11:36:41Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
<li>[https://codex.wordpress.org/WordPress_APIs WordPress API]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente por dos razones: no se fomenta la interacción con los usuarios, como compartir contenido o realizar comentarios; y no hay integración de los perfiles sociales, como mostrar un "timeline" con las últimas publicaciones realizadas. Tampoco mejora el posicionamiento de ésta en buscadores (SEO), ya que la integración de las redes sociales en una web es un factor clave para mejorar este aspecto.

Para solucionar este problema, se ha desarrollado un subsistema: un plugin para WordPress en el lenguaje PHP. Éste se llama '''SocialHub by EGC''' y tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles sociales, comentarios... Para ello, se han integrado varias redes sociales: Twitter, Facebook, Google+, LinkedIn, Reddit, Instagram... Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, la modularización del código fuente ha sido fácil, así como la integración de estos. Además, permite cambiar la funcionalidad de uno sin que esto afecte al resto.

== Introducción y contexto ==
La página web SPLC 2017 de la que dispone la asignatura está montada con WordPress un sistema de gestión de contenidos enfocado a la creación de cualquier tipo de página web. Para poder probar nuestro plugin en la web de forma local, se ha usado la máquina virtual Debian propuesta por el grupo de integración. En ella se copia el plugin y es probado.

En cuanto al plugin, como ya se ha comentado anteriormente, contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código, todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commits. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se comunicará al encargado de las incidencias. Éste se encargará de registrar la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación. Además, se asignará a un responsable.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==
La implementación del plugin no ha sido una tarea muy compleja, dado que tanto la API de WordPress como las de las redes sociales integradas es muy flexible. Además, la documentación es completa y tiene ejemplos.

Por otro lado, consideramos que es muy importante estudiar en profundidad un buen modelo para gestionar las ramas: crear sólo las ramas necesarias y, sobre todo, que éstas se adapten tanto al proyecto como al modo de trabajar del equipo. En nuestro caso esto no fue así. Esto originó que tuviéramos que cambiar el modelo con el proyecto ya empezado, lo que originó que se acumularan muchas tareas para los últimos días.

Por último, consideramos que el plugin '''SocialHub by EGC''' cumple con los aspectos más relevantes de cualquier integración con redes sociales. Sin embargo, consideramos que aún podría ser mejorado. Por ello, sugerimos una serie de mejoras para una próxima versión.

# Mejorar los estilos de los diferentes widgets: que todos utilicen el mismo color de fondo, que todos los botones tengan el mismo tamaño o que se pueda personalizar los estilos desde el formulario de configuración.
# Integrar más redes sociales como [https://www.pinterest.es Pinterest] o [https://www.flickr.com Flickr].
# Crear un manual de usuario que pueda ser consultado desde el back-end de WordPress.
# Publicar el plugin en el [https://es.wordpress.org/plugins repositorio de WordPress].

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:38:37Z

Crigalbla: /* Cambios que se han desarrollado para el proyecto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado siguiente de planificación del proyecto.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:37:45Z

Crigalbla: /* Planificación del proyecto */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
Se describe a continuación la planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en GitHub hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. De esta forma cada miembro del grupo tiene una rama con su nombre en la que trabaja de forma independiente al resto del equipo. Para crear esta rama debe partir de la rama develop donde se encuentra la plantilla del proyecto. En su nueva rama podrá realizar todos los commits necesarios para la creación de su widget. Una vez esté finalizado, deberá hacer merge con la rama develop donde se encontrará al final el plugin con todos los widgets.

La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:28:45Z

Crigalbla: /* Reuniones */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
La planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría y que no han tenido modificación en las tareas o gestión del proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:27:18Z

Crigalbla: /* Reuniones */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
La planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

Además de las descritas anteriormente, se han llevado a cabo pequeñas reuniones de diferente número integrantes del grupo para diferentes aclaraciones. En su mayoría por vídeo llamada. Todas ellas de importancia secundaría.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:24:31Z

Crigalbla: /* Reuniones */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
La planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''

Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''

Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''

Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el
Git Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro
del equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las
tareas y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master
siguen igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''

Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:21:58Z

Crigalbla: /* Reuniones */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
La planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''
Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.
Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''
Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''
Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el Git
Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro del
equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las tareas
y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master siguen
igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''
Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:17:50Z

Crigalbla: /* Reuniones */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
La planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''
Orden del día:

1. Establecer flujo de comunicación.

2. Decidir entorno de desarrollo.

3. Acordar una fecha para la siguiente reunión.

Descripciones:

1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.

2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)

3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''
Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''
Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el Git
Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro del
equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las tareas
y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master siguen
igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''
Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:17:04Z

Crigalbla: /* Reuniones */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
La planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''
Orden del día:

1. Establecer flujo de comunicación.

2. Decidir entorno de desarrollo.

3. Acordar una fecha para la siguiente reunión.

Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''
Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''
Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el Git
Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro del
equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las tareas
y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master siguen
igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''
Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:16:15Z

Crigalbla: /* Reuniones */

Gestión de integración con redes sociales
----
 

Grupo 2
----
 

ID de Opera: Grupo 4 (2017-2018)
----
 

Miembros
----
<ul style="font-size: 14px;">
<li>[https://github.com/crigalbla Galán Blanco, Cristian]</li>
<li>[https://github.com/luismiguelziuk García Rodríguez, Luis Miguel (coordinador)]</li>
<li>[https://github.com/albgomceb Gómez Ceballos, Alberto]</li>
<li>[https://github.com/juahueceb1 Huerta Cebolla, Juan]</li>
<li>[https://github.com/danmarsua1 Martínez Suarez, Daniel Jesús]</li>
<li>[https://github.com/ruano23 Ruano Enríquez, Carlos]</li>
</ul>
 

Enlaces de interés
----
<ul style="font-size: 14px;">
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales Repositorio de código (GitHub)]</li>
<li>[https://github.com/EGC-G2-Trabajo-1718/RedesSociales/projects/1 Gestor de tareas (kanban de GitHub)]</li>
</ul>
 

== Resumen ==
La web actual del congreso SPLC 2017 dispone de un plugin que permite configurar enlaces a perfiles en redes sociales. Esta utilidad es insuficiente, ya que no fomenta la interacción con los usuarios, como compartir contenido en redes sociales. Además, tampoco mejora la visibilidad de ésta en buscadores, ya que la integración de las redes sociales en una web fomenta su posicionamiento (SEO).

Para solucionar este problema, se ha desarrollado un subsistema (un plugin para WordPress) en el lenguaje PHP. Éste tiene seis widgets con diferentes funcionalidades: botones para compartir contenido, botones para seguir perfiles, comentarios… Para ello, se han integrado seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Cada widget es independiente, lo que permite ubicar cada uno en diferentes partes de la web o incluso omitir alguno si no es necesario.

Dado que cada widget del plugin es independiente, esto ha facilitado la modularización del código fuente, así como la integración de estos.

== Introducción y contexto ==
Como ya se ha comentado anteriormente, el plugin diseñado contiene diferentes widget y redes sociales. Se ha decidido dividir el trabajo por widget de forma que cada alumno realiza su parte de código todo en un único archivo .php. De esta forma se han creado las respectivas Issues para cada widget, en ellas cada alumno ha ido comentando y realizando sus commit. Si ha sido necesario se han abierto nuevas incidencias, como es el caso de la Issue #10 de la cual han salido 2 más. Una vez ha sido finalizado un widget este es subido, se ha cerrado su Issue.

Pasamos a ver la estructura del plugin final:

📁socialhub-egc (carpeta principal)
🗒socialhub-egc.php (.php principal donde se hace uso de las APIs)
📁widgets (carpeta) (aquí van las clases .php que diseñan cada widget, realizadas por cada alumno)
🗒class-share-button-widget.php
🗒class-comment-box-widget.php
🗒class-follow-button-widget.php
🗒class-timeline-widget.php
🗒class-RSS-widget.php
🗒class-message-button-widget.php

Anteriormente a la finalización del proyecto, en la carpeta widgets solo se encontraba la plantilla "class-message-button-widget.php" de la cual parten todos los widget mencionados.

Durante la realización de código, cada widget/alumno tenía su propia rama explicado en el apartado "Ramas (branches)" que tras su finalización se realizaba un merge con la rama develop.

Se ha realizado también un tablero de tareas (Kanban) en GitHub donde éstas iban siendo desplazadas según su progreso de una columna a otra.

== Descripción del sistema ==
Para explicar nuestro plugin nos pondremos en situación. Supongamos que ya está instalado en WordPress y activado. El siguiente paso sería añadir el widget deseado en la parte deseada de nuestra página web. Esto quiere decir que podemos añadir x widget sin tan siquiera tener que meter los datos del widget y (por ejemplo). Disfrutaríamos de la cantidad de widget deseada en la parte deseada de la página web, todos y cada uno de ellos totalmente independientes.
De esta forma además, si se quiere ampliar el plugin en un futuro, solo habría que acceder al .php correspondiente al widget, sin verse afectado el resto del plugin. Esto también implica la posibilidad de añadir nuevos widget al plugin con el simple hecho de añadir dos líneas de código al archivo socialhub-egc.php y añadiendo el nuevo .php (con el formato establecido por la plantilla "class-message-button-widget.php") donde se encontraría el nuevo código.

EL plugin no depende de ningún otro subsistema y tampoco ha sido necesario la interacción con alguno de ellos.

=== Cambios que se han desarrollado para el proyecto ===
Se realizó una primera planificación y reparto de tareas en la que los integrantes del grupo tenían la labor de realizar de forma individual, todo lo posible con una red social. Para añadir compañerismo y ayuda se propusieron grupos de 2 en los que se realizarían 2 redes sociales. De esta forma 2 personas pueden indagar y acabar antes un problema. Se comenzaron a realizar las Issues y a añadir código con un poco de descontrol, pero nos dimos cuenta que con este método de trabajo habría muchos conflictos en los merges (ya que todos trabajábamos sobre un mismo archivo). Se usó Trello como administrador de tareas y control de horas. Este sistema en general no funcionó bien y tras el milestone 3, tras el consejo del profesor Manuel Resinas, se cambió.
De esta forma se realizó un nuevo Workflow y redistribución de tareas, haciendo uso de la nueva planificación descrita brevemente en los anteriores apartados y que se explicará con mayor detalle en el apartado de planificación.

== Planificación del proyecto ==
La planificación usada durante el resto del proyecto y con la que se ha podido llevar a cabo todos los propósitos. En ella se decidió dividir el trabajo de los integrantes por widget, de esta forma en Github hay tantas tareas principales como widgets, es decir 6, además de las tareas secundarias y las tareas de la anterior planificación. La asignación de las tareas importantes ha sido la siguiente:

Widget para timelines -> Ruano Enríquez, Carlos
Widget para contactar a través de Twitter -> García Rodríguez, Luis Miguel (coordinador)
Widget para generar feed RSS -> Gómez Ceballos, Alberto
Widget para comentarios -> Galán Blanco, Cristian
Widget para compartir contenido en redes sociales -> Huerta Cebolla, Juan
Widget para seguir los perfiles en redes sociales -> Martínez Suarez, Daniel Jesús

Siendo así el resto tareas de menos importancia o de documentación.

=== Reuniones ===
A continuación se mencionan las reuniones principales que han sido necesarias por el grupo para la realización correcta del proyecto. En todas ellas no ha habido ausencia de miembros del equipo. Dichas reuniones han sido realizadas en presencia física:

'''Noviembre 15'''
Orden del día:
1. Establecer flujo de comunicación.
2. Decidir entorno de desarrollo.
3. Acordar una fecha para la siguiente reunión.

Descripciones:
1. Se ha creado un grupo de trabajo en la red social Telegram para la comunicación directa entre miembros del equipo.
2. Se ha decidido crear una máquina virtual con el sistema virtual Ubuntu. En ella se desplegará el sistema SPLC. Para ello será necesario la
instalación de un servidor tanto PHP y SQL. Podríamos cumplir este requisito con Xampp (Lampp en Ubuntu)
3. Se acuerda que la siguiente reunión tenga lugar el 27 de noviembre.

'''Noviembre 27'''
Orden del día:
1. Hacer una retrospectiva del Milestone 1.
2. Crear repositorio de código en GitHub.
3. Establecer un protocolo para la gestión de código.
4. Establecer un protocolo para la creación de incidencias.
5. Establecer un protocolo para la gestión de tareas.
6. Asignación de tareas.
7. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No sabemos cómo realizar la implementación de un plugin en WordPress. Para ello estudiaremos la API de WordPress.
2. Se ha creado un repositorio dentro de la organización que ha creado el equipo de integración.
3. Hemos acordado el formato de un commit y cuando se debería de hacer. Además hemos creado un Git Workflow.
4. Se ha acordado el formato de incidencias: Título, prioridad, descripción, estado, asignación, etiquetas y commit relacionados.
5. Hemos decidido crear un Kanban de Trello para gestionar las tareas y las horas de trabajo realizado.
6. Se han asignado a cada desarrollador una red social.
7. Se acuerda que la siguiente reunión tenga lugar el 22 de diciembre.

'''Diciembre 22'''
Orden del día:
1. Hacer una retrospectiva del Milestone 3.
2. Cambiar sistema de gestión de tareas.
3. Modificar el Git Workflow acordado hasta la fecha.
4. Redistribución de las tareas
5. Acordar una fecha para la siguiente reunión.

Descripciones:
1. No hemos gestionado de forma correcta el flujo de trabajo, mediante ramas, que se estableció. Por ello, se antoja necesario un cambio en el Git
Workflow. La distribución que existía en las ramas no correspondía con las funcionalidades que se requerían que implementasen cada miembro del
equipo.
2. Se cambia el sistema de gestión de tareas Trello por el que incorpora GitHub, dado que así es más fácil establecer una relación entre las tareas
y los commits. Todo esto ha sido decido gracias al profesor Manuel Resinas.
3. Se cambia las ramas actuales de cada red social por una rama independiente para cada desarrollador. Las ramas develop, hotfix y master siguen
igual.
4. Dado que se ha cambiado la gestión de ramas de GitHub, se ha acordado que cada desarrollador implemente un widget independiente del resto.
5. Se acuerda que la siguiente reunión tenga lugar el 8 de enero.

'''Enero 8'''
Orden del día:
1. Acordar fecha de publicación de la primera versión.
2. Aprobación de las tareas de documentación.
3. Nuevas asignaciones de tareas para la siguiente versión.

Descripciones:
1. Se ha establecido que el martes 9 de enero se subirá la primera versión del plugin.
2. Se han confirmado la asignación de tareas asociadas a la documentación del proyecto que previamente se acordaron por Telegram.
3. Se han formalizado las peticiones de cambio para la siguiente versión de proyecto.

== Entorno de desarrollo ==

== Gestión del cambio, incidencias y depuración ==

=== Procedimiento para registrar una incidencia interna ===
Se trabajará con el gestor de incidencias (issues) de GitHub. Para ello, un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:
# Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
# Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable y añadirá más etiquetas si fuera pertinente.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia, deberá incluir en el cuerpo del commit "Issue #<id de la incidencia>".

'''Nota:''' se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

=== Procedimiento para registrar una incidencia externa ===
Si se registrara una incidencia externa relacionada con el subsistema de redes sociales, cualquier miembro de la organización podrá publicar en el gestor de incidencias, siguiendo el mismo procedimiento que el mencionado en el apartado anterior.

En el caso de tener que reportar una incidencia externa al subsistema, el coordinador del grupo se encargará de averiguar el protocolo.

=== Formato ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.
[[Archivo:Issue-integracion-rrss.png|723px|thumb|center|Plantilla para issues|link=https://1984.lsi.us.es/wiki-egc/images/egc/1/10/Issue-integracion-rrss.png]]

=== Etiquetas (labels) ===
Existen diferentes tipos:
# Etiquetas de estado:
## '''pending:''' aún no ha sido atendida por el encargado de gestionar las incidencias.
## '''in progress:''' se ha asignado a un responsable para solucionar la incidencia.
## '''finished:''' ya ha sido resuelta.
# Etiquetas de tipo:
## '''enhancement:''' propuesta de mejora.
## '''bug:''' fallos encontrados en el sistema.
## '''help wanted:''' issue que puede ser resuelto por un miembro del equipo, pero que ha sido atendida previamente por otro.
## '''question:''' a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
## '''new functionality request:''' para solicitar formalmente una nueva funcionalidad en el sistema.
## '''duplicate:''' cuando el issue está duplicado. Se debe referenciar al issue original.
## '''invalid:''' cuando el issue no cumple con el formato propuesto.
## '''wontfix:''' cuando se ha decidido no darle una solución al issue por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

=== Tareas ===
Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que ésta pueda estar: TO DO, IN PROGRESS y DONE.

'''Nota:''' se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

== Gestión del código fuente ==

=== Commits ===
Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

'''<tipo>: <título del commit>'''
(espacio)
'''<cuerpo del commit>'''
(espacio)
'''Issue #<número de la incidencia/tarea en GitHub>'''

Ejemplo:
fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Issue #5

=== Ramas (branches) ===
Disponemos de nueve ramas:
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
# Una rama principal o '''master''' para los entregables.
# Una rama '''hotfix''' para errores detectados en producción.

[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

== Gestión de la construcción e integración continua ==

== Gestión de liberaciones, despliegue y entregas ==

Una vez obtenido el plugin realizado por todos los miembros del equipo de desarrollo y que este haya sido revisado por los mismos componentes, se liberará un .zip que contiene el plugin con el cual, el equipo de integración, podrá desplegarlo en WordPress a través de unos sencillos pasos. Para la realización de los pasos contamos con que el equipo de desarrollo tiene una carpeta compartida para la máquina virtual. Los pasos son los siguientes:

# Descomponer el .zip en la carpeta compartida.
# Copiar/Mover la carpeta a la siguiente ruta: egc/scripts/docker/wordpress/splc/wp-content/plugins/
# Una vez copiada la carpeta procedemos a otorgarle al plugin los permisos necesarios a través del siguiente comando (ejecutar comando desde la carpeta "plugins"): chmod -R 755 socialhub-egc
# Podemos comprobar que el comando ha funcionado ejecutando el comando ls -l y comprobando que la carpeta socialhub-egc tiene los siguientes permisos: drwxr-xr-x.
# Hasta este paso, tenemos el plugin importado a WordPress. Ahora tenemos que activar el plugin accediendo al apartado "Plugins" a través de la gestión de WordPress. Aquí podremos ver que aparece un nuevo plugin: Socialhub-egc. Lo activaremos para proceder a incorporarlo.
# Con el botón situado arriba a la izquierda (SPLC 2017) accedemos a la página web. Una vez dentro hacemos click en "Customize". Aparecerá un menú en la izquierda de la pantalla en la cual deberemos hacer click en "Widgets". Aquí deberá seleccionar en la posición en la que desea importar el Widget creado. Una vez seleccionada la zona, hacemos click en "Add widget", seleccionamos el widget proporcionado y lo configuramos.

FALTA: Política de nombrado e identificación de los entregables.

== Mapa de herramientas ==

== Ejercicio de propuesta de cambio ==

== Conclusiones y trabajo futuro ==

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:06:46Z

Crigalbla: /* Cambios que se han desarrollado para el proyecto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T10:06:21Z

Crigalbla: /* Cambios que se han desarrollado para el proyecto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-09T09:58:46Z

Crigalbla: /* Planificación del proyecto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-08T18:07:09Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-07T17:01:00Z

Crigalbla: /* Planificación del proyecto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-07T16:30:56Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-07T16:30:24Z

Crigalbla: /* Descripción del sistema */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-07T16:09:17Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-07T16:08:59Z

Crigalbla: /* Introducción y contexto */

Gestión de integración con redes sociales - 17 18 - G2

2018-01-07T16:08:20Z

Crigalbla: /* Introducción y contexto */