Alternativa a json_encode() de php

22 diciembre, 2010 at 11:54

La versión 5.2 de php tiene la posibilidad de agregar la función json_encode() si cargamos una librería en el php del servidor. json_encode() tiene la capacidad de convertir la mayoría de los datos de php en estructuras de datos válidos para JavaScript.

Lamentablemente algunos proveedores de hosting no habilitan json_encode(). Pero no se precupen, ya tenemos la alternativa :).

jsonwrapper ( http://www.boutell.com/scripts/jsonwrapper.html ), provee de las funciones necesarias para reemplazar y/o crear una alternativa a json_encode en los servidores que no la tengan soportada. Solo es necesario agregar un » require ‘jsonwrapper.php’; » en nuestro código ( y evidentemente subir la librería a nuestro directorio fuente ) para que todo funcione de maravilla.

sitio oficial de jsonwrapper –> http://www.boutell.com/scripts/jsonwrapper.html

Delineación Asistida de Cuerpos de Agua con Lake Walker para OpenStreetMap

12 diciembre, 2010 at 17:00

Hace algunos días me he encontrado con LakeWalker, un buen plugin para delineación asistida, disponible para el editor JOSM de OpenStreetmap. No es espectacularmente bueno, pero al menos cumple con las funcionalidades básicas esperadas en una herramienta como esta.

Para quienes realizamos aportes constantes a OpenStreetmap, puede resultar bastante interesante la integración de esta herramienta en el proceso de delineación de cuerpos de agua u otros sectores de características parejas ( como bosques o caminos ).

LakeWalker por ahora solo trabaja con imágenes liberadas de LANDSAT, por lo que no siempre es posible acceder a resultados en donde no se quieran correcciones.

Según el destripe que he realizado del plugin, el funcionamiento consta en descargar una imagen satelital infraroja desde landsat de la zona donde se ha seleccionado la delineación asistida. Generando de esta forma la traza de puntos, lineas y/o polígonos necesarios.

No es mala idea usar Landsat, pero según he visto estos último días, el servidor WMS de la NASA que cuenta con estas imágenes, no siempre está disponible ( al menos para la red de Chile ). ( He estado pensando seriamente en mejorar el plugin para permitir usar imagenes infrarojas propias ).

LakeWalker ya viene incorporado en las últimas versiones de JOSM, por lo que si actualizar su software podrán probarlo.

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?…

Historia de como integrar correctamente el motor de búsqueda google a un sitio web

27 agosto, 2010 at 14:04

Todos sabemos que google permite crear busquedas «personalizadas» , permitiendo restringir los dominios de búsqueda y «acomodar» los resultados a un estilo parecido a la de la web que desplegará los resultados.

Sin embargo algunos webmasters que desean personalizar los resultados gráficos, más allá de los que google les ofrece, no tienen opción más que meter las manos a los códigos y diseñar inventos raros.

Hace algunos días (o semanas), en lacosox.org nos propusimos mejorar el motor de búsqueda del «Grupo de usuarios GNU/Linux IX región Chile» ( http://www.gulix.cl ).  Ellos anteriormente tenían una búsqueda «personalizada» a través del motor de búsqueda de google, pero a decir verdad esta «personalización» dejaba mucho que desear. El motor de búsqueda era excelente, pero la integración gráfica era pésima.

280px-Busqueda_antes_de_personalizar

Al realizar la búsqueda el resultado era este.


Nos Propusimos encontrar la forma de integrar correctamente el buscador Goole en la web,  permitiendo que los resultados se desplegaran dentro de la lógica gráfica del sitio y manteniendo al mismo tiempo los derechos y lógica de Google Inc.

Después de algunas horas de trabajo logramos finiquitar el tema , obteniendo como resultado una visión similar a esta.

280px-Busqueda_despues_de_personalizar

Resultados actuales de la búsqueda.

La lógica ingenieril que está detrás de este proces puedes revisarlo en el acta de actualización del sitio de Gulix.cl, donde se encuentran todas las características técnicas que permiten realizar esta personalización extrema. Puedes revisar el acta aquí -> ( http://gulix.cl/wiki/WebGulix_2.0.3 )

Aunque te puedo adelantar que la lógica se basa en este diagrama:

 Diagrama que explica toda la lógica de solución.

Diagrama que explica toda la lógica de solución.

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