19 de junio de 2011

[PHP] Verificación de entradas en arrays multidimensionales (1/2)

conjuntoEntradas() {
  [PHP] Verificación de entradas en arrays multidimensionales (1/2)
  [PHP] Verificación de entradas en arrays multidimensionales (2/2)
}

Ya hace un tiempo que empecé un desarrollo de unas de mis pajas mentales con el conocido framework Web MVC (Model View Controller) denominado Zend Framework. Desde que empecé este desarrollo, el cual he tenido que interrumpir en algunas algunas ocasiones por ciertas obligaciones las cuales me gusté o no tengo que darle preferencias, además de solo poderle dedicar parte de los días que no me empleo en la empresa en la cual estoy contratado a tiempo completo, y digo parte, porque me es imposible no dedicar una parte de esos días a descansar, atender asuntos personales, buscarme la vida por otras partes o hacer otros hobbies muy necesarios para mí, me han ido surgiendo dudas sobre ciertos aspectos del lenguaje PHP; uno de ellos ya lo dejé plasmado en una entrada en este mismo blog hace algún tiempo.

Cuando empecé a descubrir las cosas que me ofrece el propio framework, a día de hoy aún me queda alguna cosa que funcionalidad más bien no por descubrir, sino por utilizar y conocer bien como se utiliza, me dí cuenta que a medida que iba desarrollando mis idas de olla, podría ir modularizando ciertos componentes, que me podrían servir para futuras pajas mentales, además de poder utilizar de manera extensiva en el desarrollo de esta; es decir lo que resumiríamos en arquitecturar código de programación para favorecer el reaprovechamiento mediante creación de componentes genéricos; algo así como ya han hecho los propios desarrolladores de dicho Zend Framework, de ahí que haya acabado en eso, en un framework.

Con todas esta paranoia que me dio y me continúa dando, por el reaprovechamiento basándome en la modularización; una de las cosas que más utilizo es la configuración de los componentes mediante ficheros de configuración, ya sean INI o XML, para poder reutilizarlos sin tener que escribir código de programación.

Zend Framework, ofrece unas clases para leer este formato de ficheros, y alguno más, y después poder obtener un array multidimensional de clave=>valor para posteriormente poder tratar el contenido desde PHP de una manera sencilla. De hecho el propio framework utiliza estos formatos para especificar las configuraciones de la aplicación web que se va a desarrollar y también para configurar parte de sus componentes.

Al empezarlo a utilizarlos en mis componentes y ver que necesitaba, en muchos casos, verificar la existencia de ciertos parámetros obligatorios en los ficheros de configuración, y esto lo tenía que hacer con la verificación de la existencia de claves dentro de los arrays multidimensionales, descubrí que desde PHP se ofrecen varias funciones o maneras de poder verificar la existencia de valores dentro de arrays, así que la paranoia de la optimización se apoderó de mi, provocando una curiosidad, necesaria por hacer cada componente algo más óptimo, por saber cual de ellas tiene un mayor rendimiento en cuanto a velocidad de proceso.

En los comentarios que dejan los usuarios en la documentación de PHP, en varias de las funciones que se pueden utilizar para verificar la existencia de claves, ya se puede saber que algunas de ellas son más óptimas que otras, por ejemplo, la función is_null(), tiene un rendimiento mucho peor que la comparación directamente con NULL, pero esta tiene un rendimiento más bajo si la comparamos con isset(), no obstante de todos estas funciones, aunque nos podrían servir para verificar la existencia de una clave, a mí, particularmente, no me gusta mucho tener que hacer referencia a valores que no van a existir si la clave no existe, que sería lo que tendríamos que hacer con is_null() y con la comparación con NULL, pongamos un ejemplo:

Defino un array que voy a utilizar para todos mis ejemplos y pruebas, dentro de este conjunto de entradas

$var1 = array(
        'clave1.0' => 'valor1.0', 
        'clave1.1' => 'value1.1',
        'clave1.3' => array (
            'clave2.0' => 'value2.0', 
            'clave2.1' => array(
                'clave3.0' => array(
                    'clave4.0' => 'value4.0'
                )
            )
        )
    );

Si quisiéramos verificar la existencia de una clave, con las dos maneas que he comentado, tendríamos que hacer lo siguiente:

if (is_null($var1['clave1.4'])) {
      print "La clave1.4 no exise \n";
  }

  if($var1['clave1.4'] === NULL) {
      print "La clave1.4 no exise \n";
  }

Funcionar, funciona pero no me gusta, porque para la verificación accedemos a una posición del array inexistente, por lo cual se genera para ambos caso el siguiente mensaje de notificación (eso si tenemos el PHP configurado para que notifique los errores del nivel NOTICE):

  PHP Notice: Undefined index: clave1.4 in /path/al/script.php on line NN

Aunque dicho mensaje podríamos provocar que no apareciese anteponiendo @ delante la función o delante la variable en el caso de la comparación con NULL.


Hasta la próxima enfermos.

13 de junio de 2011

El Gobierno de las TIC en la PyME de nuestra querida España


Llevando más de un mes sin pisar el Blog para escribir alguna de mis tonterías, acogiéndome a la gran excusa que utilizamos gran parte de los mortales, “no he tenido tiempo”, aprovecho este maravilloso día, festivo en Barcelona, para perder el tiempo escribiendo una entrada, en este maldito blog, desde el balcón de casa.

Ahora que ya me he disculpado, con la mentira de siempre, voy a pasar a decir de que puñetas voy a hablar; durante este tiempo de “reflexión”, he ido acumulando cosas de las que escribir, algunas incluso las he empezado y no las he terminado y otras se quedarán como cosas que puede escribir pero al no hacerlo, han caducado, al menos por el interés que pueden tener ahora mismo, aunque realmente, pienso que lo que escribo aquí no va mucho más allá de mi propia y absurda satisfacción.

“¡Mierda! Ya me he vuelto a ir por las ramas, perdonad”; el tema gira entorno a este artículo publicado en TNI, el 25 de mayo del 2011, titulado de la siguiente manera: ¿Cómo conseguir un departamento de informática más eficiente?

Sí, habla de la eficiencia del departamento de informática, o más conocido actualmente como departamento TIC, no habla de PyME, ni se enmarca dentro de España, esto lo añado yo, 1) porque empleo mi tiempo currando en una PyME, 2) está dentro de España.

El artículo, a mi parecer dice verdades como puños:
  1. Externalizar sí, pero sólo lo necesario.

    Como en la mayor parte de las tendencias, modas, ideologías políticas, religiones, etc..., irse a los extremos es poco apropiado a medio-largo plazo, esto lo deberíamos saber todo si miramos un poco al pasado; cuantas veces se ha oído, por algún que otro cabreo con o sin fundamento por parte de “directivos”: “me voy a cargar el departamento de informática, lo voy a subcontratar y listo”.
    Así que, directivo, si fue un calentón, no pasa nada a todos nos pasa, sino lo fue echa le un ojo al artículo, que te irá bien para reflexionar.
    Por otra parte, no quiero que se llegue a pensar que estoy diciendo que una PyME, más bien P que M, no deba subcontratar todo su departamento de informática, cuando el tamaño, en cuanto a empleados, es algo normal, ya que no solo se hace con el departamento de informática, sino con muchos otros. Por otra parte, si la mentalidad del directivo de a pié, ya sea de una P o M (no dedicada al negocio de las TIC), es: “la informática que sea invisible, que se limite a funcionar y ya está”, entonces subcontrata este departamento ya que si nos basamos por lo que dice el artículo: “y únicamente externalizar todo aquello que no se considere como valor competitivo diferencial para la empresa.”, claro está que el únicamente se convierte en el 100%.

  2. Organización y procesos del departamento.

    Volvemos a lo mismo sobre lo de no irse a los extremos; parte de una metodología de organización ya probada, ya que si tiene cierta antigüedad y continúa existiendo, es porque muchos se dieron de ostias durante su creación, eso si no te aferres a ella como si de la única verdad se tratara y adáptala a tu negocio, que nadie más bien que tú sabe que peculiaridades tiene.
    Lo que está claro es que tu departamento TIC, tiene que estar organizado y gestionado y con unos procesos claros, definidos y acorde con la empresa y este no se convierta en un grupo de frikis que tienes ahí que continuamente todo los empleados de la empresa tienen el derecho de solicitar las cosas a salto de mata, y si lo prefieres así, luego no pidas plazos (esto se traduce en compromisos) con respecto a otras cosas, que vienen del equipo directivo o que requieren una cierta cantidad de recursos.

  3. Arquitectura tecnológica definida.

    Otras de las cosas que he oído muy habitualmente de la boca de algunos directivos y mandos intermedios es que “no quiero ni oír y menos hablar del software a medida, esto no es una empresa de informática”; muchos creo que no saben ni lo que dicen, porque luego resulta que la empresa, como poco, tiene una Web que no han hecho con ninguno de las aplicaciones de creación de sites que ofrecen las numerosas empresas de hosting y unos cuantos ficheros mdb con algunas tablas, formularios e informes que ha tenido que hacer alguno de los miembros o ex-miembros del departamento TIC; “sí, señores míos, eso también es desarrollo propio, a más pequeña escala, pero lo es”.
    Creo que casi todos, sabemos que dentro de una empresa NO TIC, no se va a desarrollar un paquete de software de ofimática convencional, no se va a desarrollar un DBMS (Data base management system, o para que se entienda más SGBD) y un largo etc. de aplicaciones de uso general, global o estándar, como prefieras llamarlo; lo que si te tienes que enterar es que tu negocio puede tener ciertas particularidades que difícilmente te lo va a ofrecer una solución comercial, al menos en su totalidad, es decir que si quieres que se adapte totalmente a ti, tendrás que parametrizarla y/o implementar ciertos servicios, mecanismos, addins o como quieras llamarles, para no tener que pasar, si no quieres, por el tubo.

  4. Mejor prevenir que curar.

    Esta famosa frase que llevamos escuchando todos desde que llegamos a este mundo y que todos comprendemos pero pocas veces la tenemos presente a la hora de tomar decisiones, y no tiene más transcendencia que correr algún que otro riesgo, que en determinadas ocasiones el riesgo es diversión y como todos nos tenemos que ir a la tumba de vez en cuando incurrimos en él para justificar nuestro corto tiempo que pasamos en este mundo; no obstante no creo que la mayor parte de las decisiones que se toman en una empresa, sean puramente para pasar un buen rato, ya que estas acostumbran a tener una transcendencia a corto, medio y largo plazo. Cierto es, que lo que acabo de comentar se aplica a todas las decisiones, pero si que normalmente se encasillan en ciertas unidades funcionales (normalmente asociadas a un determinado departamento).
    En el caso que me atañe, en el departamento TIC donde trabajo actualmente, esto se da en su totalidad:

    1. ¿pasividad? LA HAY, porque después de tomarse las cosas en serio, e intentar que la dirección se las tome o al menos te escuche, y ver como ni se toman en serio, ni te escuchan, el responsable a pié se acaba cansando con el paso del tiempo y opta por esta postura.

    2. ¿siempre a remolque? SÍ, con los recursos que se destinan, como se inculca a todos los empleados que son (si he dicho que, no quien) “los individuos que están ahí trasteando con las máquinas” y ver las pocas expectativas de cambio te obligan a ir a remoque, muchas veces asumiendo responsabilidades que no llevan a ningún lugar más que tener que dedicar horas de tu tiempo libre a cambio de nada; en este caso por lo que respecta a la tecnología, si que es cierto que puede parecer imposible de cambiar, pero no es por la propia tecnología, más bien por lo que acabo de comentar.

    3. ¿anticiparse? NUNCA, después de emplear tiempo y esfuerzos muchas veces, y la mayor parte fuera del tiempo de trabajo estipulado, para proponer cambios antes de llegar al día 0, y ver que no han servido de nada porque llega el día 0 y los cambios hay que hacerlos ya sí o sí, con la consecuencia de que todo se hace más bien mal por las prisas y falta de previsión acarreando futuros problemas que todavía provocará que el departamento TIC vaya más “a remolque”.

    4. ¿cambios organizativos en el resto de la empresa para que el departamento TIC funcione mejor? JAMAS, los del departamento TIC están para la informática sea invisible a efectos de problemas y funcionamiento individual de cada empleado, así que si que “si usted tiene algún problema informático, sea cual sea, levante el teléfono y marque las extensión del departamento TIC sin ningún reparo, sea urgente o no, ya que lo suyo siempre lo será y las actividades que hacen allí que no sea esta no tienen la mayor importancia”.

Bueno, comentado el artículo y extrapolandolo a la situación que yo estoy viviendo y me atrevo (siempre teniendo en cuenta que es mi punto de vista personal) después de haber contrastado con otros compañeros del sector y dentro de España y haberlo visto a primera vista en alguna que otra PyME, a concluir qué: es una tónica habitual dentro de la PyME de esta España, para empresas cuyo negocio no son las TIC, dejando comentarios de estas a parte ya que no he tenido la experiencia de haberlo vivido ni tampoco oído de manera explícita.

Y a tú, si te encuentras en esta situación de directivo y detectas todo esto, si crees que esto puede ayudar a mejorar tu negocio cara al futuro puedes empezar a tomar medidas, no hace falta que las apliques de golpe, Roma no se creo en un día; eso sí, si eres de los que te has comido un MBA, creo que verás claramente que muchos de los aspectos, o al menos una parte, se enmarcan claramente dentro de las buenas prácticas de administración del negocio y sino es así empieza a plantearte si no perdiste el tiempo haciéndolo, ya que creo, que poco de todo lo que te contaron te llego.


Hasta la próxima enfermos!