Compartelo/Guardalo

A continuación verán una lista de 10 cosas que no se deben hacer al implementar programación orientada a objetos enfocándonos en el lenguaje PHP. Esta lista acompaña al post de 21 errores comunes programando en PHP.

1. Usar variables globales dentro las clases: una de las ventajas más importantes de la programación orientada a objetos es la reusabilidad de los códigos. Al usar variables globales ($_GET, $_SESSION, $_POST, $_COOKIE, global) dentro de las clases, esta se ve comprometida considerablemente. La razón es que todos los proyectos no tienen las mismas variables globales.
2. Mezclar código HTML en la definición de las clases: es una de las cosas que me sorprenden cada vez que la veo. Es inaceptable que esto se le haya ocurrido a algunos. Al mezclar HTML en el código PHP se compromete la reusabilidad de la clase, no todos los proyectos tienen el mismo código HTML.
3. Imprimir salida (echo) dentro de las clases: aunque esto se parece a la anterior, me refiero a los echo o similares dentro de los métodos. Si una clase no está destinada para emitir salida no lo debe hacer. Para eso muchos utilizamossistemas de plantillas.
4. Identificadores de clases, métodos y propiedades sin sentido: un identificador siempre debe ser lo más descriptivo posible. A muchos le gusta usar identificadores increíblemente irrelacionados con su propósito. Esto compromete enormemente la lectura de un código. (Mira las reglas de codificación en PHP via Cristal Lab)
5. Mezclar uso de versiones de php en una misma clase: a partir de la versión 5 de PHP, la programación orientada a objetos se puede implementar de una manera más formal, pues se introdujo los modificadores de visibilidad public, private, protected. Aparte de que se pueden crear clases de alto nivel (clase Abstractas) y métodos abstractos con la palabra reservada abstract. También se pueden definir los métodos y propiedades estáticas formalmente con la palabra reservada static. Mezclar la programación orientada a objetos en PHP 4 (donde todo era publico) con la de PHP 5 hace un código “sucio”. Consejo: elige una de las versiones y programa para ella.
6. Más de una clase en un mismo archivo: definir distintas clases en un mismo archivo es otra de las cosas que no se debe hacer. Las clase se han de componer lo más reusables posible y si puedes nombrar al archivo con el nombre de la clase muchísimo mejor. Sigue el camino de los grandes lenguajes como: Actionscript, Asp.net, Java entre otros.
7. No hacer pruebas unitarias a las clases: al terminar de codificar una clase recuerda de hacer pruebas unitarias para asegurar el correcto funcionamiento de clase. Esto es simplemente probar todos los posibles caminos que pueda tomar un estado (propiedad), parámetro de método, etc para que la clase no “explote”.
8. Todos los métodos y las propiedades publicas en una clase de PHP 5: los programadores novatos cometen el error de definir todos los métodos y propiedades como públicos, por desconocer las ventajas de los modificadores visibilidad. En PHP este es un problema grave porque no hay tipeado de datos. El problema de las propiedades públicas es que no podemos controlar de manera fácil el tipo de datos que contiene por lo que nuestra clase pudiera explotar por un tipo de dato inesperado. Si no estas seguro de que visibilidad le debes poner a una propiedad hazla privada. Valida los tipos de datos de las propiedades al menos de una manera básica.
9. Duplicación de métodos para ocultar falla de lógica: A diferencia de otros lenguajes como Java y C++, PHP no admite la sobrecarga de métodos. Al menos no de la manera tradicional. Esto, sin embargo, no es excusa para duplicar métodos sólo porque un dato cambia para la operación que éste realiza.
10. Variables de configuración dentro de las clases: Los datos de configuración de base de datos, web services y otros deben ir en un archivo de configuración aparte, NO dentro de la clases que hacen uso de estas. Aunque se admite en clases que sea exclusivamente para ello.

Compartelo/Guardalo

Los errores están divididos en 3 partes, siendo los primeros los mas “benignos” y los últimos, “críticos”. Comentare los más importantes.

Parte 1

Uso impropio del printf

Abusando de la semántica
Esto es, básicamente, no usar una misma variable para guardar en un momento números, en otras cadenas de texto, o hacer funciones que por parámetros reciban variables de varios tipos de datos.
Una adecuada forma es la declaración de variables antes de usarlas, mantener un mismo tipo de datos para todas las variables, etc.

Falta de documentación por línea
En pocas palabras, es saber crear comentarios adecuados, no hacer un comentario por línea, pero tampoco una palabra por función, además de hacerlos comprensivos, lógicos y no estupidos, como:

Código :

//Esta función imprime
function imprimir($datos){
    echo $datos;
}

Creación de demasiadas variables temporales

Rescribir funciones existentes de PHP
Esta es muy común, si no sabes que hace PHP y tienes un problema para lo que PHP tiene ya una función que lo soluciona, pero haces una función propia que haga lo mismo.
Hay que leer 

No separar el lado del cliente del lado del servidor
Lo que muchos principiantes hacen, llenar de echos el código HTML, no hacer plantillas, ni siquiera funciones para separar lógicamente la parte de PHP de la parte de HTML.

Usar paradigmas del siglo pasado
PHP es muy flexible, por lo que puedes usar aun cosas como “if endif” o “while endwhile”, pero eso es taaan viejo, como usar GOTOs.
Otro ejemplo similar es seguir usando variables globales al recibir valores de formularios, hay que actualizarse.

Parte 2

No seguir convenciones básicas en los nombres
Poner cosas como $xdb2 a una variable o convfunxml() a una función, son practicas muy malas, que llevan al desastre al mantener una aplicación. En las variables, lo mas recomendado es mantener “simples” las cosas, mientras que en las funciones, hacerlas lo mas “verbales” posible seria lo mejor.

Usar de una manera horrible la conexión a bases de datos
Gente que trae todos los resultados de una consulta solo para ver si es mayor que cero, hacer la consulta columna por columna en vez de traer un recordset completo, usar PHP para ordenar los resultados en vez de SQL, esas son formas horribles de conectarse a una DB.

Falta de detección de errores
Asúmanlo, ocurrirán errores, sea porque al hosting se le lleno la tabla de temporales, porque se acabo el espacio en disco que tenían, porque un usuario encontró una manera de saltarse una validación de datos o por lo que sea, siempre, en cuestiones delicadas (Consultas, escritura al disco, etc) hay que hacer control de errores.

Sobrepasarse con la programación orientada a objetos
PHP aun no esta 100% orientado a objetos de una manera estricta, de modo que aunque usemos MVC, frameworks como PEAR entre otras muchas cosas, podemos llegar a sobrepasarnos en el uso de POO en PHP, creando una serie de clases, métodos y propiedades exagerada que probablemente nos den mas problemas que beneficios en el futuro. No hay que exagerar

Mal uso de las expresiones regulares
Aunque es un tema muy avanzado, las expresiones regulares son muy útiles en muchos casos donde debemos analizar cadenas de texto raras para obtener resultados; pero son lentas, por lo que no hay que usarlas para tooodo, como reemplazar patrones simples en cadenas, buscar un carácter, etc.
Existen muchas funciones de manejo de strings ya hechas y más fáciles de usar.

Programar en PHP como si fuera otro lenguaje
Mucha gente que empieza en PHP, viene de otros lenguajes y con ello, traen también sus mañas y costumbres de acuerdo a cada uno de ellos.
Los de Perl que les fascina programar todo en una sola línea, los de Java que directamente hacen un framework orientado a objetos de modo que en el código HTML solo haya $pagina = new Pagina();, los que se ponen a renombrar o rescribir funciones inherentes de PHP, etc. De nuevo, hay que leer.

No ser consciente de la seguridad
PHP puede ser programado elegante o terriblemente… y aun así dar el mismo resultado a los ojos del usuario; cosas como las protecciones básicas de seguridad son olvidadas.
No permitir que, en un campo que se usara en una consulta a una DB, un usuario ponga comillas simples o punto y coma, tomar todos los valores raros y hacerles “escape” (Es decir, poner un backslash en frente de ellos) y en general validar dentro de PHP todos los valores que puedan haber sido escritos a mano es una responsabilidad nuestra.

Parte 3

Cortar y pegar; el camino incorrecto
Siempre haces la misma función de validar un correo electrónico, la misma de conectarse a la base de datos, etc… ¿Copias y pegas cuando lo haces?
Es mas optimo crear una librería de tus propias funciones, también puedes usar librerías como PEAR y demás, pero recuerda, solo usa librerías de una fuente conocida o crea las tuyas.

No tener guías de estilo de codificación en un proyecto
Iniciar proyectos “por mis huevos” siempre ha sido un error; cuando inicias un proyecto, sin importar si eres tú solo o tienes un grupo de trabajo, hay que definir unos lineamientos de codificación.
Que variables son globales y como deberían ser marcadas como global, la estructura de las carpetas de código, convenciones de los comentarios, procesos de documentación, etc.

No hacer una revisión de código
Revisar nuestro código después de hecho, ver que hace, que se puede mejorar, etc, es algo que siempre se obvia, mucho mas en nuestra cultura donde todo es “urgente” (Sobre todo hacer prilouders).
¿Cuál era el propósito de X código?, ¿Cómo se relaciona el archivo X con los demás en el proyecto?, ¿Cómo verifica los errores el programa?, ¿Dónde podría encontrar errores el usuario?… etc.

Hacerle “hacks” al código PHP abusando de fallos de diseño
Tu lo sabes, tu sabes cuando estas haciendo un código feo, sabes cuando estas solucionando algo de la peor manera, sabes cuando estas metiendo a las patadas un código para que algo funcione… no lo hagas, recapacita, piensa en los niños.

Excluir al usuario del proceso de diseño
El usuario, ese engendro infernal que nos hace eliminar, corregir, cambiar, actualizar, repetir, borrar y maldecir. ¿Por qué no lo metemos al proceso, hacemos prototipos de prueba, le mostramos todo, vemos si vamos por buen camino? La mayoría de problemas con los usuarios finales es por culpa de nuestra discriminación (con razón) hacia ellos… Cada vez que ignoras a tu usuario, Dios le quita un punto y coma a una parte aleatoria de tu código.

No apegarse al plan del proyecto
¿Seguiste el análisis, diseño e implementación como estaban planeados?, de hecho, ¿Lo hiciste si quiera en ese orden?; cuando se planea un proyecto y en un punto debes salirte del esquema planteado, sabes que las cosas irán mal.

Perderte en el tiempo
Los programadores, por defecto, son optimistas; “Si, eso sale en un mes”, decimos.
No subestimes la complejidad de nada, tiende a pedir el doble de lo que necesitas, de cualquier manera, siempre lo querrán en la mitad del tiempo. Conocete a ti mismo, conoce tu trabajo, pide el tiempo real, pide mas que eso y se conciente de cuanto código llevas, cuanto te falta y cuanto tiempo tienes.

No solo a PHP aplican estos “errores comunes”, pero de cualquier manera tenerlos en cuenta muy seguramente te ayudara en la mayoría de proyectos que inicies.
Aunque claro, siempre hay gente que jamás cae en estos errores.

¿Como tu?

Compartelo/Guardalo

Esto puedo confundir mucho ya que pareciera que fuera parte de la replicación pero no es así, realmente es una base de datos sólo lectura, estática basada en una base datos normal (fuente).

En la parte de abajo hay un ejemplo reemplacen la información por sulla y aparecerá ya base datos bajo la carpeta de Database Snapshots.

Cuál es su función:
Pueden ser utilizados para los informes. Asimismo, en el caso de un error del usuario en una base de datos de código fuente, puede restaurar la base de datos fuente al estado en que estaba cuando se creó el snapshot.

La pérdida de datos se limita a las actualizaciones de la base de datos desde su creación de la instantánea. Además, la creación de una snapshot de base de datos puede ser útil inmediatamente antes de hacer un cambio importante de una base de datos, como cambiar el esquema o la estructura de una tabla.

Tiene 3 posibles usos:

• Mantener los datos históricos para la generación de informes (Reporteria)
• Protección de datos de errores de usuario (Backup).
• La gestión de una base de datos de prueba (Base datos de pruebas)

Importante:
Database snapshots, fueron introducidos en SQL Server 2005, sólo están disponibles en las ediciones Enterprise de SQL Server 2005, SQL Server 2008 y SQL Server 2008 R2.

En la parte de abajo hay un ejemplo reemplacen la información por sulla y aparecerá ya base datos bajo la carpeta de Database Snapshots.

Crear una base datos snapshots

SNAPSHOT CREATE DATABASE AdventureWorks_dbss1800 ON
( NAME = AdventureWorks_Data, FILENAME =
‘C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data\AdventureWorks_data_1800.ss’ )
AS SNAPSHOT OF AdventureWorks;

Si hacer un restore de en base a un SNAPSHOT seria de la siguiente manera:

Restore

USE master
RESTORE DATABASE AdventureWorks FROM DATABASE_SNAPSHOT = ‘AdventureWorks_dbss1800′;
GO

Que permisos necesito para crear una:
La única manera de crear una SNAPSHOT CREATE DATABASE es utilizar Transact-SQL. Cualquier usuario que pueda crear una base de datos puede crear una snapshot de base de datos, sin embargo, para crear una instantánea de una base de datos reflejada, usted debe ser un miembro de la función de servidor sysadmin.

Articulo de referencia:
http://msdn.microsoft.com/en-us/library/ms175469.aspx
http://msdn.microsoft.com/en-us/library/ms187054.aspx
http://www.sqlcoffee.com/Tips0004.htm

Compartelo/Guardalo

Los procesadores multinúcleo ya están aquí. Los procesadores multinúcleo solo estaba disponibles para servidores y PCs de escritorio. Pero ahora, ya se están usando en teléfonos móviles y PDA, lo cual genera grandes ventajas en relación con el consumo de energía. En respuesta al aumento de disponibilidad de plataformas con procesadores multinúcleo, Parallel Language Integrated Query (PLINQ) ofrece una manera fácil de sacar partido del uso de hardware paralelo, incluidos equipos tradicionales con varios procesadores y la última ola de procesadores multinúcleo.

PLINQ es un motor de ejecución de consultas que acepta cualquier consulta LINQ to Objects o LINQ to XML y usa automáticamente varios procesadores o núcleos para su ejecución cuando estos están disponibles. El cambio en el modelo de programación es minúsculo, lo cual significa que no es necesario ser un gurú para usarlo.

Usar PLINQ es casi exactamente lo mismo que usar LINQ to Objects y LINQ to XML. Puede usar cualquiera de los operadores disponibles.

Ejemplos con conexión a base de datos.

Linq
var query = from c in db.Customers
where c.Country == “USA”
orderby c.CompanyName
select new { c.CustomerID, c.CompanyName };

plinq
var query = from c in db.Customers.AsParallel()
where c.Country == “USA”
orderby c.CompanyName
select new { c.CustomerID, c.CompanyName };

El genio Joe Duffy es el responsable de desarrollo del equipo Parallel FX de Microsoft y participa habitualmente en el blog www.bluebytesoftware.com/blog. Está escribiendo un libro, Concurrent Programming on Windows, que va a ser publicado por Addison-Wesley.

Compartelo/Guardalo

Bueno les dejo el codigo y les mando un afectuoso saludo. Y gracias a RCK, por la ayuda.

¡Hasta pronto!

Compartelo/Guardalo

Si bien es cierto que muchas aplicaciones que se hacen, como las de gestión por ejemplo, no suelen tener que sacarle partido, no es menos cierto que en muchas circunstancias nuestras aplicaciones deben poder sacarle el máximo rendimiento al hardware del que disponemos.

Desde hace unos años lo más habitual en cualquier ordenador corriente es que disponga de un procesador con al menos dos núcleos. En servidores o máquinas destinadas a tareas más demandantes es muy frecuente que haya varios procesadores con al menos cuatro núcleos.

La tendencia es que cada vez haya más núcleos en los procesadores, ya no sólo por rendimiento sino por las ventajas en cuanto a ahorro de energía, temperatura y las limitaciones existentes en cuanto a aumentar la velocidad de frecuencia de reloj.

Esto implica que casi cualquier aplicación pueda trabajar en entornos con múltiples núcleos, lo que hace realmente importante sacarle partido a la programación multi-subproceso.

Anteriormente, y aquí viene lo importante, para aumentar el rendimiento de una aplicación bastaba con moverla a una máquina con un procesador más rápido. Sin embargo hoy en día esto ya no vale, pues el rendimiento se obtiene a través de sacarle partido a más núcleos y no aumentando la velocidad.

Así que la conclusión es que si queremos que una aplicación llegue a ser escalable ésta debe sacar partido a múltiples hilos de ejecución y, por lo tanto, a múltiples nodos de procesamiento.

¿Se ve entonces la importancia? A mi me parece fundamental.

Este tipo de programación paralela siempre ha sido muy compleja, sobre todo a la hora de depurar aplicaciones en las que existen muchas probabilidades de generar interbloqueos o “race conditions”. Con .NET 4.0 y Visual Studio 2010 se incluyen nuevas bibliotecas, tipos y herramientas para facilitar la programación multi-núcleo, y debería ser un área de suma importancia para los programadores.

.NET 4.0 incluye lo que se ha bautizado como “Parallel Extensions” que están formadas por tres nuevos componentes:

• La biblioteca de tareas paralelas (TPL, Task Parallel Library): esta biblioteca dentro del espacio de nombres System.Threading.Taks.Parallel incluye construcciones para ejecutar tareas repetitivas independientes entre sí en paralelo y de forma automática, como por ejemplo versiones paralelas de los bucles For y ForEach.
• El motor de ejecución paralela de Linq (PLINQ Execution Engine): como se desprende de su nombre, se trata de una versión paralelizada de Linq to Objects, que nos permite lanzar consultas integradas en el lenguaje aprovechando la capacidad de paralelismo del sistema.
• Las estructuras de datos para coordinación (CDS, Coordination data Structures): ofrece un conjunto de primitivas de sincronización y de colecciones preparadas para multisubproceso (thread-safe) que simplifican los escenarios paralelizados. Por ejemplo, tenemos diccionarios, pilas y colas thread-safe, y objetos especiales para sincronización de hilos como el SpinWait o el SpinLock.

La MSDN tiene una buena documentación sobre todo esto en: http://msdn.microsoft.com/en-us/library/dd460693.aspx.

Y tú ¿qué opinas?

Compartelo/Guardalo

Ah jaja ¡espero y eso nunca me lo hagan mis hijos! Ah jajaja, esta muy buena la forma para programar, ¡tendré que probarla!

¡Saludos!

Compartelo/Guardalo

class Machine
{
public string Processor { get; set; }
public int RAM { get; set; }
}

Si quisiéramos crear un nuevo equipo y además inicializar sus componentes de la forma convencional sería algo parecido a esto:

var newMachine = new Machine {RAM = 6, Processor = "Intel i7 920"};

Si además esta clase Machine tuviera una serie de métodos encargados de realizar acciones como encender el ordenador, testearlo, apagarlo, etcétera ejecutaríamos cada uno de ellos invocando línea a línea los métodos declarados en dicha clase:

var newMachine = new Machine { RAM = 6, Processor = "Intel i7 920" };
newMachine.TurnOn();
newMachine.Test();
newMachine.TurnOff();

¿Qué nos ofrece Fluent Interface?

new Computer()
.AddProcessor("Intel i7 920")
.AddRAM(6)
.TurnOn()
.Test()
.TurnOff();

Si nos damos cuenta se trata de una línea de código abarcando todas las funciones que nos interesan de una clase de tipo Machine, encapsulada dentro de Computer. ¿Cómo creamos este encapsulamiento?
En primer lugar vamos a definir una interfaz que establezca los métodos disponibles y obligatorios de implementar:

namespace FluentInterface
{
interface IComputer
{
IComputer TurnOn();
IComputer TurnOff();
IComputer Test();
IComputer AddRAM(int GB);
IComputer AddProcessor(string model);
}
}

Lo primero que nos puede llamar la atención es que cada uno de los métodos deberá retornar el tipo IComputer, es decir, debería devolver una clase que implemente esta interfaz que estamos declarando o dicho de otra forma: Deberá devolverse a sí mismo. ¿Qué conseguimos con ello? Devolver el contexto (valores de las variables) en cada acción que vayamos invocando para poder ser utilizado en la siguiente llamada. Como implementación válida a esta interfaz tendríamos lo siguiente:

using System;
namespace FluentInterface
{
class Computer : IComputer
{
private readonly IMachine _machine;
public Computer()
{
_machine = new Machine();
}
public IComputer TurnOn()
{
_machine.Status = "On";
Console.WriteLine("Your computer is {0}", _machine.Status);
return this;
}</p>
public IComputer TurnOff()
{
_machine.Status = "Off";

Console.WriteLine("Your computer is {0}", _machine.Status);

return this;
}

public IComputer Test()
{
Console.WriteLine("Your computer is {0}", _machine.Status);

return this;
}

public IComputer AddRAM(int GB)
{
_machine.RAM = GB;

Console.WriteLine("{0} GB RAM added. Do you think its enough?", _machine.RAM);

return this;
}

public IComputer AddProcessor(string model)
{
Console.WriteLine("{0} processor added.", _machine.Processor);

_machine.Processor = model;

return this;
}
}
}

En cada uno de los métodos realizaremos las operaciones necesarias y finalmente retornaremos this, es decir, la instancia de la clase que implementa IComputer para poder continuar operando con ella de una manera fluida. Gracias a este estilo de programación conseguiremos un código más legible y atractivo para el desarrollador
¡Saludos!

Compartelo/Guardalo

Las traducciones son realizadas a través de Google Translate en sus 50 idiomas, no hay límite en el tamaño del documento a traducir y no se necesita estar registrado para utilizar el servicio.

Documentos de Word y Excel son totalmente compatibles y también lo son archivos .txt. En caso de que use un sistema operativo diferente a Windows, deberás consultar la tabla de compatibilidad.

¡Saludos!

Compartelo/Guardalo