Después, los preciados namespaces. Con esto vamos a tener más libertad a la hora de nombrar clases (ya que se evitan los conflictos de nombres) y beneficiará a la programación con objetos toda.

Con el asunto de namespaces se vienen varias palabras reservadas nuevas, necesarias en el momento de tratar con las nuevas funcionalidades.

A la espera del release, lo único que tenemos por ahora son los snapshots dev.

En cuanto a sistemas e informática, en un país en el que no tenemos tradición de horario de verano, el asunto no deja de ser engorroso.

Para hacerlo bien, además de adelantar una hora el reloj de la PC, hay que cambiar la zona horaria a “GMT -2″. La pueden encontrar con varias denominaciones, siendo la más común “Atlántico Central” ó “Mid-Atlantic“. En Windows, al cambiar la zona horaria automáticamente se adelantará una hora el reloj. Todos estos cambios manuales no serían necesarios si la política de cambio horario fuese regular y la configuración para “Argentina” la contemplara. Es decir, que necesitamos una regularidad en la política :).

Si cambiamos sólo la hora, pero no la zona horaria, algunas aplicaciones mostrarán horas incorrectas, ya que se manejan por el tiempo GMT. Un ejemplo es Gmail. Si adelantamos la hora pero no modificamos nuestra zona horaria, es como si estuvieramos corriendo el horario GMT.

Espero haber sido claro… a cambiar los relojes!

Una vez tuve una visita a este mismo blog desde una búsqueda en Google para la siguiente query: “chico lindo que tenga msn”.

Evidentemente Google tiene que seguir ajustando sus algoritmos :) Pero, ¡la semántica ya está aquí! Y esta realidad es por fuera del chiste.

Pero ¿para qué? Bueno, a mí me resulta útil para cuando estoy en la cama con la notebook y quiero cambiar de tema o subir el volumen de la música, que corre en mi desktop, alejada cinco metros de mi mano :)

Para bajártelo e instalarlo en tu Winamp: Web interface, un plugin para winamp.

Es interesante la propuesta, al menos en principio: se trata de publicar tus libros y compartir experiencias de lectura y opiniones con amigos y el resto del público.

Mi perfil: http://www.shelfari.com/maurogullino

Si bien ya había probado betas anteriores, ésta sí se instaló bien y ya está funcionando en mi pc. Evidentemente se han corregido varios problemas, conclusión a la que llego principalmente porque el producto ahora funciona!

No es momento de hacer review ya que sólo lo usé unos segundos, pero me gustaría destacar dos cosas:

1. Safari es realmente rápido, me ha impresionado.
2. Para todos los que trabajamos en desarrollo web: echenlé un ojo. Verán qué distinto se ve todo.

Les dejo el link para descargarse el beta de Safari para Windows.

Ser o no un workaholic no sería algo tan relevante en sí mismo, sino que lo interesante es tener en cuenta las consecuencias en la salud que este tipo de ¿hábitos? puede tener.

Les dejo los puntos más relevantes desde mi punto de vista. Pueden encontrar la nota completa aquí.

Q: What are some of the dangers of working too hard?

A: The stress that goes along with working too much has been shown to lead to substance abuse, sleep disorders, anxiety and ultimately to physical problems like heart disease.

Q: Do workaholics accomplish more than people who work fewer hours?

A: Often, they don’t. That is because, as perfectionists, they may become so fixated on inconsequential details that they find it hard to move on to the next task.

Entre estos servidores de eMule caídos están los conocidos DonkeyServer, que eran un punto de reunión importante dentro de la red.

Se escuchan varios rumores, desde desconexiones intencionales por el alto tráfico que estos servidores tenían, hasta factores legales que hicieron caer a estos gordos de la red eMule.

Lo cierto es que por ahora siguen caídos y sin noticias oficiales.

Como en muchas otras empresas, trabajamos con servidores de prueba y de producción, separados. En uno de ellos se lleva a cabo el desarrollo y testing de las aplicaciones y luego de superadas ciertas etapas se “sube” a producción, en donde el código tiene su feliz vida dentro de la aplicación real que navegan los usuarios finales.

Hoy quiero contar algo que me pasó en estos días, al intentar subir unos cambios a una aplicación, alojada en un servidor que también me toca administrar. Entre los servidores de desarrollo y producción, en este caso, hay algunas diferencias, pero no demasiado sustanciales. De hecho, no afectan para nada el desarrollo y, casi el cien por ciento de las veces, todos los cambios se limitan a una simple transferencia de archivos.

Hoy fue la excepción. En ciertos casos de uso… bueno, con algunas urls, parte de la aplicación dejó de funcionar. Vueltas y vueltas, configuración de php, investigar las reglas del mod_rewrite, url encodings… ¿qué está sucediendo?

En desarrollo todo iba perfecto, pero en producción, con ciertas combinaciones de caracteres en la url, se obtenian errores 400 alias “bad request” que, junto al 500 (”internal server error“), formaría algo así como la pantalla azul de la muerte para Apache.
Como casi todos los problemas insondables del universo que alguna vez fueron resueltos (y seguramente lo mismo pasará con los que no lo fueron aún), di en la tecla por una suerte de inspiración momentanea, o iluminación. La fuente del problema era una regla del mod_security.

Claro! En desarrollo no lo utilizamos tan severamente como en producción, y el error se veía tan genérico que ni se me ocurrió. Se me ocurrieron decenas de otras causas antes de dar con la correcta.

Ahora bien: ¿qué tiene que ver con el título de mi post? ¿Seguridad y usabilidad? ¿Dónde?

La usabilidad no es sólo de los usuarios. Hace rato que observo diariamente lo que yo llamo “usabilidad del código“, o como quieran llamarle. Se trata de la facilidad de edición de un programa, por ejemplo. En este caso, la facilidad de subir cambios a un servidor de producción.

Como en producción (o live) tenemos reglas más severas, a veces se producen este tipo de cosas inesperadas.

Para dar otro ejemplo un poco más simple: transferir archivos por ssh es un poco (mínimamente) más incómodo que por ftp liso y llano. Pero, por seguridad, nos molestamos un poco más y lo hacemos bien.

Si quisieramos que todo fuera más cómodo, deberíamos bajar nuestros niveles de seguridad. Mientras que si queremos sistemas más seguros, perdemos un poco de comodidad diaria.

La comodidad diaria no es otra cosa más que la usabilidad o, en otras palabras, esos cachitos de felicidad imperceptibles para nuestra consciencia que alguna parte de nuestro cerebro disfruta cuando todo va bien.

Y la seguridad no es otra cosa más que ponerle trabas a esa comodidad. Porque para estar más seguros tenemos que pensar más a través de todo el proceso, y pensar no nos resulta cómodo.

Resulta que una persona se hizo con las claves de las cuentas de correo de cientos de embajadores y altos mandos corporativos a través de la explotación de la red TOR.

La red TOR es un sistema de enrutamiento anónimo. Es básicamente un proxy que ofusca de tal manera el tráfico de los paquetes a través de distintos nodos alrededor del mundo que, prácticamente, es imposible rastrear el origen de un paquete. Es utilizada para navegar de manera anónima.

Si bien todo el tráfico dentro de la red es cifrado, el último tramo no lo es. Esto quiere decir que todo el tráfico que se enrute a través de un nodo TOR, si éste es el último de los nodos que recorrerá nuestro paquete, puede ser capturado directamente, sin más tecnología que un sniffer.

Este ha sido el origen del robo de contraseñas. El atacante instaló varios nodos TOR (cualquiera de nosotros puede abrir un nodo TOR) únicamente para minar su tráfico.

Nuevamente, debemos decir que la inseguridad no está en TOR, sino en la ingenuidad del usuario. O, mejor dicho, el desconocimiento que de cosas tan técnicas tienen los usuarios.

Como bien explican en Hispasec, si no se utiliza el cifrado punto a punto (como SSL), no puede garantizarse la privacidad de los datos en tránsito.

¿Podemos culpar a los usuarios de no conocer a fondo los detalles técnicos del enrutamiento en internet, o de los protocolos de cifrado y de control de tráfico? Por supuesto que no.

Tratándose de usuarios gubernamentales y corporativos, supongo que el mayor peso de la culpa debería recaer sobre los respectivos departamentos de sistemas. Pero claro, todos sabemos que los usuarios suelen tomar iniciativas propias y más hoy en día, cuando los instaladores de software y wizards de configuración facilitan todo al punto de poder prescindir de todo “departamento” de sistemas.
Pero muchachos, de todas formas van a culparlos. “¿Por qué no me avisaste?“… simplemente porque no sabía que lo estabas haciendo. ¿Entonces debemos monitorear todo lo que se hace?

En todo caso vuelve a repetirse la historia: la seguridad es la inversa de la usabilidad.