domingo, 9 de noviembre de 2008

Las personas: el activo de las empresas... no.

Un poco a cuento de las cuestiones laborales sobre las que venía reflexionando, dos perlitas:

1) Yoriento referencia una frase vista en el blog de Escolar, atribuída a "Eusebi Cima, vicepresidente de Fomento del Trabajo (la patronal catalana) y presidente de la patronal Fepime, sobre las ayudas de 1.500 euros para los empresarios que contraten a parados con cargas familares":

"Desgraciadamente, lo que necesitamos son ayudas para despedir a la gente. Hay un ajuste de mercado, una crisis muy grave, se está generando desocupación y no puestos de trabajo. Ahora no es el momento de crear este tipo de ayudas."

2) Un extracto (muy iluminado, a mi entender) del blog de Javier Llinares (no tiene relación directa con el punto 1):

Yo no estoy de acuerdo en que las personas sean el mejor activo que tienen las empresas, ni siquiera estoy de acuerdo en que las personas sean un activo de las empresas, ya que si fuesen algo que poner en el balance, en lugar de en la cuenta de resultados, creo que lo que serían es un renting.

Las personas son un activo para ellas mismas, nunca para las empresas, ya que para que algo sea considerado un activo, tiene que existir cierto nivel de posesión, y naturalmente las personas solo se pertenecen a ellas mismas.

El resaltado es mío. Les recomiendo el artículo completo.

sábado, 8 de noviembre de 2008

Qué significa NINJA en "Crisis NINJA".

Voy a deschavar (con alguna vergüenza) mi desconexión absoluta de la actualidad en estos días (que no de la realidad, que es bien diferente) y de paso hacer un favor a quienes no se atrevían a preguntar.

Acabo de leer en el blog de Javier Llinares Salas, por primera vez, el significado de NINJA, término que ha estado dando muchas vueltas estos meses:

NINJA = No income, no job, no assets, es decir que un ninja es una persona que no tiene ingresos, no tiene trabajo y no tiene propiedades.

Un rayo de luz al interior de mi zócalo...

viernes, 7 de noviembre de 2008

Gestión del tiempo.

No quisiera que esta joyita se perdiera entre los links de "lo que leo":

La teoría de gestión no sirve para los proyectos importantes.

"Las cosas realmente importantes de la vida, ni se pueden elegir, ni se pueden medir".

Jueguitos de viernes: Assembler.

Assembler es un juego de ingenio bastante original, en el que tenemos que arreglárnoslas para colocar unas cajas en los espacios indicados... no es tan fácil como parece...

Un poco corto para mi gusto, deja con ganas.

Máxima seguridad.

Espero que el afán de aumentar la seguridad en mi oficina no llegue a esto...

Visto en The Daily WTF.

jueves, 6 de noviembre de 2008

Codificación: datos de la aplicación como recursos XML embebidos (parte III).

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

III. Encapsulamiento.

Con lo que tenemos hasta aquí ya podríamos armar nuestro menú de ejemplo copiando y pegando el código de prueba que tenemos y modificándolo para recorrer los datos de acuerdo a las necedidades del caso.

Pero hay un tema extremadamente importante que aclarar antes de seguir: cuidado con XML. Podemos definirlo y utilizarlo muy fácilmente, y así de fácil se nos puede ir de las manos. Ya he comentado algunos ejemplos en este blog:

  • XML * Inconciencia.
  • XML (donde comenzaba con la muy acertada frase: "XML is like Violence, if it doesn't solve the problem, use some more").
  • Pobre XML.

XML es una muy buena herramienta para guardar los datos, pero nunca, nunca jamás (créanme) accedan directamente a ellos desde toda la aplicación.

En este sentido son asimilables a una base de datos: no accedemos a ellos creando una conexión y los objetos necesarios para ejecutar un comando SQL en cada módulo, clase o procedimiento en el que los necesitamos. Siempre creamos una capa de datos que puede ser más o menos compleja y con más o menos funcionalidades de acuerdo al caso, pero nunca, nunca accedemos a ellos directamente.

Las razones principales son:

  • Claridad del código.
  • Si cada vez que deseamos obtener información de un menú hacemos

    
    //......
    
                string resourceName = "EjemploRecursosXMLEmbebido.Menu.xml";
                
                XmlDocument menuesXML = new XmlDocument();
                using (Stream s = this.GetType().Assembly.GetManifestResourceStream(resourceName))
                {
                    menuesXML.Load(s);
                }
    
    //.... (etcétera)...
            
    

    Estaremos ensuciando el procedimiento con todo este montón de cuestiones acerca de los recursos, los streams y demás que dificultan la lectura.

  • Mantenimiento.
  • Imaginemos que utilizamos el código anterior en muchas clases de nuestro proyecto. El simple hecho de cambiar el nombre del recurso implicaría buscar la cadena "EjemploRecursosXMLEmbebido.Menu.xml" por todos lados y reemplazarla.

    Es fácil cometer errores al utilizar XPath. Tal vez no todos los programadores del equipo están familiarizados con él. En cada acceso podría cometerse un error diferente.

  • Mejoras, nuevas funcionalidades, reutilización.
  • Veremos que hay mucho para mejorar en la utilización de recursos XML. Las posibilidades son muchas y usualmente iremos aprendiendo sobre la marcha, a medida que surjan las necesidades. Por ello es que necesitamos tener encapsulado el acceso, para poder modificarlo sin que el resto del sistema se vea afectado.

Espero haberlos convencido. Si es así, estarán dispuestos a crear un par de clases que encapsulen el recurso y lo hagan invisible al resto de la aplicación.

Examinemos la estructura de cada nodo que representa un ítem del menú:

<menu id="compras">
  <titulo>Compras</titulo>
  <submenues>
    <!-- lista de elementos menu con la misma estructura-->
  </submenues>
</menu>

Podemos crear una clase (MenuItem) que encapsule ese nodo y exponga los datos que contiene como propiedades:

using System;
using System.Collections.Generic;
using System.Xml;

namespace EjemploRecursosXMLEmbebido
{
    public class MenuItem
    {
        XmlNode _nodo;

        public MenuItem(XmlNode nodo)
        {
            _nodo = nodo;
        }

        public string Id
        {
            get { return _nodo.SelectSingleNode("@id").InnerText; }
        }

        public string Titulo
        {
            get { return _nodo.SelectSingleNode("titulo").InnerText; }
        }

        public IEnumerable<MenuItem> Submenues()
        {
            XmlNodeList submenues = _nodo.SelectNodes("submenues/menu");

            foreach (XmlNode menuNodo in submenues)
                yield return new MenuItem(menuNodo);

        }

    }
}

Y otra clase que nos dé acceso al recurso (Menues):

using System;
using System.Xml;
using System.IO;
using System.Collections.Generic;

namespace EjemploRecursosXMLEmbebido
{
    public static class Menues
    {
        private static XmlDocument _menuDocument;
        private const string _resourceName = "EjemploRecursosXMLEmbebido.Menu.xml";
        
        static Menues()
        {
            _menuDocument = new XmlDocument();
            using (Stream s = typeof(Menues).Assembly.GetManifestResourceStream(_resourceName))
                _menuDocument.Load(s);
        }

        public static MenuItem Raiz
        {
            get { return new MenuItem(_menuDocument.SelectSingleNode("menu")); }
        }

    }
}

Ya estamos listos para otra prueba. Colocamos un nuevo botón sobre el formulario, cuyo código será:

        private void button2_Click(object sender, EventArgs e)
        {
            foreach (MenuItem menuItem in Menues.Raiz.Submenues())
            {
                MessageBox.Show(menuItem.Titulo);
            }
        }

Vemos que ahora, para nuestro front-end de pruebas, el XML simplemente no existe, ni siquiera "sabe" que es un recurso XML. Simplemente solicita a la clase Menues el menú raíz y recorre sus submenúes mostrando el título.

Pero seguimos sin tener un menú como la gente. Paciencia...

Parte I: Resumen.

Parte II: La definción del archivo XML.

Parte III: Encapsulamiento.

Parte IV: Que funcione.

miércoles, 5 de noviembre de 2008

Humor: Entrevista de trabajo.

Un sujeto está en una entrevista de trabajo.

El psicólogo le dice:

- Le voy a realizar un test final para su admisión.

- Perfecto -dice el candidato.

Entonces el psicólogo le pregunta:

- Usted está en una calle oscura y ve a lo lejos dos faros viniendo en su dirección, ¿usted qué piensa que es?

- Un auto.

- Un auto es muy poco, ¿Qué tipo de auto? ¿Un BMW, un Audi, un Volkswagen?

- ¿Y cómo lo voy a saber?

- Hummm… -dice el psicólogo, que continúa:

- Le voy a hacer otra pregunta: usted está en la misma calle oscura y ve sólo un farol viniendo en su dirección, ¿qué es?

- Una moto.

- Si, pero ¿qué tipo de moto? ¿Una Yamaha, una Honda, una Suzuki?

- Pero si es una calle oscura ¿cómo lo voy a saber (ya medio nervioso)?

- Hummm... Aquí va la última pregunta: en la misma calle oscura usted ve de nuevo un solo farol pero más pequeño y percibe que viene más lento, ¿qué es?

- Una bicicleta.

- Si, pero ¿qué tipo de bicicleta?, ¿una Orbea, una BH?

- ¡¡No sé!!

- Lo siento pero no ha pasado el test.

Entonces el candidato, medio triste con el resultado, dice al psicólogo:

- Aunque no he pasado el test me pareció muy interesante. ¿Puedo hacerle una pregunta, en la misma linea de razonamiento?

- ¡Claro que puede!

- Usted señor, está a la tarde casi noche en una calle mal iluminada. Ahí ve una mujer muy maquillada, con un vestido rojo muy corto, girando su cartera, ¿qué es?

- Ah! Es una puta.

- Si, pero ¿qué puta? ¿Su hermana? ¿Su hija? ¿Su mujer? ¿O la puta que lo parió?

Cuac.

Es realmente irresistible, como dice apuntesgestion, de donde me lo robé.