Archivo por meses: abril 2009

Motivar y desmotivar en la gestión de personal

Estas vacaciones de Semana Santa que he pasado en Túnez (pronto contaré la experiencia como siempre 😛 ) me han servido para terminar de leer un libro (en realidad dos) que se me había atragantado un poco, El mito de la motivación, como escapar de un callejón sin salida, de Reinhard K. Sprenge. Lo empecé en diciembre pero hacia la mitad se me hizo un poco pesado, algo que después cambia y se hace mucho más llevadero pues el libro es realmente  interesante y de recomendable lectura a cualquiera que tenga gente a su cargo.

Reinhard, a partir de su experiencia en multitud de empresas, diferencia claramente entre motivación y manipulación,  desmitificando cualquier tipo de sistema de incentivos, léase por objetivos, pagas de beneficios, comisiones… Para él cualquiera de estos sistemas son la respuesta a la acción desmotivadora de algún directivo que no sabe cómo reconducir a su gente después de haber provocado, sin saberlo, la situación que viven.

En un momento del libro, Reinhard dice algo así,

Si nuestros colaboradores son gente adulta, con hipotecas, niños a los que criar y educar, parejas por las que luchar… ¿Por qué hemos de pensar  que en su vida  profesional alguien tiene que tratarlos como críos diciéndoles en cada momento lo que deben hacer y cortando su iniciativa?

Nuestros colaboradores son gente con conociemientos, preparación y experiencia y no quieren un trabajo de marionetas, quieren retos, afrontar problemas y tomar decisiones, pero si alguien se hace responsable permanentemente de las decisiones sin permitir que los demás tomen la inciativa y demuestren su valía nos plantamos en eso que se conoce como “desmotivación”. ¿Quién es el culpable entonces?

Intentar motivar es absurdo e imposible una vez se ha caído en la desmotivación. Por muchos intentos que se hagan por conseguirlo, normalmente a base de incentivos económicos, su éxito será sólamente efímero puesto que el dinero se valora y disfruta en un primer momento, cayendo en el olvido o en la costumbre en los siguientes.

La verdad es que en el libro no se cuenta nada que, desde la perspectiva de los que estamos por debajo, no hayamos visto siempre como “de cajón“, pero parece que hay mucha gente que nunca ha tenido este punto de vista y hay que mostrárselo.

Un libro que todos los directivos y managers deberían leer para entender muchas de las cosas que ocurren a su alrededor.

RETD, la primera red de conmutación de paquetes mundial fue española

Leyendo hoy un artículo de la serie de El Cedazo Historias de un viejo informático de Macluskey me entero de algo que es prácticamente desconocido para la mayoría de informáticos actuales. Resulta que allá por el año 1971 se inauguró en España la primera red de transmisión de datos mundial que utilizaba la conmutación de paquetes (igual que hoy en día hace Internet): RETD (Red Especial de Transmisión de Datos), que a la larga sería IBERPAC. En este otro enlace podéis encontrar la historia de de este hito de las telecomunicaciones en nuestro país, de lectura más que recomendable. No sería hasta 1978 cuando aparece otra red similar, la conocida Transpac francesa.

La historia es realmente emocionante.

Macluskey cuenta que por aquellos años (finales de los 60) se comenzaron a implantar los primeros sistemas online en la banca española, los más interesados en aquellos años en toda la informática y comunicaciones en general y que fueron los que comenzaron a utilizar las primeras redes para conectas las sucursales con las centrales. Banesto fue el primer banco en disponer de sistemas conectados entre todas sus oficinas.

Desde la Telefónica de aquellos años comenzaron a trabajar en un sistema que permitiese de un modo fiable, rápido y barato este tipo de conexiones y, sin saberlo, llegaron a la misma solución en que la gente del MIT estaba trabajando para lo que sería ARPANET, los inicios de Internet, pero como era un proyecto secreto del gobierno norteamericano no se sabía nada: la comutación de paquetes.

Vale la pena que os leáis la historia, a veces aquí también innovamos 😛 .

Igualmente recomiendo la serie completa de artículos “Historia de un viejo informático“, os dará un punto de vista que no tenemos los que nos dedicamos a esto hoy en día además de conocer la prehistoria de nuestra profesión desde un punto de vista más práctico que teórico.

Adobe AIR IX – firmar aplicaciones, una cuestión de confianza

Y otro más sobre AIR. A ver si ya es el final de la serie 😛 . Los últimos días me he estado peleando con la firma de aplicaciones AIR, no entendía mucho cómo funcionaba y me extrañaba que, a pesar de tener que firmar siempre una aplicación con un certificado SSL, al instalarla siempre me salía “Editor: DESCONOCIDO“, lo que da muy mala imagen. Ahora lo tengo claro, confundía los términos firmar y confiar. Si no quieres que salga el mensaje en cuestión tendrás que comprar un certificado de firma de software emitido por una entidad certificadora válida (Thawte), una firma de confianza.  Lo malo es que su precio ronda los 300 euros, nada más y nada menos. Personalmente creo que se han flipado un poco pero si no las firmas tus potenciales usuarios tendrán una sensación de inseguridad, tus aplicaciones estarán firmadas pero no se confiará en ellas.

Existe una segunda opción y es crear tu propia entidad certificadora (CA) y firmar tus aplicaciones tú mismo. El inconveniente de hacerlo así es que los usuarios tendrán que tener instalado el certificado de tu CA (los habituales vienen por defecto en el navegador). Como la aplicación en la que estoy trabajando se utilizará en un entorno concreto y definido, puedo utilizar este sistema y ahorrarme un dinero. Además, mis potenciales usuarios ya tienen instalado el certificado de nuestra CA ya que será la misma que utilizamos para generar certificados SSL cliente/servidor. Si firmo la aplicación AIR con la misma autoridad todo irá bien.

En aquel artículo vimos cómo generar tu propia autoridad de certificación, el método sigue siendo el mismo. Sólo necesitaremos OpenSSL:

openssl req -x509 -newkey rsa:2048 -days 3650 -keyout cakey.pem -out cacert.pem

Creamos un par de archivos para mantener la base de datos de certificados emitidos:

echo '100001' >serial
touch certindex.txt

Veamos ahora cómo generamos el certificado para la firma de software. No es fácil saber todas las opciones necesarias para que después funcione la firma, lo mejor es meterlas todas en un archivo de configuración, openssl.cnf:

dir                    = .

[ ca ]
default_ca                = CA_default

[ CA_default ]
serial                    = $dir/serial
database                = $dir/certindex.txt
new_certs_dir            = $dir/certs
certificate                = $dir/cacert.pem
private_key                = $dir/cakey.pem
nameopt                = default_ca
certopt                = default_ca
policy                    = mypolicy
default_days            = 365
default_md                = md5
preserve                = no
email_in_dn                = no

[ mypolicy ]
countryName            = match
stateOrProvinceName        = match
organizationName            = match
organizationalUnitName        = optional
commonName            = supplied
emailAddress            = optional

[ req ]
default_bits                = 1024
default_keyfile            = key.pem
default_md                = md5
string_mask                = nombstr
distinguished_name        = req_distinguished_name
req_extensions            = v3_req

[ req_distinguished_name ]
0.organizationName            = Organization Name (company)
organizationalUnitName            = Organizational Unit Name (department, division)
emailAddress                = Email Address
emailAddress_max            = 40
localityName                = Locality Name (city, district)
stateOrProvinceName            = State or Province Name (full name)
countryName                = Country Name (2 letter code)
countryName_min                = 2
countryName_max            = 2
commonName                = Common Name (hostname, IP, or your name)
commonName_max            = 64

0.organizationName_default        = Xplota Soluciones
localityName_default            = Valencia
stateOrProvinceName_default        = Valencia
countryName_default            = ES
emailAddress_default            = [email protected]

[ v3_ca ]
basicConstraints                = CA:TRUE
subjectKeyIdentifier            = hash
authorityKeyIdentifier            = keyid:always,issuer:always
keyUsage                    = cRLSign, keyCertSign
nsCertType                         = sslCA, emailCA, objCA
subjectAltName                = email:copy
crlDistributionPoints            = URI:http://ca.xplota.com/cert/
nsCaPolicyUrl                = http://ca.xplota.com/policy.html

[ v3_req ]
basicConstraints                = CA:FALSE
subjectKeyIdentifier            = hash

[ air_cert ]
basicConstraints              = critical, CA:false
keyUsage                               = critical, digitalSignature
extendedKeyUsage               = critical, codeSigning
subjectKeyIdentifier            = hash
authorityKeyIdentifier            = keyid:always, issuer:always
subjectAltName                = email:copy
issuerAltName                = issuer:copy
crlDistributionPoints            = URI:http://ca.xplota.com/cert/

Quizás tengas que cambiar alguna ruta a los archivos de tu CA. Son muchas opciones, pero no hace falta que conozcas los detalles.  Generemos ahora nuestro certificado:

openssl req -new -nodes -out air_key-req.pem -keyout private/air_key-key.pem -days 3651 -config ./openssl.cnf -extensions air_cert

Cuando te pida los datos del certificado, muy importante: los relativos a nombre de la organización, localidad, provincia y país tienen que ser los mismos de la CA o no podrás generarlo, pon exactamente los mismos datos. En Common Name debes poner el nombre que quieres que aparezca en vez de aquél “DESCONOCIDO, puede ser el tuyo o el de tu empresa.

Si has llegado hasta aquí sólo nos queda firmar el certificado con la CA.

openssl ca -extensions air_cert -out air_key-cert.pem -days 3652 -config ./openssl.cnf -infiles air_key-req.pem

Cómo vimos con los certificados cliente, el certificado generado no nos sirve de mucho, debemos exportarlo a un formato más estándar:

openssl pkcs12 -export -out air_key.pfx -in air_key-cert.pem -inkey private/air_key-key.pem -name "My Code Key" -chain -CAfile cacert.pem

Hemos terminado. Copia el archivo air_key.pfx a tu estación de trabajo y exporta tu proyecto AIR con este certificado. Si no hay problemas extraños tendrás tu aplicación firmada. Vamos a probarla:

signed air app untrusted
Vaya, no funciona. ¿Qué ha pasado? Sencillo, lo que comentaba al principio, tu sistema no tiene instalado el certificado de la CA con lo cual no confía en tu aplicación. Instalarlo es muy sencillo. Se importa el archivo cacert.pem en la lista de “Entidades Emisoras de Confianza” de tu navegador web.

Veamos ahora qué ocurre si tratamos ahora de instalar la aplicación firmada con nuestro certificado:

air_trus¡Funciona!

Cómo mi entorno es limitado y ya tiene mi CA puedo fácilmente firmar yo mismo mis aplicaciones, en un entorno real más general no sería posible y habría que pagar por la confianza.

Un aspecto muy importante sobre la firma de aplicaciones AIR y a tener en cuenta es que debes firmarla siempre con el mismo certificado, cada nueva versión debe ir firmada con el mismo certificado que utilizaste la priemra vez o tus clientes no podrán actualizar de una versión a otra ya que el mecanismo de seguridad detecta que el certificado es distinto y puede ser una brecha de seguridad.

Espero haberos aclarado un poco el mundo de las firmas y confianzas en AIR.