Probando Netbenas Early Access for PHP

Llevo un par de días trabajando con Netbeans para probar el Early Access for PHP. La verdad es que no esta mal, aunque no sea la versión final no tiene mucho que envidiar a Eclipse + PDT, que es la comparación obligatoria.

La instalación es bastante sencilla y no interfiere con el NetBeans 6.0.x que ya tengo instalado para trabajar con Java. Además es una descarga ligerita, creo que no llega a los 20 megabytes.

Lo primero que he hecho es cargar algún proyecto existente, configurando en el wizzard la ruta a los fuentes. Lo normal es que te cree un subdirectorio con la información del proyecto y que tengas que retocar la ruta del servidor web para ejecutar la aplicación. Una vez hecho esto tendremos la navegación habitual de este IDE por proyecto o gestor "tradicional" de archivos, el navegador de clases, etc. Todo ello en el panel lateral izquierdo.

Además dispondremos de la paleta de objetos HTML, detección de errores, detección de código muerto (he probado a poner exit(); y return antes de algunas lineas en el interior de una función y no me ha funcionado) y más.


Todavía tienen cosas que pulir, la navegación hasta las declaraciones de funciones no va todavía muy bien, al menos en mi caso, cuando trato de llegar a una función de una clase creada por mi en un fichero distinto al que estoy trabajando. También le queda un poco al autocompletado de nuevo con clases propias ya que no me encuentra métodos estáticos ni funciones de objetos creados con anterioridad.

La integración de Xdebug también es fácil, se instala el debugger se retoca el php.ini para que pueda acceder el Netbeans y a correr, por ejemplo:

zend_extension_ts="c:/xdebug/php_xdebug-2.0.2-5.2.5.dll"
xdebug.remote_enable=1

Cuando mejoren esos pequeños aspectos estarán prácticamente a la par de PDT y ya tendremos que elegir uno a otro segun nos guste y, mas importante, en base a los plugins que queramos utilizar: SVN, diseño de BDs, UML, etc.

Yo de momento volveré a Eclipse pero estaré muy al corriente de como evoluciona esto.

Multipeticioens con CURL

Parece que me estoy aficionando últimamente a meter el dedo en el ojo ajeno y quien me conoce sabe que tengo los dedos largos. Bromas a parte lo que me dispongo a hacer es criticar otro post de uno de esos blogs que leo con asiduidad. Tarde o temprano alguien me dará con la misma medicina.

El artículo en cuestión es este ya hablé de él y tiene su tiempo. Es cierto que a su autora le dan estopa en su propia casa y es curioso porque este tipo de cosas suelen ocurrir siempre de la misma forma: los primeros comentarios son positivos y luego se va enrareciendo la cosa y se convierten en criticas. Siempre aparece algún fanático que termina descalificando.

Tampoco voy a decir nada que ella no haya comentado:
No es un multithreading real y pude llegar a sobrecargar el servidor. De hecho esto último es lo que me frenó a la hora de adoptarlo. Mi servidor de pruebas se quedaba tostado si no intercalaba una llamada a usleep con unos cuantos microsegundos en el bucle do{}while. Por cierto la prueba consistía en que este servidor lanzase peticiones post contra si mismo.

Repito una vez más lo de siempre: hay que poner en duda las soluciones que encontremos y ponerlas a prueba en nuestro entorno. Lo que sea válido para algunos puede que no lo sea para nosotros.

Mi solución al problema de inserción masiva en SQL Server

El título de este artículo puede parecer un poco egocéntrico pero hay que tener en cuenta que es la continuación de este otro y que además me refiero a una solución valida al problema que planteé en el entorno de producción que me afecta.

Recapitulando un poco para el que no quiera leerse el post enlazado, el problema en cuestión era conseguir unos 50 000 inserciones en un SGBD MS SQLServer. Todo ello sin ejecutar cada vez un

INSERT INTO MiTabla ...

El caso es que dicho entorno de producción tiene una particularidad tal vez no muy deseable: el SGBD y el servidor web corren en la misma máquina. Debido a esto se pasaba por mi cabeza que tal vez un Bulk Insert fuese una buena solución pero no me lo terminaba de creer porque suponía que esa instrucción se convertiría posteriormente en mis 50 000 "insert into", con lo cual incluso perdería mas tiempo.

El código fuente que utilicé aproximadamente en mis pruebas es el siguiente:

define("MAX",100000);
define("TAM_BLOQUE",10000);
mssql_connect("miservidor","miusuario","mipass");
mssql_select_db("MiDB");


mssql_query("TRUNCATE TABLE Cola");
$t1=time();
$query="BULK INSERT Cola
  FROM 'C:\\www\\pruebas\\envio.txt'
  WITH
     (
       KEEPNULLS,
        FIELDTERMINATOR = '|',
        ROWTERMINATOR = '\r\n'
     )";
  $i=0;
  $fecha=date();
  while ($i < MAX){ 
     $str=null;
     while ($j < TAM_BLOQUE && $i<=MAX){
        $str.="0|0|".(620000000+$i)."|".$fecha."||2|12|8|1|1|un texto mas o menos largo|hola|prueba|10|http://www.google.com|1|1|0|0|0|0|0|0|0||\r\n";
        $i++;$j++;
     }  
  $fd=fopen("envio.txt","w");
  fwrite($fd,$str);
  fclose($fd);
  mssql_query($query);
 } 
$t2=time();
echo "Tiempo: ".($t2-$t1); 

Como se puede observar hay dos bucles anidados para evitar hacer todo el trabajo de golpe en caso de que se superen ciertos límites. Esto es así porque durante las pruebas observe que el uso de CPU se sostenía cerca del 100% durante bastante tiempo si se mandaba un sólo archivo de golpe. Escribir varios archivos le daba oxígeno al servidor y no me hacía perder un tiempo considerable en la ejecución total del script.

Sin duda el hecho de que el Apache pudiese escribir en el disco duro que comparte con el SQL Server aceleró bastante las cosas, pero esto puede hacer que a muchos de vosotros no os sirva la solución. Si no es vuestro caso tal vez podáis montar una unidad lógica para obtener unas condiciones parecidas pero sufriréis una latencia adicional por ello (aclaro que yo no he probado esto último).


Para los más curiosos detallaré un poco el entorno de pruebas que utilicé: se trata de un servidor con un procesador Intel Pentium 4 a 2,66 GHz con 1 GB de RAM y SQL Server 2000.

Os recuerdo algo que dejé caer en el anterior post y que es la moraleja de todo esto: no os fiéis de nada que encontréis en un blog, el blogger no tiene por que ser un gurú aunque él mismo lo crea. Por supuesto que este artículo está incluido en la moraleja así que si os interesa ponedlo en duda y haced vuestras propias pruebas antes de darlo por bueno.

Posts de interés

No os voy a contar mi vida. Sólo diré que estoy en horas bajas y no puedo terminar ninguno de los artículos que tengo pendientes, así que os dejo algunos posts interesantes que he leído estas últimas semanas.

Joomla y capa de presentación para móviles. De uno de los tipos que más sabe sobe presentación móvil. Interesante artículo para aquellos que quieran adaptar su aplicación Joomla a terminales móviles.

Presentación sobre testeos con PHPUnit, DBUnit, etc. Una buena lectura para iniciarse con PHPUnit y demás-

Guerra de frameworks. Respuesta de un desarrollador Symfony a otr de Rubi on Rails ¿Que puedo decir? si alguien se enzarza en una guerra dialéctica más vale saber de que se habla.


Peticiones simultaneas en PHP usando CURL. En realidad no son tan simultaneas y recomiendo probar su viabilidad antes de implantarlo. En nuestro caso finalmente lo desechamos.

Situación del UML. Esta es la causa de mi anterior post sobre el uso de UML.

Modelo de contrato ágil. Solo es un patrón pero me parece interesante.

Sobre el uso de UML

Hace un par de días el autor de uno de mis blogs preferidos se preguntaba si el UML estaba pasado de moda. Lo del uso o desuso del UML es un tema que me toca la fibra. En principio yo pienso que no ha terminado de extenderse todo lo que se presumía, pero aún así lo creo algo imprescindible y a mi modo de ver se irá propagando poco a poco.

Uno de los primeros problemas que veo es el modo en el que empezó a enseñarse. Los que como yo lo hayáis estudiado hace unos siete años, seguramente, habréis aprendido toda una metodología cerrada en la que empezabais por los casos de uso, seguías con los diagramas de clases y así sucesivamente en un orden fijo preestablecido, bastante aburrido por cierto, en el que lo último que dibujaríais sería el diagrama de despliegue. Ni que decir tiene que en mi caso me limité a aprobar la asignatura y después lo dejé un poco de lado (ummm ¿no hice eso con casi todas? ¡Ah! ¡No! Hice esa carrera por que me gustaba :p ).

Afortunadamente parece que este modo de ver las cosas ha ido cambiando. En realidad todo es mucho más flexible pero tal vez no hemos entendido aún que hay miles de formas de usar UML y su uso tiene que ser diferente en base al perfil de quien lo haga:

• Un programador debe saber "leer" UML y no tiene por qué escribirlo. Parece una tontería pero leer bien un diagrama de clases que modela el diseño de una parte de la aplicación significa que sabremos como escribir el código de esas clases: una herencia se convertirá en un "extends" (fácil), pero ¿y una agregación? ¿y una composición? Esto implica también que quien haga el diseño debe saber lo que está pintando ya que repercutirá en el código.
• Probablemente las capas altas de tu organización y los clientes finales no habrán ni oído hablar de este lenguaje, así que mostrarles un diagrama de interacción o estados puede ser bastante inútil. Sin embargo no se debe desechar la posibilidad de enseñarles algún diagrama de casos de uso, despliegue, o incluso de clases orientado al análisis (preferiblemente representando las clases como cajas simples, sin los compartimentos de atributos y métodos).
  
• Por supuesto que los que se encuentren entre los dos extremos (analistas de cualquier tipo, coordinadores, etc.) deberían saber leer y escribir UML.
  

Por otro lado es muy importante escoger la herramienta CASE correcta para nuestras necesidades. No creo que mucha gente que se desenvuelva con Java o .Net escogiera ArgoUML como herramienta pero, como dije hace un par de posts, para un escenario basado en PHP puede ser una opción muy interesante.

Una vez escogida la herramienta más adecuada la forma de aplicar UML vendrá determinada en gran medida por el entorno en el que nos encontremos. Puede influir en ello la carga de trabajo, los conocimientos de UML de todo el equipo de trabajo, la naturaleza de los proyectos, etc.

En definitiva cada equipo debe encontrar su modo idóneo de utilizar UML, los ingenieros debemos acostumbrar a programadores y altos mandos a recibir pequeñas raciones de diagramas cuando lo creamos necesario. No olvidemos tampoco que en este país muchos ponen en duda que nuestro trabajo sea una ingeniería y en parte se debe a que todas nuestras metodologías de trabajo están verdes, por eso creo, aplicando un símil con el mundo de la construcción (como no) que nuestra herramienta CASE debe ser lo mismo para nosotros que el AutoCAD para un arquitecto.