Sinceramente me complace muchisimo el grado de expectativas que se ha generado en torno al que sera el primer encuentro de la comunidad PHP Argentina.
En particular me alegra saber que si bien s trata de un encuentro informal cuyo fin ultimo es lograr la integracion de nuestra incipiente comunidad, al parecer ha tenido mayor repercusion de la que hubieramos anticipado en un principio.
Esta mañana por algun motivo se me ocurrio tirar un "php beer" en google. Los primeros resultados no me sorprendieron: php.net, CaFeLug y obviamente php-ar. El que si me sorprendio fue un breve anuncio en desarrolloweb, un lindo sitio que me ayudo a dar mis primeros pasos en el desarrollo web años atras.
En la misma linea de sorpresas, Thomas, un medico australiano me escribio a mi y tambien a Ricardo interesado en participar. Thomas va a pasar unos dias en Argentina buscando reclutar desarroloadores de PHP y magos del AJAX. Asi que si buscas trabajo, tenes otra excusa para venirte mañana a tomarte unas birras!!
En otros temas: perdon por los horrores ortograficos. Estoy desde el iPod nuevamente y me hace constantemente "correcciones" sobre lo que escribo. Alguien sabe como desactivar este feature????
Editado: Cambie el link para vaya al articulo de desarrolloweb en cuestion. Desde el iPod no tenia forma de hacer copy&paste :s
miércoles, 17 de diciembre de 2008
jueves, 20 de noviembre de 2008
Integrando CodeIgniter y Doctrine: Segunda vuelta
Como prometí aquí está el tutorial para integrar la consola de Doctrine en una instalación de CodeIgniter
Para empezar, yo tomé la decisión arbitraria de colocar los ejecutables al mismo nivel que index.php (el front-controller de CI).
Hecha la aclaración, comenzamos.
Este archivo va a ser el encargado de inicializar doctrine y obtener la información correspondiente de los archivos de configuración que creamos en el anterior tutorial.
[DocumentRoot]/doctrine.php
La primera parte corresponde a la inicialización de las variables de CI y es identica a la primera parte del archivo index.php provisto por CodeIgniter.
Luego se incluye el archivo de configuracion de doctrine (que creamos en el tutorial anterior) y la configuracion de la base de datos
Hasta ahora es perfectamente posible usar un comando como /sbin/php -f doctrine.php parametros... etc
pero siempre resulta más cómodo tener un script ejectuable a mano
Como esta implementación la tengo corriendo en un servidor con windows pero la desarrolle en una maquina con linux, tengo preparado el script para ambas versiones.
En ambos casos, es necesario ajustar la ruta hasta o incluso el nombre del ejecutable de php
Unix: ./doctrine
Creamos un archivo doctrine con permisos de ejecucion en el mismo directorio que doctrine.php del paso anterior.
Windows: doctrine.bat
Creamos un archivo doctrine.bat en el mismo directorio que el archivo doctrine.php que creamos en el paso 1
...y ya está.
Dos sencillísimos pasos y tenemos la consola de Doctrine corriendo con CI.
Lamentablemente la consola de Windows pierde todos los estilos que tiene la de Unix. Supongo qeu habrá alguna forma de solucionar esto último, pero personalmente no es algo que me preocupe.
Si alguien tiene una solución, los invito a postearla en los comentarios
Para empezar, yo tomé la decisión arbitraria de colocar los ejecutables al mismo nivel que index.php (el front-controller de CI).
Hecha la aclaración, comenzamos.
Paso 1: doctrine.php
Este archivo va a ser el encargado de inicializar doctrine y obtener la información correspondiente de los archivos de configuración que creamos en el anterior tutorial.
[DocumentRoot]/doctrine.php
<?php
# Estos parametros son identicos a los que tenemos en index.php
$system_folder = "system";
$application_folder = "application";
if (strpos($system_folder, '/') === FALSE)
{
if (function_exists('realpath') AND @realpath(dirname(__FILE__)) !== FALSE)
{
$system_folder = realpath(dirname(__FILE__)).'/'.$system_folder;
}
}
else
{
// Swap directory separators to Unix style for consistency
$system_folder = str_replace("\\", "/", $system_folder);
}
define('BASEPATH', $system_folder.'/');
if (is_dir($application_folder))
{
define('APPPATH', $application_folder.'/');
}
else
{
if ($application_folder == '')
{
$application_folder = 'application';
}
define('APPPATH', BASEPATH.$application_folder.'/');
}
include(APPPATH . DIRECTORY_SEPARATOR . 'config' . DIRECTORY_SEPARATOR . 'doctrine.php');
require_once($config["doctrine_path"]);
spl_autoload_register(array('Doctrine', 'autoload'));
include(APPPATH . DIRECTORY_SEPARATOR . 'config' . DIRECTORY_SEPARATOR . 'database.php');
$doctrine_group = $active_group;
//$doctrine_group = 'doctrine_custom_group';
$dsn = $db[$doctrine_group]['dbdriver'] .
'://' . $db[$doctrine_group]['username'] .
':' . $db[$doctrine_group]['password'].
'@' . $db[$doctrine_group]['hostname'] .
'/' . $db[$doctrine_group]['database'];
Doctrine_Manager::connection($dsn);
$cli = new Doctrine_Cli($config);
$cli->run($_SERVER['argv']);
?>La primera parte corresponde a la inicialización de las variables de CI y es identica a la primera parte del archivo index.php provisto por CodeIgniter.
Luego se incluye el archivo de configuracion de doctrine (que creamos en el tutorial anterior) y la configuracion de la base de datos
Paso 2: los ejecutables
Hasta ahora es perfectamente posible usar un comando como /sbin/php -f doctrine.php parametros... etc
pero siempre resulta más cómodo tener un script ejectuable a mano
Como esta implementación la tengo corriendo en un servidor con windows pero la desarrolle en una maquina con linux, tengo preparado el script para ambas versiones.
En ambos casos, es necesario ajustar la ruta hasta o incluso el nombre del ejecutable de php
Unix: ./doctrine
Creamos un archivo doctrine con permisos de ejecucion en el mismo directorio que doctrine.php del paso anterior.
#!/usr/bin/env php
<?php
chdir(dirname(__FILE__));
include('doctrine.php');Windows: doctrine.bat
Creamos un archivo doctrine.bat en el mismo directorio que el archivo doctrine.php que creamos en el paso 1
@C:\ruta\al\archivo\php.exe -r "chdir(dirname(__FILE__));include('doctrine.php');"...y ya está.
Dos sencillísimos pasos y tenemos la consola de Doctrine corriendo con CI.
Lamentablemente la consola de Windows pierde todos los estilos que tiene la de Unix. Supongo qeu habrá alguna forma de solucionar esto último, pero personalmente no es algo que me preocupe.
Si alguien tiene una solución, los invito a postearla en los comentarios
viernes, 14 de noviembre de 2008
CodeIgniter ♥ Doctrine
Este es el paso por paso para integrar Doctrine y CodeIgniter de manera elegante, es decir, sin hackear el core.
Puede parecer trivial, pero es importante.
En la página de descargas de Doctrine, hay para todos los gustos.
Una vez descargados los archivos sólo se necesita, por ahora, el contenido de la carpeta lib.
En este tutorial se asume que el contenido de lib es guardado en [DocumentRoot]/system/doctrine
Para mantener el feeling the CodeIgniter, opté por crear un archivo doctrine.php dentro de [DocumentRoot]/system/application/config
Contenido de [DocumentRoot]/system/application/config/doctrine.php
Nótese que uso las constantes BASEPATH y APPATH que provee CodeIgniter, para que, en caso de alguna personalización de la configuración, este sistema siga siendo compatible.
Lo siguiente es crear las carpetas pertinentes. Yo opté por colocarlas dentro de la carpeta application que es donde coloco todo aquello sobre lo que trabajo. Algunos podrían preferir colocarlas al nivel de system o completamente fuera de CI. Si lo hacen deben editar config/doctrine.php
Las siguientes carpetas deben ser creadas:
Para la configuración de base de datos vamos a compartir la de CodeIgniter
En este punto me pareció importante tener control sobre la inicialización de Doctrine, al igual que CI provee control sobre la inicialización de la base de datos. Jugué un poco con la idea de que fuera una Library, pero finalmente opté por cargarlo como un plugin.
Para ello creé un archivo en [DocumentRoot]/system/application/plugins llamado doctrine_pi.php
Hasta aca ya quedo instalado Doctrine en CodeIgniter. Para usarlo sólo hace falta inicializar el plugin desde el controlador
La próxima, implementación de la consola de Doctrine para unix y windows integrada con CodeIgniter
Paso 1: Descargar doctrine
Puede parecer trivial, pero es importante.
En la página de descargas de Doctrine, hay para todos los gustos.
Una vez descargados los archivos sólo se necesita, por ahora, el contenido de la carpeta lib.
En este tutorial se asume que el contenido de lib es guardado en [DocumentRoot]/system/doctrine
Paso 2: Configuración
Para mantener el feeling the CodeIgniter, opté por crear un archivo doctrine.php dentro de [DocumentRoot]/system/application/config
Contenido de [DocumentRoot]/system/application/config/doctrine.php
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
$config['doctrine_path'] = BASEPATH . DIRECTORY_SEPARATOR . 'doctrine' . DIRECTORY_SEPARATOR . 'Doctrine.php';
$config['data_fixtures_path'] = APPPATH .DIRECTORY_SEPARATOR .'data' . DIRECTORY_SEPARATOR . 'fixtures';
$config['models_path'] = APPPATH .DIRECTORY_SEPARATOR . 'models';
$config['migrations_path'] = APPPATH .DIRECTORY_SEPARATOR .'migrations';
$config['sql_path'] = APPPATH .DIRECTORY_SEPARATOR .'data' . DIRECTORY_SEPARATOR . 'sql';
$config['yaml_schema_path'] = APPPATH .DIRECTORY_SEPARATOR .'yaml';
?>Nótese que uso las constantes BASEPATH y APPATH que provee CodeIgniter, para que, en caso de alguna personalización de la configuración, este sistema siga siendo compatible.
Lo siguiente es crear las carpetas pertinentes. Yo opté por colocarlas dentro de la carpeta application que es donde coloco todo aquello sobre lo que trabajo. Algunos podrían preferir colocarlas al nivel de system o completamente fuera de CI. Si lo hacen deben editar config/doctrine.php
Las siguientes carpetas deben ser creadas:
- [DocumentRoot]/system/application/data
- [DocumentRoot]/system/application/data/fixtures
- [DocumentRoot]/system/application/data/sql
- [DocumentRoot]/system/application/migrations
- [DocumentRoot]/system/application/schema
Para la configuración de base de datos vamos a compartir la de CodeIgniter
Paso 3: Integración con CodeIgniter
En este punto me pareció importante tener control sobre la inicialización de Doctrine, al igual que CI provee control sobre la inicialización de la base de datos. Jugué un poco con la idea de que fuera una Library, pero finalmente opté por cargarlo como un plugin.
Para ello creé un archivo en [DocumentRoot]/system/application/plugins llamado doctrine_pi.php
<?php
// Incluyo la config
include APPPATH . DIRECTORY_SEPARATOR . 'config' . DIRECTORY_SEPARATOR . 'doctrine' . EXT;
include APPPATH . DIRECTORY_SEPARATOR . 'config' . DIRECTORY_SEPARATOR . 'database' . EXT;
require_once $config['doctrine_path'];
// Inicializo el
spl_autoload_register(array('Doctrine', 'autoload'));
// Cargo la conexion de Base de Datos
$doctrine_group = $active_group;
//$doctrine_group = 'doctrine_custom_group';
$dsn = $db[$doctrine_group]['dbdriver'] .
'://' . $db[$doctrine_group]['username'] .
':' . $db[$doctrine_group]['password'].
'@' . $db[$doctrine_group]['hostname'] .
'/' . $db[$doctrine_group]['database'];
Doctrine_Manager::connection($dsn);
// Cargo los modelos
Doctrine::loadModels($config['models_path'], Doctrine::MODEL_LOADING_CONSERVATIVE);
?>
Paso 4 - Uso
Hasta aca ya quedo instalado Doctrine en CodeIgniter. Para usarlo sólo hace falta inicializar el plugin desde el controlador
<?
class Test extends Controller {
public function index() {
$this->load->plugin("doctrine");
}
}
La próxima, implementación de la consola de Doctrine para unix y windows integrada con CodeIgniter
miércoles, 12 de noviembre de 2008
Proyecto nuevo y la felicidad que eso representa.
La meta: desarrollar una intranet que incorpore gradualmente funcionalidad migrando el sistema actual de la empresa (entiendase por "sistema" a un montón de hojas de cálculo desparramadas entre las 6 terminales) de la manera más transparente posible.
Las condiciones: No muchas. Total libertad para elegir la plataforma, el lenguaje y demas. La única limitación fuerte es que no puedo interferir de ninguna manera en el funcionamiento de la empresa. Es decir, no puedo ocupar una maquina, no puedo distraer a los empleados, no puedo por ejemplo, reiniciar el router porque que quedé sin conexión. Tampoco puedo pedir que se instalen programas o que prueben tal o cual cosa.
Ok. Hasta aquí ningún problema. Me instalé con mi laptop y me puse manos a la obra.
Primero lo primero, el análisis. Muchas libertades, pero tenía que concretar decisiones. Por cierto, soy el único desarrollador/analista/tester ya que es un trabajo "de favor".
Primera decisión - El lenguaje:
Fácil. PHP. Si fuera otro, mi blog tendría otro nombre.
Segunda decisión - Plataforma:
Bueno, las PCs ya están corriendo en Windows y mi trabajo no puede afectar el funcionamiento de la empresa, por lo que formatear e instalar otro OS está fuera de la discución.
Por lo tanto abarajé mis posibilidades y recurrí a un viejo y conocido amigo: Wampserver.
La última vez que jugé con Wamp andaba por la version 1.7 y era práctico y fácil de usar. Hoy la versión 2.0 me parece IDEAL.
Sigue siendo sencillísimo de instalar y configurar y sigue trayendo las últimas versiones de MySQL, Apache y PHP incorporadas, pero además ahora trae una característica para instalar distintas versiones de PHP, Mysql, y Apache e intercambiar la que se está usando con sólo un click (no es que la vaya a necesitar, de cualquier manera). Decidido.
De esta manera, el servidor termino siendo un Apache, corriendo en Windows. Para base de datos: MySQL
Tercera decisión - Arquitectura:
Gran parte de esto ya estaba decidido. Hace ya algunos años que uso CodeIgniter siempre que puedo darme el gusto. Y como ahora me podía dar los gustos que quisiese, mantuve mi linea de comportamiento.
Un punto débil de CI (tiene varios, en realidad), es la capa del Modelo. CI mantiene la arquitectura MVC que se ha vuelto tan popular en los frameworks de hoy en día, y si bien la estructura de las Vistas y los Controladores "cumplen las expectativas", los Modelos de CI no son más que clases carentes de comportamiento propio en la que uno DEBERIA incluir todas las peticiones y procesamiento de datos.
Empecé a buscar reemplazos.
Mi primer impulso fue el "hágalo usted mismo". Durante el tiempo que trabajamos juntos con mi amigo Seppo habiamos desarrollado una API para los modelos de CI que nos resultó muy práctica por aquéllos tiempos.
Tanto él como yo continuamos desarrollando aquella librería aunque en direcciones ligeramente distintas.
La solución si bien era más completa que la de CI, aún no me convencía, por lo que seguí investigando.
Recientemente asistí a una charla en Latinoware en la que Guilherme Blanco hablaba sobre las bondades de Doctrine. La charla me había resultado bastante interesante por lo poco que pude entender (ya que era en portugués) y en mi todo list aún figuraba "checkear Doctrine".
Lo investigué, jugué un poco, busqué experiencias de otros usuarios y me decidí a utilizarlo.
La primera gran dificultad fue el manual de usuario. El capitulo 1: "Getting Started" es pésimo. No encuentro una palabra en español para misleading (¿desconcertante?), pero eso es lo que es. Una vez que se ignora ese capítulo, el resto es bastante comprensible y se decubre que doctrine es bastante poderoso.
La API es muy intuitiva (aunque un poco extensa) y las herramientas para generar codigo son muy buenas. La consola que trae es sencillamente: Un golazo
El problema era incorporar elegantemente Doctrine a la arquitectura de CI.... pero eso me lo guardo para otro día.
Decición Final - Schedule:
Como ya dije, es un proyecto "de favor" así que el schedule es cualquier cosa menos riguroso en cuanto a los tiempos. Pero por amor al orden, es una decisión que tenía que tomar, al menos para organizarme yo mismo.
Para empezar, sólo voy a estar dedicándole un día a la semana a estar "on site" implementando y durante la semana sólo le dedicaré tiempo a la investigación que resultara necesaria (como la que hice para la integración de Doctrine y otros problemillas que surgieron... tela para otros dias)
La primera semana la dediqué a instalar y configurar el servidor y customizar CI. También laburé sobre lo que tienen ellos armado actualmente.
Las proximas dos semanas serán dedicadas a la migración de los datos. La intención es levantar todas las hojas de excel a una base de datos. Como en este tiempo seguirán trabajando con hojas de Excel, necesito buscar periodicamente en las terminales de trabajo si abrieron nuevas hojas de calculo o si se efectuaron cambios.
Terminada la migración, desarrollaré la primera aplicación: Un buscador. Parece algo básico, pero actualmente se toman el trabajo de buscar en cada maquina (menu Inicio -> buscar) hasta que encuentran la hoja que necesitan.... inaceptable
Una vez centralizados los datos e implementado el buscador, el paso siguiente es suprimir definitivamente los archivos excel, y reeemplazarlos por una interfase que autocomplete los datos de clientes y productos, etc
Y de ahí en adelante... es un misterio..
Las condiciones: No muchas. Total libertad para elegir la plataforma, el lenguaje y demas. La única limitación fuerte es que no puedo interferir de ninguna manera en el funcionamiento de la empresa. Es decir, no puedo ocupar una maquina, no puedo distraer a los empleados, no puedo por ejemplo, reiniciar el router porque que quedé sin conexión. Tampoco puedo pedir que se instalen programas o que prueben tal o cual cosa.
Ok. Hasta aquí ningún problema. Me instalé con mi laptop y me puse manos a la obra.
Primero lo primero, el análisis. Muchas libertades, pero tenía que concretar decisiones. Por cierto, soy el único desarrollador/analista/tester ya que es un trabajo "de favor".
Primera decisión - El lenguaje:
Fácil. PHP. Si fuera otro, mi blog tendría otro nombre.
Segunda decisión - Plataforma:
Bueno, las PCs ya están corriendo en Windows y mi trabajo no puede afectar el funcionamiento de la empresa, por lo que formatear e instalar otro OS está fuera de la discución.
Por lo tanto abarajé mis posibilidades y recurrí a un viejo y conocido amigo: Wampserver.
La última vez que jugé con Wamp andaba por la version 1.7 y era práctico y fácil de usar. Hoy la versión 2.0 me parece IDEAL.
Sigue siendo sencillísimo de instalar y configurar y sigue trayendo las últimas versiones de MySQL, Apache y PHP incorporadas, pero además ahora trae una característica para instalar distintas versiones de PHP, Mysql, y Apache e intercambiar la que se está usando con sólo un click (no es que la vaya a necesitar, de cualquier manera). Decidido.
De esta manera, el servidor termino siendo un Apache, corriendo en Windows. Para base de datos: MySQL
Tercera decisión - Arquitectura:
Gran parte de esto ya estaba decidido. Hace ya algunos años que uso CodeIgniter siempre que puedo darme el gusto. Y como ahora me podía dar los gustos que quisiese, mantuve mi linea de comportamiento.
Un punto débil de CI (tiene varios, en realidad), es la capa del Modelo. CI mantiene la arquitectura MVC que se ha vuelto tan popular en los frameworks de hoy en día, y si bien la estructura de las Vistas y los Controladores "cumplen las expectativas", los Modelos de CI no son más que clases carentes de comportamiento propio en la que uno DEBERIA incluir todas las peticiones y procesamiento de datos.
Empecé a buscar reemplazos.
Mi primer impulso fue el "hágalo usted mismo". Durante el tiempo que trabajamos juntos con mi amigo Seppo habiamos desarrollado una API para los modelos de CI que nos resultó muy práctica por aquéllos tiempos.
Tanto él como yo continuamos desarrollando aquella librería aunque en direcciones ligeramente distintas.
La solución si bien era más completa que la de CI, aún no me convencía, por lo que seguí investigando.
Recientemente asistí a una charla en Latinoware en la que Guilherme Blanco hablaba sobre las bondades de Doctrine. La charla me había resultado bastante interesante por lo poco que pude entender (ya que era en portugués) y en mi todo list aún figuraba "checkear Doctrine".
Lo investigué, jugué un poco, busqué experiencias de otros usuarios y me decidí a utilizarlo.
La primera gran dificultad fue el manual de usuario. El capitulo 1: "Getting Started" es pésimo. No encuentro una palabra en español para misleading (¿desconcertante?), pero eso es lo que es. Una vez que se ignora ese capítulo, el resto es bastante comprensible y se decubre que doctrine es bastante poderoso.
La API es muy intuitiva (aunque un poco extensa) y las herramientas para generar codigo son muy buenas. La consola que trae es sencillamente: Un golazo
El problema era incorporar elegantemente Doctrine a la arquitectura de CI.... pero eso me lo guardo para otro día.
Decición Final - Schedule:
Como ya dije, es un proyecto "de favor" así que el schedule es cualquier cosa menos riguroso en cuanto a los tiempos. Pero por amor al orden, es una decisión que tenía que tomar, al menos para organizarme yo mismo.
Para empezar, sólo voy a estar dedicándole un día a la semana a estar "on site" implementando y durante la semana sólo le dedicaré tiempo a la investigación que resultara necesaria (como la que hice para la integración de Doctrine y otros problemillas que surgieron... tela para otros dias)
La primera semana la dediqué a instalar y configurar el servidor y customizar CI. También laburé sobre lo que tienen ellos armado actualmente.
Las proximas dos semanas serán dedicadas a la migración de los datos. La intención es levantar todas las hojas de excel a una base de datos. Como en este tiempo seguirán trabajando con hojas de Excel, necesito buscar periodicamente en las terminales de trabajo si abrieron nuevas hojas de calculo o si se efectuaron cambios.
Terminada la migración, desarrollaré la primera aplicación: Un buscador. Parece algo básico, pero actualmente se toman el trabajo de buscar en cada maquina (menu Inicio -> buscar) hasta que encuentran la hoja que necesitan.... inaceptable
Una vez centralizados los datos e implementado el buscador, el paso siguiente es suprimir definitivamente los archivos excel, y reeemplazarlos por una interfase que autocomplete los datos de clientes y productos, etc
Y de ahí en adelante... es un misterio..
martes, 11 de noviembre de 2008
Prettiffying
Estaba yo escribiendo una entrada para el blog, cuando de repente comprendí que no tenía de parte de los señores de blogspot, ningún tipo de syntax highlight
Por lo que me hice a la búsqueda de alguna solución y me topé con este interesante pedazo de código
Es hora de ponerlo a prueba:
Por lo que me hice a la búsqueda de alguna solución y me topé con este interesante pedazo de código
Es hora de ponerlo a prueba:
<?php
$str = "Hola Mundo!";
echo $str;
?>
blogeando desde el iPod
Esta cuestión de la tecnología no deja de sorprenderme.
Estoy en el mc donalds frente a la facultad de ingeniería quemado de estudiar, quemado de leer RSSs y tomando un café quemado. Cuando ya no sabía como seguir contando las horas hasta matemática discreta, se me ocurrió empezar este blog.
Una vez más mi fiel ipod se ha portado de mil maravillas. Puedo afirmar que fueron mis 400 dólares mejor gastados.
No me voy a extender ya que tipear así es difícil, pero la idea aquí será hacer un poco de catarsis de la vida en general y del mundo de la programación en particular. Si en el proceso ayudo a alguien... le cobro, por supuesto
Estoy en el mc donalds frente a la facultad de ingeniería quemado de estudiar, quemado de leer RSSs y tomando un café quemado. Cuando ya no sabía como seguir contando las horas hasta matemática discreta, se me ocurrió empezar este blog.
Una vez más mi fiel ipod se ha portado de mil maravillas. Puedo afirmar que fueron mis 400 dólares mejor gastados.
No me voy a extender ya que tipear así es difícil, pero la idea aquí será hacer un poco de catarsis de la vida en general y del mundo de la programación en particular. Si en el proceso ayudo a alguien... le cobro, por supuesto
Suscribirse a:
Comentarios (Atom)
