desarrollo de una aplicación web utilizando phpdeim.urv.cat/~pfc/docs/pfc1275/d1340023345.pdf ·...

23
1 Desarrollo de una aplicación web utilizando PHP TITULACIÓN: Ingeniería Técnica en Informática de Gestión Autor: Aleix Royo Obregón Tutor URV: M.Àngels Moncusí Tutor Empresa: Jordi Compte Fecha: Junio 2012

Upload: dinhxuyen

Post on 20-Sep-2018

212 views

Category:

Documents


0 download

TRANSCRIPT

1

Desarrollo de una aplicación web utilizando PHP

TITULACIÓN: Ingeniería Técnica en Informática de Gestión

Autor: Aleix Royo Obregón Tutor URV: M.Àngels Moncusí Tutor Empresa: Jordi Compte Fecha: Junio 2012

2

Agradecimientos

Agradecer tanto al jefe de la empresa como a los jefes de proyecto respectivamente el

apoyo y la confianza demostrada durante este tiempo y a mis compañeros de trabajo,

diseño y comercialización sin los cuáles no hubiéramos podido llegar tan lejos.

3

Índice

1. Descripción de la empresa ..................................................................... 4

2. Ubicación del proyectante dentro de la empresa ................................... 5

3. Descripción del trabajo realizado ........................................................... 7

3.1. Objetivos del proyecto ..................................................................... 7

3.2. Especificaciones del proyecto .......................................................... 7

3.3. Diseño .............................................................................................. 8

3.4. Desarrollo ........................................................................................ 9

3.5. Evaluación ...................................................................................... 17

3.6. Recursos utilizados ......................................................................... 19

4. Aportaciones del proyecto a los conocimientos del alumno ................. 20

5. Aportaciones de los estudios realizados al proyecto ............................ 21

6. Conclusiones ........................................................................................ 22

4

1. Descripción de la empresa

SMARTOXIDE, SL nace en el 2008 con la idea de que se puedan generar productos de

calidad de base tecnológica dentro de nuestro territorio y con el objetivo de ser una

puerta más para todos los ingenieros en el sector de la informática y la electrónica.

Como sectores importantes dónde se desarrollan productos y se ofrecen servicios hay

la telefonía móvil, la domótica en distintos ámbitos, las soluciones Linux, el diseño de

hardware y la consultora general. Esta iniciativa empresarial mereció el primer premio

del “Concurs Tàrraco Empresa Jove 2007” y fue finalista en los” IV Premis Reus a la

Creació d’Empreses 2007”.

En los últimos meses ha surgido de ella “IgnicioLabs”, cuya finalidad es la de actuar

como acelerador de negocios entre el talento universitario y los empresarios

proporcionando un espacio de trabajo en equipo para diferentes colaboradores del

sectores fomentando de esta forma la colaboración y el trabajo en equipo.

“IgnicioLabs” se ha creado a principios del 2012 y somos los primeros universitarios en

formar parte de la empresa.

5

2. Ubicación del proyectante dentro de la empresa

A mediados de Octubre del año pasado comencé a trabajar de becario en la empresa

“SmartOxide”, puesto que tendría que en principio tendría que ocupar hasta finales de

febrero de este año.

Después de una entrevista inicial por teléfono con Jordi Compte, jefe de proyecto y

cofundador de “SmartOxide”, decidí que su empresa podía ser un buen lugar para

acabar el proyecto de final de carrera dado que mi intención era la de hacer una

aplicación web con PHP y era lo que ellos estaban buscando.

El primer día en la oficina conocí a Eusebi que sería mi compañero de trabajo durante

los próximos meses y a los demás colaboradores que estaban trabajando en el otro

proyecto de la empresa.

El proyecto que ambos teníamos que realizar conjuntamente se puede dividir en dos

partes bien diferenciadas. Por un lado una aplicación web con base de datos colgada

en el servidor capaz de generar códigos Quick Response (Q.R.) y por el otro, una

aplicación para terminales móviles que utilizaría un “framework” llamado “Phonegap”,

el cual permite realizar aplicaciones multiplataforma sin tener que trabajar con los

lenguajes nativos del terminal como pueden ser “Java” para “Android” u “Objective C”

para “iOs”.

Fue en este momento en el que ambos nos pusimos de acuerdo que Eusebi realizaría

la aplicación móvil y yo me encargaría de la aplicación web y de gestionar la base de

datos.

Lo primero que hice el primer día de trabajo fue formatear el ordenador e instalar todo

el entorno de trabajo que en un principio iba a necesitar (“NetBeans IDE 7.1.1”,”

Xampp Version 2.5”, “Mozilla Firefox”, “Google Chrome”).

A partir del segundo día fui completando las tareas que se me iban asignando

mediante “google docs” y que básicamente consistían en búsqueda de las mejores y

6

más perdurables librerías que podíamos necesitar para evitar los odiosos

“deprecateds” como sucedió en su día con la versión 2.0 de “google maps”.

De este modo las primeras semanas recibía información constantemente tanto de la

finalidad del proyecto como de las funcionalidades que se iban a necesitar con lo que

fui estructurando toda esta información a modo de clases buscando así integrar los

conceptos de la programación orientada a objetos que había ido entendiendo durante

la carrera.

Los coordinadores de los proyectos iban realizando controles periódicos del estado de

la aplicación de igual modo que iban aportando nuevas tareas las cuáles se nos

notificaban a base de reuniones internas, motivo que permitió una rápida integración

en la empresa.

7

3. Descripción del trabajo realizado

3.1 Objetivos del proyecto

Hacer una aplicación web con base de datos para comercios y usuarios mediante PHP

que sea capaz de generar códigos Quick Response (QR) y geo localizarlos.

3.2 Especificaciones del proyecto

Para desarrollar la aplicación se han llevado a cabo las siguientes especificaciones:

Incorporar un generador de códigos QR para generar nuestros propios códigos

e incorporarlos a nuestro sistema.

Geo localización automática de nuestros códigos QR en un mapa.

Generación de diferentes modelos de QR con sus funcionalidades específicas

para segmentar la comercialización (QR Favorito, QR Postal, QR Queja).

Generar fichas de los comercios de manera automática en función a unos

modelos genéricos de comercios y la información introducida al sistema por los

mismos.

Acceso al sistema independiente para los comercios con funcionalidades de

contacto en tiempo real con sus posibles clientes.

Funcionalidades de acceso, privacidad e histórico de su paso por nuestro

sistema para nuestros usuarios.

8

3.3 Diseño

Una vez comprendidas las especificaciones del proyecto quedó patente que tendría

total libertad para estructurar el mismo siguiendo mis propios criterios. En este

momento decidí que lo ideal sería seguir el patrón Modelo Vista Controlador siguiendo

la arquitectura del modelo Cliente/Servidor.

El primer paso fue plasmar un diseño de clases en papel que reflejaría a su vez las

tablas a generar en la base de datos y el conjunto de clases a generar en PHP.

Todas las clases han sido identificadas siempre con identificadores únicos y con fechas

de inicialización ya que resulta mucho más seguro y eficiente trabajar con

identificadores de tipo “BigInt” y no con cualquier tipo de datos.

De igual modo, fui implementando los atributos específicos de cada una de ellas, el

correspondiente constructor y el conjunto de “getter’s” y “setter’s” básico para poder

modificar y consultar los atributos de los objetos una vez instanciados.

A su vez el número de las tablas de la base de datos iba aumentando paralelamente

con la incorporación de nuevas clases siguiendo la correspondencia lógica entre

campos y atributos.

Dada que se necesitaba un conjunto básico de funcionalidades por clase que pudieran

acceder a la base de datos (“insert”, “select”, “update”, “delete”), fui implementando

nuevos métodos que incorporasen sentencias en SQL y que de manera genérica

accediesen a la misma separando por un lado, la información que se inserta o consulta

de la información básica de acceso a la misma.

Las reuniones de empresa comenzaban a producirse periódicamente y con cada una

de ellas se incorporaban nuevas ideas a raíz de las cuáles la idea inicial del proyecto

comenzaba a evolucionar, lo que hizo que cada vez me sintiera más integrado en la

empresa.

9

3.4 Desarrollo

Durante el principio de la fase de desarrollo he trabajado en local. Para ello he

utilizado la versión 2.5 de la “Xampp” programando con el entorno de desarrollo de

“NetBeans” en su versión 7.1.1. para “PHP”.

He seguido el modelo Cliente/Servidor, el cuál explicaré ahora, combinándolo a su vez

con la esencia del patrón Modelo Vista Controlador y manteniendo en todo momento

una separación entre la vista y el control de la información:

Modelo Cliente/Servidor:

El modelo Cliente/Servidor se puede definir como una arquitectura distribuida que

permite a los usuarios finales obtener acceso a la información de forma transparente

aún en entornos multiplataforma.

En él, el cliente envía un mensaje solicitando un determinado servicio a un servidor y

este envía uno o varios mensajes con la respuesta.

Veamos ahora más específicamente cuáles son sus roles:

Cliente:

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos

al servidor.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

• Administrar la interfaz de usuario.

• Interactuar con el usuario.

• Procesar la lógica de la aplicación y hacer validaciones locales.

• Generar requerimientos de bases de datos.

• Recibir resultados del servidor.

• Formatear resultados

10

Servidor:

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún

recurso administrado por él. El servidor normalmente maneja todas las funciones

relacionadas con la mayoría de las reglas del negocio y los recursos de datos.

Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes

puntos:

• Aceptar los requerimientos de bases de datos que hacen los clientes.

• Procesar requerimientos de bases de datos.

• Formatear datos para trasmitirlos a los clientes.

• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de

datos.

Durante este proceso tuve que crear una base de datos con su nombre de usuario y

contraseña de manera que se consulta su información cada vez que se ejecuta una

consulta a la misma.

Dado el grado de repetitividad de algunas de las consultas opte por generar clases en

las que determinadas consultas se llaman a medio de métodos. De esta forma, la

aplicación es más genérica y no se repite el mismo código de una anterior consulta.

Así, poco a poco, fui generando una pequeña API de clases con sus métodos

particulares de cada una, siguiendo el patrón Modelo Vista Controlador, el cuál

explicaré ahora:

Patrón Modelo Vista Controlador (MVC):

El Patrón MVC, es una arquitectura de Software que define la separación de los datos

que conforman la vista de la lógica de una aplicación.

Esto se hace con la finalidad de que cada una de las partes de una aplicación solo

realice lo que está en su responsabilidad, además de que le da mayor entendimiento a

nuestros desarrollos y los hace más fácil de mantener, ya que la parte del diseño solo

tiene la cantidad de código de programación que necesita al igual que en la parte que

11

conforma nuestro código del negocio solo se va a encontrar lógica de programación en

el lenguaje que estemos trabajando (PHP en nuestro caso).

De este modo, lo que este patrón desea evitar es que el un código de inserción de un

registro se encuentre junto con la vista en un mismo archivo, algo nada recomendable,

ya que puede provocar fallos de seguridad.

Veamos ahora más específicamente cuál es el rol de cada uno de los elementos del

patrón:

Vista:

La vista como su nombre lo indica es la parte visual, lo que el usuario final visualizara

en su aplicación. Es la que comunica al usuario lo que quiere ver, esta tiene acceso

directo al modelo y es esta la que transmite los datos a la aplicación para hacer el

proceso que necesitemos.

Modelo:

El modelo es el lugar donde se encuentra la lógica del sistema de almacenamiento de

nuestro producto y es ahí donde se procesan todos los datos provenientes de la vista.

Controlador:

Finalmente, el controlador es el encargado de hacer la conexión entre la parte visual y

la lógica del modelo, este se encarga de pasar los datos de la vista hacia el modelo

cargando la información correspondiente según la respuesta que este le entregue.

12

Una vez definido el método de trabajo, ahora explicaré las características básicas de la

base de datos:

Está formada por más de una treintena de relaciones, el tipo de motor de la misma es

“InnoDB” y el cotejamiento, tanto para las tablas como para sus conexiones “MySQL”

es “utf8_unicode_ci”.

Al generar la base de datos, basándome en una de las premisas que tendría que

soportar nuestro sistema en algunos de sus registros, la concurrencia, decidí que era

mejor utilizar el motor “InnoDB” y no el “MyISAM” por los siguientes motivos:

Al contrario de “MyISAM”, “InnoDB” tiene capacidad de ejecutar transacciones

de tipo ACID cuyas siglas en ingles significan Atomicity, Consistency, Isolation

and Durability, es decir, Atomicidad (es la propiedad que asegura que la

operación se ha realizado o no, y por lo tanto ante un fallo del sistema no

puede quedar a medias), Consistencia (es la propiedad que asegura que sólo se

empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas

operaciones que no van a romper las reglas y directrices de integridad de la

base de datos), Aislamiento (es la propiedad que asegura que una operación no

puede afectar a otras. Esto asegura que la realización de dos transacciones

sobre la misma información sean independientes y no generen ningún tipo de

error) y Durabilidad (es la propiedad que asegura que una vez realizada la

operación, ésta persistirá y no se podrá deshacer aunque falle el sistema).

“InnoDB” permite mantener la integridad referencial, de esta manera se

pueden definir llaves foráneas entre tablas “InnoDB” relacionadas para

asegurarse de que un registro no puede ser eliminado de una tabla si aún está

siendo referenciado por otra.

A su vez, “InnoDB” permite el bloqueo de registros a nivel de filas. Con

“MyISAM”, al tener que ejecutar consultas muy grandes que requieren de

mucho tiempo, simplemente no se podían ejecutar más consultas hasta que

terminaran las consultas que estaban en ejecución. En cambio, las tablas

“InnoDB” usan bloqueo a nivel de filas. Con esto consiguen mejorar el

rendimiento en casos como que una lectura esté siendo bloqueada por otra

consulta que está haciendo cambios en la misma tabla, facilitando de este

modo la concurrencia.

13

Pese a la menor velocidad de codificación del cotejamiento “utf8_unicode_ci” frente al

“utf8_general_ci”, decidí utilizar el primero dado su mayor grado de precisión ya que,

en un futuro, iba a ser necesario almacenar información en otros idiomas como el

alemán que requieren del cotejamiento “utf8_unicode_ci” para evitar errores durante

el proceso de codificación/decodificación.

También he utilizado claves primarias a modo de identificadores comprobando en

todo momento la coherencia de los datos. De igual modo he controlado que no se

hicieran nuevas inserciones en caso de repetición de ciertos campos.

Respecto a la interficie de la aplicación he de decir que partiendo de las

especificaciones del proyecto, dadas desde un principio por los coordinadores del

mismo (Jordi y Carlos) y el jefe de la empresa (Armand), yo he decidido en todo

momento la manera en que se iban a hacer todas las peticiones al servidor junto con

los parámetros que se iban a recibir (el paso de parámetros siempre es por POST) y

que se han de retornar a cada instante.

De igual modo, he decidido en todo lo referente al control de la información tratando

independientemente en función al tipo de datos que han de ser tratados.

Decidí utilizar sesiones las cuáles, al igual que son creadas, son destruidas llegado el

momento oportuno.

He implementado la subida de imágenes al servidor. Estas se limitan por su formato y

se transforman automáticamente y de forma transparente para el usuario en función

del peso que se quiere almacenar en el mismo. De este modo no tan sólo existe un

control de la información sino que, posibles problemas para un usuario poco avanzado,

como puede ser bajar el peso de una imagen, se hacen totalmente transparentes.

De igual modo, he implementado la descarga de imágenes desde el servidor.

14

En lo que a la interficie gráfica se refiere, he trabajado conjuntamente tanto con los

jefes de empresa y de proyecto, como con el equipo de diseño gráfico (Gerard y Jose).

He tenido la oportunidad de compartir opinión con ellos a modo de “brainstorming” y

he sido el encargado de estructurar tanto la información que aparecería en los

“header’s” como los “bodies” como los enlaces que comportan.

He de decir que el diseño de los iconos y en general, el diseño gráfico puro

(“PhotoShop”, “FreeHand”, etc) ha sido trabajo de los diseñadores gráficos pero sin

embargo, si ha sido competencia mía, generar los ficheros correspondientes de estilo

en los que quedan definidos los patrones con los que se muestran los diferentes

elementos que aparecen en pantalla y la manera en la que se interactúa con ellos.

Para ello, utilizo “html” como lenguaje de navegador, junto con “css” para definir el

estilo de las vistas.

Para el acceso de los comercios, decidí que lo más innovador era integrar un

“fancybox” el cuál se abre sobre un fondo más oscuro al clicar sobre el icono de

registro y que, a su vez, tiene un formulario de acceso implementado internamente.

Esto comporta el uso de “Javascript” o “jQuery” para el control de la información y de

PHP para el paso de parámetros el cuál siempre se hace por $_POST evitando así que

la información aparezca en la barra del navegador y haciendo de este modo más

seguras las transferencias de información.

En lo que a desarrollo se refiere, el siguiente paso fue integrar un generador de

códigos QR el cuál, no solo tuve que integrar sino que, dada la especificación del

proyecto, también lo tuve que modificar previamente para que permitiera generar los

tipos de QR ya nombrados (Favorito, Postal, Queja).

Para ello, tuve que decidir cómo se generarían los QR’s y el modelo a seguir para

identificarlos generando de este modo el sistema con la información que contendrían

en sí, al escanearlos con nuestra aplicación.

15

Dado que una gran parte de la aplicación debe ir sincronizada también con la “app”

para terminales móviles, ya que debe poder hacer peticiones al servidor para enviar y

recibir información de la base de datos y al hecho, que la conexión ha de hacerse a

través de un servidor que este en Internet y no en local, se hizo patente la necesidad

de coger un dominio gratuito capaz de soportar “PHP” para los ficheros y “MySQL”

para la base de datos.

Tras valorar una serie de críticas, mi compañero y yo decidimos que subir la

información a “000webhost.com” era la mejor opción debido principalmente a que es

gratis y actualmente trabaja con la última versión de PHP, la 5.2.

Por política de empresa los detalles más internos en lo que a código fuente,

funcionalidad o casos de uso se refiere no pueden ser desvelados públicamente,

motivo por el cuál continuaré a modo de memoria este apartado.

A partir de este momento y dada la imposibilidad de utilizar el “000webhost” a modo

de repositorio, me descargue el programa “FileZilla” para conectar con el servidor y

sincronice la edición de los archivos que estaban colgados en el “hosting” con mi

“NetBeans” diciéndole a su vez que almacenara copia en el “htdocs” de mi propia

“Xampp” en local.

De este modo conseguí evitar el tener que estar subiendo archivos al servidor cada vez

que modificaba información en local y a la inversa.

Con la nueva adhesión de miembros al grupo (Luis y Rubén) se hizo necesaria la

coordinación y gestión más cercana de las tareas, responsabilidad que llevo ejerciendo

como coordinador del proyecto desde hace ya tres meses a través del repositorio

asociado a codebasehq.com

Con esta herramienta se puede crear un proyecto (con su repositorio asociado), añadir

y modificar permisos a nuevos miembros del proyecto, añadir tareas y asignarlas a

determinados miembros, o generar puntos de control a modo de “milestones” para

seguir una evolución y un porcentaje del total del trabajo que queda para finalizar el

mismo.

16

Esto me permite seguir en tiempo real el transcurso de los acontecimientos al igual

que de los “commits” realizados a través de la asociación que tengo creada entre el

mismo “codebase” y mi cuenta de correo electrónico del trabajo.

Por este motivo, decidí instalarme el entorno de desarrollo de “Eclipse Enterprise

Edition” (EE) para desarrolladores web, junto con el “Android Standard Development

Kit”(SDK) y el ”plug-in” de “Phonegap”.

Al no disponer de un “smartphone” propio comencé a utilizar el emulador de

“Android” que se instala con el SDK pero dada la lentitud del mismo y el elevado

consumo de recursos del ordenador Armand (jefe de la empresa) compró uno.

El modelo con el que trabajo es un “Samsung Galaxy Young GT-S5360” con la versión

de sistema operativo 2.3.6 de “Android” versión depurada de la 2.3.3 “Gingerbread” y

pese a tener unas dimensiones más pequeñas que las de sus hermanos mayores, es

francamente un lujo poder utilizarlo para el desarrollo de aplicaciones móviles.

Para el intercambio de información tanto con el repositorio de la aplicación web como

con el de la aplicación móvil utilizo “Subversion”.

He utilizado el inspector de elementos de “Google Chrome” durante el desarrollo, no

tan sólo para el control en tiempo real de la aplicación, sino también, para acabar de

definir las características para el estilo o vista (CSS), ya que te permite realizar cambios

en el propio navegador y luego aplicarlos al documento con los estilos de los diferentes

elementos.

17

3.5 Evaluación

Conforme el proyecto fue adquiriendo forma y permitía realizar a través de él las

primeras consultas a la base de datos, he ido siguiendo una serie de mecanismos de

control de la información que se almacena en el servidor en cuanto a veracidad y

coherencia.

He realizado este control por medio de lenguajes como “Javascript” y “jQuery” de

manera que, cuando el usuario clique sobre un botón, se ejecuten asociados ciertos

mecanismos de control de los cuáles describiré los más sencillos brevemente:

Suponiendo el caso de un campo de una tabla de la base de datos cuyo tipo sea

un “varchar” de 50 caracteres y al cuál no queramos que entren valores igual a

7, por un lado, el número máximo de caracteres que se asociarán a su input

será de 50 y a su vez, dado que puede ser cualquier tipo de carácter menos el 7,

se le aplicarán dos restricciones a modo de condicionantes diciendo que, la

longitud del valor asociado al input ha de ser menor o igual que 50 y diferente

de 7.

Suponiendo el caso de un campo de una tabla de la base de datos cuyo tipo sea

un “int” de 4 caracteres y al cuál no queramos que entren valores menores que

5000, por un lado, el número máximo de caracteres que se asociarán a su input

será de 4 y a su vez, se le aplicarán dos restricciones a modo de condicionantes

diciendo que, la longitud del valor asociado al input ha de ser menor o igual

que 4 y que, el valor tratado ha de estar en un rango de entre 5000 y 9999.

En el caso de que los datos a introducir sean contraseñas, he seguido un proceso de

encriptación al tratar el valor introducido por el usuario y le he asignado un tipo

“password” y no “text” para, de este modo, no se vea al escribir el usuario.

También he comprobado que, en caso de errores en el momento del “login” no se

muestren errores del tipo “Su email no es correcto” o “Su contraseña no es correcta”

dado que un posible intruso, experimentado, si sólo recibiera un mensaje, sabría que

en la opción que no ha aparecido ha acertado.

18

Por este motivo los mensajes que se envían son siempre del tipo “ERROR: Su email o

su contraseña no son válidos”.

Por otro lado, los botones se bloquean tras su primera pulsación. De este modo dejan

de estar funcionales, como mínimo hasta que reciben la información de la petición y se

reflejan sus resultados para, de este modo, no permitir que se puedan seguir enviando

nuevas peticiones clicando repetidas veces en el tiempo que tarda en producirse la

transferencia lo cual podría provocar una sobrecarga del servidor de hacerse desde

“malas manos”.

Para “debugar” las transferencias de información entre la aplicación y el servidor, he

utilizado el inspector de elementos del “Google Chrome”, controlando así, la correcta

recepción de los parámetros, los cuáles son encriptados si así es necesario.

He utilizado su inspector de elementos dado que es una herramienta capaz de detectar

el resultado, hasta incluso, en caso que las peticiones que se realizan al servidor sean

por “Ajax”.

He hecho pruebas periódicas con las últimas versiones de “Mozilla Firefox” y “Safari”.

He “debugado” ciertas consultas directamente en la misma base de datos a través de

la opción “SQL” del “phpMyAdmin”, verificando de este modo la información que se

obtenía de las mismas antes de plasmarla en el proyecto.

Principalmente, en determinados casos más complejos, en los que eran necesarias

consultas múltiples, asegurándome de este modo de que la consulta no provocaría un

error.

También he utilizado el “phpMyAdmin” en el caso de ciertas consultas en las cuáles,

debido a que se pueden hacer de varias formas, dudaba.

Para ello, evalúo el rendimiento de las mismas desde el mismo servidor, dado que

valorar una petición desde un navegador no tiene porque darnos una respuesta fiable,

puesto que dependemos de demasiados parámetros relacionados ya en menor grado

con la eficiencia de la consulta pero sí, sin embargo, en mucho mayor grado, con la

conexión de la que dispongamos y su ancho de banda.

19

Estos son algunos ejemplos de tiempos de carga al realizar peticiones al servidor:

Petición al servidor 1 Petición al servidor 2

Conecting 151 ms 154 ms 153 ms 0 0 0

Sending 1 ms 0 0 0 0 0

Waiting 902 ms 1,04 s 1,01 s 889 ms 857 ms 940 ms

Receiving 650 ms 671 ms 315 ms 153 ms 151 ms 111 ms

Total 1,70 s 1,87 s 1,48 s 1,04 s 1,01 s 1,05 s

Como se puede ver, en ambas peticiones, los tiempos de espera se mantienen estables

y dentro de la media siendo el tiempo de recepción (ver petición 1), el cual depende de

otros parámetros relacionados con la conexión a Internet, el principal causante de

aumentar el tiempo total, principalmente en el primer caso,

3.6 Recursos utilizados

Generador libre de códigos QR.

API PHP (http://php.net/manual/en/)

API v3 Google maps (https://developers.google.com/maps/documentation/)

Páginas webs como: http://www.cristalab.com/tutoriales/

http://www.w3schools.com/

http://www.lawebdelprogramador.com/foros/PHP/index1.html

Más.

20

4. Aportaciones del proyecto a los conocimientos del alumno Durante el tiempo que llevo en el proyecto he adquirido una mayor experiencia en

lenguajes de programación como PHP y SQL trabajando siempre en un entorno de

trabajo innovador y haciendo frente día a día a los nuevos retos que surgían.

A resultas de este tiempo, he conseguido practicar la arquitectura cliente/servidor a

medida que iba avanzando el proyecto.

A parte de ello, he adquirido mayor experiencia a la hora de gestionar las tareas y los

tiempos de entrega coordinando estos últimos tres meses los recursos como “Project

Manager”.

He tenido que crear y gestionar repositorios y crear cuentas en varios servidores de

Internet, subiendo así toda la estructura de carpetas del proyecto, al igual que su base

de datos.

Durante este tiempo he debatido y aportado ideas, algunas de las cuales siguen aún en

proceso de desarrollo.

He de decir que día a día estoy aprendiendo en campos no tan sólo relacionados con la

técnica sino más relacionados con la buena comunicación con los miembros de la

empresa, mirando de hacerles participe de lo que están haciendo, valorando sus ideas

y motivándoles para seguir en la dirección correcta.

21

5. Aportaciones de los estudios realizados al proyecto He de decir que pese a que del total de los lenguajes utilizados tan sólo había

trabajado con SQL en la carrera, asignaturas como Lenguajes de Programación (L.P.) y

Sistemas Abiertos (S.O.) han sido claves para entender los principios seguidos durante

el desarrollo del proyecto.

Sin los conocimientos aprendidos en L.P. no hubiera sido capaz de generar todo el

sistema de clases a modo de API accediendo e implementando en ellas nuevas

funcionalidades conforme los requisitos del proyecto lo iban necesitando.

De igual modo, al cursar S.O. pude apreciar la diferencia entre los lenguajes

mostrativos de navegador como “html” y los lenguajes de programación de servidores

como es el caso de PHP, así pude aprender el Modelo Cliente/servidor o el Patrón

Modelo Vista Controlador en el que se separa la vista de la información y se accede a

ella por medio de un conjunto de funcionalidades. De hecho conceptos tan básicos

como el de formulario (form) o el de paso de parámetros entre navegador y servidor

son otros ejemplos de conceptos que aprendí cursando la misma.

A su vez, tanto Introducción a las Bases de Datos (I.B.D.) como Base de Datos (B.D.),

me han servido a la hora de visualizar y generar las relaciones de información que sería

necesarias implementar en la propia base de datos de modo que permitiesen generar

todo tipo de consultas y de control de la información con la que trabajo.

Para acabar, conceptos como los de escalabilidad y “overhead” han resultado a su vez

muy útiles los cuáles comprendí cursando Redes P2P y a su vez tanto Proyectos

Informáticos (P.I.) a la hora de gestionar y asignar los recursos del proyecto como

Ingeniería del Software (E.S.) con los conceptos de intuitivo y los diagramas

estructurales me han ayudado a posicionarme a la hora de programar pensando

siempre desde el punto de vista del usuario, simplificando así al máximo los casos de

uso de modo que la mecánica interna de funcionamiento resulte transparente para el

mismo.

22

6. Conclusiones

El haber tenido la oportunidad de realizar un proyecto de final de carrera como este

partiendo de unas premisas básicas que han tenido que ir evolucionando con el tiempo

me ha permitido poder participar más activamente en el proyecto de lo que jamás

hubiera esperado en un principio.

A día de hoy ya hemos llegado prácticamente al punto de comercialización de nuestro

producto y de resultas de esta proximidad inminente, mi compañero y yo ya hemos

realizado dos presentaciones junto con el jefe de la empresa ante dos grupos distintos

de posibles compradores los cuales en su mayoría se mostraron francamente

interesados en el producto que ofrecemos, sin duda, una sensación muy gratificante la

cuál tengo que agradecer a toda la estructura que nos compone.

23