Framework PHP

Un arsenal de técnicas y herramientas para desarrollar aplicaciones web con PHP

Nos trasladamos

leave a comment »

Este blog se traslada a http://codice.aletia8.com/, si te gusta lo que aquí se habla podemos seguir la conversación allí.

Written by juananruiz

septiembre 16, 2008 at 11:25 pm

Publicado en General

El arte de programar

leave a comment »

Estamos acostumbrados a pensar por comparación y a aprender con parábolas. Esto a menudo es de gran ayuda, pero a la larga nos impide dar el salto cualitativo del aprendiz al maestro. En informática esta advertencia tiene un profundo significado. Tendemos a comparar los ordenadores con personas o con máquinas, luego aplicamos estas comparaciones para intentar comprender lo que es un ordenador, pero un ordenador no es ni una cosa ni otra y no podremos entenderlo (y por tanto dominarlo) hasta que no dejemos de lado esas comparaciones, esas muletas que nos ayudan a aprender.

Central Solar Solucar

Quien escribe esto se haya muy al principio de ese camino de aprendizaje, a veces he tenido un vislumbre de la magia de un algoritmo o de la potencia de un paradigma informático, en esos momentos se queda uno asombrado ante la elegancia y la simplicidad que subyacen en un simple fragmento de código. Pero pronto me ofusco de nuevo y tengo que volver a las comparaciones y las parábolas para seguir avanzando. En estas páginas uso muchas comparaciones, pero no quedaros con ellas, no penséis que todo puede ser aprendido así, tampoco penséis que vosotros no podréis aprenderlo, si nos lo proponemos en firme y actuamos en consecuencia algún día daremos ese salto. Entonces dominaremos el arte de programar.

Algunos consejos rápidos

  • Aprende bien el lenguaje: no te quedes con las cuatro estructuras que conoces y las veinte funciones que manejas, hay mucho más hay dentro, cada estructura tiene su lugar, de cada función puedes aprender algo. Intenta aprender algo nuevo cada día.
  • Lee mucho código. ¿Te imaginas un novelista que nunca leyera libros? Lee código, mejor si es bueno, pero hasta del malo se aprende. Intenta entenderlo, pregúntate porqué está hecho así. Una buena fuente de código son los frameworks abiertos.
  • No dejes de practicar: entre proyecto y proyecto practica con piezas pequeñas, crea pequeños algoritmos o programas que hagan esto o aquello. Un buena idea es ir creando tus propias herramientas. Primero algo modesto, que resuelva pequeñas tareas tediosas, pero no tienes porqué quedarte ahí, puedes crearte tu propio editor, o, quien sabe, algún día tu propio lenguaje, al fin y al cabo así suelen empezar la mayoría de los proyectos de código abierto.
  • Aprende y aplica nuevos conceptos: no hagas siempre lo mismo, te quedarás atrás y te aburrirás.
  • Conoce y utiliza nuevas herramientas: no digo que cambies de editor cada día, pero, ¿sabes lo que es un gestor de versiones?¿te suenan de algo los tests unitarios?¿usas alguna herramienta para validar html o css?
  • Aprende más de un lenguaje: esto es algo más a largo plazo, pero no lo pierdas de vista. Sólo manejando varios lenguajes llegarás algún día al fondo de la cuestión.

Enlaces recomendados

Written by juananruiz

octubre 2, 2007 at 11:18 pm

Publicado en General, Programación

Código samurai: como programar mejor

with one comment

Este artículo es un resumen de los consejos ofrecidos en el artículo Free Programming Tips are Worth Every Penny (Consejos gratuitos para programadores que valen su peso en oro) por Will Shipley.Dibujo de samurai. Autor: Eugene Collache

Sigue el Código Samurai

Los antiguos samurais, cuando luchaban, se pasaban horas observándose mutuamente hasta que repentinamente uno de ellos lanzaba un sólo golpe y derrotaba al contrincante.

Cuando vayas a programar, antes de nada, piensa, luego piensa un poco más, hasta que tengas una idea de conjunto de todo el proyecto. Luego piensa en un problema concreto con el que vayas a comenzar a programar, piensa de nuevo en el conjunto y en como encaja esta pieza en él. Entonces comienza a escribir código. No escribas una sola línea de código hasta que no tengas claro que es lo que vas a hacer.

Si eres de los que necesitan escribir para pensar: escribe en una carpeta aparte, crea tantas nuevas carpetas como bocetos necesites y cuando ya tengas el dibujo completo entonces escribe en la carpeta o proyecto definitivo; reutilizando los fragmentos de código que son de calidad y reescribiendo de nuevo lo que haya salido emborronado.

Escribe todo el código “en limpio” la primera vez que lo escribas. No hagas una chapuza pensando que lo arreglarás más tarde, de hecho nunca lo arreglarás. Utiliza clases para todos. Usa tipos enumerados.

Escribe código robusto y “a prueba de balas” desde el principio. Piensa en todo lo que podría causar un fallo y toma medidas preventivas como si el fallo ya hubiera ocurrido.

Cada vez que retoques tu código para añadir funcionalidades o corregir un fallo aprovecha para hacer limpieza. Haz limpieza todo el rato. Pasa el paño cada vez que veas una mota de polvo afeando tu código.

Menos código casi siempre es mejor. Mejor para depurar, mejor para que lo entiendan otro programadores o tu mismo en el futuro, menos código son menos fallos. No añadas funciones adicionales a una clase pensando que las necesitarás en el futuro. Escribe sólo lo que necesites ahora. Cuando necesites contemplar nuevos casos escribe una función más genérica, que admita parámetros, pero no lo hagas hasta que no estés usando esa función en dos o más lugares de tu aplicación.

No te obsesiones con la velocidad y la eficiencia de tu código al principio. Tu tiempo de programador es caro, el hardware es rápido y barato. Cuando tu código funcione y esté depurado podrás hacer test de rendimiento y encontrar los cuellos de botella que merece la pena optimizar.

Written by juananruiz

septiembre 21, 2007 at 11:57 pm

Publicado en Programación

Lista de frameworks MVC en PHP

with 3 comments

Written by juananruiz

septiembre 21, 2007 at 9:09 am

Publicado en Más frameworks

Características de la programación orientada a objetos

with one comment

Extraído de Wikipedia: Programación orientada a objetos.

Hay un cierto desacuerdo sobre exactamente qué características de un método de programación o lenguaje le definen como “orientado a objetos”, pero hay un consenso general en que las características siguientes son las más importantes (para más información, seguir los enlaces respectivos):

  • Abstracción: Cada objeto en el sistema sirve como modelo de un “agente” abstracto que puede realizar trabajo, informar y cambiar su estado, y “comunicarse” con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.
  • Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.
  • Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
  • Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en “tiempo de ejecución”, esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en “tiempo de compilación”) de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
  • Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementar su comportamiento. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple; esta característica no está soportada por algunos lenguajes (como Java).

Written by juananruiz

septiembre 19, 2007 at 5:40 pm

Publicado en Conceptos básicos OOP, OOP

Definición de programación orientada a objetos

with one comment

Este blog se traslada a http://codice.aletia8.com/, si te gusta lo que aquí se habla podemos seguir la conversación allí.

Basado en Wikipedia: Programación orientada a objetos.

La Programación Orientada a Objetos (POO u OOP) es un paradigma de programación que define los programas en términos de “clases de objetos”, objetos que son entidades que combinan estado (propiedades o datos), comportamiento (procedimientos o métodos) e identidad (propiedad del objeto que lo diferencia del resto).

La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.

Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases (e incluso entre objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos). A su vez, dispone de mecanismos de interacción (los llamados métodos) que favorecen la comunicación entre objetos (de una misma clase o de distintas), y en consecuencia, el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan (ni deben separarse) información (datos) y procesamiento (métodos).

Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase es la definición de un objeto. Cuando se programa un objeto y se definen sus características y funcionalidades, realmente se programa una clase.

Written by juananruiz

septiembre 19, 2007 at 5:29 pm

Publicado en Conceptos básicos OOP, OOP

Reglas para el diseño orientado a objetos

leave a comment »

1. Buscar las relaciones de herencia identificando los datos y/o funciones que son comunes a varios objetos.
2. Buscar las relaciones de inclusión identificando grupos de datos y/o funciones que se complementen en un sólo objeto.
3. No intentar nunca representar las relaciones de inclusión en los diagramas de herencia y viceversa.
Receptor Telefunken 4. Debe pensarse en la aplicación como un conjunto de objetos que colaboran.
5. Se deben diseñar primero los objetos y sus ficheros de cabecera, para implementar más tarde los métodos descritos en los ficheros de cabecera.
6. Se debe poner toda la funcionalidad en los objetos, si una función no parece encajar en ningún objeto se debe aplazar su desarrollo hasta que aparezca un objeto adecuado.
7. Se debe comenzar con los objetos sencillos y continuar añadiendo objetos a medida que parezcan evidentes.
8. La utilización de un tipo como parámetro o como estructura de campo es un problema en potencia. Normalmente el tipo debe ir implícito en el objeto, quizás estamos intentando implementar un objeto que realice dos tareas cuando deberíamos utilizar dos o más objetos.

Written by juananruiz

septiembre 13, 2007 at 7:53 pm

Publicado en OOP