Ayer probé la velocidad de coneccion con el iphone entrando a cuernavaca (en el pullman), no está mal para navegar, pero dista mucho de ser banda ancha.
La señal se pierde con cierta frecuencia tambien, incluso dentro del DF, me parece (aunque es solo sensación) que en Cuernavaca falla menos. Habría que probar la velocidad en sitios centricos, para ver donde está el máximo.
Acabo de ver el anuncio del beta 1 de Django 1.1.
Los cambios no son demasiado dramáticos, pero si hay cosas interesantes, como que le agregan flexibilidad al manejo de módulos, permitiendo el manejo de los mismos por “fuera” de django, también me agrada que le agregaron una opción para que podamos evitar que algunos campos sean “traidos” en los queries, útil para aquellos campos que son lentos de manejar, como los BLOBs, textos, etc.
También en la autenticación le agregaron soporte para delegar la misma al webserver, con lo cual se puede usar la autenticación típica de apache (por ejemplo) para los sitios hechos en Django, muy buena integración si me preguntan 🙂
Al rato me pondré a probar esta nueva versión con lo que llevo de la bolsa de trabajo, y a ver si logro avanzarle un poco más !! hace semanas que no he tenido tiempo.
Bueno, pues ya de vuelta del 3fsl en tlaxcala, y habiendo dormido suficiente como para pensar correctamente, hoy encontré una nota interesante sobre una nueva herramienta que cambiará la historia de la computación y el desarrollo del software para windows !!
Un “escaner” para encontrar bugs explotables que “crashean” las aplicaciones, ahora solo necesitamos que los programadores se sientan tranquilos habiendo encontrado todos los bugs que truenan las aplicaciones, para que los hackers se dediquen a explotar libremente todos aquellos que no lo hacen.
Chale
Esta semana, haciendo una migración de un servidor, descubrimos (los 2 que estabamos migrandolo) un cambio de comportamiento en un script de Perl que usa la combinación opendir/readdir, resulta que el servidor original tenía ext3 en sus sistemas de archivos, y el nuevo reiserfs (defaults de RHEL 5 y SUSE 10.2 respectivamente), el caso es que en el primero el “readdir” devolvía los archivos en el orden en el que fueron modificados descendetemente, es decir, el mas nuevo primero.
En el servidor con reiserfs el orden es bastante “aleatorio”, no es que cambie, sino que no tiene un orden facilmente entendible, entonces mi compañero se puso a hacer un parche al script para ordenar algo que antes no lo requería, hasta que de repente mientras me platicaba de comportamiento normal del “stat” y el “readdir”, caí en cuenta que el nuevo server había cambiado de sistemas de archivos, y bueno, una googleada ligera resulta darnos la respuesta obvia, reiserfs tiene unas tablas raras, que no prentendo entender, para organizar los archivos, y que no tienen nada que ver con parametros como su creacion, modificación, etc.
Se menciona por ejemplo que reiserfs puede mostrarte “.” y “..” (aqui y abajo de aqui) intercalados entre los archivos, lo cual es bastante raro, pero pues así furula reiserfs (no tenemos porque comprender el comportamiento ni de el sistema de archivos ni de su creador).
En fin, ahi queda el tip para cuando alguno de los que lean esta nota lo tenga en mente pa futuros movimientos de sistemas de archivos y el uso de readdir en particular.
Tengo un par de fotos de baja calidad, pero que dejan ver el espectáculo que vemos todos los que pasamos por la parada de camiones de la joya, a ver si hoy me doy un minuto para tomarle fotos a una galería graffiteada por la que se llega a la parada donde tome estas 2 fotos, son aún más impresionantes los dibujos.
Y bueno, creo que a todos nos queda claro que este tipo de expresiones las vemos en todos lados, algunas valen la pena, otras son una porquería egocentrista que no dice nada, y algunas son realmente obras de arte magistrales.
No podemos dejar de notar en la segunda foto la finesa del arte comercial, que tiene su gracia también 🙂
Buen día !
Hola
Ya nos mandaron el poster oficial del tercer foro de software libre en la Universidad Politécnica de Tlaxcala
Hoy al abrir el google reader la primera noticia que veo es una nueva ley en USA que obligaría a los ISP y usuarios caseros de tecnologías como WIFI a guardar al menos 2 años los registros de las IPs y usuarios que se conectaron a sus equipos.
Supongo yo que Obama no tiene tan buenos asesores después de todo, una porque va a estar realmente cañon que los usuarios caseros aprendan a guardar los logs, eso repercute en que tendrán que obligar a los fabricantes a generar lo necesario para que se guarden solitos, y por otro lado, todos los que se jacten de apreciar un poco su privacidad estarán usando MAC address al azar para no dejar huella de su paso por los diferentes hotspots, si antes era ligeramente deseable, ahora con esta ley es casi indispensable.
La siguiente reforma de esta ley será seguramente obligar a usar un sistema de registro usuario-mac-IP para que sea menos sencillo andar anónimo.
Que bonita la globalización !! 😛
Buen fin de semana !
Creo que a todos los que han escrito más de 100 lineas de código para web estarán de acuerdo en que casi nunca es deseable escribir todo el código necesario para el funcionamiento, sino hacer un uso inteligente de bibliotecas para cada cosa que sea posible.
Centrándonos en la parte del cliente (lo que era normalmente la “V” del MVC) ahora resulta que gran parte del proceso de construcción de la interface ([G]UI) para usuario tiene que ver con un montón de programación que no solo tiene que ver con vista, sino con reglas de negocio, mandado y recepción de datos del servidor, entre otras cosas que terminan mezclando las 3 capas típicas que se crean en una aplicación Web.
Esta necesidad de riqueza de funcionalidad (RIA: rich internet applications) en lo que el navegador ofrece hacia el usuario ha resultado en un gran cambio de lo que conocemos como “páginas de internet”, para convertirse en una plataforma de aplicaciones que corre no solo sobre algo que no estaba preparado realmente para eso (el navegador), sino que también corre sobre lenguajes que nunca se pensó serían tan explotados cuando fueron creados (HTLM, CSS, JavaScript), y bueno, ahora pasamos de tener simples funciones que creaban dinamicidad en las páginas, a tener grandes sistemas de paquetes, que contienen desde cosas muy sencillas como modificar partes de una página (DOM) hasta las llamadas “widgets” que son pequeñas aplicaciones apilables en una o más paginas.
Obviamente, esto ha generado el nacimiento de un sin número de herramientas/bibliotecas para facilitar el proceso de creación de aplicaciones “web 2.0”, tenemos desde cosas básicas hasta paquetes con una inmensidad de funciones (scriptaculous, dojo, meteora, GWK, YUI, etc).
Entre las herramientas disponibles tenemos 2 arquitecturas diferentes, una es mantener todo el JavaScript (JS) empaquetado de tal manera que separemos el lenguaje de la aplicación del lado del server por completo del lenguaje del cliente (JS); la otra opción es mantener “escondido” todo el JS y que a través del lenguaje servidor se cree de manera automática todo lo necesario para el cliente, de tal manera que el programador solo utiliza un lenguaje para la totalidad de la apliación, no tiene que tocar para nada JS.
GWT es el ejemplo perfecto de el segundo caso, todo se hace con Java, y de manera interna, sin que el programador llegue a escribir una sola linea de JS, se crea todo el código necesario para el cliente. La propuesta es muy interesante, pero el contra principal es que no hay manera de usar la biblioteca si no sabes Java, o si no lo quieres usar.
El otro lado de la moneda es más flexible, pero requiere no solo aprender con suficiente destreza tanto el lenguaje del lado del servidor (Java, PHP, Python, Perl, Ruby, etc), como aprender Javascript, DOM, y las tripas de la biblioteca que hayas decidido usar para AJAX/Efectos/Widgets. Y no solo esa desventaja tiene, frecuentemente hay serios problemas para mantener la separación de capas, en especial entre la V y la C, porque frecuentemente es más sencillo escribir código (HTML y JS), que será agregado al cliente, directamente en la capa de control, porque la opción de andar creando plantillas para cosas como un “<p>Los datos de $usuario han sido guardados</p>” pues nomas meten más confusión, y la separación de capas en vez de ayudar nos estorba, por otro lado, generar una función en JS que acepte un argumento ($usuarui) y cree el texto que será mostrado no solo es más lento, además es tonto.
De tal manera que tenemos 2 grandes opciones, con grandes limitantes cada una de ellas. Y además, respetando la separación de capas estilo MVC, el hecho de que el cliente necesita saber mucho tanto de vista como de control, genera necesariamente una mezcla de V y C que dificilmente puede ser corregida manteniendo la funcionalidad a menos que te vayas por la opción 1 que te obliga a sujetarte a la funcionalidad disponible en la librería.
La pregunta es cuál es la mejor opción ??, pues yo prefiero lidiar con JavaScript por separado, el lenguaje está hecho para modificar el DOM, y tiene su atractivo, no me agrada mucho la idea de usar cosas demasiado complicadas para “facilitarme” la vida, y por otro lado, el separar el código del servidor con el código que se ejecuta en el cliente, obtenemos mucha más flexibilidad, es más fácil agregar funciones en javascript que modificar el código de un “framework” para agregale nueva funcionalidad. Por otro lado, no haya nada equivalente a GWT para python, php o similares.
Y tu qué opinas ?
