Llevándote bien con los Fixtures

Estándar

Las Factories pueden ayudar a lidiar con las dolorosas etapas tempranas, pero pueden ser dolorosas conforme una aplicación crece. Los Fixtures pueden ser incómodos al inicio, pero brillantes con la complejidad. A su propio modo, ambos hacen más fácil el hacer pruebas. Ninguno es un anti-patrón.

technicalHay una división en el mundo de Rails. Bueno, hay muchas divisiones en el mundo Rails, especialmente acerca de ¿cómo escribir pruebas? Para puntualizar. Los desarrolladores en Rails no están de acuerdo sobre como configurar sus datos de prueba.

Hay dos posturas en este debate. Los Fixtures vienen con Rails por defecto. Estos son le método que eligió el equipo del Núcleo de Rails y DHH los respalda. En la otra esquina tenemos a la gente que aboga por reemplazar los fixures con gemas para factory como Factory Girl o Fabrication. Ambas estrategias tienen suficientes defensores y detractores como para mantener viva la discusión por muchos años. Recientemente un defensor de las factory fue tan lejos como para afirmar que los fixtures eran un anti-patrón, lo que me hizo pensar en como encajan los fixtures y factories en el libro de las las pruebas.

He estado usando Fabrication como mi generador de datos de prueba como mi elección durante los últimos meses. Antes estuve usando Factory Girl depues de abandonar bastante pronto los fixtures. Hasta la semana pasada, me sentia muy comodo con la generación de objetos de prueba. He estado usando Fabricators activamente en mis pruebas e incluyendolos en algunas pruebas de entranamiento. La última semana, regrese al proyecto de un viejo cliente que estaba soportado con fixtures. Lo primero que pense fue re-escribir los test para usar fabricators, pero simplemente no habia tiempo para hecerlo. A regañadientes, he vuelto a usar fixtures para mis pruebas.

La semana incio algo lenta como si tratara de adaptar los nuevos fixtures a mi flujo de trabajo con fabricator, pero despues de un sorpendentemente corto periodo de adaptación, realmente lo estaba disfrutando. No estaba preocupado de crear el paquete correcto de objetos para pruebas complejas. Todo lo que necesitaba estaba justo ahí, esperando a ser probado. Esperaba revertirlo en el transcurso de la semana, pero no creo que sonsidere cambiar a usar fixtures con regularidad. Esto me hizo pensar de nuevo en el debate fixture vs factory con una nueva luz.

Quiero darle otra revisión a las dieferencias entre fixtures y factories con una nueva óptca.

Definiciones

Los fixtures son definidos en archivos yaml. Generalmente lucen algo como esto:

bond:
  first_name: James
  last_name: Bond
  email: jamesbond007@mi6.gov.uk

bourne:
  first_name: Jason
  last_name: Bourne
  email: jbourne@cia.gov

Las factories (Fabricators en este caso) se definen algo así:

Fabricator :agent do
  first_name { Faker::Name.first_name }
  last_name { Faker::Name.last_name }
  email { Faker::Internet.email }
end

La vía de los fixtures consiste en escribir múltiples definiciones de el mismo tipo de objeto. Las factories son en realidad plantillas de objetos, así que terminan buscando mucho más que las definiciones de tablas en db/schema.rb. Los fixtures promueven la repetición y trabajan mejor con algunos datos de prueba creativos y dignos de recordar. Las factories no te hacen pensar o reiterarte.

Escribir fixures parece algo tedioso cuando te fijas en ellos a lo ancho y largo, especialmente cuando estas usando una gema para generación de datos, como Faker, con factories. Definir datos para un solo tipo de modelos es claramente una victoria para las factories.

Creando objetos

Las factories crean nuevos objetos bajo demanda en las pruebas. Las pruebas usando factories inician con un borrón y cuenta nueva en cada ocasión, esperando a que preguntes por un tipo de objeto específico. Los fixtures tienen una aproximación diferente. Cuando arranca el entorno de pruebas, una de las primeras cosas que hace es leer todos las definiciones en los fixtures e insertarlas directamente en la base de datos, sin discriminarlas. Los fixtures se saltan el proceso completo de creación de objetos, evitando validaciones y encadenamientos.

Debido a la forma en que son cargados, los fixtures son ridículamente rápidos, pero no pueden ser cambiados. Si un objeto con cierto tipo de datos de prueba es necesario para una prueba, este necesita ser definido en un archivo de fixture (o creado con un Model.new). Esto es especialmente frustrarte durante etapas tempranas del desarrollo como la concreción de modelos de datos y requerimientos de aplicación.

Debido a la forma en que las factories son creadas, estas tienen la ventaja de la flexibilidad. Si te percatas de que en un punto en una prueba necesitas un cierto tipo de datos, fácilmente puedes sobre-escribir la definición de una factory para llenar las necesidades de la prueba. Esto es especialmente útil en una nueva aplicación donde aun estamos entendiendo como necesitan ser estructuradas nuestras pruebas.

test 'on_assignment collects agents on active missions' do
  agent_on_assignment = Fabricate(:agent, mission: Fabricate(:active_mission))
  agent_not_on_assignment = Fabricate :agent
  assert_includes Agent.on_assignment, agent_on_assignment
  refute_includes Agent.on_assignment, agent_not_on_assignment
end

En esta prueba, solamente necesitamos una factory predefinida para Mission y Agent, y manejar los detalles en la prueba. No necesitamos ir a otro archivo para establecer la definición. Si necesitamos un agente con una misión, entonces podemos extraer esto a su propio factory :agent_with_active_mission. Este tipo de flexibilidad da resultados con anticipación.

Desafortundamente, hay un impacto en el rendimiento con las factories. Las factories necesitan crear un objeto entero y posiblemente guardarlos en la base de datos para tenerlo disponible para la prueba. Esto se amontona conforme necesitas más objetos en las pruebas. pero como efecto colateral favorece las pruebas de forma aislada.

La misma prueba usando fixtures puede lucir algo como esto:

test 'on_assignment collects agents on active missions' do
  agents(:bourne).missions.clear
  assert_includes Agent.on_assignment, agents(:bond)
  refute_includes Agent.on_assignment, agents(:bourne)
 end

Necesitamos asegurar que el fixture del agente :bond esta asociado con una misión. Para hacer esto, tenemos que buscar entre los archivos de fixtures por los agentes y misiones. También podemos asumir que el fixture del agente :bourne debe tener misiones asociadas con el, así que debemos transparentar esa asociación.

Cuando de flexibilidad y obviedad se trata, las factories tienen claras ventajas con su habilidad para crear objetos dinámicamente cuando los necesitemos.

La desventaja de las Factories

Muchas de las comparaciones que he viso entre fixtures y factories usan ejemplos de una aplicación que esta en etapas muy tempranas de desarrollo en pruebas individuales. Las factories abordan el problema del no saber como deben lucir los datos de prueba. Ellas te permiten tomar decisiones acerca de los datos de prueba cuando este mucho más esclarecido lo que necesitas: en la prueba.

Esta ventaja temprana lentamente se convierte en una desventaja conforme la aplicación crece. Las factories crean objetos, propiciando el que los desarrolladores prefieran pruebas con objetos y datos tan reducidos como sea posible. Existe una carga asociada con la agregación de nuevos datos y objetos de prueba. Las pruebas toman más tiempo y nuevas variantes de datos necesitan ser añadidas. Las factories empiezan construir objetos con asociaciones y dependencias para probar escenarios de complejidad creciente. La simplicidad de las factories nos dieron al inicio pueden terminar por fatigar una aplicación más compleja.

Es semejante al problema de la última milla con el internet de banda ancha. Escribir esas primeras pruebas resulta mucho más fácil con factories, pero la cantidad de esfuerzo necesario para cubrir pruebas complejas crece en el tiempo. Este no es un factor decisivo pero es un tanto irritante.

Los fixtures despues de la luna de miel

Ya nos examinamos los aspectos negativos del uso de fixtures. Se termina por experimentar algo de dolor desde el principio por tener que evolucionar las pruebas con datos redundantes y buenos sin la ayuda de un generador. Tienes que saltar entre las pruebas y los fixtures a menudo cuando se trata de las necesidades cambiantes. Mantener ese sobre-esfuerzo a lo largo del proyecto es intimidante.

Pero aquí esta la cosa acerca de los fixtures: se vuelven más fáciles conforme pasa el tiempo. Iniciar con los fixtures es un tanto doloroso, pero puede ser condenadamente agradable una vez que se establecen los requerimientos de datos. He encontrado que los fixtures pueden ser mucho mejores si les entras con estas cosas en mente:

Escribir al menos tres fixtures para cada modelo.

Si. Debes escribir tus propios datos de prueba. Como desarrollador, esto apesta porque sabemos que no lo tenemos que hacer. Simplemente se siente mal. Pero si lidias con tus propios sentimientos de frustración, pasan cosas divertidas. Tus datos de prueba empiezan a formar una narrativa. Una historia toma forma al rededor de tus modelos, enlazas objetos logicamente como si estuviesen en tu aplicación. Con las factories, estás construyendo moldes que pueden llenarse con plastico no descriptivo, pero con fixtures, contruiras algo a mano con mayor detalle.Los fixtures te dan la oportundad de dejas de pensar en tu aplicación como un puñado de clases y la imaginas en el mundo real. Esto realmente ayuda

Abraza el cargar todo previamente.

Tres fixtures por cada modelo pareec una exajeración cuando empezas, pero rápidamente sientes que no es suficiente para representar diferentes tipos de datos.

No lo es.

Cuando estas trabajando con factories, terminas por definir varios objetos diferentes para manejar diferentes situaciones. Este es un efecto colateral de las factories iniciando cada prueba con borrón y cuenta nueva. Si necesitas a menudo un objeto usuario que tiene multples objetos compra, necesitas definir una única factory que los construya.

Si puedes abrazar la forma en que Rails carga los fixtures antes de probar, tendrías acceso a las mas complejas relaciones con mínimo esfuerzo. Las factories requiren que inicies con datos de prueba pequeños y aislados y agregas factories más complejas de forma incremental. Los fixtures, por otro lado, se espera que sean tan complejos como sea posible, tan pronto como sea posible. Puedes hacer esto simplemente asegurando que los objetos asociados estan conectados.

Así es, tendrás que mantener tus datos actualizados.

Una vez que tienes el mismo tipo de cosa definida al menos tres veces, probablemente necesitarás implementar cambos a los datos al menos tres veces. Nuevamente, como desarrolladores, esto se siente como si no tuviesemos porque hacer esto. Se siente como un gasto de tiempo.

Tambien podemos recibir una dosis concentrada muy pronto en la vida de la aplicación conforme nuestros modelos tomen forma al rededor de requerimientos cambiantes.

Si trabajas en superar esta incomodidad inicial, no sera tan malo como pienzas. Miigraciones y cambios de datos pasan mucho al inicio, pero van disminuyendo rápidamente conforme una aplicación va creciendo.

No te quedes atascado con los nombres

Las factories están diseñadas para ser plantillas de diferentes representaciones de datos. Las factories tienen finalmente un montón de nombres para recordar los muchos tipos de datos. ¿Necesitas un usuario que tenga múltiples ordenes? Probablemente terminaras teniendo una factory :user_with_multiple_orders para obtener justo lo que necesitas.

¡No! No con fixtures. Tu limitas el número de objetos en el fixture para cumplir con varios roles diferentes, por eso no tendremos una semántica de nombrado de lujo. Simplemente dale a esos objetos nombres cortos, únicos y fáciles de recordar y llamar algún día.

No te olvides del Object.new

Los fixtures se saltan el ciclo entero de creación de objetos. Cuando estas probando validaciones o llamandas en Rails, simplemente creas un nuevo objeto del modelo con la de de un fixture, algo como:

test 'should require a unique code_name' do
  duplicate_mission = Mission.new(missions(:grand_slam).attributes)
  assert_invalid Mission.new, code_name: "can't be blank"
  assert_invalid duplicate_mission, code_name: 'has already been taken'
end

(assert_invalid es una aserción personalizada declarada en test_helper.rb)

Crear un nuevo objeto de un modelo es también una buena forma de manejar variantes únicas de tus datos que serán irremediablemente necesarios.

Entonces ¿Fixtures o Factories?

guerra-quesosNo pienso que vaya ha haber una resolución a la discusión de Fixtures vs. Factories. Ambas son increíblemente útiles y tienen sus propias ventajas y desventajas. Conocer las limitaciones de cada una te ayudará a escoger la mejor herramienta para el trabajo.

Me estoy moviendo de regreso a fixtures despues de darles otra oportunidad, pero puedo ser perfectamente feliz en un proyecto con factories. Es bueno tener opciones.

Esta es una traducción del artículo original: [Getting Friendly with Fixtures] (https://whatdoitest.com/getting-friendly-with-fixtures)

Anuncios

La belleza de la proporción, la razón áurea en la web

Estándar

Luego de muchas conversaciones acerca de como debería ser una web, me di cuenta que para mucha gente la web continua siendo un territorio sin reglas; pese a que hay ideas bastante claras sobre principios de diseño aplicado al arte, creación de materiales impresos, desarrollo de productos, arquitectura y varias otras.

Las web modernas deben llenar no solamente las expectativas de los propietarios. Las web y aplicaciones de hoy deben también cumplir las exigencias de un público globalizado, diverso y rico en preferencias. Por ello resulta vital que se utilicen ideales de belleza tan universales como sea posible. Esos ideales de belleza son por tanto aquellos que utilizamos de forma innata y en los que la naturaleza es rica, tal es el caso de la proporción áurea.

Golden Ratio - Proporción Áurea

El número áureo (también llamado número de oro, razón extrema y media, razón áurea, razón dorada, media áurea, proporción áurea y divina proporción ) es un número irracional , representado por la letra griega φ (phi) (en minúscula) o Φ (Phi).

Además de su belleza matemática, su carácter misterioso como número irracional y la aparente armonía que otorgaba a las proporciones, los artistas clásicos utilizaron la razón áurea tras comprobar que aparecía en numerosos diseños de la naturaleza, comenzando por las mismas proporciones del cuerpo humano. Esto les llevaba a pensar que la razón áurea era algo así como un canon divino implantado en el universo. Hoy sabemos que la llamada ‘proporción divina’ tiene que ver con los procesos de crecimiento y optimización de las formas.

Esta proporción ha sido usada por pintores, escultores, arquitectos, matemáticos, escritores, fotógrafos, novelistas, cineastas, músicos y un largo etcétera en diversas épocas. También es utilizado por los diseñadores gráficos de nuestro tiempo. En lo personal encuentro interesante la idea de aplicar la razón áurea al diseño web. ¿Comó se ha aplicado? y  ¿Cómo podemos utilizarla nosotros?

Marcas y Logotipos

Hurgando un poco por la web, encontré que la proporción áurea ha sido aplicada en diseño de logotipos de varias marcas reconocidas. Estos diseñadores han sabido utilizar esta proporción para transmitir esas nociones de ‘proporción’ y ‘armonía’ que las marcas desean asociar con ellas.  Les dejo acá un enlace al artículo y algunas imágenes interesantes.

La Proporción Áurea en el diseño de logotipos (http://www.brandemia.org/la-proporcion-aurea-en-el-diseno-de-logotipos)

Pero de lo que va este artículo es del ¿cómo aplicar la proporción áurea al diseño web? así que vamos a ver algunas ideas y aplicaciones prácticas de esta proporción y algunas herramientas que nos facilitaran el ponerla en uso.

Diseño Web

Al diseñar el aspecto visual de un sitio web o la creación de imágenes en general, el dilema de elegir proporciones surge inevitablemente. Por ‘elegir proporciones’ nos referimos a la idea de diseñar un espacio que contenga la información de un sitio web o la información visual de una imagen. En ocasiones, estas decisiones se vuelven más simples al crear las cajas contenedoras de información(“div”) de forma proporcional, lo suficientemente grandes para contener la información.

Al utilizar una proporción como la proporción áurea, esta relación de aspecto no se altera por la expansión o contracción. El contenido de un sitio web puede ser mostrado en cualquier tamaño y todavía tendría sentido, ya que no se basa en el mundo físico. El colocar la información de un sitio web dentro de un div que tiene las proporciones áureas permitiría una presentación de la información que sigue las ideas clásicas de la belleza visual. Además, ya que el rectángulo de oro se puede dividir en cuadrados para crear rectángulos áureos más pequeños, la información puede ser incrustada como divs con estas proporciones una dentro de otra.

El Mito de la Lectura Superficial. Investigaciones con eyetracking (http://blog.pucp.edu.pe/item/162324/lectura-superficial)

Algunos estudios acerca del comportamiento de los usuarios mientras navegan, como el citado arriba, indican que las webs se leen desde arriba a la izquierda, en diagonal, hacia abajo a la derecha, perdiendo importancia según se va bajando. Los elementos más importantes tienen que ir siguiendo esta tendencia. Información de importancia se coloca dentro del rectángulo más grande, con información de la sub-categoría en los rectángulos más pequeños. El resultado sería un diseño espacial y visualmente agradable, con información organizada de forma conceptual por el tamaño relativo. Podemos apreciar esto en el diseño del sitio web de Twitter.

Legibilidad

No es que la gente lea menos, los sitios web todavía no están diseñados para que el usuario pueda leer textos extensos cómodamente.

LecturaLa legibilidad se define como la capacidad de una forma para poder ser descifrada y se basa especialmente en la eficiencia de la palabra visible. Existen reglas, o al menos, principios, para la legibilidad tipográfica. Para lograr textos más legibles debemos tener en cuenta estos factores:

  • La forma del tipo
  • Su organización en el espacio
  • Su tamaño (cuerpo)
  • Longitud de línea
  • Distribución de blancos: interletra, interpalabra, interlineado, ubicación del texto en relación al tamaño de la página.
  • La jerarquización de la información.

La proporción áurea también puede ser utilizada para logar mayor legibilidad, ya que nos permite establecer valores o al menos rangos para estos factores. En los siguientes artículos se nos explica mejor como podemos utilizar la razón áurea para el calculo de los factores de legibilidad.

[Cómo calcular tamaños tipográficos para Web] (http://www.cristalab.com/tutoriales/como-calcular-tamanos-tipograficos-para-web-c113111l/)

[Tipografía Básica] (http://tipografiabasica.wordpress.com/)

[Secret Symphony: The Ultimate Guide to Readable Web Typography] (http://www.pearsonified.com/2011/12/golden-ratio-typography.php)

Herramientas

Para finalizar y animarlos a que utilicen esta proporción en sus diseños, les dejo acá algunas de las herramientas que encontré y me parecieron útiles.

Golden Ratio Typography Calculator. Nos calcula a partir del ancho de línea el tamaño de la tipografía y el interlineado o bien calcular en base al tamaño de la letra. También puede calcular en base a cantidad de caracteres por línea y permite visualizar el aspecto de el punto en tal tipografía, de un listado básico de tipografías.

Type Scale. Permite previsualizar y elegir la escala tipográfica adecuada para tu proyecto y experimentar con el tamaño de la tipografía, escala y diferentes fuentes web.

The Golden Grid. Es un sistema de rejilla para web. Es producto de la búsqueda de un sistema perfecto de rejilla moderno. Su intención es ser una herramienta de CSS para los sitios web basados en cuadrícula o rejilla. Incluye ejemplos y hojas de estilo para layout, proporciones comunes para tipografía, imágenes y vídeos.

BlockLayer – Golden Ratio Calculator. Permite calcular las dimensiones de objetos proporcionales utilizando la razón áurea, para objetos rectangulares, círculos, elipses y triángulos.

Está infografía es una guía de todo lo que necesita saber. Aprender los conceptos básicos como lo que es la proporción aurea y donde se puede encontrar, además de formas prácticas de utilizarla en sus diseños. Ya sea que encuentren eligiendo una tipografía, en la edición de fotos, la creación de formas o incluso el trabajo en el diseño, pueden utilizar la razón aurea para que su diseño se vea lo mejor posible.

 

Everything you Need to Know About The Golden Ratio #infographic

You can also find more infographics at Visualistan

Proceso estructurado para desarrollo de aplicaciones web

web development tools
Estándar

Hace un tiempo ya encontré un artículo muy bueno que trata de un proceso estructurado para el desarrollo de aplicaciones web, como ya lo dice el título de este artículo. De modo que acá reproduzco ese contenido en español, espero que no le moleste a Antonio Lupetti, pero debo confesar que es un artículo excelente. A continuación el artículo.

Desarrollar aplicaciones web es un trabajo duro que requiere mucho tiempo que tienes que gastar haciendo miles de cosas. Si no utilizas un enfoque metódico, en especial un proyecto complejo, corres el riesgo de perder la perspectiva del proyecto y perder tu tiempo por nada.

Este artículo ilustra un proceso estructurado que puede ayudarte a simplificar el enfoque para desarrollar tus aplicaciones web, ahorrando tiempo y haciéndolo de forma eficiente.

Descarguen el documento N1 | Structured process you must know to develop a web application

Fases principales del proceso

En un proceso genérico para el desarrollo de aplicaciones web pudes identificar cinco fases principales:

Definición de Requisitos

Diseño

Ejecución

Prueba

Liberación

Planificación y revisión es una “fase permanente” que siguen los procesos de desarrollo definiendo un plan de proyecto compuesto por una lista de actividades las cuales tienes que revisar durante la ejecución del proyecto. Para cada actividad se debe definir un conjunto de información que servirá para su revisión, por ejemplo:

  • responsable

  • duración

  • costos

….

Denle un vistazo a estos artículos que escribí hace algún tiempo acerca de como implementar un plan de proyecto con un diagrama de Gantt usando Excel o Google Spreadsheets.

Como organizar tu plan de proyecto

Plantilla de diagrama de Gantt en Excel

Implementando un plan de proyecto y gestionando actividades con Google Spreadsheets.

1. Definición de Requisitos

In esta primera fase debes definir el alcance y necesidades de tu aplicación web en términos de lo tu aplicación debe hacer, las principales funcionalidades y requisitos técnicos:

Alcance

Para definir el alcance de tu aplicación web es suficiente con recopilar una lista detallada de las funcionalidades con una descripción clara. En este punto no es importante “cómo” se realizara esto pero si el “qué” es lo que se debe realizar.

Necesidades

Analizar las necesidades es una parte crucial del proceso de desarrollo. En este paso debes estimar tu tráfico potencial, escoger un lenguaje de lado del servidor (PHP, ASP, Coldfusion…), bases de datos, seleccionar un proveedor de servicio de hospedaje… No debes sobrestimar/subestimar tus estimaciones. Evalúa cada cosa con un balance adecuado entre tiempos, costos y objetivos.

2. Diseño

Después de la fase de definición de requisitos, debes “diseñar” tu aplicación con un proyecto bien claro. En esta fase puedes identificar los siguientes pasos:

Diseño: Mapa de la Aplicación

Un mapa de la aplicación contiene solamente información significativa y esencial acerca de la estructura de tu aplicación: paginas (representadas como bloques) y principales relaciones entre ellas. Tu mapa de aplicación debería ser algo así:

De esta forma tienes un mapa con algunas “ubicaciones” (páginas) y una “ruta” (relaciones entre páginas) las que sencillamente debes seguir en orden para proceder, página por página, para implementar tu aplicación en la siguiente fase. De esta forma ahorraras mucho tiempo, teniendo claro e la mente que es lo que debes implementar.

Diseño: Base de Datos

Ahora es el momento de diseñar la base de datos para tu aplicación. Una forma simple de hacerlo es usando modelos Entidad-Relación. En general puedes seguir este orden: define primero tablas, luego atributos y relaciones entre tablas. Tu modelo ER debería parecerse a este:

1:1 expresa la cardinalidad de una relación (en este caso por ejemplo 1 usuario es asignado solamente a 1 tarea, 1 usuario vive solamente en una ciudad). Para más información acerca de este tema revisar en mis artículos más viejos:

Definiendo el modelo de entidades y relaciones

Un enfoque correcto para definir relaciones entre tablas de base de datos

10 artículos útiles acerca de diseño de bases de datos

Diseño: Estructura de la Página

El siguiente paso es hacer una maqueta de tu página, identificando todas las secciones principales usando un nombre (por ejemplo #header, #navbar, #mainContent, #sidebar).

Diseño: Lenguaje del lado del servidor

Teniendo en mente la orientación a objetos para el desarrollo de tu aplicación, puedes definir clases, funciones y toda la funcionalidad el lado del servidor que necesites. Recuerda … esto no es la “ejecución” pero si una forma de tener una “guía” para o que deberás implementar en la siguiente fase.

Diseño: JS Framework

En este paso seleccionamos un JavaScript Framework (jQuery, Scriptaculous, MooTools…), que proveería las funcionalidades que quieres implementar (arrastrar y soltar, animación, efectos …) recopilando una lista de que fucnionalidades específicas están relacionadas con una o más páginas en tu aplicación.

En este punto la fase de diseño esta completa. Puedes iniciar con tu ejecución.

3. Ejecución

Ahora el verdadero reto porque “ejecución” es la realización de tu aplicación. Puedes dividir esta fase en los siguientes pasos:

Ejecución: Base de Datos

Crea una nueva base de datos y escribe el código SQL para definir tus tablas, atributos y relaciones. En el pasado dedique algunos artículos a este tema. Revisen los siguientes enlaces para mayor información:

Como usar PHP y SQL para crear tablas de base de datos y relaciones.

Creación de tablas y relaciones con SQL.

Ejecución: HTML

Usa la maqueta de la página para implementarla en código HTML.

 


Este es el momento para adicionar al HTML todos los elementos que necesites en las secciones identificadas durante la fase de Diseño. Por ejemplo si las secciones de contenido principal tiene un artículo con un título, un texto en el cuerpo y algunas etiquetas, agrega estos elementos:

 

 

 

Ejecución: CSSUna vez lista la estructura principal, inicias a escribir código CSS para adicionar estilos a tu aplicación. Si necesitas algunas sugerencias de como escribir mejor el código CSS revisa alguno de estos artículos:

CSS: enfoque semántico en convención de nombrado.

Guías útiles para mejorar tu CSS y su mantenibilidad.

Ejecución: Lenguaje del lado del servidor

Implementa las clases de la aplicación, funciones, interacciones con la Base de Datos, consultas, y cualquier cosa que requiera interacción del lado del servidor.

Ejecución: JavaScript

Implementa las fucnionalidades AJAX usando el framework que escojiste en la fase de diseño.

4. Prueba

Durante esta fase debes someter el código de tu aplicación a varias condiciones de ejecución (por ejemplo diferentes navegadores). Tu objetivo es detectar todos los errores en tu aplicación antes del lanzamiento final.

Recuerda, este proceso debe ser meticuloso y requiere mucha paciencia. Probar cada página y cada funcionalidad (también en este caso puede ayudarte tu mapa de aplicación para proceder con cierto orden). Si encuentras un error durante la pruebas de ejecución, corrigelo modificando el código y entonces realizas la validación final (una prueba posterior) del código.

5. Liberación o lanzamiento

 

¡Finalmente estas listo para lanzar tu aplicación! Publícala en un directorio de prueba y realiza una prueba final. Si todo funciona correctamente entonces procede al lanzamiento final.

  • El contenido de este artículo, incluyendo imágenes y referencias, es una traducción de original que puede encontrarse en la siguiente dirección:

http://woork.blogspot.com/2009/01/structured-process-you-must-know-to.html

PHP 5.+ el C++ de la web

Estándar

Me parece una analogía interesante este título, porque C++ es uno de los lenguajes de programación mas extendidos de geográficamente hablando y en lo que a usos y aplicaciones compete. Casi cualquier software que podamos imaginarnos que utilizamos hoy guarda alguna relación con este lenguaje. Esto es porque compiladores, interpretes, maquinas virtuales, frameworks o sistemas operativos esta desarrollado usando C, C++ o algún descendiente o derivado de estos.

Pero el objetivo no es hablar de C++, hablaremos de PHP. Entonces ¿porque la analogía? se preguntaran algunos. Pues básicamente porque PHP es el lenguaje más extendido en la web. Cuando el internet era como el viejo oeste, antes de que se descubriera el oro en el, PHP hacia su debut en este terreno. La evolución de PHP me parece un tanto curioso ya que nace para la web y luego se va convirtiendo en un lenguaje de propósito general. Casi la mayoría de los lenguajes de programación ha seguido un curso inverso al de PHP, desde lenguaje de propósito general hasta desarrollar extensiones o versiones para web. Mucho de lo que se usa en la web esta escrito en parte en PHP, entre esto encontramos paneles de administración, clientes de bases de datos, clientes de correos, servicios de datos, gran parte de nuestras páginas favoritas, CMS, etc.. para darnos una idea.

Un dato curioso

Casi siempre que me encuentro con un viejo desarrollador que programa con PHP noto en el una cierta resistencia al uso de las nuevas características del lenguaje. Las encuentra poco relevantes o simplemente no esta interesado en ello. Es como si para ellos el tiempo se hubiese congelado en la evolución de este lenguaje, y avocan siempre por sus ancestros menos evolucionados. Pues les tengo una noticia, la extinción es algo inminente, porque es el curso que toma todo en el mundo, desde los seres vivos hasta la tecnologías se ven relegados por sus versiones mejor adaptadas, y el rechazar esta realidad nos convierte en parte del conjunto destinado a extinguirse. No digo que no haya que saber de lo que precede a lo actual, “nunca hay que olvidar de donde se viene”, pero al igual que la vida en nuestro entorno de trabajo no podemos vivir en el pasado mientras el mundo exterior continua su marcha.
Continúan las semejanzas

Dirán algunos ¿en que se parece PHP a C++? Pues les diré que tienen algunas características comunes. Ambos soportan programación procedimental, funcional y orientado a objetos, aunque hay diferencias en la forma en que implementan la orientación a objetos dado que este desarrollo de PHP se ha visto más influenciado por lenguajes como Java. Al igual que C y C++, PHP cuenta con un gran conjunto de librerías y extensiones para todo tipo de interacciones, servicios web, interacción con el shell del sistema operativo, manipulación de archivos, edición de imágenes, tratamiento y manipulación de cadenas y más.

Creo que una de las grandes ventajas de en lo que a funcionalidad se refiere es el número de librerías para interacción con bases de datos. En este sentido el desarrollo de PDO puede darle una ventaja más en esto al pasar de muchos controladores para cada SGBD a una capa de abstracción de acceso a datos más ligera y fácil de implementar para cada manejador, es lo que JDBC en Java, provee por ahora menos funciones pero permite una interacción mas limpia y resulta fácil de migrar. Algunos aducirán que MDB solucionaba esto, pero esto es algo que no es un script es parte del lenguaje en si mismo, así que dejemos de intentar reinventar la rueda.

Otras de las similitudes es que PHP esta disponible en casi todas las plataformas, puede bien ser usado como interprete o como modulo con un servidor web entre estos IIS y Apache. es decir que pueden correr sus programas en donde sea. Gracias a algunas extensiones es posible programar aplicaciones de escritorio utilizando PHP GTK.

El soporte para programación orientada a objetos es relativamente reciente, en las últimas versiones estables disponibles, estas características están bastante maduras. Aunque para aquellos que conocieron como se trabajaba con clases y objetos ne la versión 4 se darán cuenta de que es algo muy distinto en versión 5 o superior. Pero no es mi objetivo mostrar acá las nuevas características del lenguaje, es mejor si eso lo investigan uds. mismos consultando el manual siempre disponible en php.net. Hablaremos sin embargo de algunas de las características y tecnologías prometedoras y algunos buenos y malos hábitos.

Dejando los malos hábitos
Otras de las semejanzas PHP – C++ es que si no se tienen buenos hábitos de programación y codificación, y no suele documentar mucho su código, el mantener y depurar un programa o modulo puede resultar una tarea infernal. Para los que han trabajado con C o C++ se darán cuenta de que muchos de los errores provienen de aspectos mal gestionados o no gestionados por el programador como la memoria, los tipos de datos, lo valores contenidos en  las variables en un momento dado y otros. En PHP se tienen casi una cantidad de problemas semejante, el hecho de que PHP sea un lenguaje débilmente tipado conlleva una cantidad de problemas con ello, es una arma de doble filo.

Por ejemplo, si bien puedo utilizar una variable para contener distintos tipos de dato al realizar operaciones con la misma necesito validar el tipo de dato contenido, su previa declaración y existencia, para saber si es posible o no aplicarle o utilizarla con una función en particular. Igualmente el retorno de funciones y métodos no tiene un tipo especifico, si lo tiene. con lo que no se puede tener certeza del resultado o del valor retornado, si se desea utilizar posteriormente. Existe ademas una cierta cantidad y tipos de errores que pueden producirse en tiempo de ejecución que no causan un termino o la no ejecución de un bloque de código, lo que puede resultar en que se llegue a un resultado no deseado o se desencadene un error que se pueda frenar la ejecución.

Análogo a los punteros de C++ en PHP el uso extensivo de matrices es uno de sus grandes potenciales y también una de los grandes problemas, por falta de una correcta gestión. Debemos tener presente siempre que en entornos de producción hay limites a la cantidad de memoria disponible, aunando a esto el uso incorrecto de las claves se pueden llegar a tener muchos problemas al usar matrices. PHP no es Fortran en lo que a gestión de matrices y potencia de cálculos vectoriales se refiere, pero cuenta con una gama de funciones bien surtida para la manipulación, búsqueda y ordenación ser refiere.

Otra mala práctica, remanente en unos pocos programadores, es el embeber html  u otro código dentro del script php. He dicho embeber html en el php y no embeber php en el html que resultan dos cosas diferentes, algo que algunos terminan confundiendo. El embeber es una práctica que debe limitarse al mínimo posible. No solo porque no es “elegante”, sino porque ya hay motores de plantillas más o menos maduros que facilitan esto, porque facilita el dar mantenimiento al código y separar nuestras capas de datos o modelo de negocios de nuestra capa de presentación, hace mas simple los desarrollos futuros.

Debemos aprender a escuchar y poner en práctica las recomendaciones de Zend y la comunidad de desarrolladores. Si una función esta obsoleta, créalo es obsoleta y use el reemplazo. Si se dicen que una determinada variable es el remplazo de otra úsela en sus programas. Si esta usando una versión de PHP no intente hacerlo funcionar como una versión inferior a menos que sea absolutamente necesario. Al menos lea las referencias de funciones, novedades y diferencias de la versión que utiliza. Usemos las cosas para lo que son y como debe ser, las expresiones booleanas deben recibir valores o expresiones booleanos, los que lo hacen saben de lo que les hablo, usar variables no definidas, con valores nulos, numéricos o de cadena cuyo valor pueda ser evaluado como booleano. Se deben usar los tipos de dato correctamente, validar o forzar su tipo si es necesario y evitar las asignación de datos de otro tipos en esas variables. Debe tenerse presente la versión para la que se esta escribiendo el código. A partir de PHP 5 existe un nuevo nivel de error E_STRICT que incluye tipos de errores de tipo estricto de la versión esto puede ayudarnos a detectar y corregir aquellos segmentos en que estamos usando código no acorde a las últimas versiones estables, también esta disponible la función version_compare que algunos herramientas CASE incluyen en el código generado para validar la ejecución del en dependencia de la versión del interprete.

Aprendamos a trabajar con objetos, como debe ser. No mezcle sintaxis de versiones diferentes.  Establezca el tipo de objetos en los argumentos de los métodos. Saquemos provecho real de características como la visibilidad, la unificación de constructores y los métodos especiales, asignemos los valores por defecto a los parámetros que puedan ser opcionales. Dejemos de usar los objetos como arreglos, prácticas como la asignación y uso de atributos no declarados no son recomendables. Procuremos mantener separadas nuestras capas de presentación, modelo de negocios y acceso a datos. Saquemos máximo provecho de los paradigmas de programación soportados por el lenguaje utilizando el tipo adecuado al contexto o problema solucionar.

Buenas prácticas

Finalmente creo que estos dos lenguajes (PHP y C++) si tienen varias similitudes, no solo en los problemas que se presentan al programar con ambos, sino también en las bondades que cada uno provee. PHP es un lenguaje con gran potencial, pero al igual que las demás cosas creadas por el ser humano todo depende del uso que se le de. Con el Objetivo de que mejoren en los aspectos que necesiten les dejo un par de enlaces donde pueden explorar las mejoras prácticas que cada quien puede usar en sus proyectos o en su estilo de programación. Mejores prácticas de desarrollo en PHP, Guía de buenas practicas en PHP, Manual de phpDocumentor, Zona PHP – ¿Qué esperar de PHP 5 ?.