domingo, marzo 25, 2012

Experiencia de un error pero no de muerte

Como es costumbre y tradición en nuestro país Colombia, en el transporte publico masivo, ocasionalmente se suben vendedores ambulantes, o personajes solicitando ayuda económica para determinada causa personal. En una oportunidad que yo utilizaba este servicio de transporte, se subió. un personaje solicitando una ayuda económica, sin entrar en detalles en la justificación, me llamo la atención un comentario que realizo de un colega electricista que murió en la construcción de un edificio en un pueblo de Colombia; un electricista experimentado y veterano en el oficio, que con un puntero y una maceta golpeaba una estructura intentando ajustar el espacio para instalar un dispositivo eléctrico, por error el puntero realizo contacto con un cable de alta tensión e inmediatamente el electricista falleció.

Con esta experiencia, me recordó,  una experiencia no muy grata. En una ocasión, operando una aplicación critica desarrollada por mi, oprimí un botón, que ocasiono perdida de datos; este evento sucedido en un momento de mucha  tensión  y presión; donde la información era utilizada para grandes decisiones corporativas.

Estos dos eventos tienen algo en común, la confianza. Aunque mi experiencia no trajo consecuencias de muerte, tanto el electricista como yo conocíamos la herramienta, el escenario, las consecuencias de alguna acción inapropiada, sin embargo por la confianza que teníamos en la tarea realizada no se tomaron todas las precauciones, y se saltaron las medidas de seguridad. 

Son solo dos experiencias, que aunque puedan seguir sucediendo, porque no aprendemos de errores y experiencias anteriores hay están en el tiempo.

lunes, febrero 06, 2012

this one





I have been reading several books, I decide to do this painting.
the most important reason is explore the fantastic world and capturing of 
the mind power. by Graphic Designer petter (all rights reserved)

jueves, diciembre 29, 2011

Calendario 2012 - Comfenalco Tolima


jueves, octubre 13, 2011

lunes, septiembre 12, 2011

23 frases más usadas de los programadores

23 frases más usadas de los programadores: Al estar desarrollando una aplicación, siempre ocurren anécdotas y se crean frases celebres que nos rodean. Seguramente si sonreías es porque algunas son conocidas en tu entorno o soles usar bastante. Si tienes algunas que soles usar o escuchaste, compartila. Estas frases recolecte de una comunidad de programación de computadoras
  1. "Pues es raro…"
  2. "Nunca había pasado antes."
  3. "Pues ayer funcionaba…"
  4. "¿Cómo es posible?"
  5. "Tiene que ser un problema de tu hardware."
  6. "¿Qué hiciste mal para lograr que fallara?"
  7. "Algo debe de estar mal en tus datos."
  8. "¡Si no he tocado ese módulo en meses!"
  9. "Debes de estar usando una versión anterior."
  10. "Es sólo una desafortunada coincidencia."
  11. "¡Es que no lo puedo probar todo!"
  12. "ESTO, no puede ser la causa de ESO."
  13. "Funciona, pero no lo he probado."
  14. "¡Alguien debe de haber cambiado mi código!"
  15. "¿Has comprobado que no haya algún virus en tu sistema?"
  16. "Ya sé que no funciona, pero ¿te gusta?"
  17. "No puedes utilizar esa versión en tu sistema"
  18. "¿Por qué quieres hacer eso?"
  19. "¿Y tú dónde estabas cuando se colgó el programa?"
  20. EN MI MÁQUINA SÍ FUNCIONA!"
  21. ¡Como .... se llamaba la función!
  22. ¡Tengo que volver a revisar el manual! ¿Hay manual?... No.
  23. Error de usuario.
Fuente: Comunidad de Programación de Computadoras del Orkut

jueves, septiembre 08, 2011

Día de la libertad del software / Software Freedom day

El 17 de Septiembre de 2011 esta cerca, es la fecha esperada por todos los apasionados y no apasionados por la libertad del software, esta planeado y programado  a nivel mundial el día de la libertad del software


Este año se han unido al evento un mayor numero de personas que día a día se involucran activamente en las diferentes comunidades de software libre.


Ibague va ser una de las ciudades en los que se van a realizar eventos, la pagina oficial de Ibague es la siguiente: http://wiki.softwarefreedomday.org/2011/Colombia/Ibague/IbagueLibre A la fecha de hoy no aparece confirmado el lugar, sin embargo uno de los conferencistas  vía Twitter me comento que posiblemente va ser en la Universidad del Tolima.

miércoles, abril 27, 2011

En equipo los de hardware y los de software

No hay que olvidar nunca la misión de un departamento de informática. Cuando en algunas empresas por le tamaño de las mismas se tiene dividido los roles dentro de informatica: los que se encargar de la instalación y mantenimiento del inventario tecnológico de hardware y lo que se encargar del desarrollo y mantenimiento de la parte lógica del inventario tecnológico - Software. Siempre se debe tener claro el objetivo final de la solución tecnológica. 

No basta con dividir determinado problema y aislarse de el porque no es del segmento responsable. El trabajo en equipo en la solución beneficia todas las soluciones tecnológicas. En grupo, con un método de comunicación eficiente, con sentido de pertenencia de un grupo y con un líder con capacidad de integrar las partes se pueden obtener mejores resultados que la suma de las partes

En todas las etapas sin importar la metodología empleada en la solución tecnológica, lograr una integración de las partes minimiza lo errores en el día a día y beneficia a los usuarios.

Y siempre hay que probar, no limitarse y suponer que las cosas deberían de funcionar porque siempre que se realiza esa tarea a funcionado.


jueves, abril 07, 2011

comentario proyecto de ley en Colombia sobre "acabar la pirateria"

Aquí en Colombia  el Min. German Vargas radico un Proyecto de ley donde su principal objetivo es evitar la piratería.

Comentarios:

  •  Que el país tome medidas represivas parta combatir las infracciones al derecho de autor (piratería)  en todos los escenarios es una buena medida y aplaudido y respaldado  por la mayoría de Colombianos; pero que por evitar la piratería se vulneren otros derechos fundamentales como la libertad es lo que es cuestionable de la ley.
  • No esta claro y estipulado en el proyecto de ley los casos, tipo de material que deba retirarse, la mayor parte es el procedimiento que se debe seguir  un prestador de servicio para tomar la decisión  de retirar contenido de los servidores administrados.
  • Si en Colombia una entidad que pueda tener la independencia de el gobierno, de la clase política, etc que pueda monitorear los servidores Colombianos y filtrar contenido en lo concerniente a la piratería; y que esta entidad fuera la responsable de hacer las solicitudes a los prestadores de servicio, podría ser una opción, pero así como esta planteado se presta a manipulación de contenido y limitaciones a la libertad.
  • Aunque el proyecto de ley lo están vendiendo como una solución a la piratería, en el no se hace referencia a la manera al procedimiento para demostrar la propiedad o el derecho de autor. Para efectos de esta ley, se debería de establecer que entidad seria la encargada de certificar la propiedad de un contenido.


martes, febrero 15, 2011

Language string failed to load: recipients_failed

En un script de envió de correos masivos que tengo, utilizo la clase phpmailer.  Últimamente sin una explicación aparente estaba saliendo el siguiente error "Language string failed to load: recipients_failed". 

No existe en Internet suficiente y completa información que documente la solución a este problema. En algunos foros como Foros del web tratan en algunos mensajes el tema pro sin una solución definitiva.

Básicamente este comportamiento sucede cuando el correo electrónico al que se le va enviar un mensaje esta mal configurado.

La solución que pude encontrar sin ser la mas apropiada fue:

En el if cuando verifico si el correo es enviado o no, en el caso de no ser enviado, destruyo el objeto y vuelvo a crearlo. y así si esta en un ciclo no es abortado y puede continuar enviando los correos.

ej:


if($mail->Send())
          // sin problemas con el envió
}
else
          // aqui es cuando hay un problema con el envio

          $mail = new PHPMailer(); 
       
          //Especifico ciertos datos del correo 
          unset ($mail);

  $mail = new PHPMailer(); 

$mail->From = $correo; $mail->FromName = "Boletin ".$descripcion; $mail->Subject = $titulo; $mail->Host = "localhost"; $mail->Mailer = "smtp";}         

Y así se continua en el ciclo hasta que termine de enviar todos los correos.


martes, enero 18, 2011

Ganadores de los 5 hosting de regalo

En el blog Reparación de PC en un concurso que realizaron me regalaron 1 hosting gratis por un año. Gracias.


Ganadores de los 5 hosting de regalo: "
Lo prometido es deuda, los ganadores del concurso de 5 hosting gratis de Reparación de PC son los siguientes:
Jorge Eduardo Olaya ha ganado un Hosting Profesional con las siguientes características:
  • Espacio Disco MB: 500
  • Transferencia mensual MB: 25000
  • Usuarios FTP: 5
  • Total de Correos: 5
  • Lista de Correos: 5
  • Base de Datos: 5
  • SubDominios: 5
  • Cantidad de enlaces a agregar: 7
jaimebarrios69 ha ganado un hosting Intermedio con las siguientes características:
  • Espacio Disco MB: 300
  • Transferencia mensual MB: 15000
  • Usuarios FTP: 5
  • Total de Correos: 5
  • Lista de Correos: 5
  • Base de Datos: 5
  • SubDominios: 5
  • Cantidad de enlaces a agregar: 5
kilimon, tHeLaRiOs, quiero un hosting (un buen nick xD) han ganado un hosting básico con las siguientes características:
  • Espacio Disco MB: 100
  • Transferencia mensual MB: 10000
  • Usuarios FTP: 5
  • Total de Correos: 5
  • Lista de Correos: 5
  • Base de Datos: 5
  • SubDominios: 5
  • Cantidad de enlaces a agregar: 3
Nos pondremos en contacto (martes 11/01) por correo para que me indiquen el dominio y poder crear las cuentas de hosting.
Gracias por participar!

Entradas relacionadas en Reparación de PC

"

miércoles, diciembre 08, 2010

Depreciación del software


Mi jefe lanzo una pregunta de que tenia que calcular y dar el dato la vida útil del software para poder calcular la  depreciación del software, este dato lo debería de dar a  a la gerencia; empezaron a fluir varia ideas al respecto sobre si el software es despreciable o no y a justificar el porque, se analizaba la vida útil de aplicaciones en particular y su uso en el tiempo. 

 En Internet a varios foros que han tratado el tema: en Todoexpertos  hay una pregunta "Un sotfware tiene depreciacion o amortizacion" y en CHW encontre el siguiente foro "Un software es depresiable?"

Independientemente de la discusión  contable si por el software ser un bien intangible se amortiza y no se deprecia,  aunque parezca muy fuerte, los años de depreciación del software debería de ser cero (0).  Si se ha pagado por el uso del software, en el mismo momento de la compra, el activo se vuelve $0.

El activo de la empresa no es el software si no la información. 


jueves, agosto 12, 2010

PHP The Anthem - Himno de PHP





Letra:




Oh yeah. (Oh yeah.)
(Just one day it just hits you all of a sudden. It’s just like…)


Oh yeah, I’m so PHP this year.
Got a mic in the left, and ‘n the right, cold beer.
Compile that Apache.
Now we got version 5 and two chicks laid out in the back seat.
Yeah, sometimes the code looks a little trashy.
But, this ain’t ColdFusion.
Stop talking sassy, and pull up them panties.


I’m really… I’m just saying; why don’t you go check out the API reference docs.
They’re really good.
(They are.)


Is it underline or CamelCase?
I can’t remember; I’ve been busy poundin’ cakes.
It’s what PHP developers do.
We get more booty than you.
Don’t be jealous when you smell us; check the Boolean dude, it reads…


[chorus]
(Oh yeah.)
Check the Boolean dude; it reads true.
(Oh yeah.)
PHP gets more booty than you.
(Oh yeah.)
Check the Boolean dude; it reads true.
(Oh yeah.)
PHP gets more booty than you.
(Oh yeah.)
Check the Boolean dude; it reads…


True, PHP gets more booty than you,
but we still keep it clean.
MySQL really real wrappin’ all strings.
Filter input like it was a herpes strain.
(You know what I’m saying?)
That’s why we got the STD class.
Objects we pass might need to be trashed.
Girl, what you doin’?


Come gunzip this.
Be my witness as I strip this string of all slashes.
Now, I got what I need.
No traversing my filesystem when you ain’t supposed to be.
That’s how it is rolling with PHP.
All the hot chicks, yeah, they love PHP.
(It’s so true.)
(Oh yeah, that’s what I’m talking about.)


[chorus]


(Yo, yo, tell ‘em about it.)

martes, junio 29, 2010

Inter-Screen y Hie-d. Teconología Colombiana en Campus Party Colombia

Carlos Anzola haciendo la presentación de su producto "Inter-Screen y Hie-d" en el campus Party Colombiano.





lunes, junio 21, 2010

Y usted dicta clases?

Una pregunta que me hacen muy seguido usuarios, amigos  y personas en general cuando me ven operando una aplicación ofimática, o configurando algún dispositivo, o desean tener ciertas habilidades y/o destrezas informáticas, o desea aprender a programar.

Usted dicta clases?, cuanto cobra por enseñarme excel? o las típicas: el computador de la casa no me imprime? , el computador de la casa esta muy lento, sera que tiene virus, u unas cuantas mas.

Creo que no soy el único informático que día a día le realizan este tipo de preguntas en el trabajo, en una cafetería, en un e-mail .....

Hay que tener cuidado y ética profesional, si se acepta un contrato enseñanza. Hay métodos de aprendizaje que debería de dominar el instructor, solo con conocer el tema no quiere decir que pueda transmitir el conocimiento fácilmente.

Este tipo de contratos le puede abrir nuevas posibilidades profesionales, si se analiza la oferta con cuidado. 

Tener planeado un curso de un tema que se domine es una buena practica, si se desea estar preparado para la oportunidad.





viernes, junio 04, 2010

Cómo distinguir a los buenos programadores

Alberto Fernández Capel  "Cómo distinguir a los buenos programadores", blog "Código Comestible", entrada del 4 de Junio de 2010. URL: http://codigocomestible.com/2010/06/04/como-distinguir-a-los-buenos-programadores/

En una entrada anterior hablaba de cómo los buenos desarrolladores son altamente rentables para las empresas. Aunque sea interesante, ese es un dato TBU, -True But Useless: Cierto pero inútil. De nada nos sirve saber que los buenos programadores son muy rentables si no podemos encontrarlos. El problema, como bien señala Jorge Eduardo Olaya, es ¿cómo podemos distinguir a los buenos desarrolladores de los mediocres?

Es una pregunta complicada que no tiene una respuesta sencilla y no es extraño que muchas empresas se equivoquen con su respuesta. Los procesos que habitualmente siguen las grandes empresas para contratar gente son bastante penosos y están condenados al fracaso. Examinarlos nos puede servir, al menos, para descubrir como no se distingue a los buenos desarrolladores.
En las grandes empresas las contrataciones suelen ser responsabilidad del departamento de recursos humanos, es decir gente especializada en contratar trabajadores pero que rara vez tiene conocimientos técnicos. Y eso es lo peor que se puede hacer para encontrar buenos programadores: dejar que sólo gente sin conocimientos técnicos evalúe a los aspirantes.

Alguien sin conocimientos técnicos tiene unos medios muy limitados para saber si un aspirante es adecuado para un puesto. Al final acaba limitándose al sencillo criterio de contar las bolitas del curriculum:
  • Experto en desarrollo de Servicios Web SOAP: 5 puntos
  • Experto en programación en JEE con EJBs -qué serán los EJBs piensan con razón en RRHH- 10 puntos.
  • Sun Certified Enterprise Architect for the Java EE Platform: 5 puntos
  • Etcétera.
¿Y qué significa eso? Alguien con la cara suficientemente dura, puede “ser experto” en cualquier cosa.
Incluso, aunque el currículum no esté inflado, es muy difícil hacerse una idea del candidato sólo con leerlo. La experiencia y los títulos son indudablemente importantes, pero dicen poco de la dedicación y la capacidad de aprender nuevas cosas que, al paso al que evoluciona la informática, son las características más importantes que debe tener un buen desarrollador.

La experiencia siempre es un grado, pero no es un criterio infalible: no es raro ver a gente que lleva diez años programando sin haber aprovechado ese tiempo. Si alguien lleva diez años haciendo chapuzas, casi mejor que no tuviese esa experiencia, porque acaba tan acostumbrado a hacer chapuzas que no concibe que se pueda desarrollar software de otra manera.

Con los títulos pasa lo mismo: hay quien aprende en cada curso que hace, y hay otros muchos que sólo sacan de provecho un papel para enmarcar y dejar colgado de la pared, y una frase en el currículum.
Entonces, si todos estos métodos son tan deficientes, ¿como podemos distinguir a los buenos desarrolladores?

Para encontrar la respuesta pensemos en que, aunque alguien sin conocimientos técnicos no puede distinguir el código bien escrito del que es una chapuza, un buen desarrollador puede distinguirlos con facilidad. Hablando con un candidato puede hacerse rápidamente una idea del nivel de conocimientos del candidato, de si le interesa lo que hace y si realmente le gusta su trabajo. Si el candidato resuelve alguna tarea práctica es fácil evaluar su capacidad de enfrentarse a los problemas. Y si ha colaborado con proyectos Open Source muchísimo mejor: mirando sus contribuciones puedes hacerte una idea muy aproximada cómo trabaja ese programador.

Al final la respuesta al enigma de cómo se distingue a los buenos programadores es sencilla: los buenos programadores se distinguen entre sí.

"




Que pasa con el mantenimiento de software.

Cuando no existe una política metodológica a seguir  sobre mantenimiento de software, ni existe gestión de configuración o gestión del cambio; al solicitar un requerimiento de cambio un usuario o un cliente se pueden presentan  problemas al tratarle de explicar las implicaciones que trae para la aplicación el cambio solicitado. 

Cuando un usuario se contacta con el líder del producto para comentarle de una idea de modificación que tiene, el  usuario o  cliente le parece que lo que esta requiriendo es un cambio sencillo, pequeñito  y no visualiza el alcance o los problemas. La negociación con el usuario en este momento es de gran importancia, en el mejor de los casos lo que esta solicitado ya esta desarrollado y en producción, es cuestión de explicarle el procedimiento  para realizar esta tarea en el software. Hay que tener ética y de ser necesario decir no en el momento oportuno, en caso de que dicho requerimiento no sea viable.

No todos los cambio son planteados por los usuarios y/o clientes, también existe mantenimiento al encontrar r un error en el comportamiento. Todos los errores encontrados y/ reportados  debería de quedar registrados en una bitácora, para llevar un registro de estos incidentes, hay algunas herramientas que le ayudan a gestionar esta información.

Si después de negociar el cambio, realizamos el cambio directamente en el código, sin ninguna planeación, análisis, y demás procesos  de ingeniería   de software y calidad  en lo relacionado con mantenimiento. El resultado va afectar el desempeño y la calidad del producto. De igual manera todo cambio debe de quedar correctamente registrado y los documentos de análisis, diseño y otros actualizados.

En caso de no contar con un sistema de control de versiones, aunque parezca obvio, sacar una copia de el código fuente es una buena practica.





miércoles, mayo 26, 2010

Lo que se gana, de lo que se pierde.

En días pasados me contacte por teléfono y e-mail con un contratista que estaba involucrado en un proyecto de desarrollo de un software, después de un proceso  corto de negociación llegamos a unos acuerdos.

El me envió un documento con las especificaciones, que resulto ser el producto final de el análisis que realizaron. Por la forma como estaba organizado el documento me di cuenta que utilizaron la metodología de desarrollo proceso unificado, no sé si estaban siguiendo la metodología estrictamente, pero por lo menos el documento se acerca mucho a los principios de esta.

Esta nueva metodología de desarrollo, adaptable a los proyectos de desarrollo puede ser una buena opción para seguir una metodología en los proyectos de desarrollo.

Una de las tareas al  aplicar ingeniería en la construcción de software, es tomar la decisión de que métodos, procesos y herramientas utilizar no es tarea fácil, existen muchas opciones, y a veces no se saber por dónde empezar. Seguir el proceso unificado (UP) orientado a la tecnología no a las personas, es una alternativa a tener en cuenta.

Aunque el contrato de desarrollo fue terminado con el contratista, el documento que ""me gane" me ha servido de plantilla para mis proyectos, en especial la de los casos de uso. 





lunes, abril 19, 2010

Presentación de Zend y netMX

En el primer  encuentro Colombia PHP estaba agendada una charla de la empresa NetMX, que es la única empresa para Latinoamerica y el Caribe Partner de Zend.

Esta es la presentación que enviaron para la charla:

Productos y servicios de Zend y NetMX