De un artículo de Taringa, copio los 20 consejos para ser mejor programador:

1. Estudia, estudia y estudia
2. Busca antes de preguntar
3. Busca scripts ya desarrollados
4. Lee el código fuente libre
   Descarga algunas aplicaciones para ver como están programadas, de verdad que se aprende mucho, a medida que realicemos esta practica cada vez iremos aprendiendo mas, en especial si estas aplicaciones son de uso popular en donde miles de programadores del mundo “meten” mano para mejorarla. Un buen ejemplo de esto es WordPress.
5. No copies y pegues
6. Buscar el momento para programar
   Estas sentado delante de tu ordenador, llaman por teléfono, tu compañero de trabajo o familiar te pregunta algo, realmente es lo mas molesto e incomodo que hay, es difícil concentrarse, es preferible hacer algo mas “Light” antes de programar algo mal y después tener que arreglarlo.
7. Ten tu propia Wiki o blog
   Esto lo recomiendo muchísimo, es muy sencillo instalar una Wiki o WordPress en nuestro PC: simplemente podemos descargar el Easyphp y tener en nuestro ordenar un servidor funcional, y mejor aun si quieres hacer la instalación “a mano”
8. Comenta todo lo que sea necesario
9. Participa en foros/comunidades
10. Habla con otros programadores
11. Tiempo libre para otras cosas
12. Arma tu bunker
    Tener un espacio de trabajo acorde con tus gustos es indispensable para programar, un buen sillón que no dañe nuestra columna, un lindo escritorio que nos permita desparramar CDS, libros, etc. También hay que ser organizado, pero siempre a nuestro gusto, es bueno que sea TU espacio y que nadie meta mano, uno a la larga lo termina sintiendo como un refugio.
13. Tu equipo en condiciones
    Otro punto importante, una buena computadora, que no tenga problemas, si es necesario un poco mas de RAM, no hace falta tener una supermáquina para programar con PHP pero si algo que no se este colgando cada 2 seg.
14. Usa herramientas gratuitas
15. Organiza tu propia biblioteca de scripts
    Relacionado con el punto 7.
16. Se agradecido con los que te ayudan
17. Se humilde
    Esencial. Siempre hay alguien que sabe más que uno y más en este “rubro” en donde hay verdaderos cráneos.
18. Siempre busca perfeccionarte
19. Intenta ser eficiente y luego inténtalo de nuevo
    Que funcione no quiere decir que este bien. También una de las cosas más lindas de programar: siempre se puede hacer una función mas eficiente, que consuma menos recursos,…
20. Programa primero lo que menos te gusta
    Esto es bastante personal, pero por lo general me da buenos resultados. Cuando me siento a programar algo los primeros minutos son de “ambientación” luego tengo un periodo de concentración digamos máxima, en ese momento las cosas que parecen o son mas complicadas son cuando mas rápido y mejor salen, luego cuando uno esta mas cansado puede dedicarse a las cosas mas sencillas y rutinarias.

No hay entradas relacionadas.

El problema surge que cuando se configura Netbeans para trabajar con Zend Tool, automáticamente deja de funcionar Zend Tool desde línea de comandos, dando el siguiente error:

Warning: include_once(NetBeansCommandsProvider.php): failed to open stream: No such file or directory in C:\xampp\php\PEAR\Zend\Loader.php on line 146
 
Zend_Exception: File "NetBeansCommandsProvider.php" does not exist or class "NetBeansCommandsProvider" was not found in the file in C:\xampp\php\PEAR\Zend\Loader.php on line 99

Esto es debido a que esta buscando el archivo NetBeansCommandsProvider.php y no lo encuentra. Para que no surja el problema, existen dos maneras:

1. Primera opción
   1. Buscar el archivo zf.ini en el ordenador (seguramente estará en la carpeta de nuestro perfil de usuario).
   2. Renombrar ‘includepath‘ por ‘include_path‘
   3. Borrar las rutas que hacen referencia al Netbeans 6.9
   4. Borrar la segunda línea que hace referencia a Netbeans.
2. Segunda opción
   1. Buscar el archivo NetBeansCommandsProvider.php por el ordenador (seguramente uno estará en C:\Archivos de programa\NetBeans 6.9\php\zend).
   2. Copiar el contenido a la librería de Zend (en caso de no querer mezclar la librería de Zend de un proyecto con este archivo, se puede copiar en un include_path, en XAMPP por ejemplo se puede copiar en C:\xampp\php\PEAR\Zend)

Vía NetBeans Forums y Foros del Web.

Entradas relacionadas:

1. Instalar y configurar Zend Framework y Zend_Tool para construir proyectos en Ubuntu
2. Instalar Zend Framework y Zend_Tool para construir proyectos en Windows
3. Configurar Netbeans para trabajar con PHPUnit y Zend Framework

Existen tres tipos de documentaciones:

• Interfaz (para los usuarios del código): qué hace, como se utiliza, que devuelve, … Pero no cómo lo hace.
• Implementación (para editores del código): cómo funciona internamente, que algoritmos utiliza, …
• Toma de decisiones (para editores y responsables de desarrollo): por qué se ha implementado de una forma o otra (razones de rendimiento, recursos, …).

La documentación de la implementación reside dentro del código, y la de la interfaz ha de ser un documento. Pues PHPDocumentor se encarga de convertir la documentación que existe en el código, a documentación legible desde un documento como una página web. De esta forma, cada vez que se aplique un cambio en el código, esto repercutirá en la documentación de la interfaz, manteniendola actualizada constantemente.

Para conseguir esto, la documentación en el código tiene que seguir unos estándares. Se escriben unos bloques de documentación llamados DocBlock, que siguen una estructura y pueden tener una serie de marcas para ayudar a PHPDocumentor a entender mejor la documentación. Un ejemplo de bloque DocBlock de una función seria:

/**
* Descripción breve (una línea)
*
* Descripción extensa. Todas las líneas que
* sean necesarias
* Todas las líneas comienzan con *
*
* Este DocBlock documenta la función suma()
*/
function suma()
{
...
}

Se puede comentar cualquier archivo PHP (.php, .php5, .phtml), y dentro de ellos se pueden documentar: clases, variables, defines, funciones, variables globales y llamadas a otros ficheros. En los DocBlock, unas de las muchas marcas que se pueden añadir son:

• @access: Si @access es ‘private’ no se genera documentación para el elemento (a menos que se indique explícitamente). Muy interesante si sólo se desea generar documentación sobre la interfaz (métodos públicos) pero no sobre la implementación (métodos privados).
• @author: Autor del código.
• @copyright: Información sobre derechos.
• @deprecated: Para indicar que el elemento no debería utilizarse, ya que en futuras versiones podría no estar disponible.
• @example: Permite especificar la ruta hasta un fichero con código PHP. phpDocumentor se encarga de mostrar el código resaltado (syntax-highlighted).
• @ignore: Evita que phpDocumentor documente un determinado elemento.
• @internal: Para incluir información que no debería aparecer en la documentación pública, pero sí puede estar disponible como documentación interna para desarrolladores.
• @link: Para incluir un enlace (http://…) a un determinado recurso.
• @see: Se utiliza para crear enlaces internos (enlaces a la documentación de un elemento).
• @since: Permite indicar que el elemento está disponible desde una determinada versión del paquete o distribución.
• @version: Versión actual del elemento

Marcas para funciones:

• @global: Permite especificar el uso de variables globales dentro de la función.
• @param: Parámetros que recibe la función. Formato: @param tipo $nombre_var comentario
• @return: Valor devuelto por la función. Formato: @return tipo comentario

Marca para variables:

• @var: Documenta los atributos de la clase. Formato: @var tipo comentario

Tipos de datos:

• array
• string
• boolean
• integer
• float
• object
• mixe

Ejemplos:

/**
* Dirección de correo
* @var string
* @access protected
*/
protected$_email;
 
/**
* Verifica si una direccion de correo es correcta o no.
*
* @return boolean true si la direccion es correcta
* @param string $email direccion de correo
*/
function checkEmailAddress ($email)
{
....
}

Vía Epsiolon Eridani.

Entradas relacionadas:

1. Configurar proyecto en Subversion para completar PHPDocumentor

Antes de explicarlos, hay que refrescar un poco los conceptos de programación orientada a objetos, los necesario para explicar el partón Singleton:

• Existen clases y objetos, y no son lo mismo. Un objeto es la instancia de una clase.
• Los atributos y métodos NO estáticos de una clase, son de los objetos.
• Los atributos y métodos estáticos de una clase, son de la clase.
• La llamada al constructor de la clase, devuelve un objeto.

El contexto de este patrón es cuando se diseña una aplicación donde tenemos una clase, de la cual sólo puede existir una instancia.

El problema esta en controlar este aspecto, ya que por defecto, la programación orientada objetos da libertad para instanciar tantos objetos de una clase como se desee.

La solución que se aplicaría usando el patrón Singleton, trata de realizar unas modificaciones en la clase para bloquear el método contructor para que no se pueden hacer indefinidos objetos, y también crear un método alternativo para conseguir la instancia única que se desea. Detallando en forma de lista las modificaciones que hay que hacer en una clase para aplicar el patrón Singleton, quería así:

• Convertir en privado el método constructor.
• Crear un atributo, privado y estático, que almacenará la única instancia.
• Crear un método, público y estático, que devolverá la única instancia. Su función será:
  • La primera vez que se llame a este método, creará una instancia, la almacenará en el atributo estático, y la devolverá.
  • Las siguiente veces que se llame, devolverá la instancia almacenada.

El esquema UML sería el siguiente (Los elementos subrallados son elementos estáticos):

El código de una clase singleton en PHP5, sería así:

<?php
class Ejemplo
{
    // Contenedor Instancia de la Clase
    private static $_instance;
 
    // Constructor privado; previene creacion de objetos via new
    private function __construct()
    {
        echo 'Soy el constructor';
    }
 
    // EL metodo singleton
    public static function getInstance()
    {
        if (!isset(self::$instance)) {
            $c = __CLASS__;
            self::$_instance = new $c;
        }
 
        return self::$_instance;
    }
 
    // Clone no permitido
    public function __clone()
    {
        trigger_error('Clone no se permite.', E_USER_ERROR);
    }
 
}
 
?>

Ejemplos del uso del Patrón Singleton, o ejemplos de cuando es necesario tener una clase que solamente se puede instanciar una vez: la ventana de una aplicación, la conexión a la base de datos, el sistema de logs, o de caches, …

No hay entradas relacionadas.

Pero los sistemas operativos no estan pensados para trabajar con dos monitores, y no dan funcionalidades para trabajar mejor. Para ello existe una aplicación para Windows, UltraMon, que permite:

• Mover eficientemente ventanas de un monitor a otro.
• Extender la barra de tareas a todos los monitores.
• Más opciones de configuración del fondo de pantalla y del salvapantallas.
• Clonar las pantallas, para hacer que un monitor sea un espejo del otro.
• Control de que aplicaciones estan en cada monitor.

La clave de este programa es lo que se en la siguiente imagen: dos botones que se añaden a todas las ventanas, que permiten mover las aplicaciones de una ventana a otra, o maxizimar la ventana y que ocupe los dos monitores.

Vía Taringa.

Entradas relacionadas:

1. VirtuaWin: varios escritorios virtuales en Windows

Si se quiere generar una imagen del contenido, como sistema de backup o simplemente para poder hacer pruebas y después reestablecerlo todo, existe una aplicación muy práctica que permite crear y restaurar imágenes de unidades USB. La aplicación se llama USB Image Tool, es gratuita y senzilla de utilizar.

No hay entradas relacionadas.

La cuestión es que eso mismo se hace la próxima vez que tocan expresiones regulares, como si nunca se aprendiesen. Así que quiero hacer un breve resumen que sirva para búsquedas básicas.

Unos ejemplos de verificación:

• Dirección de email (si PHP > 5.2.0, entonces filter_var()):

  '/^[^0-9][a-zA-Z0-9_]+([.][a-zA-Z0-9_]+)*[@][a-zA-Z0-9_]+([.][a-zA-Z0-9_]+)*[.][a-zA-Z]{2,4}$/'

• Nombre de usuario:

  '/^[az\d_]{5,20}$/i'

• IP:

  '/^(([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]).){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$/'

• Dominio:

  '/^(http|https|ftp):\/\/([A-Z0-9][A-Z0-9_-]*(?:\.[A-Z0-9][A-Z0-9_-]*)+):?(\d+)?\/?/i'

Vía bueltge.de

Entradas relacionadas:

1. Plugins para hacer tests de Regular Expressions
2. Comprobar si un email tiene registros MX, con Zend_Validate

Pero con una línea en el .htaccess, se pueden evitar miradas indeseadas en las carpetas .svn de nuestros proyectos:

RewriteRule ^(.*/)?\.svn/ - [F,L]

Entradas relacionadas:

1. Configurar Subversion para utilizar los repositorios externos de Zend Framework
2. Instalar y configurar XAMPP y Eclipse en Windows

Existen dos plugins, uno para Firefox y otro para Google Chrome, que nos pertimen realizar los tests sin salir del navegador:

• Regular Expressions Tester 3.0: plugin de Firefox, que resalta con colores los resultados de las búsquedas.

• Regular Expression Checker: plugin de Google Chrome, inspirado en el anterior.

Vía Devcurry.

Entradas relacionadas:

1. Eliminar la barra para traducir de Google Chrome
2. Aplicaciones web para hacer mapas mentales
3. Script simple de PHP para hacer cache

• Zend_Layout_Controller_Plugin_Layout: este plugin actua en el postDispatch, y aplica el patrón Two Step View (captura el contenido en el Zend_Response, y después lo pasa al Zend_Layout para processarlo y se inyectado en el script de la vista del Layout).
• Zend_Controller_Plugin_ErrorHandler: también actua en el postDispatch, y se encarga de comprobar si se ha producido una excepción y ha sido registrada. En tal caso, ejecuta otra petición al controlador y acción para tratar errores y mostrarlos según sea conveniente.

El plugin de layout es ejecutado en la posición 99 de la pila, y el plugin de errores en la 100. Esto provoca que se ejecute una petición en el controlador de errores, habiendo establecido ya el layout. Para resolver este problema existen dos formas: cambiar el orden de ejecución de los plugins, o vaciando el contenido de la respuesta cuando se ejecuta la petición de tratamiento de errores.

La última opción es la más simple y conlleva menos problemas; solamente hay que añadir una línea en la acción del controlador de errores. Normalmente se trata del errorAction del ErrorController, y la primera línea de código debería ser:

public function errorAction() {
 
        $this->getResponse()->clearBody();
 
        //handle error ........
}

El siguiente diagrama muestra el flujo de ejecución de Zend Framework:

Artículos relacionados:

• Layout being rendered twice
• Zend_Application_Resource_Frontcontroller
• Front Controller Plugins in Zend Framework
• Zend_Controller_Plugins_ErrorHandler uses layout script twice

Entradas relacionadas:

1. Acceder a Zend_View desde un plugin en Zend Framework
2. ZFDebug: debug bar para Zend Framework
3. Comprobar si un email tiene registros MX, con Zend_Validate