PsicoMarketing

La palabra como tal “PsicoMarketing” o “Psico-Marketing” no existe en el diccionario de la Real Academia Española.

Pero analizando el significado de las dos palabras que la componen:

Psico: Elemento compositivo que significa ‘alma’ o ‘actividad mental’

Y por lo otro lado:

Mercadotecnia (Marketing en inglés):  Conjunto de principios y prácticas que buscan el aumento del comercio, especialmente de la demanda

psicomercadotecnia

Yo entiendo entonces que la PsicoMercadotecnia es el estudio y práctica de principios que buscan provocar y seducir al alma con el objetivo de vender servicios y/o productos.

Lo escrito en el párrafo anterior puede sonar un poco tenebroso, pero en la actualidad así funciona la publicidad de muchas marcas, y funciona a la perfección, ya que los seres humanos somos emocionales, esta característica no es buena ni mala, simplemente es algo que las marcas pueden y están dispuestas a explotar.

Con esta entrada estreno una nueva etiqueta en el blog: “Mercadotecnia”, bajo la cual escribiré sobre estrategias de mercadeo que me parecen interesantes, también vale la pena escribir datos curiosos sobre las reacciones de nuestra mente ante ciertos estímulos.

Nos leemos en la siguiente entrada.

Saludos.

Anuncios

¿WordPress en GCP?

De lo primero que me dí a la tarea de investigar es la instalación de uno de los CMS más utilizados actualmente (WordPress) en el Google Cloud Platafform (GCP), y resulta ser que en el GCP ya cuenta con la opción de desplegar soluciones prediseñadas, me sorprende la cantidad de soluciones que ya están listas para desplegarse, para darse una idea basta con echarle un ojo a la siguiente información.

Y como era de esperarse el CMS de WordPress es una de esas soluciones que ya están disponibles para desplegar con unos cuantos clics.

wordpress_gcp

Paso 1.

Desplegamos el menú principal, ubicado en la parte superior izquierda:

menu_principal

Paso 2.

Elegimos la opción Cloud Launcher.

cloud_launcher

Paso 3.

Buscamos WordPress en la categorías Blogs y CMS o lo seleccionamos de la pantalla principal.

localizar_wordpress

Paso 4.

Damos clic en el boton Ejecutar en Compute Engine.

info_predespliegue

Paso 5. Disfruta tu CMS.

Al dar clic sobre el botón Ejecutar en Compute Engine y después de configurar cosas básicas, nos muestra la pantalla de administración del despliegue como la que se muestra a continuación:

config_desplegue_wordpress_desenfoque

Ahora visitando el link donde ahora está ejecutándose el CMS (WordPress) que desplegamos en el GCP. Veremos algo similar a lo siguiente:

wordpress_desplegado

El GCP hizo el despliegue de WordPress en su versión 4.9.6 que viene con el tema Twenty Seventeen y ahora podemos comenzar a modificar nuestro WordPress cambiando el tema, instalando plugins, agregando widgets etc.

Las aplicaciones que GCP ya pone a disposición nos ahorran bastante tiempo, ya que con unos cuantos clics tenemos un CMS listo para utilizarse. Algo que no puede pasar desapercibido es, que el CMS ya tiene su IP pública, osea es accesible desde cualquier parte del mundo, ¡ya esta en internet! Ahora la observación obvia, ¿Cuánto cobra Google por éste servicio? Si tienes una cuenta Google (gmail) puedes tener de momento algunas cosas de manera gratuita, estas cuentas gratuitas duran un periodo de 12 meses, para que le puedas mover y picar a todas las opciones que brinda el GCP. Una vez terminado el periodo de prueba puedes adquirir una cuenta de pago, donde solo pagas o que tu sitio consume, por ejemplo cuanto consumo de CPU, memoria, red, almacenamiento permanente, etc. Puedes consultar la siguiente información de precios de GPC, para que te formes una mejor idea.

Pero procuraré no perder el tiempo y le sacaré provecho a mi cuenta gratuita.

Nos leemos en la siguiente entrada.

¡Felices líneas!

Saludos.

Google App Engine

Me entere del Google App Engine en un momento entre enero y mayo del 2017. Y como todo buen chismoso hice el clásico ejercicio del “hola mundo” en esta API de Google.

Ha pasado poco más de un año de eso, y no me acuerdo ni como lo hice, lo único que recuerdo a groso modo es, que al tener una cuenta de gmail (o google) ya puedo tener acceso a esta dichosa API.

También recuerdo en aquel entonces observar el App Engine como un hosting donde puedes subir o desarrollar tus aplicaciones web, la novedad era la facturación dinámica basada en el consumo de recursos de tu aplicación. En el clásico hospedaje pagas una cuota fija para utilizar los recursos de almacenamiento y procesamiento, esta cuota es fija sin importar que tanto de estos recursos utilices. En el App Engine pagas de acuerdo al consumo de recursos de tu aplicación.

app_engine

Ahora que estoy comenzando con mis propios clientes, considero de suma importancia volverme un experto (por no decir un “Cloud Hero”) en el App Engine, por tal razón con esta entrada estreno una nueva etiqueta “AppEngine” a la cual iré agregando entradas sobre mis pruebas y resultados con esta herramienta.

Nos leemos en la siguiente entrada.

¡Felices líneas!

 

Modelos Parte 1

Los modelos en el framework Laravel, son clases que permiten la comunicación entre nuestra aplicación y su(s) base(s) de datos para poder persistir y recuperar información. Es una de las cosas más importantes en el patrón MVC. Para cada tabla de la base de datos existe un Modelo (no es una regla). La principal característica de un modelo es la abstracción de una tabla como un elemento orientado a objetos.

M_modelo_modo_senin

Antes de comenzar

En la entrada Migraciones Parte 1 y Migraciones Parte 2 observamos que al ejecutar el comando php artisan make:migration:schema el mensaje de respuesta decía algo similar a lo siguiente: “Model created successfully” (Modelo creado correctamente)

make_migration_schema_ejemplo

Todos los modelos que se crearon al trabajar las migraciones, están ubicados en la ruta escuela/app y por convención cada modelo lleva el nombre en singular de la tabla a la que representa. Por ejemplo el modelo escuela/app/Carrera.php representa a la tabla carreras en la base de datos, y recordemos que dicha tabla fue creada con la migración created_carreras_table.php. En caso de necesitar un nuevo modelo, puedes utilizar el comando: php artisan make:model.

Vamos a verificar que ya existen nuestros modelos, observamos el directorio escuela/app, y veremos algo similar a lo siguiente:

modelos

El código de los modelos creados es similar a lo siguiente:

model_class

Una clase de nombre en singular que extiende de la clase Model, ¿Y ahora cómo las podemos utilizar? ¡Vamos a lo siguiente!

Tinker

El framework provee un REPL de nombre tinker que nos permite interactuar con nuestra aplicación vía consola. Es una herramienta bastante útil para probar nuestra aplicación (ojo no me refiero a realizar pruebas unitarias o algo similar). Hasta este punto hemos visto poco código PHP, la mayoría de las cosas se han realizado mediante comandos artisan y utilizaremos un poco más la consola. Recapitulando en general hemos realizado hasta ahora lo siguiente:

  1. Instalamos Laravel utilizando la consola
  2. Conectamos la aplicación a la base de datos configurando datos de conexión
  3. Instalamos librerías debugbar y generators utilizando la consola
  4. Definimos nuestro ejemplo usando un diagrama de contexto
  5. Creamos nuestras primeras vistas y diseñamos nuestra plantilla general utilizando código HTML y el motor de plantillas Blade de Laravel
  6. Generamos las migraciones (y de paso se generaron los modelos) de las entidades definidas en nuestro ejemplo, dichas migraciones se crearon utilizando la consola

Vamos a utilizar tinker para probar, en parte, el funcionamiento de nuestros modelos. Sigamos los siguientes pasos:

  1. Iniciamos tinker, ejecutando el siguiente comando:
    php artisan tinker

    Y veremos algo similar a lo siguiente:
    tinker

  2. Escribimos una instrucción que ya es propia de PHP, y nos permite ejecutar un método de uno de los modelos creado. Ejecutamos el siguiente comando:
    App\Carrera::all();

    Y veremos algo similar a lo siguiente:
    all_carreraComo observamos el resultado nos regresa un Objeto de tipo Collection que está vacío.

  3. Intentaremos crear una carrera ejecutando al siguiente instrucción:
    App\Carrera::create(["carrera" => "Derecho", "descripcion" => "Licenciatura de Derecho"]);

    Y veremos algo similar a lo siguiente:
    create_carreraNos muestra una excepción (un error).

  4. Para corregir el error anterior, solo tenemos que modificar nuestro modelo Carrera.php. Agregamos a la clase, la siguiente propiedad:
    protected $fillable = ["carrera", "descripcion"];

    quedando de la siguiente manera:
    fillableSi deseas conocer más sobre la asignación masiva puedes leer la siguiente documentación.

  5. Cerramos tinker escribiendo exit. Para después volver a iniciar tinker como se hizo en el punto 1. Es necesario para reflejar el cambio que hemos realizado en el modelo.
  6. Una vez reiniciado tinker ejecutamos de nuevo el comando:
    App\Carrera::create(["carrera" => "Derecho", "descripcion" => "Licenciatura de Derecho"]);

    Y observamos algo como lo siguiente:
    create_carrera_success

  7. Confirmamos la creación de un registro nuevo en nuestra base de datos:
    select_from_carreras
    O si gustas observarlo desde la interfaz HeidiSQL:
    carreras_heidi
  8. Ahora podemos ejecutar el comando del punto 2:
    App\Carrera::all();

    Y vemos información recuperada de la base de datos:
    all_carrera_success

Con los pasos anteriores sin crear algún script PHP ya hemos verificado que nuestra aplicación ya puede persistir datos. También observamos que podemos modificar nuestros modelos para tener acceso a ciertos métodos que son propias del “ActiveRecord” que brinda el ORM Eloquent que utiliza Laravel.

Conclusiones

Estamos en el punto donde insertamos un registro en una tabla de nuestra base de datos sin haber escrito ninguna instrucción SQL. Esta es la maravillosa abstracción que brinda la M del MVC, dicho de otro modo es lo que permiten los Modelos en el patrón Modelo Vista Controlador, permiten manejar operaciones con base de datos de manera más rápida, sencilla y ¿porqué no? elegante.

Nos leemos en la siguiente entrada.

¡Felices líneas!

Migraciones Parte 2

En la entrada Migraciones Parte 1, explique a muy groso modo mi saber sobre las migraciones en Laravel, también se creó con éxito la migración de la primera entidad definida en nuestro ejemplo. Ahora seguimos con las migraciones restantes.

Entidad Materias

Esta entidad, así de rápido, consta de campos muy específicos para identificar una materia impartida a los alumnos de una escuela. Dichos campos pueden ser los siguientes:

  • Un campo nombre o materia, que permita texto al menos unos 50 caracteres.
  • Un campo tipo, que permita un valor binario (uno o cero). Si el valor es cero se entiende que la materia es de tronco común, si es uno se entiende que la materia es de especialidad.
  • Un campo créditos que permita valores numéricos
  • Un campo carrera ID que indique la pertenencia de dicha materia a una carrera
  • Un campo descripción que permita texto, de un tamaños considerable

El comando artisan quedaría algo similar a lo siguiente:

php artisan make:migration:schema create_materias_table --schema="materia:string(50), tipo:binary, creditos:smallInteger:default(6), carrera_id:integer:unsigned:foreign, descripcion:text:nullable"

La clase resultante es similar a lo siguiente:

CreateMateriasTable

Lo notable en la migración anterior es la llave foránea, que también es soportada por la librería generators que instalamos en la entrada Algunas cosas extra antes comenzar. Parte 2.

Entidad Profesores Catedrático

Te preguntarás porque tache la palabra Profesores. La razón es para cumplir con la Convención sobre Configuración que utiliza Laravel para manejar los nombres de las migraciones y los modelos. Esta convención, pide utilizar los nombres de las tablas en plural y el nombre del modelo en singular. Para nuestra entidad profesores (en inglés Professor) la tabla migración debería ser create_professors_table. Pero al tener la palabra en español el algoritmo de laravel no tiene forma de saber que, en español, la palabra profesores perdería las ultimas dos letras (profesores) al pasar a singular. Por lo tanto al cambiar a la palabra catedrático, se cumple la convención, ya que la migración se llamaría create_catedraticos_table y al pasar a singular la palabra catedráticos, solo se pierde la letra “s”.

Campos necesarios para identificar a un catedrático:

  • Nombres
  • Apellido paterno
  • Apellido Materno
  • Grado máximo de estudios
  • Dirección
  • Tipo, dato binario (cero y uno). Si el valor es cero se considera que trabaja a tiempo completo, si el valor es uno se considera que trabaja por horas
  • Fecha nacimiento

El comando artisan a ejecutar es similar a lo siguiente:

php artisan make:migration:schema create_catedraticos_table --schema="nombres:string(30), appaterno:string(30), apmaterno:string(30):nullable, titulo:string(150):nullable, direccion:string(250):nullable, tipo:binary, fnac:date:nullable"

La clase resultante es similar a lo siguiente:

CreateCatedraticosTable

Entidad Alumnos

Campos necesarios para identificar a un alumno:

  • Nombres
  • Apellido paterno
  • Apellido materno
  • Fecha Nacimiento
  • Dirección
  • Carrera, para usar como referencia de carrera a la que pertenece el alumno

El comando artisan a ejecutar es similar a lo siguiente:

php artisan make:migration:schema create_alumnos_table --schema="nombres:string(30), appaterno:string(30), apmaterno:string(30):nullable, fnac:date:nullable, direccion:text:nullable, carrera_id:integer:unsigned:foreign"

La clase resultante es similar a lo siguiente:

CreateAlumnosTable

Entidad Periodo

Esta entidad merece en realidad un mejor análisis, pero para nuestro ejemplo definimos lo siguiente: La entidad periodos significa lapsos estudiantiles de seis meses (semestres), y deberá existir un registro por cada lapso de tiempo y cada carrera. Por ejemplo: supongamos que la escuela tiene dos carreras, en la entidad periodo, deberán existir al inicio de año dos registros, uno por cada carrera. A medio año deberán existir otros dos nuevos registros, uno por cada carrera. Y así, por cada año transcurrido, se creará un registro por carrera cada seis meses.

Campos necesarios para identificar un grupo:

  • Nombre del periodo. Nombre que describa de manera breve la carrera y el periodo representado por el registro
  • Fecha de inicio del periodo
  • Fecha de fin del periodo
  • Carrera ID para usar como referencia de carrera a la que pertenece el periodo

El comando artisan a ejecutar es similar a lo siguiente:

php artisan make:migration:schema create_periodos_table --schema="nombre:string(50), finicio:date, ffin:date, carrera_id:integer:unsigned:foreign"

La clase resultante es similar a lo siguiente:

CreatePeriodosTable

Entidad Grupo

Un grupo y sus relaciones con otras entidades, bien pueden abordarse de mejor manera, pero para nuestro ejemplo definimos lo siguiente: Esta entidad nos permitirá aglutinar un número finito de alumnos de una carrera específica durante un periodo definido, estos alumnos aglutinados estarán ligados a un solo catedrático.

Campos necesarios para identificar un grupo:

  • Alumno ID como referencia de alumno ligado al grupo
  • Periodo ID como referencia de periodo ligado al grupo
  • Catedrático ID como referencia de un catedrático ligado al grupo

El comando artisan a ejecutar es similar a lo siguiente:

php artisan make:migration:schema create_grupos_table --schema="alumno_id:integer:unsigned:foreign, periodo_id:integer:unsigned:foreign, catedratico_id:integer:unsigned:foreign"

La clase resultante es similar a lo siguiente:

CreateGruposTable

Entidad Tira de Materias Tiras

La entidad Tiras, al igual que la entidad Catedráticos, ha sido renombrada para adaptarse a la convención de nombres que Laravel utiliza. Y de igual forma esta entidad merece un mejor análisis, pero para nuestro ejemplo se define lo siguiente: Una tira permite ordenar las materias de las carreras en semestres continuos, para que puedan ser utilizados en periodos específicos.

Campos necesarios para identificar una tira:

  • Nombre que describa de manera breve la tira
  • Carrera ID como referencia de una carrera específica
  • Materia ID como referencia de una materia específica
  • Número de semestre donde se recomienda cursar la tira de materias

El comando artisan a ejecutar es similar a lo siguiente:

php artisan make:migration:schema create_tiras_table --schema="nombre:string(30), carrera_id:integer:unsigned:foreign, materia_id:integer:unsigned:foreign, semestre:smallInteger"

La clase resultante es similar a lo siguiente:

CreateTirasTable

Ejecutar migraciones

Ya tenemos muchas migraciones creadas, recordemos que en la entrada Migraciones Parte 1 creamos una migración y la ejecutamos. Entonces ahora quiero saber el estado de las migraciones. Para lo anterior podemos utilizar el siguiente comando:

php artisan migrate:status

Y observamos algo similar a lo siguiente:

migrate_status

Es una tabla muy simple que nos indica que archivos de migración ya han sido ejecutados. Desde el archivo create_materias_table hacia abajo, no se ha ejecutado ninguna migración.

Ejecutamos el siguiente comando:

php artisan migrate

El resultado es algo similar a lo siguiente:

migrate

Ahora se puede verificar las tablas existentes en nuestra base de datos:

show_tables

El diagrama de contexto original sufrió cambios en nombres de algunas entidades para ajustarnos a la convención de nombres de Laravel. Para ilustrar mejor lo anterior el diagrama de contexto actualizado es el siguiente:

diagrama_contxto_modificado.jpg

En color rojo estan marcadas las entidades que ya tenemos su migración. Aquellas con marca color verde, son las que hemos renombrado para cumplir con la convención.

Conclusión

Con las entidades creadas hasta este punto, tenemos suficiente (de momento) para continuar con el desarrollo de la aplicación y así continuar con el manejando de conceptos como: modelos, request y controladores.

Nos leemos en la siguiente entrada.

¡Felices líneas!

Migraciones Parte 1

Las migraciones, son una manera, o una herramienta que brinda Laravel para trabajar con los esquemas de las bases de datos. Son bastante útiles, permiten construir la base de datos sin tener que trabajar directamente con un motor de base de datos. También permite llevar un control de los cambios realizados a los esquemas de la base de datos de nuestra aplicación conforme se avanza en el desarrollo de la misma.

Los archivos de migración se guardan en la siguiente carpeta (de nuestro ejemplo): escuela\database\migrations, el nombre de cada archivo de migración esta compuesto por una marca de tiempo, seguido de una palabra que indica la operación que se realizará en la base de datos: por ejemplo create, add, remove, etc y termina con el nombre de la tabla donde se realiza dicha operación.

Un archivo de migración de ejemplo es el siguiente:

user_table_migration

Laravel incluye el siguiente archivo de migración 2014_10_12_000000_create_users_table.php

Como puede verse la migración es una clase que extiende la clase Migration, y contiene dos métodos. El método up es el encargado de realizar las acciones necesarios que corresponden con la operación (create, add, drop, remove, etc). El método down revierte las acciones realizadas en el método up.

Podemos utilizar comandos artisan para trabajar con migraciones, los comandos disponibles son los siguientes:

migrate_commands

También tenemos opciones en el comando make de artisan, esto gracias a la librería generators que instalamos en la entrada Algunas cosas extra antes comenzar. Parte 2

make_migrate_commands

Creando la migración “Carreras”

Recordando nuestro diagrama de contexto que tratamos en la entrada Definiendo un ejemplo sabemos que tenemos que crear una entidad que permita registrar o persistir los datos de las carreras disponibles en la escuela.

entidad_carreras

 

Eligiendo un comando

Echando un ojo a los comandos artisan, tenemos dos opciones: make:migration y make:migration:schema

  • Si decidimos utilizar el comando make:migration, se creará el archivo .php en la carpeta escuela/database/migrations, y el contenido será el siguiente:create_carreras_table_op1
    Con sus respectivos métodos up y down, posterior a esto, nos corresponde modificar dichos métodos para agregar las acciones necesarias, lo cual, requiere que leas la siguiente documentación.
  • Si deseas verte más “pro”, puedes utilizar el comando make:migration:schema, que permite crear un archivo .php, con la diferencia, que desde la misma sintaxis del comando se pueden incluir operaciones con las columnas. Por ejemplo para la entidad carreras, el comando será algo similar a lo siguiente:
    php artisan make:migration:schema create_carreras_table --schema="carrera:string(30), descripcion:text"

    El resultado de ejecutar el comando anterior es algo similar a lo siguiente:
    make_migration_schema_ejemplo
    Como puede verse el mensaje dice que se ha creado la migración y el modelo. Los modelos los veremos en próximas entradas. Por ahora, el archivo de migración se observa algo similar a lo siguiente:
    migration_carreras
    Es más “pro”, además de mayor utilidad, ya que para crear las tablas de nuestro proyecto, nos permite definir las columnas y los tipos de dato de cada una. Solo basta ceñirse a la sintaxis de COLUMNA:TIPO. Para saber los tipos de columna que se pueden utilizar puedes consultar la siguiente documentación. También puedes consultar los ejemplos mostrados en la siguiente documentación de la librería generators.

Ejecutando migraciones

Hasta este punto, hemos creado los archivos de migración, que tiene las instrucciones para crear las tablas necesarias en nuestro proyecto. Ya con todas las migraciones creadas, solo basta ejecutar el siguiente comando:

php artisan migrate

El resultado del comando es algo similar a lo siguiente:

ejecucion_migraciones

Aclaración: Se ejecutaron los archivos de migración para las tablas users y passwords_resets junto con la migración que creamos en esta entrada, porque al ejecutar el comando migrate, se ejecutan todos los archivos de migracion que ésten pendientes de migrar. El control de los archivos pendientes de migrar se llevan en la tabla migrations.

Hecho lo anterior, podemos verificar la creación de dichas tablas en nuestro motor de la base de datos.

show_tables

Consultando desde la consola

Y !ta ta ra taaa! logramos crear nuestra tabla carreras (entre otras) en nuestra base de datos, y solo tuvimos que tirar unos cuantos comandos desde la consola.

Conclusión

Cuando conocí las migraciones de Laravel, en un principio no les tome gran estima, debido a que los proyectos en los que trabajaba por aquellos tiempos no eran aplicaciones que tuvieran que hacerse desde cero. Eventualmente estuve a cargo de nuevas creaciones, completamente realizadas desde cero, donde quedé encantado con las migraciones, ya que podía comenzar a desarrollar rápido, plasmando mis ideas directamente hacia la consola, sin tener que pasar por diagramas. Todo estaba en la mente y eso es realmente satisfactorio y efectivo cuando es combinado con el desarrollo ágil, especialmente con la metodología de Programación extrema.

Nos leemos en la siguiente entrada.

¡Felices líneas!

Vistas, Plantillas y Rutas

Comenzaremos con algunos conceptos básicos del framework: vistas, plantillas y las rutas. Para este desarrollo he seguido los pasos del post Probando sin ver. Parte 1 para tener una instancia de Laravel en la carpeta escuela como se puede observar en la URL de la siguiente imagen:

inslacion_escuela

En mis palabras, definiría los conceptos de la siguiente manera: Las vistas es lo que se pinta o se renderiza en el navegador, las plantillas son vistas, que pueden ser utilizadas como modelo para crear otras vistas y las rutas son las URLs a las que responderá nuestra aplicación.

Las vistas y las plantillas se crean en el siguiente directorio de nuestro framework escuela\resources\views:

directorio_escuela

Las rutas se crean en el archivo web.php que se encuentra ubicado en escuela\routes:

rutas

La página que se muestra en una instalación recién hecha de Laravel 5.3 es una vista que se muestra cuando se pide la ruta “\” (que se entiende como ruta principal).

Un clásico

De momento modificaré el contenido de la vista welcome.blade.php que se muestra al pedir la ruta “\”. Quiero que se muestre el clásico “Hola mundo!”

El contenido del archivo web.php es el siguiente:

contenido_web_php

Como puede verse la línea 4, retorna el helper view  al que se le pasa como primer argumento el nombre de la vista, en este caso “welcome”.

Abrimos el archivo ubicado en resources\views\welcome.blade.php. Si se requiere más información sobre el motor de plantillas que utiliza Laravel 5.3 consultar la siguiente documentación.

welcom_view

El contenido de la vista welcome.balde.php es código HTML, por lo tanto lo podemos modificar sin problema, se modifica de la siguiente forma:

hola_mundo

 

Este cambio da como resultado lo siguiente en el navegador:

hola_mundo_navegador

Hasta este punto ya hemos modificado una vista (welcome.blade.php), y echamos un ojo al archivo web.php donde solo hay una acción para la ruta predeterminada “\”.

Plantillas

Las plantillas servirán para definir la estructura básica que tendrán la mayoría de las páginas de nuestra aplicación, no importa qué recurso de nuestra aplicación estemos consultando Alumnos, Materias, etcétera la vista deberá contar con algunos elementos básicos en su diseño. La ventaja de las plantillas es que las tenemos que codificar una sola vez, para después reutilizar su diseño en cualquier otra vista.

La diseño básico de nuestra aplicación será: un encabezado (donde seguro habrá un menú), una sección de contenido general y un pie de página. La sección de contenido general estará dividida en dos partes. El blueprint será similar a lo que se muestra en la siguiente imagen:

blueprint

Nota: Las líneas de color son ilustrativas, no forman parte del diseño.

Se creará una vista con este diseño específico, para esta labor se requiere utilizar la librería bootstrap v3.3.7 para crear la rejilla necesaria, para saber más sobre las rejillas de bootstrap consulta la siguiente documentación.

Creando la plantilla

Creamos un nuevo archivo de nombre plt_basica.blade.php y en él, escribimos el código del diseño planteado. El archivo estará ubicado en escuela/resources/views.

creando_plantilla

El archivo contiene lo siguiente:

codio_plantilla

La mayoría del código es HTML, pero se agregaron instrucciones propias de Blade (el motor de plantillas que utiliza Laravel). Dichas instrucciones son @section y @yield, con estas instrucciones estamos marcando, en la plantilla, lugares donde se podrá agregar contenido dinámico desde las vistas “hijas” que utilicen esta plantilla.

Hasta este punto, el diseño anterior no es visible desde ningún lado, recordemos que solo tenemos la ruta “\” (inicial), la cual muestra la vista welcome.blade.php. Pero basta un cambio en el archivo welcome.blade.php para hacerla hija de la plantilla plt_basica.blade.php. El cambio en el archivo welcome.blade.php queda de la siguiente manera:

modificando_welcome

Como puede verse en la imagen, solo basta la instrucción @extends(“plt_basica”) para indicar a Blade que la vista welcome.blade.php es hija de la plantilla plt_basica.blade.php. Después de la instrucción @extends, solo resta utilizar las secciones de la plantilla que se necesiten, en este caso solo se utilizó la sección “titulo” y “seccionA”.

Al guardar los cambios y actualizar la solicitud de la ruta “\” (inicial) el resultado es el siguiente:

welcome_actualizado_navegador

Las plantillas hacen que no sea necesario construir o copiar la estructura de nuestra página en cada una de las vistas que generemos. Para dimensionar su utilidad, podemos hacer un ejercicio mental con dos entidades que mencione en la definición de nuestro ejemplo con las entidades Alumnos y Profesores necesitaremos al menos 3 vistas por cada entidad, imagina tener que copiar la misma estructura en cada una de las vistas, resultaría un trabajo, tal vez, no pesado, pero sí susceptible a errores sin mencionar que sería difícil realizar y replicar cambios al diseño.

Resumen

Fue una entrada larga en mi opinión, pero con ésto ya hemos avanzado buena parte, también ya conocemos los conceptos de vista, plantilla y ruta. Y apreciamos la importancia de utilizar plantillas en nuestra aplicación. Si bien no tiramos líneas php como tal, sí conocimos instrucciones nuevas, propias del motor de plantillas Blade.

Nos leemos en la siguiente entrada.

¡Felices líneas!

Definiendo un ejemplo

A partir de esta entrada voy a simular el desarrollo de un sistema con el que trabaje algunos años atrás. Era un sistema de administración escolar, tomaré los ejemplos de dicha simulación para documentar (a mi estilo) cómo lo hubiera desarrollado en aquel entonces de haber conocido Laravel.

Nota: Con respecto a la base de datos quiero aclarar que no me detendré en el diseño de la base de datos, por la tanto habrá algunas cosas que parecerán ir contra el buen diseño de base de datos, pero mi objetivo es Laravel, y no la arquitectura de base de datos.

Diagrama de contexto

La manera más rápida de abordar un proyecto, en mi opinión, es hacer un diagrama de contexto, para darnos una idea rápida de los recursos que se programarán, el diagrama de contexto en el que me voy a basar es el siguiente:

diagrama_contexto

Como puede verse en el diagrama, hay un recuadro central denominado sistema, el cual contiene funciones o módulos especiales que se deben desarrollar para darle utilidad a la información que se registrará en el sistema.

Los módulos (Carreras, Materias, Alumnos, Profesores) localizados fuera del recuadro central denominado sistema, yo los considero como catálogos, los cuales serán los más rápidos de desarrollar, y los que trataré en las siguientes entradas.

Nos leemos en la siguiente entrada.

¡Felices líneas!

Probando sin ver. Parte 1

Una sugerencia a modo de ejercicio sería el siguiente:

La idea es seguir los pasos que se escribieron en las entradas:

Sé que puede resultar algo tedioso leer esas entradas, así que escribiré puntos precisos:

  1. Instalar composer en nuestra PC
  2. Instalar XAMPP en nuestra PC
  3. Utilizar el siguiente comando composer para descargar el framework:
    composer create-project –prefer-dist laravel/laravel instalacion “5.3.*”
  4. Verificar que el framework funciona, ingresando a la ruta de instalación desde el navegador, donde veremos algo similar a esto:
    probando_navegador
  5. Configurar los datos para la conexión a la base de datos de nombre test que viene creada al instalar XAMPP
  6. Ejecutar el siguiente comando artisan: php artisan migrate:install
  7. Instalar las librerías debugbar y generators del framework laravel
  8. Verificar que nuestro framework sigue funcionando
    debugbar_navegador

La idea del ejercicio es verificar que al inicio puede resultar un poco tardado, pero una vez que dominas estos pasos comenzarás a observar lo rápido que puedes tener un marco de trabajo para comenzar con la creación de aplicaciones web. Recomiendo realizar éstos pasos para distintas instalaciones, a fin de cuentas el único límite que se tiene, es la capacidad del disco duro ;).

Nos leemos en la siguiente entrada.

¡Felices líneas!

Algunas cosas extra antes comenzar. Parte 2

Ya tenemos nuestro debugbar, ahora instalaremos una librería que también será de utilidad, la librería es laracasts/generators pondrá a nuestra disposición algunos comandos artisan extra.

Lo primero que debemos hacer es buscar la librería en el sitio packagist, como se muestra en la siguiente imagen:

packagist_generators

La librería generators, fue exclusivamente desarrollada para la versión 5 del framework laravel. Ahora instalaremos generators utilizando composer, ejecutando el siguiente comando:

composer require laracasts/generators –dev

composer_generators

Ahora agregamos las siguientes líneas de código:

if ($this->app->environment() == ‘local’) {
$this->app->register(‘Laracasts\Generators\GeneratorsServiceProvider’);
}

Las líneas se agregan al siguiente archivo app/Providers/AppServiceProvider.php. El código se escribe dentro de la función register, quedando de la siguiente manera:

register_provider

Y por ultimo verificamos, la instalación y establecimiento del provider, ejecutando el siguiente comando en la consola:

php_artisan

Ahora se pueden observar tres nuevos comandos, como se muestra en la siguiente imagen:

verifcar_generators

Con esta segunda parte instalada podemos entrar de lleno al desarrollo de aplicaciones con Laravel.

Nos leemos en la siguiente entrada.

¡Felices líneas!