miércoles, 28 de julio de 2010

Agenda de contactos

Hoy en día lo más común es tener nuestras agendas de contactos (con números de teléfono, direcciones, direcciones de e-mail, etc.)  en formato electrónico, ya sea en el teléfono celular, en la computadora, en la nube (como por ejemplo los contactos de Google), etc.

Hay algo que me llama la atención, y es que ninguna de las aplicaciones que conozco para almacenar información de contactos está normalizada.

Por ejemplo, uno de mis contactos es una empresa. De la empresa tengo cierta información, como ser la dirección y el teléfono. Por otro lado, tengo un segundo contacto que trabaja en dicha empresa (información que le dí a la aplicación). ¿Por qué entonces me pide que ingrese el número de teléfono del trabajo? ¡Ese dato ya está en la agenda!

Hasta ahí parece trivial... ¿Por qué nadie lo ha implementado? O capaz que la aplicación existe y no la conozco.

Hay algún detalle más, por ejemplo, de una empresa tengo el teléfono, pero de una persona quisiera también conocer la extensión que tiene. De todas formas, el número de teléfono debería ser una referencia al teléfono de la empresa.

Otra cosa que puede pasar es que la empresa tenga dos direcciones, porque tiene dos oficinas distintas. Dada una persona que trabaja en dicha empresa, va a trabajar en una sola de esas oficinas. Pero tampoco sería complicado hacer que la referencia sea a una de las direcciones en lugar de ser a la entidad "empresa".

Cuanto más lo pienso más natural me parece la implementación... No me queda claro por qué nadie lo ha hecho así.

lunes, 26 de julio de 2010

Se terminan las direcciones IP(v4)?

Leo en ReadWriteWeb, que aparentemente en menos de un año se terminan las direcciones IPv4...

Hay una página en Twitter que lleva la cuenta regresiva. En este momento dice que en 340 días se terminan las direcciones IP.

¿Qué significa que se terminan? Significa que cuando alguien quiera publicar un nuevo sitio web, no va a poder.

Por suerte desde hace años existe el protocolo IPv6, que en lugar de usar direcciones de 32 bits usa direcciones de 128 bits, con lo cual se resuelve el problema por un buen tiempo (hay que multiplicar la cantidad de direcciones actuals por 7,9x1028 = 79,000,000,000,000,000,000,000,000,000 para obtener la cantidad que se pueden usar con el nuevo protocolo).

El único problema es que la adopción de IPv6 ha sido un tanto lenta... Capaz que a partir de ahora se empieza a acelerar.

El otro tema es la compatibilidad. El protocolo IPv6 es compatible hacia atrás, y por lo tanto puede acceder a direcciones IPv4. Pero el recíproco no es cierto... Si yo tengo una dirección IPv4, no puedo acceder a la red IPv6.

No es para que entren en pánico... pero ¿alguien sabe si ANTEL está trabajando en este tema?

Cambiando de tema... ¿Alguien ha notado que no existe un logo para Internet? Estaba buscando una foto para poner en la nota (buscando en Google aparecen muchos logos de Internet Explorer), pero no existe... ¿Alguien se anima a crearlo, y hacemos fuerza para que se adopte como estándar? :)

miércoles, 21 de julio de 2010

Cambio en la numeración telefónica en Uruguay

El próximo 29 de agosto, en Uruguay cambia la numeración de los teléfonos fijos, pasando a tener todos 8 dígitos.

Las reglas para el cambio de numeración no son muy complicadas:
  • Los números 0800, 0900, y los números cortos, no cambian.
  • Los demás, se les agrega la característica adelante, y pueden pasar dos cosas:
    • el número queda de 8 dígitos => ese es el número (es el caso de Montevideo y Maldonado)
    • el número queda de 7 dígitos => se le agrega un 4 adelante (para el resto del país).
Hay más información en el sitio de ANTEL.

Para los impacientes (como yo), que tienen todos los números en la agenda del celular, acá les dejo un tip. Si hoy el número es X XXX XXX, desde un celular se puede discar +598 2X XXX XXX, y funciona. Es de suponer que a partir del 29 de agosto también va a funcionar, porque ese es el número internacional...

Lo que no dice nada que vayan a cambiar los números de los celulares, que hoy son de 9 dígitos aunque el primero siempre es un cero (y como todos sabemos los ceros a la izquierda no cuentan...). De todas formas el tip también sirve: si el número es un celular, y por lo tanto es de la forma 09X XXX XXX, se puede discar +598 9X XXX XXX, y funciona ahora y seguramente funcione en el futuro.

Ahora, una reflexión un poco más profunda... ¿Qué sentido tiene tener "números" de teléfono? Es decir, el número en sí tiene muy poca información (la localidad o la zona, o si es móvil, pero nada más).

En pleno siglo XXI, pienso que podría hacerse mejor. Un número de 8 dígitos no significa nada... Claramente el motivo de que sean todos dígitos, tiene sus raíces en los comienzos de la telefonía, hace al rededor de 150 años.

Si yo tuviera que inventar una "numeración" telefónica hoy en día, la haría más parecida a una dirección de e-mail... Digamos, algo así como nombre@antel.tel.uy. Tiene bastante más información que un número de 8 dígitos, ¿no? Por supuesto, también tiene sus desventajas... ¿Qué pasa cuando hay dos personas con el mismo nombre? Tampoco es demasiado práctico si hay que "discarlo" en vez de buscarlo en la agenda.

En todo caso no es mi intensión dar una solución, sino plantear el problema... Seguramente si se le dedica más de 30 segundos a pensarlo se encuentre una solución mejor que los 8 dígitos.

sábado, 17 de julio de 2010

Matemática... ¿Estás ahí?

Hace unos días terminé de leer el libro Matemática... ¿Estás ahí? de Adrián Paenza.

Realmente está muy bueno, vale la pena leerlo. Se puede bajar (legalmente, para uso personal) del sitio de la Universidad de Bs. As., junto con el resto de los libros de la serie (cinco en total, pero por ahora solo leí el primero).

Me tomo la libertad de reproducir acá un fragmento, donde demuestra por el absurdo que todos los números naturales son "interesantes".
Números interesantes
Voy a probar ahora que todos los números naturales son números “interesantes”. Claro, la primera pregunta que surge es: ¿qué quiere decir que un número sea interesante? Vamos a decir que un número lo es cuando tiene algún atractivo, algo que lo distinga, algo que merezca destacarlo de los otros, que tenga algún borde o alguna particularidad. Creo que todos entendemos ahora lo que quiero decir con interesante. Ahora, la demostración.
El número uno es interesante porque es el primero de todos. Lo distingue entonces el hecho de ser el más chico de todos los números naturales.
El número dos es interesante por varias razones: es el primer número par, es el primer número primo. Creo que con estos dos argumentos ya podemos distinguirlo.
El número tres también es interesante, porque es el primer número impar que es primo (por elegir una razón de las muchas que habría).
El número cuatro es interesante porque es una potencia de dos.
El número cinco es interesante porque es un número primo. Y de aquí en adelante deberíamos ponernos de acuerdo en que cuando un número es primo, ya tiene una característica fuerte que lo distingue y lo podríamos considerar interesante sin buscar otros argumentos.
Sigamos un poco más.
El número seis es interesante porque es el primer número compuesto (o sea, no es un número primo) que no sea una potencia de dos. Recuerde que el primer número compuesto que apareció es el cuatro, pero es una potencia de dos.
El número siete es interesante, y no hace falta argumentar más porque es primo.
Y así podríamos seguir. Lo que quiero probar con ustedes es que:
“Dado un número entero positivo cualquiera siempre... siempre... hay algo que lo transforma en ‘interesante’ o ‘atractivo’ o ‘distinguible’”.
¿Cómo hacer para probar esto con todos los números, si son infinitos? Supongamos que no fuera así. Entonces, eso quiere decir que hay números que llamaremos no interesantes. A esos números los ponemos en una bolsa (y supondremos que esta bolsa no está vacía). Es decir, tenemos una bolsa llena de números no interesantes. Vamos a ver que esto nos lleva a una contradicción. Esa bolsa —como todos los números que contiene son números naturales, o sea, enteros positivos— tiene que tener un primer elemento. Es decir, un número que sea el menor de todos los que están en la bolsa.
Pero entonces, el supuesto primer número no interesante se transforma en interesante. El hecho que lo distingue es que sería el primero de todos los números no interesantes, una razón más que suficiente para declararlo interesante. ¿No les parece? El error, entonces, provino de haber pensado que había números no interesantes. No es así. Esa bolsa (la de los números no interesantes) no puede contener elementos, porque si los tiene, alguno tiene que ser el primero, con lo que pasaría a ser interesante un número que por estar en la bolsa debería ser no interesante.
MORALEJA: “Todo número natural ES interesante”.
Simplemente genial :)

miércoles, 14 de julio de 2010

Propiedades en Objective-C y el manejo de memoria

Hace unos días comentaba sobre el manejo de memoria en Objective-C.

Hoy quería hablar en particular sobre las propiedades.

Cuando un declara un propiedad en una clase,  con la directiva @property, el setter de dicha propiedad puede tener una de las siguiente semánticas:

  • assign: se usa una asignación simple, es el valor por defecto
  • retain: se le envía un mensaje de "retain" al valor que se va a asignar a la propiedad
  • copy: se le envía un mensaje de "copy" (se crea una copia) al valor que se va a asignar.
Cuando se va a implementar el método setter (si no se usa la directiva @synthesize para que lo cree por defecto) se debe tener en cuenta la semántica que se le quiere dar a dicha propiedad.

Assign

Supongamos que tenemos una propiedad definida como 
@property (nonatomic, assign) NSObject *myProperty;
El método setter de dicha propiedad deberá ser de la siguiente forma:
- (void) setMyProperty:(NSObject *)valor {
    myProperty = valor;
    // custom implementation
}
Retain

Si en cambio la propiedad está definida como
@property (nonatomic, retain) NSObject *myProperty;
Entonces el método setter deberá ser:
- (void) setMyProperty:(NSObject *)valor {
    if (myProperty)
        [myProperty release];
    myProperty = [valor retain];
    // custom implementation
}
Copy

Por último, si la propiedad se declara como
@property (nonatomic, copy) NSObject *myProperty;
El método setter deberá ser:
- (void) setMyProperty:(NSObject *)valor {
    if (myProperty)
        [myProperty release];
    myProperty = [valor copy];
    // custom implementation
}
Método dealloc

En el caso que se haya declarado la propiedad como retain o como copy, en el método dealloc se debe liberar la memoria con
[myProperty release];
Esto no se debe hacer en el caso que la propiedad sea de tipo assign

domingo, 11 de julio de 2010

Uruguay y el mundial de fútbol

Se terminó el mundial.

Tenemos a España como nuevo campeón, que si bien tiene buen cuadro, no fue el equipo que dio mejor espectáculo. Los cuatro partidos que jugaron en la segunda fase fueron todos bastante aburridos, incluso la final, y terminaron los cuatro con idéntico resultado: 1 a 0.

De todas formas, ¡felicitaciones a los españoles por el campeonato!

Con respecto a Uruguay, creo que a nadie le quedan dudas que fue la revelación del campeonato. Fuimos los últimos en entrar, y nos metimos entre los cuatro mejores. Seguimos sin poder ganar en un partido por el tercer puesto, igual que en el 54 y en el 70... en algún momento se nos va a dar.

Esta selección de Uruguay, además de ser la sorpresa, jugó muy buen fútbol, y dio mucho más espectáculo que el que dieron los campeones del torneo. Además logró alcanzar algunos hitos que no se conseguían desde hace cuarenta años: ser primeros del grupo, ganar varios partidos seguidos, hacer muchos goles (11 en 7 partidos, cuando desde el 74 hizo solo 9 goles en 14 partidos...), quedar entre los 4 mejores, etc.

Como si esto fuera poco, Diego Forlán fue elegido el mejor jugador del mundial, además de haber quedado con la misma cantidad de goles que Müller (de Alemania) que fue el goleador del torneo.

Pero más allá del buen nivel futbolístico que mostró esta selección de Uruguay, tanto en sus jugadores de forma individual como a nivel de equipo, lo que más me llamó la atención fue la reacción de la gente. Se festejó el primer lugar en el grupo, la victoria ante Corea en octavos y la victoria ante Ghana en cuartos. Pero lo sorprendente es que se festejó haber perdido contra Holanda primero y contra Alemania después.

Esto demuestra la entrega y las ganas que le pusieron los jugadores. En general cuando Uruguay pierde, terminamos todos calientes con los técnicos, los jugadores, los directivos y los periodistas deportivos. Esta vez no fue el caso. La garra demostrada por los jugadores en todo el campeonato determinó que la gente se sintiera contenta a pesar de perder.

Mañana llega la selección, y el recibimiento va a ser casi como si hubieran sido los campeones.

¡Felicitaciones por el buen papel realizado!

Ahora a seguir trabajando y a no dormirse en los laureles, para que este desempeño no demore otros 40 años en repetirse :)

viernes, 9 de julio de 2010

Manejo de memoria en Objective-C

Una de las cosas que más me ha dado más trabajo por el momento en Objective-C es el manejo de memoria (la otra cosa es el diseño de la interfez de usuario con Interface Builder, pero ese es otro tema).

Desde hace muchos años, trabajo con lenguajes donde no había que preocuparse por el manejo de memoria, o bien porque el lenguaje tenía garbage collector (C#, Java) o bien porque la herramienta ocultaba el problema (GeneXus, por ejemplo con el generador C/SQL).

La última vez que me había tenido que preocupar por el manejo de memoria había sido en la facultad (hace más de 10 años), cuando en algún curso usamos C y C++...

En Objective-C creo que no es tan complicado como en C, pero igual suele dar bastantes dolores de cabeza.

Un buen recurso para empezar a ver el tema, es la documentación de Apple al respecto.

Los problemas de memoria suelen ser difíciles de diagnosticar, y hay de dos clases:
  1. Cuando se libera la memoria antes de tiempo (los más complicados), el programa cancela de forma aparentemente aleatoria, en distintos puntos en las sucesivas ejecuciones.
  2. Cuando no se libera memoria que ya no está en uso (memory leak), que para el programa no tiene ningún efecto negativo, pero que puede llegar eventualmente a dejar sin memoria al dispositivo. Estos casos se pueden detectar más fácilmente ejecutando en XCode con Run -> Performance Tools -> Leaks.
Las reglas que se deben seguir para saber cuando liberar memoria son:
  1. Si uno crea un objeto (mediante la función alloc, o alguna función que contenga "new" o "copy"), es responsable de liberarlo más adelante enviándole un mensaje "release".
  2. Si uno no crea el objeto (es el resultado de alguna otra invocación), entonces no es el dueño del mismo, y no tiene que liberarlo. Al no ser el dueño, puede ser que el objeto sea liberado en cualquier momento, y no tenemos control de esto.
  3. Si uno quiere "apoderarse" de un objeto, debe enviarle un mensaje "retain".
¿Simple, no? Lo que cuesta más es acostumbrarse...