Javascript as object oriented (javascript class object; class in javascript)

3 noviembre, 2012 at 16:12

El objetivo de las siguientes notas es generar una estructura en JavaScript que nos permita reutilizar de manera limpia las funciones creadas en otros ficheros javascript, para esto reorganizaremos el código intentando aproximarnos al concepto de clase tomando como base su implementación en el lenguaje de programación orientado a objetos PHP. El material que adjunto lo desarrollé para mis alumnos del curso desarrollo web que actualmente dicto, esto dado que no encontré algún documento que describiera una aproximación a la creación de una clase con JavaScript en la web. Abajo adjunto los códigos que use en el documento. Si encuentran un error o algo mal favor reportar a gustavo(arroba)lacosox.org o en el formulario de contacto de esta web, gracias.

DESCARGAR PDF JavaScript como Orientación a Objetos

JavaScript_as_OO_0
Título: JavaScript_as_OO_0 (0 click)
Leyenda:
Filename: javascript_as_oo_0.pdf
Size: 230 KB
src_java_script_as_OO.tar
Título: src_java_script_as_OO.tar (0 click)
Leyenda:
Filename: src_java_script_as_oo-tar.gz
Size: 24 KB

Desconferencias tecnológicas en Temuco, una idea para pensar.

20 noviembre, 2011 at 00:58

Una desconferencia es en realidad la inversa de una conferencia, en la que los asistentes son los charlistas y por tanto los charlistas los asistentes. En las desconferencias no existen asistentes que no participen de forma activa en el desarrollo de la misma, normalmente compartiendo experiencias, trabajos u otros por medio de charlas cortas.

En Temuco hay grandes desarrolladores de software, pero, ¿Qué están haciendo hoy?; cuando veo que la mayoría de los eventos tecnológicos se realizan fuera de la Región me pregunto cuál es la verdadera razón de esto y siempre llego a la misma conclusión y es que los desarrolladores en Temuco no se juntan a conversar, no comparten, no coolaboran. Hey!, pero esperen un momento, colaborar en que? si ni siquiera sabemos en están trabajando… Silicon Valley es el centro de desarrollo tecnológico mundial no precisamente porque algún tipo de energía radioactiva logre que los habitantes sean más inteligentes, es un gran lugar porque allí hay un montón de gente inteligente con ganas de hacer grandes cosas nuevas que se junta en un único lugar ha compartir grandes ideas, Silicon Valley no es una ciudad es sólo el nombre de un lugar, un lugar que perfectamente podría estar aquí, ¿Cuantas universidades están formando informáticos en Temuco?, Temuco es como Silicon Valley pero sin empresas, está la gente que es lo más importante, sólo falta entonces la interacción, las hackathones necesarias para crear la innovación.

Es ampliamente conocido por los informáticos en Temuco lo injustamente mal pagada que es la profesión a nivel regional, a menudo observamos como el mismo trabajo es pagado desde 2 (Santiago) hasta 4 veces (Extranjero) más caro en otras ciudades como consecuencia la innegable e indignante centralización que sufrimos en nuestro país (Chile). Muchos lo pensamos pero pocos son los esfuerzos que se hacen por cambiar las cosas, y es que a esta falta de sinergia se le agrega además el hecho de que las empresas informáticas buscarán siempre mejorar los márgenes de beneficio y ¿que mejor que en una ciudad dónde no hay una fuerte competencia en el área? (grandes pensamientos de una empresa que no voy a nombrar pero que suena a Evercrisp y no es precisamente la de las papas fritas 🙂 . Mejorar el mercado no significa solamente sentarse a esperar que lleguen las grandes empresas multinacionales a ofrecer mejores sueldos, porque eso tardará, si es que llegan. La única forma de mejorar el mercado de la informática en Temuco es sentarse a conversar que se está haciendo y que proyectos podemos realizar en común entre colegas a nivel regional, a nivel local, conversar, generar nuevas ideas, ser activos en el desarrollo regional y no esperar.

El otro día le comentaba esto a un amigo y recordé el término de desconferencia, «Desconferencia tecnológica» de titulados sonó como algo natural, y es que no es una mis locuras temporales, es algo totalmente posible de hacer en Temuco (hay algún titulado de informática que quiera hacer cosas interesantes que este leyendo esto?), dejo abierta la invitación entonces al que quiera tomar un cervezas un día de estos y conversar acerca de como formar un grupo de desconferencias tecnológicas en Temuco, algo simple, charlas cortas entre colegas, pero de todos los participantes, charlas donde compartir experiencias a nivel local, a nivel regional, compartir y colaborar en nuevos proyectos, en nuevas ideas.

¿Qué es un DFD: Data Flow Diagram, ó diagrama de flujo de datos?

17 octubre, 2011 at 15:29

Hay un montón de temas de informáticdfda sobre los que nunca he tratado en este blog y que en algún momento he estado trabajando. Hoy me pidieron hacer un DFD y me acordé de una guia que hice hace ya un buen tiempo para una ayudantía, voy a tratar de ir retomando algunos temas de modelación y compartir algunas cosas en la medida que tenga tiempo. Por el momento voy a compartir esta guia muy básica y un poco añeja pero que estoy seguro que a más de alguien le servirá.

pdta: Guia adjunta abajo. ( haciendo click sobre el titulo de esta nota para expandir o sobre la imagen del costado )

 

 

 

 

 

simbologia_dfd
Título: simbologia_dfd (0 click)
Leyenda:
Filename: simbologia_dfd.pdf
Size: 186 KB

Mis 10 Consejos para administrar servidores y no morir en el intento

14 septiembre, 2010 at 02:29

Últimamente he estado un poco desaparecido, quizá algunos ya se habrán dado cuenta de esto, la razón es que me estoy enfocando en algunas cosas nuevas de la informática.

Como es conocido durante mis años en la universidad he estado trabajando bastante en la línea de GNU/Linux y administración de servidores (de hecho es lo que más he hecho junto con desarrollo web claro), ahora bien dentro de esta «reinvención» personal he decidido entre otras cosas dejar definitivamente la lìnea de administración de servidores (no así GNU/Linux) por lo que he pensado que sería una buena idea escribir un artículo con los principales consejos en base a experiencias que he aprendido hasta el momento en lo que a administración de servidores y GNU/Linux respecta. Los siguientes consejos los he aprendido a punta de porrazos  y más de alguno que me conozca recordará porque he escrito algún consejo, casi todos en base a experiencias reales. Espero que a alguno que este comenzando le puedan servir.

1.- No borres, mueve: Es común borrar datos por error que mas tarde requerimos durante el proceso de mantención de un servidor, no borres, mueve; crea un directorio temporal en /tmp/mimantención y mueve allí los datos que deseas borrar pero borra el directorio al finalizar todo. Este simple consejo puede ahorrarte trabajo extra causado por los típicos errores que uno comete.

2.- Guarda los comandos que haz utilizado en un fichero de log:  Yo lo llamo workbashlog en similitud al conocido changelog. Resulta una muy buena práctica que de a poco he ido implementando; trata simplemente de documentar no sólo el proceso sino que los comandos en terminal que utilizo para realizar los procesos de administración, existen varias buenas razones para hacer esto, sin embargo,  quizá la más importante sea que con el tiempo aprendes a utilizar comandos cada vez más potentes, reducidos y sin causar daños colaterales. Si eres un poco flojo puedes incluso utilizar un comando que se llama «script» para automatizar la creación del  workbashlog en un fichero de los comandos que ejecutas en terminal (como lo haría bash_history pero sin necesidad de cerrar sesión)

3.- Ser paranoico es tu obligación, no una elección, pero hay un límite: Sea el tipo de servidor que sea excepto cuando no sea uno en tu red local casera, siempre y ante todo debes esperar que alguien atacará tu servidor, esta es casi una regla de oro en lo que respecta a administración de servidores. Si dejas un servidor con la posibilidad de accesar por ssh como usuario root estas perdido; si dejas un servidor sin un firewall adecuado estas perdido; si dejas un servidor apache sin módulos de seguridad estas perdido, y así hay mil ejemplo de prácticas comunes en temas de seguridad que no se necesita ser hacker para utilizar. Los ataques por fuerza bruta desde servidores zombie son cosas de todos los días, creer que tu servidor no será atacado es convertirlo en un servidor zombie por lo bajo. Asegurar tu servidor hasta los extremos no debería porque interrumpir tu trabajo ó el de otros que utilicen el servicio, la regla aquí es prohibir todo aquello que no se use o no conozcas para que se usa y creer que quien lo usa (usuario de tu servidor) puede ser tu atacante, déjalo trabajar tranquilo pero elimina la probabilidad de que destruya tu servidor.

4.- Controla el acceso físico a la máquina: Esto tiene mucho que ver con el punto anterior, pero he querido recalcarlo, ambos (acceso físico y por software) son importantes, no sacas nada teniendo un servidor totalmente protegido a nivel de software con firewall espectaculares si el acceso físico a la máquina es cosa de niños. He tomado el control de servidores en forma física (con autorización claro) en minutos, tener acceso físico a un servidor es incluso peor que no utilizar contraseña para acceder vía ssh por ejemplo.

5.- Asegura tu trasero: Es común (quizá más de lo que se pueda creer) quedar colgado mientras se realizan operaciones en el servidor. Esto se refiere a perder el control de servidor sin haber establecido ningún tipo de seguro antes de esto,  frases típicas para ejemplificar este caso son: «el firewall que he creado me ha cerrado el puerto de ssh y he quedado fuera», «la actualización de software me ha instalado un nuevo kernel que ha fallado al rearrancar la máquina», «mientras actualizaba datos en mi web me han robado la contraseña de la base de datos»«han interceptado mi comunicación sin cifrar y me han robado los datos». Recuerda siempre crear un seguro antes de realizar procesos críticos , visualiza 2 o tres jugadas a futuro como la harías si jugaras ajedrez (asegurarías a la reina o al rey antes de atacar).  Algo muy básico como programar un cron de autoreinicio del servidor en un período de 45 minutos más antes de comenzar a realizar una tarea que sabes te tomará al menos de ese tiempo puede salvarte frente a problemas como cierre de puertos, etc.

6.- Nada de puertas traseras: Una mala práctica recurrente en administradores de servidores es crear puertas traseras para tomar el control a posteriori en caso de cualquier cosa del servidor. No recomiendo hacer esto por razones casi obvias, las puertas traseras pueden ser usadas por cualquiera. Borra ya ese pensamiento de tu mente y haz el trabajo de manera ética y profesional.  Si tienes un revólver en casa puedes matar a un ladrón con el o el ladrón puede matarte a ti.

7.- No copies y pegues comandos que no conoces que hacen:  Soy un convencido que la mayor parte de los problemas que acarrea un sistema pertenecen no a fallas del mismo sino a una mala operación, comúnmente a un desconocimiento de como se ha operado. Esto último ocurre más a menudo de lo que creemos, copiar y pegar comandos sin tener una mínima idea de que realizan es la peor de las prácticas que puedes realizar en GNU/Linux. A menudo no faltan los chistosos que en algún foro o blog de GNU/Linux publican comandos donde hay  cosas como «rm -rf /»  ó «yes > hola.txt» ocultos entre otros comandos y usuarios llorando que su sistema a petado por causa de ellos, almenos deberías tener una idea de que hace cierto comando antes de ejecutarlo màs aùn si lo haces como usuario root.

8.- Participa de la comunidad: Levantar un servidor con todas las medidas de seguridad disponibles hasta la fecha no basta,  existe un período de tiempo realmente importante entre que una falla de seguridad ha sido detectada y el parche para la misma es liberado, durante todo este tiempo si tu servidor es afectado queda expuesto. Resulta importante participar de comunidades de seguridad (o listas de seguridad de la distribución de GNU/Linux que uses) esto es porque los fallos normalmente son avisados por listas de correo mucho antes que sean reparados, y las reparaciones de los mismos son también liberados por listas de correos mucho antes de que estos sean propagados por los repositorios de seguridad. Para estar preparado debes estar informado.

9.- Establece contraseñas complejas: Estoy casi seguro que este debe ser sino por poco el consejo más repetido en temas de seguridad, sin embargo pocos lo implementan. La razón normalmente es que nadie está dispuesto a memorizar millones de claves para temas de seguridad, sin embargo, existen soluciones a este problema: por nombrar algunas aplicaciones como Keepassx entre otras te permiten manejar contraseñas complejas con una clave única de desbloqueo, averigua sobre eso e impleméntalo.

10.- Utiliza un servicio de monitorio de servidores: Hoy en día existen muchísimos servicios de monitoreo de servidores gratuitos, que básicamente te avisan por correo cuando tu servidor ha caído o cierto servicio ha dejado de funcionar. Son realmente útiles.

Turista v/s Mapuche , doble estándar

30 agosto, 2010 at 22:43

hacen falta los comentarios?…

Como instalar eXeLearning en Ubuntu 10.04 y Ubuntu 9.04 (y derivados)

16 agosto, 2010 at 00:54

Este fin de semana me tocó resolver uno de esos desagradables problemillas que aveces ocurren al intentar instalar aplicaciones, específicamente mi tortura fué la instalación de eXeLearning en su última versión sobre Ubuntu 10.04 y Ubuntu 9.04. Dado que al buscar información del problema me percaté que no está resuelto completamente aún en ninguna web pensé que sería bueno documentarlo por si a alguien le ocurre lo mismo, bueno aqui voy con la historia.

Si ya haz visitado la web oficial de eXeLearning te habrás dado cuenta de algo : la versión disponible para GNU/Linux lleva alli años sin ser actualizada y no hay una versión funcional para la actual distribución, incluso si haz ido más allá intentando instalarla habrás notado que la aplicación depende de un obsoleto Python 2.4, tengo una buena noticia para ti, no estas solo. Si crees que esto es malo quizá deberías leer el artículo escrito por  Juan Rafael Fernández aquí http://blog.ofset.org/jrfernandez/post/2010/01/23/Informe-sobre-el-estado-actual-de-eXe-Learning-y-Wink  en donde nos revela algo mucho peor de fondo en esta aplicación, lo cual explica el porque la misma no se encuentra en los repositorios ni de Ubuntu ni de Debian,  no hace falta leer, examine un par de directorios de la aplicaciòn y se dará cuenta del desastre de la misma. Pero bueno, vamos a una solución parche temporal (de momento funciona bajo python 2.6 y 2.5, procedimiento probado bajo Ubuntu 10.04 y Ubuntu 9.04):

mkdir -p /home/knx/temporalExeLearningUbuntu
cd /home/knx/temporalExeLearningUbuntu

svn co https://exe.svn.sourceforge.net/svnroot/exe/trunk exe
sudo apt-get install python-setuptools
cd exe
sudo python setup.py install
chmod -R 777 /home/knx/.exe/

Descarga el fichero adjunto a este post y luego descomprimelo en tu home de usuario o en otro lugar, la explicación aquí va por el lado de un problema con eXeLearning tiene con Firefox 3.6 (no daré detalles técnicos de eso, al final diré el porque), peus bien, una vez descargado el fichero adjunto el procedimeinto  sigue mas o menos así:

cd /home/knx/
tar -xvzf Proyectos_eXe.tar.gz
cd Proyectos_eXe/
chmod -R 777 *
chmod +x nuevo.sh
./nuevo.sh

Funcionó? (hay una alternativa más fea aquí usando wine, pero obviamente recomiendo la mia porque es mejor de todas formas este es el enlace: http://manuelflr.blogspot.com/2010/03/instalacion-exe-learning-104-con-wine.html )

Conclusiones parciales: 

1.- eXeLearning es una basura desde el punto de vista de diseño de software (incluye su propia versión de casi todo WTF!).

2.- eXeLearning es exelente desde el punto de vista pedagógico y útil.

3.- El proyecto eXeLearning debe ser rediseñado completamente (pero quizá nadie lo haga porque hay 1 desarrollador activo , creo, para más información leer el link que deje arriba del artículo de Juan Rafael Fernández )

4.- sin comentarios (seguro usted tendrá más de uno)…

 

En vista del estado de el proyecto le envié un correo al desarrollador principal para analizar si puedo contruir almenos un paquete actualizado del software para debian y derivados (no puedo hacer más que eso por falta de tiempo), veremos que tal me va con eso, por ahora esta es mi solución parche. Saludos.

Proyectos_eXe.tar
Título: Proyectos_eXe.tar (0 click)
Leyenda:
Filename: proyectos_exe-tar.gz
Size: 809 B